@gtrabanco/pi-agentic-workflow 0.3.0 → 0.4.1

package/README.es.md

@@ -47,7 +47,6 @@ no reciben comando propio — los componen los de arriba:
 | `/generate-docs` | Generar guías incrementales basadas en el diff. |
 | `/init-workspace` | Adaptar el andamiaje del workflow a un repositorio. |
 | `/log-session` | Añadir una entrada de sesión estructurada a `docs/LOGS.md`. |
-| `/loop-review-fold` | Revisar una unidad y plegar lo que encontró. |
 | `/plan-feature` | Dirigir el trabajo diseñado a planificación y roadmap. |
 | `/plan-fix` | Redactar un SPEC de fix por fases desde uno o varios issues. |
 | `/product-audit` | Auditar la superficie del producto, no solo el diff. |
@@ -146,8 +145,9 @@ archivo de proyecto mientras el proyecto no sea de confianza.
 
 ## Notas
 
-- Probado con Pi 0.84.3 (`pi install`, skills de paquete, `sendUserMessage` con
-  expansión de plantillas).
+- Probado con Pi 0.85.0 (2026-09-04) (`pi install`, skills de paquete, registro de
+  comandos amigables, set/clear enrutado, round-trip de consola de ajustes,
+  `sendUserMessage` con expansión de plantillas).
 - El paquete declara Pi como peer dependency; no incluye ninguna copia de Pi.
 - Las skills pueden indicar al modelo que ejecute comandos. Revísalas como con
   cualquier paquete de terceros.

package/README.md

@@ -45,7 +45,6 @@ their own — they are composed by the ones above:
 | `/generate-docs` | Generate incremental, diff-driven developer guides. |
 | `/init-workspace` | Adapt the workflow scaffold to a repository. |
 | `/log-session` | Append a structured session entry to `docs/LOGS.md`. |
-| `/loop-review-fold` | Review a unit, then fold what it found. |
 | `/plan-feature` | Route designed work into planning and the roadmap. |
 | `/plan-fix` | Draft a phased fix SPEC from one or more issues. |
 | `/product-audit` | Audit the product surface, not just the diff. |
@@ -140,8 +139,9 @@ touch the project file while the project is untrusted.
 
 ## Notes
 
-- Verified against Pi 0.84.3 (`pi install`, package skills, `sendUserMessage` with
-  prompt template expansion).
+- Verified against Pi 0.85.0 (2026-09-04) (`pi install`, package skills, friendly
+  command registration, routed set/clear, settings console round-trip, `sendUserMessage`
+  with prompt template expansion).
 - The package declares Pi as a peer dependency; it bundles no copy of Pi.
 - Skills can instruct the model to run commands. Review them as you would any
   third-party package.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gtrabanco/pi-agentic-workflow",
-  "version": "0.3.0",
+  "version": "0.4.1",
   "description": "Pi package: canonical agentic-workflow skills, friendly slash commands, and per-command model routing.",
   "keywords": [
     "pi-package",
@@ -53,6 +53,7 @@
     "@earendil-works/pi-coding-agent": "*"
   },
   "devDependencies": {
+    "@earendil-works/pi-server": "0.85.0",
     "@types/node": "^24",
     "typescript": "6"
   }

package/skills/design-feature/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: design-feature
 user-invocable: true
-version: 3.1.0
+version: 3.2.0
 argument-hint: <idea | NN-slug> [<instruction>]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -53,6 +53,34 @@ evidence → draft → cut → readiness. Its outcomes (`READY-FOR-REVIEW |
 NEEDS-EVIDENCE | NEEDS-DESIGN | NEEDS-REPLAN`) are an authoring gate, never an
 approval: only `review-spec` can approve a Product half.
 
