@mjasnikovs/pi-task 0.38.10 → 0.38.12

package/dist/task/stall-detector.js

@@ -0,0 +1,159 @@
+/**
+ * Progress-based runaway guard for phase children — the replacement for a
+ * wall-clock cap.
+ *
+ * WHY NOT SECONDS. PHASE_CHILD_TIMEOUT_MS was sized against "measured HEALTHY
+ * planning children" on one local backend: decompose 89s, so 600s looked like a
+ * 6x margin. That sizing is not a property of the pathology, it is a property of
+ * that day's model, that day's samplers and that day's design doc. Measured on
+ * the same 27B backend with reasoning ON (2026-08-17, n=10 replays of one
+ * captured auto-decompose request, everything else byte-identical): every single
+ * healthy run took 610-927s and produced 26-42 correct titles. The cap would
+ * have killed 10 out of 10 GOOD runs. A slower model, a bigger design doc or a
+ * longer reasoning budget moves that number again — so any constant in seconds
+ * is wrong for someone.
+ *
+ * WHAT REPLACES IT. Two bounds, both dimensionless — invariant to model speed,
+ * project size and reasoning budget:
+ *
+ *   1. NO NEW GROUND. Count CONSECUTIVE tool calls whose RESULT taught the child
+ *      nothing: an error, or bytes it has already been given. A child paging
+ *      forward through a 25 KB design file gets different bytes every call and
+ *      never trips, however slow it is. A child re-opening the same four files
+ *      trips after NO_PROGRESS_LIMIT of them, however fast it is.
+ *
+ *      Judged on the RESULT, not the arguments, because the arguments lie. The
+ *      thrash measured on 2026-08-17 was 197 of 200 calls REFUSED by the
+ *      single-read guard, each at a different rising offset — so by arguments it
+ *      looked like textbook forward paging, and both an offset rule and the loop
+ *      detector's path rule waved all 200 through. By result it is 197 identical
+ *      refusals in a row, which is what it actually was.
+ *
+ *   2. CONTEXT CHURN. Sum the bytes of tool RESULTS the child has pulled in. Once
+ *      that exceeds CONTEXT_CHURN_FACTOR times its own context window and it
+ *      still has not answered, it has necessarily forgotten what it read first
+ *      and is re-reading to fill a window pi keeps compacting. That is the
+ *      mx5-n 2026-08-14 shape: 16m23s at 117,370 of a 120,064-token window,
+ *      ~56k tokens of tool output per minute, forward-paging the whole time so
+ *      rule 1 alone would not have caught it. The bound scales with the model's
+ *      OWN window, so a 1M-context model gets a 1M-context allowance.
+ *
+ * Neither rule can fire on a child that is thinking rather than calling tools:
+ * that case is bounded by the model's max tokens (server-enforced) and by the
+ * stream watchdog if the stream goes silent. Between the three there is no
+ * runaway left that needs a clock.
+ *
+ * Pure logic, no I/O, no timers. LoopDetector (loop-detector.ts) is the
+ * short-window sibling that trips FAST on an exact repeat; this is the
+ * whole-run backstop that trips on sustained non-progress.
+ */
+import { stableStringify } from './loop-detector.js';
+/**
+ * Consecutive no-new-ground tool results before the child is killed.
+ *
+ * Eight, because the honest reasons to get back something you have already seen
+ * are few and bounded: re-checking a file after an edit, a grep that lands in a
+ * file already read, a retry after a malformed call, a missing path. A child
+ * doing real work interleaves those with progress and resets the counter. In the
+ * replayed thrash the counter never resets at all — the observed runs made
+ * 188-201 consecutive dead calls. The gap between "a handful" and "two hundred"
+ * is wide enough that the exact value is not load-bearing.
+ */
+export const NO_PROGRESS_LIMIT = 8;
+/**
+ * Multiples of the child's OWN context window of tool output it may pull before
+ * being called stuck. Two, so a child is allowed to fill its window once and
+ * still have a whole window of budget left for legitimate re-reading after pi
+ * compacts. Past that it is provably re-reading what it can no longer hold.
+ */
+export const CONTEXT_CHURN_FACTOR = 2;
+/** Chars per token. Rough on purpose — the bound is a factor of 2, not a budget. */
+const CHARS_PER_TOKEN = 4;
+export class StallDetector {
+    limit;
+    churnFactor;
+    /** Every distinct result the child has been handed, for the WHOLE run. */
+    seenResults = new Set();
+    /** Exact (name, args) keys already issued — the fallback signal for a
+     *  transport that reports calls but not results. */
+    seenCalls = new Set();
+    deadStreak = 0;
+    resultChars = 0;
+    contextWindow = 0;
+    constructor(limit = NO_PROGRESS_LIMIT, churnFactor = CONTEXT_CHURN_FACTOR) {
+        this.limit = limit;
+        this.churnFactor = churnFactor;
+    }
+    /**
+     * Record a tool call. Returns a LoopHit (tagged with `stall`) when either
+     * rule has tripped, so it rides the kill/restart path the loop detector
+     * already has, else null.
+     *
+     * The verdict is read here but EARNED in noteResult: this is the hook the
+     * child runner can kill from, and a result only arrives after its call has
+     * been let through.
+     */
+    record(call) {
+        if (this.churnTripped()) {
+            return {
+                call,
+                count: Math.round(this.resultChars / CHARS_PER_TOKEN),
+                windowSize: this.contextWindow,
+                stall: 'context-churn'
+            };
+        }
+        const key = `${call.name}\x00${stableStringify(call.args)}`;
+        // A verbatim repeat is dead ground whatever its result turns out to be,
+        // and this is the only signal available if results are not reported.
+        if (this.seenCalls.has(key))
+            this.deadStreak++;
+        this.seenCalls.add(key);
+        if (this.deadStreak >= this.limit) {
+            return { call, count: this.deadStreak, windowSize: 0, stall: 'no-new-ground' };
+        }
+        return null;
+    }
+    /**
+     * A tool call finished. Its result is what actually entered the context, so
+     * it — not the arguments — decides whether the child learned anything. An
+     * error, or bytes already handed over earlier in this run, is dead ground.
+     */
+    noteResult(text, isError = false) {
+        this.resultChars += text.length;
+        if (isError || this.seenResults.has(text)) {
+            this.deadStreak++;
+            return;
+        }
+        this.seenResults.add(text);
+        this.deadStreak = 0;
+    }
+    /** Latest context-window size reported by the child. 0 until one arrives. */
+    noteContext(contextWindow) {
+        if (contextWindow > 0)
+            this.contextWindow = contextWindow;
+    }
+    churnTripped() {
+        if (this.contextWindow <= 0)
+            return false;
+        return this.resultChars / CHARS_PER_TOKEN > this.contextWindow * this.churnFactor;
+    }
+}
+/**
+ * Restart hint for a child killed by the stall detector. Names the specific
+ * mistake — re-reading covered ground vs pulling in more than it can hold —
+ * because "you ran out of time" (the old wall-clock hint) told a model that was
+ * working correctly but slowly to truncate its work for no reason.
+ */
+export function formatStallHint(kind) {
+    if (kind === 'context-churn') {
+        return ('[SYSTEM NOTE: Your previous attempt pulled in more file content than '
+            + 'its context window can hold, so the earliest material was dropped and '
+            + 'you began re-reading it. Do not re-open files. Read only what you have '
+            + 'not read yet, and write your answer from what you have.]');
+    }
+    return ('[SYSTEM NOTE: Your previous attempt made a run of tool calls that returned '
+        + 'nothing you had not already seen — you were re-opening files you had '
+        + 'already read. Read each region of a file AT MOST ONCE, and when a file is '
+        + 'too large to read whole, page FORWARD through it rather than re-opening '
+        + 'the start. Write your answer from what you have gathered.]');
+}

