pi-gauntlet 4.4.0 → 4.4.1

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # Changelog
 
+## v4.4.1 - 2026-07-13
+
+Gates ratify, not ceremony: two gauntlet gates now auto-apply mechanical/drafting
+changes and stop the human only for a load-bearing decision, not ritual confirmation.
+
+- **Conformance gate (`verification-before-completion/reference/conformance-check.md`,
+  `subagent-driven-development`, `verification-before-completion`):** GAPS handling is
+  a deterministic verdict-then-`recommended` partition, no menu. `fix` gaps auto-close
+  through an isolated SDD-mirror fix loop (per-gap `implementer` + `spec-reviewer` on a
+  gap-block contract, `plan_tracker` fix-wave progress, per-round `code-reviewer`, delta
+  re-audit with regression guard, `maxFixRounds` cap -> escalate). `accept`/`rescope`/
+  `UNAUTHORIZED` gaps carry OPEN to the finishing gate. New `## Closure / conformance`
+  handoff schema + `conformance fix Gn` commit convention.
+- **Spec council (`roasting-the-spec`, `brainstorming`):** the main-loop model applies
+  the chair's apply-set before the single brainstorming review gate; a gate-only
+  Applied/Deferred/Rejected audit is recorded in the spec commit body. The verbatim
+  summary now reflects the final post-apply spec on both worker and council paths;
+  checklist item 10 reduced to a re-scan; revert valve at the gate.
+- **`finishing-a-development-branch` Step 3.5:** enforced per-gap disposition gate
+  (accept-into-spec / rescope-into-spec / fix-now / custom disposition / revert) with
+  three-tier revert semantics.
+- **`agents/conformance-reviewer.md`:** deterministic `UNAUTHORIZED` recommendation
+  (harmless -> accept, else fix).
+- **Extensions (`phase-tracker.ts`, `plan-tracker.ts`):** `SHIP_ADVISORY` and the
+  `plan_tracker` tool description reworded to allow carried-open deferred gaps and
+  verify-phase fix waves (description strings only, no logic change).
+- **`README.md`:** conformance gate auto-fixes requirement-restoring gaps, defers
+  spec-rewriting decisions to the finishing gate.
+
 ## v4.4.0 - 2026-07-12
 
 Add an unconditional parallel context-gather step to `/skill:brainstorming`. Step 3's

package/README.md

@@ -38,7 +38,7 @@ Concretely, one change through the gauntlet:
 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. **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. This gate is machine-blocked from being skipped.
