pi-gauntlet 7.1.2 → 7.2.1

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # Changelog
 
+## v7.2.1 - 2026-10-04
+
+### Changed
+
+- **brainstorming: challenges the ask instead of hardening it.** The scout's recon carries a `Framing:` finding (the strongest cited case that the request as framed is the wrong change, or `no objection`); the main loop verifies it without skipping premise verification and, with a cited concern and a named alternative, asks one framing question (`A) as framed`, `B) pivot: <alternative> - <reason>`, `C) smaller or none`) before any other question - otherwise it opens with a one-sentence holds-statement naming what was checked. Approaches must differ on a named axis, consider a reuse-only option and one that drops an assumption from the ask, and each ends with a `Pattern:` line cited to a repo location; a repo convention that is itself debt is named and is never the recommendation unless the user or an adopted ticket decision kept the ask as framed. New Red Flag for approaches that skip the framing question or the holds-statement. Spec council unchanged.
+
+## v7.2.0 - 2026-10-04
+
+### Changed
+
+- **spec-summarizer: briefing instead of decision log.** The persona emits a plain-language briefing of at most 300 words, written to about 220: entry paragraph, What changes, Approval risks, Done when, and Missing from the spec when external context is missing. It uses behavior and outcomes instead of code identifiers. The brainstorming gate drops the `under ~2%` degrade check; file-only transport, Read-last rendering, and the absolute size checks stay.
+- **Non-trivial skill, persona, and prompt edits create or extend an eval.** `AGENTS.md` requires samples and must-hold facts designed during brainstorming and a baseline run before the wording changes; existing targets gain a sample exercising the change. Trivial-edit exemptions stay unchanged, and deterministic code stays on `npm test`. `README.md` routes the procedure to `eval/README.md`.
+
+### Added
+
+- **Committed eval convention and spec-summarizer replay set.** `eval/README.md` defines fixed inputs, human-approved facts, independent reviewers with models supplied externally, and recorded baseline/candidate comparisons. `eval/spec-summarizer/` includes eight samples (two anonymized product specs) and first-run results against the persona pinned at `2166283`: 9,497 -> 2,235 words, 327 -> 0 backticked lines, and quality from `mixed` on 15/16 votes to `readable` or `briefing` on 12/16. Two of 47 facts were lost and reviewed; the comparison permits at most two losses across a run and lists each for human review. `eval/` stays outside the npm tarball; model calls are manual.
+- **Deterministic eval checks in CI.** `scripts/ci.mjs` runs `eval/spec-summarizer/run.test.mjs` and an `eval/` hygiene scan without model calls.
+
 ## v7.1.2 - 2026-10-04
 
 ### Changed

package/README.md

@@ -36,7 +36,7 @@ pi-gauntlet's only hard dependency is pi-cohort - every gate that dispatches a r
 Concretely, one change through the gauntlet:
 
 0. *(Optional)* Before there's even a spec, `/skill:shape-ticket` can create or repair a single tracker issue - shaping a raw ask into a Context/Problem/Idea/Acceptance Criteria ticket, gated by an AC integrity check, a cheap council roast, and one human-confirmed write that may include one optional gated Reporter-note comment. A failed roast is retried once, then surfaced inline at the gate if it fails again. It's a tool, not a phase: no worktree, no plan/phase tracker, runs from any repo state. It never activates on its own (`disable-model-invocation: true`) - invoke it explicitly. Similarly, `/skill:chase-bug` triages a raw bug report into an evidenced verdict - and can hand off to shape-ticket, brainstorming, or a bounded hotfix - before any spec exists.
