pi-gauntlet 5.2.3 → 5.3.1

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## v5.3.1 - 2026-09-06
+
+- Task tracking: planning initializes the list once; execution starts and completes existing indices explicitly. Execution retries and fix loops reuse their task; conformance adds only new remediation gaps and reuses their `Gn` indices across rounds.
+- `phase_tracker`: explicit implement/verify completion rejects recorded pending or in-progress tasks under the existing flow guards. Terminal-negative `failed` tasks remain failed; existing escalation rules still apply. Sequential tool execution prevents same-batch tracker updates from being read too early. Requires Pi 0.85.1 or newer; no new settings or tracker schema.
+- Foreground flow dispatch: agent calls explicitly set `async: false`, preserving independent implementation, per-patch SR and council fan-outs. Final order is parent full verification -> whole-diff CR -> conformance; removes async review/test overlap and its classification/polling branches. Pi-cohort's `forceTopLevelAsync` setting is incompatible with this policy.
+- Verification: runtime regressions and real Pi batch ordering pass. Behavioral diagnostics retain observed model-following limits: missed task reopening, an omitted async flag and malformed deferred-gap output. These are documented limits, not claims of infallible tracking or runtime enforcement of foreground dispatch. Spec: `doc/specs/2026-09-06-task-tracking-reliability.md`.
+
+## v5.3.0 - 2026-09-04
+
+- `chase-bug`: the real-bug verdict menu gains a fourth row, "Implement hotfix now", for small, evidenced, urgent fixes - a middle ceremony tier between the trivial carve-out and the full gauntlet. It hands off to the new companion `skills/chase-bug/hotfix.md`: dedicated `hotfix/<slug>` worktree, one implementer (TDD), one code review as the last mutation gate, an advisory conformance pass, then an unpushed squash commit on the default branch with guaranteed worktree/branch cleanup (or a PR when the pick says "as a PR"). Three safety invariants (no schema/persistence change, no public-contract change, one-commit rollback) gate the row's availability; three judgment predicates steer `[recommended]`. Triage itself stays read-only; the row is reachable only through the verdict menu. Zero changes to finishing, SDD, verification, extensions, or ci.mjs. Spec: `doc/specs/2026-09-03-chase-bug-hotfix.md`.
+
 ## v5.2.3 - 2026-09-01
 
 - Isolated `subagent` dispatch examples now mint an OS-temp report directory and use absolute `output:` paths, preventing reports from being captured in and deleted with throwaway worktrees. The parallel-dispatch Output capture guidance now distinguishes that isolated failure mode from non-isolated shared-working-tree commit/overwrite risk. Fixes #23. Spec: `doc/specs/2026-09-01-gh-23-absolute-report-paths.md`.

package/README.md

@@ -35,11 +35,11 @@ pi-gauntlet's only hard dependency is pi-cohort - every gate that dispatches a r
 
 Concretely, one change through the gauntlet:
 
-0. *(Optional)* Before there's even a spec, `/skill:shape-ticket` can create or repair a single tracker issue - shaping a raw ask into a Context/Problem/Idea/Acceptance Criteria ticket, gated by an AC integrity check, a cheap council roast, and one human-confirmed write that may include one optional gated Reporter-note comment. A failed roast is retried once, then surfaced inline at the gate if it fails again. It's a tool, not a phase: no worktree, no plan/phase tracker, runs from any repo state. It never activates on its own (`disable-model-invocation: true`) - invoke it explicitly. Similarly, `/skill:chase-bug` triages a raw bug report into an evidenced verdict - and can hand off to shape-ticket or brainstorming - before any spec exists.
+0. *(Optional)* Before there's even a spec, `/skill:shape-ticket` can create or repair a single tracker issue - shaping a raw ask into a Context/Problem/Idea/Acceptance Criteria ticket, gated by an AC integrity check, a cheap council roast, and one human-confirmed write that may include one optional gated Reporter-note comment. A failed roast is retried once, then surfaced inline at the gate if it fails again. It's a tool, not a phase: no worktree, no plan/phase tracker, runs from any repo state. It never activates on its own (`disable-model-invocation: true`) - invoke it explicitly. Similarly, `/skill:chase-bug` triages a raw bug report into an evidenced verdict - and can hand off to shape-ticket, brainstorming, or a bounded hotfix - before any spec exists.
 1. You describe the change. **`brainstorming`** sets up an isolated worktree, explores the codebase, and turns your description into a written spec. A multi-model critique runs on it automatically. If the spec replaces a known prior spec, brainstorming marks the predecessor with a `> **Superseded by:**` banner under its title (default format, syntax overridable via `.pi/gauntlet-overrides.md`; event-driven only — gauntlet never sweeps historical specs). **You read and approve the spec - human gate 1.** No implementation code exists yet.
 2. **`writing-plans`** decomposes the approved spec into atomic, independently-verifiable tasks, grouped into parallel waves where they don't touch the same files.
-3. **`subagent-driven-development`** executes the plan one task at a time, each in a fresh subagent, behind spec-compliance review then code-quality review. TDD-locked: red, green, refactor.
-4. **verify**: a whole-diff code review, then the **conformance gate** - a subagent reads the finished code and docs against your *original words* from step 1, not the plan, and reports per-requirement: delivered, partial, missing, drifted, or unauthorized. Inside a brainstorming-entered flow this gate is machine-blocked from being skipped. Compatible executable recommendations auto-run through an isolated fix-and-re-audit loop with no prompt; anything still open surfaces as a dense list - one line per decision, plain-language, with its recommended choice inline. Reply `1` to take every recommendation, or `2:` with per-item overrides; a current `CONFORMS` / no-concerns result goes straight to the branch options with no extra conformance sign-off.
+3. **`subagent-driven-development`** executes the plan one task at a time, each in a fresh subagent, behind spec-compliance review then code-quality review. TDD-locked: red, green, refactor. Independent implementation, review, and council batches remain parallel, but their dispatches are foreground: the orchestrator waits for terminal results before accepting work or advancing a phase.
+4. **verify**: the parent first runs the plan's full verification command set; only a passing result permits whole-diff code review, then the **conformance gate**. A review fix invalidates that result, so the parent reruns full verification before the next review or conformance gate. The conformance subagent reads the finished code and docs against your *original words* from step 1, not the plan, and reports per-requirement: delivered, partial, missing, drifted, or unauthorized. Inside a brainstorming-entered flow this gate is machine-blocked from being skipped. Compatible executable recommendations auto-run through an isolated fix-and-re-audit loop with no prompt; anything still open surfaces as a dense list - one line per decision, plain-language, with its recommended choice inline. Reply `1` to take every recommendation, or `2:` with per-item overrides; a current `CONFORMS` / no-concerns result goes straight to the branch options with no extra conformance sign-off.
 5. **`finishing-a-development-branch`**: squash, PR, keep, or discard. Once a PR exists, run `/skill:gatekeep-pr <pr>` to verify it against its issue before merging. **Human gate 2** - the only other decision you make.
 6. *(Optional)* Once the merge lands, `/skill:check-delivery <ref>` can prove delivery - default-branch landing, delivery target, per-AC evidence - before the tracker status advances. Explicit invocation only, no auto-chain: deploys commonly lag merges by minutes to hours, so an auto-run would routinely check too early.
 
@@ -69,9 +69,9 @@ Everything between gate 1 and gate 2 - task breakdown, implementation, both revi
 
 pi-gauntlet ships three kinds of pieces, layered on top of pi-cohort's dispatch:
 
