pi-gauntlet 4.4.0 → 4.4.2

package/CHANGELOG.md

@@ -1,5 +1,58 @@
 # Changelog
 
+## v4.4.2 - 2026-07-15
+
+Condense the finish-time conformance disposition gate to a dense, human-readable
+decision list - the corrective second pass over v4.4.1's disposition work, which
+delivered the right behavior but bloated the render and the freshness protocol.
+
+- **Finish gate (`finishing-a-development-branch`):** carried-open conformance
+  findings now render as a dense one-line-per-decision list - each line carries a
+  plain-language title, the unresolved point, its question, and an inline recommended
+  choice - with a two-option reply (`1` = every recommendation; `2:` =
+  recommended-except comma-separated `<handle>=<choice>` overrides). Replaces the
+  terse `Gn` tokens and the flat D1-D5 per-gap menu. Single-concern gaps show no
+  `/Cn` symbol; `UNAUTHORIZED` items note availability deviations inline; the
+  zero-gap path still goes straight to branch options with no sign-off.
+- **Freshness (`verification-before-completion/reference/conformance-check.md`,
+  `finishing-a-development-branch`, `subagent-driven-development`):** the four-field
+  audit-identity/hash protocol (duplicated across three files) collapses to a
+  `status`/`audited-base` sentinel plus a two-command working-tree drift check;
+  any change or doubt re-audits. The durable `## Closure / conformance` handoff
+  header drops `audited-spec-path`/`audited-diff-hash`/`audited-spec-hash`.
+- **De-duplication:** the disposition-availability table, the `UNAUTHORIZED`
+  question, the `recommended: none` preflight, and the fix loop now live only in
+  `conformance-check.md`; the finish gate and SDD consume them by link.
+
+## 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. 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. **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? Compatible executable recommendations auto-fix first; anything still open renders as a dense one-line-per-decision list with each recommended choice inline. Reply `1` to accept all recommendations or `2:` with per-item overrides; a current `CONFORMS` / no-concerns handoff goes straight to branch options with no extra sign-off. |
 | 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.2",
   "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,23 +70,105 @@ 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 disposition gate**, not a surface-only notice. The user is about to choose how to ship; every carried-open decision 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).
+`verification-before-completion/reference/conformance-check.md` is **canonical** for the durable handoff schema, concern-decomposition rules, the single disposition-availability table, the `UNAUTHORIZED` question text, the `recommended: none` preflight, the freshness rule, and the concern-scoped fix projection. This step owns only **render, response, and execute-order** and consumes the rest by link - it does not restate the availability table, the `UNAUTHORIZED` question, or the preflight prose.
 