+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. This gate is machine-blocked from being skipped. Requirement-restoring gaps (code drifted from the approved spec) auto-close through an isolated fix-and-re-audit loop with no prompt; only decisions that would *rewrite* your approved spec - accept, rescope, or removing unrequested code - are deferred to the finishing gate for your call.
 5. **`finishing-a-development-branch`**: squash, PR, keep, or discard. **Human gate 2** - the only other decision you make.
 
 ```mermaid
@@ -74,7 +74,7 @@ pi-gauntlet is **opinionated**: every non-trivial change rides this one pipeline
 | --- | --- |
 | Gate | A machine-enforced checkpoint between phases (e.g. `complete verify` is blocked until conformance review has run). Not a suggestion. |
 | Spec council | Multi-model critique of the spec before you see it (`roasting-the-spec`); falls back to a single-model critique if no council is configured. |
-| Conformance gate | The closing check: does the delivered code + docs match your *original prompt*, not the derived plan? Per-requirement verdict, no auto-fix. |
+| Conformance gate | The closing check: does the delivered code + docs match your *original prompt*, not the derived plan? Per-requirement verdict; auto-fixes requirement-restoring gaps, defers spec-rewriting decisions (accept/rescope/unauthorized) to the finishing gate. |
 | Wave | A batch of plan tasks that don't touch the same files, dispatched to implementers in parallel. |
 | Overrides file | `.pi/gauntlet-overrides.md` - where you put project-specific detail the generic skills don't know (CI command, worktree wrapper, routing rules). |
 

package/agents/conformance-reviewer.md

@@ -64,7 +64,7 @@ DELIVERED rows keep an `Rn` id; every non-DELIVERED row gets a durable `Gn` id r
 ## Structured gap blocks
 
 After the coverage table, emit one fenced block per non-DELIVERED row so the
-orchestrator can drive the disposition menu mechanically. In a re-audit round
+orchestrator can partition and dispose of them mechanically. In a re-audit round
 (see conformance-check.md "When the check finds gaps"), also emit a `DELIVERED`
 block for any gap that closed, reusing its original `Gn` id.
 
@@ -122,15 +122,15 @@ disjointness rule does. When you cannot confidently certify a pair disjoint, mar
 `recommended` is a proposal; you never decide, edit, dispatch, or re-audit.
 
 - Default `fix` for every `PARTIAL` / `MISSING` / `DRIFTED` row.
-- `accept` only for an `UNAUTHORIZED` row whose behavior is harmless, with a one-line
-  rationale in `remediation`.
+- For every `UNAUTHORIZED` row: harmless → `accept` with a one-line rationale in
+  `remediation`; otherwise → `fix` (= remove the unrequested code).
 - `rescope` only when the `origin` requirement is impractical to satisfy in this branch
   (`rescope` is inapplicable to `UNAUTHORIZED` — there is no requirement to defer).
 
 ## Rules
 
 - **Read-only. Never edit.** You audit; you do not fix.
-- **Propose, do not dispose.** For each gap you may suggest a one-line remediation *direction*, but you do **not** decide whether to apply it, defer it, or accept it — that is the user's call, surfaced by the orchestrator. Never present a fix as a decision made.
+- **Propose, do not dispose.** For each gap you may suggest a one-line remediation *direction*, but you do **not** decide the disposition - the orchestrator auto-applies `fix` gaps and defers `accept`/`rescope`/`UNAUTHORIZED` to the user at the finish gate. Never present a fix as a decision you made.
 - **Evidence or it didn't happen.** Cite a real `file:line` for every DELIVERED/PARTIAL. If you cannot, downgrade the row to MISSING.
 - **Spec is canonical; the prompt catches what the spec dropped; the ticket is fallback only** when no spec exists.
 - **Do not absorb origin drift silently** — flag every spec↔prompt/ticket disagreement.

package/extensions/phase-tracker.ts

@@ -71,12 +71,12 @@ const CLOSURE_GATE_ERROR =
   '  phase_tracker({ action: "skip", phase: "verify", reason: "<user waiver>" })';
 
 const SHIP_ADVISORY =
-  "Verify is complete and ship is pending. If the conformance verdict is resolved\n" +
-  "(CONFORMS, or every gap dispositioned and approved), invoke\n" +
-  "/skill:finishing-a-development-branch now - do not add a 'ready to finish?' prompt;\n" +
-  "its squash/PR/keep/discard menu is the human gate. If a requirement decision is\n" +
-  "still open, you should not have completed verify - reopen it and surface the open\n" +
-  "decision instead.";
+  "Verify is complete and ship is pending. Verify may complete when the conformance\n" +
+  "verdict is CONFORMS, or every gap is either fixed or carried open as a deferred\n" +
+  "accept/rescope/unauthorized decision. Invoke /skill:finishing-a-development-branch\n" +
+  "now - do not add a 'ready to finish?' prompt; its disposition + squash/PR/keep/discard\n" +
+  "menu is the human gate that resolves any carried-open decision. Only reopen verify if\n" +
+  "a `fix` gap was left unresolved (neither fixed nor deferred).";
 
 // --- Flow guards (spec 2026-06-17-gauntlet-flow-guards) ---
 

package/extensions/plan-tracker.ts

@@ -129,7 +129,7 @@ export default function (pi: ExtensionAPI) {
     name: "plan_tracker",
     label: "Plan Tracker",
     description:
-      "Track progress while EXECUTING an implementation plan — the implement phase only. Actions: init (set task list), update (change task status), status (show current state), clear (remove plan). Do NOT use for brainstorming, research, or planning checklists: those phases are open-ended and a bounded task list misrepresents them as a fixed N-step process.",
+      "Track progress while EXECUTING an implementation plan (the implement phase) or a verify-phase conformance fix wave. Actions: init (set task list), update (change task status), status (show current state), clear (remove plan). Do NOT use for brainstorming, research, or planning checklists: those phases are open-ended and a bounded task list misrepresents them as a fixed N-step process.",
     parameters: PlanTrackerParams,
 
     async execute(_toolCallId, params, _signal, _onUpdate, ctx) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "4.4.0",
+  "version": "4.4.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

@@ -59,10 +59,10 @@ Work through the items below **in order**. This is your own checklist to follow,
 6. **Present the design** — in sections, get approval after each
 7. **Write the spec** — to `doc/specs/` (see [Filename Convention](#filename-convention))
 8. **Spec self-review (lint)** — placeholder scan + internal consistency + documentation named, run inline
-9. **Critique pass (auto-dispatched)** — scope + ambiguity; the spec council via `/skill:roasting-the-spec` when `gauntlet_setting` returns verdict `council`, else a fresh `worker` (see [Spec Council](#spec-council-optional))
-10. **Re-run placeholder scan** — after the critique pass returns, first inline any `external-ref:` flags it raised (see [Spec Self-Review](#spec-self-review-before-user-review-gate)), then re-scan for placeholders its edits may have introduced; surface any ambiguity the worker could not safely resolve at the user gate
-11. **Generate spec summary** — dispatch a fresh, spec-only `spec-summarizer` writing to an absolute temp-dir path via `outputMode: "file-only"`, then `Read` that file back as the **last content-producing** tool call before composing the gate and render its contents **verbatim** at the top of the gate message — do not paraphrase, condense, re-section, or rewrite it (see [User Review Gate](#user-review-gate)); this is part of the existing gate, not a new one
-12. **User review gate** — user reviews the committed spec
+9. **Critique pass (auto-dispatched)** — scope + ambiguity; the spec council via `/skill:roasting-the-spec` when `gauntlet_setting` returns verdict `council` (it applies its apply-set, including any external-ref inlining, to the spec before returning — see [Spec Council](#spec-council-optional)), else a fresh `worker` that applies its own fixes in place
+10. **Re-run placeholder scan** — after the critique pass returns, re-scan the **applied** spec for placeholders its edits may have introduced; surface any ambiguity the critique could not safely resolve at the user gate
+11. **Generate spec summary** — dispatch a fresh, spec-only `spec-summarizer` over the **final (post-apply)** spec, writing to an absolute temp-dir path via `outputMode: "file-only"`, then `Read` that file back as the **last content-producing** tool call before composing the gate and render its contents **verbatim** at the top of the gate message — do not paraphrase, condense, re-section, or rewrite it (see [User Review Gate](#user-review-gate)); this is part of the existing gate, not a new one
+12. **User review gate** — user reviews the applied spec's verbatim summary plus the council audit (Applied/Deferred/Rejected), with a revert valve for any applied council edit
 13. **Transition** — only after approval, invoke `/skill:writing-plans`
 
 ## Project Routing
@@ -244,7 +244,7 @@ After writing the spec to `<project>/doc/specs/<filename>.md` (per [Filename Con
 
 The first three checks — **placeholder scan**, **internal consistency**, and **documentation named** — are the inline **lint**: run them here at the main loop and fix what they surface. The last two — **scope** and **ambiguity** — are **not** run inline; they are the **critique pass**, auto-dispatched (per [Spec Council](#spec-council-optional)):
 
-- **Council** (`gauntlet_setting({ key: "specCouncil" })` returns verdict `council`) → invoke `/skill:roasting-the-spec`; it runs the critique and proposes dispositions.
+- **Council** (`gauntlet_setting({ key: "specCouncil" })` returns verdict `council`) → invoke `/skill:roasting-the-spec`; it runs the critique, derives dispositions, and **applies the apply-set to the spec** (including inlining any `external-ref:` cluster it has context for) **before returning** — see that skill for apply mechanics. It returns a structured audit: `Applied:` / `Deferred:` / `Rejected:`.
 - **Otherwise** → dispatch one fresh `worker` that applies the scope + ambiguity checks and fixes them in place:
 
   ```
@@ -253,23 +253,24 @@ The first three checks — **placeholder scan**, **internal consistency**, and *
     "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" +
     "state out-of-scope explicitly. (2) Ambiguity — is every 'we should' a concrete decision?\n" +
-    "Replace 'we could probably' with 'we will'/'we won't'. Also flag (do NOT fetch) any\n" +
-    "load-bearing external reference (ticket AC, commit SHA, doc) the spec relies on but does\n" +
-    "not inline, and recommend inlining it. Return a summary of what you changed, and flag any\n" +
-    "ambiguity you could NOT safely resolve." })
+    "Replace 'we could probably' with 'we will'/'we won't'. Also inline any load-bearing\n" +
+    "external reference (ticket AC, commit SHA, doc) already given to you in the problem\n" +
+    "statement above; if the spec relies on one not provided here, flag it (do NOT fetch) in\n" +
+    "your summary. Return a summary of what you changed, and flag any ambiguity you could NOT\n" +
+    "safely resolve." })
   ```
 
   `worker`'s model resolves from `subagents.agentOverrides.worker.model` in `settings.json` (unset → inherits the main loop); the dispatch passes no `model:`.
 
-After the critique pass returns, scan it for load-bearing external references before re-running the placeholder scan: in the council path, look for chair clusters whose theme is prefixed `external-ref:`; in the worker path, look for the worker's external-ref flag. For each, inline the referenced content you have context for (e.g. the ticket fetched during brainstorming) via the normal disposition/edit path - you hold the ticket, the critics do not. Then re-run the placeholder scan to catch anything the edits introduced. If the worker flagged ambiguities it could not safely resolve, surface them in the [User Review Gate](#user-review-gate) message so the user decides - the worker auto-applies fixes but never silently swallows an open question.
+Both paths apply their fixes **before returning** — the council auto-applies inside `/skill:roasting-the-spec`, the worker edits the spec file directly. After the critique pass returns, re-run the placeholder scan over the **applied** spec to catch anything the edits introduced. If the worker flagged ambiguities it could not safely resolve, surface them in the [User Review Gate](#user-review-gate) message so the user decides - the worker auto-applies fixes but never silently swallows an open question.
 
 ## Spec Council (Optional)
 
-After the inline lint and before the user review gate, **brainstorming owns the critique-pass gate**. Resolve the council with `gauntlet_setting({ key: "specCouncil" })` - the tool returns the merged (repo-over-preset) value as `{ verdict, members, chair, malformed, warning, errors }`. **Do not** hand-roll a settings read. When `verdict` is `"council"`, the council *is* the critique pass - invoke `/skill:roasting-the-spec` automatically (no offer, no prompt), passing `members`/`chair`. When `verdict` is `"worker"`, run the fresh-`worker` critique instead (see [Spec Self-Review](#spec-self-review-before-user-review-gate)). If `malformed` is true or `errors` is non-empty, emit the `warning`/error as one line, then branch strictly on `verdict` - `malformed` can accompany *either* verdict (e.g. a bad `chair` with valid `members` still returns `council`), so never infer the worker path from `malformed` alone. If `gauntlet_setting` is unavailable, stop and report - never fall back to a manual bash/JSON settings merge. Approved council edits (or the worker's in-place fixes) ride in the same worktree commit. The conceptual precedence rule lives in `verification-before-completion/reference/settings-precedence.md`.
+After the inline lint and before the user review gate, **brainstorming owns the critique-pass gate**; council **apply mechanics** live in `/skill:roasting-the-spec` (single source of truth - link, don't restate). Resolve the council with `gauntlet_setting({ key: "specCouncil" })` - the tool returns the merged (repo-over-preset) value as `{ verdict, members, chair, malformed, warning, errors }`. **Do not** hand-roll a settings read. When `verdict` is `"council"`, the council *is* the critique pass - invoke `/skill:roasting-the-spec` automatically (no offer, no prompt), passing `members`/`chair`; it applies its apply-set and returns the audit (Applied/Deferred/Rejected). When `verdict` is `"worker"`, run the fresh-`worker` critique instead (see [Spec Self-Review](#spec-self-review-before-user-review-gate)). If `malformed` is true or `errors` is non-empty, emit the `warning`/error as one line, then branch strictly on `verdict` - `malformed` can accompany *either* verdict (e.g. a bad `chair` with valid `members` still returns `council`), so never infer the worker path from `malformed` alone. If `gauntlet_setting` is unavailable, stop and report - never fall back to a manual bash/JSON settings merge. The already-applied council edits (or the worker's in-place fixes) ride in the same worktree commit. The conceptual precedence rule lives in `verification-before-completion/reference/settings-precedence.md`.
 
 ## User Review Gate
 
-After self-review (and council review, if configured) and after inlining any external-ref flags, dispatch the spec-only summarizer, then commit the spec on the worktree branch and stop. This is the **same** single human gate - the summary is folded into it, not a new gate.
+After self-review and the critique pass (council or worker, both already applied to the spec - see [Spec Council](#spec-council-optional)), dispatch the spec-only summarizer over the **applied** spec, then commit the spec on the worktree branch and stop. This is the **same** single human gate - the summary is folded into it, not a new gate.
 
 Mint an absolute temp path outside the worktree (so it is never committed), then dispatch the summarizer on a fresh context, reading only the spec, writing to that path via file-only output (no `model:` - it inherits the main loop unless a preset sets `subagents.agentOverrides.spec-summarizer.model`):
 
@@ -285,7 +286,7 @@ subagent({ agent: "spec-summarizer", context: "fresh", cwd: "<abs worktree path,
 
 `<SUMMARY_PATH>` above is a placeholder in the dispatch object; it means substitute the value of the shell variable `$SUMMARY_PATH` set above. The steps below use `$SUMMARY_PATH` (the shell form) once the value is in hand.
 
-Then commit the spec — this commit is **unconditional**: the summary is only a gate aid, so a degraded or missing summary never blocks it. Evaluate the summary in two stages (the **Degrade path** referenced in each is defined just below):
+Then commit the spec — this commit is **unconditional**: the summary is only a gate aid, so a degraded or missing summary never blocks it. If the council path ran, include its audit (`Applied:` / `Deferred:` / `Rejected:`, verbatim from `/skill:roasting-the-spec`'s return) in the **commit message body** - this is the durable, non-contractual record a finish-time revert reads back; the audit is never a committed spec section. Evaluate the summary in two stages (the **Degrade path** referenced in each is defined just below):
 
 1. **From the dispatch tool result, before the `Read`.** If the result is **not** an `"Output saved to: <path> (<N> KB, <M> lines)"` reference (e.g. an exit-0 save error returns the full inline output plus an "Output file error" line — the prunable shape, no file to read), or the reference reports under ~500 bytes, or a size grossly disproportionate to the spec (under ~2% of its byte size), or over ~45 KB (the `Read` truncates at 50KB / 2000 lines, so a larger file cannot render whole) — skip the `Read` and take the degrade path. Use the reference's reported figures; do not re-derive them.
 2. **The `Read` itself, as the last content-producing tool call before composing the gate.** `Read` `$SUMMARY_PATH` and paste its contents verbatim at the top of the gate. If the `Read` fails, returns 0 bytes, or reports truncation — take the degrade path. The `Read` must be last: pi-condense does not protect a `/tmp` read, so any turn boundary between the `Read` and the render lets the ~9KB read result be pruned, reproducing the bug.
@@ -294,21 +295,28 @@ Then commit the spec — this commit is **unconditional**: the summary is only a
 
 Either way — summary rendered or degraded — then `rm "$SUMMARY_PATH"` (unconditional cleanup; harmless if the file was never created, since it lives outside the worktree under the OS temp dir).
 
-Render the temp file's contents **verbatim** first — paste it as-is, do **not** paraphrase, condense, re-section, drop sections, or merge it with council output. "Fold into the gate" means *place it inside the gate message*, not *rewrite it*. After the verbatim block, append the commit confirmation, then — as their **own** adjacent lines, not edits to the summary — any council outcome, critique-pass-unresolved ambiguities, and every entry from the summarizer's gap/external-context footer (surface **all** of them, not just the top risk):
+Render the temp file's contents **verbatim** first — paste it as-is, do **not** paraphrase, condense, re-section, drop sections, or merge it with the council audit. "Fold into the gate" means *place it inside the gate message*, not *rewrite it*. This summary is of the **final (post-apply)** spec, since both critique paths already applied before this dispatch. After the verbatim block, append the commit confirmation, then — as their **own** adjacent lines, not edits to the summary — the council audit (if the council path ran: `Applied:` / `Deferred:` / `Rejected:`, one line each), critique-pass-unresolved ambiguities, and every entry from the summarizer's gap/external-context footer (surface **all** of them, not just the top risk):
 
 ```
 <spec-only summary read back from the temp file — pasted verbatim, unedited>
 
 Spec written and committed to <project>/doc/specs/<filename>.md (worktree: <path>).
 
-<council outcome, if any; unresolved ambiguities; every gap-footer entry from the summary>
+Applied: <cluster -> edit>, ...
+Deferred: <cluster -> where it belongs>, ...
+Rejected: <cluster -> one-line reason>, ...
+(omit the three lines above when the worker path ran, not the council)
 
-Please review. Approve to proceed, or tell me what to change in the spec.
+<unresolved ambiguities; every gap-footer entry from the summary>
+
+Please review. Approve to proceed, tell me what to change in the spec, or say "revert applied council edit <X>" to undo a specific applied edit.
 ```
 
 If you believe the summary needs correcting, do **not** silently rewrite it — re-dispatch the summarizer or note the discrepancy as an adjacent line beneath the verbatim block.
 
-Wait for the user. On a change request, revise the spec and re-present — mint a **fresh** temp path for the re-dispatched summarizer (never reuse a prior round's path, so stale content can never be mistaken for the new summary). On approval, proceed immediately to `/skill:writing-plans` with no further prompt — the plan and execution mode are mechanical derivatives, so the only human gate here is spec approval itself. Don't land the spec on `main`; it stays in the worktree and ships in the same squash commit as the implementation.
+**Revert valve.** "Revert applied council edit X" is a normal change request: revise the spec to undo edit X, re-dispatch the summarizer with a **fresh** temp path (per the re-dispatch rule below), and re-present the gate. This is cheap here - the spec is not yet plan- or code-bearing.
+
+Wait for the user. On a change request (including a revert), revise the spec and re-present — mint a **fresh** temp path for the re-dispatched summarizer (never reuse a prior round's path, so stale content can never be mistaken for the new summary). On approval, proceed immediately to `/skill:writing-plans` with no further prompt — the plan and execution mode are mechanical derivatives, so the only human gate here is spec approval itself. Don't land the spec on `main`; it stays in the worktree and ships in the same squash commit as the implementation.
 
 After approval, mark the brainstorm phase complete:
 

package/skills/finishing-a-development-branch/SKILL.md

@@ -70,24 +70,61 @@ git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
 
 Or ask: "This branch split from main - is that correct?"
 
-### Step 3.5: Surface Closure / Conformance Status
+### Step 3.5: Closure / Conformance Disposition Gate
 
-Before presenting finish options, surface the closing-loop conformance result as **its own section** — the user is about to choose how to ship, and they need to see whether the deliverable matches what was *asked*, not just whether tests pass. Tests prove the code runs; conformance proves it does what was requested. Different gates.
+This is an **enforced per-gap disposition gate**, not a surface-only notice. The user is about to choose how to ship; every carried-open gap must get an explicit disposition here, before Step 4's menu. Tests prove the code runs; conformance proves it does what was requested — different gates.
 
-- **If the execution flow already closed the loop** (the `conformance-reviewer` ran in the `subagent-driven-development` verify gate), restate its verdict here: `CONFORMS`, or the `GAPS` and how each was dispositioned (fixed / accepted-and-recorded-in-spec / rescoped). If any gap is still open, drive it through the remediation loop in `verification-before-completion/reference/conformance-check.md` "When the check finds gaps"; on a normal-repo (`GIT_DIR == GIT_COMMON`) or detached-HEAD finish there is no worktree to dispatch fix waves into, so that menu offers accept / rescope / manual fix-in-place only.
-- **If no conformance check has run in this flow** (e.g., ad-hoc work that landed without an execution skill), say so plainly and offer to run it now — dispatch a fresh-context `conformance-reviewer` against the origin (spec + verbatim prompt + full diff vs base) per `verification-before-completion/reference/conformance-check.md`. Closing the loop is cheap relative to shipping unverified intent.
-- **Unreconciled gaps are a blocker, not a footnote.** Do not bury them inside the options menu. If any gap is still open, resolve it (or get explicit user acceptance recorded in the spec) before offering Option 1 (squash-merge) or Option 2 (PR).
+**If no conformance check has run in this flow** (e.g., ad-hoc work that landed without an execution skill): say so, then dispatch a fresh-context `conformance-reviewer` against the origin (spec + verbatim prompt + full diff vs base) per `verification-before-completion/reference/conformance-check.md`. Closing the loop is cheap relative to shipping unverified intent. Then proceed below with its verdict.
 
-Present it as a distinct line the user reads before choosing:
+**If verdict is `CONFORMS`** (no carried-open gaps): report `Closure / conformance: CONFORMS`. If the run auto-applied any fixes, also surface the flat `auto-applied fix commits: <Gn: SHA>, ...` index from the `## Closure / conformance` block with a one-line revert offer (see "Revert semantics") — a gap that auto-converged to `CONFORMS` mid-verify has no per-gap line above, so this index is the only place its fix commit stays revertable. No per-gap menu. Continue to Step 4.
+
+**If gaps were carried open:** read the `## Closure / conformance` block from the verify completion summary (schema and field names defined once in `verification-before-completion/reference/conformance-check.md` — do not re-derive them here). For each `Gn` line, render it verbatim and offer this ordered menu — the human must pick one entry per gap before Step 4:
+
+```
+G<n>: <verdict> — recommended: <fix|accept|rescope> — touched-files: <paths>
+  round history: R1 ..., R2 ...
+
+D1. Apply now: accept-into-spec — fold a dated decision into the spec now (main session edits the spec directly, never a subagent)
+D2. Apply now: rescope-into-spec — same, recorded as reduced/changed scope
+D3. Apply now: fix-now — run the fix loop now (worktree finish paths only, see below)
+D4. Custom disposition — e.g. capture as a follow-up ticket per this project's issue-tracker convention (see `.pi/gauntlet-overrides.md`)
+D5. Revert an auto-applied change for this gap (see "Revert semantics" below)
+
+Which option for G<n>?
+```
+
+Also surface the flat `auto-applied fix commits: <Gn: SHA>, ...` index from the same block — this is the revert candidate list for D5, covering every `conformance fix Gn` commit this run (open and already-closed gaps alike).
+
+**`fix-now` loop scope (worktree finish paths only):**
+
+1. Commit any `accept-into-spec` / `rescope-into-spec` edits picked in this gate **before** dispatching — a dirty tree rejects `worktree: true`, and the re-audit must read the amended spec.
+2. Run the **full** loop from `verification-before-completion/reference/conformance-check.md` "Fix loop" (implementer → integrate → test → `code-reviewer` → re-audit). Do not re-describe the loop steps here — that file is the single source.
+3. Re-run Step 1's test verification on the result.
+4. Re-enter this step (3.5) with the re-audited `## Closure / conformance` block before re-presenting ship options.
+
+**Non-worktree precondition (unchanged):** on a normal-repo finish (`GIT_DIR == GIT_COMMON`) or detached HEAD there is no worktree to dispatch fix waves into — the menu above offers D1, D2, D4, and D5 (manual fix-in-place substitutes for D3) but never dispatches `fix-now`.
+
+No auto-proceed: every carried-open gap needs an explicit answer from the list above before Step 4 renders. Once all gaps are dispositioned, report the final state as a distinct line:
 
 ```
 Closure / conformance: CONFORMS
-  (or: GAPS — <n> open)
-  - <gap> → proposed remediation: <one line>   [if any open]
+  (or: GAPS — <n> dispositioned: G1 accept-into-spec, G2 fix-now → CONFORMS, ...)
 ```
 
 Then continue to Step 4.
 
