mixdog 0.9.40 → 0.9.41

package/src/runtime/agent/orchestrator/tools/shell-command.mjs

@@ -500,6 +500,7 @@ export function execShellCommand({
   onProgress,
   clientHostPid,
   backgroundOnTimeout,
+  promotedTimeoutMs = 0,
 }) {
   return new Promise(async (resolve) => {
     const taskId = `shell_${randomUUID().slice(0, 8)}`;
@@ -741,9 +742,8 @@ export function execShellCommand({
     //      BACKGROUND_MS opt-in) — an EARLIER promotion before the timeout, and
     //   2. the foreground timeout deadline (backgroundOnTimeout) — the default
     //      promote-on-timeout that replaces the old tree-kill.
-    // Either way the adopted job runs UNLIMITED (timeoutMs 0, matching the
-    // async default): the original foreground timeout no longer bounds it, and
-    // the adopted-job cap poll still enforces the 100 MB output ceiling.
+    // A capped explicit foreground timeout supplies its remaining deadline to
+    // the adopted job; otherwise adoption remains unlimited as before.
     // Mutually exclusive with settle() via the autoBackgrounded flag set
     // synchronously at the top before any await.
     const _autoBackground = async ({ reason = 'threshold' } = {}) => {
@@ -754,8 +754,7 @@ export function execShellCommand({
       if (child.exitCode != null || child.signalCode != null) return;
       autoBackgrounded = true;
       // The foreground capture is over; stop the local watchdogs/timers so
-      // they cannot treeKill the now-adopted child. The adopted job runs
-      // unlimited; refreshShellJob only enforces the output cap.
+      // they cannot treeKill the now-adopted child.
       if (timer) { clearTimeout(timer); timer = null; }
       _clearProgressTimer();
       if (sizeWatchdog) { clearInterval(sizeWatchdog); sizeWatchdog = null; }
@@ -777,14 +776,13 @@ export function execShellCommand({
       const stdoutPath = taskOutput.spilled ? taskOutput.stdoutPath : null;
       const stderrPath = taskOutput.spilled ? taskOutput.stderrPath : null;
       let job = null;
+      const adoptedTimeoutMs = reason === 'timeout' ? promotedTimeoutMs : 0;
       try {
         job = adoptForegroundShellJob({
           command,
           cwd,
           pid: child.pid,
-          // Unlimited: the promoted job is no longer bounded by the foreground
-          // timeout (matches the async omitted-default behavior).
-          timeoutMs: 0,
+          timeoutMs: adoptedTimeoutMs,
           mergeStderr: false,
           stdoutPath,
           stderrPath,
@@ -854,9 +852,10 @@ export function execShellCommand({
           outputCaptureError: taskOutput.writeError,
           backgrounded: true,
           jobId,
+          backgroundTimeoutMs: adoptedTimeoutMs,
           backgroundMessage: jobId
-            ? `${_verb}; still running — completion will be delivered as a background task notification. Use task with task_id:${jobId} only for manual wait/status/read/cancel.`
-            : `${_verb}; still running`,
+            ? `${_verb}; still running. Waiting is a decision, not a default: judge from the partial output whether this will finish within your remaining budget — if progress looks slow or stalled, diagnose the cause and pursue an alternative instead of waiting. Completion will be delivered as a background task notification; use task with task_id:${jobId} only for manual wait/status/read/cancel.`
+            : `${_verb}; still running — judge from the partial output whether waiting can finish in budget, or diagnose and pursue an alternative.`,
         }),
       );
     };

package/src/workflows/bench/WORKFLOW.md

@@ -1,36 +1,60 @@
 ---
 id: bench
 name: Bench
-description: "Autonomous benchmark workflow — loop to completion without user approval."
+description: "Autonomous headless benchmark workflow with directed execution and parallel cross-verification."
 hidden: true
 agents: worker, heavy-worker, reviewer, debugger, maintainer
 ---
 
 # Bench
 
-Autonomous: no user. Never wait for approval or ask questions; decide/proceed.
-Loop until verified complete or provably blocked.
-
-Lead supervises, delegates, coordinates, judges, decides. Lead directly handles
-simple 1–2-step work, coordination, pre-planning, config, final git deployment.
-Worker: several-step implementation; Heavy Worker: high-complexity multi-step
-implementation; Reviewer: implementation diff/regression/missing-check review;
-Debugger: very high complexity or root cause already failed once.
-
-1. Plan: form it and execute immediately; no approval step.
-2. Delegate: split to the maximum independent scopes. Parallelize independent
-   implementation/analysis/review/debugging, spawning every scope in one turn.
-   Shared/cross-cutting code does not justify merging: split by path and verify
-   shared parts yourself. A single scope needs a genuinely inseparable
-   dependency; state it. Within one complex scope, sequence steps with a
-   build/test-green gate between them. Briefs follow the Lead brief contract.
-   After async spawn, end turn: no polling, guessing, or dependent work until
-   completion notification.
-3. Review: one Reviewer per implementation scope, spawned 1:1 in the same turn,
-   never deferred/batched; wait. Fact-check agent responses and cross-check
-   implementation/review yourself before acting. Return fixes to the original
-   scope; loop verify -> fix -> re-verify until clean. Skip only simple,
-   low-risk review. If a bug survives 2+ fix cycles, Debugger investigates
-   before another fix round.
-4. Finish: verify final state yourself; stop only verified complete or hard
-   blocked. Final states outcome and evidence.
+Autonomous headless run: no user exists. Never ask questions, propose plans
+for approval, or end the turn waiting — decide and proceed. Standing
+pre-approval covers every action: edits, state mutation, delegation, builds.
+Loop until the task is verified complete or provably blocked.
+
+The pipeline has exactly three stages. Lead directs and verifies it, but NEVER
+executes the work itself: no edits, answers, or artifact generation, regardless
+of task size, perceived simplicity, or number of steps.
+
+## 1. Lead analysis and direction
+Lead performs real analysis first on EVERY task: task structure, required
+deliverables, boundaries, the task's own verification means, and solution
+direction. Convert it into clear execution direction and delegation briefs
+following the Lead brief contract.
+
+Hand the direction and briefs to executors. Analysis is not permission for
+Lead to implement any portion of the result: all edits, answer production, and
+artifact generation belong to executor sessions.
+
+## 2. Executors perform the work
+Use Worker sessions, or Heavy Worker sessions for broad scopes, to execute the
+directed work. Multiple workers MAY fan out in parallel, one per independent
+scope. Keep ownership clear for each assigned deliverable.
+
+Executors build the answer or artifact and perform basic does-it-run checks.
+They are not a verification role and do not own acceptance, requirements
+judgment, or final correctness. Each executor reports its result to Lead.
+
+## 3. Lead and Reviewer verify
+
+When executors report, Lead and Reviewer start cross-verification IN PARALLEL,
+never serially. Lead personally runs the task's own verification means, such
+as its test suite, grader script, simulator, or self-checkable output.
+Reviewer independently judges the result against every task requirement,
+including intent, correctness, boundaries, and deliverables.
+
+Judgment-type answers with no direct ground truth still require parallel
+cross-verification, even for a single small deliverable. Lead evaluates against
+available criteria while Reviewer independently judges requirements;
+perceived simplicity is no exemption.
+
+Merge any finding into a clear fix delta and return it to the SAME executor
+session owning the affected scope. The executor applies it and reports again.
+Lead and Reviewer repeat the same parallel cross-verification until both legs
+are clean; Lead never fixes or completes the work directly.
+
+Before declaring completion, Lead personally runs the task-required
+verification one final time and checks that every deliverable is present.
+Never end with a question, approval request, or proposed next step. Continue
+until verified complete or stop only when completion is provably blocked.

package/src/workflows/default/WORKFLOW.md

@@ -13,33 +13,38 @@ Approval is a later explicit user message after the latest plan ("do it",
 approval with a scope change needs a revised plan and fresh approval. Before
 approval: no edits, state mutation, or delegation.
 
-Lead supervises, delegates, coordinates, judges, decides. After approval,
-delegate by default; Lead only coordinates, does git, or an obvious 1-edit/
-1-check change. Route other implementation/research/debugging to its matching
-agent. Worker: bounded established path, low local risk/coupling/verification,
-clear local check. Heavy Worker: high risk/coupling/verification (including any
-high-risk scope), or coupled staged work needing coordinated verification.
-Architecture, contracts, storage, concurrency, security, lifecycle are
-indicators, not automatic categories. Reviewer verifies an implementation;
-Debugger handles requested debugging or root cause after a failed fix.
+Lead orchestrates and verifies. Lead-direct work is allowed only for pure
+read/analysis, git/configuration, or when the user explicitly supplies both the
+exact target and exact replacement/output. Never infer an exemption from a task
+name, file count, or perceived difficulty. Every other implementation, reverse
+engineering, debugging application, or artifact generation delegates to the
+matching agent. Debugger owns diagnosis and reverse engineering; Worker applies
+an established bounded change or fully specified artifact; Heavy Worker owns
+implementation that must establish the change through investigation or staged
+delivery. Applying a Debugger result is implementation, not diagnosis.
 
 1. Plan: draft before any implementation; settle scope/plan, ask if ambiguous,
    then await the gate.
-2. Delegate: maximize useful fan-out—one suitable Worker/Heavy Worker per ready
-   independent scope whose parallel gain exceeds coordination/merge cost; spawn
-   all in one turn, with no count cap. Serialize only a real dependency,
-   overlapping write, or inseparable coupling. Briefs follow the Lead brief
-   contract. After async spawn, end the turn.
-3. Review: after approval, complete delegation, review, self-verification, and
-   in-scope fixes without reapproval. Every delegated implementation gets one
-   Reviewer (all ready reviewers in one turn) and Lead integration/cross-scope
-   verification in parallel. Reviewer independently judges risk, intent,
-   boundaries; Lead checks acceptance/interactions, not duplicate same-scope
-   work. High-risk scopes add distinct lenses. Synthesize one verdict; send
-   merged fixes to the original live session; loop fix -> re-verify (same
-   Reviewer + Lead re-check) until clean. Debugger first for requested debugging
-   or a bug surviving 2+ fix cycles. Agent reports relay scope, verdict, next
-   work as in-progress, never conclusions.
+2. Delegate: one agent per ready independent scope; spawn all ready scopes in
+   one turn, with no count cap. Serialize only a real dependency, overlapping
+   write, or inseparable coupling. Briefs follow the Lead brief contract.
+   After async spawn, end the turn.
+3. Review: review is exempt only for pure read/analysis with no edit, artifact,
+   or state mutation; git/configuration; or a request where the user explicitly
+   supplies both the exact target and exact replacement/output. Every
+   non-exempt mutation or artifact, whether produced or applied by Worker,
+   Heavy Worker, Debugger, or Lead, gets one Reviewer (all ready reviewers in
+   one turn) and Lead
+   integration/cross-scope verification in parallel. Debugger analysis cannot
+   substitute for implementation review: applying a Debugger result triggers
+   the same Reviewer + Lead verification. Reviewer independently judges risk,
+   intent, boundaries; Lead checks acceptance/interactions, not duplicate
+   same-scope work. High-risk scopes add distinct lenses. Synthesize one
+   verdict; send merged fixes to the original live session; loop fix ->
+   re-verify (same Reviewer + Lead re-check) until clean. Debugger first for
+   requested debugging or a bug surviving 2+ fix cycles. Exempt mutations still
+   require shell self-verification before report. Agent reports relay scope,
+   verdict, next work as in-progress, never conclusions.
 4. Report: final (not interim) report compares work to approved plan and gives
    verified result; never forward raw agent output. Ask about ship/deploy when
    relevant. Build/deploy/commit/push require an explicit user request after