-Present it as a distinct line the user reads before choosing:
+**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 that reference - it owns the audit-time input rule (stage/commit untracked deliverables before auditing). Closing the loop is cheap relative to shipping unverified intent. Route the raw reviewer verdict through the reference's canonical pipeline (gap/concern partition, auto-fix where eligible, concern decomposition, emission of a durable `## Closure / conformance` block), then consume that block through the branching below exactly as a carried handoff.
+
+**Freshness precondition - before any verdict branch, including `CONFORMS`.** The durable block opens with a two-line sentinel: `status: CONFORMS (0 open)` or `status: GAPS (N open)`, then `audited-base: <full HEAD SHA at audit time>`. Read the sentinel, then apply the reference's freshness rule (its `## Closure / conformance` block is the single source): compare `audited-base` to the current working tree; any change, doubt, missing/mismatched sentinel, legacy terse row, or malformed structured reviewer block triggers a fresh audit and replacement of the closure block. Never infer `CONFORMS` from the absence of bullets. Only a clean, valid `status: CONFORMS (0 open)` handoff enters the zero-gap fast path.
+
+**Zero-gap fast path:** print exactly
+
+```
+Closure / conformance: CONFORMS
+```
+
+then continue directly to Step 4. No approval prompt, no menu, no shared options line, no sign-off. If the run auto-applied fixes, surface the flat `auto-applied fix commits: <Gn: SHA>, ...` index from the durable block as **one informational, non-blocking line** with a one-line revert offer (see "Revert semantics") - a gap that auto-converged mid-verify has no bullet, so this index is the only place its fix commit stays revertable. Do not wait for acknowledgment.
+
+**Carried-open render (dense).** Read the `## Closure / conformance` block. Render a header with the decision count, one bullet per decision unit (a gap by default; a `Gn/Cn` concern only where the reference split it), then the shared options line, then the recommended-set reply. Never show durable-card internals (ownership, evidence tokens, identity, hashes) in the render.
+
+Each bullet:
+
+`* <handle> - <plain title>: <what's unresolved, one clause>. <short question> Recommended: <choice> (<one-clause why>).`
+
+- `<handle>` leads the bullet and is a short unique human word derived from the title (`Cache coverage` -> `cache`); on collision append a digit. It is the token option 2 targets. When a gap split and no clean word fits, use the bare `Gn/Cn`; a single-concern gap uses its gap ID `Gn`.
+- The shared options line sits below the bullets: `Other options per item: fix-now / accept / rescope / follow-up / custom`, listing the options **generally available across items**. When a specific item's availability deviates - an option unavailable for it, or an `UNAUTHORIZED` item whose `rescope` is unavailable and whose `fix-now` means removal - note that deviation as a short parenthetical on **that item's bullet** (one clause, not a block), e.g. `(rescope N/A: scope creep)`. The shared line appears **only in the carried-open render**, never in the zero-gap path. Full per-option effects only on request, or when option 2 targets an unclear choice.
+- Group items under one recommended line only when they share a disposition and rationale; each grouped handle repeats its title.
+- Availability per concern comes from the reference's single availability table - apply it against current context (worktree state, `maxFixRounds`, ownership, resource accessibility), do not restate it. `UNAUTHORIZED` bullets ask the reference's question verbatim (`Should this unrequested behavior become part of the current workflow?`); `rescope-into-spec` is shown **unavailable** (not dropped) and `fix-now` means **removal** of the unrequested code.
+- `revert conformance fix Gn`, when the gap has an auto-applied fix, renders on the shared options line as a **separate one-off action** - never inside a bullet's recommendation and never in the option-2 list. Name the parent gap and warn that revert undoes the entire gap-level commit (see "Revert semantics").
+
+Representative carried-open render (multi-concern gap split to `e2e`; single-concern gap `cache`; `UNAUTHORIZED` gap `auth`):
+
+```
+Conformance: 3 decisions needed before shipping.
+
+* e2e - Source-image E2E validation: not run; blocked (HYDRA1.png, HTTP 401).
+  Still in scope for this branch? Recommended: rescope (defer until image available) (fix-now N/A: needs HYDRA1.png).
+* cache - Cache coverage: implemented but the spec is silent on it.
+  In scope? Recommended: accept into spec (behavior is intentional).
+* auth - Unrequested admin bypass: adds an unlisted route. Should this unrequested behavior become part of the current workflow? Recommended: fix-now = remove it (rescope N/A: scope creep).
+
+Other options per item: fix-now / accept / rescope / follow-up / custom.
+
+1. Go with recommended
+2. Recommended except <handle>=<choice>   e.g. "2: cache=follow-up"
+```
+
+A single-concern render is identical minus the split: one bullet whose handle is the gap ID or word, no sibling.
+
+#### Response grammar
+
+```
+1                                  -> apply every recommendation
+2: cache=follow-up
+2: e2e=custom(open ticket after image lands), cache=follow-up
+```
+
+- `1` (or `apply recommended`) applies all recommendations.
+- `2:` takes a comma-separated override list, each `<handle>=<choice>`; omitted items keep their recommendation. A handle may appear at most once (repeat = invalid).
+- `custom(<concrete effect>)` supplies an inline effect. Manual fix-in-place is expressed only as `custom(...)` where isolated `fix-now` is unavailable.
+- `recommended: none` items follow the reference's preflight (linked, not restated): the item needs a `<handle>=custom(...)` decision, and option 1 is withheld until every open item has an executable recommendation; after the custom decision the menu re-renders for the remainder.
+- `revert conformance fix Gn` is a valid standalone reply, mutually exclusive with `1` and `2:`; it never appears inside a `2:` override list.
+- Invalid handle or choice -> focused reprompt naming only that item, retaining every valid pick and never reopening the gate. Unknown token: list the valid titled handles. Known item, bad choice: repeat its title + its available choices.
+
+#### Execute order
+
+Take **no** disposition action before the reply. Then, once, in order:
+
+1. **Normalize** every `custom(...)` into explicit operations; classify state-changing (edits code or spec) vs not. Clarify only an ambiguous or unexecutable effect.
+2. **Commit spec edits** (`accept-into-spec`, `rescope-into-spec`, state-changing spec `custom`) - the main session edits the spec directly, before any fix dispatch (a dirty tree rejects `worktree: true`, and the re-audit must read the amended spec).
+3. **Re-audit if step 2 changed the spec**; regenerate the inventory and re-render if it changed. Project `fix-now` only from the refreshed inventory.
+4. **fix-now + code-changing custom:** project the selected concerns per gap into the reference's concern-scoped fix contract (excluding accepted/rescoped/followed-up siblings); run the reference "Fix loop" (unchanged - do not re-describe it). A code-changing `custom` runs the project's tests + `code-reviewer` on its delta before proceeding. Re-run Step 1's canonical tests.
+5. **Re-audit after all state-changing work;** obtain fresh decisions **only if** the refreshed inventory differs from the approved one, else proceed.
+6. **follow-up** from the current inventory: create the item via the project's issue-tracker convention (`.pi/gauntlet-overrides.md`), record the ticket ID/URL; on failure keep the concern open.
+7. **Non-state-changing custom:** execute and record the result.
+8. **revert** (`revert conformance fix Gn`): light-revert the indexed commit, re-run Step 1's canonical tests; on failure stop; on pass re-audit and regenerate.
+9. Re-enter Step 3.5 with the re-audited block if any concern remains open.
+
+Record every final disposition with its **stable ID** as `Gn/Cn - <title>: <disposition>` (or `Gn - <title>: <disposition>` for a single-concern gap) - ticket ID/URL for `follow-up`, result for `custom`; never relabel a `custom` result as a recommendation. This durable record is the machine/audit surface; the interactive render stays handle-based. Then continue to Step 4:
 
 ```
 Closure / conformance: CONFORMS
-  (or: GAPS — <n> open)
-  - <gap> → proposed remediation: <one line>   [if any open]
+  (or: GAPS resolved - G1/C1 - Source-image E2E validation: rescope-into-spec;
+       G2 - Cache coverage: follow-up (PROJ-123); ...)
 ```
 