+### Revert semantics
+
+Three tiers, increasing cost — name the tier when a revert is requested:
+
+| Tier | What's reverted | Cost | Mechanics |
+|---|---|---|---|
+| Cheap | Council edit, reverted at the `brainstorming` gate | Spec isn't yet plan- or code-bearing | Revise spec, re-present |
+| Light | Conformance fix, reverted at finish | Gap re-opens for a fresh disposition | Revert the `conformance fix Gn` commit(s), re-audit |
+| Heavy | Council edit, reverted at finish | Rewrites the already-ratified contract that drove the plan and code | Amend spec → re-approve → regenerate affected plan/code → re-run verify before ship |
+
+A **heavy** revert is not a menu toggle — say so explicitly to the user before proceeding, and do not present it as equivalent-effort to the light tier. The council audit that lets the human identify revert candidates lives in the `brainstorming` spec commit message body (not a committed spec section).
+
 ### Step 4: Present Options
 
 **Normal repo and named-branch worktree — present exactly these 4 options:**
@@ -300,7 +337,7 @@ phase_tracker({ action: "complete", phase: "ship" })
 - Remove a worktree before confirming merge success
 - Clean up worktrees you didn't create (provenance check)
 - Run `git worktree remove` from inside the worktree
-- Present finish options while a conformance gap is open and undispositioned
+- Auto-proceed past an undispositioned carried-open gap
 - Skip the guarded plan-doc removal before push on Option 2 when a plan doc was committed
 
 **Always:**

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

@@ -1,13 +1,13 @@
 ---
 name: roasting-the-spec
-description: Use after writing a spec, when a spec council is configured (the resolved piGauntlet.specCouncil council, via the gauntlet_setting tool, repo settings over the preset). Auto-dispatched by /skill:brainstorming as the critique pass when members is non-empty (no longer offered). N members on different models critique in parallel, a neutral chair consolidates and adjudicates, the parent proposes dispositions, the user approves.
+description: Use after writing a spec, when a spec council is configured (the resolved piGauntlet.specCouncil council, via the gauntlet_setting tool, repo settings over the preset). Auto-dispatched by /skill:brainstorming as the critique pass when members is non-empty (no longer offered). N members on different models critique in parallel, a neutral chair consolidates and adjudicates, the parent applies its own dispositions and returns an audit for the user to ratify at brainstorming's gate.
 ---
 
 # Roasting the Spec (Spec Council)
 
 ## Overview
 
-A multi-model critique pass for a freshly written spec. Each council **member** runs on a different model and critiques the spec independently — different models surface different angles. A neutral **chair** consolidates the critiques and adjudicates disagreements. The parent proposes what to apply; the **user** approves. The council never decides on its own what changes land.
+A multi-model critique pass for a freshly written spec. Each council **member** runs on a different model and critiques the spec independently — different models surface different angles. A neutral **chair** consolidates the critiques and adjudicates disagreements. The parent decides what to apply and applies it before returning; the **user** ratifies (or reverts) the result at brainstorming's single gate. The council never decides on its own what changes land.
 
 Auto-dispatched from `/skill:brainstorming` as the critique pass, after the inline lint and before the user review gate, **only when a council is configured** (`members` non-empty). brainstorming owns that gate; when no council is configured it runs a single fresh-`worker` critique instead and does not invoke this skill.
 
@@ -19,8 +19,8 @@ This skill may read anything and edit **only** the spec under `doc/specs/`. It d
 
 - **Members** — independent witnesses. One per configured model, fresh context, read-only.
 - **Chair** — judge of the testimony. Fresh context (never saw the spec authored); consolidates and resolves member-vs-member conflicts. Final say on conflicts; no say on what gets applied.