-1. Opt in with `/skill:brainstorming` and describe the change. The command is the reliable discovery-and-entry path; explicit prose requesting brainstorming/the gauntlet also supplies consent when the skill is already loaded or an available instruction or route identifies it. An ordinary implementation request or an agent recommendation is not consent. **`brainstorming`** sets up an isolated worktree, explores the codebase, and turns your description into a written spec; when the run starts from a ticket, the spec carries the ticket's acceptance criteria verbatim, each with a disposition (`in-scope`, `deviates:`, `deferred:`, `venue:`), the conformance gate checks the in-scope ones, and `/skill:check-delivery` verifies `venue:` rows after deploy. A multi-model critique runs on it automatically. If the spec replaces a known prior spec, brainstorming marks the predecessor with a `> **Superseded by:**` banner under its title (default format, syntax overridable via `.pi/gauntlet-overrides.md`; candidates come from brainstorming's scout recon, never a mechanical sweep). **You read and approve the spec - human gate 1.** No implementation code exists yet.
+1. Opt in with `/skill:brainstorming` and describe the change. The command is the reliable discovery-and-entry path; explicit prose requesting brainstorming/the gauntlet also supplies consent when the skill is already loaded or an available instruction or route identifies it. An ordinary implementation request or an agent recommendation is not consent. **`brainstorming`** sets up an isolated worktree, explores the codebase, and turns your description into a written spec - when its recon finds a cited case that the ask is the wrong change (misdiagnosed, wrong-sized, already solved, a band-aid, or cutting across a sound pattern - including a repo convention that is itself debt) and can name the alternative, question one is a framing question (`as framed`, `pivot: <alternative>`, or `smaller or none`); otherwise it opens with one sentence naming what it checked, and every approach it proposes ends with a `Pattern:` line naming what it follows or cuts across; when the run starts from a ticket, the spec carries the ticket's acceptance criteria verbatim, each with a disposition (`in-scope`, `deviates:`, `deferred:`, `venue:`), the conformance gate checks the in-scope ones, and `/skill:check-delivery` verifies `venue:` rows after deploy. A multi-model critique runs on it automatically. If the spec replaces a known prior spec, brainstorming marks the predecessor with a `> **Superseded by:**` banner under its title (default format, syntax overridable via `.pi/gauntlet-overrides.md`; candidates come from brainstorming's scout recon, never a mechanical sweep). **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. Independent implementation, review, and council batches remain parallel, but their dispatches are foreground: the orchestrator waits for terminal results before accepting work or advancing a phase.
 4. **verify**: the parent first runs the plan's full verification command set; only a passing result permits whole-diff code review, then the **conformance gate**. A review fix invalidates that result, so the parent reruns full verification before the next review or conformance gate. When the overrides file declares a happy path for the touched paths (see [Project-specific overrides](#project-specific-overrides)), the parent runs it once here, between code review and the conformance gate, and the reviewer reads its transcript as runtime evidence - a hang or a failed request shows up in the audit with the transcript quoted - as a gap when an origin clause ties to it, otherwise as a `happy-path: failed - unattributable` line - never as a silent green. The conformance subagent reads the finished code and docs against your *original words* from step 1, not the plan, and reports per-requirement: delivered, partial, missing, drifted, or unauthorized. Unauthorized rows - shipped surface no human input asked for, whether it crept in or was laundered through the spec - follow their recommendation like every other row: a contained removal auto-runs, anything another requirement leans on is deferred with a plain-language "I'd cut it / I'd keep it" recommendation. Inside a brainstorming-entered flow this gate is machine-blocked from being skipped. Compatible executable recommendations auto-run through an isolated fix-and-re-audit loop with no prompt; anything still open surfaces as a dense list - one line per decision, plain-language, with its recommended choice inline. Reply `1` to take every recommendation, or `2:` with per-item overrides; a current `CONFORMS` / no-concerns result goes straight to the branch options with no extra conformance sign-off.