-Then continue to Step 4.
+No auto-proceed: every carried-open decision needs an explicit disposition before Step 4 renders.
+
+### 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
 
@@ -300,7 +382,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. 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 name = `Gn: <short desc>`, lifecycle `pending → in_progress → complete` per gap); 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.
+3. 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.
+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 concerns are resolved there per concern via the `## Closure / conformance` block from step 3. 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 only on a current `CONFORMS` result or a current durable carried-open closure inventory permitted by `reference/conformance-check.md` (including declared-precondition-unavailable `recommended: fix` gaps). A started positive-cap fix loop that blocks, fails, or exhausts rounds with an open `fix` gap is escalation, not completion. | Plan-vs-code review, tests passing |
 
 ## Rationalization Prevention
 

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

@@ -89,131 +89,378 @@ 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.
+### 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 a declared
+     fix-loop precondition is unavailable** (`maxFixRounds: 0`, or no eligible
+     named-branch worktree), in which case carry the gap **OPEN** (see the fix
+     loop's precondition and `maxFixRounds: 0` notes).
+   - `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,
+eligible named-branch worktree) 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 it at finish via the
+canonical Disposition catalog and availability table below. `fix-now` is
+unavailable there; any other disposition is offered only when its table
+prerequisites hold.
+
+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.
+
+## Concern decomposition
+
+The main verification orchestrator — **not** `conformance-reviewer` — decomposes
+each carried-open gap into concerns when it writes the completion summary. A
+**gap** is the reviewer's overall finding; a **concern** (`Gn/Cn`) is one
+consequence within it that could reasonably receive a *different* disposition.
+Observations that necessarily move together stay one concern.
+
+The orchestrator reasons from:
+
+- The final reviewer coverage row and structured gap block.
+- The origin spec and original prompt already supplied to verification.
+- Session-observed blockers, prerequisite checks, and fix-loop outcomes.
+- The round history and current touched-file/resource ownership.
+
+Per gap, apply these rules **in order**:
+
+1. Extract atomic unmet clauses and remediation actions from `origin`,
+   `evidence`, and `remediation`. Add a session-observed blocker **only** when a
+   tool result or fix-loop outcome established it.
+2. **Split** two points when either could be fixed, accepted, rescoped, or
+   followed up without imposing the same disposition on the other.
+3. **Keep together** when one action is meaningful only with the other, or no
+   different disposition could be executed independently.
+4. Map **every** unmet clause, remediation action, and established blocker to at
+   least one concern. Do **not** add a requirement absent from the origin or
+   prompt — invent nothing.
+5. Order concerns by first appearance in the origin/remediation and assign
+   `C1`, `C2`, and so on (source order).
+
+A valid decomposition has no omitted source point, no invented requirement or
+evidence, and a concern-scoped remediation plus ownership estimate for every
+`fix-now` candidate. Shared evidence may appear in multiple concerns. When the
+source cannot support a safe split, the fallback is **one indivisible `Gn/C1`**
+concern carrying the complete gap and the known blocker; decomposition never
+blocks on obtaining richer prose from the unchanged reviewer.
+
+Field derivation is explicit: `title` and `unresolved` summarize the unmet
+clause; `origin` narrows the gap `origin` to this concern's specific clause
+without inventing a new requirement; `remediation` states the concern-scoped
+remediation action drawn from the gap `remediation`; `impact` states the
+consequence already implied by the origin requirement; `evidence` copies
+reviewer evidence plus verified session observations;
+`touched-files`/`touched-resources` narrow the gap ownership where supported,
+otherwise `unknown`/`none`. For an `UNAUTHORIZED` concern there is no origin
+requirement to narrow: keep `origin: none (scope creep)` verbatim — never invent
+an origin clause; derive `unresolved` from the reviewer's `evidence`/`remediation`
+as a plain description of the unrequested behavior; and derive `impact` from the
+consequence of retaining, removing, or ratifying that behavior, not from an origin
+requirement. These per-concern fields persist the exact contract
+the concern-scoped fix projection consumes after pruning. **`evidence: absent`
+is an unmet-delivery fact, not
+an external blocker** — never relabel missing implementation evidence as a
+blocker. A malformed structured reviewer gap block — missing its stable `Gn`
+label or any required field (`verdict`, `origin`, `evidence`, `remediation`,
+`touched-files`, `touched-resources`, `recommended`) — triggers a **fresh
+audit**; a complete structured reviewer gap block does not — the orchestrator
+decomposes it or emits the indivisible fallback.
+
+## Disposition catalog and availability
+
+Each concern lists **every** supported disposition, its concrete effect, and
+current availability. This table is the single availability contract, referenced
+by both this verify gate and `finishing-a-development-branch`:
+
+|Disposition|Ordinary gap effect|`UNAUTHORIZED` effect|Available when|
+|---|---|---|---|
+|`fix-now`|Complete missing implementation or validation.|Remove the unrequested code or behavior.|Named-branch worktree; `maxFixRounds > 0`; concern ownership is known; every required local/external resource is accessible.|
+|`accept-into-spec`|Ratify intentional implemented behavior when the written contract is stale.|Ratify the unrequested behavior as approved scope.|A writable spec exists and there is concrete behavior to ratify.|
+|`rescope-into-spec`|Explicitly remove or defer the origin requirement from this workflow.|Unavailable: scope creep has no origin requirement to defer.|The verdict is not `UNAUTHORIZED` and a writable spec exists.|
+|`follow-up`|Keep the concern valid but transfer it to separately owned work.|Transfer a separately valid decision or removal task.|The concern can stand alone and the project defines an executable issue-tracker convention. Without one, mark unavailable and direct the user to `custom` to name another durable owner.|
+|`custom`|Execute another user-defined disposition after its effect is clarified.|Same.|Always visible; executable only after the user supplies a concrete effect. It is never an automatic recommendation.|
+
+A failed condition leaves the disposition visible and names the exact missing
+prerequisite. `touched-files: unknown` makes `fix-now` unavailable until
+ownership is established. A normal checkout (`GIT_DIR == GIT_COMMON`) or detached
+HEAD cannot dispatch the isolated fix loop at all - it has no named-branch
+worktree to branch fixes from - so `fix-now` stays unavailable there regardless
+of ownership; resolve those concerns manually at finish. `maxFixRounds: 0`
+(audit-only) likewise leaves `fix-now` visible but unavailable — the user
+configured no auto-fix loop, and finish-time selection never bypasses or resets
+that cap; a concrete `custom`/manual-fix disposition remains possible. `UNAUTHORIZED` cards
+replace the primary question with
+`Should this unrequested behavior become part of the current workflow?`, so
+removal and ratification are not presented as missing-feature choices.
+
+Reviewer tokens map to executable concern recommendations:
+
+- `fix` maps to `fix-now`; for `UNAUTHORIZED`, that means removal.
+- `accept` maps to `accept-into-spec`; for `UNAUTHORIZED`, that means ratification.
+- `rescope` maps to `rescope-into-spec` and is invalid for `UNAUTHORIZED`.
+- `follow-up` may replace an unavailable `fix-now`/`rescope-into-spec` **only**
+  when the concern remains valid, has separate ownership, and the issue-tracker
+  action is executable.
+
+The orchestrator may choose another named disposition only when current evidence
+supports its stated effect. If no named executable disposition is available, the
+concern serializes `recommended: none` - the durable state for "no named
+executable choice exists" - and its `rationale` must name the exact missing
+prerequisites plus the concrete custom effect still required. `custom` is never
+auto-recommended, so `none` never silently resolves to `custom`.
+
+A concern with `recommended: none` is excluded from the recommended set. Before
+any exhaustive `Apply recommended set`, the finish gate asks for a targeted
+custom approval that supplies a concrete effect for that one concern (finishing
+owns the exact reply syntax - a per-item `custom(...)` decision - not an `apply
+recommended` variant). That reply approves only that concrete custom effect for
+that concern. Validate and normalize it immediately: if the effect is ambiguous or
+unexecutable, clarify and keep the concern open; if executable, record it as a
+**pending approved custom decision** and remove that concern from the still-open
+inventory used to build the recommended set. If other open concerns remain,
+render the exhaustive recommended set for them and visibly carry the pending
+approved custom decision through the existing action-order and freshness
+barriers; `apply recommended` approves only the remaining recommendations. If no
+other concerns remain, execute the approved custom directly through the existing
+mechanics. The final disposition record keeps this concern as a `custom` result;
+never relabel it as a model recommendation.
+
+**Never recommend an unavailable disposition or an unexecutable `custom`
+placeholder.**
+
+`revert` is a separate action, not a generic concern disposition. The commit
+index stays gap-granular (`conformance fix Gn`). A listed gap-level commit makes
+revert visible on every concern card under that gap, with an explicit warning
+that the **entire gap commit** is reverted. Existing light-revert semantics
+remain: revert the indexed commit, re-audit, and return to the decision gate
+only if a concern remains open.
+
+## 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 gap - `accept`/`rescope`/`UNAUTHORIZED`,
+or a `recommended: fix` gap carried open because a declared fix-loop precondition
+was unavailable so the loop never started (`maxFixRounds: 0`, or no eligible
+named-branch worktree - normal checkout / detached HEAD). Escalation - a started
+positive-cap loop that exhausted its rounds or blocked/failed with an open `fix`
+gap - is the one non-completing terminal state; the precondition-unavailable
+carried-open `fix` state is valid closure inventory, not escalation.
+
+### Handoff sentinel and freshness anchor - every handoff
+
+Every `## Closure / conformance` block - a `CONFORMS` no-card handoff and a
+carried-open GAPS handoff alike - **opens with a two-line sentinel** that lets
+the finish gate re-verify freshness after context pruning, with no session
+history:
+
+```text
+status: CONFORMS (0 open)      # or: status: GAPS (N open)
+audited-base: <full HEAD SHA at audit time>
+```
 
-### GAPS — disposition menu
+`N` = count of open concerns (decision units), matching the number of emitted
+concern cards. Record `audited-base` as the full 40-char HEAD SHA at audit time;
+never abbreviate. This block is the **single source** for the freshness rule;
+`finishing-a-development-branch` links here rather than restating it.
 
-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):
+**Freshness rule.** The audit-input rule requires deliverables committed before
+auditing, so `audited-base` captures the audited state; freshness compares that
+commit to the **current working tree**, not to HEAD (a commit-to-commit diff
+misses staged/unstaged edits when HEAD has not moved). Run two cheap commands:
 
