@qwen-code/qwen-code 0.21.2 → 0.21.3

package/bundled/review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review
-description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, or `/review <pr-number> --comment` to post inline comments on the PR. Add `--effort low|medium|high` to trade depth for speed (defaults to high for PRs, medium for local changes).
-argument-hint: '[pr-number|file-path] [--effort low|medium|high] [--comment]'
+description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, `/review <pr-number> --comment` to post inline comments on the PR, or `/review --fix` to apply the findings to your working tree. Add `--effort low|medium|high` to trade depth for speed (defaults to high for PRs, medium for local changes).
+argument-hint: '[pr-number|file-path] [--effort low|medium|high] [--comment] [--fix]'
 allowedTools:
   - task
   - run_shell_command
@@ -59,13 +59,14 @@ It prints a JSON verdict; use it **verbatim**:
 - `target` — `{type: "pr-number", number}` | `{type: "pr-url", url, host, owner, repo, number}` | `{type: "file", path}` | `{type: "local"}`. A `pr-url` arrives validated and canonicalized (scheme/host lowercased, query and fragment dropped, the number required to end its path segment — `/pull/42oops` is not PR 42) with host/owner/repo/number extracted; do not re-classify tokens by hand. A token that merely looks like a URL is refused with a warning and reported in `extraTokens`, never guessed into a target.
 - `effort` + `effortSource` — the resolved level after defaults (**high** for PR targets, **medium** for local/file) and the `--comment` override (an **effective** `--comment` forces `high`; an ignored one on a non-PR target changes nothing). Do not re-derive it.
 - `comment.requested` / `comment.effective` — `effective` is what gates Step 7; `requested && !effective` means the user asked on a non-PR target, and the warning for that is already in `warnings`.
+- `fix.requested` / `fix.effective` — `--fix` is `--comment` reflected, and gated on the opposite target. `--comment` writes to a **pull request**, so it needs one; `--fix` writes to a **working tree**, so it needs one that outlives the review. A PR review's tree is the ephemeral worktree `fetch-pr` creates and Step 9 deletes, so `--fix` on a PR target is ignored with a warning — edits there are discarded minutes later, and reporting findings as "fixed" into a directory that no longer exists is worse than not fixing them. `effective` is what gates Step 6B. An effective `--fix` also floors the effort at **medium**: it edits the user's files, and low runs no verification, so applying an unverified finding is the same mistake as posting one, aimed at their working tree instead of a pull request. It does not force **high** — medium's findings are verified, and the reverse audit high adds hunts for findings that are _missing_, which is not what deciding whether to apply one turns on.
 - `warnings` — surface every entry to the user, word for word.
 - `extraTokens` / `unknownFlags` — leftover input the parser refused to guess about; mention them to the user rather than silently dropping them.
 
 What each level runs:
 