-- **17 skills** - the workflow logic. Thirteen activate automatically when pi sees the matching kind of task, and each one gates the next: `brainstorming`, `writing-plans`, `roasting-the-spec`, `test-driven-development`, `subagent-driven-development`, `dispatching-parallel-agents`, `verification-before-completion`, `requesting-code-review`, `receiving-code-review`, `using-git-worktrees`, `finishing-a-development-branch`, `writing-skills`, `linear` (reads/searches/comments on/manages Linear tickets via the `linearis` CLI; owns all linearis mechanics and the `## Issue tracker` overrides schema; tracker-facing skills route to it). Four more are explicit-invocation-only (`disable-model-invocation: true`): `shape-ticket` creates or repairs one tracker issue per run against a Context/Problem/Idea/Acceptance-Criteria template, gated by an AC integrity check, a cheap council roast, and a single human-confirmed write - run it with `/skill:shape-ticket`. `gatekeep-pr` is consent-gated pre-merge verification of a PR against its issue - read-only gathering, verification evidence resolved CI-first (green checks on the exact assessed head count as evidence; the project's verification command runs only as fallback), a rubric-based review, then a deterministic authorship-aware menu with stable finding IDs (P#/L#/C#/F#) and numbered pre-composed courses (fixes execute as a single parallel-safe wave: one gate run, one re-review, one push); nothing mutates (fixes, pushes, reviews, merges) until you pick a row - run it with `/skill:gatekeep-pr <pr>`. `check-delivery` is a post-merge detective control: proves an issue actually shipped (default-branch landing, delivery target, per-AC evidence) before its tracker status advances; it never writes a terminal status - run it with `/skill:check-delivery <ref>`. `chase-bug` is human-only bug triage: read-only root-cause discovery to an evidenced verdict menu (real bug -> ticket/brainstorm/respond; five negative verdicts), then a gated response to the reporter for addressable origins (GitHub issue / tracker ticket) and a rendered verdict summary otherwise - it never fixes during triage - run it with `/skill:chase-bug`.
+- **17 skills** - the workflow logic. Thirteen activate automatically when pi sees the matching kind of task, and each one gates the next: `brainstorming`, `writing-plans`, `roasting-the-spec`, `test-driven-development`, `subagent-driven-development`, `dispatching-parallel-agents`, `verification-before-completion`, `requesting-code-review`, `receiving-code-review`, `using-git-worktrees`, `finishing-a-development-branch`, `writing-skills`, `linear` (reads/searches/comments on/manages Linear tickets via the `linearis` CLI; owns all linearis mechanics and the `## Issue tracker` overrides schema; tracker-facing skills route to it). Four more are explicit-invocation-only (`disable-model-invocation: true`): `shape-ticket` creates or repairs one tracker issue per run against a Context/Problem/Idea/Acceptance-Criteria template, gated by an AC integrity check, a cheap council roast, and a single human-confirmed write - run it with `/skill:shape-ticket`. `gatekeep-pr` is consent-gated pre-merge verification of a PR against its issue - read-only gathering, verification evidence resolved CI-first (green checks on the exact assessed head count as evidence; the project's verification command runs only as fallback), a rubric-based review, then a deterministic authorship-aware menu with stable finding IDs (P#/L#/C#/F#) and numbered pre-composed courses (fixes execute as a single parallel-safe wave: one gate run, one re-review, one push); nothing mutates (fixes, pushes, reviews, merges) until you pick a row - run it with `/skill:gatekeep-pr <pr>`. `check-delivery` is a post-merge detective control: proves an issue actually shipped (default-branch landing, delivery target, per-AC evidence) before its tracker status advances; it never writes a terminal status - run it with `/skill:check-delivery <ref>`. `chase-bug` is human-only bug triage: read-only root-cause discovery to an evidenced verdict menu (real bug -> ticket/brainstorm/hotfix/respond; five negative verdicts), then a gated response to the reporter for addressable origins (GitHub issue / tracker ticket) and a rendered verdict summary otherwise - it never fixes during triage; the hotfix row hands off to `skills/chase-bug/hotfix.md` after the menu - run it with `/skill:chase-bug`.
 - **7 subagent personas** - the specialized child agents the skills dispatch via pi-cohort: `implementer`, `code-reviewer`, `spec-reviewer`, `conformance-reviewer`, `spec-summarizer`, `spec-council-member`, `spec-council-synthesizer`. See [doc/personas.md](./doc/personas.md) for what each one does and why its permissions are scoped the way they are.
-- **3 runtime extensions** - the enforcement layer. `plan-tracker` and `phase-tracker` are tools skills call to track progress (with a TUI widget); `verify-before-ship` is a hook that warns if you push or open a PR without a passing test run since your last edit; a phase-tracker flow guard reminds on implement-phase commits missing spec/code review. phase-tracker also registers plan_check, a deterministic plan linter (8 mechanical plan-vs-spec checks) whose pass stamp gates implement-start inside a gauntlet flow. See [doc/configuration.md](./doc/configuration.md) for the settings each one reads.
+- **3 runtime extensions** - the enforcement layer. `plan-tracker` and `phase-tracker` are tools skills call to track progress (with a TUI widget); `verify-before-ship` is a hook that warns if you push or open a PR without a passing test run since your last edit; a phase-tracker flow guard reminds on implement-phase commits missing spec/code review. In a brainstorming-entered flow, phase-tracker rejects `implement` or `verify` completion while tracker tasks remain pending or in progress; see [its configuration reference](./doc/configuration.md#phase-tracker). phase-tracker also registers plan_check, a deterministic plan linter (8 mechanical plan-vs-spec checks) whose pass stamp gates implement-start inside a gauntlet flow. See [doc/configuration.md](./doc/configuration.md) for the settings each one reads.
 
 pi-gauntlet is **opinionated**: every non-trivial change is *meant* to ride this one pipeline, entered through `brainstorming`. Enforcement is opt-in by entry, not ambient: once brainstorming starts a flow, the phase-tracker extension mechanically blocks a phase from closing before its gate runs, and warns once if the main loop writes code during implement (subagents own implement-phase edits). A change made *without* entering the flow (a typo, a formatting run, a dependency bump - see "When to use / when NOT to use") is not gated; the discipline of routing real work through the pipeline is a convention the tooling supports, not a trap it springs on every edit.
 
@@ -89,12 +89,12 @@ pi-gauntlet is **opinionated**: every non-trivial change is *meant* to ride this
 
 **Use it** for any change with more than one moving part: a feature, a refactor across files, anything where "what did we actually agree to build" matters by the time it's done.
 
-**Don't use it** for a one-line fix, a typo, or a throwaway spike you're going to discard. The gates have real overhead - a spec, a plan, a conformance check - and that overhead isn't worth paying for a change trivial enough to just make.
+**Don't use it** for a one-line fix, a typo, or a throwaway spike you're going to discard. The gates have real overhead - a spec, a plan, a conformance check - and that overhead isn't worth paying for a change trivial enough to just make. Between that carve-out and the full pipeline sits one middle tier: `chase-bug`'s hotfix row - a small, evidenced, urgent fix landed as an unpushed squash, entered only through the triage verdict menu.
 
 ## Requirements
 
-- [pi-coding-agent](https://github.com/earendil-works/pi) ≥ 0.1.0
-- [pi-cohort](https://github.com/jjuraszek/pi-cohort) ≥ 1.4.5 - required peer package. Skills that dispatch agents (`requesting-code-review`, `subagent-driven-development`, `dispatching-parallel-agents`, `writing-plans`, `writing-skills`, `shape-ticket`, `roasting-the-spec`) call `subagent({})`, which pi-cohort provides. pi-gauntlet does not vendor the dispatch tool; without pi-cohort those skills have nothing to call.
+- [pi-coding-agent](https://github.com/earendil-works/pi) ≥ 0.85.1 - tested minimum for sequential `phase_tracker` tool execution, which persists a tracker update before a later tool call in the same model message.
+- [pi-cohort](https://github.com/jjuraszek/pi-cohort) ≥ 1.4.5 - required peer package. Skills that dispatch agents (`requesting-code-review`, `subagent-driven-development`, `dispatching-parallel-agents`, `writing-plans`, `writing-skills`, `shape-ticket`, `roasting-the-spec`) call `subagent({})`, which pi-cohort provides. pi-gauntlet does not vendor the dispatch tool; without pi-cohort those skills have nothing to call. Gauntlet execution dispatches explicitly use `async: false`; do not enable pi-cohort's incompatible `forceTopLevelAsync` setting. See pi-cohort's [dispatch configuration](https://github.com/jjuraszek/pi-cohort/blob/main/doc/configuration.md) for that setting's owner and semantics.
 
 Both packages must be listed in your `.pi/settings.json#packages` array (pi adds them automatically when you `pi install`). pi-gauntlet and pi-cohort are versioned independently but release together whenever dispatch semantics change - pin compatible versions of both.
 

package/extensions/phase-tracker.test.ts

@@ -56,11 +56,12 @@ function harness(options: { cwd?: string; branch?: unknown[]; idle?: boolean; be
   const tools: { name: string; execute: (...args: any[]) => unknown }[] = [];
   const sent: { message: any; options: any }[] = [];
   let idle = options.idle ?? true;
+  let branch = options.branch ?? [];
   const ctx = {
     cwd: options.cwd ?? tempCwd(),
     hasUI: false,
     isIdle: () => idle,
-    sessionManager: { getBranch: () => options.branch ?? [] },
+    sessionManager: { getBranch: () => branch },
   };
   const pi = {
     on(event: string, handler: (event: unknown, context: unknown) => unknown) {
@@ -68,7 +69,7 @@ function harness(options: { cwd?: string; branch?: unknown[]; idle?: boolean; be
       registered.push(handler);
       handlers.set(event, registered);
     },
-    registerTool(tool: { name: string; execute: (...args: any[]) => unknown }) {
+    registerTool(tool: { name: string; executionMode?: string; execute: (...args: any[]) => unknown }) {
       tools.push(tool);
     },
     sendMessage(message: unknown, sendOptions: unknown) {
@@ -86,7 +87,7 @@ function harness(options: { cwd?: string; branch?: unknown[]; idle?: boolean; be
     for (const handler of handlers.get(name) ?? []) results.push(await handler(event, ctx));
     return results;
   };
-  return { emit, emitEvent, sent, tools, ctx, setIdle: (next: boolean) => (idle = next) };
+  return { emit, emitEvent, sent, tools, ctx, setIdle: (next: boolean) => (idle = next), setBranch: (next: unknown[]) => (branch = next) };
 }
 
 const settle = async (h: ReturnType<typeof harness>) => {
@@ -289,6 +290,163 @@ test("resumed session: closure gate blocks complete verify without a conformance
   assert.equal(res.details.error, "no conformance-reviewer dispatch observed");
 });
 
+const taskSnapshot = (tasks: { name: string; status: string }[], isError = false) => ({
+  type: "message",
+  message: { role: "toolResult", toolName: "plan_tracker", isError, details: { tasks } },
+});
+
+const completePhase = async (h: ReturnType<typeof harness>, phase: "implement" | "verify") => {
+  const tool = h.tools.find((t) => t.name === "phase_tracker")!;
+  return (await tool.execute("complete", { action: "complete", phase }, undefined, undefined, h.ctx)) as {
+    content: { text: string }[];
+    details: { error?: string; phases: Record<Phase, { status: string }> };
+  };
+};
+
+test("phase_tracker registration requests sequential execution", () => {
+  const h = harness();
+  assert.equal(h.tools.find((t) => t.name === "phase_tracker")!.executionMode, "sequential");
+});
+
+test("all-complete plan activity auto-completes an active implement phase", async () => {
+  const h = harness({ branch: implementBranch() });
+  await h.emit("session_start");
+  await h.emitEvent("tool_execution_end", {
+    toolName: "plan_tracker",
+    isError: false,
+    result: { details: { tasks: [{ status: "complete" }, { status: "complete" }] } },
+  });
+  const tool = h.tools.find((t) => t.name === "phase_tracker")!;
+  const status = (await tool.execute("t1", { action: "status" }, undefined, undefined, h.ctx)) as {
+    details: { phases: { implement: { status: string } } };
+  };
+  assert.equal(status.details.phases.implement.status, "complete");
+});
+
+test("cold implement and verify completions ignore unfinished snapshots", async () => {
+  for (const phase of ["implement", "verify"] as const) {
+    const h = harness({
+      branch: [
+        phaseResult("start", phases({ [phase]: "in_progress" })),
+        taskSnapshot([{ name: "standalone task", status: "pending" }]),
+      ],
+    });
+    await h.emit("session_start");
+    const completed = await completePhase(h, phase);
+    assert.equal(completed.details.error, undefined, phase);
+    assert.equal(completed.details.phases[phase].status, "complete", phase);
+  }
+});
+
+test("completion backstop rejects unfinished snapshot indices, preserves state, and permits same-index retry", async () => {
+  const branch: unknown[] = [
+    ...resumedBranch({ plan: "complete", implement: "complete", verify: "in_progress" }),
+    subagentResult(["conformance-reviewer"]),
+    taskSnapshot([
+      { name: "T1 implementation", status: "complete" },
+      { name: "G1 conformance", status: "pending" },
+      { name: "G2 conformance", status: "in_progress" },
+    ]),
+  ];
+  const h = harness({ branch });
+  await h.emit("session_start");
+  const rejected = await completePhase(h, "verify");
+  assert.equal(rejected.details.error, "unfinished tasks");
+  assert.equal(rejected.details.phases.verify.status, "in_progress");
+  assert.match(rejected.content[0].text, /1: G1 conformance \(pending\)/);
+  assert.match(rejected.content[0].text, /2: G2 conformance \(in_progress\)/);
+
+  branch.push(taskSnapshot([
+    { name: "T1 implementation", status: "complete" },
+    { name: "G1 conformance", status: "complete" },
+    { name: "G2 conformance", status: "complete" },
+  ]));
+  const completed = await completePhase(h, "verify");
+  assert.equal(completed.details.error, undefined);
+  assert.equal(completed.details.phases.verify.status, "complete");
+});
+
+test("completion backstop uses the latest successful current-branch snapshot", async () => {
+  const branch: unknown[] = [
+    ...resumedBranch({ plan: "complete", implement: "in_progress" }),
+    taskSnapshot([{ name: "old", status: "pending" }]),
+    taskSnapshot([{ name: "errored", status: "pending" }], true),
+  ];
+  const h = harness({ branch });
+  await h.emit("session_start");
+  const rejected = await completePhase(h, "implement");
+  assert.equal(rejected.details.error, "unfinished tasks");
+  assert.match(rejected.content[0].text, /0: old \(pending\)/);
+
+  branch.push(taskSnapshot([])); // clear/init supersedes the old snapshot
+  assert.equal((await completePhase(h, "implement")).details.phases.implement.status, "complete");
+
+  const resetOnlyBranch: unknown[] = [
+    ...resumedBranch({ plan: "complete", implement: "in_progress" }),
+    taskSnapshot([{ name: "retained through reset", status: "in_progress" }]),
+    phaseResult("reset", phases()),
+    ...resumedBranch({ plan: "complete", implement: "in_progress" }),
+  ];
+  const resetOnly = harness({ branch: resetOnlyBranch });
+  await resetOnly.emit("session_start");
+  assert.equal((await completePhase(resetOnly, "implement")).details.error, "unfinished tasks");
+  resetOnlyBranch.push(taskSnapshot([{ name: "retained through reset", status: "complete" }]));
+  assert.equal((await completePhase(resetOnly, "implement")).details.phases.implement.status, "complete");
+});
+
+test("completion backstop preserves exclusions and closure-error precedence", async () => {
+  const unfinished = taskSnapshot([{ name: "failed", status: "failed" }]);
+  const explicitImplement = harness({ branch: [...resumedBranch({ plan: "complete", implement: "in_progress" }), unfinished] });
+  await explicitImplement.emit("session_start");
+  assert.equal((await completePhase(explicitImplement, "implement")).details.phases.implement.status, "complete");
+
+  const closureFirst = harness({
+    branch: [...resumedBranch({ plan: "complete", implement: "complete", verify: "in_progress" }), taskSnapshot([{ name: "T1", status: "pending" }])],
+  });
+  await closureFirst.emit("session_start");
+  assert.equal((await completePhase(closureFirst, "verify")).details.error, "no conformance-reviewer dispatch observed");
+
+  const disabled = harness({
+    cwd: tempCwd({ piGauntlet: { flowGuards: { enforce: false } } }),
+    branch: [...resumedBranch({ plan: "complete", implement: "in_progress" }), taskSnapshot([{ name: "T1", status: "pending" }])],
+  });
+  await disabled.emit("session_start");
+  assert.equal((await completePhase(disabled, "implement")).details.phases.implement.status, "complete");
+
+  const adHoc = harness({ branch: [taskSnapshot([{ name: "T1", status: "pending" }])] });
+  await adHoc.emit("session_start");
+  const tool = adHoc.tools.find((t) => t.name === "phase_tracker")!;
+  assert.equal((await tool.execute("x", { action: "complete", phase: "plan" }, undefined, undefined, adHoc.ctx)).details.error, undefined);
+});
+
+test("completion backstop leaves no/empty snapshots and skip alone, and uses the switched branch", async () => {
+  const noSnapshot = harness({ branch: resumedBranch({ plan: "complete", implement: "in_progress" }) });
+  await noSnapshot.emit("session_start");
+  assert.equal((await completePhase(noSnapshot, "implement")).details.phases.implement.status, "complete");
+
+  const skipped = harness({
+    branch: [...resumedBranch({ plan: "complete", implement: "in_progress" }), taskSnapshot([{ name: "T1", status: "pending" }])],
+  });
+  await skipped.emit("session_start");
+  const skipTool = skipped.tools.find((t) => t.name === "phase_tracker")!;
+  assert.equal((await skipTool.execute("skip", { action: "skip", phase: "implement", reason: "waived" }, undefined, undefined, skipped.ctx)).details.error, undefined);
+
+  const switched = harness({
+    branch: [...resumedBranch({ plan: "complete", implement: "in_progress" }), taskSnapshot([{ name: "off branch", status: "pending" }])],
+  });
+  await switched.emit("session_start");
+  switched.setBranch([...resumedBranch({ plan: "complete", implement: "in_progress" }), taskSnapshot([{ name: "active", status: "complete" }])]);
+  await switched.emit("session_switch");
+  assert.equal((await completePhase(switched, "implement")).details.phases.implement.status, "complete");
+
+  const closureOff = harness({
+    cwd: tempCwd({ piGauntlet: { closureReview: { enforce: false } } }),
+    branch: [...resumedBranch({ plan: "complete", implement: "complete", verify: "in_progress" }), taskSnapshot([{ name: "T1", status: "pending" }])],
+  });
+  await closureOff.emit("session_start");
+  assert.equal((await completePhase(closureOff, "verify")).details.error, "unfinished tasks");
+});
+
 const subagentResult = (agents: string[]) => ({
   type: "message",
   message: {

package/extensions/phase-tracker.ts

@@ -774,6 +774,7 @@ export default function (pi: ExtensionAPI) {
       "Track workflow phase progress (brainstorm → plan → implement → verify → ship); " +
       "ad-hoc calls do not arm gates. Not for ad-hoc use.",
     parameters: PhaseTrackerParams,
+    executionMode: "sequential",
 
     async execute(_toolCallId, params, _signal, _onUpdate, ctx) {
       switch (params.action) {
@@ -891,6 +892,43 @@ export default function (pi: ExtensionAPI) {
               } as PhaseTrackerDetails,
             };
           }
+          if (
+            gauntletEntered &&
+            (params.phase === "implement" || params.phase === "verify") &&
+            resolveFlowGuards(loadGauntletSettings(ctx.cwd).gauntlet).enforce
+          ) {
+            let tasks: { name: string; status: string }[] = [];
+            for (const entry of [...ctx.sessionManager.getBranch()].reverse()) {
+              if (
+                entry.type !== "message" ||
+                entry.message.role !== "toolResult" ||
+                entry.message.toolName !== "plan_tracker" ||
+                entry.message.isError
+              ) {
+                continue;
+              }
+              const details = entry.message.details as { tasks?: { name: string; status: string }[]; error?: string } | undefined;
+              if (!details || details.error || !details.tasks) continue;
+              tasks = details.tasks;
+              break;
+            }
+            const unfinished = tasks.flatMap((task, index) =>
+              task.status === "pending" || task.status === "in_progress"
+                ? [`${index}: ${task.name} (${task.status})`]
+                : [],
+            );
+            if (unfinished.length) {
+              return {
+                content: [
+                  {
+                    type: "text",
+                    text: `Cannot complete ${params.phase}: unfinished tasks:\n${unfinished.join("\n")}\nReconcile these same indices against acceptance evidence, update them and retry.`,
+                  },
+                ],
+                details: { action: "complete", phases: { ...phases }, error: "unfinished tasks" } as PhaseTrackerDetails,
+              };
+            }
+          }
           phases = { ...phases, [params.phase]: transitionPhaseState("complete") as PhaseState };
           firedGuards.clear();
           updateWidget(ctx);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "5.2.3",
+  "version": "5.3.1",
   "description": "Opinionated, gated workflow skills, subagent personas, and runtime extensions for the pi coding agent.",
   "author": "Jacek Juraszek",
   "type": "module",

package/skills/brainstorming/SKILL.md

@@ -36,6 +36,12 @@ The line: exercising the system **as it is today** is research; exercising the *
 
 This skill ends with a **written, user-reviewed spec inside a worktree**. Nothing else.
 
+## Foreground dispatch policy
+
+Flow-owned execution dispatches run in the foreground: set top-level `async: false` on gather, critique, council, summary, implementation, review, conformance, and retry calls. `forceTopLevelAsync` must remain unset or false; it is incompatible with this flow. See [pi-cohort dispatch configuration](https://github.com/jjuraszek/pi-cohort/blob/main/doc/configuration.md). If a dispatch returns an async handle despite `async: false`, stop and report the configuration error: do not poll it, relaunch work, or advance the flow. An intercom-detached child is likewise incomplete work; use the existing coordination path and never accept or duplicate it.
+
+Foreground does not serialize independent work: preserve existing isolated parallel `tasks` batches and await their terminal results before acceptance or tracker/phase advancement.
+
 ## Checklist
 
 Work through the items below **in order**. This is your own checklist to follow, not a `plan_tracker` plan — brainstorming is open-ended exploration, and `plan_tracker` is execution-only (the implement phase). The terminal state is the user review gate; after approval the **only** next skill is `/skill:writing-plans`. Do not jump to implementation, and do not silently drop the critique pass.
@@ -280,7 +286,7 @@ The first three checks — **placeholder scan**, **internal consistency**, and *
 - **Otherwise** → dispatch one fresh `worker` that applies the scope + ambiguity checks and fixes them in place:
 
   ```
-  subagent({ agent: "worker", context: "fresh", cwd: "<abs worktree path, from git rev-parse --show-toplevel>", task:
+  subagent({ agent: "worker", context: "fresh", async: false, cwd: "<abs worktree path, from git rev-parse --show-toplevel>", task:
     "Problem statement: <the problem the spec addresses + the user's stated intent>.\n" +
     "Read the spec at <abs path to doc/specs/...>. Edit ONLY that file. Apply two checks and\n" +
     "fix what you find in place: (1) Scope — does every paragraph serve the goal? Cut filler;\n" +
@@ -311,7 +317,7 @@ SUMMARY_PATH=$(mktemp "${TMPDIR:-/tmp}/gauntlet-spec-summary.XXXXXX")   # absolu
 ```
 
 ```
-subagent({ agent: "spec-summarizer", context: "fresh", cwd: "<abs worktree path, from git rev-parse --show-toplevel>",
+subagent({ agent: "spec-summarizer", context: "fresh", async: false, cwd: "<abs worktree path, from git rev-parse --show-toplevel>",
   output: "<SUMMARY_PATH>", outputMode: "file-only", task:
   "Summarize the spec at <abs path to doc/specs/...> for the user review gate. Read ONLY that file." })
 ```

package/skills/brainstorming/gatherer.md

@@ -12,12 +12,14 @@ Mint a temp dir outside the worktree (never committed):
 GATHER_DIR=$(mktemp -d)
 ```
 
-Set the substep, then dispatch one parallel-tasks `subagent` call (foreground — no
-`async:`; no `model:` — pi-cohort `agentOverrides` owns builder models):
+Set the substep, then dispatch one foreground parallel-tasks `subagent` call (`async: false`; no
+`model:` — pi-cohort `agentOverrides` owns builder models). Preserve the parallel batch and await
+its terminal result before assembling the draft:
 
 ```
 phase_tracker({ action: "substep", phase: "brainstorm", substep: "gather" })
 subagent({
+  async: false,
   tasks: [
     { agent: "scout", cwd: "<abs worktree path>", phase: "context-gather",
       output: "<GATHER_DIR>/scout.md",

package/skills/chase-bug/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: chase-bug
-description: Use when a human hands you a bug report to triage - a Slack paste, tracker ticket, GitHub issue, or described symptom - and the goal is an evidenced verdict (real bug, not-a-bug, cannot reproduce, already fixed or reported), not a fix.
+description: Use when a human hands you a bug report to triage - a Slack paste, tracker ticket, GitHub issue, or described symptom - and the goal is an evidenced verdict (real bug, not-a-bug, cannot reproduce, already fixed or reported); triage itself never fixes - a real-bug verdict may hand off to a bounded hotfix after the menu.
 disable-model-invocation: true
 ---
 
@@ -8,13 +8,16 @@ disable-model-invocation: true
 
 ## Overview
 
-Triage a bug report to an evidenced verdict, never a fix.
+Triage a bug report to an evidenced verdict. Triage never
+fixes; a real-bug verdict may hand off to a bounded hotfix (hotfix.md) after
+the menu.
 
 ## Boundaries
 
 - Reads: anything - code, history, tracker, origin text.
 - Writes: `$TMPDIR` scratch only (repro captures, notes), plus at most one gated push to the
-  origin's response channel at the very end.
+  origin's response channel at the very end; after a valid hotfix pick: the hotfix
+  worktree and one default-branch squash commit, per hotfix.md.
 - Does NOT: touch tracked files; touch tracker state (never closes, relabels, or
   reassigns an existing issue).
 - The zero-mutation invariant below mechanically enforces tracked-file immutability
@@ -25,7 +28,8 @@ Triage a bug report to an evidenced verdict, never a fix.
 
 ## Hard constraint
 
-**No verdict without evidenced root cause; no fix, ever.** (write surface: see
+**No verdict without evidenced root cause; no fix during
+triage. After a valid hotfix pick, writes follow hotfix.md.** (write surface: see
 Boundaries; enforcement: see the zero-mutation invariant below.)
 
 The invariant is baseline-relative, checked at three points. Never revert
@@ -41,17 +45,24 @@ pre-existing work - only ever revert damage this skill caused.
    rendering the summary). Re-run the same command and confirm it still matches
    the baseline.
 
+**Handoff check** (hotfix row only). Immediately before handing off to
+`hotfix.md`, run the same command on the primary checkout and require it to
+match the baseline. Checkpoint 3 still runs at skill end, on the primary
+checkout: a landed squash
+commit and a restored branch leave tracked porcelain clean, so the invariant
+holds literally on both exits.
+
 ## When to Use
 
 - A human pastes a bug report (Slack message, tracker ticket, GitHub issue, plain
   description of broken behavior) and wants to know whether it is real.
 - The ask is "is this a bug" / "can we reproduce this" / "what's causing this",
   not "fix this".
+- An evidenced, urgent "fix this" request also enters
+  here - triage stops at the menu, where the hotfix row is offered.
 
 ## When NOT to Use
 
-- The report already has an evidenced root cause and the ask is to implement a
-  fix - exit into `/skill:brainstorming` directly.
 - The item is an already-shaped ticket ready for implementation, not a report
   needing triage.
 
@@ -153,33 +164,64 @@ Render **only the matching action set** - never merge real-bug and negative-verd
 menus into one list. The human may **overrule the verdict in prose** - that is a
 change request, not a menu row.
 
-**Real bug** - three actions (all rendered unless noted), exactly one tagged
-`[recommended]`:
+**Real bug** - four actions (all rendered unless noted), exactly one tagged
+`[recommended]`. Untracked origin:
 
 ```
-1. [ ] File a ticket - one /skill:shape-ticket create-mode invocation, seeded
-       with this evidence.
+1. [ ] File a ticket - /skill:shape-ticket, seeded with this evidence.
 2. [ ] Brainstorm now - /skill:brainstorming with this evidence as the seed.
-       Handoff happens AFTER gate 2 (step 5).
+3. [ ] Implement hotfix now - follow hotfix.md; add "as a PR" for a PR.
+4. [ ] Respond to reporter only.
+```
+
+Tracker/GitHub origin (ticket row omitted as today, renumbered):
+
+```
+1. [ ] Brainstorm now - /skill:brainstorming with this evidence as the seed.
+2. [ ] Implement hotfix now - follow hotfix.md; add "as a PR" for a PR.
 3. [ ] Respond to reporter only.
 ```
 
-For unaddressable origins, action 3 reads `Finish with rendered summary`
-instead of "Respond to reporter only", and action 2's handoff happens after
-the rendered summary instead of gate 2. Exactly one rendered action still
-carries `[recommended]`.
+Unaddressable variants adjust the last row's label exactly as today. Exactly
+one `[recommended]` preserved. The eligibility line renders under the menu:
+`eligible` or `not eligible: <predicate>`, from the predicate evaluation below.
 
-If the origin is itself a tracker/GitHub ticket, it's already tracked: omit
-action 1 and renumber the remaining two as 1 (Brainstorm now) and 2 (Respond
-to reporter only). Exactly one rendered action still carries `[recommended]`.
+For unaddressable origins, the last action reads `Finish with rendered summary`
+instead of "Respond to reporter only", and the Brainstorm handoff happens after
+the rendered summary instead of gate 2.
 
-Heuristic for the `[recommended]` tag: pressing (user-facing break, data loss,
-security) or trivially fixable -> recommend brainstorm now; real but deferrable
--> recommend file a ticket; blocked on another party (needs reporter input,
-upstream fix, another team) -> recommend respond-only (rendered as "Finish with
-rendered summary" for unaddressable origins). Root cause found but the
-fix cost is unclear still stays a **real-bug** verdict - state the uncertainty
-plainly in the fault story, do not downgrade the verdict to hedge on cost.
+**Predicates and row availability.** Evaluate the six predicates in
+`hotfix.md` once, here, from the root cause - a prediction of the fix shape
+(read-only judgment). A failed safety invariant (1-3) renders the row as
+`Implement hotfix now - unavailable: <invariant>`: never pickable, never
+`[recommended]`; a pick of it is a change request. Judgment predicates (4-6)
+only steer `[recommended]` and the eligibility line.
+
+Heuristic for the `[recommended]` tag - rows top-down, first match wins:
+
+| Situation | `[recommended]` |
+|---|---|
+| Pressing or trivially fixable, all predicates pass | Hotfix now |
+| Pressing, any predicate fails | Brainstorm now |
+| Trivially fixable, any predicate fails | Brainstorm now |
+| Real but deferrable | File a ticket (tracker-origin: respond-only) |
+| Blocked on another party | Respond-only |
+
+Respond-only renders as "Finish with rendered summary" for unaddressable
+origins. Root cause found but the fix cost is unclear still stays a
+**real-bug** verdict - state the uncertainty plainly in the fault story, do
+not downgrade the verdict to hedge on cost.
+
+**Hotfix handoff.** On a hotfix pick, write the handoff record to
+`$TMPDIR/hotfix-<slug>.md`: `delivery-mode` (`squash`, or `pr` when the pick
+says "as a PR"); the evidence pack (fault story; trigger, observed, and
+expected values from Phase 1; repro command; `file:line`; falsification
+result); `slug` (kebab-case, from the symptom); origin type and response
+target (step 1); the predicate evaluation. Run the handoff check (see the
+zero-mutation invariant), then follow `hotfix.md`, which reads only this
+record. On a hotfix abort, `hotfix.md` runs its baseline re-check and this
+menu re-renders - the same gate, re-fired: with the hotfix row when the abort
+created nothing, without it otherwise.
 
 **Negative verdicts** - exactly five, each with its own named citation source:
 
@@ -236,6 +278,10 @@ any handoff:
   response citing the new ticket link -> gate 2 -> done.
 - Brainstorm now chosen -> draft the response first ("confirmed, investigating
   now - fix to follow") -> gate 2 -> **then** hand off to `/skill:brainstorming`.
+- Hotfix now chosen -> hand off to `hotfix.md` first; on completion, draft the
+  response citing `fixed in <SHA>` or the PR link -> gate 2 (`send it`) -> done.
+  Gate 2 fires once. On abort, `hotfix.md` returns to the step-4 menu; step 5
+  then runs for the new pick, the draft citing the abort reason.
 - Respond-only, or any negative verdict -> draft -> gate 2 -> done.
 
 **Draft template:**
@@ -298,6 +344,9 @@ action renders the verdict as a **summary to the human**, then the skill ends
   link.
 - Brainstorm now chosen -> render the summary -> **then** hand off to
   `/skill:brainstorming`.
+- Hotfix now chosen -> hand off to `hotfix.md`; on completion render the
+  summary citing `fixed in <SHA>` or the PR link -> done. On abort, return to
+  the step-4 menu.
 - Finish with rendered summary chosen -> render the summary -> done.
 
 **Summary template** (same four fields as the draft - the difference is
@@ -319,7 +368,7 @@ rendered is out of skill scope - the skill has ended.
 
 | Verdict | Citation source | Response next-step |
 |---|---|---|
-| Real bug | Falsification test run + passed | Ticket link, fix branch, or ack |
+| Real bug | Falsification test run + passed | Ticket link, squash SHA, fix branch, or ack |
 | `not-a-bug` | Contract satisfied (spec/schema/API doc) | Explain the contract |
 | `intended-behavior` | Decision record (design doc/ADR/commit) | Point to the decision |
 | `cannot-replicate` | Phase 1 repro attempts, missing input named | Ask reporter for missing input; offer discovery ticket |
@@ -337,11 +386,14 @@ falls through to the 404 handler.
 Proof: `curl /widgets/` -> 404 | src/router.ts:88 | expected match, got none
 
 1. [ ] File a ticket - /skill:shape-ticket, seeded with the above.
-2. [x] Brainstorm now - user-facing 404 on a common URL shape. [recommended]
-3. [ ] Respond to reporter only.
+2. [ ] Brainstorm now - /skill:brainstorming with the above as the seed.
+3. [x] Implement hotfix now - follow hotfix.md; add "as a PR" for a PR. [recommended]
+4. [ ] Respond to reporter only.
+
+eligible - all predicates pass
 ```
 
-(The example assumes an addressable origin - action 3's label is the addressable one.)
+(The example assumes an addressable origin - action 4's label is the addressable one.)
 
 **Negative-verdict example** (citation-source contrast):
 
@@ -361,7 +413,7 @@ nested resources" (the decision that made it so).
 
 | Excuse | Reality |
 |---|---|
-| "Trivial fix, faster to just do it" | Fixing during triage is the one thing this skill forbids - hand it to the human at the menu, always |
+| "Trivial fix, faster to just do it" | Fixing during triage is forbidden - the hotfix row after the menu is the sanctioned path |
 | "Root cause is obvious, skip falsification" | Obvious and evidenced are different things - run the test or report it blocked |
 | "Reporter is waiting, skip the gate" | The gate is what makes the response trustworthy - urgency is not a bypass |
 | "I already know there's no prior report" | A guess isn't a search - use the ladder or declare it unreachable |

package/skills/chase-bug/hotfix.md

@@ -0,0 +1,198 @@
+# Hotfix (chase-bug supplementary)
+
+Consumed only by `SKILL.md` in this directory, at the real-bug menu handoff. Input:
+the handoff record at `$TMPDIR/hotfix-<slug>.md` - read nothing else about the bug.
+Automatic end to end: the menu pick was the consent. The only human gate left is
+chase-bug's `send it`, reached in step 10 below.
+
+## Boundaries
+
+- Reads: anything.
+- Writes: the hotfix worktree; exactly one squash commit on `<default>`, made in the
+  primary checkout with a clean index, `<orig-branch>` restored after; `$TMPDIR`.
+- Does NOT: run tests or create files in the primary checkout; push without an
+  explicit request; touch tracker state; commit on the source checkout during setup;
+  touch pre-existing dirt or any resource this run did not create.
+
+## Ownership
+
+Two flags, `created-worktree` and `created-branch`, set only when `git worktree add`
+succeeds (it creates both). Every destructive command below is gated on its flag.
+
+## Procedure
+
+1. **Read the record; print the eligibility line.** Reprint the menu-time
+   evaluation verbatim: `eligible` or `not eligible: <predicate>`. Never
+   re-derive, never block.
+2. **Resolve before mutating.** `SCOPED_TEST_COMMANDS`: the gauntlet overrides
+   file's verification section (`## verification-before-completion`, or a section
+   matching the verification topic), else `AGENTS.md` or the project's documented
+   test command. The full project test target is acceptable. Add the record's repro
+   command when present. No exact command -> abort (pre-land). Draft the implementer
+   task text from the record; not writable -> abort (pre-land). Nothing exists yet.
+3. **Worktree.** From the primary checkout:
+
+   ```bash
+   PRIMARY_ROOT=$(git rev-parse --show-toplevel)
+   DEFAULT=$(git symbolic-ref --short refs/remotes/origin/HEAD) && DEFAULT=${DEFAULT#origin/}
+   BASE_SHA=$(git rev-parse "$DEFAULT")
+   ORIG_BRANCH=$(git branch --show-current)
+   git status --porcelain > "$TMPDIR/hotfix-<slug>.baseline"
+   ```
+
+   Abort (pre-land, nothing created) when: `git rev-parse --git-dir` differs from
+   `git rev-parse --git-common-dir` (inside a linked worktree); `DEFAULT` empty
+   (never guess a squash target); `ORIG_BRANCH` empty (detached HEAD); `git status
+   --porcelain --untracked-files=no` non-empty; `git check-ignore -q .worktrees/`
+   fails (never commit on the source checkout); `git show-ref --verify -q
+   refs/heads/hotfix/<slug>` succeeds or `.worktrees/hotfix/<slug>` exists (never
+   reuse, never force); `git worktree add` itself failing (creation failure).
+
+   ```bash
+   git worktree add ".worktrees/hotfix/<slug>" -b "hotfix/<slug>" "$DEFAULT"
+   ```
+
+   Success sets both flags. Run the project's dependency install inside the
+   worktree. Every dispatch below: `cwd` = the worktree path, the record path in the
+   task text, `output:` (when used) an absolute `$TMPDIR` path.
+4. **Implement.** One `implementer`, fork context:
+
+   > Read `$TMPDIR/hotfix-<slug>.md`; the evidence pack is also inlined here:
+   > <evidence pack>. The evidence pack replaces plan and spec; do
+   > not report BLOCKED for a missing plan. TDD: write the regression test, run it,
+   > confirm it fails, then the minimal fix (dependency-bump fallback: the repro
+   > re-run is the regression evidence). SCOPED_TEST_COMMANDS: <commands>. Commit on
+   > `hotfix/<slug>` before reporting. End with the SDD status line verbatim.
+
+   `DONE` -> step 5. `DONE_WITH_CONCERNS` -> step 5 unless a concern names a safety
+   invariant -> abort. `NEEDS_CONTEXT` or `BLOCKED` -> abort. A regression command
+   named in the report joins `SCOPED_TEST_COMMANDS` only if it uses the resolved
+   command's runner.
+5. **Test.** Run `SCOPED_TEST_COMMANDS` in the worktree. Red -> one implementer
+   retry -> red -> abort.
+6. **Verify (advisory).** One fresh `conformance-reviewer`. Its entire origin, in
+   the task text, located as `prompt`:
+
+   > R1: the trigger `<trigger>` now yields `<expected>` (was `<observed>`).
+   > R2: regression evidence exists (test or repro re-run).
+   > R3: the diff stays inside the envelope: files implementing the mechanism at
+   > the recorded `file:line`, the regression test, and (dependency exception)
+   > manifest + lockfile.
+
+   Parent filter: only rows located as `prompt` count; a row sourced from a spec
+   file or ticket is not-a-gap. Real gaps -> one implementer round -> re-run step
+   5 -> no second audit; unfixable -> abort. Dispatch failure or malformed output
+   -> note it, continue.
+7. **Review - last mutation gate.** One fresh `code-reviewer` over
+   `<base-sha>..HEAD` in the worktree. Task text: the record path,
+   `SCOPED_TEST_COMMANDS`, invariants 1-3 and predicates 4-6 as named review items
+   (a predicate miss is Moderate unless it trips an invariant). `SHIP` -> step 8.
+   `FIX_FIRST` -> one implementer round fixing every Critical and Moderate ->
+   re-run step 5 -> one re-review; `SHIP` -> step 8, else abort. `REJECT` or any
+   invariant violation -> abort, no round. Dispatch failure or malformed output ->
+   one redispatch, then abort.
+8. **Finish.** Branch on the record's `delivery-mode`: `squash` -> squash path;
+   `pr` -> PR path. Every command from `PRIMARY_ROOT`. Squash path, by state:
+
+   ```bash
+   cd "$PRIMARY_ROOT"
+   [ -z "$(git status --porcelain --untracked-files=no)" ] || land_abort
+   [ "$(git rev-parse "$DEFAULT")" = "$BASE_SHA" ] || land_abort   # base moved: never touch <default>
+   git checkout "$DEFAULT" || land_abort                            # pre-squash ends here
+   git merge --squash "hotfix/<slug>" || { git reset --hard "$BASE_SHA"; land_abort; }
+   git diff --cached --quiet && { git reset --hard "$BASE_SHA"; land_abort; }   # empty squash
+   git commit -m "fix: <slug>" -m "<fault story>" || { git reset --hard "$BASE_SHA"; land_abort; }
+   [ "$(git rev-parse HEAD^{tree})" = "$(git rev-parse "hotfix/<slug>^{tree}")" ] \
+     || { git reset --hard "$BASE_SHA"; land_abort; }              # proven; never reset after this line
+   SHA=$(git rev-parse HEAD)
+   [ "$ORIG_BRANCH" = "$DEFAULT" ] || git checkout "$ORIG_BRANCH"  # failure: report, commit stays
+   git worktree remove --force ".worktrees/hotfix/<slug>" && git worktree prune \
+     && git branch -D "hotfix/<slug>"                               # failure: keep commit, report residual
+   ```
+
+   `git branch -D` is forced by construction: a squash commit never has the branch
+   tip as ancestor, so `-d` always refuses; the proven tree is the loss guard. The
+   commit stays **unpushed**. Report: `$SHA`; revert line `git checkout <default>
+   && git reset --hard <base-sha>` (unpushed) or `git revert <sha>` (after any
+   push); `git status --porcelain` diff against the baseline (expected none); a
+   push nudge.
+
+   PR path, cwd = the worktree: `git push -u origin hotfix/<slug>` - failure ->
+   report branch + worktree path, no URL, preserve. `gh pr create --base <default>
+   --head hotfix/<slug>` - `gh` missing or failing after one retry -> report the
+   pushed branch and compare URL. Worktree and branch preserved; print the closing
+   line.
+9. **Cleanup evidence.** Squash exit and pre-land aborts: `git worktree list`
+   without the hotfix entry; `git branch --list hotfix/<slug>` empty; porcelain
+   delta vs baseline none. PR exit and land-stage aborts: both present, plus
+   `git worktree remove --force .worktrees/hotfix/<slug> && git branch -D hotfix/<slug>`.
+10. **Response.** chase-bug step 5 rules apply unchanged: addressable -> draft
+    citing `fixed in <SHA>` or the PR link -> `send it`; unaddressable -> summary.
+    Abort never reaches this step - it returns to the menu.
+
+## Eligibility predicates
+
+Evaluated once by `SKILL.md` at menu time from the root cause; re-checked against
+the diff in step 7.
+
+Safety invariants (row availability):
+
+1. No schema, migration, or persistence change.
+2. No public API, contract, or config-shape change.
+3. Rollback is reverting one commit - no data or state side effects.
+
+Judgment predicates (`[recommended]` only; Moderate review items):
+
+4. Existing code only - new files limited to the regression test.
+5. Dependencies unchanged, one exception: a patch/minor bump whose upstream issue or
+   changelog names the symptom, diff = manifest + lockfile, no call-site change.
+   Replacement, major/breaking upgrade, new dependency -> fails.
+6. Regression evidence writable in the existing harness (bump fallback: the repro).
+
+## Abort
+
+Both classes end with the baseline re-check, then chase-bug step 4 re-renders.
+
+**Pre-land** (steps 2-7): unresolvable commands or task text; setup precondition
+unmet; `NEEDS_CONTEXT`/`BLOCKED` or a concern naming an invariant; red after retry;
+unfixable conformance gap; review `REJECT`, invariant violation, or a non-`SHIP`
+re-review.
+
+```bash
+[ "$created_worktree" = 1 ] && git worktree remove --force ".worktrees/hotfix/<slug>"
+git worktree prune
+[ "$created_branch" = 1 ] && git branch -D "hotfix/<slug>"
+```
+
+Nothing else is touched. The re-rendered menu keeps the hotfix row when neither
+flag was set, omits it otherwise.
+
+**Land-stage** (step 8 before *proven*, after review `SHIP`): base moved, checkout failure, empty
+squash, merge/commit failure, tree mismatch. `git reset --hard <base-sha>` only when
+this run moved `<default>` (squash-applied or later) and `<default>` is checked
+out (the step 8 lines do
+exactly that); on base moved `<default>` is never touched and both SHAs are
+reported. Restore `<orig-branch>`. Preserve worktree and branch (reviewed work).
+Report path, tip SHA, closing line. The menu re-renders without the hotfix row.
+
+**Baseline re-check**: `git status --porcelain --untracked-files=no` matches the
+triage baseline; full porcelain delta reported; `<default>` == `<base-sha>` asserted
+only when this run touched `<default>`. Pre-existing dirt is never touched.
+
+## Harness fallback
+
+No `subagent` tool and no personas (the Claude Code marketplace ships `agents: []`):
+run the duties inline, same order. Write the failing regression test, confirm red,
+minimal fix, confirm green, commit on `hotfix/<slug>`. Self-review the diff against
+the record, invariants 1-3, predicates 4-6. Run `SCOPED_TEST_COMMANDS`. Apply the
+abort classes as written. Finish and report per steps 8-9.
+
+## Red Flags - STOP
+
+- Any mutation before every step 3 precondition passes
+- Reusing or force-replacing an existing `hotfix/<slug>` branch or path
+- `git reset --hard` after *proven*, on `<orig-branch>`, or inside the worktree
+- Re-running tests in the primary checkout
+- Merging onto a moved base
+- Landing a diff the last review did not see
+- Pushing without an explicit request

package/skills/dispatching-parallel-agents/SKILL.md

@@ -15,6 +15,8 @@ When you have multiple **independent tasks** — unrelated test failures, or imp
 
 This skill is the **mechanic home** for parallel fan-out: fresh-context isolation, `worktree: true` filesystem isolation, and serial patch integration. `subagent-driven-development`'s Parallel-Wave Mode builds its per-wave dispatch on this skill — debugging is the worked example below, but the mechanics are identical for implementation tasks.
 
+Gauntlet flow callers dispatch foreground: explicitly set top-level `async: false`, including retries and prose-described dispatches. `forceTopLevelAsync` is incompatible; if an async handle is returned anyway, stop and report rather than polling or relaunching. See [pi-cohort dispatch configuration](https://github.com/jjuraszek/pi-cohort/blob/main/doc/configuration.md).
+
 **Why parallel subagents:** each agent gets a fresh context window with only its problem domain. No cross-contamination between investigations, smaller diffs, faster wall-clock time. You stay the orchestrator — you read the summaries, resolve any file overlap, and run the integrated tests.
 
 **Fresh context is not the default.** Some packaged subagents (including `worker`) fork the parent context unless you opt out. Always pass `context: "fresh"` on every task entry — if it's missing, you're getting forked agents and losing the isolation that makes parallel dispatch worth doing in the first place.
@@ -78,6 +80,7 @@ Use the `subagent` tool in parallel mode, with explicit fresh context per task:
 ```ts
 subagent({
   context: "fresh",
+  async: false,
   tasks: [
     { agent: "worker", task: "Fix agent-tool-abort.test.ts failures" },
     { agent: "worker", task: "Fix batch-completion-behavior.test.ts failures" },
@@ -123,7 +126,7 @@ Grammar (identical across producers, modulo id prefix — `F` for code/spec revi
 
 **After the fix wave:** integrate patches serially per "Review and Integrate" above (mis-partition is self-healing: integrate the successes, re-run the conflicting finding sequentially on integrated HEAD); run the consuming loop's scoped test gate on the integrated tree; then one re-review of the integrated fix delta, per the consuming loop's own rules. The fan-out counts as one fix round against the consuming loop's budget — it grants no extra rounds.
 
-**Progress:** `plan_tracker({ action: "add" })` one task per fixed finding, named mechanically — `"<prefix>fix F<n>: <finding's first line verbatim>"`, where `<prefix>` is `"W<k>-"` inside an execution wave and empty elsewhere. Fix tasks always extend the tracker, never re-init. Mark `in_progress` at dispatch, `complete` at integration.
+**Progress:** In a gauntlet flow, fix work reuses the consuming task/wave index (or durable `Gn:` gap index) and preserves it through retries, fan-out, tests, and re-review; do not append a fix task or replace an active flow list. Mark the existing index `in_progress` before dispatch and `complete` only after its consuming acceptance point. For standalone non-flow consumers with no owning task, preserve the generic append behavior: `plan_tracker({ action: "add" })` one task per fixed finding, named mechanically — `"<prefix>fix F<n>: <finding's first line verbatim>"`; mark it `in_progress` at dispatch and `complete` at integration.
 
 ## Agent Prompt Structure
 
@@ -192,6 +195,7 @@ REPORT_DIR=$(mktemp -d)
 ```ts
 subagent({
   context: "fresh",
+  async: false,
   worktree: true,        // isolate edits; omit for read-only investigations
   concurrency: 3,
   tasks: [

package/skills/requesting-code-review/SKILL.md

@@ -37,10 +37,10 @@ Fill the template at `code-reviewer.md` in this skill directory, then dispatch a
 
 **How to dispatch:**
 
-Use the `subagent` tool with the code-reviewer template filled in:
+Use the `subagent` tool with the code-reviewer template filled in. This foreground dispatch must return a terminal result before acting on review feedback:
 
 ```ts
-subagent({ agent: "code-reviewer", task: "... filled template ..." })
+subagent({ agent: "code-reviewer", async: false, task: "... filled template ..." })
 ```
 
 **Placeholders:**
@@ -57,7 +57,7 @@ subagent({ agent: "code-reviewer", task: "... filled template ..." })
 - Note Minor issues for later
 - Push back if reviewer is wrong (with reasoning)
 
-**Fix rounds.** Critical and Moderate findings trigger a fix round; when dispatched from an orchestrating skill, fixes go to `implementer` subagents (per the orchestrator's no-self-coding rule), fanned out per `dispatching-parallel-agents` "Fix fan-out" when the review's `Parallel-safe:` line certifies a `disjoint` group of ≥ 2 findings. Before fanning out, validate the review's `Parallel-safe:` line with the structural probe in `dispatching-parallel-agents` § Fix fan-out (exactly-one-line grammar check, one re-ask, then explicit sequential fallback). After integration and the project's test command, re-dispatch the reviewer once on the integrated delta. If Critical or Moderate findings remain, run one more fix round and one more re-review; still failing → escalate to the user. Minor findings never trigger the fan-out.
+**Fix rounds.** Critical and Moderate findings trigger a fix round; when dispatched from an orchestrating skill, fixes go to `implementer` subagents (per the orchestrator's no-self-coding rule), fanned out per `dispatching-parallel-agents` "Fix fan-out" when the review's `Parallel-safe:` line certifies a `disjoint` group of ≥ 2 findings. Before fanning out, validate the review's `Parallel-safe:` line with the structural probe in `dispatching-parallel-agents` § Fix fan-out (exactly-one-line grammar check, one re-ask, then explicit sequential fallback). After integration and the project's test command, re-dispatch the reviewer once on the integrated delta in the foreground with top-level `async: false`; await its terminal result. If Critical or Moderate findings remain, run one more fix round and one more foreground re-review; still failing → escalate to the user. Minor findings never trigger the fan-out.
 
 ## Example
 

package/skills/roasting-the-spec/SKILL.md

@@ -58,6 +58,7 @@ Capture the worktree path once (`git rev-parse --show-toplevel`, run from inside
 
 ```
 subagent({
+  async: false,
   control: { needsAttentionAfterMs: 300000, inFlightSilenceCeilingMs: 300000, inFlightSilenceKillMs: 600000 },
   tasks: members.map((model, i) => ({
     agent: "spec-council-member",
@@ -76,7 +77,7 @@ subagent({
 
 **Usable-critique test (mechanical structural probe).** After the fanout returns - success or failure of the tool call itself - probe the expected output paths on disk; judge by files, not by the tool result's failed/succeeded labels (a killed member may have written a usable critique first). A member file is usable iff it is non-empty AND contains both a `^verdict:\s*(sound|needs-work|unsound)` line and an `^addresses-problem:` line. A `findings:` header with zero bullets is a valid, usable sound critique. Existence plus header regex only - never read or weigh findings content.
 
-**Targeted retry.** Members whose file is missing or not usable are re-dispatched **once**, together, in a second parallel call carrying the same `control` block, with fresh output paths that preserve the `member-<i>-<slug>` basename under a `retry/` subdir of the same temp dir (the chair recovers `raised-by` attribution from that filename pattern). Members with usable files are never re-run.
+**Targeted retry.** Members whose file is missing or not usable are re-dispatched **once**, together, in a second foreground parallel call carrying `async: false` and the same `control` block, with fresh output paths that preserve the `member-<i>-<slug>` basename under a `retry/` subdir of the same temp dir (the chair recovers `raised-by` attribution from that filename pattern). Await its terminal result. Members with usable files are never re-run.
 
 **Quorum.** At least one usable file after retry -> dispatch the chair over the usable files only (next section). Zero usable files -> abort the council, say so, and return to the user gate.
 
@@ -87,6 +88,7 @@ Dispatch the chair once. It reads the member files (not you), the spec, and the
 ```
 subagent({
   agent: "spec-council-synthesizer",
+  async: false,
   model: <chair from config, else omit to inherit>,
   cwd: "<abs worktree path>",
   control: { needsAttentionAfterMs: 300000, inFlightSilenceCeilingMs: 600000, inFlightSilenceKillMs: 900000 },
@@ -99,11 +101,11 @@ subagent({
 })
 ```
 
-The chair runs one long single-turn synthesis; the control block sets an effective silence-kill of max(900s, 600+300) = 900s. Margin rationale: one observed healthy chair turn ran 506s of silence, so a 600s kill would leave under 2 minutes of margin - the chair gets 900s. In the coverage line, use pi-cohort's kill diagnostic as the reason when present (e.g. "Likely wedged in a tool call"), else "no output produced"; omit per-member reasons at full coverage. With one usable member, use singular wording ("synthesize the single member critique").
+The chair runs one long foreground single-turn synthesis; await its terminal result before applying findings. The control block sets an effective silence-kill of max(900s, 600+300) = 900s. Margin rationale: one observed healthy chair turn ran 506s of silence, so a 600s kill would leave under 2 minutes of margin - the chair gets 900s. In the coverage line, use pi-cohort's kill diagnostic as the reason when present (e.g. "Likely wedged in a tool call"), else "no output produced"; omit per-member reasons at full coverage. With one usable member, use singular wording ("synthesize the single member critique").
 
 List the exact member paths in the task text. The `reads:` array injects their contents, but the chair's prompt expects the paths explicitly; without them it scans the tree for `*.md` and stalls.
 
-A chair synthesis is usable iff it contains a `^consensus:` line. If the configured `chair` model is unreachable, retry once with the inherited model; a wedge-killed or unusable chair retries once with the same model. Second failure -> abort the council, say so, and return to the user gate.
+A chair synthesis is usable iff it contains a `^consensus:` line. If the configured `chair` model is unreachable, retry once with the inherited model; a wedge-killed or unusable chair retries once with the same model. Each retry remains foreground with top-level `async: false` and is awaited to a terminal result. Second failure -> abort the council, say so, and return to the user gate.
 
 ### 3 — Decide and apply
 

package/skills/subagent-driven-development/SKILL.md

@@ -13,6 +13,8 @@ Execute a plan by dispatching a **fresh subagent per task**, with two-stage revi
 
 If a tool result contains a ⚠️ workflow warning, stop immediately and address it before continuing.
 
+Gauntlet execution dispatches are foreground: set top-level `async: false` on every implementation, review, conformance, retry, and prose-described dispatch. Preserve parallel `tasks` batches and chain groups. `forceTopLevelAsync` is incompatible; an unexpected async handle means stop and report, never poll or relaunch. See [pi-cohort dispatch configuration](https://github.com/jjuraszek/pi-cohort/blob/main/doc/configuration.md).
+
 ## Why Subagents
 
 Your context window holds the full plan, prior decisions, and conversation history. Each subagent gets a fresh window with only the current task's text and context.
@@ -39,7 +41,7 @@ Periodic "should I continue?" prompts add latency without adding safety. The pla
 
 - Running inside a dedicated worktree (the same one the spec and plan were authored in). If you're on `main` in the primary checkout, stop and invoke `/skill:using-git-worktrees` first — implementation never lands directly on `main`.
 - Approved plan or clear task scope
-- `plan_tracker` initialized with the full task list
+- `plan_tracker` list initialized at writing-plans handoff with the full wave-ordered task list. Consume and preserve it on continuation; only direct recovery with no tracker initializes the full plan list once, before dispatch, and never over an existing list.
 
 ## Sequential vs. Parallel-Wave
 
@@ -53,17 +55,17 @@ Before the first task, enter the implement phase: `phase_tracker({ action: "star
 
 For each task in `plan_tracker`:
 
-1. **Dispatch implementer.** Pass the full task text + scene-setting context + the task's plan-declared test commands as `SCOPED_TEST_COMMANDS` (or `none`). Don't make the subagent re-read the plan.
+1. **Start, then dispatch implementer.** Mark the task's existing `plan_tracker` index `in_progress` before dispatch. Pass the full task text + scene-setting context + the task's plan-declared test commands as `SCOPED_TEST_COMMANDS` (or `none`). Don't make the subagent re-read the plan.
 2. **Handle implementer status** (see below).
 3. **Dispatch spec reviewer.** Pass the task text, the patch diff, the absolute spec path, and the task's `**Spec:**` anchors — SR reads the anchored ranges from the spec file itself; never inline spec excerpts. The spec wins every dispute; the authority hierarchy and finding labels live in `./spec-reviewer-prompt.md`. Anchor-less tasks (no `**Spec:**` line): task text alone is the contract. Verify the change satisfies the anchored spec — nothing missing, nothing extra.
 4. If spec reviewer finds gaps → re-dispatch implementer to fix → re-review. Loop until ✅, within [Fix-Loop Rounds](#fix-loop-rounds).
 5. **Dispatch code-quality reviewer.** Only after spec is ✅. Skip for doc-only tasks (every file in the task's `Files:` block documentation-only) — SR-only, same exemption as doc-only waves. Pass `SCOPED_TEST_COMMANDS` = the task's plan-declared commands.
 6. If quality reviewer finds issues → re-dispatch implementer → re-review. Loop until ✅, within [Fix-Loop Rounds](#fix-loop-rounds).
-7. Mark task complete in `plan_tracker`.
+7. After its existing reviews accept the work (and its required commit point), mark that same task index `complete` in `plan_tracker`. A subagent exit or green tests alone are not acceptance.
 
 The spec is frozen at plan time and the orchestrator is its only writer during execution; if you do edit it mid-run, re-run writing-plans' anchor-resolution check before the next wave. An SR unable to read the spec at a cited anchor (missing file, unresolvable heading/range) returns a blocking finding — the contract is spec+task or stop, never a silent fallback to task-only review.
 
-After all tasks: proceed to [After All Tasks](#after-all-tasks-complete) - it owns the whole-diff code review dispatch and the full verification run (concurrent when the verification set classifies safe).
+After all tasks: proceed to [After All Tasks](#after-all-tasks-complete) - it owns parent full verification, then whole-diff code review, then conformance.
 
 ## Fix-Loop Rounds
 
@@ -121,6 +123,7 @@ Pi-subagents accepts a per-task `model` override. Use it.
 ```ts
 subagent({
   agent: "implementer",
+  async: false,
   task: "...",
   model: "anthropic/claude-haiku-4"   // cheap tier
 })
@@ -132,18 +135,18 @@ When in doubt, default. Don't downgrade reviewers — false negatives are expens
 
 ```ts
 // implementer
-subagent({ agent: "implementer", task: "<task text + context + SCOPED_TEST_COMMANDS + status protocol>" })
+subagent({ agent: "implementer", async: false, task: "<task text + context + SCOPED_TEST_COMMANDS + status protocol>" })
 
 // spec compliance
-subagent({ agent: "spec-reviewer", task: "<task text + patch diff + absolute spec path + task's Spec: anchors>" })
+subagent({ agent: "spec-reviewer", async: false, task: "<task text + patch diff + absolute spec path + task's Spec: anchors>" })
 
 // code quality
-subagent({ agent: "code-reviewer", task: "<diff range + SCOPED_TEST_COMMANDS (task commands; wave: union; whole-diff: none) + ask: production-ready?>" })
+subagent({ agent: "code-reviewer", async: false, task: "<diff range + SCOPED_TEST_COMMANDS (task commands; wave: union; whole-diff: none) + ask: production-ready?>" })
 
 // closing-loop conformance (origin vs deliverable) — its OWN dispatch, never fused with code quality
 // model: call gauntlet_setting({ key: "closureReview" }) first; use the returned model (omit model: if undefined to inherit) and maxFixRounds
 // If gauntlet_setting is unavailable, stop and report - never fall back to a manual bash/JSON settings merge.
-subagent({ agent: "conformance-reviewer", model: /* gauntlet_setting({ key: "closureReview" }).model, else omit to inherit */, task: "<spec path + verbatim original prompt + full diff vs main; per conformance-check.md>" })
+subagent({ agent: "conformance-reviewer", async: false, model: /* gauntlet_setting({ key: "closureReview" }).model, else omit to inherit */, task: "<spec path + verbatim original prompt + full diff vs main; per conformance-check.md>" })
 ```
 
 Prompt templates live alongside this SKILL.md:
@@ -160,22 +163,22 @@ Auto-selected at handoff by `writing-plans` (any wave with ≥2 tasks) when the
 
 **Progress tracking (`plan_tracker`).** `plan_tracker` is a flat list with no native group concept, so waves are *encoded*, not modeled:
 
-- **Init once, wave-ordered:** `init` with every task across all waves in wave order, each name prefixed with its wave (`"W1: <title>"`, `"W2: <title>"`, …). Indices are positional and stable; never re-init mid-run (it drops statuses).
-- **Wave fan-out → `in_progress`:** mark every task index in the wave `in_progress`. Multiple simultaneous `in_progress` entries is expected (sequential mode has one).
-- **Wave commit → `complete`:** after the wave's gate passes and it commits, mark all that wave's indices `complete`. `complete` = durably committed, so a task in conflict-fallback stays `in_progress` until its wave commits.
+- **Consume, preserve, recover only if absent:** consume the wave-ordered list initialized at writing-plans handoff; indices are positional and stable, so never re-init on continuation or mid-run. Only direct recovery with no tracker initializes the full plan list once before dispatch.
+- **Wave fan-out → `in_progress`:** unconditionally mark every task index in the wave `in_progress` before dispatch. Multiple simultaneous entries are expected (sequential mode has one).
+- **Wave commit → `complete`:** after the wave's gate passes and it commits, unconditionally mark all those same indices `complete`. `complete` = durably committed, so a task in conflict fallback stays `in_progress` until its wave commits.
 - **Lifecycle per task:** `pending → in_progress (wave fan-out) → complete (wave commit)`.
 - **Widget caveat (known, deliberately unfixed).** The persistent `plan_tracker` widget's icon strip (`○ → ✓`) and `(c/total)` count reflect every task, but its trailing *name* shows only the **first** `in_progress` task. In parallel mode the icon strip and the `status` action are the full in-flight view; a richer multi-task widget is a separate extension change, out of scope (YAGNI).
-- **Sequential mode is unchanged:** init the full list, one `in_progress` at a time; wave prefixes are harmless if present.
+- **Sequential mode:** consume the same existing full list, one `in_progress` index at a time; wave prefixes are harmless.
 
 **Per-wave loop:**
 
 1. **Independence check.** Parse the wave's tasks' `Files:` blocks; assert pairwise-disjoint (mechanical). Runtime-resource disjointness (DB/schema, port, fixture, external service, shared temp path) is not machine-checkable here — trust the plan's wave grouping, which `writing-plans`' D5 contract guarantees. Either kind of overlap → the wave is mis-grouped; run those tasks as sequential single-task waves and note it.
-2. **Fan out.** One parallel dispatch (shape below): `implementer` per task, `context: "fresh"`, `worktree: true`. Each returns a status + a patch.
+2. **Start, then fan out.** Mark every wave index `in_progress` before one parallel foreground dispatch (shape below): `implementer` per task, `context: "fresh"`, `worktree: true`. Each returns a status + a patch.
 3. **Status + spec review per task.** Parse each `DONE`/`BLOCKED`/etc. (see [Implementer Status](#implementer-status)) **first**. Then **dispatch a `spec-reviewer` per accepted patch** (`DONE`, or a `DONE_WITH_CONCERNS` you proceeded with) in one parallel fan-out — `context: "fresh"`, `cwd: <this worktree>`, **no `worktree` flag** (read-only) — each passed its task text, the returned **patch diff**, the absolute spec path, and the task's `**Spec:**` anchors — SR reads the anchored ranges itself (never inline excerpts; authority hierarchy in `./spec-reviewer-prompt.md`; anchor-less tasks are task-text-only). Review starts from the diff (its hunks carry `file:line`) and reads each touched file in full, and test execution is never the reviewer's job - in either mode (persona rule; the wave test gate in step 5 runs the wave's declared test commands). Inline verdicts are fine at normal wave sizes; large waves use `output:` + `outputMode: "file-only"` to keep verdicts out of your context. **Re-dispatch by cause:** `BLOCKED`/`NEEDS_CONTEXT` per the [Implementer Status](#implementer-status) matrix; a **spec gap** re-dispatches the implementer (fresh, `worktree: true`) carrying the prior patch + the reviewer's findings, the new patch superseding the old at step 4. Loop until accepted + spec ✅, within [Fix-Loop Rounds](#fix-loop-rounds), same as sequential.
 4. **Integrate.** `git apply` each task's patch sequentially onto HEAD. Apply fails = textual conflict → drop that task, finish the rest, re-run the dropped task sequentially on the updated HEAD.
 5. **Test gate.** Run the union of the wave's tasks' declared test commands on the integrated tree — the full verification set is the verify phase's job, run once. Failure = semantic conflict or bug → re-run the offending task sequentially, else fix per [When a Subagent Fails](#when-a-subagent-fails).
 6. **Quality review.** CR binds to the wave: exactly one **initial** code-review dispatch per code-touching wave, over the integrated wave diff - never per task within a wave, never batched across waves. Subsequent dispatches within the wave are re-reviews triggered only by findings, per Fix-Loop Rounds. Pass `SCOPED_TEST_COMMANDS` = the union of the wave's tasks' declared commands. Code-quality review on the integrated wave diff; loop fixes to ✅ within [Fix-Loop Rounds](#fix-loop-rounds), same as sequential. Skip for doc-only waves (SR-only per the commit precondition below).
-7. **Commit the wave.** Leaves a clean tree; the next wave's children branch from this commit and so see the integrated work.
+7. **Commit and complete the wave.** After the gate passes and the wave commits, mark all of its existing indices `complete`. Leaves a clean tree; the next wave's children branch from this commit and so see the integrated work.
 
 **Two-stage review is preserved:** spec review per task (pre-integration, dispatched `spec-reviewer` — not inline), quality review per wave (post-integration). A wave commit requires one spec-review verdict per accepted task, plus one code-review verdict on the integrated diff for waves that touch code. A doc-only wave (every task's `Files:` block documentation-only, per `writing-plans`' Wave Grouping) is SR-only — the CR gate does not apply.
 
@@ -192,6 +195,7 @@ REPORT_DIR=$(mktemp -d)
 ```ts
 subagent({
   context: "fresh",
+  async: false,
   cwd: "/abs/path/to/this/worktree",  // REQUIRED: the worktree you're in, else children branch from main
   worktree: true,        // each task in its own git worktree, branched from cwd's HEAD
   concurrency: 4,        // default; cap = wave size
@@ -223,11 +227,9 @@ For the fan-out + worktree + patch-integration + conflict mechanics, see `dispat
 ## After All Tasks Complete
 
 0. Call `phase_tracker({ action: "start", phase: "verify" })`. (The `implement` phase was started at execution start and auto-completes from `plan_tracker` once all tasks are done; this flow runs its own verify gate instead of `/skill:verification-before-completion`, so it must mark verify itself.)
-1. **Classify, then dispatch both audits.** Classify the plan header's `**Verification:**` commands once per verify entry (post-fix re-runs are serial by nature — no re-classification): **unsafe** = anything that can rewrite tracked files — write-mode formatters (`--write`, `-w`), autofixers (`--fix`, `-u` snapshot updates), codegen, migrations regenerating checked-in artifacts; **safe** = commands that write only untracked/ignored paths — test runners, check-mode linters/formatters (`--check`, `--diff`), type checkers, builds only when their outputs are untracked; wrappers (`script/verify`, `package.json` aliases, `Makefile` targets) — read one level in, safe iff every invoked command classifies safe; deeper nesting or an undeterminable write destination → unsafe. The rule is the write destination; examples are illustrative, not authoritative. Unclear → serial. Orchestrator judgment, not config — no settings key, never a prompt.
-   - **Safe → concurrent (default).** Dispatch the whole-diff review per `/skill:requesting-code-review` against the worktree's full diff vs `main`, passing `SCOPED_TEST_COMMANDS: none` (the full run below is the orchestrator's): `subagent({ agent: "code-reviewer", context: "fresh", async: true, cwd: <worktree>, output: <absolute non-colliding $TMPDIR path>, task: <review template> })` — capture the returned run id; never a relative `output:` path (it lands untracked in the worktree). In the same turn, run the full `**Verification:**` set foreground in your own bash: tests + style + format (a single bundling entrypoint, or the listed individual commands). This is the only full run before conformance — task and wave gates ran scoped commands only.
-   - **Unsafe/unclear → serial.** Same two audits, review first (a plain synchronous dispatch), then the verification set, with one declarative notice naming the offender — e.g. `Serial review->verify: 'npm run fmt' writes tracked files.` Only the start order changes; step 2's join invariant is identical.
-2. **Join, then disposition.** Never busy-wait: after verification returns, check the review at most once via `subagent({ action: "status", id: <run id> })`; if still running, end the turn with no disposition — pi delivers the async completion, and the review output file is read only after terminal completion. If the async dispatch errored or the child died, re-dispatch the review serially (the verification result is already in hand). **No disposition of either result — no fix dispatch, no finding triage, no verify-complete claim, no `conformance-reviewer` dispatch — before both results are in hand and any fix-triggered re-run is green.** Post-join, address Critical and Moderate findings before handoff. Verification failed, review clean → dispatch fixes, then re-run the full set before any subsequent gate. Both audits dirty → strictly ordered, never merged: the review's certified `Parallel-safe:` fan-out first (when present, else sequential fixes), then the remaining verification failures sequentially, then one re-review and one full verification re-run — verification failures never join a `Parallel-safe:` group (they carry no finding IDs and no disjointness certification, and `dispatching-parallel-agents` forbids orchestrator-invented partitions). Both audits bind to the committed HEAD: any post-join fix commit — review-derived or conformance-derived — invalidates the verification result; re-run the full set before re-dispatching any gate. (Consumers wanting an in-flow project-specific audit re-add it via the gauntlet overrides file (see Project overrides), or run `/self-audit` manually.)
-3. **Close the loop — conformance check.** The review in step 1 is plan-vs-code (single-step); it inherits any requirement the plan already dropped. Before marking verify complete, dispatch a fresh-context **`conformance-reviewer`** — its **own** dispatch, never fused into the step-1 review — to confront the deliverable (code **and** docs) against the *origin* — the spec **and** the original prompt — per `verification-before-completion/reference/conformance-check.md`. Pass the spec path, the verbatim original prompt, and the full diff. Follow that reference for the partition rule, concern decomposition, and fix-loop mechanics; do not reimplement them here. The fix loop may drive `plan_tracker` to surface fix-wave progress (task naming and lifecycle per conformance-check.md's fix loop / the Fix fan-out Progress rule); it never calls `phase_tracker`. Call `phase_tracker({ action: "complete", phase: "verify" })` only when the reference says the handoff is durably complete: either a current `CONFORMS` result, or a current `## Closure / conformance` inventory whose carried-open concerns all come from valid deferred gaps, including `recommended: fix` gaps carried open because a declared precondition made the fix loop unavailable (`maxFixRounds: 0`, or no eligible named-branch worktree). A started positive-cap fix loop that blocks, fails, or exhausts its rounds with an open `fix` gap is escalation, not completion; on escalation, do not complete verify, stop and report.
+1. **Parent full verification.** Run the complete plan-header `**Verification:**` command set foreground: tests plus every declared lint, type, format, and build check. A failure must be repaired and the full set rerun successfully before the next step. Before dispatching a verification repair, reopen (`in_progress`) every existing plan-task index whose `Files:` ownership includes its touched files; leave unowned cross-cutting repair work in the verification report. Those indices stay `in_progress` through the successful full rerun **and** step 2's whole-diff review accepting the repair — that acceptance is their completion point, not the passing rerun. Commit any verification-produced tracked changes; use the resulting `HEAD_SHA` in the review task and include the commands/results in its existing `DESCRIPTION`.
+2. **Whole-diff code review.** Only after passing full verification, dispatch one foreground whole-diff `code-reviewer` per `/skill:requesting-code-review` against that committed HEAD, with `SCOPED_TEST_COMMANDS: none`; the reviewer does not repeat the full suite. Address Critical and Moderate findings. Before dispatching a review repair, reopen (`in_progress`) every existing plan-task index whose `Files:` ownership includes its touched files; leave unowned cross-cutting repair work in the review report. Mark each reopened index `complete` only once the repair is re-verified and the re-review accepts it — this is the same completion point step 1's reopened indices wait for, not an extra gate, and the gate order stays full verification -> whole-diff CR -> conformance. Any repair invalidates prior full verification, so rerun the full set successfully before the next gate.
+3. **Close the loop — conformance check.** The review in step 2 is plan-vs-code (single-step); it inherits any requirement the plan already dropped. Before marking verify complete, dispatch a fresh-context **`conformance-reviewer`** — its **own** dispatch, never fused into the step-2 review — to confront the deliverable (code **and** docs) against the *origin* — the spec **and** the original prompt — per `verification-before-completion/reference/conformance-check.md`. Pass the spec path, the verbatim original prompt, and the full diff. Follow that reference for the partition rule, concern decomposition, and fix-loop mechanics; do not reimplement them here. The fix loop reuses durable `Gn` gap indices as defined in conformance-check.md; it never calls `phase_tracker`. Call `phase_tracker({ action: "complete", phase: "verify" })` only when the reference says the handoff is durably complete: either a current `CONFORMS` result, or a current `## Closure / conformance` inventory whose carried-open concerns all come from valid deferred gaps, including `recommended: fix` gaps carried open because a declared precondition made the fix loop unavailable (`maxFixRounds: 0`, or no eligible named-branch worktree). A started positive-cap fix loop that blocks, fails, or exhausts its rounds with an open `fix` gap is escalation, not completion; on escalation, do not complete verify, stop and report.
 4. Summarize what was implemented (tasks completed, files changed, test counts, code-review verdict). Emit the `## Closure / conformance` block exactly as defined in `verification-before-completion/reference/conformance-check.md`: it must open with the two-line sentinel (`status: CONFORMS (0 open)` or `status: GAPS (N open)`, then `audited-base: <full HEAD SHA>`), then carry the exact durable concern schema by reference with no renamed or reformatted fields. `finishing-a-development-branch` Step 3.5 consumes that block verbatim.
 5. **Proceed to finishing — no confirmation prompt.** Once verify is complete per step 3's criterion, invoke `/skill:finishing-a-development-branch` immediately. Its Step 4 menu (squash / PR / keep / discard) is the human gate; a separate "ready to finish?" prompt only stacks a second stop in front of it. Carried-open concerns are resolved there per concern via the `## Closure / conformance` block from step 4. Manual testing is a follow-up after the finishing choice (on `<base-branch>` after a squash-merge, or on the PR branch), never a reason to hold this gate.
 
@@ -251,7 +253,9 @@ For the fan-out + worktree + patch-integration + conflict mechanics, see `dispat
 - Dispatching `code-reviewer` per task inside a wave (CR binds to the integrated wave diff)
 - Dispatching an implementer or code-reviewer without a `SCOPED_TEST_COMMANDS` value (commands or `none`)
 - About to run the full verification entrypoint during the implement phase — task and wave gates run scoped, plan-declared commands only; the full set belongs to verify
-- Dispositioning either after-all-tasks audit — fix dispatch, finding triage, verify-complete claim, or `conformance-reviewer` dispatch — before both the whole-diff review and the full verification run have completed
+- Dispatching a verification or review repair before reopening (`in_progress`) the plan-task indices that own its touched files, or completing them on the passing rerun instead of on the accepting whole-diff review
+- Dispatching whole-diff CR before parent full verification passes, or conformance before the foreground CR result and any invalidating repair re-verification/re-review are accepted
+- Polling, joining, or relaunching an unexpectedly asynchronous gauntlet dispatch instead of stopping and reporting
 
 ## Integration
 

package/skills/test-driven-development/SKILL.md

@@ -219,7 +219,7 @@ Otherwise → not TDD
 
 No exceptions without your human partner's permission.
 
-When the TDD implementation cycle is complete (all tests green, code committed), mark the implement phase complete:
+When the TDD implementation cycle is complete (all tests green, code committed), mark the implement phase complete only for a direct, standalone task. In an orchestrated gauntlet task or review loop, green tests and a commit do not accept the parent task or complete its phase: the parent retains tracker and phase ownership through its required reviews.
 
 ```
 phase_tracker({ action: "complete", phase: "implement" })

package/skills/verification-before-completion/SKILL.md

@@ -160,7 +160,7 @@ Defaults recognise `make ci`, `make test`, `npm test`, `pnpm test`, `yarn test`,
 
 Before running the verification gate, call `phase_tracker({ action: "start", phase: "verify" })`.
 
-When all verification passes, mark the verify phase complete:
+When all verification passes, finish and await the required `plan_tracker` updates before marking verify complete. Reconcile accepted work on its existing indices; never clear or reinitialize to obtain closure. In a direct verification path, complete only after those updates have actually returned.
 
 ```
 phase_tracker({ action: "complete", phase: "verify" })

package/skills/verification-before-completion/reference/conformance-check.md

@@ -130,7 +130,7 @@ Mirrors `subagent-driven-development` Parallel-Wave Mode and reuses its
 `plan_tracker` progress surface. Runs entirely inside the gate — it invokes
 **no** `phase_tracker` calls (`phase_tracker({ phase: "implement" })` errors
 while verify is `in_progress`) and does **not** enter SDD's phase machinery.
-Only the fan-out/integrate/review shape and `plan_tracker` are reused.
+Only the fan-out/integrate/review shape and `plan_tracker` are reused. Every execution dispatch is foreground with top-level `async: false`, including retries and prose-described dispatches; an unexpected async handle is a configuration failure: stop and report, never poll or relaunch. `forceTopLevelAsync` is incompatible; see [pi-cohort dispatch configuration](https://github.com/jjuraszek/pi-cohort/blob/main/doc/configuration.md).
 
 **Precondition — worktree required.** The loop needs a worktree HEAD to branch
 fixes from. On the ad-hoc `finishing-a-development-branch` paths that run in a
@@ -143,23 +143,16 @@ prerequisites hold.
 
 Per round:
 
-1. **`plan_tracker` add** — append the round's gaps as tasks (`Gn: <gap origin
-   clause verbatim, truncated>`; carry the gap's requirement text mechanically,
-   no orchestrator-authored summaries); never `init`, which would wipe the
-   implement phase's completed task list. Lifecycle per gap: `pending` →
-   `in_progress` → `complete`. The widget now shows fix-wave progress during
-   verify.
+1. **Synchronize gap tasks** — append only a genuinely new gap that is entering remediation, named `Gn: <gap origin clause verbatim, truncated>`; never `init`. Find existing gaps by their exact `Gn:` prefix and reuse that index even if origin wording changes. Carried-OPEN inventory-only gaps add nothing. Before dispatch, mark every remediated gap's existing index `in_progress`; a re-audit needing more work reopens that same `Gn` index. The lifecycle traces `[T1,T2]`, then `[T1,T2,G1]`, then `[T1,T2,G1,G2]`; no test-retry or review-round wrapper task.
 2. **Fix dispatch** — per `dispatching-parallel-agents` "Fix fan-out": a `disjoint`
    group of ≥ 2 gaps (per the report's `Parallel-safe:` line) fixes in one parallel
-   dispatch — one `implementer` per gap (fresh context, `worktree: true`, `cwd` =
-   the conformance worktree, task = the gap block verbatim with `touched-files` as
-   the ownership boundary). The dispatch adds `SCOPED_TEST_COMMANDS` to the gap
-   block: the gap-relevant plan-declared commands, or `none` (the round's test
-   gate owns execution). `conflicts` pairs serialize. Gaps outside any ≥ 2-ID
-   `disjoint` group run sequentially as before. Then dispatch `spec-reviewer` per
-   gap on the gap-block reference contract below. Task lifecycle: mark `in_progress` at
-   dispatch; `complete` is deferred until the gap's patch is successfully
-   integrated in step 3 below.
+   foreground dispatch — one `implementer` per gap (fresh context, `async: false`,
+   `worktree: true`, `cwd` = the conformance worktree, task = the gap block verbatim
+   with `touched-files` as the ownership boundary). The dispatch adds `SCOPED_TEST_COMMANDS`
+   to the gap block: the gap-relevant plan-declared commands, or `none` (the round's
+   test gate owns execution). `conflicts` pairs serialize. Gaps outside any ≥ 2-ID
+   `disjoint` group run sequentially as before. Then dispatch foreground `spec-reviewer`
+   per gap on the gap-block reference contract below.
 3. **Integrate** serially via `git apply` onto the worktree HEAD, one gap's
    patch at a time. Failure handling is inherited verbatim from
    `dispatching-parallel-agents` "Review and Integrate": textual conflict →
@@ -168,10 +161,9 @@ Per round:
    offending task sequentially on integrated HEAD; a failed agent → integrate
    the successes, then retry the failure with fresh context including the
    integrated changes. A `BLOCKED`/`NEEDS_CONTEXT` return surfaces to the user.
-4. **Test gate** on the integrated tree, using the project's canonical test
-   command. A failure re-enters the failure-handling rules above.
-5. **`code-reviewer` once** on the round's cumulative fix delta (not per gap), with `SCOPED_TEST_COMMANDS` = the round's gap-relevant commands, or `none` (the round's test gate owns execution).
-6. **Re-audit**: re-dispatch `conformance-reviewer` over the fixes **plus** the
+4. **Test gate** on the integrated tree. In a plan flow, run the full plan-header `Verification` set once here; on an ad-hoc no-plan path, use the project's canonical test command. A failure re-enters the failure-handling rules above.
+5. **Round CR and completion** — run `code-reviewer` once on the round's cumulative fix delta (not per gap), foreground with `async: false` and `SCOPED_TEST_COMMANDS` = the round's gap-relevant commands, or `none` (the round's test gate owns execution). After integration, tests, and this CR accept the work, explicitly mark every remediated gap's same `Gn` index `complete`, before re-audit.
+6. **Re-audit**: foreground re-dispatch `conformance-reviewer` with `async: false` over the fixes **plus** the
    regression guard (any prior-`DELIVERED` requirement whose `evidence` file
    the fix diff touched). Pass the full prior conformance report (every row,
    including DELIVERED rows and their `evidence` `file:line`) and the round's

package/skills/writing-plans/SKILL.md

@@ -85,7 +85,7 @@ Otherwise one plan. Service, contract, or schema count is not a split signal - o
 Before mapping files, dispatch a scout to build the implementation map. Foreground, no announcement, no user interaction. The task template below is fixed — fill exactly **one** variable, the absolute spec path; compose nothing else:
 
 ```
-subagent({ agent: "scout", context: "fresh", cwd: "<abs worktree path>",
+subagent({ agent: "scout", context: "fresh", async: false, cwd: "<abs worktree path>",
   phase: "plan-recon", output: "<abs plan path — same filename as the spec, per the table above>",
   task: <the fixed template below, with the spec path filled> })
 ```
@@ -316,10 +316,11 @@ Fix what this review finds before handoff.
 
 ## Execution Handoff
 
-After saving the plan, mark the planning phase complete:
+After saving the plan, mark the planning phase complete, then initialize `plan_tracker` once with every plan task in wave order. Name each entry `W<k>: <title>` using its containing wave and task title. This is the execution list: do not initialize it again on continuation.
 
 ```
 phase_tracker({ action: "complete", phase: "plan" })
+plan_tracker({ action: "init", tasks: ["W1: <title>", "W1: <title>", "W2: <title>"] })
 ```
 
 Then auto-select the execution mode and proceed — no pause, no picker. The mode is a pure function of the plan's wave structure: