task-pipeline-skill 0.12.0 → 0.17.1

package/plugins/task-pipeline/skills/task-pipeline/references/grill.md

@@ -4,7 +4,7 @@ The intake grill is **part of this skill**. No companion skill to install, no
 provider to resolve, nothing to fall back to: this file *is* the implementation.
 
 Its job is not to design. It is to take a one-line request ("make me feature X")
-and interview it into a brief complete enough that stages 1→9 finish without
+and interview it into a brief complete enough that stages 1→10 finish without
 coming back to the operator.
 
 > Adapted, with thanks, from Matt Pocock's `grilling` / `grill-with-docs` skills
@@ -95,19 +95,22 @@ numbering (scan for the highest number, increment).
 ## The autonomy sweep
 
 Resolving the *task* is not enough. The grill must also pre-resolve everything that
-would otherwise stop stages 1→9 mid-flight. Every row gets an answer **or** an
+would otherwise stop stages 1→10 mid-flight. Every row gets an answer **or** an
 explicit "stop and ask me here":
 
 | Stage | What to settle up front |
 |---|---|
 | run-wide | the model decision ([`model-tiering.md`](model-tiering.md)); what to decide autonomously vs escalate |
 | 1 Docs | external libs/APIs/SDKs in play; any private ones context7 can't resolve → where their docs live |
+| 2 Decompose | is this a platform (several capabilities/surfaces) or one module? if platform: deploy cadence — per module or once at the end |
 | 2–3 Spec | UI verdict (arms super-ux); any scenario-tracing waiver |
 | 4–5 Dev | base branch; worktree/branch policy; is `main` off-limits; commit convention; task tracker |
+| 5 Integration | how the branch lands (merge / PR + approver / "leave it unmerged"); parallel fan-out wanted (one worktree per implementer)? |
 | 6 Tests | the test command; what "green" means here; known-red baseline; coverage expectation |
 | 7 Lint+deploy | lint command; deploy target and path; release automation on/off; deploy-from-main rule; **deploy authorization** |
 | 8 Post-deploy | where logs / health live (app name, endpoint, workflow) |
 | 9 Docs+wiki | which module docs / runbooks this change updates; wiki sync yes/no |
+| 10 Acceptance | who signs off; where deferred REQs are tracked (issue tracker, backlog) |
 
 **Deploy authorization has a hard floor.** Deploy and publish are outward and
 irreversible, so a vague "just do everything" authorizes nothing. A standing