-- **Parent (you)** — advocate. Proposes apply / defer / reject per finding on scope grounds. Cannot suppress findings.
-- **User** — jury. Approves what actually lands, at the existing review gate.
+- **Parent (you)** — advocate, and now also executor. You decide apply / defer / reject per finding on scope grounds, then apply the apply-set yourself (you hold the `edit`/`write` tools; this was always the main-loop model's job, just moved earlier). Cannot suppress findings — every finding lands in the audit as applied, deferred, or rejected.
+- **User** — sole jury. Ratifies (or reverts) the finished spec at brainstorming's one gate — after the apply, not before.
 
 ## Configuration and gating
 
@@ -100,32 +100,41 @@ List the exact member paths in the task text. The `reads:` array injects their c
 
 If the configured `chair` model is unreachable, retry once with the inherited model.
 
-### 3 — Propose dispositions
+### 3 — Decide and apply
 
-For each cluster in the chair's report, decide and state one of:
+For each cluster in the chair's report, decide one of:
 
-- **apply** — with the concrete edit you will make.
-- **defer** — out of scope for this spec; name where it belongs.
-- **reject** — with a one-line reason.
+- **apply** — make the concrete edit to the spec under `doc/specs/` now.
+- **defer** — out of scope for this spec; name where it belongs. Do not edit the spec.
+- **reject** — one-line reason. Do not edit the spec.
 
-You are the advocate here, not the judge — propose, do not unilaterally apply.
+Also inline any `external-ref:` cluster you have context for (e.g. a ticket fetched during brainstorming) as part of the apply-set — this is your call, same as any other cluster.
 
-### 4 — User gate
+You are the advocate — decide on scope grounds — and, unlike a dispatched subagent, also the executor: you hold `edit`/`write` tools directly, so apply the edit yourself instead of proposing it for someone else to make. Do this **before** returning to brainstorming.
 
-Fold the chair's clusters, its `resolved` audit notes, and your proposed dispositions into brainstorming's user review gate. Let the user approve or adjust.
+### 4 — Emit the audit
 
-### 5 — Apply and clean up
+Return a structured audit, gate-only (not a committed spec section) — three labelled lists:
 
-Apply the approved edits to the spec under `doc/specs/`. Re-run brainstorming's placeholder scan. Remove the temp dir (`rm -rf` the `mktemp -d` path). Then continue with brainstorming's normal commit. Nothing council-related (member files) is ever staged.
+- `Applied:` — cluster -> the concrete edit made.
+- `Deferred:` — cluster -> where it belongs.
+- `Rejected:` — cluster -> one-line reason.
 
-Single pass — no automatic re-roast loop. The user can invoke this skill again after edits for another round.
+Hand this audit to brainstorming along with the now-final spec. brainstorming writes it into the **spec commit message body** (git-native, readable pre-squash) so it survives for finish-time revert visibility, then shows it to the user alongside the final spec at its one review gate. The user can revert any applied edit there — that gate, not this skill, is where ratification happens.
+
+### 5 — Clean up
+
+Re-run brainstorming's placeholder scan over the applied result. Remove the temp dir (`rm -rf` the `mktemp -d` path). Nothing council-related (member files) is ever staged.
+
+Single pass — no automatic re-roast loop. The user can invoke this skill again after the gate for another round.
 
 ## Red flags — STOP
 
 - Running the council when `piGauntlet.specCouncil.members` is absent or empty (brainstorming owns the gate and should have used the worker fallback).
 - Reading member critique files yourself instead of routing them through the chair.
 - Writing member files to a relative path (they land in the worktree).
-- Auto-applying findings without the user gate.
+- Applying edits without surfacing the audit at brainstorming's gate — apply-before-the-gate is correct; apply-without-the-gate is not.
+- Suppressing a finding instead of routing it to applied, deferred, or rejected in the audit.
 - Surfacing member-vs-member disagreements to the user instead of letting the chair adjudicate.
 - Editing anything other than the spec under `doc/specs/`.
 

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

@@ -190,9 +190,9 @@ For the fan-out + worktree + patch-integration + conflict mechanics, see `dispat
 
 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. **Run the whole-diff code review.** Dispatch `/skill:requesting-code-review` against the worktree's full diff vs `main` (already covered in [The Process](#the-process) step "After all tasks"). Address Critical and Moderate findings before handoff. (Consumers wanting an in-flow project-specific audit re-add it as an explicit step in `.pi/gauntlet-overrides.md`, or run `/self-audit` manually.)
-2. **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. On `GAPS`, do not auto-fix or auto-proceed: run the remediation loop in `verification-before-completion/reference/conformance-check.md` "When the check finds gaps" (disposition menu → isolated fix waves → bounded delta re-audit, capped by `gauntlet_setting({ key: "closureReview" }).maxFixRounds`). Only when the verdict is `CONFORMS` (or every gap is dispositioned) call `phase_tracker({ action: "complete", phase: "verify" })`.
-3. Summarize what was implemented (tasks completed, files changed, test counts, code-review verdict). Give the closing loop its **own section** — `Closure / conformance: CONFORMS` (or `GAPS` with each gap and its disposition) — so the user sees intent-fidelity as a first-class line before any finishing decision, not buried in the review verdict.
-4. **Proceed to finishing — no confirmation prompt.** When the verdict is `CONFORMS` (or every gap is dispositioned), 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. Open gaps are already owned by step 2, so nothing is left to decide here. 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.
+2. **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. On `GAPS`, this skill does not choose a disposition or stop for one: `conformance-check.md` "When the check finds gaps" auto-runs the fix loop for every `recommended: fix` gap (no menu, no stop) and carries any `accept`/`rescope`/`UNAUTHORIZED` gap OPEN to the finish gate — follow that file for the partition rule and the fix-loop mechanics; do not reimplement them here. The fix loop may drive `plan_tracker` to surface fix-wave progress (task name = `Gn: <short desc>`, lifecycle `pending → in_progress → complete` per gap); it never calls `phase_tracker`. Call `phase_tracker({ action: "complete", phase: "verify" })` once every gap is either fixed (`CONFORMS`) or carried OPEN as a deferred `accept`/`rescope`/`UNAUTHORIZED` gap — escalation (fix-round cap reached with an open `fix` gap) is the sole non-completing terminal state; on escalation, do not complete verify, stop and report.
+3. Summarize what was implemented (tasks completed, files changed, test counts, code-review verdict). Emit the `## Closure / conformance` block verbatim per the schema defined in `verification-before-completion/reference/conformance-check.md` (do not rename or reformat its fields); `finishing-a-development-branch` Step 3.5 consumes it by those exact field names.
+4. **Proceed to finishing — no confirmation prompt.** Once verify is complete per step 2'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 gaps are resolved at Step 3.5 of that skill via the `## Closure / conformance` block from step 3 — nothing is left to decide here. 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.
 
 ## Red Flags — STOP
 
@@ -215,7 +215,7 @@ For the fan-out + worktree + patch-integration + conflict mechanics, see `dispat
 - `/skill:using-git-worktrees` — set up isolation first (small changes can branch in place with user approval)
 - `/skill:writing-plans` — creates the plan this skill executes
 - `/skill:requesting-code-review` — review template for reviewer subagents
-- `/skill:finishing-a-development-branch` — invoked automatically once the conformance verdict is `CONFORMS` (or all gaps dispositioned)
+- `/skill:finishing-a-development-branch` — invoked automatically once every gap is fixed (`CONFORMS`) or carried open
 
 **Subagents follow by default:**
 

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

@@ -57,7 +57,7 @@ Skip any step = lying, not verifying
 | Regression test works | Red-green cycle verified | Test passes once |
 | Agent completed | VCS diff shows changes | Agent reports "success" |
 | Requirements met | Line-by-line checklist | Tests passing |
-| Intent delivered (loop closed) | Fresh reviewer audits code+doc vs origin spec + prompt (`reference/conformance-check.md`) | Plan-vs-code review, tests passing |
+| Intent delivered (loop closed) | Fresh reviewer audits code+doc vs origin spec + prompt; verify completes when every gap is `CONFORMS` or carried-open as a deferred `accept`/`rescope`/`UNAUTHORIZED` gap - the sole non-completing terminal state is escalation (cap reached with an unresolved `fix` gap). Partition, fix loop, and `## Closure / conformance` schema: `reference/conformance-check.md` | Plan-vs-code review, tests passing |
 
 ## Rationalization Prevention
 

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

@@ -89,132 +89,145 @@ The reviewer **proposes, it does not dispose.** It emits structured gap blocks
 the verify gate) drives disposition, fixes, and re-audit. The reviewer never edits,
 dispatches, or re-audits itself.
 
