@qwen-code/qwen-code 0.21.13 → 0.21.14-preview.0

package/bundled/review/SKILL.md

@@ -88,13 +88,25 @@ The parser already classified the target, so there is nothing to disambiguate by
      --owner <the verdict's owner> --repo <the verdict's repo> --host <the verdict's host>
    ```
 
+   For an **Aone nested-group target** (`…/<group>/<subgroup…>/<project>/codereview/<id>`), also pass `--group-path <group>/<subgroup…>/<project>` (the URL's full path before `/codereview/`) — owner/repo collapse to the last two segments, and without the full path the matcher could pick a different group's same-named repo.
+
    Exit 0 prints the matching remote's name — forks included: a clone whose `upstream` points to the target repository matches that repository's PRs exactly. Exit 6 means no remote matches — go to item 3. Exit 7 means several match; tell the user and stop rather than picking one. Any other exit is fail-closed like the other gates: report it and stop.
 
 2. If a matching remote is found, proceed with the **normal worktree flow** — use that remote name (instead of hardcoded `origin`) for `git fetch <remote> pull/<number>/head:qwen-review/pr-<number>`. In Step 7, use the owner/repo from the URL for posting comments.
 
-For a `pr-url` whose `host` is not `github.com` (GitHub Enterprise), **pass `--host <host>` to every review subcommand that talks to the platform — `meta`, `fetch-pr`, `pr-context`, `comment-status`, `issue-context`, `fetch-diff`, `comment-body`, `plan-diff`, `test-plan`, `presubmit`, `compose-review`, `submit`, and `publish-assets`** — which routes all of their API calls at the right host in code; a forgotten host silently retargets them at github.com's same-named `owner/repo`. Every fetch this skill needs rides a subcommand — the one exception is Step 4's render-adjudication carve-out (a direct `gh api` against `QWEN_REVIEW_SCRATCH_REPO`, GitHub-only by nature). That call runs in a **verifier subagent's** shell, so a `--host` note here cannot reach it: it routes at the Enterprise host only when GH_HOST is **exported in the environment** (subagent shells inherit the process env). On an Enterprise run without an exported GH_HOST, render adjudication is unavailable — the verifier rules from the raw markdown and says so.
+For **every** `pr-url` target — **`github.com` included** — **pass `--host <host>` to every review subcommand that talks to the platform — `meta`, `fetch-pr`, `pr-context`, `comment-status`, `issue-context`, `fetch-diff`, `comment-body`, `plan-diff`, `test-plan`, `presubmit`, `compose-review`, `submit`, and `publish-assets`**. This routes all of their API calls at the right host in code (a forgotten host silently retargets them at github.com's same-named `owner/repo`), and it pins platform detection to the URL's host: without the hint, detection falls back to the cwd clone's origin, so a `github.com` PR reviewed from inside an Aone-origin clone (or the reverse) is hijacked to the other platform's backend. Every fetch this skill needs rides a subcommand — the one exception is Step 4's render-adjudication carve-out (a direct `gh api` against `QWEN_REVIEW_SCRATCH_REPO`, GitHub-only by nature). That call runs in a **verifier subagent's** shell, so a `--host` note here cannot reach it: it routes at the Enterprise host only when GH_HOST is **exported in the environment** (subagent shells inherit the process env). On an Enterprise run without an exported GH_HOST, render adjudication is unavailable — the verifier rules from the raw markdown and says so.
+
+For an **Aone Code** target, run `/review` **from inside a clone of that repo** (origin on `gitlab.alibaba-inc.com`). The platform is detected from the clone's remote — the read subcommands (`meta`, `fetch-pr`, `issue-context`, `fetch-diff`) work unchanged, backed by the `a1` CLI instead of `gh`; the target number is the global MR id. `fetch-pr` fetches `refs/merge-requests/<id>/head` and builds the worktree + diff as usual, so agents still review the worktree. A `…/codereview/<id>` URL pasted from OUTSIDE a clone of that repo cannot be resolved — the URL's host does pin detection (passed as `--host`), but there is then no clone to fetch the MR ref into and build the worktree/diff from — stop and tell the user to run inside the clone. Pass `--host gitlab.alibaba-inc.com` on the subcommands for Aone targets: it is harmless for the a1-backed readers and makes both detection and the `--comment` refusal fire regardless of cwd.
+
+Every Aone run is **context-unavailable** this phase, and several flows must be skipped rather than allowed to hit github.com's same-named repo:
 
-3. If **no remote matches**, use **lightweight mode**: fetch the diff directly with `"${QWEN_CODE_CLI:-qwen}" review fetch-diff <number> --repo <owner>/<repo> --out .qwen/tmp/qwen-review-pr-<number>-diff.txt` (add `--host <host>` for Enterprise). If `fetch-diff` fails here (auth, network), inform the user and stop — lightweight mode has no diff to review and no later step refetches it. Skip Step 2 (no local rules) and Step 8 (no local reports or cache). In Step 9, skip worktree removal (none was created) but still clean up temp files (`.qwen/tmp/qwen-review-{target}-*`). Also run `"${QWEN_CODE_CLI:-qwen}" review pr-context <number> <owner>/<repo> --out .qwen/tmp/qwen-review-pr-<number>-context.md` — it is pure platform API and works cross-repo. Agent 0 and Step 6's open-Critical re-check depend on it: a `Refs #123`-style target issue is only discoverable from the PR body, and open Critical threads only from the context file, so skipping it lets a wrong-root fix sail through blocker-free. If `pr-context` fails here (auth, network), warn and continue with the diff alone — but skip Agent 0 (it has nothing to work from) and treat every open-Critical re-check verdict as "cannot tell", which forbids an Approve. Carry this forward as the **context-unavailable** state: Step 7's invariant caps **every** `C=0` outcome of such a run at `COMMENT` with a diff-only body (both the would-be APPROVE and the Suggestion-only "no blockers" sentence), so a run that could not see the PR's existing discussion can post findings but never certify the absence of blockers. In Step 7, use the owner/repo from the URL. Inform the user: "Cross-repo review: running in lightweight mode (no build/test)."
+- `pr-context`, `comment-status`, `presubmit` have no Aone backing — skip them. Step 7 caps the verdict at `COMMENT`; findings are still generated.
+- `test-plan` fetches the PR body via `gh pr view` (GitHub-direct) — unbacked on Aone; treat the Test Plan as unchecked.
+- Agent 0 (issue fidelity) is gated on `pr-context` success, so it is **skipped** on Aone — do not claim issue fidelity ran. (`issue-context` works standalone for the workitem evidence, but it is not wired to Agent 0.)
+- Step 9's bypass audit queries GitHub by host; on an Aone report (host null) skip it instead of querying github.com.
+- The run **is** read-only toward the platform in this phase: `publish-assets` (Step 7) is a Contents-API write that is not Aone-backed — skip it on Aone — and **`--comment` is refused** — report the findings in the terminal and saved report only, and tell the user posting to Aone is not supported yet.
+
+3. If **no remote matches**, use **lightweight mode**: fetch the diff directly with `"${QWEN_CODE_CLI:-qwen}" review fetch-diff <number> --repo <owner>/<repo> --host <host> --out .qwen/tmp/qwen-review-pr-<number>-diff.txt` (the URL's host — `github.com` included, per the host rule above: without it the cwd clone's origin picks the platform). If `fetch-diff` fails here (auth, network), inform the user and stop — lightweight mode has no diff to review and no later step refetches it. Skip Step 2 (no local rules) and Step 8 (no local reports or cache). In Step 9, skip worktree removal (none was created) but still clean up temp files (`.qwen/tmp/qwen-review-{target}-*`). Also run `"${QWEN_CODE_CLI:-qwen}" review pr-context <number> <owner>/<repo> --host <host> --out .qwen/tmp/qwen-review-pr-<number>-context.md` — it is pure platform API and works cross-repo. Agent 0 and Step 6's open-Critical re-check depend on it: a `Refs #123`-style target issue is only discoverable from the PR body, and open Critical threads only from the context file, so skipping it lets a wrong-root fix sail through blocker-free. If `pr-context` fails here (auth, network), warn and continue with the diff alone — but skip Agent 0 (it has nothing to work from) and treat every open-Critical re-check verdict as "cannot tell", which forbids an Approve. Carry this forward as the **context-unavailable** state: Step 7's invariant caps **every** `C=0` outcome of such a run at `COMMENT` with a diff-only body (both the would-be APPROVE and the Suggestion-only "no blockers" sentence), so a run that could not see the PR's existing discussion can post findings but never certify the absence of blockers. In Step 7, use the owner/repo from the URL. Inform the user: "Cross-repo review: running in lightweight mode (no build/test)."
 
 Based on the parsed `target.type`:
 
@@ -145,14 +157,14 @@ Based on the parsed `target.type`:
 
     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): read `.qwen/review-cache/pr-<n>.json` **before** `fetch-pr` (it is a local file; nothing about it needs the fetch) and, when it holds a `lastCommitSha`, pass it to the fetch as `--since <lastCommitSha>`. **You never run `git` against an anchor yourself** — no `git diff <sha>..HEAD`, no `cat-file`, no `merge-base --is-ancestor`: the command validates the anchor against the fetched history and computes the scoped diff and chunk plan in one pass, because a hand-run check is one a run can skip, and the hand-computed delta was exactly the shape this skill forbids everywhere else (the diff is a file the CLI writes, never a command you run). The report's `incremental` field is the decision; act on it with `lastModelId` from the cache and the current model ID (`{{model}}`):