+## Research gate (mandatory, fail-closed)
+
+Before the Product half is emitted, run the research gate in the evidence pass
+(step 2 of the ordered passes):
+
+- **Fetch the domain** — acquire **at least two externally fetched sources** on
+  the capability's domain (fetch/WebFetch/browser): how the domain defines and
+  solves this capability. Repo evidence alone cannot ground a design; the bias
+  this gate closes is designing from what the repository already believes.
+  Each fetched source becomes an evidence row (URL and access date).
+- **Cover the full definition** — the rows must state what the capability **is
+  and what it is not**, and the **user's expectation of it** — accepted and
+  rejected inputs, boundaries, semantics — not just the project's current
+  framing of it.
+- **Decompose every enunciated expectation** — expand each expectation the
+  user enunciates into the implicit case decomposition it implies **before**
+  the Product half is cut: valid and invalid values and limits, interaction
+  states, degraded mode, backend validation/filtering/parsing, alternate user
+  paths. The canonical case: a "phone number input" is not a field — it is the
+  whole case vector (prefixes/suffixes, lengths, non-text rejection, focus,
+  no-JS/JS behavior, backend filtering/validation/parsing) that the product
+  owner's one-liner hides.
+- **Fail closed** — offline, or a material question the fetches do not answer,
+  returns `NEEDS-EVIDENCE` with the named owner and next fetch: never a guess,
+  never an invented citation.
+- **Research before encode** — platform semantics a test will encode are
+  verified against authoritative documentation before the test exists (the
+  prevention half of `verification-contract`'s test-immutability contract).
 
 ## Progressive loading — resolve status before product detail
 
@@ -102,7 +130,8 @@ required resource or unresolved mandatory slot returns NEEDS_INPUT; never guess.
 - The Expectation sweep enumerates **domain conventions**, not new scope: it
   may only route each expectation to in-scope / out-of-scope / deferred — it
   never silently grows the feature beyond what the user confirms.
-- No systematic per-feature market research; no global skill/MCP discovery
+- No market or competitive research — the mandatory research gate above is
+  this skill's only external research; no global skill/MCP discovery
   sweep (`product-audit`'s job); no `--update` flag — upsert is always the
   default behavior, not an opt-in.
 - Don't build a separate `DESIGN.md` — one SPEC, two halves, always.

package/skills/evidence-grounding/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: evidence-grounding
 user-invocable: false
-version: 1.5.0
+version: 1.6.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -75,7 +75,12 @@ Authoring is progressive. Never jump from discovery to a polished artifact.
    NEEDS-DESIGN`. Follow references and topology as far as the claim requires —
    the cap is the claim, not a file count. Wide reading that is not this turn's
    own goes out to the delegate-only role: [references/DELEGATION.md](references/DELEGATION.md)
-   is its contract and the only shape its findings may arrive in. **If you are
+   is its contract and the only shape its findings may arrive in. **Web pass** —
+   when repository evidence cannot answer a bounded question, and always at
+   design stage where `design-feature`'s research gate makes it mandatory, fetch
+   external sources and freeze each as an evidence row (URL and access date);
+   offline or unanswered material questions return `NEEDS-EVIDENCE`, never an
+   invented citation. **If you are
    that reader** — you did not write the artifact and are not writing it — the
    contract governs you: skip steps 1, 3 and 4, and produce the artifact under
    whatever name the invitation used; the position decides, not the label.

package/skills/evidence-grounding/references/ROWS.md

@@ -28,7 +28,7 @@ id | claim-or-obligation | authority-kind | source-and-location | observed-revis
 | Value | Means | Acceptable `source-and-location` |
 |---|---|---|
 | `repository` | observed in tracked source, config, or a generated artifact | `path:line` or `path` + symbol/test name |
-| `document` | a project doc, template, SPEC, roadmap or fix-index row | `path:section` |
+| `document` | a project doc, template, SPEC, roadmap or fix-index row, or fetched external documentation | `path:section`, or the URL plus access date for a fetched source (`https://… (fetched YYYY-MM-DD)`) |
 | `ledger` | a frozen Normalized Repository State fact/decision, or an accepted architectural decision | `REPOSITORY_STATE.md` row ID (`F0nn`/`AD-nnn`) |
 | `forge` | an issue, PR, review, or CI record | absolute issue/PR URL |
 | `user` | an explicit user decision recorded this unit or in `decisions.md` | dated `decisions.md` / SPEC `## Amendments` row |

package/skills/execute-phase/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: execute-phase
 user-invocable: true
-version: 4.0.2
+version: 4.2.0
 argument-hint: <NN> [P<k>] | --fix <n> [P<k>] | [--max-attempts N] [--force]
 allowed-tools: [Bash, Read, Edit, Write, MultiEdit]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
@@ -105,8 +105,9 @@ use its fallback; never skip the workflow step.
 
 Planned by `plan-feature`/`plan-fix`; executes their SPEC. Explicit phases may
 hand off to `review-change` at layer/accumulation/sensitivity checkpoints and must
-at unit end. Unit-loop skips intermediate checkpoints and recommends
-`loop-review-fold` after opening the PR; direct `review-change` remains manual.
+at unit end. Unit-loop skips intermediate checkpoints and recommends the manual
+`/fold-findings` → re-run `/review-change` path after opening the PR; direct
+`review-change` remains the manual entry.
 Independent work stays a proposal. A finished unit always opens its PR and flips
 to `done`; `audit-pr` gates merge. Every invocation prints the next step.
 
@@ -117,4 +118,5 @@ to `done`; `audit-pr` gates merge. Every invocation prints the next step.
   committed on the correct branch with nothing bundled beyond scope.
 - `git status --porcelain` is empty and an open-PR branch has nothing unpushed.
 - A finished unit is `done`, has an opened PR (URL printed), and recommends the
-  mandatory `/loop-review-fold` hand-off with direct `/review-change` as manual alternative.
+  mandatory `/fold-findings` → re-run `/review-change` hand-off, with `/audit-pr`
+  as the merge gate.

package/skills/execute-phase/references/BATCH_AND_PORTABILITY.md

@@ -8,8 +8,9 @@ The normal omitted-phase command is already the batch:
 ```
 
 It selects every unfinished phase, gates and commits each one, skips
-intermediate review stops, opens the PR, then recommends
-`/loop-review-fold`. An explicit `P<n>` keeps the atomic/manual path.
+intermediate review stops, opens the PR, then recommends the manual
+`/fold-findings` → re-run `/review-change` path. An explicit `P<n>` keeps the
+atomic/manual path.
 
 ### Fresh-context driver (recommended for cheap models)
 
@@ -19,8 +20,8 @@ slice, and compact receipts. An external driver may implement the same contract:
 
 1. Call `workflow-status` and choose the next unfinished phase.
 2. Invoke `/execute-phase <unit> P<n>` on the cheap tool-capable tier.
-3. Repeat `CONTINUE`; route `READY_FOR_REVIEW` to `/loop-review-fold` on the
-   required review/fold tiers.
+3. Repeat `CONTINUE`; route `READY_FOR_REVIEW` to `/fold-findings`, then re-run
+   `/review-change`, on the required review/fold tiers.
 4. Stop on `NEEDS_INPUT`, `HALT`, repeated unchanged evidence, or the declared
    attempt budget.
 

package/skills/execute-phase/references/CLOSEOUT.md

@@ -22,8 +22,9 @@ Write `docs/features/<NN>-<slug>/CHECKLIST.md`: schema migration applied (if any
 ## Review checkpoint & finishing a unit
 
 **Independent final review is mandatory — every unit gets one before merge.**
-Recommend `loop-review-fold` because it preserves fresh review contexts while
-handling bounded corrections; direct `review-change` is the manual path. Review
+Recommend the manual `/fold-findings` → re-run `/review-change` path because it
+preserves fresh review contexts while handling bounded corrections; direct
+`review-change` remains the manual entry. Review
 runs in its own turn (hand-off, not composed): a skill's model and
 effort are fixed at turn start, so invoking `review-change` from here would run it at
 execute-phase's `sonnet`/`medium` rather than its own `opus`/`high` — under-powering
@@ -45,8 +46,8 @@ one).
 **Finishing a unit (single-pass, `--fix`, or a feature's final phase): the last step
 is always an open PR.** Mark the unit `done`, commit the flip, push, and `gh pr create`
 (see the mode steps above) — regardless of the review/audit still to come. Then hand
-off to `/loop-review-fold` (recommended) or direct `/review-change`, which feeds
-`audit-pr` (the merge gate).
+off to `/fold-findings`, then re-run `/review-change`, which feeds `audit-pr`
+(the merge gate).
 
 **Adversarial pass at that mandatory end review.** `review-change` evaluates its
 own recommendation checklist there (`L`/sensitive change, reviewer not the

package/skills/execute-phase/references/FOLDING.md

@@ -17,6 +17,8 @@ end up "solved" locally but absent from the merged PR:
 ```
 ✓ Fixes implemented (scope: only the routed findings — nothing extra)
 ✓ Gate RUN and green (exit codes pasted)
+✓ Never edit an existing test's expectation to match behaviour — a setup
+  repair keeps assertions at least as strong and never touches expectations
 ✓ Per-phase / unit docs updated where the finding touched them
   (known-issues.md entry resolved? progress.md notes the fold)
 ✓ Each folded finding's row in the unit's `review-findings.md` ledger (if one
@@ -39,8 +41,7 @@ Final-phase / single-pass / fix hand-off:
 <unit> implemented, gate green, marked done.
 PR opened: <FULL PR URL — always printed here; not every agent shows open PRs>
 Roadmap/fix-index row: done · #<n> (linked and pushed)
-→ Next: /loop-review-fold <unit> (recommended review/fold router; unresolved findings go to triage/replan)
-  · manual path → /review-change
+→ Next: /fold-findings, then re-run /review-change (unresolved findings go to triage/replan)
   · clean    → /audit-pr (merge gate) → human merges
   · findings → fold fix-now into this PR; independent work remains a proposal until user triage; re-review
   · docs site declared (documentation map has a `Docs site` block) →

package/skills/execute-phase/references/UNIT_LOOP.md

@@ -82,7 +82,6 @@ UNIT LOOP — <unit> COMPLETE
 Phases: <n> · Commits: <sha list> · Acceptance: <blob> · Gate: PASS
 PR: <url>
 
-→ Next: /loop-review-fold <unit> — select the persisted review/fold route, then triage or replan unresolved findings
-  · manual path → /review-change, then /fold-findings and re-review as required
+→ Next: /fold-findings, then re-run /review-change on the changed HEAD — triage or replan unresolved findings
   · merge gate after REVIEW-PASS → /audit-pr
 ```

package/skills/fold-findings/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fold-findings
 user-invocable: true
-version: 1.2.2
+version: 1.3.0
 argument-hint: [finding-id …]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT

package/skills/fold-findings/references/FOLD_POLICY.md

@@ -31,6 +31,8 @@ A finding is `FOLDED` only when **all** of these hold:
 ✗ Adding a known-issues.md / backlog entry instead of fixing the code
 ✗ A decisions.md tradeoff note that accepts the defect as-is
 ✗ Deleting, skipping (.skip, .only elsewhere), or loosening a test to make it pass
+✗ Editing an existing test's expectation to match behaviour — a setup repair
+  may only keep assertions at least as strong and never touch expectations
 ✗ eslint-disable / @ts-ignore / equivalent suppression AS the fix
 ✗ A TODO/FIXME stub left in place of the actual fix
 ✗ Ticking `folded: yes` without a reviewer-mappable diff behind it
@@ -41,3 +43,8 @@ A finding is `FOLDED` only when **all** of these hold:
 
 Something forbidden looks like the only option → stop, do not apply it, and
 mark the finding `DISPUTED` or `BLOCKED` with the reason instead.
+
+Never edit an existing test's expectation to match behaviour: a setup repair may
+only keep assertions at least as strong and never touch expectations; the
+test-immutability contract (`verification-contract`) owns the sole amendment
+path.

package/skills/plan-feature-scaffold/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plan-feature-scaffold
 user-invocable: false
-version: 2.1.0
+version: 2.2.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -56,6 +56,18 @@ The [verification contract](<../verification-contract/SKILL.md>) owns the
 `ACCEPTANCE.md` schema, validation ladder, and anti-weakening rules. Consume it
 after the engineering plan is complete and before registering `planned`.
 
+## Research and reference trace (plan stage)
+
+- **Conditional web research.** Plan-stage research runs only when a bounded
+  question (ROWS.md Q1–Q5) cannot be answered from repository evidence: run
+  exactly one web pass before the phases are emitted and freeze what it
+  returns as evidence rows (URL and access date). A question the repository
+  answers is never re-fetched.
+- **Mandatory reference trace.** Affected code is located by symbol/reference
+  search — LSP/serena when the environment offers it, grep otherwise — and the
+  blast radius is derived from that search, never from model memory: added or
+  changed code can break callers the plan must name.
+
 ## Guardrails
 
 - Docs only. No source edits, migrations, or dependencies.

package/skills/plan-fix/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plan-fix
 user-invocable: true
-version: 3.0.1
+version: 3.1.0
 argument-hint: <issue-number> [<issue-number> …]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -68,6 +68,18 @@ One or more GitHub issue numbers from this repo, space-separated.
 - One local commit with SPEC and `docs/fix/README.md` (`pending`, all merged issues).
 - **Stop: do not push/open PR.** Hand off to `review-plan`, then `execute-phase --fix`.
 
+## Research and reference trace (plan stage)
+
+- **Conditional web research.** Plan-stage research runs only when a bounded
+  question (ROWS.md Q1–Q5) cannot be answered from repository evidence: run
+  exactly one web pass before the phases are emitted and freeze what it
+  returns as evidence rows (URL and access date). A question the repository
+  answers is never re-fetched.
+- **Mandatory reference trace.** Affected code is located by symbol/reference
+  search — LSP/serena when the environment offers it, grep otherwise — and the
+  blast radius is derived from that search, never from model memory: added or
+  changed code can break callers the plan must name.
+
 ## Hard rules
 
 - Honor Workflow conventions: create `fix/<n>-<topic>` first, never `main`; gate,

package/skills/pre-execution-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: pre-execution-review
 user-invocable: false
-version: 1.5.0
+version: 1.7.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >

package/skills/pre-execution-review/references/LEDGERS.md

@@ -135,7 +135,7 @@ and is out of scope; a copy or shell rewrite stays the reviewer's job.
 ```text
 ledger-ownership@1
 truth-class | ledger | owner | annotator | annotator-token | validator
-review-findings | docs/features/<NN>-<slug>/review-findings.md · docs/fix/<issue>-<topic>/review-findings.md | review-change:finding-rows + review-change:review-mark + audit-pr:audit-rows + triage-issue:triage-rows + fold-findings:folded-flag | scripts/ledger-provenance.mjs | · fold <sha> + · ticked <sha> + · REOPENED | node --test scripts/ledger-provenance.test.mjs
+review-findings | docs/features/<NN>-<slug>/review-findings.md · docs/fix/<issue>-<topic>/review-findings.md | review-change:finding-rows + review-change:finding-mark + review-change:review-mark + audit-pr:audit-rows + triage-issue:triage-rows + fold-findings:folded-flag | scripts/ledger-provenance.mjs | · fold <sha> + · ticked <sha> + · REOPENED | node --test scripts/ledger-provenance.test.mjs
 planning-findings | docs/features/<NN>-<slug>/planning-findings.md · docs/fix/<issue>-<topic>/planning-findings.md | review-spec:spec-stage-rows + review-plan:plan-stage-rows + design-feature:product-class-resolutions + plan-feature:plan-class-resolutions + plan-fix:fix-plan-class-resolutions + fold-findings:source-class-resolutions | none | none | node --test scripts/pre-execution-quality.test.mjs
 progress | docs/features/<NN>-<slug>/progress.md · docs/fix/<issue>-<topic>/progress.md | plan-feature-scaffold:create + execute-phase:phase-entries + execute-phase:gate-rejection-traces + review-spec:product-receipt + review-plan:plan-receipt | none | none | node --test scripts/pre-execution-sensor.test.mjs
 known-issues | docs/features/<NN>-<slug>/known-issues.md · docs/fix/<issue>-<topic>/known-issues.md | plan-feature-scaffold:create + execute-phase:blocker-entries-and-status | none | none | node --test scripts/ledger-ownership.test.mjs
@@ -172,3 +172,25 @@ REVIEW-RAN | HEAD <40-hex sha> | n/a | n/a | review-mark | n/a | n/a
 other cells carry `n/a` because the row reports no finding — which keeps it out of
 the fix-now projection, `fold-findings`, and the annotator (its pattern matches
 `F<n>` ids only). A mark says a review ran, never that the candidate passed.
+
+### The durable finding mark
+
+A candidate finding that verifies — or refutes — before persistence gets a
+per-finding durable signature of its own, under `review-change:finding-mark`.
+This is the fix/161 extension of the feature-28 treatment: a verdict has a
+signature, so must the individual finding. The single writer of every finding mark is `review-change`; nothing else appends one.
+
+```text
+finding-mark@1
+id | file:line | axis | severity | class | route | folded
+VF-<n> | <file:line> · reviewer review-change · HEAD <40-hex sha> · recheck <method + reproducer> | <axis> | confirmed | finding-mark | n/a | n/a
+```
+
+`VF-` ids are deliberately outside the `F<n>` range the provenance annotator's
+row pattern matches, so a finding mark is invisible to the recount, to
+`--check`, to `--annotate`, and to the fix-now projection. A `confirmed`
+finding's row carries the mark; a `refuted` candidate carries its
+counter-evidence in the same report and **never becomes a row**, a fold task,
+or a re-review trigger. The mark's `confirmed | refuted` value and the
+`recheck` cell (the method the finding's axis demands) are what let a driver
+outside the repo consume the verification the review performed.

package/skills/pre-execution-review/references/POLICY.md

@@ -86,7 +86,7 @@ outside this policy and can never be translated into a PASS.
 - An automatic forge issue. No route in the pre-execution set — `evidence-grounding`
   readiness, `review-spec`, `review-plan`, `plan-feature-scaffold`, `plan-fix`,
   `execute-phase`, `workflow-status`, `ship-roadmap`, `review-change`,
-  `loop-review-fold`, `audit-pr` — creates one for a planning gap, and none defers
+  `audit-pr` — creates one for a planning gap, and none defers
   an obligation to a future issue: the row stays in the unit's ledger, open, until
   the **user** amends the governing SPEC. A blocker that says "file an issue" is a
   contract violation, not a workaround, and a `deferred` row without an amendment is

package/skills/review-change/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-change
 user-invocable: true
-version: 3.0.0
+version: 3.2.1
 argument-hint: <path-or-glob> [--adversarial N] [--synthesize]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -81,19 +81,19 @@ Every axis maps to a skill of the workflow's **own internal review pack**
 | API ergonomics / usage docs (inline pass) | if API | if API | flags/help | ✓✓ | ✓ |
 
 > `review-implementation` (the single classifier over the synthesized table —
-> process step 7) and `review-debt` (the debt transform over the classified
-> table — process step 8) are not axis finders: they run once per review, not
+> process step 8) and `review-debt` (the debt transform over the classified
+> table — process step 9) are not axis finders: they run once per review, not
 > per axis.
 
 ## Isolation rule (default — every pass, not only adversarial)
 
-Each applicable pass, the classifier (step 7), and debt transform (step 8) runs
+Each applicable pass, the verification pass (step 6), the classifier (step 8), and debt transform (step 9) runs
 **isolated/context-clean** and returns only its fixed findings table plus
 `PASS | FAIL`—never diff or prose. Spawn one fresh subagent/headless run per
 pass; without those, use a fresh conversation. Pass only scope, its checklist,
 and Step 0 docs; cap full non-diff reads at 10 (targeted ≤50-line reads/greps
 excluded). The orchestrator retains tables, not sources, and fuses them in step
-6. Inline fallback is sequential table reduction. A pass runs at its own tier or
+7. Inline fallback is sequential table reduction. A pass runs at its own tier or
 stronger, never weaker.
 
 
@@ -143,8 +143,11 @@ only for independent proposals (D3). It is Stage 4: checkpoint reviews are
 optional, the end review is mandatory and fresh. `fix-now` folds in-unit,
 `replan-in-unit` adds user-confirmed phases, and independent work becomes
 proposals. `audit-pr` consumes only the verified PR-comment receipt, never the
-chat report; `product-audit` is the periodic sweep;
-`loop-review-fold` may run this skill fresh and route FAIL to `fold-findings`.
+chat report; `product-audit` is the periodic sweep. On `REVIEW-FAIL` the manual
+correction path is `/fold-findings`, then re-run `/review-change` on the changed
+HEAD (bounded at two cycles — a third cycle never starts without an explicit
+user instruction, per `REVIEW_PROCESS.md`); a programmatic outer driver may run
+the same review→fold sequence.
 
 ## Done when
 

package/skills/review-change/references/PERSIST_AND_DECIDE.md

@@ -16,7 +16,11 @@
    or `med` (only ledger severities; finder scale
    `critical`→`high`, `major`→`med`, `minor`→`low`): append a row
    (create the file with the header row when missing), carrying the
-   verbatim `Sev` value into `severity`; `folded` always starts `no` —
+   verbatim `Sev` value into `severity`; `folded` always starts `no` — that
+   row comes from a **confirmed** candidate only and carries its
+   `finding-mark@1` signature on a **separate `VF-` row** (reviewer, head SHA,
+   recheck + reproducer), as modeled in `LEDGERS.md` (§finding-mark@1) and the
+   fixture.
    `execute-phase`'s fold cycle is the only step that ever flips it to `yes`.
    A `low` finding is **never persisted to the fold ledger** — report-only
    note (step 13), never blocking (finders' materiality floor). Re-runs
@@ -25,7 +29,7 @@
    a re-report at a folded row's location is legitimate only as `regression of <id>`
    (fix provably failed) or `DISPUTED`; else `Fn+1`.
    **Non-fix-now findings are never written here** — they keep
-   their destinations from step 10 (outcome routing): independent future
+   their destinations from step 11 (outcome routing): independent future
    capabilities batch as proposals; only the user routes them to `triage-issue`
    (D3).
    **Commit the ledger append** — rows + `REVIEW-RAN` mark, one commit
@@ -34,7 +38,7 @@
    `REVIEW-PASS` with an open PR no ledger write happens (the SHA-bound
    receipt is the durable record): head and posted receipt stay identical.
 12. **Close out the final-review receipt before reporting.** First derive the
-   `Decision` from step 6 and persist step 11. Then, before printing any line of
+   `Decision` from step 7 and persist step 11. Then, before printing any line of
    the fixed report block or the `→ Next:` block, complete the receipt action
    below. The receipt is a precondition of the report, not a follow-up.
 
@@ -85,7 +89,7 @@
    Architectural invariants: pass | finding (<ID>) | n/a: no project invariants declared
    Receipt: current at <head SHA> | n/a: no PR | none: REVIEW-FAIL/NEEDS-DECISION
 
-   <the synthesized decision table (step 6)>
+   <the synthesized decision table (step 7)>
 
    Manual verification (a human must check):
    - <item> …
@@ -93,14 +97,17 @@
    Notes (low · report-only, never persisted):
    - <finding + evidence, or none>
 
-   Proposals (step 10): <n> — batched for the user, no issues created (D3)
+   Refuted (verified false — reported with counter-evidence, never persisted):
+   - <candidate + counter-evidence, or none>
+
+   Proposals (step 11): <n> — batched for the user, no issues created (D3)
 
    Summary: <1-2 sentences>
    Decision: REVIEW-PASS | REVIEW-FAIL | NEEDS-DECISION   (D10: review says these three; only audit-pr says MERGE-READY)
    ```
 
 14. **Next step.** The `→ Next:` block is **never one static template** — branch
-   on the `Decision` value from step 6 and emit the matching block **verbatim,
+   on the `Decision` value from step 7 and emit the matching block **verbatim,
    as multiple literal lines**. Never join the `·` sub-bullets into one prose
    line — each sub-bullet is its own line, exactly as quoted below.
    For `REVIEW-FAIL` or `NEEDS-DECISION`, list every open finding ID in the
@@ -111,9 +118,9 @@
    passing receipt was posted** (step 12):
 
    ```
-   → Next: /loop-review-fold <unit> — repair all open fix-now findings: <F1> + <F2> + <F3>,
-     then re-review changed HEADs within the bounded correction budget
-     · manual path → /fold-findings, then re-run /review-change
+   → Next: /fold-findings — repair all open fix-now findings: <F1> + <F2> + <F3>,
+     then re-run /review-change on the changed HEAD (bounded at two cycles; a
+     third cycle never starts without an explicit user instruction)
      · /audit-pr → only after the table is clean (not yet — findings open)
       · any finding routed replan-in-unit? → confirm the proposed SPEC phase(s),
         then /execute-phase on this same branch (yes: list the finding ids; no:

package/skills/review-change/references/REVIEW_PROCESS.md

@@ -78,14 +78,30 @@
    (stack-specific linters, framework skills) and they are installed, run them
    **in addition** — their findings merge into the same table. Never treat an
    absent extra as a gap; the pack already covered the axis.
-6. **Synthesize.** Fuse all findings into **one** findings table, deduped by
+6. **Verify, then synthesize.** Before fusing anything, every candidate finding
+   is **verified in an isolated context against the reviewed head's bytes** (the
+   SHA frozen in step 1) and marked `confirmed` or `refuted`. The recheck method
+   follows the finding's axis:
+   - a **code / behavioral** claim confirms only with a **failing reproducer** —
+     a red test written first and run against **unchanged code**, or
+     **reproducible command output**;
+   - a **documentation / wording** claim confirms by **direct read** of the
+     cited text (typos and wording are corrected without ceremony, no test);
+   - a **missing-documentation** claim confirms the named user path is
+     undocumented.
+   Only **confirmed** candidates flow to synthesis; a **refuted** candidate is
+   reported with its counter-evidence in the same report and never becomes a
+   row, a fold task, or a re-review trigger. The per-finding durable mark is
+   `finding-mark@1` (contract in `pre-execution-review/references/LEDGERS.md`).
+
+7. **Synthesize.** Fuse all findings into **one** findings table, deduped by
    `file:line` + axis, per the synthesis contract (the same fusion rules apply
    in the default single-reviewer case). Columns: `# | Finding | Axis | Sev |
    Evidence | Suggested fix` — **unclassified**. Overlapping signals on the same
    defect collapse into one row. Add a **`Reviewers n/N`** column when running
    in `--adversarial N` mode (omitted entirely in the default single-reviewer
    case).
-7. **Classify (once).** Run `review-implementation` over the synthesized table
+8. **Classify (once).** Run `review-implementation` over the synthesized table
    (isolated, per the *Isolation rule*) — the single classification engine
    (D5). It verifies axis coverage (every applicable axis represented; a
    missing axis is a `coverage` finding) and applies the current-unit contract:
@@ -94,17 +110,37 @@
    → the **classified decision table** (Sev, Class, WHY, impl risk, long-term
    impact, premature-opt?, Route). No per-pass or per-reviewer classification,
    no re-litigation.
-8. **Debt transform.** Run `review-debt` over the classified table — it
+9. **Debt transform.** Run `review-debt` over the classified table — it
    transforms debt-shaped findings into explicit TRIGGER-carrying debt items;
    it does not rescan the diff (SPEC contract).
-9. **Manual-verification checklist.** List what automated review **cannot** confirm
+10. **Manual-verification checklist.** List what automated review **cannot** confirm
    and a human must check — visual correctness, real-device/locale behavior, UX
    feel, perf under load, anything marked *verify*. Be explicit so the dev has zero
    doubt about what to eyeball.
-10. **Route the outcomes.** fix-now findings fold into the current unit (or gain
+11. **Route the outcomes.** fix-now findings fold into the current unit (or gain
     user-confirmed phases via replan-in-unit); decision-required stops for the
     user's decision; genuinely independent future capabilities become
     **non-blocking proposals** — batched in the report with a trigger, and
     **never** sent to `triage-issue` automatically (D3). `review-change` creates
     no backlog work. No non-fix-now finding may end without a destination — none
     silently lost.
+
+## Two-cycle cap
+
+The review→fold loop runs at most **two** review→fold cycles per unit, counted
+unit-level and family-agnostic from the ledger's `REVIEW-RAN` marks and forge
+receipts — new finding families do not reset the count. After two cycles without
+convergence, the review prints
+
+```text
+LOOP CAP REACHED — <unit>
+- Finding ids: <every open id>
+- Cycles: 2 (REVIEW-RAN marks + forge receipts)
+- Route: /triage-issue --prioritize-now <unit> F<k> … (or the programmatic outer driver)
+```
+
+A **third cycle never starts** unless the user explicitly instructs it — it is
+the user's escape, never a reviewer election. The residue routes to
+`triage-issue --prioritize-now` (or the programmatic outer driver), and a unit
+that needs a third cycle has a planning or root-cause defect, not a review
+deficit.

package/skills/review-code/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-code
 user-invocable: false
-version: 1.1.0
+version: 1.2.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -41,6 +41,8 @@ default branch. State the scope at the top of the returned table.
 ✓ No new dependency not justified in the SPEC
 ✓ Simplification: any changed block that can lose lines without losing
   behavior (cite before/after)
+✓ Reference trace: every changed symbol/API got a reference search —
+  un-updated callers are findings
 ✓ Edge cases the SPEC's dev scenarios name are actually handled in code, not
   just in tests
 

package/skills/review-implementation/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-implementation
 user-invocable: false
-version: 1.6.0
+version: 1.7.0
 argument-hint: <path-or-glob>
 allowed-tools: Read, Grep, Glob, Bash, WebFetch
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"

package/skills/review-implementation/references/CLASSIFY.md

@@ -113,7 +113,7 @@ finding in its `Route` cell.
 
 | Owning stage | Hand-off | Never |
 |---|---|---|
-| `source` | fold locally: `/loop-review-fold` → `/fold-findings` → re-review the changed HEAD | — |
+| `source` | fold locally: `/fold-findings`, then re-run `/review-change` on the changed HEAD | — |
 | `plan` | the planning author re-cuts the artifact (SPEC `## Phases`, an obligation row, an acceptance mapping, a ledger) on the same branch with the user's confirmation, then a **fresh `/review-plan <unit>`** precedes `execute-phase` | fold it in code and leave the plan describing the old build |
 | `product` | `/design-feature <unit>` repairs the half, then `/review-spec <unit>` re-judges it | patch the product claim into agreement in code |
 | `environment` / `runtime` | the existing retry/`BLOCKED` paths | translate into a PASS, or an issue |

package/skills/review-plan/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-plan
 user-invocable: true
-version: 1.4.0
+version: 1.5.0
 argument-hint: <NN-slug | fix-N | path/to/SPEC.md> [--adversarial N]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT

package/skills/review-plan/references/OUTPUT.md

@@ -93,8 +93,8 @@ stage.
 resolver:** class `plan` → `plan-feature` / `plan-fix` (the author re-cuts, then
 `/review-plan` re-judges) · class `product` → `design-feature` repairs the
 Product half (then `/review-spec`, then the plan re-derives) · class `source` |
-`environment` | `runtime` → the executor's fold path (`/loop-review-fold` →
-`/fold-findings`), never by editing the plan to hide the row.
+`environment` | `runtime` → the executor's fold path (`/fold-findings`, then re-run
+`/review-change`), never by editing the plan to hide the row.
 **`fold-findings` never repairs a planning artifact** — folding repairs source,
 not authority.
 

package/skills/review-spec/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-spec
 user-invocable: true
-version: 1.4.0
+version: 1.5.0
 argument-hint: <NN-slug | path/to/SPEC.md>
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT

package/skills/review-spec/references/OUTPUT.md

@@ -80,7 +80,7 @@ fourth verdict.
 resolver:** class `product` → `design-feature` (then `/review-spec` re-judges the
 new revision) · class `plan` → `plan-feature` / `plan-fix` re-cuts the plan (then
 `/review-plan` re-judges) · class `source` | `environment` | `runtime` → the
-executor's fold path (`/loop-review-fold` → `/fold-findings`).
+executor's fold path (`/fold-findings`, then re-run `/review-change`).
 **`fold-findings` never repairs a planning artifact**, and a planning finding is
 never resolved by patching the artifact during review — folding repairs source,
 not authority.

package/skills/ship-roadmap/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ship-roadmap
 user-invocable: true
-version: 5.0.0
+version: 5.1.0
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 argument-hint: "[--fullauto] | --continue [--fullauto]"
@@ -102,7 +102,7 @@ fallback only when a primitive is unavailable; keep stage order and safety floor
 
 | Relation | Skills/policy |
 |---|---|
-| Compose (same/lower tier) | `init-workspace`; JIT `design-feature` + `plan-feature-scaffold`; `plan-feature`; `loop-review-fold`; verdict-only `audit-pr`; `audit-docs`. |
+| Compose (same/lower tier) | `init-workspace`; JIT `design-feature` + `plan-feature-scaffold`; `plan-feature`; the review→fold manual path (`/fold-findings` → re-run `/review-change`); verdict-only `audit-pr`; `audit-docs`. |
 | Cheap workers | `execute-phase` (fresh context/phase), mechanical folds, audit-blocker fixes; use the validated worker model. |
 | Human hand-off | Default merges, `product-audit` (higher effort), and report issue batches via `triage-issue`. |
 | Sibling | `workflow-status` supplies the strict sensor result; worker skills use the package-owned output profiles, while the conductor keeps its native `SHIP:` turn contract. |

package/skills/ship-roadmap/references/ADVANCE.md

@@ -70,11 +70,12 @@
      when the PR opens; any flips left at run end ride the report commit).
      Stop before the literal final `Hardening & PR` phase: PR owns that explicit
      phase so close-out has one owner. Never bundle phases into one worker.
-   - **REVIEW** — compose `loop-review-fold` in-turn (equal tier) once, over
-     the complete PR candidate. It reuses a current exact-SHA receipt or runs
-     `review-change` context-clean, batches compatible fixes through
-     `fold-findings`, and re-reviews only changed HEADs. Default correction
-     budget is two; unchanged evidence stops NO-PROGRESS. L/sensitive features
+   - **REVIEW** — compose the manual review→fold path in-turn (equal tier) once,
+     `/fold-findings`, then re-run `/review-change`, over the complete PR
+     candidate. It reuses a current exact-SHA receipt or runs `review-change`
+     context-clean, batches compatible fixes through `fold-findings`, and
+     re-reviews only changed HEADs. Default correction budget is two; unchanged
+     evidence stops NO-PROGRESS. L/sensitive features
      forward `--adversarial 2` (security/auth: `3`) as the unattended floor;
      other units use one final reviewer. There are no intermediate phase
      reviews in autopilot: phase gates + frozen acceptance guard execution,

package/skills/ship-roadmap/references/MODEL_ROUTING.md

@@ -9,7 +9,7 @@
 | Product review (REVIEW-SPEC) | opus/high | `review-spec` in a **clean context** (fresh subagent or outside headless call) — never the turn that wrote the product half; tier equals or exceeds the author's, so the ≥ rule holds |
 | Plan review (REVIEW-PLAN) | opus/high | `review-plan` in a **clean context**, same rule; it judges the plan the previous stage froze |
 | Phase execution, single-pass, fixes | **cheap worker** | fresh context per phase following `execute-phase`; Claude branch maps this role to `sonnet`, portable drivers use their validated worker tier |
-| Final review/correction loop | opus/high | compose `loop-review-fold`; it selects review or fold from persisted evidence and routes unresolved findings to `triage-issue --prioritize-now` |
+| Final review/correction loop | opus/high | compose the manual path `/fold-findings`, then re-run `/review-change`; it reuses a current exact-SHA receipt or reviews context-clean, and routes unresolved findings to `triage-issue --prioritize-now` |
 | Merge gate | opus/high | compose `audit-pr` in-turn (the highest-stakes automated verdict; must share one turn with the floor checks) |
 | Forge/git mechanics | — | Bash tool calls; no model judgment involved |
 | Final-report evidence gathering | haiku (optional) | fan-out subagents for grep-shaped per-feature log collection when ultracode is on; synthesis stays opus |

package/skills/triage-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: triage-issue
 user-invocable: true
-version: 2.6.0
+version: 2.7.0
 argument-hint: <issue-number> [more issue numbers…] | <audit-id> F<k> [F<j>…] | --prioritize-now <unit> F<k> [F<j>…]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT

package/skills/triage-issue/references/REVIEW_FINDING_PROCESS.md

@@ -25,7 +25,7 @@ after `/fold-findings` leaves rows unresolved.
 
 4. Never implement the new phases in this triage turn. After a replan, ask the
    user to continue manually with `/execute-phase <unit> P<n>` (or the fix
-   equivalent), then re-run `/loop-review-fold` on the resulting HEAD.
+   equivalent), then re-run `/review-change` on the resulting HEAD (the manual path).
 
 Return exactly one block per finding:
 

package/skills/verification-contract/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: verification-contract
 user-invocable: false
-version: 1.1.0
+version: 1.2.1
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
   Internal contract: one compact frozen ACCEPTANCE.md per delivery unit, its
   validation ladder, anti-weakening rules, and blob-bound execution receipt.
-  Consumed by planners, execute-phase, review-change, and loop-review-fold.
+  Consumed by planners, execute-phase, and review-change.
 ---
 
 # Verification Contract (internal)
@@ -80,6 +80,17 @@ stub, hard-coded answer, or no-op fix used to manufacture green. A command canno
 prove an untested read/manual row. Stronger regression tests are allowed. Repair
 test setup only when assertions stay at least as strong and the reason is logged.
 
+## Test immutability
+
+A test, once written, is **immutable**. The executor fixes code until green,
+never the test — editing an expectation to match behaviour is not a fix, it is
+a cover-up. The sole legitimate amendment is a **proven mis-encoding of external semantics**: the test's expectation contradicts the actual
+documented semantics of the platform/library/language, cited from authoritative documentation — not a product decision change. Even that surfaces as a
+**finding plus a SPEC amendment**, never a silent edit to go green.
+
+Prevention rides the research gate (**research-before-encode**): platform
+semantics are verified against authoritative documentation **before a test encodes them**, so **adding stronger tests stays allowed**; **editing expectations never** (except the proven-mis-encoding path above).
+
 ## Done when
 
 Frozen manifest + current blob receipt + named validators + literal quality

package/skills/loop-review-fold/SKILL.md

@@ -1,200 +0,0 @@
----
-name: loop-review-fold
-user-invocable: true
-version: 4.0.0
-argument-hint: <NN> | --fix <issue-number>
-author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
-license: MIT
-description: >
-  Run the simple review-change/fold-findings loop for an open feature or fix
-  unit. Inspect persisted review evidence first so a previous review resumes
-  with fold-findings instead of reviewing the same candidate again. Unresolved
-  findings go to triage-issue with an immediate-fix instruction; oversized
-  findings become a user-confirmed plan-feature or plan-fix replan with new
-  phases. Triggers: "loop-review-fold", "review and fold this PR", "run the
-  review fold loop".
----
-
-# Review / Fold Loop
-
-Run one small state loop over the current feature or fix unit:
-
-```text
-review-change ── findings ──▶ fold-findings ── changed HEAD ──▶ review-change
-       ▲                              │
-       └──────── current PASS ◀───────┘
-                                      └─ unresolved ─▶ triage-issue
-```
-
-This skill is a router, not a third review or repair implementation. It reads
-the durable evidence left by `review-change` and `fold-findings`, chooses the
-next action, and stops when a user decision or manual phase execution is
-required. Never merge, create an unrelated issue, or silently discard a
-finding.
-
-## Turn contract
-
-```text
-✓ The feature/fix unit, branch, PR, current HEAD, acceptance, and finding ledger were checked
-✓ The first action was selected from persisted evidence: PASS, review-change, or fold-findings
-✓ review-change ran only when no current review result required fold-findings first
-✓ A successful fold was followed by review-change on the new HEAD
-✓ Every unresolved finding is named and routed to triage-issue --prioritize-now
-✓ An oversized finding routes to plan-feature or plan-fix, new P<n> phases, and manual user execution
-✓ No merge, unrelated issue, acceptance weakening, or silent finding drop occurred
-✓ The fixed result and the closing → Next: block are the final output
-```
-
-Any unchecked box means the turn is not done.
-
-## When to use
-
-Use after `execute-phase` opens the unit PR, or when the user asks to review and
-fold an open feature or fix. The argument identifies the unit:
-
-- `/loop-review-fold <NN>` for a feature unit.
-- `/loop-review-fold --fix <issue-number>` for a fix unit.
-
-Do not use this entrypoint to edit this skill, inspect its implementation as the
-requested deliverable, or invent a target when the unit argument is missing.
-
-## Step 0 — Discover the project (always first)
-
-Read the target project's agent guide and documentation map. Then verify the
-target unit, current branch, open PR, remote HEAD, frozen acceptance artifact,
-the latest `review-change` result/receipt, and the unit's `review-findings.md`.
-Use repository and forge commands required by the project's own conventions.
-Narration, an old chat result, or a clean worktree alone is not evidence.
-
-If the target, PR, acceptance, or ledger cannot be verified, stop with
-`BLOCKED` and name the exact missing input and recovery command. Do not create
-replacement artifacts in this router.
-
-## Process
-
-Apply this first-match table exactly:
-
-| Persisted state on the current HEAD | First action |
-|---|---|
-| Exact current `REVIEW-PASS`, matching acceptance, and no open finding rows | `PASS`; do not run either skill |
-| A review result exists for this HEAD and it leaves any `folded: no` row | `fold-findings` on the complete open queue |
-| No usable current review result and no open queue | `review-change` on the current HEAD |
-
-Then continue as follows:
-
-1. Run the selected skill in its own fresh context and follow that skill's
-   contract literally. This loop does not copy its internal checklist.
-2. If `review-change` returns `REVIEW-PASS`, verify its exact-HEAD receipt and
-   zero open rows, then return `PASS`.
-3. If `review-change` returns findings, run `fold-findings` for every open
-   `fix-now` row. Do not start another review before that queue is processed.
-4. If `fold-findings` changes and pushes the candidate, run `review-change` on
-   that new HEAD. Never review an unchanged HEAD a second time.
-4a. Before step 5, split the open queue by **owning stage** (the `route` cell each
-    `review-change` finding carries: `product | plan | source | environment |
-    runtime`). Only `source`, `environment` and `runtime` rows may be folded or
-    triaged here. A `plan`-owned row stops the loop with `BLOCKED` and hands off to
-    `/plan-feature <unit>` (fix: `/plan-fix <n>`) for one root-caused re-cut, then
-    `/review-plan <unit>`; a `product`-owned row goes to `/design-feature <unit>`
-    then `/review-spec <unit>`. Folding repairs the candidate; it cannot repair the
-    authority that describes it, so never fold a row whose artifact of record is a
-    planning document, and never send one to `triage-issue` to make it disappear.
-4b. On entering a **second** local review→fold cycle for the same finding family,
-    diagnose before editing again: emit the `CONVERGENCE-ANOMALY` report defined by
-    `pre-execution-review` (repeated vs new ids, snapshot digest and
-    `artifactRevisionId` move, what was missed, owning stage, why the prior
-    repair failed, route to owner) and continue from the owner it names. A third
-    blind edit is not a repair attempt, and no cycle count here is ever hidden.
-4c. **Cycle bound (unit-level, family-agnostic).** This loop runs at most **two**
-    review→fold cycles for a unit, counted from the unit's ledger marks and
-    receipts — new finding families do not reset the count. A third cycle never
-    starts here: stop with `TRIAGE-REQUIRED`, name every open finding ID, and
-    hand the convergence diagnosis to `/triage-issue --prioritize-now` (which
-    routes replans) or to the user. A unit that needs a third cycle has a
-    planning or root-cause defect, not a review deficit — more blind rounds
-    only manufacture findings.
-
-5. If any finding remains unresolved (`DISPUTED`, `BLOCKED`, `REPLAN`, or an
-   open row left after folding), stop the loop and hand every such ID to:
-
-   ```text
-   /triage-issue --prioritize-now <unit-or-fix> F1 F2 ...
-   ```
-
-   Tell `triage-issue` to try to resolve every named finding immediately. It
-   may route a small correction back to the current unit, but it must not hide,
-   downgrade, or postpone a review finding merely to finish the loop.
-6. When the smallest correct correction is too large for the current fold,
-   `triage-issue` must choose a replan route: re-run `/plan-feature <slug>` for
-   a feature or `/plan-fix <issue-number>` for a fix, append explicit new
-   `P<n>` phases to the unit's SPEC, and stop. The loop then asks the user to
-   execute those phases manually with `/execute-phase <unit> P<n>` (or the
-   fix equivalent) before invoking this loop again.
-
-Do not use a hidden retry count. The loop ends at the first `PASS`, blocked
-prerequisite, unresolved finding, or required manual replan. A later user
-invocation starts from the newly persisted state. The loop files nothing: an
-unresolved finding never becomes a forge issue from here, and deferring one out of
-the unit requires the user to amend the governing SPEC first.
-
-## Fixed output contract
-
-Return exactly:
-
-```text
-REVIEW-FOLD LOOP — PASS | TRIAGE-REQUIRED | BLOCKED
-Unit: <unit> · PR: <url> · HEAD: <sha>
-First action: PASS | review-change | fold-findings
-Review: <PASS | FAIL | not-run> · Fold: <changed | unchanged | not-run>
-Owned elsewhere: <plan → /plan-feature + /review-plan | product → /design-feature
-  + /review-spec | none>
-Unresolved: <F1 + F2 + … | none>
-Evidence: <one concise line explaining the selected action and result>
-
-→ Next: <one concrete command or user action> — <why>
-  · <alternative when applicable>
-```
-
-Use `TRIAGE-REQUIRED` whenever a finding needs `triage-issue`, a replan, or a
-user decision. Replace every placeholder, list each actual finding ID exactly
-once joined with ` + `, and never emit a literal ellipsis.
-
-## Guardrails
-
-Allowed: read target evidence, invoke `review-change`, invoke `fold-findings`,
-and route unresolved findings to `triage-issue`.
-
-Forbidden: implementing a fix in this router, editing review classifications,
-marking findings folded, creating unrelated issues, weakening acceptance or
-checks, merging, or claiming that a user has implemented newly planned phases.
-Also forbidden: folding a `plan`- or `product`-owned finding, re-editing on a
-second local cycle before the convergence diagnosis is reported, entering a
-third review→fold cycle for the same unit, and treating an
-absent pre-execution PASS as foldable debt.
-
-## Relationship to other skills
-
-`execute-phase` hands off here after a unit PR opens. `review-change` owns
-read-only classification and the SHA-bound pass receipt. `fold-findings` owns
-the actual correction and ledger tick. `triage-issue --prioritize-now` owns the
-decision for unresolved findings and routes oversized work to `plan-feature` or
-`plan-fix`; the user then executes the appended phases manually.
-
-## Portability (agents other than Claude Code)
-
-If fresh contexts or subagents are unavailable, invoke each delegated skill in
-a new conversation and re-read the persisted HEAD, receipt, and ledger before
-continuing. If the host has no slash-command menu, open each named `SKILL.md`
-and follow it literally. Never claim a clean review after the same context
-implemented the correction.
-
-## Done when
-
-The current HEAD has a verified `REVIEW-PASS` and no open findings, or every
-remaining finding has a concrete triage/replan hand-off and the user has been
-told to implement the new phases manually.
-
-→ Next: print the matching terminal route from the fixed output contract — never send a non-PASS result to audit-pr
-  · PASS → /audit-pr — consume the current exact-HEAD REVIEW-PASS
-  · TRIAGE-REQUIRED → /triage-issue --prioritize-now <unit> F<k> — resolve every actual unresolved finding, then plan/execute new phases manually
-  · BLOCKED → the exact recovery command — supply the missing target, PR, acceptance, or ledger input before re-running the loop