-- **low** — quick pass. You read the diff yourself and report up to 8 unverified findings (Step 3C). No subagents, no build/test, no verification, no reverse audit, no PR posting, no incremental cache, no project rules.
-- **medium** — **balanced**: the high pipeline with its most expensive passes removed. It runs the parallel review agents (Step 3A/3B) over a **reduced dimension set** — issue fidelity (Agent 0, PR targets only), correctness (Agents 1a/1b/1c), **security (Agent 2)**, quality (Agent 3), performance (Agent 4), **test coverage (Agent 5)**, and **build & test (Agent 7)** — followed by a **single verification pass** (Step 4). It loads and enforces project rules (Step 2) and runs `comment-status` like high. It **skips** the adversarial-persona agents (6a/6b/6c), the diff-specialist finders (Agent 8), the **reverse audit** (Step 5), the incremental cache, and PR posting (`--comment` still forces high). Findings are **verified** (Step 4 ran — they are not "unverified" the way low's are), but without the reverse-audit second pass. Reach for it when high is too slow/expensive but a real bug-catching review is still needed: it keeps the two things that reliably catch bugs cheaply — the finder fan-out and `build-test` (which mechanically catches compile/test failures) — and drops the depth passes with the lowest marginal yield. Measured against high on the same PR it lands at roughly **one-third to one-half** the time and tokens. It reliably catches mechanical defects (compile errors, failing tests) and obvious correctness bugs, but is **not an exhaustive correctness audit** — a subtle Critical that only the reverse audit or the adversarial personas would surface can slip; for a security-sensitive or pre-release review, use `--effort high`.
+- **low** — quick pass. You read the diff yourself, walking it once per **angle** — `plan.budget.inlineAngles` directed angles (3-6, scaled by diff size) plus a gap sweep when the budget asks for one, all in this context — and report up to 10 unverified findings (Step 3C). No subagents, no build/test, no verification, no reverse audit, no PR posting, no incremental cache, no project rules. The angle rotation is what makes a subagent-free tier worth running: one undirected read converges on the most visibly suspicious hunk and leaves the rest of the diff unexamined, and that is the pass this replaces.
+- **medium** — **balanced**: the high pipeline with its most expensive passes removed. It runs the parallel review agents (Step 3A/3B) over a **reduced dimension set** — issue fidelity (Agent 0, PR targets only), correctness (Agents 1a/1b/1c), **security (Agent 2)**, quality (Agents 3a/3b/3c), performance (Agent 4), **test coverage (Agent 5)**, and **build & test (Agent 7)** — followed by a **single verification pass** (Step 4). It loads and enforces project rules (Step 2) and runs `comment-status` like high. It **skips** the adversarial-persona agents (6a/6b/6c), the diff-specialist finders (Agent 8), the **reverse audit** (Step 5), the incremental cache, and PR posting (`--comment` still forces high). Findings are **verified** (Step 4 ran — they are not "unverified" the way low's are), but without the reverse-audit second pass. Reach for it when high is too slow/expensive but a real bug-catching review is still needed: it keeps the two things that reliably catch bugs cheaply — the finder fan-out and `build-test` (which mechanically catches compile/test failures) — and drops the depth passes with the lowest marginal yield. Measured against high on the same PR it lands at roughly **one-third to one-half** the time and tokens. It reliably catches mechanical defects (compile errors, failing tests) and obvious correctness bugs, but is **not an exhaustive correctness audit** — a subtle Critical that only the reverse audit or the adversarial personas would surface can slip; for a security-sensitive or pre-release review, use `--effort high`.
 - **high** — the full pipeline: parallel review agents (Step 3A/3B — the full dimension set including security, test-coverage, the adversarial personas 6a/6b/6c, and Agent 8), verification (Step 4), iterative reverse audit (Step 5), PR submission (Step 7), incremental cache (Step 8).
 
 At every effort level, the mechanics of obtaining the diff — worktree flow, diff capture, base resolution, chunk plan — are shared: the truncation and wrong-base traps this step exists for do not care how fast you want the answer. The _reviewed range_ can still differ: the incremental cache is a high-only feature, so a high re-review of a previously-reviewed PR may scope to `lastCommitSha..HEAD` while a low/medium pass (which never consults the cache) always reviews the full PR diff.
@@ -113,12 +114,12 @@ Based on the parsed `target.type`:
 
     Guessing the owner/repo here is not a recoverable mistake — dogfooding this skill against its own PR, the model inferred the fork from the branch's push target, `fetch-pr` answered "Could not resolve to a PullRequest", and the review stopped before reading a line of code. If `gh repo view` and the remote scan disagree, or no remote matches, say so and stop rather than picking one.
 
-    Read `.qwen/tmp/qwen-review-pr-<n>-fetch.json` for: `worktreePath`, `baseRefName`, `headRefName`, `fetchedSha` (use as the **HEAD commit SHA** for Step 7), `isCrossRepository`, `diffStat` (files / additions / deletions), and `prDescriptionHasHan` (the PR description contains Chinese — every posted inline comment must then be bilingual; see Step 7). If the command fails (auth, network, PR not found), inform the user and stop.
+    Read `.qwen/tmp/qwen-review-pr-<n>-fetch.json` for: `worktreePath`, `baseRefName`, `headRefName`, `fetchedSha` (use as the **HEAD commit SHA** for Step 7), `isCrossRepository`, `diffStat` (files / additions / deletions), `emptyDiff` (**stop here**: the branch tree is byte-identical to its merge base — the work already landed or was superseded; tell the user and recommend close-as-superseded instead of fanning out agents over zero hunks), `collapsedFromUpstream` (disclose in the summary: overlapping merged PRs have collapsed this one to a residual — the review scope is the recomputed diff, and body claims about the rest are description-of-history, which Agent 0 should read accordingly), and `prDescriptionHasHan` (the PR description contains Chinese — every posted inline comment must then be bilingual; see Step 7). If the command fails (auth, network, PR not found), inform the user and stop.
 
     Worktree isolation: all subsequent steps (agents, build/test) operate inside `worktreePath`, not the user's working tree. Cache and reports (Step 8) are written to the **main project directory**, not the worktree.
 
   - **Incremental review check** (high effort only — neither low nor medium consults or updates the cache): if `.qwen/review-cache/pr-<n>.json` exists, read `lastCommitSha` and `lastModelId`. Compare to `fetchedSha` from the fetch report and the current model ID (`{{model}}`):
-    - If SHAs differ → continue with the worktree just created. Compute the incremental diff (`git diff <lastCommitSha>..HEAD` inside the worktree) and use as the review scope; if the cached commit was rebased away, fall back to the full diff and log a warning.
+    - If SHAs differ → continue with the worktree just created. Compute the incremental diff (`git diff <lastCommitSha>..HEAD` inside the worktree) and use as the review scope; if the cached commit was rebased away, fall back to the full diff and log a warning. **Also read the cache's `findings` ledger** (older caches have none — then there is nothing to track): these are the previous round's findings with their ids, and Step 6 owes each of them a ruling this round.
     - If SHAs match **and** model matches **and** `--comment` was NOT specified → inform the user "No new changes since last review", run `"${QWEN_CODE_CLI:-qwen}" review cleanup pr-<n>` to remove the worktree just created, and stop.
     - If SHAs match **and** model matches **but** `--comment` WAS specified → run the full review anyway. Inform the user: "No new code changes. Running review to post inline comments."
     - If SHAs match **but** model differs → continue. Inform: "Previous review used {cached_model}. Running full review with {{model}} for a second opinion."
@@ -182,6 +183,7 @@ Read from it:
 - `diffLines`, `diffChars`, and `srcDiffLines` / `testDiffLines` / `docsDiffLines` / `generatedDiffLines`
 - `chunks[]` — contiguous, non-overlapping line ranges tiling the whole diff. Each entry has `id`, `startLine`, `endLine` (1-based, inclusive), `lines`, `chars`, an `oversized` flag, and `files[]` naming the source files and new-side line ranges it covers. A chunk with `oversized: true` may exceed what one `read_file` call returns.
 - `files[]` — per-file `kind` (`source` / `test` / `generated`), `hunks[]` new-side ranges (Step 7 validates comment anchors against these), `addedRanges[]` and `diffRange` (present only on `heavy` files — the exact lines the PR wrote, and where that file's own diff lives, so an invariant agent can see what was deleted), change counts, and the `heavy` flag
+- `budget` — how much walking the **size-elastic** parts of this run owe, derived from `srcDiffLines` the same way the topology gate is, and recorded here rather than passed as a flag so every reader sees one number. `inlineAngles` and `sweep` scope Step 3C's low pass; `specialistCap` is the Agent 8 ceiling (**0** below 80 source lines — "one domain dominates the diff" is a judgement, and a judgement made about forty lines finds a dominant domain every time, because forty lines are usually all one thing); `verifyShard` is Step 4's findings-per-verifier. **It never scales a dimension away** — which agents a review owes is the roster's answer and the roster reads `effort`, so a size input cannot become a back door into shrinking coverage. Nothing here is yours to override: a budget the caller can inflate is a budget that gets inflated. **A plan with no `budget` field** (written by an older CLI — the version-skew this skill has already measured once) falls back to the pre-budget flat behaviour, which errs toward more coverage, never less: walk all six angles, run the sweep, cap Agent 8 at 2, shard verification at 8.
 
 A chunk is read with `read_file(file_path=diffPathAbsolute, offset=startLine - 1, limit=endLine - startLine + 1)` — `offset` is 0-based.
 
@@ -230,9 +232,9 @@ If `diffPath` is `null` (merge-base could not be resolved), fall back to giving
 - **`srcDiffLines` ≤ 500 and `diffLines` ≤ 3200** — use the dimension fan-out in Step 3A.
 - **otherwise** — use the territory × dimension fan-out in Step 3B, and inform the user: "This is a large changeset (N source lines of M total, K chunks). The review may take a few minutes."
 
-Test code is where diff size lies. Across this repo's last 40 merged PRs the median diff is **41% test code**, and a third of them are more than half tests. Prose and lockfiles are excluded for the same reason — a translation PR carries no runtime risk. Markdown _inside a source tree_ still counts as source: this skill is one such file. A change of 173 production lines that ships 489 lines of new tests is a small change; carving it into territories spends most of the reviewers on test files and leaves the production code with **one** agent instead of the ten lenses it deserves ("lenses" = the diff-reading dimension agents: the twelve minus Issue Fidelity and Build & Test, which read the issue and run commands rather than reviewing the diff). Territory fan-out earns its keep when there is a lot of _risky_ code to divide, not a lot of _lines_.
+Test code is where diff size lies. Across this repo's last 40 merged PRs the median diff is **41% test code**, and a third of them are more than half tests. Prose and lockfiles are excluded for the same reason — a translation PR carries no runtime risk. Markdown _inside a source tree_ still counts as source: this skill is one such file. A change of 173 production lines that ships 489 lines of new tests is a small change; carving it into territories spends most of the reviewers on test files and leaves the production code with **one** agent instead of the twelve lenses it deserves ("lenses" = the diff-reading dimension agents: the fourteen minus Issue Fidelity and Build & Test, which read the issue and run commands rather than reviewing the diff). Territory fan-out earns its keep when there is a lot of _risky_ code to divide, not a lot of _lines_.
 
-The second clause is an attention bound, not a risk one: past roughly 3200 diff lines, asking the eleven diff-reading agents each to read the whole diff dilutes them all, and the chunk topology's base cost (`ceil(diffLines / 400) + 4` diff-reading agents, before invariant and specialized ones — Build & Test reads no diff) crosses twelve about there. It is not a guarantee of fewer calls — a heavy file adds `3` invariant agents and a dominant domain up to `2` specialized finders, so a barely-over-the-line changeset can cost more under 3B than 3A; what 3B buys at that size is one accountable reader per line instead of eleven diluted ones. It is the safety valve for a changeset dominated by tests or generated files.
+The second clause is an attention bound, not a risk one: past roughly 3200 diff lines, asking the thirteen diff-reading agents each to read the whole diff dilutes them all, and the chunk topology's base cost (`ceil(diffLines / 400) + 4` diff-reading agents, before invariant and specialized ones — Build & Test reads no diff) crosses that count nearer 3 600. The gate stays at 3 200 rather than moving with the roster: fanning out slightly _before_ the crossover errs toward one accountable reader per line, which is the property 3B is bought for, and a gate that drifts every time a dimension is split or merged is a gate nobody can reason about. It is not a guarantee of fewer calls — a heavy file adds `3` invariant agents and a dominant domain up to `2` specialized finders, so a barely-over-the-line changeset can cost more under 3B than 3A; what 3B buys at that size is one accountable reader per line instead of thirteen diluted ones. It is the safety valve for a changeset dominated by tests or generated files.
 
 Either way the chunk plan covers **every** line — tests and generated files included. What changes is how many reviewers are assigned and what each is asked to do, not what gets read.
 
@@ -270,9 +272,9 @@ Use **Step 3A** or **Step 3B** as the topology gate in Step 1 decided. The dimen
 
 ## Step 3A: Dimension fan-out (small source change)
 
-Launch **12 agents** for same-repo **PR** reviews (Agent 1 has three procedural variants 1a/1b/1c and Agent 6 has three persona variants 6a/6b/6c — each variant counts as a separate parallel agent), plus up to 2 optional diff-specialized finders (Agent 8) when the diff's domain calls for them. For cross-repo lightweight **PR** mode launch **10 agents** — skip Agent 7 (Build & Test) and Agent 1c (Cross-file tracer), since there is no local codebase to build, test, or grep. (Agent 8 finders need only the diff, so the up-to-2 option applies in every mode — lightweight and local included.) Lightweight mode also degrades Agents 1a and 1b, whose briefs assume a source tree: tell them they have the diff ONLY — 1a reviews hunks without enclosing-function reads, and 1b, when it cannot find a deleted invariant re-established because the evidence would live outside the diff, reports the candidate at `Confidence: low` and says the re-establishment could not be checked, instead of asserting it is missing. Step 4's verifiers operate under the same limit, so lightweight-mode findings that depend on unseen source must stay low-confidence (terminal-only) rather than becoming public blockers. **Agent 0 (Issue Fidelity) runs only when the review target is a PR** — a local-diff or file-path review has no PR and no linked issue, so skip Agent 0 and launch **11 agents** (Agents 1a–7). Each agent should focus exclusively on its dimension. (Agent counts are maxima: on a diff with no removed or replaced lines, Agent 1b has nothing to audit and is skipped — one fewer agent.)
+Launch **14 agents** for same-repo **PR** reviews (Agent 1 has three procedural variants 1a/1b/1c, Agent 3 has three checklist slices 3a/3b/3c, and Agent 6 has three persona variants 6a/6b/6c — each variant counts as a separate parallel agent), plus up to 2 optional diff-specialized finders (Agent 8) when the diff's domain calls for them. For cross-repo lightweight **PR** mode launch **12 agents** — skip Agent 7 (Build & Test) and Agent 1c (Cross-file tracer), since there is no local codebase to build, test, or grep. (Agent 8 finders need only the diff, so the up-to-2 option applies in every mode — lightweight and local included.) Lightweight mode also degrades Agents 1a and 1b, whose briefs assume a source tree: tell them they have the diff ONLY — 1a reviews hunks without enclosing-function reads, and 1b, when it cannot find a deleted invariant re-established because the evidence would live outside the diff, reports the candidate at `Confidence: low` and says the re-establishment could not be checked, instead of asserting it is missing. Step 4's verifiers operate under the same limit, so lightweight-mode findings that depend on unseen source must stay low-confidence (terminal-only) rather than becoming public blockers. **Agent 0 (Issue Fidelity) runs only when the review target is a PR** — a local-diff or file-path review has no PR and no linked issue, so skip Agent 0 and launch **13 agents** (Agents 1a–7). Each agent should focus exclusively on its dimension. (Agent counts are maxima: on a diff with no removed or replaced lines, Agent 1b has nothing to audit and is skipped — one fewer agent.)
 
-**At medium effort, launch the reduced set:** skip the three adversarial personas (Agents 6a/6b/6c) and the Agent 8 diff-specialists, launching Agents 0 (PR targets only), 1a, 1b, 1c, 2, 3, 4, 5, and 7 — **9 agents** for a same-repo PR, **8** for a local-diff or file-path review (no Agent 0), **7** for cross-repo lightweight (drop Agent 7 and 1c too, as above). Everything else about 3A is identical — the briefs, the `working_dir` pin, the whiff check, coverage; medium changes only which dimensions launch, not how any agent runs. **Build the roster with `agent-prompt --roster`** — it reads the effort the plan recorded at Step 1 (`plan.effort`), so on a medium plan it omits 6a/6b/6c from the roster it prints (Agent 8 was never in it) and you launch exactly these agents. `check-coverage` (Step 3D) reads the **same** `plan.effort` and requires exactly these too — no flag to pass, and no way for the roster you launched and the gate that checks it to disagree. (The effort lives in the plan, not in a flag, on purpose: a roster a caller could shrink by omitting a flag is a roster that gets shrunk. If Step 1 recorded no effort, the full roster is required, personas included — the fail-safe, not a medium review.)
+**At medium effort, launch the reduced set:** skip the three adversarial personas (Agents 6a/6b/6c) and the Agent 8 diff-specialists, launching Agents 0 (PR targets only), 1a, 1b, 1c, 2, 3a, 3b, 3c, 4, 5, and 7 — **11 agents** for a same-repo PR, **10** for a local-diff or file-path review (no Agent 0), **9** for cross-repo lightweight (drop Agent 7 and 1c too, as above). Everything else about 3A is identical — the briefs, the `working_dir` pin, the whiff check, coverage; medium changes only which dimensions launch, not how any agent runs. **Build the roster with `agent-prompt --roster`** — it reads the effort the plan recorded at Step 1 (`plan.effort`), so on a medium plan it omits 6a/6b/6c from the roster it prints (Agent 8 was never in it) and you launch exactly these agents. `check-coverage` (Step 3D) reads the **same** `plan.effort` and requires exactly these too — no flag to pass, and no way for the roster you launched and the gate that checks it to disagree. (The effort lives in the plan, not in a flag, on purpose: a roster a caller could shrink by omitting a flag is a roster that gets shrunk. If Step 1 recorded no effort, the full roster is required, personas included — the fail-safe, not a medium review.)
 
 **Do not write these prompts, and do not ask for them one at a time. One call builds all of them:**
 
@@ -284,7 +286,7 @@ Launch **12 agents** for same-repo **PR** reviews (Agent 1 has three procedural
 
 **Redirected to a file, then `read_file` it, paging until `isTruncated` is false** — the same rule as every other large output in this skill: shell output truncates at 30 000 characters, and a large plan's roster exceeds that, which would silently swallow the middle blocks. The output is self-checking: blocks are numbered `agent k of N` and the file ends with an `end of roster` line — if any `k` is missing or the end line is absent, rebuild just those blocks with `--chunk <id>` / `--role <r>` (every prompt is also recorded on disk regardless).
 
-It prints one labelled block per required agent — which roles this review owes is read out of the plan, so the paragraph above is the _why_ and the roster is the _list_ — and **each block goes to its agent verbatim**, all launched in one response. To rebuild a single agent's prompt (a relaunch after Step 3D): `--role <role>` in place of `--roster`; the roles are `0`, `1a`, `1b`, `1c`, `2`, `3`, `4`, `5`, `6a`, `6b`, `6c`, `7`.
+It prints one labelled block per required agent — which roles this review owes is read out of the plan, so the paragraph above is the _why_ and the roster is the _list_ — and **each block goes to its agent verbatim**, all launched in one response. To rebuild a single agent's prompt (a relaunch after Step 3D): `--role <role>` in place of `--roster`; the roles are `0`, `1a`, `1b`, `1c`, `2`, `3a`, `3b`, `3c`, `4`, `5`, `6a`, `6b`, `6c`, `7`.
 
 **What it prints is short — a few hundred characters — and it is short on purpose.** It names the agent's role, points at the **brief file** the command just wrote, and lists the `read_file` calls for the diff. The brief itself — the dimension, the finding format, the severity definitions, the project rules — is on disk, and the agent reads it, exactly as it reads the diff. That is not an optimisation. Asked to paste a 4 652-character prompt to each of twelve agents, a real run delivered **2 893** characters of one: it kept the head, added a preamble of its own, and cut nineteen hundred characters out of the middle. Then it read the coverage check's refusal, concluded that "the agents clearly did their job", skipped `compose-review`, and filed an **Approve it had written itself**. What you are asked to carry is now small enough that you will carry it. Copy it; do not retype it. (Agent 8, when you launch one, is the exception — its brief is the one you write, so give it `--whole-diff` and append your domain brief.)
 
@@ -322,7 +324,7 @@ Everything below still governs what the agent is asked to do; the command builds
 - **An instruction to page.** Ordinary chunks are sized to fit one un-truncated read, but a chunk whose `oversized` flag is set is a single hunk that offered no safe place to cut, and its `chars` can exceed one read's ~25 000. Tell the agent: if the read comes back with `isTruncated`, keep calling `read_file` with a larger `offset` until it has the whole range. An agent that returns a `Covered:` receipt for a range it only half read makes the coverage guarantee a lie — which is worse than not having one.
 - **What to do when paging cannot help.** A chunk whose `maxLineChars` exceeds ~25 000 contains a single line longer than one read returns — a minified bundle, a base64 blob. Paging starts every page at a line boundary, so the tail of that line is unreachable by any `offset`. Such a chunk MUST NOT be receipted as covered. Tell the agent to return, instead of the receipt: `Uncoverable: chunk <id> — line exceeds the read limit`. Report those chunks to the user in Step 6 and do not let the verdict be Approve on their strength.
 - Permission to read the **full source files** it covers (via `read_file` on the worktree path) whenever a hunk's correctness depends on code outside the hunk. Diff context lines are three lines deep; state invariants are not. A source file over ~25 000 characters comes back with `isTruncated` set — page through it rather than reasoning from the first screenful.
-- The review focus: it owns **all** of Agents 1a, 1b, and 2–6's dimensions (line-by-line correctness with the language-pitfall and wrapper-routing checks, the removed-behavior audit of its own deleted lines, security, code quality including altitude, performance, test coverage, and the three adversarial personas) **for its territory only**. Two duties are whole-diff agents, not chunk duties, because a chunk agent is structurally blind to them: **cross-file tracing (Agent 1c)** — it cannot see a caller that lives in another chunk — and the **cross-chunk half of removed-behavior (Agent 1b)** — it cannot see that its deleted export's replacement, three files away, quietly changed a default. Audit the deletions in your own territory; do not conclude a deletion is unreplaced merely because the replacement is not in your range.
+- The review focus: it owns **all** of Agents 1a, 1b, and 2–6's dimensions (line-by-line correctness with the language-pitfall and wrapper-routing checks, the removed-behavior audit of its own deleted lines, security, all three code-quality slices — reuse/duplication, altitude and abstraction fit, sibling consistency and clarity — performance, test coverage, and the three adversarial personas) **for its territory only**. Two duties are whole-diff agents, not chunk duties, because a chunk agent is structurally blind to them: **cross-file tracing (Agent 1c)** — it cannot see a caller that lives in another chunk — and the **cross-chunk half of removed-behavior (Agent 1b)** — it cannot see that its deleted export's replacement, three files away, quietly changed a default. Audit the deletions in your own territory; do not conclude a deletion is unreplaced merely because the replacement is not in your range.
   - **The severity definitions from the finding format below, verbatim.** A chunk agent owns the test-coverage dimension with no dedicated agent to calibrate it, and an uncalibrated agent files "zero test coverage" as Critical. It has happened.
 - Project-specific rules from Step 2 (if any).
 
@@ -400,9 +402,9 @@ Agent 2 (Security)       — WHIFF (returned "No issues found." with no evidence
 
 A check you perform silently is a check you skip, and this one has been skipped: dogfooded against this skill's own PR, Agent 0 returned in **6 seconds** having made **one tool call**, and the review went on to print "All chunks were successfully reviewed and covered" and **Approve**. The roll-call is what makes that impossible to miss — you cannot write the artifact line for an agent that named no artifact, and a `WHIFF` line you have written is a `WHIFF` you must then act on (relaunch once; on a second bare return, record the dimension in `unreviewedDimensions`, which forbids the Approve).
 
-**The whole-diff agents have no receipt, so this is the only check they get: an agent that returns near-instantly with almost no output did not do its job, and its silence is indistinguishable from "found nothing".** This is not hypothetical — in dogfooding an invariant agent on a heavy file returned in 11 seconds having emitted a few hundred tokens, while its sibling agents ran for minutes; the whiffing agent happened to own the checklist half that held the run's most serious defect, and nothing flagged the miss. Apply the check to **every agent that owes no receipt** — in 3B, the whole-diff agents (Agent 0, **1b**, 1c, Agent 7, the invariant agents, the test-coverage matrix, Agent 8); in 3A, **all of them**, since no 3A agent emits a receipt (Agents 0, 1a, 1b, 1c, 2, 3, 4, 5, 6a, 6b, 6c, 7, and Agent 8 if launched). A whiffing 3A dimension agent is exactly as invisible as a whiffing invariant agent, and the same one-line fix applies. For each such agent, sanity-check that its return is substantive: it names the specific fields/callers/lines it walked, or it explicitly says "No issues found" **after** describing what it examined. For **Agent 7** the evidence is the build/test **commands it ran and their outcomes** — a Build & Test return that names no command whiffed even if it says "build passed", and after its second whiff record `build-and-test` in `unreviewedDimensions` like any other dimension: a zero-finding run whose deterministic verification never actually ran must not certify on its silence. A legitimately empty scope also passes — Agent 0 on a feature PR with no linked issue returns "No issues found — scope empty" plus the evidence it checked (empty `closingIssuesReferences`, no referenced issue, not a bugfix), and that is a complete answer, not a whiff; do not relaunch it. What fails the check is a bare "No issues found" with no evidence of any walk or scope determination, or a response conspicuously shorter and faster than its peers — relaunch that one agent before Step 4, **once**. The relaunch is capped at one attempt per agent: if the second return is also bare, do not spin — take it, and record that agent's dimension in an **`unreviewedDimensions`** list. (The finding format tells every agent to return `No issues found — <what you examined>`; an agent that ignores that twice is not going to comply on the third ask.) A silent whole-diff agent is the Step-3A/3B equivalent of a chunk with no receipt — **and it is treated like one**: `unreviewedDimensions` is carried into Step 6's "Not reviewed" section, it **forbids an Approve** (a dimension nobody reviewed cannot be certified clean, exactly as an uncoverable chunk cannot), and Step 7 serializes it in the review body (compose-review's `unreviewedDimensions` input), named alongside any uncoverable chunks. A run that silently drops Security or the cross-chunk removed-behavior audit and then posts LGTM is the failure this whole check exists to prevent; noting the gap in the terminal and approving anyway would only move it.
+**The whole-diff agents have no receipt, so this is the only check they get: an agent that returns near-instantly with almost no output did not do its job, and its silence is indistinguishable from "found nothing".** This is not hypothetical — in dogfooding an invariant agent on a heavy file returned in 11 seconds having emitted a few hundred tokens, while its sibling agents ran for minutes; the whiffing agent happened to own the checklist half that held the run's most serious defect, and nothing flagged the miss. Apply the check to **every agent that owes no receipt** — in 3B, the whole-diff agents (Agent 0, **1b**, 1c, Agent 7, the invariant agents, the test-coverage matrix, Agent 8); in 3A, **all of them**, since no 3A agent emits a receipt (Agents 0, 1a, 1b, 1c, 2, 3a, 3b, 3c, 4, 5, 6a, 6b, 6c, 7, and Agent 8 if launched). A whiffing 3A dimension agent is exactly as invisible as a whiffing invariant agent, and the same one-line fix applies. For each such agent, sanity-check that its return is substantive: it names the specific fields/callers/lines it walked, or it explicitly says "No issues found" **after** describing what it examined. For **Agent 7** the evidence is the build/test **commands it ran and their outcomes** — a Build & Test return that names no command whiffed even if it says "build passed", and after its second whiff record `build-and-test` in `unreviewedDimensions` like any other dimension: a zero-finding run whose deterministic verification never actually ran must not certify on its silence. A legitimately empty scope also passes — Agent 0 on a feature PR with no linked issue returns "No issues found — scope empty" plus the evidence it checked (empty `closingIssuesReferences`, no referenced issue, not a bugfix), and that is a complete answer, not a whiff; do not relaunch it. What fails the check is a bare "No issues found" with no evidence of any walk or scope determination, or a response conspicuously shorter and faster than its peers — relaunch that one agent before Step 4, **once**. The relaunch is capped at one attempt per agent: if the second return is also bare, do not spin — take it, and record that agent's dimension in an **`unreviewedDimensions`** list. (The finding format tells every agent to return `No issues found — <what you examined>`; an agent that ignores that twice is not going to comply on the third ask.) A silent whole-diff agent is the Step-3A/3B equivalent of a chunk with no receipt — **and it is treated like one**: `unreviewedDimensions` is carried into Step 6's "Not reviewed" section, it **forbids an Approve** (a dimension nobody reviewed cannot be certified clean, exactly as an uncoverable chunk cannot), and Step 7 serializes it in the review body (compose-review's `unreviewedDimensions` input), named alongside any uncoverable chunks. A run that silently drops Security or the cross-chunk removed-behavior audit and then posts LGTM is the failure this whole check exists to prevent; noting the gap in the terminal and approving anyway would only move it.
 
-**Step 3A has no receipts, and must not.** There every dimension agent walks every chunk, so "exactly one receipt per chunk" would demand either none or one per diff-reading agent — eleven, or up to thirteen when Agent 8 launches (every agent except Build & Test reads the diff). Territory ownership is a Step 3B idea. **What Step 3A does not lack is coverage** — that is Step 3D's job on both paths, and it needs no receipt from anyone: it reads the lines each agent was pointed at out of the prompt the CLI built, and the diff reads out of the harness's transcript. A receipt was only ever a sentence the agent typed. (For a while the two were confused, and 3A reviews were told nobody had read them. See Step 3D.) What Step 3A shares is the uncoverable rule, and that needs no agent at all: **a chunk is uncoverable iff its `maxLineChars` exceeds ~25 000**, which the orchestrator reads straight out of the plan before launching anything. Compute that list up front on both paths, carry it into Step 6, and let a Step 3B agent's `Uncoverable` receipt add to it rather than be the only source of it.
+**Step 3A has no receipts, and must not.** There every dimension agent walks every chunk, so "exactly one receipt per chunk" would demand either none or one per diff-reading agent — thirteen, or up to fifteen when Agent 8 launches (every agent except Build & Test reads the diff). Territory ownership is a Step 3B idea. **What Step 3A does not lack is coverage** — that is Step 3D's job on both paths, and it needs no receipt from anyone: it reads the lines each agent was pointed at out of the prompt the CLI built, and the diff reads out of the harness's transcript. A receipt was only ever a sentence the agent typed. (For a while the two were confused, and 3A reviews were told nobody had read them. See Step 3D.) What Step 3A shares is the uncoverable rule, and that needs no agent at all: **a chunk is uncoverable iff its `maxLineChars` exceeds ~25 000**, which the orchestrator reads straight out of the plan before launching anything. Compute that list up front on both paths, carry it into Step 6, and let a Step 3B agent's `Uncoverable` receipt add to it rather than be the only source of it.
 
 **Do not let precision suppress recall in this step.** The "if you're unsure, do NOT report it" rule in the Exclusion Criteria applies to **Suggestion** and **Nice to have** findings. A suspected **Critical** must always be reported, marked `low confidence` if uncertain — Step 4's verifier decides. A Critical dropped here is dropped irreversibly; a Critical dropped there is at least reviewed by a second agent.
 
@@ -440,39 +442,66 @@ An agent that finds nothing must say so **and say what it walked** — `No issue
 | `1b`                                      | **Removed-behavior audit.** Owns the `-` lines, which exist only in the diff — the post-change tree carries no trace of what was deleted. For each removal: what invariant did it enforce, and where is that re-established? Includes removed or renamed _exports_ (compared to their replacement as **behaviour, not names**), changed _literals_ a distant consumer matches on by shape (marker strings, keys, codes, regex text), and whether a rename/format/schema change handles the data that **already exists** (migration / split-brain).                                                                       |
 | `1c`                                      | **Cross-file tracer** (needs a local tree). Owns the whole cross-file walk. _Consumer direction_: grep every caller of every changed export and check it against the new contract. _Producer direction_: for every field the diff **adds**, grep its **read sites** — a live path reading a field the diff never populates is Critical, and nothing in the build will tell you.                                                                                                                                                                                                                                          |
 | `2`                                       | **Security.** Injection, XSS, SSRF, path traversal, authn/authz bypass, secrets in logs, weak crypto, hardcoded credentials. Includes **option/argument injection into subprocess calls** — a user-controlled positional that starts with `-` or is `.`/`..` becomes a git/gh flag or pathspec (`--output=`, `-f`, `checkout .`); `execFile` does not stop it — validate the value against the subcommand grammar (a ref/name allowlist, reject a leading `-`); a `--` separator ends option parsing but does **not** neutralize a pathspec (`checkout -- .` still discards changes), so the value allowlist is the fix. |
-| `3`                                       | **Code quality.** Duplication that names the existing helper to call instead; over-engineering; **altitude** — is the fix at the right depth, or a bandaid on shared infrastructure?; and **sibling consistency** — a guard/validation one member of a parallel family has but its twin lacks (asymmetric failure; if the missing guard is on untrusted input, a security bug, not a nit).                                                                                                                                                                                                                               |
+| `3a`                                      | **Reuse & duplication.** Does the codebase already have this? Greps the shared/utility modules and adjacent files for the _behaviour_ (a literal, an error string, a regex — not a plausible function name), and **names the existing helper to call instead**; a duplication finding that names nothing is not a finding. Also owns **dead code the diff leaves behind**.                                                                                                                                                                                                                                               |
+| `3b`                                      | **Altitude & abstraction fit.** Is each change at the right depth — or a bandaid on shared infrastructure, a downstream compensation for an upstream bug, or a new abstraction serving a single call site? **Names the depth the change should live at**, and the blast radius on the other callers.                                                                                                                                                                                                                                                                                                                     |
+| `3c`                                      | **Consistency & clarity.** **Sibling consistency** — a guard/validation one member of a parallel family has but its twin lacks (asymmetric failure; if the missing guard is on untrusted input, a security bug, not a nit) — plus convention drift measured against a cited local example, misleading names and comments, and needless complexity in the added code.                                                                                                                                                                                                                                                     |
 | `4`                                       | **Performance & efficiency.** N+1s, leaks, needless re-renders, bad data structures, bundle size. **Reproduces the PR's claimed numbers** rather than trusting them — confirms a cheap deterministic claim (bundle bytes, tree-shake) or flags an unreproducible/unsubstantiated benchmark as unverified.                                                                                                                                                                                                                                                                                                                |
 | `5`                                       | **Test coverage.** Specific untested paths in the diff, never "coverage is low"; a missing test is a Suggestion. **Mutation-tests the tests the diff adds/changes** — a test that stays green when the code under it is broken is vacuous — a Suggestion, Critical only when it asserts the opposite, was weakened in-diff, or lets a named incorrect behaviour ship (report the behaviour, not the gap).                                                                                                                                                                                                                |
 | `6a` `6b` `6c`                            | **Undirected audit, three personas** — attacker, 3 AM oncall, six-months-later maintainer. The framings force diverse paths; the union of what they find is the point, so all three run.                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| `7`                                       | **Build & test verification** (needs a local tree). Runs _one_ build and _one_ test command, and the **test-efficacy probe** — which reverts the diff's source, keeps its tests, and reports the ones that pass anyway, and deletes individual added safety statements (mutants) to find the ones no test notices. Its evidence is the commands it ran. `Source: [build]` / `[test]`, never `[review]`.                                                                                                                                                                                                                  |
+| `7`                                       | **Build & test verification** (needs a local tree). Runs _one_ build and _one_ test command, and the **test-efficacy probe** — which reverts the diff's source, keeps its tests, and reports the ones that pass anyway, deletes individual added safety statements (mutants) to find the ones no test notices, and reverts individual **hunks** one at a time to find the changes no test turns on. Its evidence is the commands it ran. `Source: [build]` / `[test]`, never `[review]`.                                                                                                                                 |
 | `test-matrix`                             | **Test coverage matrix** (Step 3B). Maps each behavioural change to the test that exercises it — the pairing a territory agent cannot see, because it holds either the implementation or the test, rarely both.                                                                                                                                                                                                                                                                                                                                                                                                          |
 | `invariant-a` `invariant-b` `invariant-c` | **Whole-file invariants** on a `heavy` file, one checklist slice each: (a) mutable fields, timers, collections; (b) retry counters, ignored return values, error taxonomies; (c) config fields, early returns.                                                                                                                                                                                                                                                                                                                                                                                                           |
 
+**Why code quality is three agents.** It was one, holding six unrelated checks — reuse, sibling symmetry, altitude, abstraction fit, conventions, dead code — which is the shape this skill already refuses two rows down. The invariant agents were split three ways on measured evidence (PR #6457's `QQChannel.ts`: one agent holding the whole eight-item checklist found **one** of that file's five invariant-class defects; the same model split three ways found **all five**), because a long checklist is not a task an agent does six times — it is a task it does once, well, and then stops. Nothing in that measurement was specific to invariants, and the quality checklist was the other place the same shape survived. The seam is where the questions genuinely differ: _does this already exist_ (3a), _is it at the right depth_ (3b), _does it match what surrounds it_ (3c). All three run at medium as well as high — dropping two slices would not save a lens, it would restore the failure the split fixed.
+
 Two things the command's briefs carry that no orchestrator should be relaying by hand, and that a hand-written prompt has never once included: the **Exclusion Criteria** (what is not a finding — the whole precision control), and the rules that make an **anchor** resolvable (prefer added lines; a removed line cannot be anchored; a bare `}` matches everywhere).
 
+**And one the briefs now carry against the Exclusion Criteria: the recall rule.** The exclusions are a filter on what _kind_ of thing is a finding. Read as a confidence bar — which is how an agent under a "silence is better than noise" constitution reads them — they license dropping anything half-believed, and that drop is invisible: no later stage sees a candidate that was never filed. Every stage this skill has after the finders (dedup, Step 4 verification, the reverse audit, the confidence split that keeps low-confidence findings off the pull request) exists to **remove** wrong findings; none of them can **add** a missing one. So each finder's brief now states the split explicitly — file every candidate whose failure scenario you can name, at `Confidence: low` if unsure; do not stay silent because another lens might catch it; the scenario gate itself is unchanged. It goes to the finders only. The Step 4 verifier does **not** get it: telling the stage whose job is removing wrong findings to keep everything it cannot rule out would disable the precision half of the pipeline.
+
 **Path-scoped rules.** Some files have failure modes no dimension would think to ask about — a GitHub Actions workflow reads as configuration, and the reviewer who treats it as configuration misses `pull_request_target` checking out the contributor's code with a write token. `agent-prompt` appends a checklist for such a file to the brief of every code-reviewing agent **whose territory actually contains one**. It is additive to the project's own rules, never a replacement, and it is silent on a diff that triggers none.
 
-### Agent 8: Diff-specialized finders (0–2 agents, optional; high effort only — medium skips them)
+### Agent 8: Diff-specialized finders (0 to `plan.budget.specialistCap` agents, optional; high effort only — medium skips them)
 
 The fixed dimensions are domain-blind. When a diff concentrates in a domain with a recognizable failure grammar — a reconnect/backoff state machine, a module loader, a cron scheduler, a wire-protocol codec, a cache layer, a data migration — write 1–2 additional finder briefs specialized to that domain and launch them alongside the standard set, labeled `Agent 8a/8b: <domain> angle`.
 
 **This is the one brief you write**, so it is the one place `--role` does not help: build the diff-reading block with `"${QWEN_CODE_CLI:-qwen}" review agent-prompt --plan <plan> --whole-diff` and append your domain brief to it. A specialized brief names the domain's specific invariants to walk, the way the invariant checklist does for a rewritten file. Examples: for a module loader — resolution order, ESM/CJS interop, circular-import timing, cache invalidation; for reconnect logic — state flags reset on every exit path, backoff growth and cap, timer cancellation on teardown, buffered-data loss when a retry is abandoned.
 
-Rules: at most 2; launch none when no domain stands out (the common case — most diffs get zero). They are not in the roster, so nothing will ask for them. Their findings are `Source: [review]`, use the standard finding format including the failure scenario, and go through Step 4 verification like any other finding.
+Rules: at most `plan.budget.specialistCap` — which is **0 below 80 source lines**, so on a small diff there is no ruling to make and you launch none regardless of how concentrated it looks; launch none when no domain stands out (the common case — most diffs get zero). They are not in the roster, so nothing will ask for them. Their findings are `Source: [review]`, use the standard finding format including the failure scenario, and go through Step 4 verification like any other finding.
 
 ### What Agent 7's results mean downstream
 
-Build and test results are **deterministic facts**. A code-caused failure skips Step 4 verification — the `[build]` / `[test]` source tag is how it is recognised as pre-confirmed. An environment/setup failure (a missing dependency, a tool not installed) is informational only and must not affect the verdict. Test-efficacy findings are deterministic in the same way, and likewise pre-confirmed.
+The efficacy report's `harnessValidated` is the probe kit's own control, and it has THREE values: `false` means an injected always-failing test left the runner green, every would-be survivor was re-classed inconclusive (counted in `mutants.skippedForControl` / `hunks.skippedForControl`, which is NOT the budget running out), and the terminal should say the probe harness could not be validated rather than implying clean coverage; `null` means the control produced no verdict — either it never ran (no green baseline, no candidates, no budget, an unreadable probe file) or it ran and died before answering (its deadline killed it, the runner could not be spawned), which the outer catch leaves as `null` rather than as a fabricated `false`. Say which of the two the report supports rather than "the control never ran", because for the second it did. Neither validated nor refuted either way, so a survivor stands but unconfirmed; only `true` licenses reading a survivor as a coverage gap. Build and test results are **deterministic facts**. A code-caused failure skips Step 4 verification — the `[build]` / `[test]` source tag is how it is recognised as pre-confirmed. An environment/setup failure (a missing dependency, a tool not installed) is informational only and must not affect the verdict. Test-efficacy findings are deterministic in the same way, and likewise pre-confirmed.
+
+When the PR side's tests fail, Agent 7's brief has it **measure** the attribution rather than judge it by path: `base-tree` + `test-delta` rerun the same failed commands on the built merge base and diff the failing **file sets**. `netNew` (fails on the PR side only) is the PR's own failure by measurement — a Critical even in a file the diff never touched; `shared` (fails on base too) is pre-existing by measurement — never filed, even in a file the diff rewrote. Counts are deliberately not compared: a flaky suite fails different test names between two runs of the same tree, so the file-set difference is the signal and an empty `netNew` is the strongest "pre-existing" statement available. Where the delta cannot rule — no merge base, an unparsed failure, a timed-out base rerun, a base rerun that failed without naming any failing file (it did not measure the base), or a command the whole-command budget could not fit — the old path judgment stands, and the report names each case with its own reason rather than folding them into one.
 
 If the probe reports `inconclusive`, that is **not a finding and must never be reported as one**: reverting the source often breaks the test's own compile, and a runner that collected nothing is not a test catching a regression. Note it in the terminal and move on.
 
 ## Step 3C: Inline pass (low effort)
 
-At low effort there are no subagents: you are the finder, in this context. The diff is still read via the chunk plan — `read_file` per chunk range, paging oversized chunks; the read-cap rules from Step 1 apply unchanged, and chunks whose `maxLineChars` exceeds the read cap are uncoverable here exactly as in 3A. (For a file-path review of an unchanged file there is no plan — read the whole file, paging until `isTruncated` is false, per Step 1's no-diff branch.) (**Medium is not an inline pass** — it runs the Step 3A/3B fan-out and Step 4 verification like high, minus the reverse audit; see the effort table and Step 3.)
+At low effort there are no subagents: you are the finder, in this context, and you walk the diff once per angle rather than once in total. The diff is still read via the chunk plan — `read_file` per chunk range, paging oversized chunks; the read-cap rules from Step 1 apply unchanged, and chunks whose `maxLineChars` exceeds the read cap are uncoverable here exactly as in 3A. (For a file-path review of an unchanged file there is no plan — read the whole file, paging until `isTruncated` is false, per Step 1's no-diff branch.) (**Medium is not an inline pass** — it runs the Step 3A/3B fan-out and Step 4 verification like high, minus the reverse audit; see the effort table and Step 3.)
+
+**Directed angles, then a sweep — not one pass.** A single undirected read of a diff is the weakest thing this skill can do, and it was what low did: one walk, self-censoring under the "silence is better than noise" constitution, capped at 8. What replaces the subagent fan-out at this level is not fewer readers — it is **the same reader, rotated**. Fan-out along the dimension is what buys recall in 3A; at low you buy the same thing by walking the diff once per angle, in this context, sequentially. It costs no subagent, no build, no verification, and no worktree; it costs turns, and it is still an order of magnitude cheaper than medium.
+
+The angles below are the ones that pay at hunk-only depth — every one of them can be answered from the diff text plus its context lines, because low reads nothing else. **Walk the first `plan.budget.inlineAngles` of them, in the order listed, one at a time**, and surface **up to 6 candidates each**. The order is not arbitrary and the budget is what makes it load-bearing: A, B and C are always walked, because each is defined by _how_ it walks rather than by a topic and each is answerable on a diff of any size; D, E and F unlock as the diff grows, one per 60 source lines, because a wrapper that routes wrongly, a helper duplicated across files, and a sibling that lost its guard all need enough code present to be visible at all. Do not merge them into a single "look for bugs" read: that is the pass this replaces, and it converges on whichever hunk looks most suspicious while nine-tenths of the diff goes unexamined.
+
+- **A — line-by-line.** Every hunk, every changed line. What input, state, timing or platform makes this line wrong? Inverted or wrong conditions, off-by-one, null/undefined deref where nearby lines show the value can be absent, falsy-zero (`if (x)` where `0` or `''` is valid), a missing `await`, wrong-variable copy-paste, an error swallowed by a `catch` that should propagate, unescaped regex metacharacters.
+- **B — removed behaviour.** Every line the diff **deletes or replaces**. Name the invariant it enforced, then look for where the new code re-establishes it. A removed guard, a dropped error path, a narrowed validation, a deleted test that covered a real case. When the re-establishment would live outside the diff you cannot check it — report at `Confidence: low` and say so; do not assert it is missing.
+- **C — language pitfalls.** The classic footguns of this diff's language and framework, and only instances the diff **introduces**: JS falsy-zero, `==` coercion, a closure capturing a loop variable; Python mutable default arguments and late-binding closures; Go nil-map writes and range-variable capture; SQL string interpolation; timezone/DST arithmetic; float equality; integer division.
+- **D — wrapper and proxy routing.** When the diff adds or changes a type that wraps another — a cache, proxy, decorator, adapter — check that every method routes to the **wrapped instance** and not back through a registry, session or global (a caching provider whose `delegate` field resolves through `session.get(...)` instead of `delegate.get(...)` re-enters its own cache or recurses), and that the wrapper forwards every method its callers actually use.
+- **E — reuse and dead code.** New code that re-implements a helper **visible in the diff or its context** (low does not grep), the same block pasted into two files in this one change, and code the diff leaves unreachable: a function, branch, export or import nothing reaches once this lands.
+- **F — sibling consistency.** Where the diff touches one member of a parallel family — sibling loaders, the arms of a switch, the handlers of a route table, two functions that build the same command — and the family's other members are **also visible in the diff**, check that a guard, validation, cleanup or shape-check present in one is present in all. The missing half is a latent asymmetric failure.
 
-**One pass over the diff.** Flag runtime-correctness bugs visible from the hunks alone: inverted/wrong condition, off-by-one, null/undefined deref where nearby lines show the value can be absent, a guard removed in the hunk, falsy-zero, missing `await`, wrong-variable copy-paste, an error swallowed by a catch that should propagate. Also flag — still from the hunks alone — new code duplicating a helper visible in the diff context, and dead code the diff leaves behind. Do not read full source files, do not grep the codebase, do not run anything. Project rules are not loaded at low (Step 2 is skipped). Cap: **8 findings**, most severe first.
+**Then one sweep, when `plan.budget.sweep` is true.** On a diff small enough to hold entirely in view the sweep is skipped, and that is not a saving grace-noted in passing — a second reader of the same few hunks _is_ the first reader, and "what did the first pass not get to" has no answer when the first pass got to all of it. Otherwise, take a further pass, in this same context, as a fresh reviewer who has been handed the deduplicated candidate list. Re-read the hunks looking **only for what is not already on it** — do not re-derive, re-confirm or re-argue anything already there; the job is gaps. What a first pass reliably misses: code that was **moved or extracted** and dropped a guard or an anchor on the way; second-tier footguns (a default evaluated once at definition time, a lock whose scope shrank, a predicate method with a side effect, iteration order relied on but not guaranteed); setup/teardown asymmetry in tests; a config default that flipped. Up to **6 more** candidates. If nothing new, return nothing from the sweep — do not pad it.
 
-Low uses the standard finding format, including **Failure scenario**, and the reporting gate applies unchanged: a Suggestion with no concrete scenario or cost is dropped; a suspected Critical you cannot pin down is kept with `Confidence: low`.
+**Pool and deduplicate — do not re-judge.** Merge near-duplicates only: same defect, same location, same reason keeps one, at the highest severity any copy carried. Do not run a verification pass over your own candidates and do not drop one because you are no longer sure — low is explicitly an unverified tier, it says so in its own label, and a candidate you delete here is one no later stage can recover. Sort by severity. Cap: **10 findings**, most severe first.
+
+**Do not read full source files, do not grep the codebase, do not run anything.** That restriction is what makes low cheap, and it is also why the angles above are the ones they are. Project rules are not loaded at low (Step 2 is skipped).
+
+**Say which angles you walked.** End the pass with one line per angle walked, naming what it examined — `B — 3 deleted hunks in submit.ts and parse-args.ts; both guards re-established at the new call site` — the same evidence-bearing return every subagent owes in 3A. This is the only check low has: nothing here reads a transcript, so a pass that skipped four angles and reported two findings is indistinguishable from a clean diff unless it says so. If the union of the passes you ran yields fewer than `min(files_changed, 3)` candidates, treat that as a signal you stopped early and re-walk the angles you finished fastest — **but do not invent findings to reach it**; a genuinely clean small diff legitimately produces none, and reports none.
+
+Low uses the standard finding format, including **Failure scenario**, and the reporting gate applies unchanged: a Suggestion with no concrete scenario or cost is dropped; a suspected Critical you cannot pin down is kept with `Confidence: low`. The recall rule the fan-out briefs carry applies to you here too — you are the finder, so file every candidate whose scenario you can name rather than withholding the half-believed ones.
+
+(Why this is prose and not a subcommand, unlike every other prompt in this skill: there is no second party to relay it to. The delivery checks exist because a prompt built for a _subagent_ has to survive being copied by the orchestrator, and measurably does not. At low the orchestrator **is** the agent, and this document is already in its context — there is no copy to drift.)
 
 Then skip Steps 4 and 5 entirely and go to Step 6 with these adjustments:
 
@@ -480,6 +509,7 @@ Then skip Steps 4 and 5 entirely and go to Step 6 with these adjustments:
 - Emit **no verdict** — no Approve / Request changes / Comment, and skip the open-Criticals re-check (that gate defends a verdict this pass does not claim). Chunks that are uncoverable by `maxLineChars` are still listed under "Not reviewed".
 - Follow-up tip: "Tip: run `/review <target> --effort medium` for a verified balanced review, or `--effort high` for the full verified review." For a local review with findings, also offer the `fix these issues` tip.
 - Step 7 never runs — `--comment` forces high effort, and if the user asks to "post comments" after a quick pass, decline and point at `--effort high` (unverified findings must not be posted publicly).
+- Step 6B never runs either, and cannot: an effective `--fix` floors the effort at medium (Step 1), so no low pass is ever a `--fix` run. If the user asks to apply the findings after a quick pass, the same reasoning as posting applies with the target changed — editing their files on the strength of an unverified finding is the mistake, not publishing it — so point at `/review --fix`, which re-runs at medium and produces findings a verifier has ruled on.
 - In Step 8, save the report (marked with the effort level) but do **not** write the incremental cache — a quick pass must never make a later full review report "No new changes since last review". Step 9 cleanup runs as usual.
 
 ## Step 4: Deduplicate, verify, and aggregate (high and medium effort)
@@ -490,7 +520,7 @@ Before verification, merge findings that refer to the same issue (same file, sam
 
 ### Batch verification
 
-Launch verification agents that between them receive **all** non-pre-confirmed findings. **Up to 8 findings per agent**, so `ceil(N / 8)` agents, launched together in one response.
+Launch verification agents that between them receive **all** non-pre-confirmed findings. **Up to `plan.budget.verifyShard` findings per agent** (8), so `ceil(N / verifyShard)` agents, launched together in one response. It is flat rather than size-derived on purpose: it is a fact about how much a verifier can re-trace before its quality collapses on the tail of its list, which is a property of the verifier and not of the diff. It lives in the budget so it has one home instead of being restated here and in whatever reads it.
 
 A single verifier for every finding was cheaper, but on a large review it becomes the most context-starved agent in the pipeline: it must re-read code for each of 30-60 findings inside one context window, and its quality collapses on the tail of the list. Sharding keeps each verifier's job small; the cost is still far below one-agent-per-finding.
 
@@ -509,6 +539,12 @@ Write this shard's findings to a file — each with its file, line, issue and fa
 
 The brief holds the method the orchestrator used to spell out here and that a paraphrase kept dropping: trace the failure scenario through the real code rather than voting on the finding's prose; engage the diff's own documented intent before calling a documented change a regression (the rule a run skipped when it auto-posted a false "leaks tokens" Critical); the one-way, quote-the-contradiction bar on **rejecting a Critical**; and — when a finding's claim is **runnable** and the repo has a fast unit harness (`vitest`/`jest`/`pytest`) — the option to **write and run a probe** and let the observed behaviour, not a re-reading, settle the verdict. That last one earns its place: measured on this repo, the strongest model traced a real double-execute (`!git push` firing twice) and called it correct; a probe that runs the path reports `sendShellCommand called twice` and the guessing stops. The brief makes the probe evidence rather than theatre with two hard rules — a mandatory self-check that the probe **flips** between buggy and correct, and leaving the tree exactly as found (no probe file, no fix edit, reaches the diff or build). A finding a probe confirmed carries `Source: [probe]`, which `compose-review` treats as deterministic (a run produced it), exactly like `[build]`/`[test]`. Read the brief to know what a verdict means; do not re-derive it here.
 
+The brief also carries the **render-adjudication capability**: when the user has set `QWEN_REVIEW_SCRATCH_REPO` (an `owner/repo` designated for disposable test posts), a verifier facing a claim about GitHub's own rendering — mention defusal, tag stripping, fold behaviour — may post the minimal payload to that repo and read back GitHub's rendered HTML (`Accept: application/vnd.github.html+json`), because a local markdown library is only a model of GitHub and a claim about the authority cannot be settled against a model of it. Without the setting, such claims cap at low confidence / `cannot tell` rather than being "confirmed" off an approximation. This is the one narrowly-scoped exception to the no-writes rule, and Step 7 names it.
+
+The brief also carries the **A/B capability**, which is the probe's counterpart for a claim that a probe structurally cannot settle. A probe runs the PR's code and answers "what does it do now"; it cannot answer "and what did it do before". A whole class of finding is exactly that difference — "this changes the output format", "this only adds a field", "cancelled and failed used to be indistinguishable" — and recovering the old behaviour by reading the diff is the step that goes wrong quietly, because the new lines are always present and always look right. So a verifier facing a comparative claim can run `qwen review base-tree`, which builds the merge base in a sibling worktree, and then run the same input on both sides and quote both outputs. Until this existed, `mergeBaseSha` was used for exactly one thing — choosing the diff range — and no step in this pipeline had ever built the code the PR is a change _to_. It costs an install and a build (reused across the review once built), so it is spent per finding rather than per review, and an unavailable base (no merge base, a stale one, a base that will not compile) is a fact about the harness that never becomes a finding against the PR.
+
+The brief also carries **`extract-step`**, which is the A/B's counterpart for a claim about a **workflow**. A `run:` script is a shell program that happens to live inside YAML, and reviewing one in place fails in a way reading normal code does not: the body is indented inside a block scalar, the `env:` that decides its behaviour is spread over three levels — workflow, job, step, nearest wins, and two of them sit nowhere near the step — and every `${{ … }}` is a hole the reader silently fills in. `qwen review extract-step` lifts the script out **verbatim** as an executable and reports what the runner would have supplied around it: the merged three-level `env:` with each key's level named, every `${{ … }}` site listed unevaluated (the stub list — the command refuses to invent values), the resolved `shell` and `working-directory`, and a heuristic list of invoked commands. What to stub and what to feed it stays with the verifier, which is the judgment half; with `base-tree`, the two arms of a workflow A/B become two invocations. A `uses:` step has no `run:` and is refused rather than simulated.
+
 **After verification:** remove all rejected findings. Separate confirmed findings into two groups: high-confidence and low-confidence. Low-confidence findings appear **only in terminal output** (under "Needs Human Review") and are **never posted as PR inline comments** — this preserves the "Silence is better than noise" principle for PR interactions.
 
 ### Pattern aggregation
@@ -629,12 +665,22 @@ List every chunk that returned `Uncoverable` in Step 3, with the files it spans,
 
 If there are none of these, omit this section.
 
+### Previous round's findings (incremental re-review only)
+
+The ledger has two sources, in priority order: **the PR itself** — `pr-context` recovers the machine ledger embedded in this account's last posted review and renders it as the "Previous /review round (machine ledger)" section (also written beside the context file as `qwen-review-pr-<n>-prev-ledger.json`) — and, as fallback for rounds that never posted, the local cache. The PR copy is authoritative because it survives what the cache cannot: CI, another machine, a fresh clone. **This ruling section runs at medium effort too** — recovering the ledger costs nothing (pr-context already fetched the reviews), and a re-review that ignores what it told the author last round is the amnesia this exists to end; medium still writes no cache and posts nothing, exactly as before. When either source loaded a ledger, this review is **round N+1 of the same PR**, and the single most useful thing it can tell the reader is what happened to round N's findings — a re-reviewer who only lists new findings leaves the author to diff two reports by hand. Rule on **every** ledger entry against the code at the reviewed commit, exactly the way the open-Criticals re-check below rules (trace the mechanism; the diff containing a fix is not the same claim as the defect no longer firing):
+
+- **fixed** — the mechanism can no longer fire. Say so, by id, in one line: `R1-2 fixed by <what>`. Do not re-report it as a finding. The sibling-entrance rule from the re-check below applies here unchanged: for a divergence-class entry, `fixed` is a ruling about the family's entrances, checked one by one — a still-open sibling becomes a fresh `R<round>-<n>` entry, never a reason to withhold the original's `fixed`.
+- **still stands** — re-report it **under its original id**, updating the location if the code moved. It keeps its severity; a still-standing Critical blocks exactly as a new one would. Write that id into the re-report itself, immediately after the severity marker — `**[Critical]** R1-2: <the claim>` — and into the body entry if it cannot be anchored (`R1-2 <the claim>`). That prefix is not decoration: `compose-review` reads it back out of the comment when it builds the marker, and it is the only way an id survives into the machine ledger the next round recovers. Omit it and the same claim comes back renumbered, which is exactly what carrying the id forward exists to prevent.
+- **cannot tell** — say so by id; a previous-round _Critical_ you cannot rule on joins `cannotTellCriticals` (it caps like any undecided blocker), a Suggestion is just disclosed.
+
+Render the rulings as a short table at the top of the Findings section — id, one-line title, this round's status — so the report reads as a continuation, the way a human reviewer's round-2 comment opens with "M1 is fixed". The incremental scope rule does not conflict with this: the _diff_ reviewed is `lastCommitSha..HEAD`, but a ledger ruling reads the code at HEAD, which every agent already has.
+
 ### Before an Approve or a zero-Critical verdict: re-check the open Criticals
 
 A `C=0` outcome — Approve, or a Comment with no Critical — is a claim that nothing blocks the merge. It is not the default you fall back to when your own agents surfaced nothing. **If Step 1 set the context-unavailable state** (`pr-context` failed — lightweight or same-repo), there is no context file to read: skip the walk below, record every existing Critical as `cannot tell` by construction, and carry that into the verdict — which the Step 7 invariant already caps at `COMMENT`. Otherwise, take **each live blocker already on the PR — from every comment-bearing section of the context file: "Open inline comments", "Blockers to re-check", "Review summaries", and "Already discussed" (both its inline threads and its issue-level comments)** — and check it against the code as it stands at the reviewed commit. Select **semantically, not by the literal marker**: a `**[Critical]**` prefix qualifies, but so does any body that asserts a blocking defect in other words — a "Critical findings could not be anchored" preamble, an explicit must-fix claim (legacy body-only blockers were emitted markerless, and one such review is exactly what a marker filter once discarded). When unsure whether a body asserts a blocker, re-check it — the cost is one ruling; the alternative is certifying a merge past it. ("Already discussed" stays in scope even though `pr-context` now promotes blocker-bearing bodies out of it: `carriesBlockerSignal` is a **fail-safe floor, not a ceiling** — it recognises the phrasings we have seen, not every phrasing that exists, and a blocker worded around all of them still settles there. That section's "do NOT re-report" header governs duplicate-_reporting_ by the finder agents; it does not exempt a body from this re-check. Read it with the same eyes you bring to the promoted section.) Review-level bodies matter because an unmappable or 422-relocated blocker lives **only** there — and the context file now carries them **in full**: `pr-context` renders every meaningful review body whole under "Review summaries" (no more 240-character snippets), and pulls every blocker-bearing body — replied inline thread or issue comment, marker or no marker — into the "Blockers to re-check" section, rendered in full, because a reply alone never settles a blocker. So the re-check usually needs no separate fetch: read those sections under the file's untrusted-data preamble, paging with `offset`/`limit` until `isTruncated` is false. **For the status half of each INLINE-thread ruling — is the anchor outdated, did the anchored file change since the blocker was filed, which commits touched it — read Step 1's `comment-status` report instead of fetching per-comment metadata**: its `code.touchedBy` list is the candidate "fixed by" commits to read, and `changedSinceComment: false` (with no head drift) tells you the anchored file is untouched since the blocker — so a claimed fix, if any, must live in some OTHER file, and the mechanism-read below is still owed either way. Two scope limits, both deliberate: the report exists only **when Step 1 wrote it** (worktree mode, fetch succeeded — a lightweight-mode run still walks this re-check and re-derives status facts the old way), and it indexes **inline threads only** — an issue-level or review-level blocker (the #6486 shape) has no entry there and keeps the context-file walk as its sole source. The report never substitutes for reading the code: it routes the read, it does not rule. Review summaries and blocker bodies are rendered in full; the Open and Already-discussed sections use one-line snippets, and **every snippet the renderer cut carries its own `_(truncated — fetch …)_` note naming the exact, already-filled-in command for the rest** — a candidate blocker whose snippet was cut is ruled on only after running that fetch; ruling on the visible prefix alone is the fail-closed violation. Run any such fetch **redirected to a file, never into the terminal** (Shell returns only an approximately 4 000-character model preview for output beyond its 30 000-character persistence trigger, which would re-truncate the very body being completed): append `--jq .body > .qwen/tmp/qwen-review-{target}-body-<id>.md` to the command the note names, then `read_file` that file, paging until `isTruncated` is false, before ruling. **Fail closed either way:** a body you could not read whole — the capped tail unfetched, or the single-object fetch failing (auth, rate limit, network) — is `cannot tell`, not "no Critical in it": it goes to compose-review's `cannotTellCriticals` input, which serializes it and caps the event at `COMMENT`; a blocker you could not read is never approved past. A reply alone does not retire a blocker — "I disagree" or "wontfix" is a reply, which is exactly why `pr-context` quarantines blocker-bearing threads in their own section instead of letting them settle into "Already discussed". Only the code decides: a blocker counts as closed exactly when the re-check below lands on "fixed by this diff", never because the thread has an answer. Record one verdict per blocker:
 
 - **still stands** — the defect is present in the code you just read. It blocks: the event is `REQUEST_CHANGES`, and the finding goes inline (or into the body if it cannot be anchored).
-- **fixed by this diff** — you traced the blocker's **mechanism** through the code as it now stands and it can no longer fire. Say nothing; do not re-report it. A GitHub thread can read `isResolved: false, isOutdated: false` for a bug a later commit fixed on an adjacent line — the flag tracks the anchored line, not the fix, so the flag is not evidence either way. Only the code is.
+- **fixed by this diff** — you traced the blocker's **mechanism** through the code as it now stands and it can no longer fire. Say nothing; do not re-report it. A GitHub thread can read `isResolved: false, isOutdated: false` for a bug a later commit fixed on an adjacent line — the flag tracks the anchored line, not the fix, so the flag is not evidence either way. Only the code is. **And "the mechanism" means the FAMILY, not the one input the fix answered**: when the blocker is a divergence-class defect — a parser bypass, an escaping hole, a filter gap — enumerate the sibling entrances to the same mechanism and check each one at the reviewed commit before ruling `fixed`. A live six-round dogfood is the caution: the fix closed the fence-shaped door into a raw-HTML block, and the code-span door beside it — same divergence, adjacent syntax — stayed open; a re-check that tested only the reported input ruled `fixed` over a hole one backtick away. A sibling entrance you found still open is a **new finding** (report it), and the original blocker is still `fixed` only if its own input is closed — the two rulings are separate, and conflating them is how the second hole ships unreviewed.
 
   **"The diff adds a fix" is not the same claim as "the defect can no longer fire", and this verdict requires the second one.** A fix's new lines are in the diff, but whether they _work_ frequently turns on code the diff never touches — a sibling subscriber, a registry entry, a dispatch order, a global binding, a default in a caller three files away. Read the diff alone and you see a plausible fix and rule it good. **So: name the mechanism the blocker claims, then name what now stops it. If that stopping condition lives outside the diff, go read it at the reviewed commit — a blocker in "Blockers to re-check" carries a `Referenced code` list extracted from its own body whenever it names a file, and the locations on it that the PR does not touch are precisely the ones this rule is about.** If you did not read them, you do not have this verdict; you have `cannot tell`. A blocker that cites no file gets no list, and hands you no shortcut: trace the mechanism through the code yourself, on the same terms.
 
@@ -661,6 +707,30 @@ Two failure modes this closes, both observed in this repo's own dogfood: reporti
 
 **You do not read its output or decide anything from it — `compose-review` does.** It derives the report's path from the plan (the pr-numbered name above, next to the plan; `qwen-review-script-lint.json` for a local review), reads it as the sole authority, and turns it into the verdict itself: a finding on a **changed line** above cosmetic `style` becomes a **pre-confirmed `[lint]` Critical** that needs no verifier (the tool already ran); an **uninstalled or crashed** checker becomes **unreviewed scope** that caps a would-be Approve; a **deferred** checker — a workflow's embedded `run:` shell, which `actionlint` would lint but whose output this env cannot trust — is **disclosed in the body on every verdict (including Approve) but does not cap**, because it is a tool limitation, not a gap the author can close; and — the proof it ran — a diff that carries an executable script but produced **no readable report** is itself unreviewed (fail closed). That is the whole reason it runs here rather than inside an agent: neither the blocker nor its severity depends on a model, and skipping the command cannot slip an Approve past the fail-closed gate. It is harmless when the diff has no scripts (it reports "nothing to lint"), and it must write to the derived path or `compose-review` will not find it.
 
+### The Test Plan check (deterministic — you run it, not an agent)
+
+**For a PR review, rule on the claims the author already wrote down.** A Test Plan is the one place in a pull request where the author states, in their own words, what they ran and what they saw — a list of falsifiable assertions, handed to the reviewer for free. Nothing in this pipeline read it. `pr-context` renders the PR body, but its consumer is Agent 0, whose question is root-cause fidelity ("is this the right fix for the linked issue?"), not "the author says 471 tests pass — do they?". So a Test Plan could name a file the diff never adds, invoke an npm script that does not exist, or report a count from three commits ago, and the review would approve around it.
+
+```bash
+"${QWEN_CODE_CLI:-qwen}" review test-plan \
+  --plan <the plan report from Step 1> \
+  --pr <pr_number> --repo <owner>/<repo> \
+  --worktree <worktreePath> \
+  --build-test <Agent 7's build-test report, when this review produced one> \
+  --out <the plan report's directory>/qwen-review-pr-<n>-test-plan.json
+# GitHub Enterprise: add --host <host> — it fetches the PR description.
+```
+
+Run it on a same-repo **PR** review only. A **local** or **file** review has no PR body, and a cross-repo **lightweight** review has no worktree to resolve paths against; the command is skipped in both, and `compose-review` expects nothing from it there.
+
+**You do not read its output or decide anything from it — `compose-review` does**, from the path derived off the plan, exactly as it does for `script-lint`. What it rules on, and what it deliberately refuses to:
+
+- A **path** the Test Plan names that is in neither the diff nor the tree at the reviewed commit is `contradicted` — the sentence describes a commit that is not this one. A path that exists but the diff does not touch is fine: "ran the existing suite at X" is a legitimate thing to write.
+- An **npm script** the Test Plan tells the reviewer to run that no workspace manifest defines is `contradicted` — the Test Plan cannot be followed. A command this review actually ran is settled by its exit code instead, which outranks the manifest lookup.
+- A **test count** that differs from what this review's suites reported is `differs`, and **never** `contradicted`. A count is only falsifiable against the suite the author meant, and a Test Plan almost never says which one; `build-test` runs the subset of workspaces the diff touched, which is frequently a different set. Ruling "471 ≠ 472, contradiction" off that mismatch would file a defect on arithmetic the command cannot do. Both numbers are reported side by side, and the reader decides.
+
+**None of it blocks, and none of it caps.** A Test Plan defect is not a code defect — the diff is unaffected — and the verdict is about the code. The notes are disclosed in the body on every event including Approve, the same disclosed-but-not-capping treatment a deferred checker gets, and for the same reason: an author cannot fix "you wrote a sentence I could not check", so it must never become a permanent cap.
+
 ### Verdict
 
 **You do not decide the verdict, and you do not write it. Ask for it:**
@@ -690,20 +760,59 @@ The rules it applies — so you can read the line it gives you, not so you can a
 
 **The `FIX:` lines on stderr are that repair, spelled out.** For every repairable gap it capped on, `compose-review` prints one `FIX:` line naming the command — with this run's plan path already substituted. The parts that vary per agent stay as selectors: take `<id>`, `<r>` and `<path>` from the labels in the same report (never paste a literal `<...>` into a shell — it parses as a redirection), and add the `--rules` file whenever Step 2 loaded one. Execute them — **one repair round, then `compose-review` again**. If the same gap survives the round, stop: the cap stands, post with it, and disclose the gap. Do not loop repairs hoping for a different verdict, and do not skip the round and post a capped verdict the FIX lines could have lifted — both are the same failure, choosing the verdict over the evidence, in opposite directions.
 
+### The findings, as data
+
+**Write the findings artifact before you do anything else with them.** Everything that matters in this pipeline is a computed artifact — the diff plan, the coverage report, the resolved anchors, the verdict — and the findings were the one exception: prose in a terminal, re-typed into the Step 8 report, re-typed again into the Step 7 review JSON. Three transcriptions of the same list, and this skill's history is a catalogue of what transcription costs (a Critical that changed severity between two sections of one review; an aggregate that arrived at `resolve-anchors` with its per-location anchors dropped and took the whole batch down).
+
+Write every confirmed finding — high and low confidence alike — as a JSON array, then:
+
+```bash
+"${QWEN_CODE_CLI:-qwen}" review findings \
+  --input .qwen/tmp/qwen-review-{target}-findings-in.json \
+  --out .qwen/tmp/qwen-review-{target}-findings.json
+```
+
+**One finding, one name.** A high-effort PR review also writes the incremental cache's cross-round `findings` ledger (Step 8), whose ids are `R<round>-<n>` — use those same ids here: a finding that will enter the ledger gets its `R<round>-<n>` as the artifact `id`, and a carried-forward finding keeps the id it already has. Two id schemes for one finding is how "R1-2" in next round's report and "f7" in this round's outcome ledger turn out to be the same defect that nobody can join.
+
+Each entry carries `id` (unique — outcomes and resolved anchors both join on it), `severity`, `confidence`, `source`, `summary`, `failureScenario`, and either `file`/`line`/`anchor` or, for a pattern aggregate, a `locations[]` array with **one entry per location** (`suggestedFix`, `category` and `shortSummary` are optional; `shortSummary` is derived from `summary` when absent). The command validates the shape, refuses a duplicate id, refuses a finding with no failure scenario, sorts by severity → confidence → file → line → id, and writes counts nobody then recomputes by hand. Read the artifact for the numbers you quote in the Summary. This is a **canonicalization**, not a gate: it does not decide the verdict — `compose-review` does that, from the same findings — and it does not run at low effort, where the pass is unverified and emits no verdict.
+
+### Step 6B: Apply the findings (`--fix`)
+
+**Run this only when the Step 1 verdict says `fix.effective` is true.** A requested-but-ineffective `--fix` (a PR target) has already produced its warning in Step 1; say nothing further and move on.
+
+Apply each finding to the working tree with the `edit` tool — Criticals and the reuse/simplification/consistency findings alike. **Skip** any finding whose fix would change intended behaviour, would require changes well outside the reviewed diff, or that you judge on a second look to be a false positive. Note the skip; do not argue with it in prose.
+
+Then record what happened to **every** finding — one of `fixed`, `skipped`, or `no_change_needed` — as a JSON array of `{id, outcome, note?}`, and merge it back:
+
+```bash
+"${QWEN_CODE_CLI:-qwen}" review findings \
+  --input .qwen/tmp/qwen-review-{target}-findings-in.json \
+  --outcomes .qwen/tmp/qwen-review-{target}-outcomes.json \
+  --out .qwen/tmp/qwen-review-{target}-findings.json \
+  --print
+```
+
+**The command refuses a ledger that does not account for every finding**, and that refusal is the whole reason it exists. A fixer that applies six of nine findings and reports six has not lied about any one of them — it has silently shortened the list, and the reader has no way to see the three that fell off. It also refuses an outcome for an id this review never produced, which is what a ledger built against the wrong list looks like. If it exits non-zero, the ledger is wrong, not the check: complete it and run it again.
+
+The three words are three different claims and are not interchangeable. `fixed` — the edit is in the tree. `skipped` — the finding is real and you did not apply it; the note says why, and the reader still owes it attention. `no_change_needed` — the finding was wrong or the code already handled it; it comes **off** the reader's plate. Collapsing `skipped` into `no_change_needed` is how a review quietly retracts a finding it could not fix.
+
+Report the outcome counts in the terminal summary, and list each `skipped` finding with its reason. **Do not re-run Steps 1–6** to check your own work: a re-review of a tree you just edited is a new review of different code, and its verdict is not this review's.
+
 Append a follow-up tip after the verdict (high and medium effort — only a **low** quick pass emits no verdict and uses Step 3C's tip instead; its "post comments" follow-up is declined per Step 3C). At **medium**, also add: "Tip: run `/review <target> --effort high` for the full verified review (adds the reverse audit, the adversarial personas, and Agent 8 — and can certify Approve)." Choose the rest based on remaining state:
 
-- **Local review with unfixed findings**: "Tip: type `fix these issues` to apply fixes interactively."
+- **Local review with unfixed findings** (Step 6B did not run — `--fix` was not passed): "Tip: type `fix these issues` to apply fixes interactively, or re-run with `/review --fix` to have the review apply and account for them itself."
+- **Local review where Step 6B ran**: offer no fix tip — the findings already carry outcomes. If any came back `skipped`, say so with their reasons instead.
 - **PR review with findings** (only if `--comment` was NOT specified — if `--comment` was set, comments are already being posted in Step 7, so this tip is unnecessary): "Tip: type `post comments` to publish findings as PR inline comments." (Do NOT offer "fix these issues" for PR reviews — the worktree is cleaned up after the review, so interactive fixing is not possible.)
 - **PR review, zero findings** (only if `--comment` was NOT specified): "Tip: type `post comments` to approve this PR on GitHub."
 - **Local review, all clear** (Approve or all issues fixed): "Tip: type `commit` to commit your changes."
 
-If the user responds with "fix these issues" (local review only), use the `edit` tool to fix each remaining finding interactively based on the suggested fixes from the review — do NOT re-run Steps 1-6.
+If the user responds with "fix these issues" (local review only), use the `edit` tool to fix each remaining finding interactively based on the suggested fixes from the review — do NOT re-run Steps 1-6. This is the same work Step 6B does; when the review has a findings artifact, record the outcomes into it the same way (`review findings --outcomes`) rather than leaving the list and the tree disagreeing about what was applied.
 
 If the user responds with "post comments" (or similar intent like "yes post them", "publish comments"), proceed directly to Step 7 using the findings already collected — do NOT re-run Steps 1-6.
 
 ## Step 7: Submit PR review
 
-**The whole rule in one sentence, so it survives even when the rest is compressed away: never run a `gh` command that writes to the pull request — `qwen review submit` is the only write path in this skill, and it refuses when the run is not authorised.** Everything below only spells out what "writes" covers so a compressor cannot quietly narrow it to a single API route. It is **every write path to the PR**, not one: no `gh api repos/.../pulls/<n>/reviews` (not to submit, not to "test" an anchor), no `gh pr comment`, no `gh pr review`, no `gh issue comment`, no `gh api` with POST/PATCH/PUT/DELETE against the PR's `issues/*` or `pulls/*` endpoints, and no editing or deleting existing comments. **You do not author PR-facing prose at all** — `compose-review` computes the review body from structured state (the verdict, the downgrade reasons, the body-Criticals), and there is no free-text field to pass through it; a free-form note you want to add is a note for the **terminal summary**, which the user reads, not for the pull request. The only text that reaches the PR is that computed body plus the inline finding comments, and both ride the one sanctioned write below. Dogfooded the hard way: a run that had lost these instructions to four context compressions decided its findings were "all duplicates", never called submit, and hand-posted a consolidated summary with `gh pr comment` — a write with no authorisation gate, no downgrade semantics, no `posted` fact, and no completion line; nothing downstream could tell it had happened. `cleanup` now audits the review window and flags issue comments by the reviewing account (submit never posts one — see Step 9), so that bypass is at least named in the terminal — a tripwire, not permission. The one write in this skill lives behind a check:
+**The whole rule in one sentence, so it survives even when the rest is compressed away: never run a `gh` command that writes to the pull request — `qwen review submit` is the only write path in this skill, and it refuses when the run is not authorised.** Everything below only spells out what "writes" covers so a compressor cannot quietly narrow it to a single API route. It is **every write path to the PR**, not one: no `gh api repos/.../pulls/<n>/reviews` (not to submit, not to "test" an anchor), no `gh pr comment`, no `gh pr review`, no `gh issue comment`, no `gh api` with POST/PATCH/PUT/DELETE against the PR's `issues/*` or `pulls/*` endpoints, and no editing or deleting existing comments. (One narrowly-scoped carve-out exists and it does not touch the PR: the Step 4 render-adjudication check may post a minimal payload to the repo the **user designated** in `QWEN_REVIEW_SCRATCH_REPO` — that repo, that check, nothing else; absent the setting there is no carve-out at all, and nothing about the PR, its code, or its authors is ever posted there.) **You do not author PR-facing prose at all** — `compose-review` computes the review body from structured state (the verdict, the downgrade reasons, the body-Criticals), and there is no free-text field to pass through it; a free-form note you want to add is a note for the **terminal summary**, which the user reads, not for the pull request. The only text that reaches the PR is that computed body plus the inline finding comments, and both ride the one sanctioned write below. Dogfooded the hard way: a run that had lost these instructions to four context compressions decided its findings were "all duplicates", never called submit, and hand-posted a consolidated summary with `gh pr comment` — a write with no authorisation gate, no downgrade semantics, no `posted` fact, and no completion line; nothing downstream could tell it had happened. `cleanup` now audits the review window and flags issue comments by the reviewing account (submit never posts one — see Step 9), so that bypass is at least named in the terminal — a tripwire, not permission. The one write in this skill lives behind a check:
 
 ```bash
 "${QWEN_CODE_CLI:-qwen}" review submit \
@@ -860,12 +969,12 @@ Rationale: an inline comment is the only place GitHub renders a ` ```suggestion
     {
       "path": "src/file.ts",
       "line": 42,
-      "body": "**[Critical]** issue description — Failure scenario: <trigger> → <wrong outcome>\n\n```suggestion\nfix code\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review_",
+      "body": "**[Critical]** issue description — Failure scenario: <trigger> → <wrong outcome>\n\n```suggestion\nfix code\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review (v{{cliVersion}})_",
     },
     {
       "path": "src/other.ts",
       "line": 88,
-      "body": "**[Suggestion]** recommended improvement — Concrete cost: <what is duplicated/wasted/fragile>\n\n```suggestion\nimproved code\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review_",
+      "body": "**[Suggestion]** recommended improvement — Concrete cost: <what is duplicated/wasted/fragile>\n\n```suggestion\nimproved code\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review (v{{cliVersion}})_",
     },
   ],
   "state": {
@@ -904,7 +1013,7 @@ The verdict is a computed fact and this is the second place it must not be re-de
 
   When `startLine === line`, emit only `"line"` — a single-line comment needs no side (it defaults to `RIGHT`, which is what every comment here is). Do **not** send `start_line` on its own: the multi-line form that omits `start_side` is the one shape of this feature that fails, and it fails by discarding every inline blocker in the review.
 
-- Comment body format: `**[Critical]** issue description — Failure scenario: <trigger> → <wrong outcome>\n\n```suggestion\nfix\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review_` — use the `**[Suggestion]**` prefix for Suggestion-level findings so the author can tell blockers from recommendations at a glance. The `description` MUST carry the finding's concrete failure scenario (the trigger and the wrong outcome, or the concrete cost) — a posted comment that says only what to change, without why it fails, has lost the evidence the finder was required to produce. The prefix must be the **first thing in the body** and the footer must be present: `.github/workflows/qwen-autofix.yml` keys off both to keep Suggestion findings out of the autofix loop. Changing either string silently makes the autofix bot start applying non-blocking suggestions.
+- Comment body format: `**[Critical]** issue description — Failure scenario: <trigger> → <wrong outcome>\n\n```suggestion\nfix\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review (v{{cliVersion}})_` — use the `**[Suggestion]**` prefix for Suggestion-level findings so the author can tell blockers from recommendations at a glance. The `description` MUST carry the finding's concrete failure scenario (the trigger and the wrong outcome, or the concrete cost) — a posted comment that says only what to change, without why it fails, has lost the evidence the finder was required to produce. The prefix must be the **first thing in the body** and the footer must be present: `.github/workflows/qwen-autofix.yml` keys off both to keep Suggestion findings out of the autofix loop. Changing either string silently makes the autofix bot start applying non-blocking suggestions.
 - The model name is declared at the top of this prompt. You MUST include it in every footer. Do NOT omit the model name.
 - Use ` ```suggestion ` for one-click fixes; regular code blocks if fix spans multiple locations.
 - Only ONE comment per unique issue.
@@ -943,10 +1052,12 @@ Create the `.qwen/reviews/` directory if it doesn't exist. **For PR worktree mod
 Report content should include:
 
 - Review timestamp and target description
+- **Provenance — the commits and the toolchain.** The head SHA reviewed (`fetchedSha` from the fetch report) and the base it was diffed against (`mergeBaseSha`), plus the platform and the Node/npm versions the gates ran on, and one line per gate with its result (`build`, `test`, `script-lint`, `test-efficacy`, `test-plan` — ran / clean / failed / skipped, and why). A saved report is read by someone who cannot re-derive what it was about: without the SHA pair a "Verdict: Approve" names no commit, so it can be neither checked against the PR nor distinguished from an approval of a different head; and without the gate line a reader cannot tell a gate that passed from one that never ran. Both facts are already in reports this run has open — copy them, do not re-measure.
 - Effort level the review ran at (low / medium / high; **low** findings are marked unverified — medium and high verify them in Step 4)
 - Diff statistics (files changed, lines added/removed) — omit if reviewing a file with no diff
 - Build & test results (Agent 7 output summary) — high and medium effort
-- All findings with verification status
+- All findings with verification status. Read them out of the findings artifact `qwen review findings` wrote (`.qwen/tmp/qwen-review-{target}-findings.json`) rather than re-typing them from the terminal — a third transcription of the same list is a third chance for a severity to drift, which has happened inside a single review.
+- **Per-finding outcomes, when Step 6B ran** — `fixed` / `skipped` / `no_change_needed`, with the reason for every `skipped`. The artifact already carries them; a `--fix` run whose archive does not say which findings were applied is a report that reads as if all of them were.
 - Verdict (high and medium effort — a low quick pass claims none; a medium verdict never exceeds Comment, since it runs no reverse audit — see Step 5)
 
 **The report's verdict is not yours to type.** `compose-review` printed the exact `Verdict:` line in Step 6 and persisted the same line as `verdictLine` inside `.qwen/tmp/qwen-review-{target}-composed.json` — copy either, verbatim. Do not reconstruct it from `event` + `cappedBy`: a presubmit downgrade also depends on fields that pair does not carry, and a rebuilt line can differ from the computed one. (And not `$(jq …)`: a `jq` binary is not guaranteed on the host, and a substitution that fails leaves the archived verdict blank or literal — worse than absent, because it looks written.)
@@ -967,11 +1078,24 @@ If reviewing a PR **at high effort**, update the review cache for incremental re
      "lastCommitSha": "<HEAD SHA captured in Step 1>",
      "lastModelId": "{{model}}",
      "lastReviewDate": "<ISO timestamp>",
+     "round": <N — 1 on a first review, previous round + 1 after>,
      "findingsCount": <number>,
-     "verdict": "<verdict>"
+     "verdict": "<verdict>",
+     "findings": [
+       {
+         "id": "R<round>-<n>",
+         "severity": "Critical | Suggestion",
+         "file": "<path>",
+         "line": <number>,
+         "title": "<one line — enough for the next round to re-locate the claim>",
+         "status": "open"
+       }
+     ]
    }
    ```
 
+   The cache is the FALLBACK copy of the ledger — the authoritative one rides the posted review body itself: `compose-review` embeds a machine-readable marker (an HTML comment, invisible on the PR page) carrying this round's findings and round number, and the next round's `pr-context` reads it back wherever it runs. A run that posts therefore persists its ledger even when this cache write is skipped; a run that does not post has only this cache, which is exactly why the cache remains. The `findings` ledger is what lets the **next** run open with "R1-2 is fixed" instead of a from-scratch list (see Step 6's previous-round section). Write every **newly confirmed high-confidence** finding under a fresh `R<round>-<n>` id, and carry a still-standing previous entry forward **under the id it already has** — the whole payoff is that `R1-2` names the same claim in every round, so a finding that survives is re-reported, never renumbered — while a finding ruled `fixed` this round leaves the ledger (the report said so; the cache is for what the next round must check, not history). Low-confidence and terminal-only findings stay out: the ledger holds claims this review stands behind, because next round re-asserts each one by id.
+
 3. Ensure `.qwen/reviews/` and `.qwen/review-cache/` are ignored by `.gitignore` — a broader rule like `.qwen/*` also satisfies this. Only warn the user if those paths are not ignored at all.
 
 ## Step 9: Clean up