-    - `effective: true` (no `upToDate`) → the report's diff and plan ARE the incremental scope (`since..head`); continue with them exactly as with a full plan. **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.
-    - `upToDate: true` **and** model matches **and** `comment.effective` is false (no `--comment` flag, and `review.comment` not enabled in settings) → inform the user "No new changes since last review" (this branch consumes no plan, so it holds even when `diffPath` is null), run `"${QWEN_CODE_CLI:-qwen}" review cleanup pr-<n>` to remove the worktree just created, and stop.
-    - `upToDate: true` **and** model matches **but** `comment.effective` is true (the `--comment` flag or the `review.comment` setting) → run the full review anyway — the report already holds the full-range diff and plan for exactly this flow, unless `diffPath` is null, which is the ordinary degraded state (partial coverage, disclosed) rather than a scoping fact. Inform the user: "No new code changes. Running review to post inline comments."
-    - `upToDate: true` **but** model differs → continue on the full-range plan (or, when `diffPath` is null, on the degraded state its siblings name — the caveat is the same). Inform: "Previous review used {cached_model}. Running full review with {{model}} for a second opinion."
+  - **Incremental review check** (high effort only — neither low nor medium consults or updates the cache): read `.qwen/review-cache/pr-<n>.json` **before** `fetch-pr` (it is a local file; nothing about it needs the fetch) and, when it holds a `lastCommitSha`, pass BOTH fields to the fetch verbatim: `--since <lastCommitSha> --since-model <lastModelId>` (omit `--since-model` when the cache has no `lastModelId`; do not substitute anything for it). **Copy them; do not compare them to anything.** The same-model gate is ruled inside `fetch-pr`, over the identity the runtime published — "clean up to `lastCommitSha`" is the recorded identity's verdict, and the command validates an anchor against the HISTORY, never against who certified it, so an anchor from another identity is ancestrally perfect and would scope this round past code it never reviewed. A hand-applied version of that gate was wrong every time it was written, because `{{model}}` interpolates the BARE model id while every identity the CLI records is provider-qualified: two provider configurations exposing one model name compared equal and passed each other's gate. When the gate refuses, the report says `cross-model-anchor` and the round reviews the full diff. Read the cache's `findings` ledger either way (Step 6 owes each entry a ruling; the work list carries across models, only the anchor does not). **You never run `git` against an anchor yourself** — no `git diff <sha>..HEAD`, no `cat-file`, no `merge-base --is-ancestor`: the command validates the anchor against the fetched history and computes the scoped diff and chunk plan in one pass, because a hand-run check is one a run can skip, and the hand-computed delta was exactly the shape this skill forbids everywhere else (the diff is a file the CLI writes, never a command you run). The report's `incremental` field is the decision; act on it with `lastModelId` from the cache and the current model ID (`{{model}}`):
+    - `effective: true` (no `upToDate`) → the report's diff and plan ARE the incremental scope (`since..head`); continue with them exactly as with a full plan. **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. (Reachable only under a matching identity: the gate inside the command is what keeps a cross-model anchor from scoping anything.)
+    - `upToDate: true` **and** `comment.effective` is false (no `--comment` flag, and `review.comment` not enabled in settings) → inform the user "No new changes since last review" (this branch consumes no plan, so it holds even when `diffPath` is null), run `"${QWEN_CODE_CLI:-qwen}" review cleanup pr-<n>` to remove the worktree just created, and stop.
+    - `upToDate: true` **but** `comment.effective` is true (the `--comment` flag or the `review.comment` setting) → run the full review anyway — the report already holds the full-range diff and plan for exactly this flow, unless `diffPath` is null, which is the ordinary degraded state (partial coverage, disclosed) rather than a scoping fact. Inform the user: "No new code changes. Running review to post inline comments."
+    - `reason: cross-model-anchor` → the cached anchor was certified by another identity, so it was not used. Continue on the full-range plan (or, when `diffPath` is null, on the degraded state its siblings name). The command already said which identity certified it and which is running; repeat that to the user rather than restating it from the cache.
     - `effective: false` → the anchor was refused and the report says why. **Every reason names a CAUSE** — `not-an-ancestor` (a rebase or force-push); `unknown-commit`; `behind-merge-base` (the base moved past the anchor, e.g. a partial merge landed, and scoping to it would review base history the PR does not contain); `hunks-outside-pr-diff` (the delta carries hunks the PR's own diff does not contain, which an ordinary "undo per feedback" revert produces from a perfectly valid anchor); `containment-unverified` (that check could not be RULED — a path shape its parser cannot name — which is an unavailable oracle rather than a disproved delta); `base-untrusted` (the base could not be fetched, so the clamp that prevents those could not be ruled); `capture-failed` (a capture threw); `partition-failed` (the diff would not tile). **Whether a PLAN exists is a separate field: `diffPath`.** Non-null → the diff and plan are the full range; continue as a full review. Null → no diff exists at all: that is the `diffPath: null` degraded state (partial coverage, disclosed), whatever the reason says. Do not read one field for both facts — a reason that meant "planless" as well as "why" is what put deterministic refusals into the retry class below. The previous round's ledger is still owed its rulings in every refusal.
 
-  - **When the cache has no anchor, the PR itself carries one** (high effort only, same as the cache). The file being absent is the NORMAL state everywhere except the machine that ran the last review — CI, another clone, a colleague's checkout — and it used to mean the incremental range silently degraded to the full diff every time, which is precisely the cost incremental review exists to avoid. The anchor now rides the posted review: the machine ledger's marker carries `sha`, the head the last clean round reviewed, and `pr-context` writes it into the side file `qwen-review-pr-<n>-prev-ledger.json` with the rest of the ledger. So when the cache had no anchor to pass, **or the anchor it passed was refused** (`incremental.effective: false` — a rebase or force-push retires a cached anchor exactly when another environment may have posted a newer round whose marker still holds a valid one): proceed with the setup batch as usual, and when the side file lands with a `sha` — **different from the one already refused, OR the same sha when the refusal was infrastructure** (`base-untrusted`, `capture-failed`: the anchor was never ruled invalid, and the component that failed — a base fetch, a capture — is re-run by the re-run. Every other reason is deterministic for the same sha and must NOT be retried: a validity refusal re-refuses, `partition-failed` re-fails the partitioner on identical bytes — with ONE exception, and `mergeBaseSha` is the field that names it. A `partition-failed` round that came back PLANLESS (`diffPath: null`) **with a null `mergeBaseSha` AND `baseFetchFailed: true`** never ran the full-range rescue at all: there was no base to rescue from, and the component that failed — the base fetch — is one the re-run repeats, so the same bytes can tile as a full review. Retry that one, once. A null `mergeBaseSha` with `baseFetchFailed: false` is the other cause and is NOT retryable: the fetch succeeded and `git merge-base` found no common ancestor at all (a cross-fork PR with unrelated history), which a re-run reproduces exactly. A planless `partition-failed` that DID carry a `mergeBaseSha` means both ranges were in hand and both refused to tile, which the re-run reproduces exactly — do not retry it. The partitioner is deterministic either way; what varies is whether the round ever had a full range to offer it. The containment reasons re-rule identically) —, **re-run the `fetch-pr` command from above with `--since <sha>` — REPLACING any `--since` it already carries, never appending a second one** (a repeated flag is one flag with two values; the CLI takes the last, but a command that reads as two anchors is a command nobody can check) — the PR ref is already fetched so the re-run is cheap, and it rebuilds the worktree, diff and chunk plan scoped to the delta, with the validation the old flow asked you to hand-run (`cat-file`, `merge-base --is-ancestor`) inside the command where it cannot be skipped. Then act on the new report's `incremental` field exactly as the cache path above does (the model comparison uses the ledger's round only for precedence — there is no `lastModelId` in the marker, so an `upToDate` anchor from the side file stops only when `comment.effective` is false). The decision lands AFTER the setup batch but BEFORE any agent launches, which is where the money is (a same-SHA stop still runs `cleanup`; it just fires three cheap commands later than the cache's fast path would have). An anchor that fails validation falls back to the full diff with the reason in the report, exactly as a rebased cache sha does. Two edges, both decided for you: if the side file's `round` is **higher** than the cache's, prefer the side file's sha — the cache is stale by a round some other environment posted; and a side file with no `sha` field means the last posted round was fail-closed (`compose-review` withholds the anchor then — Step 8 names the conditions), had its ledger truncated by the marker's size caps (a partial work list must not certify a range — the dropped entries would fall outside the next round's scope and retire silently), or predates the field — in every case there is no anchor to recover, and the review is full-range. (The side file may also carry `commitId` — the previous review's own `commit_id`. That is Step 6's **age reference** for the convergence posture, present even on fail-closed rounds; it is never an anchor, and scoping the diff to it would skip exactly the range a fail-closed round could not certify.)
+  - **When the cache has no anchor, the PR itself carries one** (high effort only, same as the cache). The file being absent is the NORMAL state everywhere except the machine that ran the last review — CI, another clone, a colleague's checkout — and it used to mean the incremental range silently degraded to the full diff every time, which is precisely the cost incremental review exists to avoid. The anchor now rides the posted review: the machine ledger's marker carries `sha`, the head the last clean round reviewed, and `pr-context` writes it into the side file `qwen-review-pr-<n>-prev-ledger.json` with the rest of the ledger. So when the cache had no anchor to pass — including the case where it HELD one that the cache-path gate withheld, because `lastModelId` was another model's: the marker may carry an anchor THIS model certified, and a round that stops at the cache would never look — **or the anchor it passed was refused** (`incremental.effective: false` — a rebase or force-push retires a cached anchor exactly when another environment may have posted a newer round whose marker still holds a valid one): proceed with the setup batch as usual, and when the side file lands with a `sha` — **different from the one already refused, OR the same sha when the refusal was infrastructure** (`base-untrusted`, `capture-failed`: the anchor was never ruled invalid, and the component that failed — a base fetch, a capture — is re-run by the re-run. Every other reason is deterministic for the same sha and must NOT be retried: a validity refusal re-refuses, `partition-failed` re-fails the partitioner on identical bytes — with ONE exception, and `mergeBaseSha` is the field that names it. A `partition-failed` round that came back PLANLESS (`diffPath: null`) **with a null `mergeBaseSha` AND `baseFetchFailed: true`** never ran the full-range rescue at all: there was no base to rescue from, and the component that failed — the base fetch — is one the re-run repeats, so the same bytes can tile as a full review. Retry that one, once. A null `mergeBaseSha` with `baseFetchFailed: false` is the other cause and is NOT retryable: the fetch succeeded and `git merge-base` found no common ancestor at all (a cross-fork PR with unrelated history), which a re-run reproduces exactly. A planless `partition-failed` that DID carry a `mergeBaseSha` means both ranges were in hand and both refused to tile, which the re-run reproduces exactly — do not retry it. The partitioner is deterministic either way; what varies is whether the round ever had a full range to offer it. The containment reasons re-rule identically) —, **re-run the `fetch-pr` command from above with `--since <sha>` — REPLACING any `--since` it already carries, never appending a second one** (a repeated flag is one flag with two values; the CLI takes the last, but a command that reads as two anchors is a command nobody can check) — the PR ref is already fetched so the re-run is cheap, and it rebuilds the worktree, diff and chunk plan scoped to the delta, with the validation the old flow asked you to hand-run (`cat-file`, `merge-base --is-ancestor`) inside the command where it cannot be skipped. Then act on the new report's `incremental` field exactly as the cache path above does (**the same-model gate on this path is RULED FOR YOU, not left to you to apply**: the marker carries `model` beside its `sha` — the identity that certified the range — and `pr-context`'s ledger section states the verdict outright, either "the same-model contract HOLDS" or "**Do NOT pass the reviewed-at sha as `--since`**". Obey that sentence and do not compare the two identities yourself: the marker's `model` is a PROVIDER-QUALIFIED identity (`<model>@<digest>`) while `{{model}}` above is the bare model id, so they are not the same kind of string — comparing them by hand either never matches, which throws away this whole recovery path, or matches loosely, which accepts another provider's same-named model and scopes past code it never reviewed. A ledger section that states no verdict — because the side file survived from an earlier round the recovery could not re-vouch — is a mismatch: review the full range. The ledger's round is used only for precedence, and an `upToDate` anchor from the side file stops only when `comment.effective` is false). The decision lands AFTER the setup batch but BEFORE any agent launches, which is where the money is (a same-SHA stop still runs `cleanup`; it just fires three cheap commands later than the cache's fast path would have). An anchor that fails validation falls back to the full diff with the reason in the report, exactly as a rebased cache sha does. Two edges, both decided for you: if the side file's `round` is **higher** than the cache's, prefer the side file's sha — the cache is stale by a round some other environment posted; and a side file with no `sha` field means the last posted round was fail-closed (`compose-review` withholds the anchor then — Step 8 names the conditions), had its ledger truncated by the marker's size caps (a partial work list must not certify a range — the dropped entries would fall outside the next round's scope and retire silently), or predates the field — in every case there is no anchor to recover, and the review is full-range. (The side file may also carry `commitId` — the previous review's own `commit_id`. That is Step 6's **age reference** for the convergence posture, present even on fail-closed rounds; it is never an anchor, and scoping the diff to it would skip exactly the range a fail-closed round could not certify.)
 
   - **The setup calls that do not feed each other go out in ONE response — as separate tool calls, never joined with `&&`/`;` into one Shell command** (high and medium effort — at low, Step 2's rules load is skipped and nothing consumes the comment index, so the batch is whatever calls remain). A joined chain changes the failure semantics — a `pr-context` failure must warn-and-continue, not skip the other two — and merges the `warning:` size lines the paging decisions below read. Once `fetch-pr` has returned (and the incremental check, which reads its report, is decided — except on the side-file anchor path, where the decision deliberately waits for `pr-context`'s side file), the next three commands are mutually independent — `pr-context` (below), `comment-status` (below), and Step 2's rules load — every one a read with no side effect the others observe. Issue all three tool calls in a single response, exactly as Step 3 already requires for the agent fan-out, then read their outputs (paging where a file exceeds one read, and those reads can share a response too). The rules load takes `<remote>/<baseRefName>` — the ref `fetch-pr` just updated; no local-existence probe — **except when the fetch report recorded `baseFetchFailed: true`: drop it from the batch and `git fetch <remote> <baseRefName>` first** (on an unresolvable ref `load-rules` reports "no rules found", indistinguishable from a repo that has none, and the review silently enforces nothing). Measured on a real small-PR run: the stretch from `parse-args` to the first agent launch took **7 minutes of wall clock**, one round-trip at a time, on calls that never needed an order. The only orderings that matter: `fetch-pr` before all of them (it creates the worktree and the plan), **any side-file `fetch-pr --since` re-run before `repo-context`** (the re-run rewrites the fetch report from scratch, and `repo-context` enriches that same file in place — an enrichment written first is silently discarded, and the roster then builds without the manifest's required agents), `repo-context` before `agent-prompt --roster` (the roster and every brief bake the manifest's required agents and context blocks, so building them first silently drops the context), and `agent-prompt --roster` after the rules load (the roster bakes the rules into every brief).
 
@@ -174,8 +186,9 @@ Based on the parsed `target.type`:
     ```bash
     "${QWEN_CODE_CLI:-qwen}" review comment-status <pr_number> <owner>/<repo> \
       --out .qwen/tmp/qwen-review-pr-<pr_number>-comment-status.json
-    # GitHub Enterprise: add --host <host>, same as fetch-pr/pr-context/presubmit —
-    # each subcommand is its own process, so a host set elsewhere does not carry over.
+    # add --host <host> (every PR target, including github.com — see Step 1's
+    # host rule); each subcommand is its own process, so a host set elsewhere
+    # does not carry over.
     ```
 
     One call answers, per existing thread, every status question the re-check and the finder agents otherwise re-derive one API fetch at a time: is the anchor **outdated** at the live head (`line: null`), did the anchored **file change in the worktree since the comment's commit** and which commits touched it (`code.touchedBy` — the candidate "fixed by" commits), who replied and **did the PR author answer**, and whether the body **asserts a blocker** (same `carriesBlockerSignal` the context file's promotion uses). It also compares the worktree HEAD against the live PR head and warns on drift. **The report can exceed one `read_file`** — `threads` is path-sorted, so a truncated read drops the alphabetically-later files wholesale while the cut JSON does not even parse (measured; DESIGN.md — The 71-thread comment-status report). The command prints a `warning:` line naming the size when this happens; when it does, query the file with `jq` (it is machine-shaped) or page with `offset`/`limit` until `isTruncated` is false — same rule as the context file above. **Do not fetch per-comment status metadata yourself** — no raw API calls to read `line`/`outdated`/`commit_id`, and no hand-run `git log` per comment (measured; DESIGN.md — The 20-turn status re-derivation). Comment **bodies** are a different matter and stay where they were: the context file renders them (in full for blockers and review summaries), and only a body the renderer truncated is fetched, by running the exact `review comment-body` command its `_(truncated — run …)_` note names. If `comment-status` itself fails (auth, network), warn and continue — it is an index, not the evidence: statuses become "re-derive if needed", and nothing here sets the context-unavailable state.