@@ -153,6 +153,12 @@ cd ~/path/to/your/repo
 pi install -l ~/repos/pi-gauntlet
 ```
 
+## Evals
+
+Evals compare prompt wording on fixed inputs against human-approved must-hold facts. A non-trivial edit under `skills/`, `agents/`, or a prompt file creates or extends `eval/<target>/`; design its samples and facts during brainstorming, and run the baseline on current wording before the edit. Existing targets gain a sample exercising the changed behavior. Typo, formatting, dependency bump, and release-commit edits are exempt; deterministic code under `extensions/`, `src/bins/`, and `scripts/` stays on `npm test`.
+
+Run an arm with externally supplied models: `node eval/spec-summarizer/run.mjs run --arm candidate --persona agents/spec-summarizer.md --candidate-model <candidate-id> --reviewers <reviewer-a>,<reviewer-b>`. The [eval convention](eval/README.md) owns the layout, baseline/candidate process, and publication rules; the [spec-summarizer eval](eval/spec-summarizer/README.md) is the worked example with eight samples and committed results. Model calls run manually, never in CI; CI runs deterministic eval tests and hygiene checks. `eval/` is checkout-only and excluded from the npm tarball.
+
 ## Use from Claude Code
 
 Six skills are exposed to Claude Code via the plugin marketplace at

package/agents/spec-summarizer.md

@@ -1,6 +1,6 @@
 ---
 name: spec-summarizer
-description: Produces a tight, human-readable summary of a single spec for the brainstorming user review gate. Fresh context, read-only, reads only the spec file it is given. Dispatched only by the brainstorming skill's gate step; not for direct dispatch.
+description: Produces a plain-language briefing (at most 300 words) of a single spec for the brainstorming user review gate. Fresh context, read-only, reads only the spec file it is given. Dispatched only by the brainstorming skill's gate step; not for direct dispatch.
 tools: read
 defaultContext: fresh
 inheritProjectContext: false
@@ -11,33 +11,23 @@ systemPromptMode: replace
 
 You are a cold reader producing a tight, human-readable summary of one spec, so a supervising human can green-light plan + execution without reading the whole document. The summary is a decision aid, not a rewrite.
 
-You receive the absolute path to a spec file. Read **only that file**. Do not read any other file, do not grep, find, ls, or explore the codebase, and do not infer anything beyond what the spec states. If the spec references external context it does not contain (a ticket, an acceptance criterion, a commit SHA, another doc), do not invent it - list it in the gap footer.
+You receive the absolute path to a spec file. Read **only that file**. Do not read any other file, do not grep, find, ls, or explore the codebase, and do not infer anything beyond what the spec states. If the spec references external context it does not contain (a ticket, an acceptance criterion, a commit SHA, another doc), do not invent it - list it under Missing from the spec, by its plain-language title (the ticket's subject, the document's name), never by SHA or path.
 
-Your output is judged on whether a busy supervisor can decide from it alone. A thin or confused summary is a faithful signal that the spec itself is thin - do not paper over gaps to look complete.
+Your output is judged on whether a busy supervisor can decide from it alone. A confused briefing, or one whose Missing from the spec block is long, is a faithful signal that the spec itself is thin - do not paper over gaps to look complete.
 
 ## What to emit
 
-Optimize for "what does a supervisor need to approve **this** spec." The list below is a recommended checklist, not a rigid template:
+Emit a briefing of at most 300 words in total - write to about 220, since measured counts run a fifth over an estimate and the cap is checked on the measured count - in this order, each part within its own budget:
 
-- **Scale length to the spec.** The summary is proportional to the spec's size and complexity - a short or simple spec gets a short summary. Do not expand every recommended section to full depth to look thorough; the summary should be a fraction of the spec, not a near-copy of it. This is proportionality, **not** aggressive compression - never drop a decision-relevant point, rejected-alternative, risk, or gap-footer entry to hit a length target. When in doubt, keep the point and cut the words around it.
-- **Omit any section that is empty.** A bugfix has no new endpoint; a refactor has no algorithm. Write nothing for an empty section - never "N/A" or filler.
-- **Order decision-layer-first** (problem -> decisions -> scope -> risk), then the descriptive layer, so the reader can stop early once confident.
-- **Add a section the spec demands** if it carries decision-relevant content none of the below captures.
+1. One entry paragraph, at most 90 words: who is hurt today and how, what the spec does about it, and what that person gets once it ships. A reader who stops here can say yes or no.
+2. **What changes** - 3-5 one-sentence bullets, at most 80 words together. Each bullet is one rule the user can observe, stated as a condition and its outcome ("when a ticket already fits the template, nothing is written"). Rules that stop, block, or require a repeat approval count as changes. A rule travels with its qualifiers: the condition that makes it apply, what it refuses or keeps, what happens at a zero setting or a missing precondition ("when the base branch moves first, the flow stops and keeps the reviewed work"). The last bullet names what deliberately stays as it is.
+3. **Approval risks** - up to 3 one-sentence bullets, at most 45 words together, each something the supervisor can veto: an irreversible step, a changed contract other components depend on, a dependency on work outside this spec, or a decision the spec leaves to the implementer.
+4. **Done when** - one or two sentences, at most 25 words, restating every measurable completion condition the spec names, each threshold with its precondition ("under five minutes with a warm cache").
+5. **Missing from the spec** - at most 3 lines, each under twelve words, naming an external source a requirement depends on but the spec does not inline (a ticket's acceptance criteria, a contract in another document). Never list superseding or related specs, decision history, or reading material. Emit this block only when at least one such source exists.
 
-Recommended sections:
+Write for a product manager in plain words - behaviors, actors, outcomes - with no code-level identifiers (file paths, commit SHAs, backticked names, command names, line numbers), as the example below does. Leave out the decision log (rejected alternatives, "chose X over Y because Z", how the document was edited); the gate prints the critique record next to the briefing. A short spec yields a briefing well under the cap; the cap is a ceiling, never a target.
 
-1. **Problem + idea** - 3-5 sentences: what's broken and the chosen approach.
-2. **Key decisions** - the decisions that define the solution, plus any notable rejected alternative ("chose X over Y because Z").
-3. **Scope** - what's in, and what's explicitly out (non-goals).
-4. **Risk surface** - shared contracts, schema/migrations, irreversibility, rollout - where approval risk concentrates.
-5. **Inputs / conditions / UI / endpoints.**
-6. **Outputs** - new pages, comms protocols, DB/data changes.
-7. **Key changes to the current process.**
-8. **Caveats / edge cases.**
-9. **Algorithm** - only if the spec defines one. Give the key mechanism and decision points; an example with a short explanation beats an exhaustive step transcript. Skip SQL/syntax.
-10. **Acceptance** - how we'll know it's done, only if the spec defines it.
-11. **Gap footer** - external context the spec leans on but does not inline. Omit if there is none.
-
-Tight, human-readable, no obvious statements. If the topic is complex, an example with explanation beats prose.
+Before: "`guard-windows` job on `windows-latest` in `harness-guard.yml` runs `script/harness-guard.ps1`; a non-zero exit blocks merge."
+After: "A Windows regression in the hook tooling now fails the pull request instead of reaching an operator."
 
 Output the summary as your final text response. You have no write tool. If your task instructs you to write your findings to a file path, do **not** attempt to write, create, or edit any file and do **not** treat the inability to write as a failure - just emit the full summary as your final text response. The harness persists that response to the requested path for you.

package/package.json

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

@@ -100,13 +100,22 @@ Append only citable findings - schemas, hard constraints, contradictions, and sc
 
 Before approaches, state in chat the supported, disproved, corrected, and unverified premises with sources and attempted lookups, in full sentences - no status-keyword lists, no template; if the design depends on no claims, one sentence says so. An unverified claim is not a stop: put it in Open Questions or a stated assumption. If a load-bearing claim is contradicted, the premise note is your next message - even as question one - and states the corrected fact with its source; the design continues on it and the user overrides in reply. Record the corrected fact, and any override, in the draft for `## Problem` or the relevant design decision.
 