@@ -116,14 +119,49 @@ preconditions ("staging once lint and the full suite are green; production alway
 asks"). Specific and recorded → it satisfies the stage-7 manual gate. Broader,
 absent or ambiguous → stage 7 stops and asks.
 
+## The REQ spine — the grill's other hard output
+
+Prose scope is not checkable. Before the brief is confirmed, the grill must turn
+what was asked into an **addressable list of requirements**, because every later
+stage traces to these IDs and stage 10 accounts for every one of them.
+
+| ID | Requirement | How it's verified | Status |
+|---|---|---|---|
+| REQ-001 | … | test name / `file:line` / command + expected output / `SCN-…` | open |
+
+Three rules that decide whether the spine is worth anything:
+
+1. **One REQ = one independently verifiable deliverable.** Not one per sentence of
+   the request. A small task gets three rows, not thirty — an inflated table is
+   ignored, and an ignored table protects nothing.
+2. **Every row names its check.** *A requirement you can't say how to verify is a
+   badly-stated requirement* — split or sharpen it here, during the grill. This is
+   the single defence against the failure mode where three vague REQs cover a large
+   task and acceptance goes green over half of it.
+3. **Ask what "finished" means per row, not for the task overall.** "Export works"
+   hides five decisions; "exports the currently filtered rows as CSV, verified by
+   `test_export_respects_filters`" hides none.
+
+**Then freeze it.** Adding a requirement mid-run is fine — append with its source.
+**Removing or narrowing one requires the operator's explicit agreement**, recorded
+in the carry-over ledger. Quietly restating the task in smaller terms is the
+subtlest way to lose it: every gate downstream then passes honestly, on a task
+that shrank without anyone deciding it should.
+
 ## Output
 
 Everything resolved goes into the **task brief**, seeded from
 [`templates/brief.md`](../templates/brief.md) and committed to
-`docs/superpowers/specs/YYYY-MM-DD-<topic>-brief.md` — scope, users, UI verdict,
-constraints, locked decisions, the autonomy table, done-criteria, open
-assumptions. Seed the template only when the file is absent; never overwrite an
-existing brief.
+`docs/superpowers/specs/YYYY-MM-DD-<topic>-brief.md` — scope, **the REQ table**,
+users, UI verdict, constraints, locked decisions, the autonomy table,
+done-criteria, open assumptions. Seed the template only when the file is absent;
+never overwrite an existing brief.
+
+Alongside it, seed the **carry-over ledger** from
+[`templates/carryover.md`](../templates/carryover.md) at
+`…-carryover.md` — append-only, written by every later stage, read in full by
+stage 10. Anything deferred, dropped, or half-done from here on goes there the
+moment it's said: **deferred out loud is forgotten.**
 
 Plus, where the session produced them: an updated `CONTEXT.md` and any ADRs, each
 written as the decision landed.

package/plugins/task-pipeline/skills/task-pipeline/references/loop-guard.md

@@ -0,0 +1,100 @@
+# Loop guard — breaking churn, cross-cutting
+
+Any stage that can repeat can also **churn**: a later pass undoing what an earlier
+pass in the same run already did, two shapes alternating, the same file rewritten
+round after round with no new information. Churn looks like progress and consumes
+a run.
+
+This file is the detector and the break protocol. It binds every repeating loop in
+the pipeline: the stage-5 fix loop, a stage re-entered after a failed gate, the
+per-module program loop ([`decomposition.md`](decomposition.md)), and any
+audit → fix → audit cycle.
+
+## Bookkeeping — the thing that makes detection mechanical
+
+You cannot detect churn from memory, especially after compaction. Every repeating
+pass appends one line to the run's ledger (`.task-pipeline/build/<plan>/progress.md`
+for stage 5; `.task-pipeline/run.md` for stage-level and program-level loops):
+
+```
+touch: <file> — pass <N> (<stage|round|module>) — reason: <finding id / gate item>
+```
+
+One line per file per pass. The reason must name **what forced the edit** — a
+finding id, a failed gate item, an operator instruction. "Cleanup", "polish" and
+"while I was there" are not reasons; they are churn with better manners.
+
+## Detection — any one of these trips the guard
+
+1. **Revert-oscillation.** An edit restores something an earlier pass in this run
+   deliberately removed, or re-removes what an earlier pass added. Shape A → B → A.
+2. **Repeat touch without new information.** The same file is edited in two
+   consecutive passes and the second pass's `reason` is the same finding/gate item
+   as the first — the fix did not fix it, or the two passes disagree about what
+   "fixed" means.
+3. **Finding resurrection.** A finding whose text (normalized) matches one already
+   marked ADDRESSED or parked-with-ruling in this run comes back.
+4. **Gate ping-pong.** The same stage is re-entered for the third time on the same
+   artifact, or two adjacent stages hand work back and forth (spec ⇄ plan,
+   plan ⇄ build) more than twice.
+5. **Cross-loop contradiction.** A pass in one loop edits a file that a *different*
+   loop (another task, another module) already closed in this run — two owners for
+   one file.
+
+Caps that trip the guard by themselves: **5 fix rounds** per task
+([`build.md`](build.md)), **2 re-entries** per stage per artifact, **3 passes** per
+module in the program loop.
+
+## The break protocol
+
+When the guard trips, **stop editing immediately**. Do not dispatch another fix, do
+not "just try one more thing". Then, in this order:
+
+1. **Freeze and name it.** Write the oscillation down in the ledger and to the
+   operator: shape **A** vs shape **B**, one line each, plus who is asking for each
+   (a finding, the plan's text, the spec, a gate check, an operator instruction) and
+   the evidence for each — `file:line`, the failing command, the review verdict.
+2. **Find the layer that owns the conflict.** Churn almost always means a decision
+   is being re-litigated at the wrong altitude:
+   - two findings disagree → the **review rubric** decides
+     ([`review.md`](review.md)); if it genuinely doesn't, it's a spec question;
+   - a finding contradicts the plan → the **operator** decides which governs
+     (never dismiss the finding, never fix against the plan silently);
+   - the plan contradicts the spec → back to **stage 4** with the evidence;
+   - the spec is ambiguous or wrong → back to **stage 3**, and if the ambiguity was
+     an unresolved intake question, say so — that is a stage-0 miss worth recording;
+   - two modules claim the same file or entity → back to **decomposition**: the cut
+     is wrong.
+   **Never resolve a higher-layer conflict inside a lower loop.** Patching code to
+   satisfy two contradictory requirements is how a run burns its remaining budget.
+3. **Re-plan the check.** Replace whatever ad-hoc verification was running with an
+   explicit ordered checklist: every disputed item, one line each, in dependency
+   order, with a single owner and a single verification command per item. Write it
+   to the ledger before touching anything.
+4. **Go in order, one at a time.** Verify item 1 → if it fails, fix only item 1 →
+   re-verify only item 1 → commit → item 2. No parallel edits, no bundled fixes, no
+   opportunistic cleanup in the same commit. The point is that each change has one
+   reason and one proof.
+5. **Re-check the whole list once** at the end, in the same order. If a later item
+   broke an earlier one, that pair is the real conflict — escalate it per step 2
+   instead of looping again.
+6. **Record the ruling.** Ledger line: `loop-guard: <A vs B> — ruling: <what governs
+   and why> — items: <N> verified in order`. The final review reads it.
+
+## When to stop and hand back
+
+If step 2 lands on "the operator decides", or a cap is hit a second time after a
+re-planned pass, **stop and report BLOCKED** with: the two shapes, the evidence, the
+history of passes, and your recommendation. That is a complete, honest hand-back —
+far cheaper than a third round of the same argument.
+
+## Rationalizations
+
+| Excuse | Reality |
+|---|---|
+| "One more pass and it converges" | Two passes with the same reason already proved it doesn't. The disagreement is above the code. |
+| "I'll just revert to what worked" | That is the oscillation, not the exit. Name A and B first. |
+| "The reviewer keeps changing its mind" | Different findings on the same lines mean the requirement is ambiguous. That's a spec question. |
+| "Tidying while I'm in the file" | Untracked edits are what make churn invisible. One reason per change, in the ledger. |
+| "Logging the loop is bureaucracy" | Detection needs a record; after compaction the ledger is the only memory that survives. |
+| "It's faster than escalating" | A run that spends its budget re-deciding a spec question delivers nothing. Escalation costs one message. |

package/plugins/task-pipeline/skills/task-pipeline/references/planning.md

@@ -0,0 +1,193 @@
+# Plan — stage 4, built in
+
+Turning the spec into an implementation plan a **zero-context implementer** can
+execute task by task without reading the spec, the chat, or the rest of the plan.
+Built into this skill; nothing to install.
+
+> Ported from the `writing-plans` skill in
+> [obra/superpowers](https://github.com/obra/superpowers) (MIT — see `LICENSE` →
+> *Third-party*), extended with the dependency graph, parallel groups and
+> file-ownership rules this pipeline's stage-5 subagent build depends on.
+
+## Audience
+
+Assume a skilled developer who knows nothing about this codebase, this domain or
+this toolset, has questionable taste, and will read **only their own task**.
+Everything they need is in that task: exact paths, complete code, exact commands,
+expected output. DRY. YAGNI. TDD. Frequent commits.
+
+Path: `docs/superpowers/plans/YYYY-MM-DD-<topic>.md` — same `<topic>` slug as the
+brief and the spec.
+
+## Before writing tasks
+
+**Scope check.** If the spec covers several independent subsystems, split it into
+one plan per subsystem; each plan must produce working, testable software on its
+own.
+
+**Map the file structure.** List every file that will be created or modified and
+what each one owns. This is where decomposition gets locked in:
+
+- One clear responsibility per file; clear boundaries, defined interfaces.
+- Files that change together live together. Split by responsibility, not by
+  technical layer.
+- Follow the existing codebase's patterns. Don't unilaterally restructure — but if
+  a file you're modifying has grown unwieldy, planning its split is fair.
+
+**Draw the dependency graph.** Which task needs what from which. Then group tasks
+into **parallel groups** in topological order, and tag each task
+`depends: [task ids]`.
+
+**File ownership is exclusive within a group.** No two tasks in the same parallel
+group write the same file — that is the rule that makes stage-5 fan-out safe.
+Sequential integration/glue tasks sit *between* groups.
+
+## Task right-sizing
+
+A task is the smallest unit that carries its own test cycle and is worth a fresh
+reviewer's gate. Fold setup, configuration, scaffolding and docs into the task
+whose deliverable needs them. Split only where a reviewer could meaningfully reject
+one task while approving its neighbor. Every task ends with an independently
+testable deliverable.
+
+Each **step** inside a task is one action, 2–5 minutes: write the failing test →
+run it and watch it fail → minimal implementation → run it and watch it pass →
+commit.
+
+## Plan header — required
+
+```markdown
+# <Feature> — implementation plan
+
+> **For agentic workers:** execute this plan task-by-task under the task-pipeline
+> stage-5 build doctrine — isolated workspace, one implementer per task, a review
+> with all three verdicts after each (spec compliance, REQ satisfied, code
+> quality). Steps use `- [ ]` checkboxes.
+
+**Goal:** <one sentence>
+
+**Architecture:** <2–3 sentences>
+
+**Tech stack:** <key technologies>
+
+**Spec:** docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
+
+## Global constraints
+
+<the spec's project-wide requirements — version floors, dependency limits, naming
+and copy rules, platform requirements — one line each, exact values copied
+verbatim from the spec. Every task's requirements implicitly include this section.>
+
+## Execution order
+
+| Group | Tasks | Runs after |
+|---|---|---|
+| A | 1, 2 | — |
+| B | 3 | A |
+
+---
+```
+
+## Task structure — required
+
+````markdown
+### Task N: <component>
+
+**Depends:** [task ids, or —]
+
+**Implements:** REQ-003, REQ-007 — *(the brief's requirement ids this task
+delivers, or `—` for pure glue/infrastructure tasks. Quote each REQ's one-line
+statement under the DoD so the zero-context implementer sees the intent, not just
+the instruction.)*
+
+**Files:**
+- Create: `exact/path/to/file.py`
+- Modify: `exact/path/to/existing.py:123-145`
+- Test: `tests/exact/path/to/test_file.py`
+
+**Interfaces:**
+- Consumes: <what this task uses from earlier tasks — exact signatures>
+- Produces: <what later tasks rely on — exact names, parameter and return types.
+  The implementer sees only this task; this block is how they learn the names
+  neighboring tasks use.>
+
+**Definition of done:** <observable, verifiable conditions — tests green, behavior
+demonstrated, docs updated in this same change>
+
+- [ ] **Step 1: write the failing test**
+
+```python
+def test_specific_behavior():
+    assert function(input) == expected
+```
+
+- [ ] **Step 2: run it and confirm it fails**
+
+Run: `pytest tests/path/test_file.py::test_specific_behavior -v`
+Expected: FAIL — `NameError: name 'function' is not defined`
+
+- [ ] **Step 3: minimal implementation**
+
+```python
+def function(value):
+    return expected
+```
+
+- [ ] **Step 4: run it and confirm it passes**
+
+Run: `pytest tests/path/test_file.py::test_specific_behavior -v`
+Expected: PASS
+
+- [ ] **Step 5: commit**
+
+```bash
+git add tests/path/test_file.py src/path/file.py
+git commit -m "feat: <what changed>"
+```
+````
+
+For UI tasks, every task that builds user-facing behavior names the **scenario
+ID(s)** and `SCR-` screen(s) it implements, and its DoD includes satisfying them
+**and** updating the affected super-ux layers in the same change.
+
+## No placeholders
+
+These are plan failures. Never write them:
+
+- "TBD", "TODO", "implement later", "fill in details"
+- "Add appropriate error handling" / "add validation" / "handle edge cases"
+- "Write tests for the above" without the actual test code
+- "Similar to Task N" — repeat the code; tasks get read out of order
+- A step that says what to do without showing how (code steps need code blocks)
+- References to types, functions or methods no task defines
+
+## Self-review — before handing off
+
+A checklist you run yourself, inline. No subagent:
+
+1. **REQ coverage — set equality, not a feeling.** Collect every `Implements:` id
+   across all tasks and compare it to the brief's REQ table. The two sets must be
+   **equal**: a REQ with no task is scope silently lost; an `Implements:` id that
+   isn't in the brief is either a typo or work nobody asked for. Print the
+   difference and fix it before anything else — this seam is where scope leaks.
+2. **Spec coverage:** walk each spec requirement. Point at the task that implements
+   it. A requirement with no task → add the task.
+3. **Placeholder scan:** search the plan for every pattern above. Fix.
+4. **Name and type consistency:** signatures, property names and types used in
+   later tasks match what earlier tasks defined. `clearLayers()` in Task 3 and
+   `clearFullLayers()` in Task 7 is a bug, not a style difference.
+5. **Parallel safety:** no two tasks in the same group write the same file; every
+   `depends:` points at a task that really produces what's consumed.
+6. **DoD present and verifiable** on every task.
+
+## GATE (auto)
+
+**Set equality first:** the REQ ids in the brief equal the union of `Implements:`
+across the plan's tasks. A non-empty difference fails the gate and is reported as
+the explicit list of dropped (or invented) requirements — this seam is where scope
+leaks, so the check is mechanical, never a judgement call.
+
+Then: every spec requirement maps to a task; no placeholders; names and types
+consistent across tasks; parallel-group tasks share no files; each task has a
+verifiable DoD. UI tasks carry their scenario IDs and `SCR-` screens. Verify all of
+it yourself and stop on failure — this gate has no operator in it.

package/plugins/task-pipeline/skills/task-pipeline/references/review.md

@@ -0,0 +1,173 @@
+# Review — the rubric and the prompts, built in
+
+Used by stage 5's per-task reviews, its scoped re-reviews and its final
+whole-branch review ([`build.md`](build.md)). Built into this skill; nothing to
+install.
+
+> Ported from the `requesting-code-review` skill and the reviewer prompts in
+> [obra/superpowers](https://github.com/obra/superpowers) (MIT — see `LICENSE` →
+> *Third-party*), condensed into one rubric plus three copy-paste prompts, with the
+> external helper scripts replaced by plain git commands so the doctrine works on
+> any agent.
+
+## The diff package
+
+A reviewer never re-derives the diff with a dozen git calls, and the diff never
+enters **your** context. Write it to one file and pass the path (`$WORKSPACE` is
+this plan's git-ignored directory, `.task-pipeline/build/<plan-basename>/` — see
+[`build.md`](build.md)):
+
+```bash
+{ git log --oneline "$BASE..$HEAD"
+  echo
+  git diff --stat "$BASE..$HEAD"
+  echo
+  git diff -U10 "$BASE..$HEAD"
+} > "$WORKSPACE/review-task-$N-$(git rev-parse --short "$HEAD").md"
+```
+
+`BASE` is the commit you recorded **before** dispatching the implementer — never
+`HEAD~1`, which silently drops every commit but the last of a multi-commit task.
+For a scoped re-review, `BASE` is the head the previous review saw. For the final
+review, `BASE` is `git merge-base main HEAD`.
+
+Never dispatch a reviewer without a diff file.
+
+## Reviewer inputs
+
+Four things, three of them paths:
+
+1. The **task brief** file — what was required.
+2. The **implementer report** file — what was done, with the test evidence.
+3. The **diff package** path.
+4. The **Global Constraints** that bind this task — copied **verbatim** from the
+   plan: exact values, exact formats, stated relationships ("same layout as X",
+   "matches Y"). This block is the reviewer's attention lens.
+
+## Controller rules
+
+- **Never pre-judge.** Don't tell a reviewer to ignore something, don't cap a
+  severity, don't explain why a finding would be a false positive. If your prompt
+  contains "don't flag", "at most Minor", or "the plan chose this" — stop: you're
+  buying yourself a shorter loop with an unreviewed defect. Let the finding come and
+  adjudicate it in the loop.
+- **Don't ask a reviewer to re-run tests** the implementer already ran on the same
+  code; the report carries the evidence.
+- **No open-ended directives** ("check all uses", "run race tests if useful")
+  without a concrete, task-specific reason.
+
+## The rubric
+
+Review in this order; stop reading the diff only when you've covered all of it.
+
+1. **Spec compliance.** Every requirement in the brief: met, partially met, or
+   missing. Anything built that the brief did *not* ask for is scope creep — flag
+   it, even when it's nice.
+2. **REQ satisfaction.** Read the task's `Implements:` requirement statements, not
+   just its instructions, and judge the diff against **those**. A task can satisfy
+   every line of its brief and still miss the requirement it exists to deliver —
+   that gap is invisible one level down, which is why it is asked for here.
+3. **Correctness.** Logic errors, off-by-one, wrong operator, unhandled `None`/nil,
+   race conditions, resource leaks, wrong error propagation. State the concrete
+   input or state that produces the wrong output — a finding without a failure
+   scenario is an opinion.
+4. **Global constraints.** Exact values, formats and relationships from the
+   constraints block. Approximations are failures.
+5. **Test honesty.** Tests assert on real behavior, not on mocks. No test that
+   passes regardless of the production code. No `skip`/`xfail`/commented assertion
+   smuggling a red suite past a gate. New behavior has a covering test; the failure
+   path has one too.
+6. **Error handling and degradation.** Every external call (network, DB, file, MCP,
+   API) handles failure, and the failure is reported honestly rather than swallowed.
+7. **Boundaries and clarity.** One responsibility per unit; names that say what the
+   thing is; no duplication of a logic block that should be shared; nothing left
+   dead.
+8. **Security.** No secrets in code, logs or fixtures; input validated at the
+   boundary; no new injection or path-traversal surface.
+9. **Docs in the same change.** Module docs, runbooks and (for UI work) the
+   super-ux layers updated alongside the code, not deferred.
+
+**Severities:**
+
+- **Critical** — wrong behavior, data loss, security hole, a red or dishonest test
+  suite. Blocks.
+- **Important** — a real defect or spec gap that will bite: missing requirement,
+  unhandled failure path, a magic value the constraints named. Blocks.
+- **Minor** — style, naming, a nit with no behavioral consequence. Never blocks;
+  goes to the ledger.
+- **⚠️ Cannot verify from diff** — the requirement lives in unchanged code or spans
+  tasks. Not a blocker for the reviewer; the controller resolves it.
+
+Formatting nits that don't change meaning are not findings. Praise is not a
+finding either.
+
+## Prompt — task review
+
+> You are reviewing one task of an implementation plan. Read, in order:
+> `<brief path>` (the requirements), `<report path>` (what the implementer did and
+> the test evidence), `<diff package path>` (commits, stat, full diff).
+>
+> Global constraints binding this task:
+> ```
+> <verbatim block>
+> ```
+>
+> Produce three verdicts, all required:
+> 1. **Spec compliance:** ✅ or ❌. List every requirement as met / partial /
+>    missing, and list anything implemented that was not asked for.
+> 2. **REQ satisfied:** ✅ or ❌ per `Implements:` id. The brief quotes each
+>    requirement's statement — judge the diff against **that statement**, not
+>    against the task's instructions. A task can follow every instruction and still
+>    miss the requirement it exists to deliver; say so when it does.
+> 3. **Code quality:** approved or not. Findings only, each as
+>    `severity — file:line — the defect — the failure scenario (concrete input or
+>    state → wrong result)`. Severities: Critical, Important, Minor. Use
+>    `⚠️ cannot verify from diff` for anything you can't judge from the diff alone.
+>
+> Review against the rubric: correctness, global constraints, test honesty (tests
+> assert real behavior, not mocks; no skipped/empty assertions), error handling and
+> honest degradation, boundaries and naming, security and secrets, docs updated in
+> the same change. No praise, no formatting nits that don't change meaning. Do not
+> re-run the tests the report already covers. Return the verdicts and findings as
+> your final message — nothing else.
+
+## Prompt — scoped re-review
+
+> A previous review of this task raised the findings below. The implementer has
+> since pushed fixes. Read `<brief path>`, `<report path>` (its fix report is
+> appended at the end) and `<fix diff package path>` — the fix diff **only**.
+>
+> Open findings:
+> ```
+> 1. <finding>
+> 2. <finding>
+> ```
+>
+> For each finding return `ADDRESSED` (with the `file:line` that resolves it) or
+> `NOT ADDRESSED` (with what's still wrong). Then flag any **new** Critical or
+> Important breakage introduced by this fix diff. Out-of-scope observations about
+> code this diff didn't touch: list them separately as deferred minors — they are
+> not part of this verdict. End with: all findings addressed / N still open.
+
+## Prompt — final whole-branch review
+
+> Review this entire branch before merge. Read `<diff package path>` (merge-base to
+> HEAD) and `<spec path>`.
+>
+> Findings deferred or parked during implementation:
+> ```
+> <the ledger's minor + parked lines>
+> ```
+>
+> Judge the branch as a whole: does it deliver the spec; do the pieces fit; is
+> anything half-migrated, duplicated across tasks, or left dead; are the tests
+> honest and the suite genuinely green; is error handling consistent; are docs in
+> sync. Triage the deferred/parked list: which of those must be fixed before merge,
+> which can stand and why. Findings only, with severity and a concrete failure
+> scenario each. Return the findings as your final message.
+
+Run the final review on the **run's confirmed model** like everything else
+([`model-tiering.md`](model-tiering.md)). It is the one review that sees the whole
+change, so if the run is on a tier below the most capable one available, say so and
+offer to escalate just this dispatch — a recommendation stated out loud, never a
+silent switch (`build.md` → *Models*).