@@ -252,9 +265,9 @@ For **cross-repo lightweight reviews**, do the same with the diff the platform h
   --pr <pr_number> --repo <owner>/<repo> \
   --effort <effort> \
   --out .qwen/tmp/qwen-review-pr-<n>-plan.json
-# GitHub Enterprise: add --host <host> — plan-diff records it and Agent 0's
-# welded issue-context command routes at it; a lightweight run has no
-# fetch-pr to carry the host otherwise.
+# add --host <host> (every PR target, including github.com) — plan-diff
+# records it and Agent 0's welded issue-context command routes at it; a
+# lightweight run has no fetch-pr to carry the host otherwise.
 ```
 
 **Pass `--pr`/`--repo` only when the `pr-context` fetch above succeeded** — they put the PR identity into the plan, which makes the roster REQUIRE Agent 0 (`check-coverage` will name it if it never runs, exactly as in worktree mode). If `pr-context` failed, omit them: the run is in the context-unavailable state, Agent 0 has nothing to work from, and a roster demanding an agent nobody can brief would wedge the review.
@@ -635,7 +648,7 @@ After deduplication, run reverse audit **iteratively** — the first launch ride
 
 - **Small diffs (Step 3A path):** one reverse audit agent per round, reading the whole diff — except rounds 1 and 2, which are **the convergence pair** and launch together (below).
 - **Large diffs (Step 3B path):** one reverse audit agent **per chunk** per round, launched together in a single response — and rounds 1 and 2 are **the convergence pair** here too, their per-chunk auditors launched together (below). A single agent asked to re-read a 5 800-line diff with a growing finding list appended is the most context-starved agent in the pipeline — precisely on the PRs where the reverse audit matters most. Each per-chunk auditor gets the same territory as its Step 3B counterpart, plus the cumulative finding list for the **whole** diff (so it knows what is already covered elsewhere).
-- **The builder schedules the 3B fan-out; you do not.** Rounds 1 and 2 audit every chunk — they are what establishes each territory's record. From round 3 on, `--all-chunks` reads the harness transcripts and **retires** any chunk whose own last two audits were substantively dry (the receipt named what it examined AND the transcript shows the diff was opened): a retired chunk is cold-checked on alternating rounds instead of every round, and a cold check that yields anything returns it to every-round auditing. The savings land on the odd rounds — every retired chunk cold-checks together on the even ones, so an even round's fan-out is unchanged; expect the odd rounds to shrink, not the even ones (under the 3-round huge-diff cap only round 3 can shrink — the cap ends the loop before round 5). The blocks it prints are the round; the `retirement:` note after the `end of round` line names each skipped chunk and its certificate — relay that note in your narration, and do not hand-build an auditor for a chunk the builder skipped. Why, measured: on a real 6-chunk run, two chunks were dry in **all five rounds** — a third of the loop's auditors re-certifying territories that had already converged, while the three hot chunks were where every finding came from. Attention follows evidence; the certificate a retired chunk holds (two consecutive substantive dry audits) is exactly the one the whole loop used to end on.
+- **The builder schedules the 3B fan-out; you do not.** Rounds 1 and 2 audit every chunk — they are what establishes each territory's record. From round 3 on, `--all-chunks` reads the harness transcripts and **retires** any chunk whose own last two audits were substantively dry (the receipt named what it examined AND the transcript shows the diff was opened): a retired chunk is cold-checked on alternating rounds instead of every round, and a cold check that yields anything returns it to every-round auditing. The savings land on the odd rounds — every retired chunk cold-checks together on the even ones, so an even round's fan-out is unchanged; expect the odd rounds to shrink, not the even ones (under the 3-round huge-diff cap — the reduction a run earns only when it has a deadline — only round 3 can shrink, because the cap ends the loop before round 5). The blocks it prints are the round; the `retirement:` note after the `end of round` line names each skipped chunk and its certificate — relay that note in your narration, and do not hand-build an auditor for a chunk the builder skipped. Why, measured: on a real 6-chunk run, two chunks were dry in **all five rounds** — a third of the loop's auditors re-certifying territories that had already converged, while the three hot chunks were where every finding came from. Attention follows evidence; the certificate a retired chunk holds (two consecutive substantive dry audits) is exactly the one the whole loop used to end on.
 
 One anomaly the builder flags but does not refuse (#9242): a per-chunk build on a plan whose own `srcDiffLines`/`diffLines` say Step 3A prints a stderr note — the plan's numbers price one whole-diff auditor per round (the reverse-audit round cap reads them), yet per-chunk auditors were built. It fires on `--all-chunks` and on a `--chunk` build of a round that has no admission stamp yet; a stamped round's `--chunk` rebuilds are exempt — their fan-out was ruled on at admission. If the note fires and the fan-out is deliberate — you decided against the plan's numbers (the routing is yours, as Step 1 says), or this is a whole-round `--all-chunks` rebuild of an already-admitted round on a hand-maintained plan — say so in the round; if it was not deliberate, stop and re-derive the topology from Step 1 instead of spending a fan-out the plan never owed.
 
@@ -690,7 +703,7 @@ The brief holds what the auditor is for: hunt only the **gaps** no prior agent c
 - **On the 3B path the builder is also the convergence ledger**: when every chunk holds two consecutive substantive dry audits and none is due a cold check, `--all-chunks` builds nothing, prints a `CONVERGED` explanation to stderr and exits **5**. Stop the loop and proceed to Step 6 — this is a **clean** convergence, not a gap: no `unreviewedDimensions` entry is owed, because each chunk holds the two-dry rule's evidence chunk by chunk — two consecutive dry **audits**, though not necessarily in consecutive rounds (a chunk dry in rounds 1 and 2 skips round 3 and cold-checks dry in round 4, holding rounds 2 and 4). If an earlier round-cap or budget refusal told you to add its stop entry to `unreviewedDimensions`, remove it now — this convergence supersedes that stop (the marker on disk is cleared the same way). Exit 5 is mainly the CLI enforcing the stop the two-dry-rounds rule above used to leave to orchestrator discretion; the new savings are the odd-round skips and a convergence at the cap round (round 5 on a 3B diff, round 3 under the huge-diff cap when the run has a deadline and round 5 when it does not — this ledger is 3B's, so the 3A tier's ten never applies here). (It cannot owe a verification launch: a reporting round makes its chunk hot, so every verifier launched with a later round that did run.)
 - Stop at the plan's **`reverseAuditRounds` cap** — 10 on a 3A diff, 5 on a 3B one, and 3 for a huge diff (effective ≥ 3000 lines) **when the run has a deadline**, 5 when it does not (the huge reduction answers a six-hour ceiling, so it applies only where there is one) — and say so in the output rather than implying convergence. The cap is per topology because it prices a round, and a 3A round is one auditor where a huge-diff round is ~90 minutes; you never work this out yourself, the builder reads the plan's tier. The builder enforces this itself: a round past the cap gets a `ROUND CAP:` refusal on stderr and exit **4**, and — like the time-budget gate — writes a marker `compose-review` caps the verdict on whether or not you relay anything; still add the entry the message names to `unreviewedDimensions` so the terminal report agrees. If the cap round reported findings, its verifiers have NOT launched — that launch rides the next round's build, which the cap forbids — so verify them before Step 6 through `agent-prompt --role verify` **only** (never a hand-rolled agent), under the same bounded tail as the budget stop below: that builder is gated on the compose floor and refuses once too little time remains, and when the deadline is within the floor you stop waiting on any verifier batch still out and compose with the tags in hand — no fresh re-verification pass, and nothing already confirmed re-verified. This matters most on exactly the huge diffs the cap targets: a time-budgeted CI run that stops at the cap with ~30-90 minutes left must not spend it on an unbounded tail and die before compose. The tag backstop below (and `compose-review`'s machine-read of it) is what catches a miss.
 - Findings **reported** by each round are merged into the cumulative list **before** the next round begins, so each round sees an updated baseline. **The merge runs unconditionally — before every round build and before Step 6, whether or not the previous round reported findings**: under the pipelined loop below, round _k_'s verdicts land during round _k+1_, and every termination mode (two dry rounds, CONVERGED, budget stop, the round cap) can arrive with the final rounds dry — a merge keyed to "some round reported something" would never apply the last verdicts that landed. Each merge applies every Step 4 verdict that has landed: confirmed removes the tag, rejected removes the entry. Verification status does not gate the merge — the list exists so auditors do not re-report what is already filed, and an unverified entry serves that purpose exactly as well as a confirmed one. The trade, named: an entry a verifier later rejects will have suppressed one round of rediscovery in its neighbourhood — the window is one round in one location, and the plan's round cap still bounds the loop. The tag is what keeps this mechanical rather than remembered: an entry enters the list tagged `— [unverified]`; the merge after its Step 4 verdict removes the tag (confirmed) or the entry (rejected). Step 6's confirmed-only read then has something to key on — anything still tagged is left out of the confirmed set — instead of a memory of which round each entry arrived in. The tag rides inside the findings file, which is hashed into the record key and copied to the digest-named list file each block points at — so a launch that drops the pointer matches no record, and the delivery floor counts the agent's read of that file exactly as it counts the brief's.
-- **A reporting round whose every finding the verifier rejected is retroactively dry.** The merge already removes a rejected entry from the cumulative list; from the merge that applies the last of a round's rejections, the round also stops counting as a reporting round, and the two-consecutive-dry rule reads rounds' **effective** status. Rejected means rejected — an entry confirmed at low confidence keeps its round a reporting round. Under the pipelined loop a round's verdicts land while the next round runs, so the upgrade usually arrives one round late, and that is still one round saved: a measured run held round 2 dry, watched round 3's sole finding be rejected, and then ran rounds 4 **and 5** — round 4's dry return plus the rejection already in hand was the two-dry evidence, and the fifth round audited nothing the loop had not already answered (measured; DESIGN.md — The rounds a rejected finding bought (PR #8353)). The rule leans on the rejection bar the verifier's brief already enforces — a rejection claims direct counter-evidence, never mere unverifiability — so a round retired by rejections is retired on evidence, not on doubt. **It pairs forward only, and is consulted when a round returns**: on round _k_'s dry return, first apply every verdict that has landed (the unconditional merge — the retirement takes effect at this application, not at some earlier moment), then end the loop if round _k−1_ was dry or is now retired. Round _k−1_ counts **launches, not labels**: the convergence pair is one round here — a pair member is never round _k−1_ on its own (the pair bullet's not-carried-forward rule stands), and a reporting pair retires only when every finding from **both** members is rejected. The upgrade never ends the loop by itself — a preceding dry round plus a freshly-retired round stops nothing while the next round is already in flight: that round was launched, and its return is taken whatever it says, because a launched auditor can be carrying a real Critical. This is the measured shape (round 4's return is where the loop closes under this rule — the measured run, which predates it, ran a fifth round; a cap-5 shape — under the 3-round huge-diff tier the upgrade can only ever retire rounds 1–2, since the cap round's verdicts land during its solo verification, after the loop has already ended) and the only pairing licensed here. It softens nothing else: a whiffed scope stays not-audited whatever the verdicts say, and on 3B the retirement ledger's per-chunk certificates are untouched — this rule reads at the level the round counter reads.
+- **A reporting round whose every finding the verifier rejected is retroactively dry.** The merge already removes a rejected entry from the cumulative list; from the merge that applies the last of a round's rejections, the round also stops counting as a reporting round, and the two-consecutive-dry rule reads rounds' **effective** status. Rejected means rejected — an entry confirmed at low confidence keeps its round a reporting round. Under the pipelined loop a round's verdicts land while the next round runs, so the upgrade usually arrives one round late, and that is still one round saved: a measured run held round 2 dry, watched round 3's sole finding be rejected, and then ran rounds 4 **and 5** — round 4's dry return plus the rejection already in hand was the two-dry evidence, and the fifth round audited nothing the loop had not already answered (measured; DESIGN.md — The rounds a rejected finding bought (PR #8353)). The rule leans on the rejection bar the verifier's brief already enforces — a rejection claims direct counter-evidence, never mere unverifiability — so a round retired by rejections is retired on evidence, not on doubt. **It pairs forward only, and is consulted when a round returns**: on round _k_'s dry return, first apply every verdict that has landed (the unconditional merge — the retirement takes effect at this application, not at some earlier moment), then end the loop if round _k−1_ was dry or is now retired. Round _k−1_ counts **launches, not labels**: the convergence pair is one round here — a pair member is never round _k−1_ on its own (the pair bullet's not-carried-forward rule stands), and a reporting pair retires only when every finding from **both** members is rejected. The upgrade never ends the loop by itself — a preceding dry round plus a freshly-retired round stops nothing while the next round is already in flight: that round was launched, and its return is taken whatever it says, because a launched auditor can be carrying a real Critical. This is the measured shape (round 4's return is where the loop closes under this rule — the measured run, which predates it, ran a fifth round; a cap-5 shape — under the 3-round huge-diff tier, which a run only gets when it has a deadline, the upgrade can only ever retire rounds 1–2, since the cap round's verdicts land during its solo verification, after the loop has already ended) and the only pairing licensed here. It softens nothing else: a whiffed scope stays not-audited whatever the verdicts say, and on 3B the retirement ledger's per-chunk certificates are untouched — this rule reads at the level the round counter reads.
 - **Verification rides alongside the next round, not ahead of it.** When round _k_ returns with new findings, one response launches BOTH round _k_'s verifiers (Step 4, `--role verify --round k` with that round's new findings) AND round _k+1_'s auditors — build the two prompt sets first, then fire every agent together, exactly as Step 3 fans out. (Step 4's initial verification is the k=0 case of the same rule: its shards ride with the first reverse-audit launch — the convergence pair, whole-diff on 3A and per-chunk rounds 1 and 2 on 3B. The convergence pair is the one exception on the LAUNCH side: a pair member's return never triggers this rule per member — round 2's auditors are already in flight — and the pair bullets above define the one transition; the pair's findings still verify as the k=2 case, riding round 3.) The serial shape (audit → wait for verification → next round) spent 5-8 minutes per round waiting for verifiers whose results the next round's auditors never needed. Two orderings still hold: the **last** round's verification must complete before Step 6 (that ordering is what keeps unverified entries out of the report and the PR, backed by the tag backstop at the end of this step — which `compose-review` machine-checks from `findingsPath`, Step 6), and a rejected finding leaves the cumulative list at the next merge.
 - **The round builder is also the loop's clock.** In a time-budgeted run (CI exports `QWEN_REVIEW_DEADLINE_EPOCH`; a local run normally has no deadline and is untouched), `agent-prompt --role reverse-audit` refuses to build a round that no longer fits: the remaining time must cover **the round itself** (estimated from the costliest round's measured cost so far — a repair relaunch can make one round the expensive one, and the gate prices the worst case the run has proved, not the newest dip — or a conservative constant for round 1) **plus** the reserve kept for its verification, compose-review and submission. On refusal it prints a `BUDGET:` line to stderr and exits **4**. That refusal is a termination rule, not an error — do not rebuild the round, do not relaunch auditors, and do not retry the command. The builder also records a budget-stop marker that `compose-review` reads directly, so the verdict is capped whether or not you relay anything; still add the exact entry the message names (`reverse audit — stopped before round <k> by the review time budget`) to `unreviewedDimensions` so the terminal report and the body agree, and proceed to Step 6. **The tail after a budget stop is bounded, and its order is load-bearing.** Verify the last round's findings — the ones whose verifiers would have ridden the round the gate just refused — **only through `agent-prompt --role verify`, never a hand-rolled `agent`**: that builder is gated on a **compose floor** and prints a `VERIFY BUDGET:` refusal (exit 4) once too little time remains, at which point you stop verifying and compose **immediately** — findings still carrying `— [unverified]` keep the tag, and `compose-review` caps the verdict on it and never treats an unverified finding as a confirmed blocker; everything earlier rounds confirmed still posts. **Bound the wait, not just the launch:** the builder gate stops a verifier from being _built_ below the floor, but a verifier admitted _above_ it can still run a real filesystem/git E2E workload past the floor while you wait on its batch — and `agent-prompt` builds prompts, it cannot cancel a running agent. So when the deadline is within the compose floor and a verifier batch has not returned, **stop waiting on it yourself**: take the findings in hand at their current tag and compose. A verifier you stopped waiting on leaves its findings `— [unverified]`, which caps the verdict exactly as a refused build would. Do **not** re-verify findings already confirmed in earlier rounds, and do **not** invent a fresh re-verification pass — that is the unbounded work a wall runs into. Compose and submit are non-negotiable; they always run. Why this exists, measured twice: a +1699-line PR's CI review ran the audit loop to the 5-round cap and was killed while round 5's findings were still being verified (#8368); and a 4,269-line cross-worktree git guard stopped the audit correctly with ~110 minutes left, then a single hand-rolled agent re-running a 15-family shell/git bypass battery with real filesystem E2E consumed all of it — the wall hit mid-verification, compose never ran, and ~20 E2E-confirmed Critical bypasses were never posted (measured; DESIGN.md — The killed-before-compose tail (PR #8687)). A review that stops on the budget still reports everything it proved; one that runs past it reports nothing.
 
@@ -762,7 +775,7 @@ Render the rulings as a short table at the top of the Findings section — id, o
 
 **A re-review that keeps posting new non-Critical findings is the motor of a feedback loop this pipeline has measured from the outside**: every push triggers a fresh review, the review files findings on code the previous round just added, the next push implements them, and the diff widens — which allocates more agents, which file more findings. One managed PR rode that loop to +13k lines across 8 rounds with its per-round Critical count flat, and was closed unmerged; the growth was 78–86% test lines. Bug-finding never converges a loop — only the **posting bar** can, and it must rise as rounds accumulate, exactly the discipline a senior reviewer applies by hand ("after ~5 rounds, only blockers; defer the rest, on the record"). This posture is that discipline, made the default. It governs **what posts to the PR**, never what is found, verified, or reported in the terminal: `RECALL` still binds every finder, Step 4 still verifies, the artifact and the terminal report still carry everything.
 
-**Resolve the floor first.** The Step 1 verdict's `severityFloor` is `critical`, `suggestion`, or `auto`. Explicit values are the operator's call: `critical` applies the Critical-only posture from round 1; `suggestion` turns the posture **off** — every round posts Suggestions, and the code-age rule below does not run. `auto` — the default — resolves here, where the round is known: **this review is round `prev ledger round + 1`**, and the round that decides the posture is the SIDE FILE's — the same read `compose-review` stamps into the marker and the deferral clause; the local cache's round scopes the diff but never decides the posture, or the body and the marker would disagree about which round ran (no recovered ledger → round 1 → no posture). Through round 5 the floor is `suggestion`; **from round 6 it is `critical`**. In the **context-unavailable** state the round is unknowable — the ledger this rule counts from could not be recovered by a run that could not read the PR — so treat `auto` as round 1: no posture, full posting, and say so in the terminal report (the deterministic marker still stamps its own count from the side file; a posting bar in doubt fails open, bookkeeping does not). Carry the **verdict's `severityFloor` into the compose state UNRESOLVED** — explicit values as they are, and `auto` as the literal string `auto`, never as the level it resolved to this round: the module licenses `auto` by the round it derives itself, and a round-resolved `suggestion` is indistinguishable from the operator's explicit posture-off override — passing it would turn every legal rounds-2–5 age-rule deferral into an unlicensed one. The resolution in this paragraph decides what YOU post; the state field carries the policy.
+**Resolve the floor first.** The Step 1 verdict's `severityFloor` is `critical`, `suggestion`, or `auto`. Explicit values are the operator's call: `critical` applies the Critical-only posture from round 1; `suggestion` turns the posture **off** — every round posts Suggestions, and the code-age rule below does not run. `auto` — the default — resolves here, where the round is known: **this review is round `prev ledger round + 1`**, and the round that decides the posture is the SIDE FILE's — the same read `compose-review` stamps into the marker and the deferral clause; the local cache's round scopes the diff but never decides the posture, or the body and the marker would disagree about which round ran (no recovered ledger → round 1 → no posture). Through round 5 the floor is `suggestion`; **from round 6 it is `critical`**. In the **context-unavailable** state the round is unknowable — the ledger this rule counts from could not be recovered by a run that could not read the PR — so treat `auto` as round 1: no posture, full posting, and say so in the terminal report (the deterministic marker still stamps its own count from the side file; a posting bar in doubt fails open, bookkeeping does not). Carry the **verdict's `severityFloor` into the compose state UNRESOLVED** — explicit values as they are, and `auto` as the literal string `auto`, never as the level it resolved to this round: the module licenses `auto` by the round it derives itself, and a round-resolved `suggestion` is indistinguishable from the operator's explicit posture-off override — passing it would turn every legal rounds-2–5 age-rule deferral into an unlicensed one. The resolution in this paragraph decides what YOU post; the state field carries the policy. **The module also enforces the floor itself**: a Suggestion still drafted inline past a resolved `critical` floor is moved into the deferral list mechanically by `compose-review`/`submit` (the composed result's `floorEnforced` names the moved indices, the posted body discloses the move, and `submit` drops those comments from the write). Your Step 6 routing stays the primary path — the enforcement is the backstop that keeps the posted set lawful when the routing drifts, so a submit report showing fewer inline comments than you drafted under a critical floor is the floor working, not a lost finding. Three consequences of it being mechanical: the backstop classifies by the drafted severity MARKER alone — it cannot re-derive confidence or a Nice-to-have, so keeping low-confidence and Nice-to-have findings OUT of the drafted comments (as this step already mandates) is what keeps them out of the published deferral list too; **leave moved comments IN the comments file and the submit payload** — the CLI removes them from the write itself, and hand-removing them "to match" makes both boundaries recompute over the reduced set and erases the deferral record the move exists to keep; and the floor it enforces is the RESOLVED one (an explicit `critical`, or `auto` from round 6), recovered where possible from the CLI's own record of the invocation rather than the state field alone.
 
 **At floor `critical`, a non-Critical finding that would otherwise post is recorded, not requested.** The deferrable set is exactly the set the floor takes away: **high-confidence Suggestions** — the findings a `suggestion`-floor round would have drafted inline. Low-confidence findings and Nice-to-haves were never posted at any floor and **stay terminal-only exactly as before**: routing them through the deferral list would _publish_ to the PR what the review contract keeps out of it, and inflate the list the posture exists to keep small. A deferred finding has been through Step 4 like any posted one — the deferral list publishes its one-line claims in the body, so `compose-review`'s verifier-delivery floor counts deferred findings exactly as posted ones; an unverified claim does not become publishable by being deferred. (Deterministic findings are the exception on both sides at once: a `[build]`/`[test]`/`[probe]` finding is pre-confirmed, Step 4 launches no verifier for it, and the floor excludes it — by its `source` field.) Each deferred finding stays in the findings artifact and the terminal report under its own grouping — "Deferred (convergence posture)" — and enters the compose state's `deferredSuggestions` as a **TYPED entry, one object per finding, copied from the artifact's own fields**: `{"file": "src/a.ts", "line": 42, "source": "test", "severity": "Suggestion", "title": "mutation survivor on the retry guard"}` (`line` optional; a pattern aggregate adds `"locations": N` for its further locations). This is a data field, not a sentence: `compose-review` derives deterministic from `source`, relocates a `severity: "Critical"` entry into the body Criticals (a Critical is never deferred), refuses a `"Nice to have"` (terminal-only) or any malformed entry, and RENDERS the human line `file:line — [source] title` itself — never write that line into the state, and never re-type the fields: read them out of the findings artifact you just wrote. It is **not** drafted into the `comments` array, **not** counted toward `S`, and casts no vote on the event: `compose-review` renders the list as a disclosed, non-capping paragraph — up to 20 entries, each capped at 240 characters, with an overflow count pointing at the run report — so the deferral is on the PR record without opening a thread that regenerates a round, and anything past the rendered cap survives in full in the findings artifact and the terminal report (say so there when the cap trims the list). A previous-round **non-Critical** ledger entry that still stands is ruled in the status table as `still stands — deferred (convergence posture)` and is likewise not re-posted; it leaves the machine ledger (`buildLedger` ingests only posted findings), and the deferral list plus the original round's thread remain its record. **A Critical is never deferred — any round, any floor**: new Criticals post, still-standing ledger Criticals re-post under their original ids, and every Critical ruling above runs unchanged. An APPROVE composed over a non-empty deferral list opens "No blocking issues" instead of "No issues found" — `compose-review` owns that wording.
 
@@ -815,7 +828,8 @@ Two failure modes this closes, both observed in this repo's own dogfood: reporti
   --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.
+# add --host <host> (every PR target, including github.com) — 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.
@@ -862,8 +876,12 @@ Each entry carries `id` (unique — outcomes and resolved anchors both join on i
 "${QWEN_CODE_CLI:-qwen}" review compose-review --input .qwen/tmp/qwen-review-{target}-compose.json \
   --comments .qwen/tmp/qwen-review-{target}-comments.json \
   --out .qwen/tmp/qwen-review-{target}-composed.json
-# GitHub Enterprise: add --host <host> — compose-review may fetch the PR
-# description to pick the body language, and that gh call must hit the PR's host.
+# PR reviews: add --pr <n> --repo <owner/repo> — the recorded-floor
+# recovery's first identity, mirroring submit's own --pr/--repo so the
+# archived compose and the post resolve one floor whatever the plan does.
+# add --host <host> (every PR target, including github.com) — compose-review
+# may fetch the PR description to pick the body language, that gh call must
+# hit the PR's host, and the host is the recovery's own identity axis too.
 ```
 
 It prints a `Verdict:` line to stderr. **That line is the verdict — print it, and nothing else.** It writes nothing, posts nothing, and needs no authorisation, so run it on every verified review — **high and medium** — whether or not you are going to post. The state file is the same one Step 7 uses (see there for every field): your findings and the states you established — the body Criticals, the discarded suggestions, the `cannot tell` blockers, the unreviewed dimensions, the `planPath`, the `findingsPath` (high effort — the cumulative reverse-audit findings file, for the `— [unverified]` check), the presubmit flags, the model id. It does **not** take the coverage or the inline counts, and it **refuses** a state JSON carrying `criticalsInline`/`suggestionsInline`. It derives coverage from the harness's transcripts, and it **counts** the inline findings from `--comments`: write the drafted inline comments to that file first — the same `[{path, line, body, …}]` array the Step 7 payload will carry, each body opening with its `**[Critical]**`/`**[Suggestion]**` marker; a review with nothing anchored inline passes a file containing `[]`. A report-only run has read Approve over a blocker its own report listed (measured; DESIGN.md — The Approve over a relocated Critical); counted from the draft, that finding cannot fall out of the computation. **If the comment set changes after composing** — an anchor fails to resolve, a finding relocates to the body, a comment is dropped — update the comments file (and the state), and run `compose-review` again: the verdict must be computed from the set you actually post, and Step 7's `submit` recounts from the payload to hold you to it.