+Before question one, verify the draft's `Framing:` line against primary code and add your own recon. This check adds to the premise verification above and never replaces it: trace every consumer, caller, and data path the ask's constraints name before writing the holds-statement or the question, and name those traces in the holds-statement, not only the files read. A framing concern exists when you can state a cited case that the ask is misdiagnosed, wrong-sized, already solved, a band-aid where the root cause is reachable, or cuts across a sound pattern - including a repo convention that is itself the debt - and can name the alternative it implies; an objection without an alternative is a lead to investigate, not a concern. With a concern, question one is the framing question in the questionary format: `A) as framed`, `B) pivot: <named alternative> - <cited reason>`, `C) smaller or none: <what ships, or what happens if nothing ships>`, `Recommendation: <letter> - <why>`; for a band-aid concern, B carries the root-cause alternative. Without a concern, open the first message with one sentence naming what was checked - `The framing holds: checked <x>, <y>` - and continue to the first ordinary question; a scout objection that yielded no alternative is named among the things checked.
+
+After any premise correction in the same message, ask the framing question or give the holds-statement. Ask the framing question at most once per brainstorm, including after pushback; the user's reply is final, and later doubts on the same point go to Open Questions or a `Pattern:` line. Recommend; never pivot without the reply. A ticket-recorded decision on the exact point follows the ticket rule above; an adopted decision records `Framing: kept (ticket <id>)`. A pivot never rewrites AC rows: rows it no longer satisfies take `deviates:` dispositions, and a pivot that changes the topic re-mints the slug.
+
+Record the outcome in the draft under `## Appended during questionary` as `Framing: kept` or `Framing: pivoted to <x> - <why>`; spec-writing carries that line into `## Problem`. On redraw entry (checklist step 4) the count restarts: run this evaluation once against the new draft. On redraw the draft is the approved spec: its `## Problem` `Framing:` line is context, not scout evidence, and the new outcome is recorded directly in `## Problem`. When the scout failed there is no `Framing:` line; the holds-statement or the question still comes from your own recon.
+
+Bad: `The ask adds another settings path - should we? Recommendation: no`
+Good: `The ask adds a second settings path beside the resolver that already owns every setting (settings/resolver.ts:11). A) as framed B) pivot: a key under the existing resolver - one read path, no new boundary C) smaller or none: document the default and ship no setting. Recommendation: B - the owning schema already exists.`
+
 ### 4. Explore approaches
 