package/dist/task/task-gates.d.ts

@@ -63,6 +63,18 @@ export interface GateDeps {
      * tests or when `verify work` is off → the sequence treats it as a pass.
      */
     verify?: (ctx: ExtensionCommandContext, cwd: string, taskTitle: string, taskId: string) => Promise<VerifyOutcome>;
+    /**
+     * The DIFFERENTIAL re-verify the enforce pass runs against the enforced tree,
+     * to decide whether its own commit survives. Absent → `verify`, which is what
+     * it has always been, so production wiring is untouched.
+     *
+     * Its own field because it answers a different question from the gate above.
+     * While the two shared one field the only way to answer them differently was to
+     * count invocations — a `verifyCalls` state machine whose FIRST return existed
+     * solely to unlock `mode === 'edit'`, re-invented in the suite and again in
+     * scripts/enforce-revert-attribution-replay-ab.ts.
+     */
+    reVerify?: (ctx: ExtensionCommandContext, cwd: string, taskTitle: string, taskId: string) => Promise<VerifyOutcome>;
     /**
      * Hold the committed work to AGENTS.md / CLAUDE.md. `edit` (fix in place) only
      * with a clean verify signal to guard against; otherwise `flag` (report only).
@@ -293,4 +305,61 @@ export declare function askVerifyResolution(ctx: ExtensionCommandContext, title:
  * only a user cancel inside a gate child propagates (handled by the caller's
  * USER_CANCELLED path).
  */
+/** The durable per-task gate trail: every outcome is appended to the task file so
+ *  the sequence is auditable from artifacts alone. Best-effort — recording must
+ *  never break the gate sequence. */
+type Recorder = (line: string) => Promise<void>;
+/**
+ * The root-cause channel: was this FAIL caused by a pre-existing defect in a file
+ * some OTHER task created and this task never touched?
+ */
+type RootCauseRouter = (failReason: string, rationale: string, scope: 'worktree' | 'committed' | 'enforce-commit') => Promise<RepairCandidate | null>;
+/**
+ * What the VERIFY half settled. Either the sequence is over (`stop` carries the
+ * terminal GateResult — dismissed picker, cancelled session, interrupted or failed
+ * autofix) or the task proceeds to commit + enforce.
+ *
+ * `cleanPass` is the ONE fact that crosses to the enforce half: a GENUINE clean
+ * pass (a real signal ran and the work met it) is the only thing that gives
+ * enforce a signal to revert against, so only then may it edit in place. A no-op
+ * pass, a disabled gate or an accept-override leaves it false → flag-only.
+ */
+type VerifyGateStep = {
+    stop: GateResult;
+} | {
+    proceed: {
+        ctx: ExtensionCommandContext;
+        cleanPass: boolean;
+    };
+};
+/**
+ * The VERIFY resolution loop: run the task's verification against the finished
+ * work, and negotiate a FAIL through the graduated ladder (bounded lint fix →
+ * recommendation → unattended autofix → picker) until it verifies, is accepted,
+ * or terminates.
+ *
+ * Split out of `runGatesForTask` at the single boolean that crosses to the
+ * ENFORCE half. It carries 8 mutable locals over ~290 lines and has four terminal
+ * exits; enforce carries one local and always falls through. Joining them meant a
+ * test of the enforce differential had to traverse this whole loop first, which is
+ * why `deps.verify` was driven by an invocation counter whose first return existed
+ * only to unlock `mode === 'edit'`.
+ */
+export declare function resolveVerifyGate(ctxIn: ExtensionCommandContext, deps: GateDeps, p: GateParams, rec: Recorder, routeRootCause: RootCauseRouter): Promise<VerifyGateStep>;
+/**
+ * The ENFORCE differential: hold the committed work to AGENTS.md / CLAUDE.md,
+ * then decide whether the pass\'s own commit survives.
+ *
+ * `reVerify` is deliberately NOT `deps.verify`. They answer two different
+ * questions — the gate above, and this differential — and while they shared one
+ * field the only way to answer them differently was to count invocations.
+ *
+ * Reads `active` and never reassigns it: nothing here can replace the live
+ * session, unlike the autofix in the verify half.
+ */
+export declare function runEnforcePass(active: ExtensionCommandContext, deps: GateDeps, p: GateParams, rec: Recorder, routeRootCause: RootCauseRouter, args: {
+    cleanPass: boolean;
+    commit: CommitResult;
+}): Promise<void>;
 export declare function runGatesForTask(ctxIn: ExtensionCommandContext, deps: GateDeps, p: GateParams): Promise<GateResult>;
+export {};

package/dist/task/task-gates.js

@@ -67,60 +67,20 @@ export async function askVerifyResolution(ctx, title, failReason, rec) {
     return classifyResolutionAnswer(answer);
 }
 /**
- * Run the verify + enforce gates against a task's just-finished implementation.
+ * The VERIFY resolution loop: run the task's verification against the finished
+ * work, and negotiate a FAIL through the graduated ladder (bounded lint fix →
+ * recommendation → unattended autofix → picker) until it verifies, is accepted,
+ * or terminates.
  *
- * Lifted verbatim from /task-auto's per-task loop so the two commands gate
- * identically. Returns a GateResult; `done` means the caller should proceed (the
- * work is verified-or-accepted, checked off, committed, and enforced), every other
- * kind is a terminal stop the caller announces. Never throws for a gate outcome —
- * only a user cancel inside a gate child propagates (handled by the caller's
- * USER_CANCELLED path).
+ * Split out of `runGatesForTask` at the single boolean that crosses to the
+ * ENFORCE half. It carries 8 mutable locals over ~290 lines and has four terminal
+ * exits; enforce carries one local and always falls through. Joining them meant a
+ * test of the enforce differential had to traverse this whole loop first, which is
+ * why `deps.verify` was driven by an invocation counter whose first return existed
+ * only to unlock `mode === 'edit'`.
  */
-export async function runGatesForTask(ctxIn, deps, p) {
+export async function resolveVerifyGate(ctxIn, deps, p, rec, routeRootCause) {
     let active = ctxIn;
-    // Durable per-task gate trail — every outcome below is also appended to the
-    // task file so the sequence is auditable from artifacts alone. Best-effort.
-    const rec = async (line) => {
-        try {
-            await deps.record?.(p.cwd, p.taskId, line);
-        }
-        catch {
-            // recording must never break the gate sequence
-        }
-    };
-    /**
-     * ROOT-CAUSE CHANNEL (mx5 run 14 item 5). Ask whether a FAIL was caused by a
-     * pre-existing defect in a file some OTHER task created and this task never
-     * touched. On a hit: record the durable debt (so the final gate surfaces it)
-     * and queue a scoped repair task (so something finally FIXES it — run 14
-     * recorded the same `test/teardown.ts` cause twice and scheduled nothing, and
-     * the bug survived ~24h). Returns the candidate so the caller can also decide
-     * NOT to punish the current task for it. Never throws: any fault degrades to
-     * null, i.e. exactly the pre-existing behavior.
-     */
-    const routeRootCause = async (failReason, rationale, scope) => {
-        if (!deps.touchedFiles || !deps.introducedBy)
-            return null;
-        try {
-            const candidate = await findRepairCandidate({
-                failReason,
-                rationale,
-                currentTaskId: p.taskId,
-                touched: await deps.touchedFiles(p.cwd, scope),
-                introducedBy: rel => deps.introducedBy(p.cwd, rel)
-            });
-            if (!candidate)
-                return null;
-            await deps.recordDebt?.(p.cwd, p.taskId, `${failReason} — ROOT CAUSE: \`${candidate.file}\` (introduced by ${candidate.owner}, not touched by this task)`, 'root-cause');
-            await deps.recordRepairCandidate?.(p.cwd, candidate);
-            await rec(`root-cause: FAIL attributed to \`${candidate.file}\` — a pre-existing defect in ${candidate.owner}'s file that this task never touched; `
-                + 'recorded as durable debt and a scoped repair task queued');
-            return candidate;
-        }
-        catch {
-            return null;
-        }
-    };
     const verdictLine = (v) => v.ok ?
         v.reason ?
             `verify: PASS (${v.reason})`
@@ -289,7 +249,7 @@ export async function runGatesForTask(ctxIn, deps, p) {
             }
             if (choice.action === 'cancel') {
                 await rec('resolution: user dismissed the verify-FAIL picker — paused');
-                return { kind: 'paused', ctx: active, reason: failReason };
+                return { stop: { kind: 'paused', ctx: active, reason: failReason } };
             }
             if (choice.action === 'accept') {
                 const byYolo = yoloChoice !== null;
@@ -360,11 +320,11 @@ export async function runGatesForTask(ctxIn, deps, p) {
             });
             active = fixRes.ctx ?? active;
             if (fixRes.sessionCancelled)
-                return { kind: 'session-cancelled', ctx: active };
+                return { stop: { kind: 'session-cancelled', ctx: active } };
             if (fixRes.interrupted)
-                return { kind: 'interrupted', ctx: active };
+                return { stop: { kind: 'interrupted', ctx: active } };
             if (!fixRes.ok)
-                return { kind: 'failed', ctx: active, reason: fixRes.reason };
+                return { stop: { kind: 'failed', ctx: active, reason: fixRes.reason } };
             // Resume reuses the same inner task id, so p.taskId is stable.
             verified = await deps.verify(active, p.cwd, p.title, p.taskId);
             await rec(verdictLine(verified));
@@ -374,39 +334,21 @@ export async function runGatesForTask(ctxIn, deps, p) {
         // accept-override (verified.ok still false at break) is NOT a guardable signal.
         verifyCleanPass = verified.ok && !verified.reason;
     }
-    // Mark the work verified (parent task-list check-off for /task-auto; no-op for
-    // /task) BEFORE committing, so the commit captures the check-off too.
-    await p.onVerified?.();
-    // Commit the task's work as one snapshot FIRST — before guideline enforcement —
-    // so a passing task is durably recorded no matter what enforcement later finds.
-    const commit = await deps.commit(p.cwd, `task: ${p.title} (${p.taskId})`);
-    if (commit.committed) {
-        await rec(`commit: task snapshot committed${commit.note ? ` (${commit.note})` : ''}`);
-        // SAY WHAT WAS LEFT OUT. The stage skips untracked regenerable test-runner
-        // output (mx5 run 20: TASK_0027's `git add -A` swept in three Playwright
-        // failure screenshots and two later fix attempts were rejected for deleting
-        // them). A SILENT exclusion is the same failure class as the silent
-        // ignored-path write nexttask 4 closed, so it gets its own trail line.
-        if (commit.excluded && commit.excluded.length > 0) {
-            await rec(`commit: left ${commit.excluded.length} untracked test-runner artifact(s) out of the `
-                + `snapshot — regenerable output, not deliverables: `
-                + `${commit.excluded.slice(0, 8).join(', ')}`
-                + `${commit.excluded.length > 8 ? `, +${commit.excluded.length - 8} more` : ''}`);
-        }
-        active.ui.notify(`${p.tag}: committed "${p.title}".`, 'info');
-    }
-    else {
-        await rec(`commit: skipped (${commit.reason ?? 'unknown'})`);
-        // A benign skip ("nothing to commit", auto-commit off) is a warning. A real
-        // git failure is louder: it silently disables enforce AND every commit-based
-        // guard — mx5 run 4 lost all 10 commits (no container git identity) with only
-        // per-task warnings to show for it. "blocked" is the unmerged-index refusal
-        // (gitCommitAll) — the same severity: nothing can commit until it's resolved.
-        const gitFailure = /^git (commit|add) (failed|blocked)/.test(commit.reason ?? '');
-        active.ui.notify(gitFailure ?
-            `${p.tag}: COMMIT FAILED (${commit.reason}) — enforce and revert guards are disabled for this task.`
-            : `${p.tag}: not committed (${commit.reason ?? 'unknown'}) — continuing.`, gitFailure ? 'error' : 'warning');
-    }
+    return { proceed: { ctx: active, cleanPass: verifyCleanPass } };
+}
+/**
+ * The ENFORCE differential: hold the committed work to AGENTS.md / CLAUDE.md,
+ * then decide whether the pass\'s own commit survives.
+ *
+ * `reVerify` is deliberately NOT `deps.verify`. They answer two different
+ * questions — the gate above, and this differential — and while they shared one
+ * field the only way to answer them differently was to count invocations.
+ *
+ * Reads `active` and never reassigns it: nothing here can replace the live
+ * session, unlike the autofix in the verify half.
+ */
+export async function runEnforcePass(active, deps, p, rec, routeRootCause, args) {
+    const { cleanPass: verifyCleanPass, commit } = args;
     // With the task committed, hold its work to AGENTS.md / CLAUDE.md — but as a step
     // INSIDE the validation gate, gated by the verify signal (see GateDeps.enforce).
     // Skipped when nothing was committed this round, when enforce is off, or in tests
@@ -516,8 +458,9 @@ export async function runGatesForTask(ctxIn, deps, p) {
             if (enforceCommit.committed) {
                 // Differential guard: re-run the verify signal against the enforced
                 // tree. A regression ⇒ drop the enforce commit, keep the verified work.
-                const after = deps.verify ?
-                    await deps.verify(active, p.cwd, p.title, p.taskId)
+                const differential = deps.reVerify ?? deps.verify;
+                const after = differential ?
+                    await differential(active, p.cwd, p.title, p.taskId)
                     : { ok: true };
                 const afterReason = after.reason ?? 'enforce re-verify failed';
                 // PRE-EXISTING-CAUSE KEEP PATH (mx5 run 14 item 5b). Both of run
@@ -632,5 +575,86 @@ export async function runGatesForTask(ctxIn, deps, p) {
         // so a missing enforce run is explainable from the trail (mx5 audit gap).
         await rec('enforce: skipped (nothing committed this round)');
     }
+}
+export async function runGatesForTask(ctxIn, deps, p) {
+    const rec = async (line) => {
+        try {
+            await deps.record?.(p.cwd, p.taskId, line);
+        }
+        catch {
+            // recording must never break the gate sequence
+        }
+    };
+    /**
+     * ROOT-CAUSE CHANNEL (mx5 run 14 item 5). Ask whether a FAIL was caused by a
+     * pre-existing defect in a file some OTHER task created and this task never
+     * touched. On a hit: record the durable debt (so the final gate surfaces it)
+     * and queue a scoped repair task (so something finally FIXES it — run 14
+     * recorded the same `test/teardown.ts` cause twice and scheduled nothing, and
+     * the bug survived ~24h). Returns the candidate so the caller can also decide
+     * NOT to punish the current task for it. Never throws: any fault degrades to
+     * null, i.e. exactly the pre-existing behavior.
+     */
+    const routeRootCause = async (failReason, rationale, scope) => {
+        if (!deps.touchedFiles || !deps.introducedBy)
+            return null;
+        try {
+            const candidate = await findRepairCandidate({
+                failReason,
+                rationale,
+                currentTaskId: p.taskId,
+                touched: await deps.touchedFiles(p.cwd, scope),
+                introducedBy: rel => deps.introducedBy(p.cwd, rel)
+            });
+            if (!candidate)
+                return null;
+            await deps.recordDebt?.(p.cwd, p.taskId, `${failReason} — ROOT CAUSE: \`${candidate.file}\` (introduced by ${candidate.owner}, not touched by this task)`, 'root-cause');
+            await deps.recordRepairCandidate?.(p.cwd, candidate);
+            await rec(`root-cause: FAIL attributed to \`${candidate.file}\` — a pre-existing defect in ${candidate.owner}'s file that this task never touched; `
+                + 'recorded as durable debt and a scoped repair task queued');
+            return candidate;
+        }
+        catch {
+            return null;
+        }
+    };
+    const step = await resolveVerifyGate(ctxIn, deps, p, rec, routeRootCause);
+    if ('stop' in step)
+        return step.stop;
+    const { ctx: active, cleanPass } = step.proceed;
+    // Mark the work verified (parent task-list check-off for /task-auto; no-op for
+    // /task) BEFORE committing, so the commit captures the check-off too.
+    await p.onVerified?.();
+    // Commit the task's work as one snapshot FIRST — before guideline enforcement —
+    // so a passing task is durably recorded no matter what enforcement later finds.
+    const commit = await deps.commit(p.cwd, `task: ${p.title} (${p.taskId})`);
+    if (commit.committed) {
+        await rec(`commit: task snapshot committed${commit.note ? ` (${commit.note})` : ''}`);
+        // SAY WHAT WAS LEFT OUT. The stage skips untracked regenerable test-runner
+        // output (mx5 run 20: TASK_0027's `git add -A` swept in three Playwright
+        // failure screenshots and two later fix attempts were rejected for deleting
+        // them). A SILENT exclusion is the same failure class as the silent
+        // ignored-path write nexttask 4 closed, so it gets its own trail line.
+        if (commit.excluded && commit.excluded.length > 0) {
+            await rec(`commit: left ${commit.excluded.length} untracked test-runner artifact(s) out of the `
+                + `snapshot — regenerable output, not deliverables: `
+                + `${commit.excluded.slice(0, 8).join(', ')}`
+                + `${commit.excluded.length > 8 ? `, +${commit.excluded.length - 8} more` : ''}`);
+        }
+        active.ui.notify(`${p.tag}: committed "${p.title}".`, 'info');
+    }
+    else {
+        await rec(`commit: skipped (${commit.reason ?? 'unknown'})`);
+        // A benign skip ("nothing to commit", auto-commit off) is a warning. A real
+        // git failure is louder: it silently disables enforce AND every commit-based
+        // guard — mx5 run 4 lost all 10 commits (no container git identity) with only
+        // per-task warnings to show for it. "blocked" is the unmerged-index refusal
+        // (gitCommitAll) — the same severity: nothing can commit until it's resolved.
+        const gitFailure = /^git (commit|add) (failed|blocked)/.test(commit.reason ?? '');
+        active.ui.notify(gitFailure ?
+            `${p.tag}: COMMIT FAILED (${commit.reason}) — enforce and revert guards are disabled for this task.`
+            : `${p.tag}: not committed (${commit.reason ?? 'unknown'}) — continuing.`, gitFailure ? 'error' : 'warning');
+    }
+    await runEnforcePass(active, deps, p, rec, routeRootCause, { cleanPass, commit });
     return { kind: 'done', ctx: active };
 }

package/dist/task/verify-work.d.ts

@@ -55,9 +55,10 @@ export declare function extractSpecForVerification(taskBody: string): string | n
  * three of them).
  *
  * Each probe is now an ADAPTER: one row carrying only what is specific to it —
- * the dep field it reads, the empty value it degrades to, how its raw result
- * becomes finding lines, the notice block those lines produce, and the numbered
- * rule the notice routes the child to. The loop owns the ritual. (Same shape as
+ * its key (which names the thunk it reads from `deps.probes`), the empty value it
+ * degrades to, how its raw result becomes finding lines, the notice block those
+ * lines produce, and the numbered rule the notice routes the child to. The loop
+ * owns the ritual. (Same shape as
  * LOCKFILE_CHECKS in final-gate.ts, where a whole package ecosystem is one row.)
  *
  * THIS PROMPT IS A MEASURED ARTIFACT — its wording is A/B-tested on the live
@@ -71,10 +72,48 @@ export declare function extractSpecForVerification(taskBody: string): string | n
  * A row whose rule is woven into the numbered narrative elsewhere (3b inside the
  * substitution rules, 3f, 5c) carries `ruleId` for the reader and no `rule` text.
  */
+/**
+ * What each probe channel's RAW probe returns — the one place a channel's shape
+ * is declared. `ProbeKey` is derived from it, so a channel exists exactly when it
+ * has a row here; delete one and the compiler names its table row and its single
+ * binding line in gate-deps' `buildVerifyProbes`.
+ */
+export interface ProbeRaw {
+    substitution: string[];
+    prohibition: string[];
+    crossTaskDeletion: CrossTaskDeletion[];
+    probeGaming: string[];
+    skipEscape: string[];
+    foreignPath: string[];
+    scriptEscape: string[];
+    runnerGlob: string[];
+    testAssembly: string[];
+}
 /** Stable identity of one probe channel: table row ↔ findings-bag key. */
-export type ProbeKey = 'substitution' | 'prohibition' | 'crossTaskDeletion' | 'probeGaming' | 'skipEscape' | 'foreignPath' | 'scriptEscape' | 'runnerGlob' | 'testAssembly';
+export type ProbeKey = keyof ProbeRaw;
+/**
+ * The channels a CALLER binds — every key but `skipEscape`, which is pure text
+ * analysis of `deps.spec` and is sourced inside its own table row, so it is never
+ * absent and never bound from outside.
+ */
+export type BoundProbeKey = Exclude<ProbeKey, 'skipEscape'>;
+/**
+ * The bound probes: one optional thunk per channel, typed to that channel's raw
+ * shape. Built in ONE place (gate-deps' `buildVerifyProbes`); an absent key means
+ * the row is skipped. Adding a probe is a `ProbeRaw` line, a table row, and a
+ * binding line — nothing else.
+ */
+export type VerifyProbes = {
+    [K in BoundProbeKey]?: () => Promise<ProbeRaw[K]>;
+};
 /** The finding lines each probe channel contributed. Absent/empty ⇒ no block. */
 export type ProbeFindings = Partial<Record<ProbeKey, string[]>>;
+/**
+ * The channels a caller must bind — the table rows that read `deps.probes`, in
+ * table order. Exported so the one binder (gate-deps' `buildVerifyProbes`) can be
+ * checked against the table rather than against a hand-kept list.
+ */
+export declare const BOUND_PROBE_KEYS: readonly BoundProbeKey[];
 /**
  * Build the verification child's prompt. Kept pure so the wording is unit-tested
  * without spawning pi. The contract: run the spec's own verification in the real
@@ -131,75 +170,22 @@ export interface VerificationDeps {
         reason: string;
     }>;
     /**
-     * Progress hook for the DETERMINISTIC stage — the repo-health run plus the ten
-     * probes below, all of which run BEFORE the child (and therefore before the
+     * Progress hook for the DETERMINISTIC stage — the repo-health run plus the
+     * `probes` below, all of which run BEFORE the child (and therefore before the
      * child's own status widget exists). Called with a short label as each step
      * starts, so the caller can keep a live line on screen through what was
      * otherwise the run's longest stretch of dead air (MEASURED at 15–69s per
      * repo-health run). ABSENT → no progress reporting, same behaviour as before. */
     onStage?: (stage: string) => void;
     /**
-     * DETERMINISTIC substitution probe (see substitution-probe.ts): scans the task's
-     * changed test files for test-the-copy shapes and returns finding lines to inject
-     * into the child's prompt. A/B-proven load-bearing: the prompt rule alone caught
-     * the class 2/5, rule + probe finding 5/5. ABSENT or empty → no probe block. */
-    probe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC prohibition probe (see prohibition-probe.ts): spec-forbidden
-     * paths the task's diff modified anyway, injected as prompt findings under the
-     * no-waiver rule (4b). Advisory, never auto-FAIL — real prohibitions can be
-     * conditional prose. ABSENT or empty → no prohibition block. */
-    prohibitionProbe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC test-assembly probe (see test-assembly.ts): authored test files
-     * that rebuild production WIRING — importing the leaf modules the shipped entry
-     * composes and assembling their own copy instead of the real assembly — become
-     * prompt findings under rule 3f (F4 test-the-copy, 3rd recurrence). Pure import-
-     * graph shape; the child then drives the real assembly before trusting the copy.
-     * ABSENT or empty → no test-assembly block. */
-    testAssemblyProbe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC probe-gaming probe (see probe-gaming.ts, run-8 F6): added lines
-     * in the task's diff whose stated purpose is to make a CHECK pass instead of
-     * meeting the requirement it stands for ("return 401 so the verification test
-     * passes"). Injected as findings under rule 4c so the child confirms the
-     * underlying requirement is genuinely met rather than trusting the green check.
-     * Pure diff-text analysis; ABSENT or empty → no probe block. */
-    probeGamingProbe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC cross-task deletion probe (see task-provenance.ts, mx5 run 12
-     * PROMPT 2): tracked files the task's diff DELETES whose introducing task (git
-     * provenance) differs from the current task — a sibling's committed deliverable
-     * destroyed, typically to green a check. Injected as prompt findings under rule
-     * 4d (MANDATORY + verdict-gating, the A/B-proven shape — buried rules score
-     * 0/5), and carried structurally on a FAIL outcome so an ACCEPT records each as
-     * a durable debt. ABSENT or empty → no block. */
-    crossTaskDeletionProbe?: () => Promise<CrossTaskDeletion[]>;
-    /**
-     * DETERMINISTIC sandbox-path-leak probe (see foreign-path.ts, mx5 run 13
-     * PROMPT 4 item 1): absolute paths this task committed that exist only inside
-     * the authoring child's own environment — `/workspace/src/shared` in a vite
-     * alias — while the real file sits at `src/shared` here. The probe REPAIRS
-     * what it can deterministically first; only leaks it could not repair reach
-     * this hook, injected under rule 4e (MANDATORY + verdict-gating, the same
-     * shape as 4d — a leak makes the affected command fail to BUILD, so the
-     * checks that would notice never run at all). ABSENT or empty → no block. */
-    foreignPathProbe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC neutered-check-script probe (see script-escape.ts, mx5 run 13
-     * PROMPT 4 item 4): check-class scripts in a manifest THIS task changed whose
-     * exit status cannot be non-zero (`… || true`, an inverted-grep launder). The
-     * damage is second-order — the script still "passes", so the gates that run it
-     * report success without measuring anything — which is exactly why the child
-     * cannot discover it by running the check. ABSENT or empty → no block. */
-    scriptEscapeProbe?: () => Promise<string[]>;
-    /**
-     * DETERMINISTIC test-runner glob-collision probe (see runner-globs.ts, mx5 runs
-     * 7 AND 13, PROMPT 4 item 2): the manifest declares two runners whose file sets
-     * are not provably disjoint, so the scanning one imports the other's specs and
-     * dies during COLLECTION. Injected under rule 4g. UNKNOWN (one runner, or
-     * disjointness proven) yields nothing. ABSENT or empty → no block. */
-    runnerGlobProbe?: () => Promise<string[]>;
+     * The DETERMINISTIC probes, one optional thunk per channel (see `PROBE_ADAPTERS`
+     * above for what each channel is and which rule its findings cite; the
+     * substitution, prohibition, test-assembly, probe-gaming, cross-task-deletion,
+     * foreign-path, script-escape and runner-glob probes all live here). Bound in
+     * ONE place — gate-deps' `buildVerifyProbes` — and consumed by the table: an
+     * absent key skips its row, a throwing thunk degrades to the row's empty value.
+     * ABSENT → no probe blocks at all (tests / callers that wire none). */
+    probes?: VerifyProbes;
     /**
      * Result of the git-state guard for the MOST RECENT runChild call (see
      * git-state-guard.ts): did the child mutate repo state (stash/checkout/file