@@ -877,6 +895,8 @@ The rules it applies — so you can read the line it gives you, not so you can a
 - **Request changes** — one or more high-confidence Criticals, anchored or in the body, **whose verification is on record** (a deterministic `[build]`/`[test]` finding is pre-confirmed and needs none).
 - **Comment** — suggestions but no blockers, **or** an Approve that a cap took away: an uncoverable chunk, a chunk nobody read, a dimension nobody reviewed, a **reverse audit that never ran**, an existing blocker you could not rule on, a PR whose discussion you could not read. A review that did not read part of the diff — or never looked for what it missed — cannot certify it. **Or a Request changes whose blockers were never verified**: the findings still post, disclosed as unverified, but an unverified finding must not become a public blocker — a run whose verifier never launched posted a CHANGES_REQUESTED onto an external contributor's PR over a Critical its own body disclosed as unverified, and this row is what stops the next one.
 
+**The body it returns already fits GitHub's limit.** A review body over 65,536 characters is rejected by the API **whole** — every blocker it carries with it — so `compose-review` measures the composed body (holding room for the ledger marker it appends) and, when it would overflow, trims in a fixed order: **the Chinese fold first** — it is a translation of the English above it, so dropping it costs no content at all — then the deferral display, then the not-reviewed disclosures, and **the blockers, the undecided-blocker list and the sentences that qualify the verdict never**. Every trim is disclosed at the top of the body — naming which kinds went, above the sentences that refer to them — and repeated on stderr; if the un-trimmable remainder still overflows, the body is truncated with a loud notice rather than posted as a rejection — and **that notice rides above the cut, with the others**, so nothing the cut left open can swallow it and no part of this has to model how the page renders. That last cut has an order of its own: it spends the sentences the author already received in an earlier round — the undecided-blocker list — before this round's body Criticals, which exist in no other place the author can reach. You do not shorten anything yourself to help it — a finding you drop is a finding lost, while **a finding it trims stays whole in the findings artifact** (each deferral is its own `D<round>-<n>` entry there). **A trimmed disclosure section is not a finding and has no other durable copy** — the artifact persists findings, counts and the trimmed body, so the not-reviewed, deferred-checker, Test-Plan and repository-context text exists nowhere else once the body drops it. The stderr line names which kinds went: **say in your Step 6 terminal summary what was trimmed and what it said.** That summary is the copy.
+
 **Why this is a command and not a paragraph.** It was a paragraph, and the paragraph was skipped. A run once printed an Approve it had composed itself, from prose, on a review whose gate had just refused (measured; DESIGN.md — The paraphrased roster prompt). There is now one place a verdict exists. Skipping the command does not get you a different one; it gets you none.
 
 **And you may not overrule the line it gives you.** The failure came back subtler: a run read the capped verdict, narrated the gap away as a "transcript visibility issue", and reported Approve — wrongly, and by its own doing (measured; DESIGN.md — The narrated-away cap). **A cap you can explain is still a cap.** If you believe a gap is wrong, the answer is to make the step verifiable — relaunch it with the prompt `agent-prompt` printed, verbatim — and run `compose-review` again. It is never to keep the verdict you preferred and narrate the gap away. The verdict you print, and the verdict in the report you save, are the one this command computed; when they differ from it, the review is lying to the person who trusted it.