-### CONFORMS
-
-Record the verdict in the completion summary's closure section and proceed.
-
-### GAPS — disposition menu
-
-Do **not** auto-proceed and do **not** auto-fix. Render the enumerated gap list —
-each as `Gn [VERDICT] origin — remediation (recommended: fix|accept|rescope)` — then
-a numbered prompt (a chat turn cannot express a bare keystroke):
+### Disposition — verdict-then-`recommended` partition, no menu
+
+Render the enumerated gap list — each as `Gn [VERDICT] origin — remediation
+(recommended: fix|accept|rescope)` — then partition and act, in this exact order.
+No prompt, no menu: this partition is deterministic and exhaustive.
+
+1. **Verdict `CONFORMS`** (no gaps) → record the verdict in the completion
+   summary's closure section and proceed. No loop.
+2. **Any gap is `UNAUTHORIZED`** → that gap **always** defers to the finish gate,
+   regardless of its `recommended` value. Never auto-remove or auto-accept
+   unrequested code here.
+3. **Every remaining `PARTIAL`/`MISSING`/`DRIFTED` gap**:
+   - `recommended: fix` → auto-run the fix loop below — **unless `maxFixRounds:
+     0`**, in which case carry the gap **OPEN** (see the fix loop's
+     `maxFixRounds: 0` note).
+   - `recommended: accept` or `recommended: rescope` → carry the gap **OPEN**,
+     deferred to the finish gate. Do not apply a spec edit here — the finish
+     gate owns disposition of deferred gaps.
+
+So the fast path (all gaps `recommended: fix`, none `UNAUTHORIZED`, cap > 0)
+therefore auto-runs the fix loop with no menu, stop, or confirmation; any other
+mix carries the `accept`/`rescope`/`UNAUTHORIZED` gaps OPEN while the `fix` gaps
+run. Record every gap's outcome (`CONFORMS`-closed or carried OPEN) in the
+`## Closure / conformance` block (schema below).
+
+**Re-partition after every re-audit.** A re-audit can introduce `Gn+1` or flip a
+carried gap's `recommended`. Re-run steps 1-3 above over the **full current
+open-gap set** each time the reviewer returns a report — never reuse a stale
+partition from an earlier round.
+
+### Fix loop — SDD Parallel-Wave mirror, per round
+
+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.
+
+**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
+normal repo (`GIT_DIR == GIT_COMMON`) or detached HEAD, there is no such HEAD:
+skip this loop, carry every `fix` gap OPEN, and resolve manually at finish
+(`accept`/`rescope`/manual fix-in-place only).
+
+Per round:
+
+1. **`plan_tracker` init** with the round's gaps as tasks. Wave-prefix tasks
+   when the reviewer's `Parallel-safe:` line marks a `conflicts` pair (file OR
+   `touched-resources` overlap) — that pair runs in separate serial waves;
+   `disjoint` gaps share one wave. Lifecycle per gap: `pending` →
+   `in_progress` → `complete`. This re-init **replaces** the implement phase's
+   completed task list in the singleton widget — state-safe, since
+   `phase-tracker.ts` `applyPlanActivity` only auto-completes `implement`
+   while it is `in_progress`; the widget now shows fix-wave progress during
+   verify.
+2. **Per gap** (task → `in_progress`): dispatch `implementer` (fresh context,
+   `worktree: true`, `cwd` = the conformance worktree, `touched-files` from the
+   gap block as an explicit ownership boundary) → dispatch `spec-reviewer` on
+   the gap-block reference contract below → task → `complete`.
+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 →
+   re-run one agent sequentially with the other's integrated changes as
+   context; semantic conflict (applies clean, suite fails) → re-run the
+   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).
+6. **Re-audit**: re-dispatch `conformance-reviewer` 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
+   fix diff. Inject `model:` call-site per `gauntlet_setting({ key:
+   "closureReview" }).model` — same mechanism as the initial audit; omit
+   `model:` when it is `undefined` to inherit the parent's model. The
+   phase-tracker closure guard blocks a dispatch that omits `model:` when
+   `closureReview.model` is set, and warns (non-blocking) on one whose model
+   differs.
+7. **Converge or continue**: verdict `CONFORMS` → record it, done. Open gaps
+   within the cap → re-partition (per the rule above) and start the next
+   round. Cap (`gauntlet_setting({ key: "closureReview" }).maxFixRounds`,
+   default `2`, floors negatives at `0`, coerces non-integers to `2`) reached
+   with an open `fix` gap → **escalate to the human** with the per-gap
+   round-by-round verdict trail. Escalation is the sole non-completing
+   terminal state — no silent re-loop, no auto-ship.
+
+Commit each per-gap fix with the message **`conformance fix Gn`** (durable,
+`git log`-readable pre-squash) so the finish gate and any revert can identify
+auto-applied fixes.
+
+**`maxFixRounds: 0`**: skip this loop entirely. Every `recommended: fix` gap
+becomes carried OPEN to the finish gate instead of auto-running — the user
+opted out of auto-fix, so treat `fix` gaps like any other deferred gap. This
+differs from a cap > 0 that is *exhausted*: that case escalates mid-verify
+because the loop tried and could not converge.
+
+### `spec-reviewer` gap-block reference contract
+
+Per-gap `spec-reviewer` in step 2 above is a **pre-integration mechanical
+check**, distinct from the round-level re-audit in step 6 (which still
+references the *origin* — spec + original prompt — unchanged). Frame the
+per-gap dispatch against the **gap block**, not a plan task:
+
+- **Requirement** = the gap's `origin` + `remediation` (what must be true
+  after the fix).
+- **Closure proof** = the patch satisfies that requirement within the gap's
+  `touched-files` — nothing missing, nothing extra.
+- **Output** = `spec-reviewer`'s normal MATCH/DRIFT verdict, referenced to the
+  gap block instead of a plan task.
+
+This is a task-framing contract in the dispatch, not a new persona.
+
+## Closure / conformance
+
+Emit this block in the verify completion summary. It is the durable handoff
+`finishing-a-development-branch` Step 3.5 consumes — parseable even if session
+context was pruned. Verify completes when every gap is either fixed
+(`CONFORMS`) or carried OPEN as a deferred `accept`/`rescope`/`UNAUTHORIZED`
+gap; escalation (cap reached with an open `fix` gap) is the one
+non-completing terminal state.
+
+For each carried-open gap:
 
 ```
-[1] apply all recommended dispositions
-[2] review per-gap (override fix/accept/rescope before applying)
+Gn: <verdict> — recommended: <fix|accept|rescope> — touched-files: <paths>
+  round history: R1 <verdict/action>, R2 <verdict/action>, ...
 ```
 