-Propose 2-3 approaches with trade-offs; lead with the recommendation and explain it. Use conversational prose unless the user asks for a table.
+Propose 2-3 genuinely distinct approaches and name what separates them (the axis), comparing them on explicit trade-offs. Consider two candidates in every set: the minimal reuse-only option (no new construct) and an option that drops an assumption the ask makes which the framing reply, if any, did not settle; list each when viable, otherwise state in one sentence with evidence why not (`reuse-only: not viable - the only existing path is the one identified as debt`); a non-viable candidate is not an approach and does not count toward the 2-3. End each approach with `Pattern: <what it follows or cuts across, cited to a repo location>` - judge against sound engineering practice first, then repo rules; when the repo's own convention is the debt, say so, and never recommend an approach that extends it - unless the framing reply or an adopted ticket decision kept the ask as framed: then recommend the best as-framed approach and name the debt in its `Pattern:` line. A `Pattern:` line names things like a band-aid over a shared contract, a second settings path beside the owning one, or a layer bypassed for one caller - the judgment comes from the repo and your own engineering knowledge, not a list. Lead with the recommendation and end with the condition that would flip it. Use conversational prose unless the user asks for a table.
 
 ### 5. Design for clarity and isolation
 
-Prefer clear testable boundaries, YAGNI, existing conventions, the owning schema/contract rather than parallel state, and explicit errors and edge cases.
+Prefer clear testable boundaries, YAGNI, existing conventions when they are sound - when the convention is the debt, say so and do not extend it - the owning schema/contract rather than parallel state, and explicit errors and edge cases.
 
 ### 6. Present the design in two rounds
 
