@qwen-code/qwen-code 0.24.5-preview.0 → 0.24.5

package/bundled/qc-helper/docs/features/channels/weixin.md

@@ -28,7 +28,7 @@ Add the channel to `~/.qwen/settings.json`:
   "channels": {
     "my-weixin": {
       "type": "weixin",
-      "senderPolicy": "pairing",
+      "privatePolicy": "pairing",
       "allowedUsers": [],
       "sessionScope": "user",
       "cwd": "/path/to/your/project",
@@ -82,7 +82,7 @@ WeChat channels support all the standard channel options (see [Channel Overview]
 - **Use plain text instructions** — Since WeChat strips all markdown, add instructions like "Use plain text only" to avoid the agent producing formatted responses that look messy.
 - **Keep responses short** — WeChat message bubbles work best with concise text. Adding a character limit to your instructions helps (e.g., "Keep responses under 500 characters").
 - **Session expiry** — If you see "Session expired (errcode -14)" in the logs, your WeChat login has expired. Stop the channel and re-run `qwen channel configure-weixin` to log in again.
-- **Restrict access** — Use `senderPolicy: "pairing"` or `"allowlist"` to control who can talk to the bot. See [DM Pairing](./overview#dm-pairing) for details.
+- **Restrict access** — Use `privatePolicy: "pairing"` or `"allowlist"` to control who can talk to the bot. See [DM Pairing](./overview#dm-pairing) for details.
 
 ## Troubleshooting
 
@@ -98,7 +98,7 @@ Your WeChat login session has expired. Stop the channel and run `qwen channel co
 
 - Check the terminal output for errors
 - Verify the channel is running (`qwen channel start my-weixin`)
-- If using `senderPolicy: "allowlist"`, make sure your WeChat user ID is in `allowedUsers`
+- If using `privatePolicy: "allowlist"`, make sure your WeChat user ID is in `allowedUsers`
 
 ### Images not working
 

package/bundled/qc-helper/docs/features/code-review.md

@@ -93,6 +93,8 @@ Step 5:  Iterative reverse audit, fanned out per chunk;
 Step 6:  Present findings + verdict (high; low pass: findings only)
          Canonicalize findings -> .qwen/tmp/...-findings.json
 Step 6B: Apply findings + record per-finding outcomes  (--fix only)
+         + fix audit: one agent over the applied hunks,
+           reports unpinned new assumptions (no verdict)  [1 call]
 Step 7:  Submit PR review (inline comments, if requested; high only)
 Step 8:  Save report + incremental cache (cache: high only)
 Step 9:  Clean up (remove worktree + temp files)
@@ -232,6 +234,8 @@ A finding is skipped when its fix would change intended behavior, would need cha
 
 **Every finding gets an outcome, and this is enforced rather than requested.** The ledger goes through `qwen review findings --outcomes`, which refuses a set that does not cover all of them — a fixer that applies six of nine findings and reports six has not lied about any one of them, it has silently shortened the list, and you would have no way to see the three that fell off.
 
+**The applied fix is then audited — by one agent, and not by re-reviewing your tree.** The review does not re-run itself over code it just edited (that would be a new review of different code, wearing this one's verdict). Instead it records your working tree before the first edit (`qwen review fix-delta --snapshot`, through a throwaway index — your own index and stash are never touched), diffs the tree against that record afterwards (`fix-delta --since`), and hands exactly those hunks, together with the `fixed` findings each claims to close, to a single `fix-audit` agent. That agent never sees the reviewed diff and files no findings. (It is not the narrower fix-audit-shaped round a critical-posture PR re-review runs, described below: that round reviews a pull request, and this agent runs only on local and file targets — after `--fix`, or after you type `fix these issues`.) It answers one question per hunk: what does this edit newly assume — a bound, a key, a lifetime, a shared resource, an ordering — and does anything in the tree pin it (a test that goes red, a type, a single source the value derives from)? Only the unpinned ones come back, each with what would pin it. They are reported in a **Fix audit** block in the terminal and as the affected finding's outcome note; they are not findings, change no verdict, and are left for you to act on — the measured reason this exists is that a third of a multi-round review's later findings were introduced by the fix immediately before them, and the two Criticals a real fix round shipped were exactly assumptions of this kind that a mutation probe of the intended fix sites could not reach (that round was a PR review whose author applied the posted comments — the path this audit does not run on; it runs where `--fix` is effective, on local and file targets). If nothing was `fixed` and nothing was applied, the audit is skipped and says so; if the ledger and the tree disagree — no `fixed` outcome beside hunks that landed, or a `fixed` outcome beside no hunk at all — you are told, because that is a bookkeeping problem rather than an audit question. A `fixed` finding none of whose locations any hunk touches is reported by the auditor as unattested rather than refused, since a fix can legitimately land entirely in files the finding does not name. The hunks have a fixed scope, printed beside the audit: the files HEAD tracks, and every other file no ignore rule hides. An edit inside a submodule or a nested repository, to a gitignored file HEAD does not track, or to any path in the review's `.qwen/tmp` name families (`qwen-review-*`, `review-pr-*`, `file-review-*`) is not in them; a hunk shows a file as git stores it (a binary file only as `Binary files … differ`, a Git LFS file as its pointer); an edit that changes the ignore rules brings the files they hid in as additions; and a commit made between the snapshot and the diff is reported — a committed edit is still in the hunks, but a gitignored file the commit started tracking is not.
+
 ## Resuming an interrupted review (`--resume`)
 
 A long review that dies part-way — a dropped connection, a timeout, a killed terminal — leaves everything it had done on disk: the worktree, the captured diff, and the harness's own record of every agent that ran. `--resume` continues from there instead of starting over:

package/bundled/qc-helper/docs/features/computer-use.md

@@ -26,7 +26,7 @@ When first used, the skill runs these commands itself:
 
 ```bash
 qwen mcp add --scope user node-repl npx -y @qwen-code/node-repl-mcp@0.1.6
-npm install --no-save --package-lock=false @qwen-code/cua-sdk@0.20.9
+npm install --no-save --package-lock=false @qwen-code/cua-sdk@0.20.11
 ```
 
 Restart Qwen Code after the MCP server is first added. The skill then resumes

package/bundled/qc-helper/docs/quickstart.md

@@ -78,7 +78,7 @@ The first-run menu lets you connect a model provider. Choose one of:
 
 > [!note]
 >
-> When you first authenticate Qwen Code with your Qwen account, a workspace called ".qwen" is automatically created for you. This workspace provides centralized cost tracking and management for all Qwen Code usage in your organization.
+> Qwen Code stores its configuration and customizations in `.qwen` directories: `~/.qwen/` for user-level settings (e.g. `settings.json`) and global custom commands, and `<project>/.qwen/` for project-specific files such as custom commands and summaries.
 
 > [!tip]
 >
@@ -221,19 +221,19 @@ review my changes and suggest improvements
 
 Here are the most important commands for daily use:
 
-| Command               | What it does                                     | Example                       |
-| --------------------- | ------------------------------------------------ | ----------------------------- |
-| `qwen`                | start Qwen Code                                  | `qwen`                        |
-| `/auth`               | Change authentication method (in session)        | `/auth`                       |
-| `/doctor`             | Check current authentication and environment     | `/doctor`                     |
-| `/help`               | Display help information for available commands  | `/help` or `/?`               |
-| `/compress`           | Replace chat history with summary to save Tokens | `/compress`                   |
-| `/clear`              | Clear terminal screen content                    | `/clear` (shortcut: `Ctrl+L`) |
-| `/theme`              | Change Qwen Code visual theme                    | `/theme`                      |
-| `/language`           | View or change language settings                 | `/language`                   |
-| → `ui [language]`     | Set UI interface language                        | `/language ui zh-CN`          |
-| → `output [language]` | Set LLM output language                          | `/language output Chinese`    |
-| `/quit`               | Exit Qwen Code immediately                       | `/quit` or `/exit`            |
+| Command               | What it does                                     | Example                            |
+| --------------------- | ------------------------------------------------ | ---------------------------------- |
+| `qwen`                | start Qwen Code                                  | `qwen`                             |
+| `/auth`               | Change authentication method (in session)        | `/auth`                            |
+| `/doctor`             | Check current authentication and environment     | `/doctor`                          |
+| `/help`               | Display help information for available commands  | `/help` or `/?`                    |
+| `/compress`           | Replace chat history with summary to save Tokens | `/compress`                        |
+| `/clear`              | Clear conversation history and free up context   | `/clear` (aliases: `reset`, `new`) |
+| `/theme`              | Change Qwen Code visual theme                    | `/theme`                           |
+| `/language`           | View or change language settings                 | `/language`                        |
+| → `ui [language]`     | Set UI interface language                        | `/language ui zh-CN`               |
+| → `output [language]` | Set LLM output language                          | `/language output Chinese`         |
+| `/quit`               | Exit Qwen Code immediately                       | `/quit` or `/exit`                 |
 
 See the [CLI reference](./features/commands) for a complete list of commands.
 

package/bundled/qc-helper/docs/qwen-serve.md

@@ -80,7 +80,7 @@ qwen serve
 
 The default bind is `127.0.0.1:4170`. Bearer auth is **off** and the primary listener is trusted, so any local process that can reach the port can use the full operator API, including executing code as the daemon user. Route-specific workspace trust, session ownership, `X-Qwen-Client-Id`, permission, feature, validation, and resource checks still apply. The daemon registers the current working directory as its primary workspace; use an absolute `--workspace /path/to/dir` to override it, and repeat the flag to register additional isolated runtimes.
 
-For an API-only daemon, disable the Web Shell. The session, prompt, workspace, permission and SSE routes are unchanged; the surfaces bound to the Web Shell go with it — Local Control enablement fails closed on every platform, and on macOS the `/live/*` routes and the `/live/host` WebSocket are not registered:
+For an API-only daemon, disable the Web Shell. The session, prompt, workspace, permission and SSE routes are unchanged; the surfaces bound to the Web Shell go with it — Local Control enablement fails closed on every platform, and the `/live/*` routes (plus, on macOS with `QWEN_SERVE_LIVE_NATIVE_HOST=1`, the `/live/host` WebSocket) are not registered:
 
 ```bash
 qwen serve --no-web
@@ -168,7 +168,7 @@ qwen channel status --daemon-url http://127.0.0.1:4170 --token secret
 qwen channel stop --daemon-url http://127.0.0.1:4170 --token secret
 ```
 
-This mode is experimental and daemon-managed. It does not replace the standalone `qwen channel start` command: without `--daemon-url`, existing `qwen channel start`, `stop`, and `status` behavior remains standalone. With `qwen serve --channel`, the explicit selection wins, the daemon reserves the channel-service lease before listening, and startup fails if the initial worker cannot become ready. On a flagless boot, the daemon restores `serve.channels` from every trusted registered workspace, so a channel a non-primary workspace is configured to start comes back with the daemon instead of needing a runtime API call. If neither source selects channels, the heavy channel runtime remains unloaded and no channel-service lease is reserved until the first runtime PUT. A channel name listed by a workspace that cannot host it is skipped with a log, leaving the other workspaces' channels running; `all` still applies only to the primary workspace. If a ready worker later crashes, the daemon keeps running, relaunches it under a bounded restart policy, and reports its state (including `channel_worker_exited` warnings) in `GET /daemon/status`.
+This mode is experimental and daemon-managed. It does not replace the standalone `qwen channel start` command: without `--daemon-url`, existing `qwen channel start`, `stop`, and `status` behavior remains standalone. With `qwen serve --channel`, the explicit selection wins, the daemon reserves the channel-service lease before listening, and startup fails if the initial worker cannot become ready. On a flagless boot, the daemon restores `serve.channels` from every trusted registered workspace, so a channel a non-primary workspace is configured to start comes back with the daemon instead of needing a runtime API call. If neither source selects channels, the heavy channel runtime remains unloaded and no channel-service lease is reserved until the first runtime PUT, or until a workspace that configures its own `serve.channels` registers. A trusted workspace registered after the daemon started restores its own `serve.channels` too, once per daemon run: registering it again later — after removing it, or after its trust was reconfigured — does not repeat the restore, so a channel you stopped in between stays stopped. Starting the daemon with an explicit `--channel` skips this entirely, and so does stopping channels with `qwen channel stop` (`DELETE /workspace/channel`) until a `qwen channel set` enables them again: registering a workspace is not a request to turn hosting back on. Unlike the boot restore, which skips a name it cannot host and keeps the rest, a late workspace whose list contains such a name gets none of its channels back, and the daemon log records why. Registering the workspace does not wait for its channels to come up. A channel name listed by a workspace that cannot host it is skipped with a log, leaving the other workspaces' channels running; `all` still applies only to the primary workspace. If a ready worker later crashes, the daemon keeps running, relaunches it under a bounded restart policy, and reports its state (including `channel_worker_exited` warnings) in `GET /daemon/status`.
 
 Automatic restore skips an invalid startup field or a validation or lease error before workers start, logs its `serve.channels` source, and keeps unrelated settings in effect. After a worker startup fails, the daemon continues only once cleanup succeeds. Global runtime startup timeouts and unconfirmed worker stops retain the normal startup-failure behavior; the service lease remains held while worker termination is unconfirmed. Check the daemon log for skipped or failed restores.
 
@@ -182,7 +182,7 @@ The daemon reads each channel's settings (tokens, `proxy`, per-channel `model`)
 
 Each selected channel's `cwd` must resolve to a registered workspace, and channels are grouped by that owning workspace: a single-workspace daemon runs one worker (unchanged from before); a multi-workspace daemon (`--workspace` repeated) runs one worker per workspace that owns a selected channel, each bound to that workspace's cwd, `QWEN_DAEMON_WORKSPACE`, and env overlay. To host a channel in a non-primary workspace, define it in that workspace's own `.qwen/settings.json` (no `cwd` needed) or set an explicit `cwd` equal to the workspace path. A channel defined only in user/system scope with no `cwd` is ambiguous across multiple workspaces: an explicit `--channel` selection fails startup, while automatic restore logs the ownership error and skips that selection before workers start. `--channel all` stays primary-only (it hosts the primary workspace's channels) and cannot be combined with named channels.
 
-Replacing a selection preflights configuration, ownership, and trust before stopping anything. It keeps workspace workers whose ordered selection is unchanged. If a changed worker cannot start, the daemon stops new workers and restores the old selection. If the daemon cannot confirm that an old child exited even after SIGKILL, it keeps the PID lease and refuses to create a duplicate worker. A worker is still considered ready when at least one requested adapter connects; PUT then returns `partial: true`, and `/daemon/status` reports `channel_worker_partial_connect` for the missing adapters.
+Replacing a selection preflights configuration, ownership, and trust before stopping anything. It keeps workspace workers whose ordered selection is unchanged. If a changed worker cannot start, the daemon stops new workers and restores the old selection. If the daemon cannot confirm that an old child exited even after SIGKILL, it keeps the PID lease and refuses to create a duplicate worker. A worker is still considered ready when at least one requested adapter connects; PUT then returns `partial: true`, and `/daemon/status` reports `channel_worker_partial_connect` for the missing adapters. A `serve.channels` name the daemon could not bring up — a configured selection whose worker failed to start, a name boot could not attribute, or one a late registration's restore left down — is reported as `channel_restore_failed` on `/daemon/status`, and shows as `error` with its `lastError` in that workspace's channel list when that workspace's own settings define it. Other ways a name can stay unhosted are in the daemon log only.
 
 When an adapter rejects `connect()`, current worker snapshots may include `startupFailures` entries with the channel, `phase: "connect"`, an optional adapter code, and a credential-redacted message. `qwen channel set`, `qwen channel reload`, and remote `qwen channel status --daemon-url …` print these reasons. If every adapter fails during a dynamic set or reload, the command receives `502 channel_worker_start_failed`; the response reasons describe that attempt and its `state` describes the result after rollback. The failed attempt is not retained by later status requests. At most 64 reasons are retained per worker startup, and adapter codes should be treated as diagnostic rather than stable categories. Initial `qwen serve --channel …` startup still exits when no adapter connects.
 
@@ -509,6 +509,10 @@ register the worker. To remove the installation, use your browser or operating
 system's app management; to remove its service worker and stored site data,
 use the browser's site settings.
 
+## Qwen Live (experimental)
+
+Qwen Live runs through the Web Shell on every platform: the browser tab is the microphone and speaker (WS `/live/web`), so open the Web Shell over `https` or `localhost` for microphone access. The native macOS `Qwen Live Host` app is off by default; to try it, start a macOS daemon with `QWEN_SERVE_LIVE_NATIVE_HOST=1`, which restores the `/live/host` WebSocket, the `realtime_voice` capability and the Host download when Live is turned on. Without it, a `Qwen Live Host.app` that is already installed stays unable to connect (the daemon does not register `/live/host`); quit it and use the Web Shell.
+
 ## CLI flags
 
 | Flag                                    | Default            | Purpose                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
@@ -758,7 +762,7 @@ provider decision with their normal tool policy and isolation boundary.
 - **`--hostname 0.0.0.0` requires a token** — one is generated when neither token source is supplied; explicitly empty sources still fail closed.
 - **`LOOPBACK_BINDS` includes IPv6** — `::1` and `[::1]` count as loopback for the no-token rule.
 - **Host header allowlist** — on **loopback** binds the daemon checks `Host:` matches `localhost:port` / `127.0.0.1:port` / `[::1]:port` / `host.docker.internal:port` or the exact bound loopback address and port (case-insensitive per RFC 7230 §5.4) to defend against DNS rebinding. When listening on port 80 or 443, the corresponding port-less forms are also accepted because browsers omit scheme-default ports. This supports the complete IPv4 loopback range (`127.0.0.0/8`) without admitting unrelated Hosts. **Non-loopback binds (`--hostname 0.0.0.0`) intentionally bypass the Host allowlist** — the operator has chosen the surface area, so the bearer-token gate is the sole authentication layer for normal API routes; reverse proxies / SNI / client cert pinning are the operator's responsibility, not the daemon's. If you need Host-based isolation on a non-loopback bind, terminate TLS + check Host at a front proxy.
-- **CORS denies any browser Origin by default** — returns `403` JSON. Pass **`--allow-origin <pattern>`** (repeatable, T2.4 #4514) to opt specific browser origins through. Each value is either the literal `*` (any origin — on a **loopback** bind boot refuses if no bearer token is configured, while a non-loopback bind boots because token generation supplies one; `--require-auth` on loopback is recommended for full hardening since `/health` remains pre-auth on loopback by default — note that the Web Shell static assets (`/`, `/assets/*`, `/manifest.webmanifest`, `/sw.js`, `/session/:id` document navigations) are mounted before the bearer in every mode and stay pre-auth even under `--require-auth`, so use `--no-web` when the residual browser surface matters) or a canonical URL origin (`<scheme>://<host>[:<port>]`, no trailing slash / path / userinfo). On a **loopback** bind without a token, HTTP(S) entries must use a loopback host; a non-loopback bind always carries a token — supplied or generated — precisely because remotely hosted browser origins can execute code through the operator API as the daemon user. Explicit browser-extension origins retain their tokenless local-automation path. Matched origins receive proper CORS response headers (`Access-Control-Allow-Origin: <echoed>`, `Vary: Origin`, plus standard methods / headers / max-age and exposed `Retry-After`); unmatched origins still get a 403 with the same envelope as the default wall. `caps.features.allow_origin` is advertised conditionally so SDK / webui clients can pre-flight whether the daemon honors cross-origin hits before issuing them. Example: `qwen serve --allow-origin http://localhost:3000 --allow-origin http://localhost:5173`. Loopback self-origin hits (e.g. the Web Shell UI) are unaffected — a separate Origin-strip shim handles them regardless of `--allow-origin`. The built-in remote Web Shell's same-origin **HTTP** requests also work without `--allow-origin`: on a non-loopback primary listener an `Origin` equal to the direct socket scheme plus the normalized `Host` authority is bearer-authenticated and then stripped ahead of the CORS wall, while its existing public static routes stay unauthenticated. Two exclusions still need `--allow-origin` — forwarded headers never establish same-origin trust, so a TLS-terminating reverse proxy's `https` browser origin is not same-origin (and neither is a plain-HTTP intermediary that rewrites the `Host` header, such as nginx's default `proxy_set_header Host $proxy_host` or k8s Ingress; the remedy there is `--allow-origin <origin>` for the origin your browser sees, or a proxy that forwards `Host` verbatim — port translation alone needs nothing, because only the forwarded `Host` is compared, with just the scheme-default `:80`/`:443` stripped), and the WebSocket upgrade routes (terminal, voice) keep a separate CSWSH gate that admits only loopback origins, allowlisted origins, and the Local Control listener's own origin.
+- **CORS denies any browser Origin by default** — returns `403` JSON. Pass **`--allow-origin <pattern>`** (repeatable, T2.4 #4514) to opt specific browser origins through. Each value is either the literal `*` (any origin — on a **loopback** bind boot refuses if no bearer token is configured, while a non-loopback bind boots because token generation supplies one; `--require-auth` on loopback is recommended for full hardening since `/health` remains pre-auth on loopback by default — note that the Web Shell static assets (`/`, `/assets/*`, `/manifest.webmanifest`, `/sw.js`, `/session/:id`, `/plugins`, `/channels`, `/scheduled-tasks`, `/goals`, and `/settings` document navigations) are mounted before the bearer in every mode and stay pre-auth even under `--require-auth`, so use `--no-web` when the residual browser surface matters) or a canonical URL origin (`<scheme>://<host>[:<port>]`, no trailing slash / path / userinfo). On a **loopback** bind without a token, HTTP(S) entries must use a loopback host; a non-loopback bind always carries a token — supplied or generated — precisely because remotely hosted browser origins can execute code through the operator API as the daemon user. Explicit browser-extension origins retain their tokenless local-automation path. Matched origins receive proper CORS response headers (`Access-Control-Allow-Origin: <echoed>`, `Vary: Origin`, plus standard methods / headers / max-age and exposed `Retry-After`); unmatched origins still get a 403 with the same envelope as the default wall. `caps.features.allow_origin` is advertised conditionally so SDK / webui clients can pre-flight whether the daemon honors cross-origin hits before issuing them. Example: `qwen serve --allow-origin http://localhost:3000 --allow-origin http://localhost:5173`. Loopback self-origin hits (e.g. the Web Shell UI) are unaffected — a separate Origin-strip shim handles them regardless of `--allow-origin`. The built-in remote Web Shell's same-origin **HTTP** requests also work without `--allow-origin`: on a non-loopback primary listener an `Origin` equal to the direct socket scheme plus the normalized `Host` authority is bearer-authenticated and then stripped ahead of the CORS wall, while its existing public static routes stay unauthenticated. Two exclusions still need `--allow-origin` — forwarded headers never establish same-origin trust, so a TLS-terminating reverse proxy's `https` browser origin is not same-origin (and neither is a plain-HTTP intermediary that rewrites the `Host` header, such as nginx's default `proxy_set_header Host $proxy_host` or k8s Ingress; the remedy there is `--allow-origin <origin>` for the origin your browser sees, or a proxy that forwards `Host` verbatim — port translation alone needs nothing, because only the forwarded `Host` is compared, with just the scheme-default `:80`/`:443` stripped), and the WebSocket upgrade routes (terminal, voice) keep a separate CSWSH gate that admits only loopback origins, allowlisted origins, and the Local Control listener's own origin.
 - **Chrome extension browser automation is separate from framing.** `qwen serve --allow-origin chrome-extension://<id>` lets the extension frame the Web Shell and connect to the daemon. Console/network/screenshot/click tools require an external CDP MCP adapter command: `QWEN_CDP_MCP_COMMAND=/path/to/cdp-mcp-adapter qwen serve --allow-origin chrome-extension://<id>`. The main CLI package does not bundle a browser automation adapter; clients can check `caps.features.includes('browser_automation_mcp')` before presenting those tools as available.
 - **A spawned `qwen --acp` child receives its owning runtime's effective environment.** The daemon freezes a process-env base, applies that workspace's settings/env-file overlay to a runtime-local snapshot, and never writes the overlay back to `process.env`; same-named keys in another runtime do not cross over. `QWEN_SERVER_TOKEN` is scrubbed before spawn because the agent does not need the daemon bearer. Loader-affecting variables (`NODE_OPTIONS`, `npm_config_node_options` and npm's config-file redirects, `NODE_PATH`, `OPENSSL_CONF`, `NODE_REPL_EXTERNAL_MODULE`, `npm_config_node_gyp`, `npm_config_init_module`, `LD_PRELOAD`, `LD_AUDIT`, `DYLD_INSERT_LIBRARIES`, `BASH_ENV`, `ZDOTDIR`, exported bash function definitions `BASH_FUNC_*`) are likewise never passed to session subprocesses — the daemon scrubs them from its own `process.env` and from the frozen base env that session-hosting children spawn with (the base env keeps them only under the `DEV=true` harness, whose `.ts` entries still need the tsx loader), and `.env` / `settings.json` `env` sources reject them (see [settings](./configuration/settings.md)); this applies to every session the daemon hosts. Base credentials such as `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `QWEN_*`, and `DASHSCOPE_API_KEY` otherwise pass through unless the runtime overlay changes them. **This is intentional, not a sandbox.** The agent runs as the same UID with shell-tool access, so anything in `~/.bashrc`, `~/.aws/credentials`, or `~/.npmrc` is reachable by prompt injection regardless. Environment isolation between runtimes is not an operating-system security boundary; do not run `qwen serve` under an identity that has credentials you would not trust the agent with.
 - **Agent text reads are child-local and follow the regular CLI permission rules, not the workspace filesystem boundary.** Direct `read_file` can reach host text paths outside every registered workspace: external paths default to confirmation, and allow rules or approval modes may approve them automatically. Approved reads use the configurable CLI output limits rather than the workspace filesystem's returned-output, full-snapshot, and large-text scan caps. This applies to every shared text-read consumer, so the pre-reads performed by write, edit, notebook, sed, and artifact operations lose those caps together with the workspace filesystem's read audit, symlink rejection, and read-side TOCTOU protections — see [the read design](../design/daemon-local-text-reads.md) for the exact list. Because a confirmation payload is built by reading the file, an out-of-workspace diff is fanned out to **every** attached SSE subscriber before anyone approves it — in the interactive CLI that content is seen only by the person at the terminal. Treat authenticated daemon clients as the same security principal. HTTP filesystem routes remain workspace-scoped and agent discovery-tool behavior is unchanged.
@@ -1074,6 +1078,8 @@ archive after rotation.
 
 The log captures lifecycle messages, route errors (with `route=` and `sessionId=` context), ACP child stderr, and — when `QWEN_SERVE_DEBUG=1` is set — extra bridge breadcrumbs. Lines that go to stderr today still go to stderr; the file log is **additive**, not a replacement.
 
+Failed standalone creation adds `Standalone session creation failed.` with the validated target `sessionId`, failed `phase`, safe `reason`, `dispatchState` and `cleanupOutcome`. Child creation retains the child ID and records the validated parent separately as `relatedSessionId`. Correlate `source_persistence_failed` lines by session ID for private source acknowledgement or transport details; `write_not_confirmed` does not identify a filesystem cause. A completed quarantine is distinct from rollback, and `unknown` does not establish cleanup success. Public error codes and retry behavior remain unchanged. These diagnostics omit raw causes, prompts and source payloads.
+
 The active file rotates before it would exceed 10 MiB. Each family retains
 four archives under `archive/`, and each file record is capped at 256 KiB. The
 in-memory queue accepts at most 4 MiB of unsettled file payload. Queue pressure,

package/bundled/review/SKILL.md

@@ -43,16 +43,18 @@ Your goal here is to understand the scope of changes so you can dispatch agents
 
 If the args file is genuinely absent (an older CLI, or a write that failed), fall back to `write_file`-ing the raw argument string **verbatim and unmodified** — copying **the user's argument**, not an example from these instructions — and say in your output that you did, so a wrong target is at least attributable. For a no-argument `/review`, no file is written and none is needed; run the parser with an empty stdin.
 
-**Every command below is written `"${QWEN_CODE_CLI:-qwen}" review …`, and that is not decoration — copy it as written.** `QWEN_CODE_CLI` is the entry of the CLI **running this skill**, exported to your shell for you; a bare `qwen` is whatever the machine's `PATH` happens to resolve to, which is a different program the moment a global install is older than the build you are in. A stale `PATH` `qwen` has already killed a review mid-run on exactly this version skew (measured; DESIGN.md — The stale PATH qwen). The `:-qwen` fallback keeps older hosts that do not export it working. It is POSIX parameter expansion, which makes the POSIX-shell requirement this skill already had (Step 0 pipes through `tee`) total: on Windows, run the review from git-bash — cmd.exe passes `${…:-…}` through literally and PowerShell errors on it.
+**Every command below is written `"${QWEN_CODE_CLI:-qwen}" review …`, and that is not decoration — copy it as written.** `QWEN_CODE_CLI` is the entry of the CLI **running this skill**, exported to your shell for you; a bare `qwen` is whatever the machine's `PATH` happens to resolve to, which is a different program the moment a global install is older than the build you are in. A stale `PATH` `qwen` has already killed a review mid-run on exactly this version skew (measured; DESIGN.md — The stale PATH qwen). The `:-qwen` fallback keeps older hosts that do not export it working. It is POSIX parameter expansion, which makes the POSIX-shell requirement this skill already had (Step 0's `:` null command) total: on Windows, run the review from git-bash — cmd.exe passes `${…:-…}` through literally and PowerShell errors on it.
 
 Then run:
 
 ```bash
 # The CLI wrote this file; you did not, and must not.
-"${QWEN_CODE_CLI:-qwen}" review parse-args --stdin < <the path in the <skill-args-file> note> \
-  | tee .qwen/tmp/qwen-review-parse-args.json
+"${QWEN_CODE_CLI:-qwen}" review parse-args --stdin --out .qwen/tmp/qwen-review-parse-args.json \
+  < <the path in the <skill-args-file> note>
 # No arguments at all (`/review` bare) — no args file exists:
-#   : | "${QWEN_CODE_CLI:-qwen}" review parse-args --stdin | tee .qwen/tmp/qwen-review-parse-args.json
+#   : | "${QWEN_CODE_CLI:-qwen}" review parse-args --stdin --out .qwen/tmp/qwen-review-parse-args.json
+# `--out`, not `tee`: the command still prints the JSON, and it refuses a
+# `.qwen/tmp` the workspace redirected before this first write lands there.
 ```
 
 **If any `qwen review …` command prints `review: the bundle these commands run from was NOT built from the review sources in this tree`, stop and tell the user before doing anything else.** Every step below runs the built bundle, so a review source changed since that build takes no effect and this run measures the old behaviour — silently. That is true of bundled launches; an `npm start` or `npm run dev` session runs the `tsc` output in `packages/cli/dist/` instead, which lags `src/` the same way but is a layout this check does not cover — there `npm run build:packages` is what refreshes what runs. Measured on 2026-08-02: a round against #8368 exercised commands that had merged that morning and were simply absent from the binary, and reproduced a bug whose fix had merged but was not in the build — it had to be discarded. The user reads your summary, not this stderr, so a line you do not repeat is a line nobody sees. Say what it said, and let them decide whether to rebuild or to read every result as being about the older build. (A related note, `review: could not check whether the bundle is current`, means the same risk is present and unmeasurable — pass it on the same way.)
@@ -177,7 +179,7 @@ Based on the parsed `target.type`:
 
   - **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 merge-base resolution, a capture — is re-run by the re-run. One shape of `capture-failed` retries ONCE, not forever: a base-less refusal (a null `mergeBaseSha`) means the base fetch failed (`baseFetchFailed: true`) and no local base ref remained, or `git merge-base` itself failed on a non-answer exit. The failed component IS re-run by the re-run, but the exit status cannot split the members — git exits 128 identically for a transient fetch fault and for a deterministic refusal (the base branch deleted on the remote — the refspec fetch fails every time), and the merge-base probe folds its surface failures the same way — so a second refusal of the same shape on the same sha is the deterministic member. Retry that one, once. Every other reason is deterministic for the same sha and must NOT be retried: a validity refusal re-refuses; a planless `partition-failed` always carries a `mergeBaseSha` — with no base nothing is captured and an empty diff cannot fail to tile — so both ranges were in hand and both refused to tile, which the re-run reproduces exactly, do not retry it; `nothing-to-narrow` re-narrows identically: the same two captures select the same hunks, and a capture that failed a UTF-8 round trip fails it again — and its base-less shape (a null `mergeBaseSha` with `baseFetchFailed: false`) 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) —, **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 anchor above 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 **and the side file carries no `anchorFromRound`** — a grafted anchor that resolves to the head means the round it was carried for closed at a head its source had already certified, so `sha..HEAD` re-covers nothing, and the stop would abandon that round's owed work list without a ruling, with every later round at the same head repeating the same stop: proceed instead as when `comment.effective` is true (the re-run report already holds the full-range diff and plan) and rule every ledger entry). 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 no anchor is recoverable. When the last posted round was fail-closed (`compose-review` withholds the anchor then — Step 8 names the conditions) and its work list survived whole, `pr-context` grafts the anchor forward from the most recent EARLIER own marker that carries one — the withhold is about the fail-closed round's own range, while the earlier round's "clean up to `sha`" stays true, and scoping `sha..HEAD` re-covers the gap (the ledger section says "anchoring at", never "reviewed at", when the anchor was carried forward this way, and names the round it was carried from). So a missing `sha` means a shape the graft refuses or cannot reach — the winning work list was truncated by the marker's size caps (a partial work list must not certify a range — the dropped entries would fall outside the grafted scope and retire silently), the only anchored own marker is the winner's own round (one round cannot both certify and withhold), the winner ran at the same head the candidate sha certifies (grafting it would hand Step 1 a same-sha stop that abandons the work list the winner still owes), every own round on the PR closed without an anchor, the only markers are other accounts' (the sha never crosses accounts), or the markers predate the field — 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.)
 
-  - **Resuming an interrupted run (`--resume`)**: when `parse-args` reported `resume.effective: true`, append `--resume` to the `fetch-pr` command above (when the plan's wall is the clock — not under the environment's epoch — `fetch-pr` then notes on stderr how much of that wall this continuation has left, or that it has run out, and which builds the gates will now refuse — information about the run ahead, not an instruction: never drop `--resume` or add `--deadline` over it), and decide `--effort` off `effortSource`, not off whether the word `--effort` was typed. Pass the resolved level whenever `effortSource` is `explicit`, `last_used`, `configured`, or `forced-by-comment` (the `--comment` flag or the `review.comment` setting forces high — parse-args announces "running at high effort"); omit it ONLY when `effortSource` is `default`. `fetch-pr` cannot tell a passed-through default from a chosen level: the interrupted run may have recorded a different one, and handing it the resolved default refuses the resume (`effort-mismatch`) whose fresh fall-through discards the very state `--resume` exists to save — blaming an effort nobody asked for. Omitted, the continuation pins to the recorded level. A level this invocation actually requires — a user's explicit `--effort`, the project's remembered level, a configured `review.effort`, or the high that `--comment` forces — that differs from the recorded one is NOT a passed-through default: pass it, so a mismatch refuses the resume (`effort-mismatch`) and runs fresh at the level this invocation needs. That is right — different effort is different work, and posting authority raising the required depth is different work too, never a silent pin. Omitting a `forced-by-comment` high is the trap: `fetch-pr` has no `--comment` input and reads `requestedEffort` only from `--effort`, so the null would pin the continuation at the recorded sub-high level while `--comment` stays effective — the "effective comment at medium effort" state the medium-tier rules call impossible, posting nothing (medium skips posting) or posting from a pipeline missing the high-only passes the forcing exists to guarantee. `fetch-pr` rules on the interrupted attempt's on-disk state itself (worktree still at `fetchedSha` and clean, diff bytes unchanged, PR head unmoved, resume cap unspent — every probe is a fact it gathers, none is yours to assert) and prints one JSON line on stdout. Branch on it:
+  - **Resuming an interrupted run (`--resume`)**: when `parse-args` reported `resume.effective: true`, append `--resume` to the `fetch-pr` command above (when the plan's wall is the clock — not under the environment's epoch — `fetch-pr` then notes on stderr how much of that wall this continuation has left, or that it has run out, and which builds the gates will now refuse — information about the run ahead, not an instruction: never drop `--resume` or add `--deadline` over it), and decide `--effort` off `effortSource`, not off whether the word `--effort` was typed. Pass the resolved level whenever `effortSource` is `explicit`, `last_used`, `configured`, or `forced-by-comment` (the `--comment` flag or the `review.comment` setting forces high — parse-args announces "running at high effort"); omit it ONLY when `effortSource` is `default`. `fetch-pr` cannot tell a passed-through default from a chosen level: the interrupted run may have recorded a different one, and handing it the resolved default refuses the resume (`effort-mismatch`) whose fresh fall-through discards the very state `--resume` exists to save — blaming an effort nobody asked for. Omitted, the continuation pins to the recorded level. A level this invocation actually requires — a user's explicit `--effort`, the project's remembered level, a configured `review.effort`, or the high that `--comment` forces — that differs from the recorded one is NOT a passed-through default: pass it, so a mismatch refuses the resume (`effort-mismatch`) and runs fresh at the level this invocation needs. That is right — different effort is different work, and posting authority raising the required depth is different work too, never a silent pin. Omitting a `forced-by-comment` high is the trap: `fetch-pr` has no `--comment` input and reads `requestedEffort` only from `--effort`, so the null would pin the continuation at the recorded sub-high level while `--comment` stays effective — the "effective comment at medium effort" state the medium-tier rules call impossible, posting nothing (medium skips posting) or posting from a pipeline missing the high-only passes the forcing exists to guarantee. `fetch-pr` rules on the interrupted attempt's on-disk state itself (worktree still at `fetchedSha` and clean, diff bytes unchanged, PR head unmoved, the same model identity running — `model-mismatch` otherwise — and resume cap unspent — every probe is a fact it gathers, none is yours to assert) and prints one JSON line on stdout. Branch on it:
     - **`{"resumed": true, ...}`** — this run continues the interrupted one. The report at the `--out` path is the PREVIOUS attempt's, deliberately left untouched (its mtime is the run epoch every downstream fence keys on); read it for the worktree, plan and diff, which are all reused. The report's `incremental` field is now HISTORY, not a decision to re-take: a resumed run proceeds on the reused plan and does NOT re-enter the incremental check above — in particular it never takes the `upToDate: true` stop/cleanup branch, which runs `cleanup pr-<n>` and would destroy the exact worktree and lease `--resume` just saved (the interrupted attempt was a `--comment` full review of an up-to-date PR; resuming it without `--comment` effective in THIS invocation would otherwise route it straight into "No new changes since last review" and abandon it). Then rebuild your working state from disk before launching anything:
 
       ```bash
@@ -1079,6 +1081,15 @@ The rules it applies — so you can read the line it gives you, not so you can a
 
 **Run this only when the Step 1 verdict says `fix.effective` is true.** A requested-but-ineffective `--fix` (a PR target) has already produced its warning in Step 1; say nothing further and move on.
 
+**Before the first edit, record the tree:**
+
+```bash
+"${QWEN_CODE_CLI:-qwen}" review fix-delta --snapshot \
+  --out .qwen/tmp/qwen-review-{target}-fix-snapshot.json
+```
+
+The fix audit below diffs the tree against this record, so it sees what changed on disk between the two moments — this step's edits, plus any other write that landed in between — and nothing the review was reviewing. It reads the working tree through a throwaway index — the user's index and the stash are untouched — and leaves this review's own files under `.qwen/tmp` out of both captures. A snapshot taken after an edit hides that edit from the audit, and there is no recovering it later. If the command fails (the target is not inside a git checkout, for one), the audit cannot run for this step: apply the findings as below, skip the audit, and say `Fix audit: not run — <what the command said>` in the summary.
+
 Apply each finding to the working tree with the `edit` tool — Criticals and the reuse/simplification/consistency findings alike. **Skip** any finding whose fix would change intended behaviour, would require changes well outside the reviewed diff, or that you judge on a second look to be a false positive. Note the skip; do not argue with it in prose.
 
 **A test you add with a fix earns its place by failing without the fix — so remove the fix and watch it fail.** Not a formality: four assertions written to pin real defects have all survived the mutation they were written for (measured; DESIGN.md — The four assertions that survived their mutation).
@@ -1102,19 +1113,43 @@ Then record what happened to **every** finding — one of `fixed`, `skipped`, or
 
 The three words are three different claims and are not interchangeable. `fixed` — the edit is in the tree. `skipped` — the finding is real and you did not apply it; the note says why, and the reader still owes it attention. `no_change_needed` — the finding was wrong or the code already handled it; it comes **off** the reader's plate. Collapsing `skipped` into `no_change_needed` is how a review quietly retracts a finding it could not fix.
 
-**Then re-issue the `report_findings` call, outcomes on it.** Re-report the same findings — fields copied from the rebuilt artifact, exactly as Step 6's call prescribes — each entry now carrying its `outcome`, and the ledger's note as `outcomeNote` for every `skipped`. The client's per-finding status trusts only a `report_findings` call that carries outcomes — the tool refuses a partial set for the same reason the command above refuses a partial ledger — so a tree edited without re-reporting leaves every client rendering as open the findings the tree already closed. **And this rule outlives Step 6B: any later time in this session a reported finding's disposition changes** — the user has you `fix these issues`, a finding is established to be wrong, a fix lands mid-conversation — record the outcomes into the artifact (`review findings --outcomes`) and re-issue the call with them. When Step 9 cleanup has already swept the `findings-in.json` side file, pass the saved artifact (Step 8's `save-artifact` output under `.qwen/reviews/`) as `--input` instead — the command accepts that wrapper and unwraps its `findings` array, so the outcome path recovers from the state that survives cleanup.
+**Then audit what you applied — one agent, and not a re-review.** Diff the tree against the snapshot, and ask for the auditor's block the way every other agent's is asked for — recorded, and dispatched through the same manifest + workflow machinery every other wave uses:
+
+```bash
+"${QWEN_CODE_CLI:-qwen}" review fix-delta \
+  --since .qwen/tmp/qwen-review-{target}-fix-snapshot.json \
+  --out .qwen/tmp/qwen-review-{target}-fix-hunks.diff && \
+"${QWEN_CODE_CLI:-qwen}" review agent-prompt --plan <the plan report from Step 1> --role fix-audit \
+  --findings .qwen/tmp/qwen-review-{target}-findings.json \
+  --hunks .qwen/tmp/qwen-review-{target}-fix-hunks.diff --batch \
+  > .qwen/tmp/qwen-review-{target}-fix-audit-manifest.json && \
+"${QWEN_CODE_CLI:-qwen}" review emit-workflow --plan <the plan report from Step 1> \
+  --batch .qwen/tmp/qwen-review-{target}-fix-audit-manifest.json
+```
+
+Then call `workflow` with the returned `scriptPath`, `run_in_background: false`, without `args` — one agent, one foreground wave whose child the generated script launches as `subagent_type: "review-agent"`, the auditor's return arriving inline as every agent's in this skill does. `--findings` is the artifact the `--outcomes` run above just rebuilt, not the ledger and not `findings-in.json`: the command reads the outcomes off it and renders only the `fixed` findings above the hunks, and it refuses an artifact whose outcomes were never recorded. **Skip the audit — and say so in one line — only when the ledger holds no `fixed` outcome and the hunks file is empty**: nothing was applied. The `&&` is load-bearing: when `fix-delta --since` fails, do not launch the auditor over a hunks file an earlier run may have left at that path — say `Fix audit: not run — <what the command said>` instead.
+
+Two refusals are a diagnosis to follow before anything is disclosed, because they say the ledger and the tree disagree. **Hunks that landed beside a ledger with no `fixed` outcome** (`the ledger records no `fixed` outcome, but --hunks carries edits`) are edits no outcome owns: if one IS a finding's fix the ledger never recorded, correct the ledger (`review findings --outcomes` again) and re-run the audit command against the rebuilt artifact; if it is a write from outside this flow — a watcher, a formatter, a background build — do not invent a `fixed` outcome to clear it, leave every outcome as the fix round recorded it, and disclose `Fix audit: not run — hunks carry edits no outcome owns`. **An empty hunks file beside a `fixed` outcome** (`--hunks is empty, but the ledger marks … fixed`) is a claim with no edit: when the tree shows the edit never landed, the outcome is wrong and the ledger is what to correct; when the snapshot was taken after the edits, or the edit landed outside the scope below, disclose `Fix audit: not run — <why>` and leave the outcomes untouched. Every other refusal is disclosed as `Fix audit: not run — <what the command said>` and moved past.
+
+**`fix-delta --since` states its scope on stderr, every run** — `fix-delta: scope — the hunks hold what `git add -A` records in this repository …` — and adds `HEAD moved between the two moments` when a commit landed in between (the hunks still compare the working tree, so a committed edit is in them, and so is anything a pull, rebase or checkout in between brought in; only a gitignored file a commit started tracking is not). The scope is fixed, not probed: an edit inside a submodule or a nested repository, to a gitignored file HEAD does not track, or to any path in the review's `.qwen/tmp` name families (tracked or not) is not in the hunks, a hunk shows a file as git stores it (a binary file as `Binary files … differ`, a Git LFS file as its pointer), and an edit that changes the ignore rules brings the files they hid in as additions. Repeat those lines under the **Fix audit** heading beside the auditor's return — an all-clear printed without its scope claims more than the command saw.
+
+What the agent is, and is not. It is not the **fix-audit round** Step 1 routes on when it chooses the topology — that is a PR re-review whose fan-out the critical posting posture narrows, read off the plan's `incremental.posture`, and it never meets this step: its target is a pull request, where `fix.effective` is false. This is one agent over the hunks this step just applied, and nothing about it changes the shape of the review that ran. Its input is the applied hunks and the `fixed` findings rendered above them — never the reviewed diff, so it cannot rediscover this review's findings. It reports two things, and both are disclosures: an assumption the edit newly introduced that nothing in the tree pins — a bound, a key, a lifetime, a shared resource, an ordering — with what would pin it; and a `fixed` finding no hunk in its input touches, on an `unattested:` line, which carries no assumption and no pin because the auditor holds zero bytes of that finding's edit and is told not to go looking for them. It produces no verdict and files no finding. Those three constraints are what keep it on the right side of the rule below: a re-review of the tree you just edited would be a new review of different code, and this is not one. The class it exists for is measured, and it is exactly the class the mutation guidance above does not reach: both Criticals the next round filed against PR #9793's fix were fix-introduced assumptions — a hand-picked `hops < 16` beneath a configurable limit of 100, a `callId`-only dedup written once one entry could host several runtimes — and a mutation probe of the three intended fix sites, which caught all three mutants, reached neither (measured; DESIGN.md — The two fix-introduced Criticals (PR #9793)). Reach, stated exactly: this audit runs where Step 6B runs — the `local` and `file` `--fix` path, the one `fix.effective` admits — and that incident's fix was applied by a human reading posted comments on a PR target, the path #10153 covers; the class is the same on both, the mechanism reaches one of them.
+
+What to do with its return. **An unpinned assumption is a disclosure, not a finding.** It never enters `findings-in.json`, never counts toward `fresh` or `induced`, never changes the verdict, and does not trigger a fix-induced re-report: putting it in the artifact would be the re-review the rule below forbids, arriving through the back door. It has two homes. For each line the agent returns that names a finding id, append the disclosure to that finding's ledger entry as its `note` (several lines for one id go into that one note, joined with `; `, after any note the fix round already wrote) — `fix audit: unpinned — assumes <…>; pin with: <…>` for an assumption, `fix audit: unattested — no hunk in the audit input touches <its locations>` for a `(no hunk)` line, which carries no assumption and no pin for you to copy — and run the `review findings --outcomes` command above again with the amended ledger, so the note rides the artifact as `outcomeNote`. And print every line, id-bearing or `none`, under a **Fix audit** heading in the terminal summary, with the `fix-delta` scope lines above — terminal-only, like the auditor's lines: never into `findings-in.json`, the census, or the verdict. That heading is also where the all-clear receipt goes, quoted, and where an audit that did not run says so with the reason — `Fix audit: not run — <why>`: an agent that died, refused, or returned neither of its two shapes is disclosed and moved past, never a reason to touch the outcomes or the artifact. An `unattested:` line is never a reason to change an outcome either: a fix can legitimately land entirely in files the findings do not name — a test file a finding asked for, the caller of a declaration it named. Do not act on an unpinned assumption in this run: pinning it is another edit, and another edit is another audit — hand it to the reader.
+
+**Then re-issue the `report_findings` call, outcomes on it.** Re-report the same findings — fields copied from the rebuilt artifact, exactly as Step 6's call prescribes — each entry now carrying its `outcome`, and the ledger's note as `outcomeNote` for every `skipped` and for every `fixed` the fix audit annotated. The client's per-finding status trusts only a `report_findings` call that carries outcomes — the tool refuses a partial set for the same reason the command above refuses a partial ledger — so a tree edited without re-reporting leaves every client rendering as open the findings the tree already closed. **And this rule outlives Step 6B: any later time in this session a reported finding's disposition changes** — the user has you `fix these issues`, a finding is established to be wrong, a fix lands mid-conversation — record the outcomes into the artifact (`review findings --outcomes`) and re-issue the call with them. When Step 9 cleanup has already swept the `findings-in.json` side file, pass the saved artifact (Step 8's `save-artifact` output under `.qwen/reviews/`) as `--input` instead — the command accepts that wrapper and unwraps its `findings` array, so the outcome path recovers from the state that survives cleanup.
 
-Report the outcome counts in the terminal summary, and list each `skipped` finding with its reason. **Do not re-run Steps 1–6** to check your own work: a re-review of a tree you just edited is a new review of different code, and its verdict is not this review's.
+Report the outcome counts in the terminal summary, list each `skipped` finding with its reason, and print the **Fix audit** block. **Do not re-run Steps 1–6** to check your own work: a re-review of a tree you just edited is a new review of different code, and its verdict is not this review's. The fix audit is the one check this step runs on its own work, and it is scoped — hunks in, disclosures out, no verdict — precisely so that it is not one.
 
 Append a follow-up tip after the verdict (high and medium effort — only a **low** quick pass and a `--topology minimal` pass emit no verdict and follow their own tip rules instead (Step 3C / Step 3M); their "post comments" follow-ups are declined per those steps). **Tip lines are user-facing terminal prose — translate them into your output language** (critical rule 2). The English templates below define the _content_ and the _command keywords_ (which stay verbatim — `post comments`, `fix these issues`, `commit` are trigger phrases the user types back); translate the surrounding sentence. With a Chinese output language, "Tip: type `post comments` to publish findings as PR inline comments." becomes "提示：输入 `post comments` 将发现作为 PR 行内评论发布。" At **medium**, also add: "Tip: run `/review <target> --effort high` for the full verified review (adds the reverse audit, the language-pitfall and wrapper/proxy specialists, the adversarial personas, the counter-frame audit (PR reviews), and Agent 8 — and can certify Approve)." Choose the rest based on remaining state:
 
 - **Local review with unfixed findings** (Step 6B did not run — `--fix` was not passed): "Tip: type `fix these issues` to apply fixes interactively, or re-run with `/review --fix` to have the review apply and account for them itself."
-- **Local review where Step 6B ran**: offer no fix tip — the findings already carry outcomes. If any came back `skipped`, say so with their reasons instead.
+- **Local review where Step 6B ran**: offer no fix tip — the findings already carry outcomes. If any came back `skipped`, say so with their reasons instead; if the fix audit returned disclosures, they are the follow-up — point at the Fix audit block.
 - **PR review with findings** (only if `comment.effective` is false — when posting is effective, via the `--comment` flag or the `review.comment` setting, comments are already being posted in Step 7, so this tip is unnecessary): "Tip: type `post comments` to publish findings as PR inline comments." (Do NOT offer "fix these issues" for PR reviews — the worktree is cleaned up after the review, so interactive fixing is not possible.)
 - **PR review, zero findings** (only if `comment.effective` is false): "Tip: type `post comments` to approve this PR on GitHub."
 - **Local review, all clear** (Approve or all issues fixed): "Tip: type `commit` to commit your changes."
 
-If the user responds with "fix these issues" (local review only), use the `edit` tool to fix each remaining finding interactively based on the suggested fixes from the review — do NOT re-run Steps 1-6. This is the same work Step 6B does; when the review has a findings artifact, record the outcomes into it the same way (`review findings --outcomes`) and re-issue the `report_findings` call with the outcomes, exactly as Step 6B prescribes, rather than leaving the list, the tree, and the client display disagreeing about what was applied. Under `--topology minimal`, decline per Step 3M instead — the findings are unverified; point at `/review --fix`, which re-runs at medium with verified findings.
+If the user responds with "fix these issues" (local review only), use the `edit` tool to fix each remaining finding interactively based on the suggested fixes from the review — do NOT re-run Steps 1-6. This is the same work Step 6B does, and whether its one extra part — the fix audit — can run here depends on whether the Step 1 plan report `agent-prompt --plan` requires is still on disk. That is a per-target fact, not a general one, so rule it per target rather than asserting a sweep that did not happen. **On a `local` target the plan is gone**: Step 9's `cleanup local` sweeps the `qwen-review-local-*` family, the plan report with it, and nothing else persists it — say `Fix audit: not run — plan report swept by Step 9 cleanup` under the **Fix audit** heading instead of launching the auditor. **On a FILE target no sweep ever reaches the plan**: the `file-review-…` family sits outside every cleanup prefix on purpose (Step 1 and Step 9 both say so, and that exclusion is what keeps a concurrent target's cleanup from killing a live file review's plan — do not rename the family into `qwen-review-*`, and do not make cleanup glob `file-review-*`). Step 9 has _you_ remove that plan by hand, with the one exception it names: a `budget-stop.json` marker inside the `-prompts` directory means the plan AND the directory were deliberately KEPT. So on a file target, look **before the first edit**: in the ordinary case you removed that plan at Step 9, and then say `Fix audit: not run — file-review plan removed at Step 9`; the plan survives when a budget stop kept it. If the plan you wrote is still there, **run the audit on this path in Step 6B's order**: (1) `fix-delta --snapshot` before the first edit — a snapshot taken after an edit records it, and the audit cannot see it; (2) apply the fixes; (3) record the outcomes with `review findings --outcomes`, passing the saved artifact under `.qwen/reviews/` as `--input` (`findings-in.json` is swept) and writing the rebuilt artifact to the same `--out` path Step 6B uses — a path in the review's own `.qwen/tmp` family, which the capture leaves out; anywhere else the file lands in the hunks; (4) run Step 6B's audit command block as written — `fix-delta --since`, `agent-prompt --role fix-audit … --hunks … --batch`, `emit-workflow --batch` — with the surviving plan as `--plan` and **that rebuilt artifact** as `--findings`, never the saved artifact itself, whose outcomes (if any) predate these edits. Everything else stays: when the review has a findings artifact, record the outcomes into it the same way (step 3 above, whether or not the audit runs), and re-issue the `report_findings` call with the outcomes, exactly as Step 6B prescribes, rather than leaving the list, the tree, and the client display disagreeing about what was applied. Under `--topology minimal`, decline per Step 3M instead — the findings are unverified; point at `/review --fix`, which re-runs at medium with verified findings.
 
 If the user responds with "post comments" (or similar intent like "yes post them", "publish comments"), proceed directly to Step 7 using the findings already collected — do NOT re-run Steps 1-6. Under `--topology minimal`, decline per Step 3M instead — the findings are unverified, and the `--user-authorized` fast path would post them on the ask alone.
 

package/bundled/review/references/persistence.md

@@ -76,12 +76,11 @@ The automatic `reviewProfile: "docs-nav"` pass never updates or promotes this ca
 
 If reviewing a PR **at high effort**, update the review cache for incremental review support. Low and medium reviews must NOT write it, and neither must a `--topology minimal` run at any effort — 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 local or file-path review at high effort writes its cache the same way, from the capture's candidate.** **Before promoting, CHECK the candidate is this round's own:** read the file at the plan's `cacheCandidatePath` and compare its `stateId` to the plan's `cacheCandidateStateId` — the path is stable per target and local/file reviews take no lease, so a concurrent same-target run overwrites the file mid-round, and promoting the foreign candidate would anchor the next round's "no changes" to a tree this round never reviewed. A mismatch (or an absent `cacheCandidateStateId` field on a plan that published a path) is treated exactly like a withheld candidate: skip the cache write and say so. `capture-local` wrote this round's content anchor to the plan's `cacheCandidatePath` (`.qwen/tmp/qwen-review-<target>-cache-candidate.json`): the hashed per-file state and HEAD of exactly what was captured, deterministic, not yours to recompute. Read that file, add the ledger fields — `lastReviewDate`, `round`, `findingsCount`, `verdict`, and `findings[]` under the same id-carrying rules as the PR cache below — and write the merged object to the path the capture named in its plan, `cachePath` — **read that field, do not compute the name**, for the reason the incremental bullet in Step 1 gives: `target` is derived inside the command and `safeTarget` is not hand-reproducible. **The fail-closed conditions here are keyed to the PR cache's marker rule below — one definition, read twice.** Do NOT apply that rule's literal CHECK here: it keys on a `sha` inside the posted review's `qwen-review-ledger` marker, and a local round posts nothing and has no marker to read — a literal check would skip this write on every round and the feature would never persist. What this write takes from that rule is its WITHHOLDING CONDITIONS, applied as conditions on this round's own caps. For a local or file-path round the rule is a POSITIVE one, deliberately — and its fail-closed half is deliberately NOT a list: the list that lived here was "completed" three times, and each time a fourth shape walked through it (the last one an Uncoverable chunk and a whiffed lens, which withheld the PR marker's `sha` but never this write). **Write the cache only when every Critical this round raised carries a confirmed disposition: fixed, or confirmed-standing and recorded in `findings[]` under an id — and skip this write under any condition that would withhold the PR marker's `sha` in the rule below, plus the one local-only condition the marker cannot see: a non-empty `skippedFiles` in the capture (skipped content is in no diff and no hash).** At the time of writing those conditions are: `cannotTellCriticals` (a verifier that returned CANNOT-TELL, or a deadline stop or timed-out batch that never returned one), an Uncoverable chunk, the context-unavailable state, `scopeUnproven` (a chunk nobody read, an idle or blind agent), a finding still marked `— [unverified]`, the deterministic gates, and any `unreviewedDimensions` entry other than a depth-only build-and-test one (a whiffed lens withholds the marker's `sha`, so it withholds this write). The examples are the set as written, not the gate: the gate is the marker paragraph's withholding set — if it changes, this write changes with it, because a second hand-copied list here is how they drifted once already. Anything else withholds the candidate and says so. The reason is one reason, and it is why the rule is stated as a rule: the anchor's whole claim is "the next round may skip this", and a claim nobody ruled on is exactly what the next round must not skip — the round after it stops decided over a Critical that was never verified: skipped content is in no diff and no hash, so a candidate promoted over it would anchor the next round's "no changes" past work this round could not read. A run that ended with unreviewed or undecided scope skips this write and says so, because the candidate would anchor the next round's skip past scope nobody reviewed. (A capture that detected a mid-capture tree change — or a tracked path carrying a visibility bit, or an enumeration of them that failed — withholds the candidate itself and says so; then there is nothing to promote.) Low and medium local reviews must NOT write it, for the PR cache's exact reason.
+**The write is one command, for PR and local alike — never a hand-copied JSON.** **On a LOCAL or file-path round, pass `--state-id <the plan's cacheCandidateStateId>` so the command CHECKS the candidate is this round's own at the moment it reads it** — the path is stable per target and local/file reviews take no lease, so a concurrent same-target run overwrites the file mid-round, and promoting the foreign candidate would anchor the next round's "no changes" to a tree this round never reviewed; a check you made yourself, reading the file minutes before the command reads it again, would not bind the bytes the command promotes. The command's refusal (or an absent `cacheCandidateStateId` field on a plan that published a path) is treated exactly like a withheld candidate: skip the cache write and say so. **A PR round has no such check**: `fetch-pr` holds the worktree lease for its PR, which already excludes a concurrent same-target run, so its candidate carries no `stateId` and its plan no `cacheCandidateStateId` — their absence there is the normal state, not a withheld candidate. Both captures write a deterministic candidate beside the plan (`cacheCandidatePath` in the plan report: `fetch-pr` records the per-file `(base, head)` blob pairs plus the commit anchor; `capture-local` the hashed per-file working-tree state plus HEAD). A candidate is not yours to recompute or transcribe — a per-file map routed through your output is a copy job that fails silently, and a dropped or mangled pair reads downstream as a verdict it is not. So: write ONLY the small ledger file `.qwen/tmp/qwen-review-<target>-ledger-<timestamp>.json` — `<timestamp>` is the `<YYYY-MM-DD>-<HHMMSS>` you are about to put in this round's report filename, and it is a per-round name for the same reason that one is, under the `qwen-review-<target>-` prefix Step 9's `cleanup` sweeps. Not the tree's `stateId`: two concurrent rounds over an unchanged tree compute the SAME one, so it would name one file for both and the second round's findings would ride the first round's promotion — the concurrency this paragraph already assumes, against the half `--state-id` cannot see (the anchor matches; the verdict and `findings[]` are the other round's) — with this round's `round`, `findingsCount`, `verdict`, and `findings[]` (id rules below). **No `lastModelId`**: the capture already recorded the identity the runtime published, provider-qualified, in the candidate — and `cache-commit` lets the candidate win it. A hand-carried one would be the bare model token (`YOUR_MODEL_ID`), which two provider configurations exposing a single model name share, so the same-model contract the anchor rests on would pass between them, then run `"${QWEN_CODE_CLI:-qwen}" review cache-commit --candidate <the plan's cacheCandidatePath> --ledger <that file> --out <the cache path for this target>` — plus `--state-id <the plan's cacheCandidateStateId>` on a LOCAL or file-path round — **from the main checkout, with all three paths resolved against it** — every one of them is main-checkout-relative (the candidate is where the capture wrote it, and the cache must outlive the worktree Step 9 deletes; a cache written inside the worktree is thrown away with it, and this machine silently loses rebase survival) (`pr-<n>.json` / `local.json` / the file-review's target). The command merges mechanically, candidate fields winning every collision, and writes atomically. **Where that path comes from differs by flow, and only one of them publishes it**: a LOCAL or file-path round reads it off the plan's `cachePath` — the capture derives the target and `safeTarget` is not hand-reproducible, so the name is not yours to spell — while the PR flow's plan carries no such field and the name is the one this section already gives, `.qwen/review-cache/pr-<n>.json`, which you already know from the PR number. Do not look for `cachePath` on a `fetch-pr` report; it has none, and treating its absence as a reason to skip the write would lose the PR cache entirely. A PR plan with **no** `cacheCandidatePath` — a degraded capture — falls back to hand-writing the template below, anchor fields only as accurate as what Step 1 recorded. A LOCAL or file-path capture under a runtime that published no model identity still writes its candidate, without `lastModelId` — run `cache-commit` exactly the same way: it persists this round's findings ledger and writes no anchor (it says so), so the next round still re-rules every open entry and reviews in full. A LOCAL or file-path plan with no `cacheCandidatePath` — the capture withheld it because the tree moved mid-capture, a tracked path carried a visibility bit, or the write itself was refused — skips the cache write and says so: the template below is PR-shaped (`lastCommitSha`, no `files`/`stateId`), the local gate refuses it unread, and there is nothing to promote. The same fail-closed rule applies to BOTH flows, and for a LOCAL round it is stated in this paragraph in full — **do not go looking for a `sha` to check in the PR cache's marker rule below**, which keys on a `sha` inside a posted review's `qwen-review-ledger` comment: a local round posts nothing and has no marker to check, so read literally it would skip this write on every round and the feature would never persist. The rule: a run that ended with unreviewed or undecided scope skips the write entirely and says so, because the candidate would anchor the next round's skip past scope nobody reviewed. Low and medium reviews must NOT write it, for the reason above. **A non-empty `skippedFiles` in the capture is fail-closed for this write, both flows**: skipped content is in no diff and no hash, so a candidate promoted over it would anchor the next round's "no changes" past work this round could not read. **The fail-closed conditions here are keyed to the PR cache's marker rule below — one definition, read twice.** Do NOT apply that rule's literal CHECK here: it keys on a `sha` inside the posted review's `qwen-review-ledger` marker, and a local round posts nothing and has no marker to read — a literal check would skip this write on every round and the feature would never persist. What this write takes from that rule is its WITHHOLDING CONDITIONS, applied as conditions on this round's own caps. For a local or file-path round the rule is a POSITIVE one, deliberately — and its fail-closed half is deliberately NOT a list: the list that lived here was "completed" three times, and each time a fourth shape walked through it (the last one an Uncoverable chunk and a whiffed lens, which withheld the PR marker's `sha` but never this write). **Write the cache only when every Critical this round raised carries a confirmed disposition: fixed, or confirmed-standing and recorded in `findings[]` under an id — and skip this write under any condition that would withhold the PR marker's `sha` in the rule below, plus the one local-only condition the marker cannot see: a non-empty `skippedFiles` in the capture (skipped content is in no diff and no hash).** At the time of writing those conditions are: `cannotTellCriticals` (a verifier that returned CANNOT-TELL, or a deadline stop or timed-out batch that never returned one), an Uncoverable chunk, the context-unavailable state, `scopeUnproven` (a chunk nobody read, an idle or blind agent), a finding still marked `— [unverified]`, the deterministic gates, and any `unreviewedDimensions` entry other than a depth-only build-and-test one (a whiffed lens withholds the marker's `sha`, so it withholds this write). The examples are the set as written, not the gate: the gate is the marker paragraph's withholding set — if it changes, this write changes with it, because a second hand-copied list here is how they drifted once already. Anything else withholds the candidate and says so. **And these two, which complete the list**: a finding still marked `— [unverified]`, and an undecided blocker — a Critical whose verifier never returned, from a deadline stop or a timed-out batch. Neither enters `findings[]` (only confirmed findings do) and neither reads as "unreviewed scope", so without naming them a round promotes the anchor over a claim nobody ruled on and the round after it stops decided. (A capture that detected a mid-capture tree change — or a tracked path carrying a visibility bit, or an enumeration of them that failed — withholds the candidate itself and says so; then there is nothing to promote.)
 
 **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:
+1. Write the ledger file and run `cache-commit` as described above. **Fallback only** — when the plan carries no `cacheCandidatePath` — create `.qwen/review-cache/` and hand-write `.qwen/review-cache/pr-<number>.json` with:
 
    ```json
    {
@@ -108,4 +107,4 @@ 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 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 list opens with an invisible `<!-- qwen-review-deferred -->` marker so later tooling can locate the block across rounds, and the findings artifact carries each deferred finding's full content under its `D<round>-<n>` id — the CI review job uploads it and the report as run artifacts (what the overflow count's "see the run report" pointer resolves to — kept for the artifact's 90-day retention window, not forever), and a local run's saved artifact under `.qwen/reviews/` holds the same — so an entry past the rendered cap, or in a list the budget trimmed, keeps a recoverable record even though the PR page never shows it. 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.
+2. 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-3RXPTLCS.js → MaxSizedBox-4MLWQHF3.js}

@@ -8,43 +8,43 @@ import {
 import "./chunk-FXLEANJX.js";
 import "./chunk-SV5PQVQE.js";
 import "./chunk-4GG4IOFX.js";
-import "./chunk-NHSGF64C.js";
 import "./chunk-5QWWOFGG.js";
+import "./chunk-NHSGF64C.js";
 import "./chunk-47ECGEJC.js";
 import "./chunk-2MIN6GRR.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-RKUWKYED.js";
-import "./chunk-3JSIWFNA.js";
+import "./chunk-XHHUGXYW.js";
 import "./chunk-GELRJXE2.js";
 import "./chunk-32CM56LO.js";
 import "./chunk-A45QOTO4.js";
 import "./chunk-LJZSMWOH.js";
-import "./chunk-H4W6TJFJ.js";
+import "./chunk-RONRTFAQ.js";
 import "./chunk-ZPJWUGCS.js";
 import "./chunk-DZJK32EE.js";
-import "./chunk-4INF7OYV.js";
-import "./chunk-NXZD3VNX.js";
-import "./chunk-FLRFAPDA.js";
-import "./chunk-GGUOO2XC.js";
-import "./chunk-VIA4STCR.js";
-import "./chunk-WVNCMGAO.js";
+import "./chunk-ELY2U74S.js";
+import "./chunk-TL7DSR47.js";
+import "./chunk-RCL6OXZC.js";
+import "./chunk-7RCAMBLN.js";
+import "./chunk-YCCBLTSL.js";
+import "./chunk-6FURC4LI.js";
 import "./chunk-6URMIIZO.js";
 import "./chunk-BCTEBRTF.js";
-import "./chunk-SRZA7OU4.js";
-import "./chunk-TS4Y2MHO.js";
-import "./chunk-E3TLOFX7.js";
+import "./chunk-MMCGLNPP.js";
+import "./chunk-CGREZDGO.js";
+import "./chunk-EUHSEMO4.js";
 import "./chunk-WKLD4E5L.js";
-import "./chunk-ZHQSWNO6.js";
+import "./chunk-AN62TPO6.js";
 import "./chunk-V2XJJTAB.js";
-import "./chunk-U5DPG7JW.js";
+import "./chunk-AYTI24XN.js";
 import "./chunk-MFWTREVT.js";
 import "./chunk-VCJNMND5.js";
 import "./chunk-YDERQ7ZV.js";
-import "./chunk-LISITUEH.js";
+import "./chunk-26KGIWIW.js";
 import "./chunk-PPDPLILM.js";
 import "./chunk-FTKXJMQV.js";
 import "./chunk-S5BHLTHK.js";
-import "./chunk-RL2HSTEB.js";
+import "./chunk-SYZPPX3O.js";
 import "./chunk-27CVFKVI.js";
 import "./chunk-VU6JX6MN.js";
 import "./chunk-GOFAQQZA.js";
@@ -55,15 +55,15 @@ import "./chunk-7TK2HU3T.js";
 import "./chunk-YNURCIW7.js";
 import "./chunk-KNMT4XIN.js";
 import "./chunk-HORVWHWX.js";
-import "./chunk-6N2PJAZG.js";
+import "./chunk-PX2ZOOGQ.js";
 import "./chunk-JBUMBQAO.js";
 import "./chunk-5EZRLTLQ.js";
 import "./chunk-QHWCP53L.js";
 import "./chunk-E4YH24E6.js";
 import "./chunk-FDOMQENS.js";
 import "./chunk-SLQ4C6GN.js";
-import "./chunk-TFBQ5CKI.js";
-import "./chunk-N4VKU36J.js";
+import "./chunk-QNEBHC2E.js";
+import "./chunk-465XOJLQ.js";
 import "./chunk-U6H3XTFA.js";
 import "./chunk-6PVPNMXU.js";
 import "./chunk-NLHFXAC4.js";
@@ -73,7 +73,7 @@ import "./chunk-SK3RZOPS.js";
 import "./chunk-YVD6XEO3.js";
 import "./chunk-ELRMZTPF.js";
 import "./chunk-6C3D7BKK.js";
-import "./chunk-BVFBDXI2.js";
+import "./chunk-TPFV5YZK.js";
 import "./chunk-MNU36NGH.js";
 import "./chunk-QXQMBRGL.js";
 import "./chunk-TWPJO254.js";
@@ -83,22 +83,21 @@ import "./chunk-O6GEWCJA.js";
 import "./chunk-I3K2QRZ5.js";
 import "./chunk-5ZPFMX67.js";
 import "./chunk-RSKMN2JH.js";
-import "./chunk-WVNML4HH.js";
+import "./chunk-VW33WARJ.js";
 import "./chunk-VNTJJ4WQ.js";
 import "./chunk-BQMSZSG6.js";
-import "./chunk-LNUQA3OE.js";
-import "./chunk-47C3HPMW.js";
+import "./chunk-CVRZNFXO.js";
+import "./chunk-O5YL6KSX.js";
 import "./chunk-JX6XHPTX.js";
 import "./chunk-QCG3JVIW.js";
-import "./chunk-JE3J5HFM.js";
+import "./chunk-KAOHUUM7.js";
 import "./chunk-P6OZD6V2.js";
-import "./chunk-QKXZOHHQ.js";
+import "./chunk-LDURD6EP.js";
 import "./chunk-BKVPLSEI.js";
-import "./chunk-GG3MO6NO.js";
+import "./chunk-PWGMHXIV.js";
 import "./chunk-H7VK3YDS.js";
 import "./chunk-S6LOFUVP.js";
 import "./chunk-Z72PLR74.js";
-import "./chunk-GC3J5W2O.js";
 import "./chunk-OK6PQW7O.js";
 import "./chunk-NAVJD2PQ.js";
 import "./chunk-Z27N2QYZ.js";
@@ -110,20 +109,23 @@ import "./chunk-DJ2GSRLV.js";
 import "./chunk-U6673AVW.js";
 import "./chunk-VXQQCZPP.js";
 import "./chunk-KP2FHIFR.js";
-import "./chunk-OU4ZCLGJ.js";
+import "./chunk-242INZ6Y.js";
 import "./chunk-KBVGO6H4.js";
-import "./chunk-MZRJ2JJS.js";
+import "./chunk-HDSI3RDN.js";
 import "./chunk-VBT4BMCQ.js";
-import "./chunk-NNN2PKPV.js";
+import "./chunk-PYYPSK6Q.js";
 import "./chunk-CFMZLE3L.js";
 import "./chunk-OJSU46VD.js";
 import "./chunk-HD7O6WLV.js";
 import "./chunk-GHKVBSBY.js";
+import "./chunk-Q4FJVWI4.js";
+import "./chunk-CLNDQINM.js";
 import "./chunk-GMTJ3YQW.js";
 import "./chunk-5ETULJLP.js";
+import "./chunk-GC3J5W2O.js";
 import "./chunk-WZAD4ZNJ.js";
 import "./chunk-XASQGHGO.js";
-import "./chunk-4FCWKBOC.js";
+import "./chunk-ALTMZEBU.js";
 import "./chunk-XZA32HII.js";
 import "./chunk-DYPTD5P5.js";
 import "./chunk-HHJLM3WQ.js";