@@ -978,9 +998,9 @@ Report `stats.drifted` in the terminal: it is the number of findings whose agent
 
 Do **not** submit a review — with a placeholder body, a one-character body, or any body at all — merely to discover whether an anchor sticks. Each such attempt is a permanent, public review on someone's pull request. This has happened, five times in one run (measured; DESIGN.md — The five test reviews). One Create Review call, after the lookup, is the only write this step makes.
 
-First, determine the repository owner/repo. For **same-repo** reviews, run `"${QWEN_CODE_CLI:-qwen}" review meta` (add `--host <host>` for Enterprise) and read its `ownerRepo`. For **cross-repo** reviews, use the owner/repo from the PR URL in Step 1.
+First, determine the repository owner/repo. For **same-repo** reviews, run `"${QWEN_CODE_CLI:-qwen}" review meta` (with `--host <host>` for every PR target — see Step 1's host rule) and read its `ownerRepo`. For **cross-repo** reviews, use the owner/repo from the PR URL in Step 1.
 
-Use the **HEAD commit SHA** captured in Step 1. If not captured, fall back to `"${QWEN_CODE_CLI:-qwen}" review meta {pr_number} --repo {owner}/{repo}` (add `--host <host>` for Enterprise) and read its `headSha`.
+Use the **HEAD commit SHA** captured in Step 1. If not captured, fall back to `"${QWEN_CODE_CLI:-qwen}" review meta {pr_number} --repo {owner}/{repo}` (with `--host <host>` for every PR target — see Step 1's host rule) and read its `headSha`.
 
 **Run pre-submission checks**: the bundled `qwen review presubmit` subcommand performs self-PR detection, CI / build status classification, and existing-Qwen-comment classification in one pass — three deterministic gh-API queries collapsed into a single JSON report. Read the report to drive the rest of Step 7.
 
@@ -1128,12 +1148,12 @@ Then reference each finding's `assets` URLs in its inline comment body as `![evi
     {
       "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 (v{{cliVersion}})_",
+      "body": "**[Critical]** issue description as plain sentences carrying the concrete trigger and the 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 (v{{cliVersion}})_",
+      "body": "**[Suggestion]** recommended improvement as plain sentences carrying the concrete cost (what is duplicated, wasted, or fragile)\n\n```suggestion\nimproved code\n```\n\n_— YOUR_MODEL_ID via Qwen Code /review (v{{cliVersion}})_",
     },
   ],
   "state": {
@@ -1176,7 +1196,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 (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.
+- Comment body format: `**[Critical]** issue description\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. Write the description as plain reviewer prose: state the problem, when it bites, and what to do about it, in ordinary sentences — no `— Failure scenario:` label, no `<trigger> → <wrong outcome>` arrow notation, no section-header voice. The description MUST still 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 scaffolding is gone, the evidence is not. The prefix must be the **first thing in the body** and the footer must be present: the CLI's counting, its unmarked-draft gates, and the attribution-off strip machinery key off them. The autofix coupling is narrower — `.github/workflows/qwen-autofix.yml` recognizes Critical findings by the `**[Critical]**` substring in comment bodies (position-independent) and keeps Suggestion findings out of the autofix loop by its absence; it never reads the footer. Changing the prefix silently makes the autofix bot start applying non-blocking suggestions. (When the operator turned `review.attribution` off, `submit` strips the prefix and the footer from what GitHub receives — you write them regardless; they are the pipeline's counting and filtering signals.)
 - 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.
@@ -1187,10 +1207,10 @@ Then submit it — through `submit`, which checks the authorisation and the payl
 "${QWEN_CODE_CLI:-qwen}" review submit \
   --pr {pr_number} --repo {owner}/{repo} \
   --review .qwen/tmp/qwen-review-{target}-review.json \
-  [--host <host>]     # required for GitHub Enterprise; omit on github.com
+  [--host <host>]     # the PR's host — pass for every PR target, including github.com (pins the platform)
 ```
 
-**If the call fails with HTTP 422**, the review is created all-or-nothing — nothing was posted, including the Critical findings. This should now be unreachable for anchor arithmetic: every `line` you posted came out of `resolve-anchors`, which only ever considers lines it collected from **inside a hunk** of the very diff you are reviewing. So before working the recovery below, check the likelier remaining causes: **the diff you resolved against is not the commit you are posting to** — re-run `"${QWEN_CODE_CLI:-qwen}" review meta <n> --repo <owner>/<repo>` (add `--host <host>` for Enterprise) and compare its `headSha` to the `commit_id` in your review JSON (which is the `fetchedSha` Step 1 captured; `fetchedSha` is a field of the _fetch report_, not of the review JSON). If they differ, the head advanced mid-review and **this review is of a commit that is no longer the pull request.** Do not re-resolve the old findings against the new diff and submit those: re-resolving relocates the _anchors_, it does not review the new code, re-verify the old conclusions, re-check the open Criticals, or re-run presubmit. You would be approving lines nobody read, or filing a blocker the new commit already fixed. **Abandon this submission and start the review again at the new SHA** — say so in your output, and go back to Step 1's `fetch-pr` — **unless this review has already restarted once for head movement** (the shared per-review bound the drift rule states above): in that case do NOT restart again, submit at the current reviewed SHA with the drift named, and let the Approve cap stand. Step 8 writes no cache for an abandoned run. The other cause is a `line` hand-edited after the resolver returned it. GitHub's error names the failing field (`pull_request_review_thread.line must be part of the diff`) but **does not tell you which entry is at fault**, so do not try to read the offender out of the error text.
+**If the call fails with HTTP 422**, the review is created all-or-nothing — nothing was posted, including the Critical findings. This should now be unreachable for anchor arithmetic: every `line` you posted came out of `resolve-anchors`, which only ever considers lines it collected from **inside a hunk** of the very diff you are reviewing. So before working the recovery below, check the likelier remaining causes: **the diff you resolved against is not the commit you are posting to** — re-run `"${QWEN_CODE_CLI:-qwen}" review meta <n> --repo <owner>/<repo>` (with `--host <host>` for every PR target — see Step 1's host rule) and compare its `headSha` to the `commit_id` in your review JSON (which is the `fetchedSha` Step 1 captured; `fetchedSha` is a field of the _fetch report_, not of the review JSON). If they differ, the head advanced mid-review and **this review is of a commit that is no longer the pull request.** Do not re-resolve the old findings against the new diff and submit those: re-resolving relocates the _anchors_, it does not review the new code, re-verify the old conclusions, re-check the open Criticals, or re-run presubmit. You would be approving lines nobody read, or filing a blocker the new commit already fixed. **Abandon this submission and start the review again at the new SHA** — say so in your output, and go back to Step 1's `fetch-pr` — **unless this review has already restarted once for head movement** (the shared per-review bound the drift rule states above): in that case do NOT restart again, submit at the current reviewed SHA with the drift named, and let the Approve cap stand. Step 8 writes no cache for an abandoned run. The other cause is a `line` hand-edited after the resolver returned it. GitHub's error names the failing field (`pull_request_review_thread.line must be part of the diff`) but **does not tell you which entry is at fault**, so do not try to read the offender out of the error text.
 
 Recovery, if it is genuinely an anchor: recheck them against `files[].hunks[]` from the fetch report — a pure lookup, no API calls (in lightweight mode, against the `fetch-diff` output you already have): an entry is valid if its `line` appears **anywhere inside a diff hunk** for `path` — an added or modified line, or an unchanged context line rendered within the hunk (every comment is on the `RIGHT` side: a single-line one by default, a multi-line one because it says so explicitly). For a multi-line entry, **one hunk must contain the whole range**: `newStart <= start_line <= line <= newEnd` for the _same_ hunk. Checking the two ends independently passes a range whose endpoints sit in different hunks, and a reversed range (`start_line > line`) passes both checks and 422s anyway — a second rejection you paid a round trip to discover. Check that it carries `side` and `start_side` too, whose absence is itself a 422. What GitHub rejects is a line in **no hunk at all**, or a file the PR does not touch. Drop every entry that fails that test, then resubmit once: move each failing **Critical** into the `body` as a whole-PR observation, and discard each failing **Suggestion** (it stays in the terminal output and the Step 8 report — Suggestion text must not enter `body`, see above). **You recompute nothing.** Update the payload and resubmit: each relocated Critical moves into `state.bodyCriticals`, each discarded Suggestion increments `state.suggestionsDiscarded`, and the failing entries come out of `comments`. `submit` recomposes the event and body from what you hand it, so the guarantees the recovery used to hand-derive are structural: a discarded Suggestion still counts toward `S`, so the verdict never upgrades to `APPROVE` on the resubmit; a context-unavailable run keeps its diff-only wording; a relocated blocker keeps `REQUEST_CHANGES` (body Criticals count toward `C` exactly like anchored ones). If the resubmit still 422s, submit once more with `"comments": []` — every remaining Critical in `state.bodyCriticals`, every Suggestion counted in `state.suggestionsDiscarded`: a review with the blockers in prose beats no review at all, and the truth table produces a non-empty `COMMENT` body when no Critical remains, so the one combination GitHub is documented to reject (no body, no comments) cannot be constructed. Never let a single mis-anchored Suggestion suppress a Critical blocker. Log which entries were relocated and which were discarded.
 
@@ -1247,14 +1267,14 @@ After the Markdown report exists, create and register the structured review arti
 
 `save-artifact` resolves relative paths and its containment root against `--workspace-root` — **pass the main project directory explicitly, as the block above does**; without the flag it falls back to its own working directory. The flag is not decoration: the root anchors the containment checks (`isWithin` and the symlink walk), and an ambient-cwd root is only as trustworthy as wherever the command happened to run — from inside the untrusted PR worktree it would be the PR's own tree, the exact threat `comment-status`'s run-from-the-main-checkout rule exists to prevent. It used to prefer `QWEN_CODE_PROJECT_DIR`, which does not name the main checkout in any environment — the harness exports it as the session-storage directory under the runtime base — and every measured CI run burned minutes rediscovering that before improvising a workaround (measured; DESIGN.md — The artifact root that pointed at qwen-home).
 
-For PR worktree mode, the findings and composed inputs were created inside `worktreePath`, while the durable report and output belong to the main project directory. Pass absolute paths for all four: resolve `--findings` and `--composed` against `worktreePath`, and resolve `--report` and `--out` against the main project directory. The worktree lives under the main project's `.qwen/tmp/`, so all four remain inside the session workspace accepted by the helper. `save-artifact` prints one JSON object on stdout — `{"path": "<absolute path>", "workspacePath": "<path relative to the main project directory>"}`. Then call `record_artifact` in the current session with exactly this registration shape, copying `workspacePath` from that stdout object verbatim (do not re-derive it from the absolute path):
+For PR worktree mode, the findings and composed inputs were created inside `worktreePath`, while the durable report and output belong to the main project directory. Pass absolute paths for all four: resolve `--findings` and `--composed` against `worktreePath`, and resolve `--report` and `--out` against the main project directory. The worktree lives under the main project's `.qwen/tmp/`, so all four remain inside the session workspace accepted by the helper. `save-artifact` prints one JSON object on stdout — `{"path": "<absolute path>", "workspacePath": "<path relative to the main project directory>"}`. Then call `record_artifact` in the current session with exactly this registration shape, copying the absolute `path` into `workspacePath`. The tool verifies the file and stores the canonical workspace-root-relative form. Do not invent a different relative path, and do not use the old `path` tool parameter:
 
 ```json
 {
   "title": "Code review result",
   "kind": "other",
   "storage": "workspace",
-  "workspacePath": ".qwen/reviews/<report>.json",
+  "workspacePath": "<absolute path from save-artifact.path>",
   "mimeType": "application/vnd.qwen.code-review+json",
   "metadata": {
     "artifactType": "code_review",
@@ -1269,7 +1289,7 @@ The JSON helper is fail-closed because it carries the authoritative review resul
 
 If reviewing a PR **at high effort**, update the review cache for incremental review support. Low and medium reviews must NOT write it — a cache hit would make a later high-effort review of the same SHA report "No new changes since last review", silently converting a cheaper pass into a full-review verdict.
 
-**A fail-closed run must not advance the cache either.** If this run ended with any not-reviewed or unresolved scope — `unreviewedDimensions` or uncoverable chunks non-empty, the context-unavailable state, **any `cannotTellCriticals` entry, or any cap in the composed verdict** (`compose-review`'s output carried a non-empty `cappedBy` — the module computes caps with no input channel at all, a chunk nobody read among them, and the marker's anchor is withheld under exactly this net; the cache and the marker must not disagree about what a clean round is) — **skip the cache write entirely and say so in the terminal output**. Caching this SHA would scope the next high-effort run to `lastCommitSha..HEAD` — or, worse, let the same-SHA shortcut report "No new changes since last review" and skip the run outright, Step 6 re-check included: a whiffed Security lens at SHA A followed by an incremental review at SHA B means no run ever reviews A's diff for security, and an existing blocker this run could only mark `cannot tell` would never be re-checked at the same SHA, while the cached verdict reads as full coverage. Leave the previous cache entry in place (or none), so the next high-effort run re-covers the whole range — re-detecting any uncoverable chunk and re-ruling on any undecided blocker, keeping both disclosures alive:
+**The cache advances exactly when the marker anchored — read the marker, do not re-derive the net.** `compose-review` already computed whether this round may certify a range: its posted body's ledger marker carries a `sha` on a clean round and withholds it otherwise (unproven coverage, an undecided blocker, any cap other than a depth-only `unreviewed-dimension` — where depth-only means every entry names the build-and-test dimension or is the machine's own relayed stop entry; a whiffed LENS in that field withholds). The cache and the marker must never disagree about what a clean round is, and a hand-copied condition list here is how they drifted once already — the list in this paragraph aged out of sync with the module and told a whiffed-lens round to cache the sha the marker had refused. So the rule is mechanical: **write `lastCommitSha` into the cache only if the composed body's marker carries a `sha`** (check the composed JSON's body for `"sha"` inside the `qwen-review-ledger` comment); when it does not, **skip the cache write entirely and say so in the terminal output**. Caching this SHA would scope the next high-effort run to `lastCommitSha..HEAD` — or, worse, let the same-SHA shortcut report "No new changes since last review" and skip the run outright, Step 6 re-check included: a whiffed Security lens at SHA A followed by an incremental review at SHA B means no run ever reviews A's diff for security, and an existing blocker this run could only mark `cannot tell` would never be re-checked at the same SHA, while the cached verdict reads as full coverage. Leave the previous cache entry in place (or none), so the next high-effort run re-covers the whole range — re-detecting any uncoverable chunk and re-ruling on any undecided blocker, keeping both disclosures alive:
 
 1. Create `.qwen/review-cache/` directory if it doesn't exist
 2. Write `.qwen/review-cache/pr-<number>.json` with:
@@ -1295,7 +1315,7 @@ If reviewing a PR **at high effort**, update the review cache for incremental re
    }
    ```
 
-   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, round number, and — when the run ended clean — the reviewed head `sha`, and the next round's `pr-context` reads it back wherever it runs. The `sha` is what lets a fresh environment recover BOTH halves of incremental review, the work list and the anchor (Step 1's recovered-anchor check), where the cache could only ever serve the machine that wrote it. It is withheld under the fail-closed conditions that skip this cache write **and under every cap `compose-review` computes itself** — the four named inputs (`unreviewedDimensions`, `cannotTellCriticals`, `uncoverableChunks`, the context-unavailable state) plus a non-empty `cappedBy` verdict (coverage the module could not prove, findings still `— [unverified]`, the deterministic gates) — because an anchor written past unreviewed scope would let the next round's incremental range skip it forever: a fail-closed round still posts its findings; it just never certifies a range. The wider net is measured, not cautionary: gated on the four input fields alone, a round the module itself stamped "could not certify that any of this diff was reviewed" still carried the anchor. 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. Findings the convergence posture deferred stay out the same way — carrying them as ledger work would hand the next round the very re-ruling the posture exists to end. Their durable record is the POSTED deferral list (up to 20 entries; the body's overflow count names how many more): the findings artifact carries each deferred finding's full content under its `D<round>-<n>` id but no structured deferred marker yet, and the run report is machine-local — so entries past the rendered cap have no cross-round record on the PR. Keep the deferral list within its cap by collapsing families first (the bounded/unbounded rule) rather than deferring twenty-plus point findings.
+   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, round number, and — when the run ended clean — the reviewed head `sha`, and the next round's `pr-context` reads it back wherever it runs. The `sha` is what lets a fresh environment recover BOTH halves of incremental review, the work list and the anchor (Step 1's recovered-anchor check), where the cache could only ever serve the machine that wrote it. It is withheld under the fail-closed conditions that skip this cache write **and under every cap `compose-review` computes itself except `unreviewed-dimension`** — `cannotTellCriticals`, `uncoverableChunks`, the context-unavailable state, `scopeUnproven` (coverage the module could not prove — a chunk nobody read, an idle or blind agent), findings still `— [unverified]`, the deterministic gates — because an anchor written past unread scope would let the next round's incremental range skip it forever: a fail-closed round still posts its findings; it just never certifies a range. The wider net is measured, not cautionary: gated on the input fields alone, a round the module itself stamped "could not certify that any of this diff was reviewed" still carried the anchor. **`unreviewedDimensions` is the deliberate exception, and it is measured too**: it is prose about DEPTH — "the integration suite CI skipped did not run locally" is true of every round on a repo whose suites do not fit `build-test`'s whole-call budget — so gating on it closed a loop with no exit, where an untestable dimension capped the verdict, the cap withheld the anchor, and the missing anchor made the next round re-review the full diff of a PR that had not changed a line (measured: PR #9113 round 2, 119 minutes, 34M input tokens). A dimension nobody could run says nothing about WHICH LINES were read, and the anchor's only claim is about lines. 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. Findings the convergence posture deferred stay out the same way — carrying them as ledger work would hand the next round the very re-ruling the posture exists to end. Their durable record on the PR is the POSTED deferral list (up to 20 entries; the body's overflow count names how many more) — and it is **not guaranteed**: the list is the first section the body budget trims, so an overflowing body can carry none of it. The findings artifact carries each deferred finding's full content under its `D<round>-<n>` id but no structured deferred marker yet, and the run report is machine-local — so an entry past the rendered cap, or in a list the budget trimmed, has no cross-round record on the PR at all. Keep the deferral list within its cap by collapsing families first (the bounded/unbounded rule) rather than deferring twenty-plus point findings; when the budget trims it, the terminal summary is where the author's copy comes from.
 
 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.
 

package/chunks/{MaxSizedBox-UQALOVVT.js → MaxSizedBox-3PZITE2Y.js}

@@ -4,44 +4,44 @@ import {
   MINIMUM_MAX_HEIGHT,
   MaxSizedBox,
   setMaxSizedBoxDebugging
-} from "./chunk-BHILXOC3.js";
+} from "./chunk-J63PKMYA.js";
 import "./chunk-6QFDQMQX.js";
 import "./chunk-SV5PQVQE.js";
 import "./chunk-2IIJTXYF.js";
 import "./chunk-2M55OBEB.js";
 import "./chunk-5QWWOFGG.js";
-import "./chunk-4NFY2S7N.js";
+import "./chunk-E7REAOTN.js";
 import "./chunk-2MIN6GRR.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-RKUWKYED.js";
-import "./chunk-4S5337WV.js";
+import "./chunk-XC377TLN.js";
 import "./chunk-GOFAQQZA.js";
 import "./chunk-5M6IDOMF.js";
 import "./chunk-TWPJO254.js";
 import "./chunk-CQ35AJ4Z.js";
-import "./chunk-DGZEMW5R.js";
-import "./chunk-WSH6GRKG.js";
-import "./chunk-CKSJECTU.js";
-import "./chunk-OVZPVYZB.js";
+import "./chunk-FS5NGKWC.js";
+import "./chunk-SLILKYV2.js";
+import "./chunk-NVRMCWTP.js";
+import "./chunk-AKBOLMUF.js";
 import "./chunk-6PVPNMXU.js";
-import "./chunk-5EYKMUUY.js";
+import "./chunk-SR2LYSMT.js";
 import "./chunk-IRH27ZC2.js";
 import "./chunk-QHWCP53L.js";
-import "./chunk-Y3YCSWG5.js";
-import "./chunk-UPDOZBWO.js";
+import "./chunk-OBJYN4MX.js";
+import "./chunk-2C6HJMG3.js";
 import "./chunk-O6GEWCJA.js";
 import "./chunk-T26EAKDL.js";
 import "./chunk-ZPJWUGCS.js";
 import "./chunk-CPBF7KYF.js";
 import "./chunk-RWDNJBWN.js";
-import "./chunk-25EYDK42.js";
+import "./chunk-WPVUOVYX.js";
 import "./chunk-MIPFDQAF.js";
 import "./chunk-MLXTMF7H.js";
 import "./chunk-KV27IEHM.js";
 import "./chunk-E3DYKPYZ.js";
-import "./chunk-OMLJNPBE.js";
-import "./chunk-OXCMMLED.js";
-import "./chunk-TIGA2IVL.js";
+import "./chunk-4ZMS3JCR.js";
+import "./chunk-DGJ7O55J.js";
+import "./chunk-OO4FKHLO.js";
 import "./chunk-SAH4BD2J.js";
 import "./chunk-XLLKYULU.js";
 import "./chunk-PT4I7NBA.js";
@@ -51,7 +51,7 @@ import "./chunk-SG7ZP5PG.js";
 import "./chunk-K623ENWT.js";
 import "./chunk-AQ37AY7B.js";
 import "./chunk-KBXKR5R2.js";
-import "./chunk-GMIEIY3Y.js";
+import "./chunk-I3N2Z25H.js";
 import "./chunk-NAVJD2PQ.js";
 import "./chunk-ROIYNTHJ.js";
 import "./chunk-2B2BF7P7.js";
@@ -59,28 +59,29 @@ import "./chunk-P3QQPMQA.js";
 import "./chunk-YZHRN3CF.js";
 import "./chunk-FAAUPSY2.js";
 import "./chunk-KM73TBQ4.js";
-import "./chunk-MPHPFVKK.js";
 import "./chunk-AXMWHKXA.js";
 import "./chunk-GLCZKT5V.js";
 import "./chunk-DJ2GSRLV.js";
 import "./chunk-QFJ5JHQR.js";
-import "./chunk-RVOJ2FBP.js";
+import "./chunk-KC4WMLZO.js";
 import "./chunk-YRLW2MSX.js";
 import "./chunk-VGC4I5JJ.js";
+import "./chunk-3PWCMXIR.js";
 import "./chunk-CHHABXPE.js";
 import "./chunk-MA2HEDVP.js";
 import "./chunk-XUJNK7Y6.js";
 import "./chunk-6HY6IF3Z.js";
-import "./chunk-4PKCUT7F.js";
+import "./chunk-QIHHJKXT.js";
 import "./chunk-F6WFNA7U.js";
-import "./chunk-46UV252V.js";
+import "./chunk-WZAD4ZNJ.js";
 import "./chunk-FPGTNKCP.js";
+import "./chunk-YHC2EYYG.js";
 import "./chunk-CPHEPGAO.js";
-import "./chunk-P7MPQI75.js";
-import "./chunk-FDGGZIYW.js";
-import "./chunk-EL5SXY3T.js";
+import "./chunk-DVR7XKO5.js";
+import "./chunk-YECDICIO.js";
+import "./chunk-XT4RKHVE.js";
 import "./chunk-HHJLM3WQ.js";
-import "./chunk-K5IDV3PC.js";
+import "./chunk-D34RDOLP.js";
 import "./chunk-BUQDLC2G.js";
 import "./chunk-VOQXFAY5.js";
 import "./chunk-75DOP5OR.js";