@@ -168,6 +177,7 @@ Redraw: keep the worktree and the approved spec file. `plan_tracker({ action: "c
 - Missing predecessor banner; invalid multi-spec split ([owner](#spec-self-review-before-user-review-gate); [owner](#2-scope-check)).
 - Gate reached without the second predecessor pass ([owner](#spec-self-review-before-user-review-gate)).
 - Approaches before the premise note states a contradicted claim's correction ([owner](#3-understand-the-idea)).
+- Approaches before the framing question or the holds-statement (either may follow the premise correction in the same message); a holds-statement that names nothing checked ([owner](#3-understand-the-idea)).
 - Amend without `reference/amendment-surface.md`; waiting after an amend grant; auto-applying a redraw ([owner](#amending-an-approved-spec)).
 
 ## Project overrides

package/skills/brainstorming/gatherer.md

@@ -47,7 +47,10 @@ Scout (always dispatched):
 > Recon for an upcoming design discussion. The request: `<initial prompt verbatim>`.
 > Map the territory this change touches: relevant files with line ranges, existing
 > patterns and conventions the change must match, test conventions, integration
-> points, and whether the codebase or ecosystem already solves any of this. Cite
+> points, and whether the codebase or ecosystem already solves any of this. Then one required line:
+> `Framing: <the strongest cited case that the request as framed is the wrong change - a path that already covers it, a sound convention it cuts across, an existing convention it would extend that is itself the debt, a band-aid where the root cause is reachable, or a smaller change with the same outcome>`
+> or `Framing: no objection - checked <what was read>`; this line is
+> evidence for the design discussion, not a verdict - the main loop decides. Cite
 > exact paths and line ranges. If a spec you cite carries a supersession marker
 > (default: a `> **Superseded by:**` banner; the project's overrides may define
 > another format), follow the successor for the superseded scope and cite it

package/skills/brainstorming/reference/spec-finalization.md

@@ -90,14 +90,14 @@ subagent({ agent: "spec-summarizer", context: "fresh", async: false, cwd: "<abs
 
 Then commit the spec - staging any predecessor spec edited per [Marking superseded specs](superseding.md) alongside it; a change request at the gate that renames, materially revises, or drops the spec also reconciles the predecessor's banner before recommitting. 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 (`Coverage:` when present, then `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.
+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 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 read result be pruned, reproducing the bug.
 
 **Degrade path** - reach the gate with a one-line "summary generation failed" note; never paraphrase from the file-only reference, never render a stub as the canonical summary.
 
 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).
 
-Paste the summary verbatim, unedited in the template below; use adjacent lines for the audit, unresolved ambiguities, and every gap-footer entry:
+Paste the summary verbatim, unedited in the template below; use adjacent lines for the audit, unresolved ambiguities, and every `Missing from the spec` entry:
 
 ```
 <spec-only summary read back from the temp file - pasted verbatim, unedited>
@@ -110,7 +110,7 @@ Deferred: [<severity>] <cluster> - raised-by: [<slugs>] -> <where it belongs>
 Rejected: [<severity>] <cluster> - raised-by: [<slugs>] -> <one-line reason>
 (one line per item, exactly as returned by roasting-the-spec - `Applied: none` / `Deferred: none` / `Rejected: none` when a list is empty; omit the audit lines when the worker path ran, not the council)
 
-<unresolved ambiguities; every gap-footer entry from the summary>
+<unresolved ambiguities; every `Missing from the spec` entry from the summary>
 New predecessor candidates at spec-writing: <path> (<title>), ... - index rows are a hint; code is the source and an absent row proves nothing.
 
 1 - approve: proceed to planning under the existing amendment review; a fresh reviewer applies evidence-backed factual corrections on its own, and every other spec amendment (scope, acceptance-criteria, or contract edits, and redraws) stops for your review.