-`[1]` applies each gap's `recommended` disposition, **except** any gap whose
-`recommended` is `accept` or `rescope`: list those and require an explicit confirming
-reply before their spec edits land (accept/rescope rewrite the origin — never on the
-unconfirmed fast path). `[2]` prompts a per-gap override, then applies.
-
-Disposition semantics:
-
-- `fix` — dispatch a remediation unit (below), then re-audit. For an `UNAUTHORIZED`
-  gap, "fix" = **remove** the unrequested code.
-- `accept` — the **main session** (not a subagent) folds the deviation into the spec as
-  a dated decision (template below). For `UNAUTHORIZED`, accept = keep the behavior,
-  document it as intended.
-- `rescope` — the main session records the requirement in the spec as an explicit
-  out-of-scope / deferred item, dated.
+Then a single flat revert index of **every** `conformance fix Gn` commit the fix
+loop produced this run — including gaps that later converged to `CONFORMS`
+(a closed gap has no block above, so its commit lives only here) — since the
+finish gate's revert option needs them all:
 
-Dated-decision template (append to the spec's decisions/deviations section):
-
-```
-- YYYY-MM-DD accept|rescope Gn: <requirement/behavior> — <one-line rationale> (conformance gate)
 ```
-
-**Commit accept/rescope spec edits BEFORE any fix wave dispatches:** pi-cohort
-rejects a dirty tree on a `worktree: true` dispatch, and the re-audit must read the
-amended spec. If a round has only accept/rescope and no `fix`, the edits land, the
-verdict is recorded, and no re-audit runs.
-
-### Fix dispatch — reuse dispatching-parallel-agents mechanics
-
-Fixes reuse the `dispatching-parallel-agents` fan-out primitive. Invoke **no**
-`phase_tracker` / `plan_tracker` calls and do **not** enter `subagent-driven-development`
-Parallel-Wave Mode (that mode opens with `phase_tracker({ phase: "implement" })`, which
-errors while the verify phase is `in_progress`, and needs a plan the fix loop lacks).
-
-**Precondition — worktree required.** Fix-via-dispatch needs a worktree HEAD to branch
-from. On the ad-hoc `finishing-a-development-branch` paths that run in a normal repo
-(`GIT_DIR == GIT_COMMON`) or detached HEAD, there is no such HEAD: the menu offers
-`accept` / `rescope` and **manual fix-in-place** only; unresolved gaps route to escalation.
-The loop below applies only when the gate already runs inside a worktree.
-
-**Wave grouping** comes from the reviewer's `Parallel-safe:` line: `disjoint` gaps form
-one parallel wave; any `conflicts` pair splits into separate serial waves. A pair conflicts
-on **file OR runtime-resource** overlap - two gaps whose fixes touch disjoint files but whose
-verification shares a `touched-resources` entry (DB/schema, port, fixture, external service,
-shared temp path) are **not** parallel-safe and run in separate serial waves, identical to
-planned-execution wave grouping. This is why the reviewer certifies both axes.
-
-**Dispatch shape** (mirrors `dispatching-parallel-agents`):
-
-```ts
-subagent({
-  context: "fresh",
-  worktree: true,
-  cwd: "<abs worktree path, from git rev-parse --show-toplevel>",
-  tasks: [
-    { agent: "implementer",
-      task: "Close conformance gap G1. Origin requirement: <origin>. What's missing: " +
-            "<remediation>. Satisfy the requirement; do not expand scope. " +
-            "Ownership boundary — modify only: <touched-files>." },
-    // one task per disjoint gap in this wave
-  ],
-})
+auto-applied fix commits: <Gn: SHA>, <Gm: SHA>, ... (revertable)
 ```
 
-- Unit = `implementer`, fresh context, `worktree: true`, `cwd` = the conformance
-  worktree. Pass `touched-files` as an explicit ownership boundary.
-- **Integrate** serially via `git apply` back onto the worktree HEAD — the fix ships in
-  the same worktree and rides `finishing-a-development-branch`'s squash. No new merge machinery.
-- **Failure handling is inherited verbatim** from `dispatching-parallel-agents`
-  "Review and Integrate": textual conflict → re-run one agent sequentially with the
-  other's integrated changes as context; semantic conflict (applies clean, suite fails)
-  → re-run the 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.
-- **`code-reviewer` over the integrated fix delta, once per round** (not per gap) — gap
-  fixes land after the branch's final code review, so review the round's cumulative diff.
-- **`spec-reviewer` is excluded** — plan-vs-code is the wrong reference point; the re-audit
-  checks fixes against the origin.
-- **Test gate** on the integrated tree after the round's waves apply, using the project's
-  canonical test command. A failure re-enters the failure-handling rules above.
-
-One round = dispatch waves → serial integrate → `code-reviewer` on round delta → test
-gate → re-audit.
-
-### Delta re-audit + cap
-
-Re-dispatch `conformance-reviewer` for a delta-scoped re-audit. Pass:
-
-- the **full prior conformance report** — every row including DELIVERED rows and their
-  `evidence` `file:line` (needed for the regression guard), not just gap IDs;
-- the **fix diff** for the round.
-
-The reviewer (not the orchestrator) computes the regression intersection: it re-verifies
-the gaps marked `fix` this round **plus** any previously-DELIVERED requirement whose
-`evidence` file appears in the fix diff. It reuses `G1..Gn`, marking each `DELIVERED`,
-still-open with its prior verdict, or introducing `Gn+1`.
-
-- The re-audit dispatch carries the **same call-site `model:` injection** as the initial
-  audit (when `piGauntlet.closureReview.model` is set, the phase-tracker closure guard
-  blocks a `conformance-reviewer` dispatch that omits `model:`, and warns — non-blocking —
-  on one whose model differs from the configured value).
-- New or still-open gaps within the cap re-enter the menu above.
-- **Cap: `gauntlet_setting({ key: "closureReview" }).maxFixRounds`** (the tool applies the
-  default `2`, floors negatives at `0`, and coerces non-integers to `2`). `0` = audit-only:
-  `GAPS` renders an accept/rescope-only menu and any unresolved gap escalates instead of
-  dispatching a fix.
-- **On non-convergence** (cap reached with open gaps): **escalate to human** with the
-  per-gap round-by-round verdict trail. No silent re-loop, no auto-ship.
-
-No completion claim stands over a gap that is neither fixed, accepted, nor rescoped.
-"Surface, don't auto-fix": the orchestrator presents options, the user decides.
-
 ## Checklist
 
 - [ ] Located canonical requirements (spec → prompt → ticket fallback)