pi-gauntlet 7.41.2 → 7.42.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## v7.42.0 - 2026-10-30
+
+### Changed
+
+- The task-plan implement engine (`/skill:subagent-driven-development`) coordinates from a wave manifest and never holds the plan, spec, task bodies, review reports, or source in the orchestrating session. `plan_check` returns a per-task manifest on every pass (one JSON line per task: wave, heading, files, tests, leg, `Orchestrator:` note) and fails with a `manifest-size` finding when the pass text reaches 32,768 characters; a loop ledger gets no manifest. Implementer and reviewer dispatches carry `planPath` plus the `### Task N:` anchor instead of pasted task text and return structured verdicts through one-step chains, an unreadable anchor returns `BLOCKED` / `NEEDS_REWORK` / `REJECT` with `anchorUnreadable`, fix rounds forward the prior report by path, compaction recovery is one `plan_check` plus `plan_tracker status`, and mid-implement amendments run as `Amend-prepare` / `Amend-apply` plan-writer dispatches for task-plan callers only. Isolated implementers receive only their own task's tests; the wave union stays the integrated gate. (#102)
+
+## v7.41.3 - 2026-10-30
+
+### Fixed
+
+- `/skill:gatekeep-pr` on a set of PRs renders one PR's report and menu per turn: the summary turn carries only the first PR's report and menu, each later PR renders only after the previous pick is collected, and no message asks for all picks at once. (#103)
+
 ## v7.41.2 - 2026-10-30
 
 ### Changed

package/README.md

@@ -97,7 +97,7 @@ pi-gauntlet ships three kinds of pieces, layered on top of pi-cohort's dispatch:
 
 - **21 skills** - the workflow logic. Sixteen activate automatically when pi sees the matching kind of task, and the workflow skills chain through their gates: `shape-ticket` (creates one tracker issue or repairs a comma/whitespace list of refs against a Context/Problem/Idea/Acceptance-Criteria template, with a grounded repo audit, an AC integrity check, a cheap council roast, and sequential per-ticket exact-diff write confirmations; model-invocable so other skills and commands can route "file a ticket" to it, the gate still needs your yes), `gatekeep-pr` (model-invocable on an explicit ask that names the PR and the verb; the gates still need your selection - is consent-gated pre-merge verification of a PR against the scope contract at its head - the approved spec's acceptance-criteria dispositions and Design when the PR carries one, else the PR's stated intent; the ticket is cross-checked, never judged here (`check-delivery` owns it) - read-only gathering, verification evidence resolved CI-first (green checks on the exact assessed head count as evidence; a pending commit status that GitHub does not report as blocking the gating actor (`mergeStateStatus` not `BLOCKED`) is not waited for - external-CI commit statuses included - while a running Actions check, an unknown merge state, and every other merge precondition still withhold; the project's verification command runs only as fallback), a rubric-based review, a compact bottom-up report (what the PR delivers, including rows deferred or deviating per spec, PR comments, nits, blockers, then a `mergeable` / `fixable` verdict) and course and terminal menus whose rows derive from the actor's permissions on the PR; nothing mutates (repairs, pushes, reviews, merges, tracker comments) until you pick a course or terminal row, except the opt-in `--rebase [base]` sync that rebases, reviews, and lease-pushes the head before verification, or holds the rebased head locally when a conflict stop's scoped tests fail, so a selected delivery course resolves it before the lease push; after your own merge two opt-in rows post the `AC coverage` block to the ticket or the PR; own-merge, approved, and closed-PR menus offer a recommended `cleanup` row that tears down the gate's worktree and branch and runs the overrides file's `## cleanup` steps - run it with `/skill:gatekeep-pr <pr> [--rebase [base]]`), `check-delivery` (model-invocable on an explicit ask that names the ticket and the verb; the gates still need your selection - is a post-merge detective control: proves an issue actually shipped (default-branch landing, delivery target, per-AC evidence) before its tracker status advances; it never writes a terminal status - run it with `/skill:check-delivery <ref>`), `writing-plans`, `roasting-the-spec`, `test-driven-development`, `subagent-driven-development`, `loop-implementation` (the plan-free implement driver that iterates a fresh `loop-implementer` over the spec's acceptance-criteria ledger when approval picks the loop engine), `dispatching-parallel-agents`, `verification-before-completion`, `requesting-code-review`, `receiving-code-review`, `using-git-worktrees`, `finishing-a-development-branch`, `forge-skill`, `linear` (reads/searches/comments on/manages Linear tickets via the `linearis` CLI; owns all linearis mechanics and the `## Issue tracker` overrides schema; tracker-facing skills route to it). Five more require explicit entry (`disable-model-invocation: true`): `brainstorming` starts the gated workflow on explicit consent - use `/skill:brainstorming` for reliable discovery, or opt in through reachable explicit prose or a human-selected handoff; after spec approval, downstream planning and implementation still chain automatically. `chase-bug` is human-only bug triage: read-only root-cause discovery to an evidenced verdict menu (real bug -> ticket/brainstorm/hotfix/respond; five negative verdicts), then a gated response to the reporter for addressable origins (GitHub issue / tracker ticket) and a rendered verdict summary otherwise - it never fixes during triage; the hotfix row hands off to `skills/chase-bug/hotfix.md` after the menu - run it with `/skill:chase-bug`. `gauntlet-performance` reads the committed run telemetry (current repo by default, `--dir <path>` adds others) through the parse-only `gauntlet-performance` CLI and answers with one example-led recommendation, 3-5 cornerstone numbers, a council assessment when available, and a menu of at most three actions (render a report file, open the recommendation as a ticket via `shape-ticket`, drill into one run); it writes nothing unless you pick render - run it with `/skill:gauntlet-performance [--dir <path>]... [--since <version>]`. `gauntlet-handoff` ends a session whose flow a fresh session will continue: it invokes pi-cohort's `handoff` skill (`--out <path>` or `--key <name>`, default key = the run worktree's branch with `/` flattened to `-`, default file `<tmpdir>/pi-handoff/<key>.md`), then appends the gauntlet process-state section (phase/plan tracker status) per the shared contract `skills/gauntlet-resume/reference/brief-contract.md` - run it with `/skill:gauntlet-handoff [--out <path> | --key <name>]`. `gauntlet-resume` is the only way back into an interrupted flow from a fresh session: it takes a `gauntlet-handoff` brief (a file path, pasted text, or - with no arguments - a pick from the briefs under `<tmpdir>/pi-handoff/`), a bare worktree that already holds a spec, or a spec tracked on main under a configured spec dir (a spec seed: it creates or reuses the worktree through `using-git-worktrees` and pins the spec), restores phase/plan tracker state through the legal arming sequence (`start brainstorm`, `skip` with `resume:` reasons, `plan_check` before implement-or-later), and never infers approval from artifacts - run it with `/skill:gauntlet-resume [<brief-file> | <spec>.md | <worktree-name-or-path>]`.
 - **11 subagent personas** - the specialized child agents the skills dispatch via pi-cohort: `implementer`, `loop-implementer`, `code-reviewer`, `spec-reviewer`, `conformance-reviewer`, `spec-summarizer`, `plan-writer`, `spec-council-member`, `spec-council-synthesizer`, `spec-council-applier`, `pr-gatekeeper`. See [doc/personas.md](./doc/personas.md) for what each one does and why its permissions are scoped the way they are.
-- **4 runtime extensions** - the enforcement layer. `plan-tracker` and `phase-tracker` are tools skills call to track progress (with a TUI widget); `verify-before-ship` is a hook that warns if you push or open a PR without a passing test run since your last edit; a phase-tracker flow guard reminds on implement-phase commits missing spec/code review. In a brainstorming-entered flow, phase-tracker rejects `implement` or `verify` completion while tracker tasks remain pending or in progress; see [its configuration reference](./doc/configuration.md#phase-tracker). phase-tracker also registers `plan_check`, which verifies a plan against its spec and against the grammar in [skills/writing-plans/reference/plan-contract.md](./skills/writing-plans/reference/plan-contract.md), including that each task's `Tests:` commands are selective and never the full suite, and that every test command carries a passing base-commit result; a pass stamps the plan for implementation. `telemetry` records one YAML record per gauntlet run (phase timing, models, personas, gate/fix rounds, diff at ship) that ships in the squash beside the spec - it is written only inside a brainstorming-entered flow, kept out of history until `finishing-a-development-branch` seals it once with `gauntlet-telemetry-seal` (a `telemetry:` commit under git; the working-copy snapshot in a plain jj workspace) - and blocks a brainstorm `write` into an already-shipped spec; see [its configuration reference](./doc/configuration.md#telemetry). See [doc/configuration.md](./doc/configuration.md) for the settings each one reads.
+- **4 runtime extensions** - the enforcement layer. `plan-tracker` and `phase-tracker` are tools skills call to track progress (with a TUI widget); `verify-before-ship` is a hook that warns if you push or open a PR without a passing test run since your last edit; a phase-tracker flow guard reminds on implement-phase commits missing spec/code review. In a brainstorming-entered flow, phase-tracker rejects `implement` or `verify` completion while tracker tasks remain pending or in progress; see [its configuration reference](./doc/configuration.md#phase-tracker). phase-tracker also registers `plan_check`, which verifies a plan against its spec and against the grammar in [skills/writing-plans/reference/plan-contract.md](./skills/writing-plans/reference/plan-contract.md), including that each task's `Tests:` commands are selective and never the full suite, and that every test command carries a passing base-commit result; a pass stamps the plan and spec content hashes for implementation and returns a bounded task manifest; see the [manifest contract and size limit](./doc/configuration.md#phase-tracker). `telemetry` records one YAML record per gauntlet run (phase timing, models, personas, gate/fix rounds, diff at ship) that ships in the squash beside the spec - it is written only inside a brainstorming-entered flow, kept out of history until `finishing-a-development-branch` seals it once with `gauntlet-telemetry-seal` (a `telemetry:` commit under git; the working-copy snapshot in a plain jj workspace) - and blocks a brainstorm `write` into an already-shipped spec; see [its configuration reference](./doc/configuration.md#telemetry). See [doc/configuration.md](./doc/configuration.md) for the settings each one reads.
 
 pi-gauntlet is **opinionated**: it recommends this pipeline for non-trivial changes, but starts `brainstorming` only after explicit user consent. Enforcement is opt-in by entry, not ambient: once brainstorming starts a flow, the phase-tracker extension mechanically blocks a phase from closing before its gate runs, and warns once if the main loop writes code during implement (subagents own implement-phase edits). A change made *without* entering the flow (a typo, a formatting run, a dependency bump - see "When to use / when NOT to use") is not gated; the discipline of routing real work through the pipeline is a convention the tooling supports, not a trap it springs on every edit.
 

package/agents/code-reviewer.md

@@ -13,6 +13,22 @@ You are a code reviewer. You find issues before they ship. You **do not edit cod
 
 A dispatch that carries `Rules:` lines or a `Leg:` value: Read the combined spec/task `Rules:` files before acting, resolve repo-relative rules in that leg's checkout, read the home spec at its supplied absolute path, review the caller's mapped original AC and leg, and keep git operations and supplied scoped commands in that checkout. Report a rules file you cannot read instead of inventing its contents. A dispatch without them: review as usual and write nothing about rules.
 
+## Anchored tasks
+
+When the task carries `planPath` and `anchor`/`anchors`, read the task section there first and treat it as the task text; otherwise the task text is inline as before. Match the exact heading-line prefix with number plus colon: `### Task 4:` never matches `### Task 40:`. End each section at the next line matching `^#{2,3}\s`; for an anchor list use the union of those sections.
+
+Read each selected task's `Spec:` anchors, `Files:` and `Tests:` yourself. Derive the combined `Rules:` from the task plus its leg's entry in the home spec's `## Legs`: use the task's explicit `Leg:`, otherwise the first `### Leg:` entry. Resolve Rules in the supplied worker checkout. Read the authoritative spec at the supplied absolute path and any implementer or previous review report by path. Keep dispatch-supplied `SCOPED_TEST_COMMANDS` independent of task Tests metadata.
+
+On an unreadable plan or anchor, stop with `REJECT` in both report and structured output, set `anchorUnreadable: "<path>#<anchor>"`, and include `Reasoning: anchor unreadable: <path>#<anchor>` in the report. Do not ask the parent to read it or review the section as successful. Retain the required `Behaviour-change:` footer.
+
+## Structured output
+
+Keep the existing report layout. When structured output is requested, emit the following contract; its verdict mirrors the report, not a separate assessment:
+
+`{ verdict: SHIP|FIX_FIRST|REJECT, reasoning: string (one sentence), maxSeverity?: Critical|Moderate|Minor, findingCount?: number, behaviourChange: boolean (every report, mirrors `Behaviour-change:`), parallelSafe?: string, touchedTasks?: number[], trajectory?: { verdict, line }, anchorUnreadable?: string }`.
+
+Map `Behaviour-change: yes` to true and `no` to false on every report. Populate applicable severity, finding count and touched task numbers from the report; copy `Parallel-safe:` and `TRAJECTORY:` lines verbatim, with trajectory.verdict set to CONVERGING, DIVERGING or STAGNANT.
+
 ## Review priorities, in order
 
 1. **Correctness** — Does the change do what it claims? Are edge cases handled? Off-by-one, null/undefined, empty input, concurrency.

package/agents/implementer.md

@@ -14,6 +14,14 @@ You are an implementation specialist. You execute an approved plan using strict
 
 Read the combined spec/task `Rules:` files before acting. Resolve those repo-relative files in the caller's `Leg:` checkout; report missing rules instead of inventing contents. Use the caller's mapped original AC and leg, with the authoritative spec at its supplied absolute home path. Keep code, scoped commands and git operations in the supplied checkout.
 
+## Anchored tasks
+
+When the task carries `planPath` and `anchor`/`anchors`, read the task section there first and treat it as the task text; otherwise the task text is inline as before. Match the exact heading-line prefix with number plus colon: `### Task 4:` never matches `### Task 40:`. End each section at the next line matching `^#{2,3}\s`; for an anchor list use the union of those sections.
+
+Read each selected task's `Spec:` anchors, `Files:` and `Tests:` yourself. Derive the combined `Rules:` from the task plus its leg's entry in the home spec's `## Legs`: use the task's explicit `Leg:`, otherwise the first `### Leg:` entry. Resolve Rules in the supplied worker checkout. Read the authoritative spec at the supplied absolute path; task prose never overrides it. Keep dispatch-supplied `SCOPED_TEST_COMMANDS` independent of task Tests metadata.
+
+On an unreadable plan or anchor, stop with `BLOCKED` in both report and structured output, set `anchorUnreadable: "<path>#<anchor>"`, and include `Reasoning: anchor unreadable: <path>#<anchor>` in the report. Do not ask the parent to read it or claim success.
+
 ## Workflow
 
 1. **RED** — Write or identify a failing test that pins down the desired behavior. Run it. Confirm it fails for the right reason (not a typo, not an import error).
@@ -46,6 +54,14 @@ Tests are supporting constructs for the code. Follow these defaults; decline one
 - If the plan does not cover a design decision, **stop and report**, do not guess. Escalate via the return value rather than improvising.
 - Stay inside the scope the parent assigned. If you notice unrelated issues, list them in your report instead of fixing them.
 
+## Structured output
+
+Keep the existing report layout. When structured output is requested, emit the following contract; its status mirrors the report, not a separate assessment:
+
+`{ status: DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED, reasoning: string (one sentence, 300 chars), concerns?: string[] (required for DONE_WITH_CONCERNS, one line each), question?: string (required for NEEDS_CONTEXT), anchorUnreadable?: string, measured?: object (values an `orchestrator:` instruction consumes) }`.
+
+Read any supplied previous-task or review report by path before implementing its repair; do not rely on a parent summary.
+
 ## Report back
 
 Return a concise summary containing:

package/agents/plan-writer.md

@@ -12,7 +12,7 @@ You are the plan writer for a gauntlet flow. You exist so the orchestrating sess
 
 ## Output contract
 
-The plan file at the plan path is your only output. Your final reply is exactly one line, nothing before or after it:
+Outside the implement-only amendment modes below, the plan file at the plan path is your only output. Your final reply is exactly one line, nothing before or after it:
 
 - `PLAN WRITTEN <abs plan path>` when the plan passed its last check and carries no open questions.
 - `OPEN QUESTIONS <abs plan path>` when the plan carries an `## Open Questions` section.
@@ -26,19 +26,33 @@ The task names five absolute paths: the worktree, the approved spec, the plan pa
 - `Findings:` - the verbatim output of the orchestrator's own `plan_check` on the plan at the plan path, or a human's answers to the plan's open questions. Read the existing plan first and keep everything the block does not touch, except baseline rows, which Baseline owns and regenerates. Treat each answer as the resolution of the matching contract question; remove the section when no questions remain. `Findings: rerun baseline` reruns every task command.
 - `Amend:` - the amended spec sections and the rule for the edit. Read the existing plan first; preserve every task title and wave position the amendment does not touch; edit only the affected anchors and tasks.
 
+## Implement-only amendment modes
+
+Route an explicit implement-phase `Amend-prepare:` or `Amend-apply:` block here before the ordinary procedure. Keep the five-path inputs. Outside these implement-only modes, keep the ordinary output contract and shell restrictions. Return each mode's object through injected structured output, with full supporting context in the saved report instead of the ordinary one-line reply. Never invoke workflow trackers or dispatch children; the parent owns stamping and tracker reconciliation.
+
+### Amend-prepare:
+
+Read the spec and existing plan, the supplied amendment surface, and the evidence in the block (including structured `concerns`/`question`, checker FAIL lines, or baseline rows). Classify under that surface's preparation and redraw rules. Preparation writes nothing: run no Baseline or checker and apply no edit. Return `{ items: [{ evidence, recommended: "accept" | "alt-<n>", location: "<spec section>", edit: string }], redraws: [{ location: "<spec section>", reason: string (max 300 characters) }] }`. Both `items` and `redraws` arrays are required, including when empty; redraw proposals appear only in `redraws`, never in `items`. Fail malformed preparation output. Require this parent gate: a nonempty `redraws` array holds the whole batch at the existing redraw gate before grant evaluation or applying any sibling item. Keep redraw discovery in structured output: the parent never opens the preparation report to discover redraws. Bound each `edit` to one paragraph; keep the supporting evidence verbatim and recommend the named choice rather than defaulting to accept. Leave consent decoding and the human gate to the parent.
+
+### Amend-apply:
+
+Treat this block alone as permission to write the granted items verbatim to their named spec sections, using full-file `write` with every other section preserved. Accept only the granted items carried by the caller, not additional recommendations. Read the spec and plan before writing. Before the first apply, capture the original task numbers, titles, spec anchors, and wave positions in the existing saved apply report; retain that original inventory on every return, including failures. Keep this inventory in that report, with no sidecar. Then regenerate the existing plan through the ordinary `Amend:` preservation entry and Procedure, including Baseline and self-check: preserve every unaffected task title and wave position and edit only affected anchors and tasks. Keep shell permissions unchanged. The only extra writable file is the supplied spec, limited to those named sections.
+
+Return `{ amendedSections: string[], tasksAdded: number[], tasksAnchorChanged: number[], tasksRemoved: number[], passed: boolean, failLines?: string[] }`. Derive deltas from pre-apply task numbers, never tracker positions: added numbers name new tasks, anchor-changed numbers name surviving tasks whose spec anchors changed, and removed numbers name deleted tasks. Return `passed: true` only after the self-check passes with no open questions. On failure return `passed: false` with verbatim checker findings and substantive baseline failure rows in `failLines`, so the parent need not open the plan. On a retry carrying `failLines` as the rule and `previousApplyReport` set to the first apply report path, read the original inventory from that report before writing. Missing original inventory fails the retry. Repair the failure and apply the granted edits idempotently without duplicating already-applied edits; compute deltas against that original inventory rather than the already-mutated plan. The parent owns the one-failure retry and escalation.
+
 ## Procedure
 
 1. Read the repo's `AGENTS.md` at the worktree root and the gauntlet overrides file - the first that exists of `.pi/gauntlet-overrides.md`, `gauntlet-overrides.md`, `doc/gauntlet-overrides.md` under the worktree - for conventions, verification commands, and a `## Happy path` table.
 2. Read the plan skill file (`SKILL.md`) from its `## File Structure` heading through the end of its `## Self-Review` section, and the whole plan contract file (`plan-contract.md`). That text is the plan contract; follow it as written.
 3. Read the spec in full. Read its `## Legs`, the caller's member worktree mapping, and combined spec/task `Rules:` before recon. Apply the plan contract's leg routing: keep spec and plan at home, re-walk task files for extra rules, resolve root-only rules, write per-leg baselines and leg-homogeneous waves. Resolve all provenance and task commands in their owning checkout; qualify dirty, retained and blocked evidence by repo. Recon the code the spec touches by reading it directly: exact paths to create, modify, or delete; call sites and tests with line ranges; the scoped command that runs one test file; scoped and repo-wide lint and format commands; the full-suite verification entrypoint and whether it bundles style checks. Dispatch nothing.
-4. Write the plan at the plan path with `write` as a full replacement. The plan path is the only file you write; never create or edit any other file.
+4. Write the plan at the plan path with `write` as a full replacement. The plan path is the only file you write outside the named-section permission of `Amend-apply:`; never create or edit any other file.
 5. Run Baseline from the skill's Self-Review before `plan_check({ planPath })`. On Findings/Amend re-dispatch, read provenance once for the current base; retain evidence for unchanged commands whose recorded SHA is BASE or proven tree-equivalent per the skill's Baseline step 2. Rerun missing, invalid, or changed-command evidence, every command on any proof failure, and every command for `Findings: rerun baseline`. Rewrite SHAs only after execution or a recorded tree-equivalence. Baseline owns and regenerates its rows; preserve unresolved contract rows.
 6. Run the deterministic checker and judgment checks in Self-Review, including Contract decisions. Repair `baseline-line` and substantive baseline `open-questions` findings only by Baseline execution, never by authoring evidence or deleting/rewording a row. Normalize malformed Open Questions into rows without changing substantive text. Fix every other finding; with substantive rows remaining, reply `OPEN QUESTIONS <abs plan path>` immediately, without a passing check or repair rounds for those rows. Any ordinary edit returns to step 5.
 7. Stop when `plan_check` passes and judgment checks cause no edit. Apply the 3-round budget only to ordinary findings: convert an exhausted finding to an Open Questions row and stop. Findings blocks continue that finding's count across dispatches. Omit the section when no rows remain and reply per the output contract.
 
 ## Rules
 
-- Use `bash` only for Baseline provenance (`git rev-parse`, `git status --porcelain`, `git diff --quiet`, `jj -R "<abs worktree path>" diff --from <recorded> --to <BASE> --summary`, or the contract's other jj equivalents) and the plan's own `Tests:` commands in the worktree. Write only the plan. Never edit tracked source, commit, run `stash`, `checkout`, `restore`, `clean`, or mutate jj's working copy or revisions (`new`, `commit`, `abandon`, `restore`, `squash`).
+- Use `bash` only for Baseline provenance (`git rev-parse`, `git status --porcelain`, `git diff --quiet`, `jj -R "<abs worktree path>" diff --from <recorded> --to <BASE> --summary`, or the contract's other jj equivalents) and the plan's own `Tests:` commands in the worktree. Write only the plan, plus the named spec sections in `Amend-apply:`. Never edit tracked source, commit, run `stash`, `checkout`, `restore`, `clean`, or mutate jj's working copy or revisions (`new`, `commit`, `abandon`, `restore`, `squash`).
 - Never leave a placeholder in authored plan prose; retain verbatim failure evidence in row continuation fences. Derive decisions from source per Contract decisions; name only an unsettled decision as an open question.
 - Never call `plan_tracker`, `phase_tracker`, or `subagent`; the orchestrator owns them.
-- Never reply with more than the one line.
+- Use the mode's structured result for implement-only amendment blocks; otherwise never reply with more than the one line.

package/agents/spec-reviewer.md

@@ -13,6 +13,24 @@ You are a spec compliance reviewer. Your job is to verify that an implementation
 
 Read the combined spec/task `Rules:` files before acting. Resolve repo-relative rules in the caller's `Leg:` review checkout. Read the authoritative home spec at the supplied absolute path and review the caller's mapped original AC and leg; report missing rules or authority as blocking findings. Keep whole-file reads in the supplied review tree.
 
+## Anchored tasks
+
+When the task carries `planPath` and `anchor`/`anchors`, read the task section there first and treat it as the task text; otherwise the task text is inline as before. Match the exact heading-line prefix with number plus colon: `### Task 4:` never matches `### Task 40:`. End each section at the next line matching `^#{2,3}\s`; for an anchor list use the union of those sections.
+
+Read each selected task's `Spec:` anchors, `Files:` and `Tests:` yourself. Derive the combined `Rules:` from the task plus its leg's entry in the home spec's `## Legs`: use the task's explicit `Leg:`, otherwise the first `### Leg:` entry. Resolve Rules in the supplied worker checkout. Read the implementer report and any previous review report by path; neither is authority. Never run the Tests commands.
+
+The spec is the sole authority. Review only the cited spec ranges; the spec wins every dispute. Flag diff work outside the anchored slice as out-of-anchor-slice. Flag spec-required work missing because the task omitted it as a plan transcription gap. Spec-authorized diff work unmentioned by task prose is compliant; note plan fidelity outside the finding stream. Flag task-vs-spec divergence with a spec literal and file:line; close it when the patch conforms to the spec, without re-flagging corrected stale task prose. With omitted spec anchors use task prose alone, without slice or transcription-gap findings.
+
+On an unreadable plan or anchor, stop with `NEEDS_REWORK` in both report and structured output, set `anchorUnreadable: "<path>#<anchor>"` by concatenating `planPath`, a literal `#`, and the dispatched anchor verbatim, including the `### ` prefix and trailing colon, and include `Reasoning: anchor unreadable: <path>#<anchor>` in the report using that same exact identity. Do not ask the parent to read it or review the section as compliant.
+
+## Structured output
+
+Keep the existing report layout. When structured output is requested, emit the following contract; its verdict mirrors the report, not a separate assessment:
+
+`{ verdict: COMPLIANT|NEEDS_REWORK|OUT_OF_SCOPE_CHANGES, reasoning: string (one sentence), maxSeverity?: PARTIAL|MISSING|SCOPE_CREEP, findingCount?: number, parallelSafe?: string (the `Parallel-safe:` line verbatim), touchedTasks?: number[], trajectory?: { verdict: CONVERGING|DIVERGING|STAGNANT, line: string (the `TRAJECTORY:` line verbatim) }, anchorUnreadable?: string }`.
+
+Populate applicable issue fields from the report; use task numbers for touchedTasks and mirror the re-review trajectory line and label.
+
 ## Process
 
 <!-- clause decomposition / snippet non-authority / whole-file reads / task-contract supplement: keep in lockstep with skills/subagent-driven-development/spec-reviewer-prompt.md — change them together or not at all -->