+```bash
+ROOT=$(git rev-parse --show-toplevel)
+git -C "$ROOT" diff --stat <audited-base> -- .          # tracked changes since the audited commit (staged + unstaged)
+git -C "$ROOT" status --porcelain --untracked-files=all # new/untracked deliverables
 ```
-[1] apply all recommended dispositions
-[2] review per-gap (override fix/accept/rescope before applying)
-```
-
-`[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:
+Any output from either command, any doubt, a missing/mismatched sentinel, or any
+closure block not opening with the two-line sentinel above (e.g. a legacy
+`Gn: PARTIAL - recommended: ...` row) triggers a fresh audit - never infer
+`CONFORMS` from the absence of cards. This is a lightweight freshness check (two
+git commands, no hashing or identity fields).
+
+**Sentinel validation.** `status: CONFORMS` requires `N = 0` and **no** emitted
+concern cards; `status: GAPS` requires `N > 0` exactly matching the emitted card
+count (`Gn/Cn` blocks), not merely gap headers. A mismatch is stale -> re-audit.
+
+**Audit-time input rule.** Stage or commit untracked deliverables before
+auditing, since `git diff <base> -- .` omits untracked files from the reviewer
+payload.
+
+For each carried-open gap, emit a durable gap header plus one card per concern
+(decomposition and derivation rules above). In rendered cards, recommendation
+lists, clarification lists, and final disposition records, every user-facing
+identifier carries both its ID **and** title; bare `Gn`/`Cn` or grouped
+identifier lists without titles are prohibited. The only exceptions are the
+machine/interaction tokens the grammar requires: bare `Gn/Cn` inside typed
+response tokens, the literal `conformance fix Gn` commit/action identifiers, and
+the flat `auto-applied fix commits` index below. The surrounding prompt or list
+must map each token to its titled concern or gap before asking for input.
+
+```text
+G1 - Source-image validation is incomplete
+  verdict: PARTIAL
+  origin: <requirement source and clause>
+  evidence: <current file:line or observed state>
+  blocker: <specific blocker, or none>
+  touched-files: <paths or unknown>
+  touched-resources: <resources or none>
+  round history: R1 <verdict/action>, R2 <verdict/action>, ...
+
+  G1/C1 - End-to-end OCR output has not been validated
+    unresolved: <plain statement of the concern>
+    impact: <why it matters to the current workflow>
+    origin: <requirement source and clause, narrowed from the gap origin; or none (scope creep) for UNAUTHORIZED>
+    remediation: <concern-scoped remediation action>
+    evidence: <concern-specific evidence or blocker>
+    touched-files: <concern-scoped paths, narrowed from the gap; or unknown>
+    touched-resources: <concern-scoped resources, narrowed from the gap; or none>
+    available dispositions:
+      fix-now: <effect and availability>
+      accept-into-spec: <effect and availability>
+      rescope-into-spec: <effect and availability>
+      follow-up: <effect and availability>
+      custom: <effect and availability>
+    recommended: <available named disposition, or none>
+    rationale: <why this is the best current choice; for none, the missing prerequisites and the concrete custom effect required>
+```
 
-- `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.
+All concerns in a gap must be represented.
 
-Dated-decision template (append to the spec's decisions/deviations section):
+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 card above, so its commit lives only here) — since the
+finish gate's revert option needs them all:
 
 ```
-- 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.
+## Concern-scoped fix projection
+
+When the finish gate selects `fix-now` on some concerns of a gap, the fix loop
+above runs against a **projected** contract, not the original whole-gap block.
+For each parent gap with selected `fix-now` concerns, project only those
+concerns into one gap-scoped fix contract:
+
+- The parent gap ID.
+- The selected concern IDs and titles.
+- Their origin clauses, concern remediations, and evidence.
+- The **union** of the selected concerns' touched files/resources (ownership
+  boundary).
+
+Rescoped, accepted, and followed-up sibling concerns are **excluded** from the
+projection. The `implementer` and the pre-integration `spec-reviewer` receive
+this projected contract in place of the original whole-gap block.
+
+The projected task runs the existing full loop above: it retains the gap-level
+`conformance fix Gn` commit name, reruns the project's tests, runs
+`code-reviewer`, re-audits against the amended spec, and reenters the gate only
+if concerns remain. Gap-level revert stays available through the flat commit
+index. The gate records the final result by concern ID and title before showing
+branch integration options.
 
 ## Checklist