@qwen-code/qwen-code 0.20.0-nightly.20260722.b98306b7e → 0.20.0

package/bundled/qc-helper/docs/configuration/settings.md

@@ -748,7 +748,7 @@ For sandbox image selection, precedence is:
 | `--extensions`               | `-e`  | Specifies a list of extensions to use for the session.                                                                                                                                                                                       | Extension names                                | If not provided, all available extensions are used. Use the special term `qwen -e none` to disable all extensions. Example: `qwen -e my-extension -e my-other-extension`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
 | `--list-extensions`          | `-l`  | Lists all available extensions and exits.                                                                                                                                                                                                    |                                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `--proxy`                    |       | Sets the proxy for the CLI.                                                                                                                                                                                                                  | Proxy URL                                      | Example: `--proxy http://localhost:7890`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-| `--include-directories`      |       | Includes additional directories in the workspace for multi-directory support.                                                                                                                                                                | Directory paths                                | Can be specified multiple times or as comma-separated values. Example: `--include-directories /path/to/project1,/path/to/project2` or `--include-directories /path/to/project1 --include-directories /path/to/project2`                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `--include-directories`      |       | Includes additional directories in the workspace for multi-directory support.                                                                                                                                                                | Directory paths                                | Can be specified multiple times or as comma-separated values. 5 directories can be added at maximum. Example: `--include-directories /path/to/project1,/path/to/project2` or `--include-directories /path/to/project1 --include-directories /path/to/project2`                                                                                                                                                                                                                                                                                                                                                                                                |
 | `--screen-reader`            |       | Enables screen reader mode, which adjusts the TUI for better compatibility with screen readers.                                                                                                                                              |                                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `--version`                  |       | Displays the version of the CLI.                                                                                                                                                                                                             |                                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `--openai-logging`           |       | Enables logging of OpenAI API calls for debugging and analysis.                                                                                                                                                                              |                                                | This flag overrides the `enableOpenAILogging` setting in `settings.json`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |

package/bundled/qc-helper/docs/features/auto-mode.md

@@ -175,8 +175,8 @@ This is useful for production or high-security environments where you
 want defense-in-depth: even seemingly harmless commands are reviewed by
 the classifier before execution. The trade-off is added latency (~300ms
 per read-only shell call) and reliance on classifier availability — if
-the classifier API is unreachable, read-only shell commands will also require
-manual approval.
+the classifier API is unreachable, read-only shell commands will also be
+blocked (fail-closed).
 
 > [!note]
 >
@@ -187,13 +187,18 @@ manual approval.
 
 ## Reading the decision
 
-When the classifier blocks an action, the tool call fails with:
+When the classifier blocks an action, the tool call fails with one of
+the following error texts:
 
 - **`Blocked by auto mode policy: <reason>`** —
   the classifier judged the action unsafe. The reason comes from Stage
   2 of the classifier.
+- **`Auto mode classifier unavailable; action blocked for safety`** —
+  the classifier API was unreachable, timed out, or returned an
+  un-parseable response. This is fail-closed behavior: when in doubt,
+  block.
 
-This message is followed by a trailing guidance line telling the agent
+Both messages are followed by a trailing guidance line telling the agent
 that the **denied action specifically** must not be completed through
 another tool, shell indirection, generated script, alias, symlink,
 config change, hook, command file, MCP configuration, encoded payload,
@@ -214,24 +219,16 @@ want non-English reasons, add a hint like
 
 Auto Mode protects you from getting stuck:
 
-- If the classifier API is unreachable, times out, exceeds its context window,
-  or returns an invalid response, the current action immediately falls back to
-  manual approval. The confirmation recommends Default Mode and offers
-  **Switch to Default Mode and allow once** alongside Allow once and Reject.
-  Switching affects only the current runtime session; it does not change your
-  saved settings.
-
 - After **3 consecutive policy blocks** the next tool call falls back to
   the standard manual-approval prompt. This catches the case where the
   agent keeps trying minor variants of a forbidden command.
-- After **2 consecutive unavailable** results (classifier API failures),
-  later calls skip the known-broken classifier and go directly to manual
-  approval. The first unavailable result already asks; the threshold avoids
-  repeatedly waiting for classifier retries.
-
-The session stays in Auto Mode unless you explicitly select the switch option.
-Only the fallback call goes through manual approval. The counters reset when
-you approve the fallback call or switch modes.
+- After **2 consecutive unavailable** results (classifier API failures)
+  the next tool call also falls back. This avoids waiting on a broken
+  classifier.
+
+The session itself stays in Auto Mode — only the single fallback call
+goes through manual approval. The counters reset when you approve the
+fallback call or switch modes.
 
 If you find yourself constantly hitting fallback, the most likely causes
 are an outage on the classifier API or hints that need tuning. Switch to

package/bundled/qc-helper/docs/features/commands.md

@@ -49,7 +49,6 @@ Commands for adjusting interface appearance and work environment.
 | → `detail`           | Show per-item context usage breakdown                                                                                                                                             | `/context detail`                                                                 |
 | `/history`           | Control history display preferences and visibility                                                                                                                                | `/history collapse-on-resume`, `/history expand-on-resume`, `/history expand-now` |
 | `/diff`              | Open an interactive diff viewer showing uncommitted changes and per-turn diffs. Use ←/→ to switch between current git diff and individual conversation turns, ↑/↓ to browse files | `/diff`                                                                           |
-| `/log`               | Open a commit history viewer for the workspace (Web Shell only)                                                                                                                   | `/log`                                                                            |
 | `/theme`             | Change Qwen Code visual theme                                                                                                                                                     | `/theme`                                                                          |
 | `/vim`               | Turn input area Vim editing mode on/off                                                                                                                                           | `/vim`                                                                            |
 | `/voice`             | Toggle voice dictation input                                                                                                                                                      | `/voice`, `/voice hold`, `/voice tap`, `/voice off`, `/voice status`              |
@@ -311,59 +310,6 @@ In headless (`--prompt`) or non-interactive contexts, `/diff` prints a plain-tex
    +3  -2  README.md
 ```
 
-**Web Shell:** In the Web Shell UI (`qwen serve`), `/diff` opens a graphical diff dialog. A tab bar at the top lets you switch between the **Changes** view and the **History** view (`/log`).
-
-#### History Viewer (`/log`) — Web Shell only
-
-The `/log` command opens a commit history browser for the current workspace. It is available only in the Web Shell UI; the CLI/TUI does not have this command.
-
-**How it works:**
-
-`/log` opens a dialog listing commits in reverse chronological order (newest first). Each row shows:
-
-- Short SHA (monospace, with a copy button for the full SHA)
-- Commit subject (single line)
-- Author name and relative time (e.g. "2h ago")
-- Branch/tag ref labels, when present
-- A merge icon (⎇) for merge commits
-
-Click a commit row to expand its details on demand:
-
-- Full commit message body
-- File change statistics (files changed, lines added/removed, per-file breakdown)
-
-Use **Load more** at the bottom to fetch the next page of commits (50 per page).
-
-**Example:**
-
-```
-┌─ History ──────────────────────────── 50 commits ─ ✕ ┐
-│                                                       │
-│  a1b2c3d  feat(cli): add --json flag        2h ago   │
-│           wenshao                                    │
-│                                                       │
-│  e4f5g6h  fix(core): handle null config     5h ago   │
-│           dev · main  v1.2.0                         │
-│                                                       │
-│ ▼ 789abcd  refactor: simplify parser        1d ago   │
-│   ┌─────────────────────────────────────────────┐    │
-│   │  Broke the monolithic parse() into smaller  │    │
-│   │  functions for readability.                 │    │
-│   │                                             │    │
-│   │  3 files · +45 −12                          │    │
-│   │   +30 −8   src/parser.ts                    │    │
-│   │   +10 −2   src/utils.ts                     │    │
-│   │   +5  −2   test/parser.test.ts              │    │
-│   └─────────────────────────────────────────────┘    │
-│                                                       │
-│              [ Load more ]                            │
-└───────────────────────────────────────────────────────┘
-```
-
-> [!note]
->
-> `/log` requires a git repository workspace. If the workspace is not a git repository or has no commits, the dialog shows a placeholder message.
-
 ### 1.9 Information, Settings, and Help
 
 Commands for obtaining information and performing system settings.

package/bundled/qc-helper/docs/features/sub-agents.md

@@ -16,23 +16,14 @@ Subagents are independent AI assistants that:
 
 In addition to named subagents, Qwen Code supports **forking** — selected explicitly with `subagent_type: "fork"` (available in interactive sessions). A fork inherits the parent's full conversation context and runs detached in the background. Omitting `subagent_type` does **not** fork; it launches the general-purpose subagent. Top-level named subagents run in the background by default and deliver their results through completion notifications. Set `run_in_background: false` when the current turn must wait for the result inline.
 
-## Fork Context with `fork_turns`
-
-Only `subagent_type: "fork"` accepts `fork_turns`:
-
-- Omitting it or using `all` inherits the full parent conversation.
-- A positive integer string such as `"3"` inherits the most recent three real user turns.
-
-Tool responses and pure system reminders do not count as user turns. Regular named subagents and agent-team teammates do not accept `fork_turns`; they keep their separate conversation context.
-
 ### How Fork Differs from Named Subagents
 
-|               | Named Subagent                                                 | Fork Subagent                                                                           |
-| ------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
-| Context       | Starts fresh with no parent conversation history               | Inherits all parent history by default; `fork_turns` can select a bounded recent window |
-| System prompt | Uses its own configured prompt                                 | Uses parent's exact system prompt (for cache sharing)                                   |
-| Execution     | Background by default; supports an explicit foreground opt-out | Always detached; parent continues immediately                                           |
-| Use case      | Specialized tasks (testing, docs)                              | Parallel tasks that need the current context                                            |
+|               | Named Subagent                                                 | Fork Subagent                                         |
+| ------------- | -------------------------------------------------------------- | ----------------------------------------------------- |
+| Context       | Starts fresh, no parent history                                | Inherits parent's full conversation history           |
+| System prompt | Uses its own configured prompt                                 | Uses parent's exact system prompt (for cache sharing) |
+| Execution     | Background by default; supports an explicit foreground opt-out | Always detached; parent continues immediately         |
+| Use case      | Specialized tasks (testing, docs)                              | Parallel tasks that need the current context          |
 
 ### When Fork is Used
 
@@ -59,7 +50,7 @@ Fork children cannot create further forks. This is enforced at runtime — if a
 
 - **Task Specialization**: Create agents optimized for specific workflows (testing, documentation, refactoring, etc.)
 - **Context Isolation**: Keep specialized work separate from your main conversation
-- **Context Inheritance**: Fork subagents inherit the full conversation by default and can select a bounded number of recent parent turns
+- **Context Inheritance**: Fork subagents inherit the full conversation for context-heavy parallel tasks
 - **Prompt Cache Sharing**: Fork subagents share the parent's cache prefix, reducing token costs
 - **Reusability**: Save and reuse agent configurations across projects and sessions
 - **Controlled Access**: Limit which tools each agent can use for security and focus

package/bundled/qc-helper/docs/integration-github-action.md

@@ -96,7 +96,7 @@ This workflow acts as a central dispatcher for Qwen Code CLI, routing requests t
 
 ### Issue Triage
 
-This action can be used to triage GitHub Issues automatically or on demand. For a working issue triage setup, see the [Qwen triage workflow](https://github.com/QwenLM/qwen-code/blob/main/.github/workflows/qwen-triage.yml).
+This action can be used to triage GitHub Issues automatically or on a schedule. For a working issue triage setup, see the [automated issue triage workflow](https://github.com/QwenLM/qwen-code/blob/main/.github/workflows/qwen-automated-issue-triage.yml).
 
 ### Pull Request Review
 
@@ -112,32 +112,32 @@ This type of action can be used to invoke a general-purpose, conversational Qwen
 
 <!-- BEGIN_AUTOGEN_INPUTS -->
 
-- <a name="__input_qwen_api_key"></a><a href="#user-content-__input_qwen_api_key"><code>qwen_api_key</code></a>: _(Optional)_ The API key for the Qwen API.
+- <a name="__input_qwen_api_key"></a><a href="#user-content-__input_qwen_api_key"><code>qwen*api_key</code></a>: *(Optional)\_ The API key for the Qwen API.
 
-- <a name="__input_qwen_cli_version"></a><a href="#user-content-__input_qwen_cli_version"><code>qwen_cli_version</code></a>: _(Optional, default: `latest`)_ The version of the Qwen Code CLI to install. Can be "latest", "preview", "nightly", a specific version number, or a git branch, tag, or commit. For more information, see [Qwen Code CLI releases](https://github.com/QwenLM/qwen-code-action/blob/main/docs/releases.md).
+- <a name="__input_qwen_cli_version"></a><a href="#user-content-__input_qwen_cli_version"><code>qwen*cli_version</code></a>: *(Optional, default: `latest`)\_ The version of the Qwen Code CLI to install. Can be "latest", "preview", "nightly", a specific version number, or a git branch, tag, or commit. For more information, see [Qwen Code CLI releases](https://github.com/QwenLM/qwen-code-action/blob/main/docs/releases.md).
 
-- <a name="__input_qwen_debug"></a><a href="#user-content-__input_qwen_debug"><code>qwen_debug</code></a>: _(Optional)_ Enable debug logging and output streaming.
+- <a name="__input_qwen_debug"></a><a href="#user-content-__input_qwen_debug"><code>qwen*debug</code></a>: *(Optional)\_ Enable debug logging and output streaming.
 
-- <a name="__input_qwen_model"></a><a href="#user-content-__input_qwen_model"><code>qwen_model</code></a>: _(Optional)_ The model to use with Qwen Code.
+- <a name="__input_qwen_model"></a><a href="#user-content-__input_qwen_model"><code>qwen*model</code></a>: *(Optional)\_ The model to use with Qwen Code.
 
 - <a name="__input_prompt"></a><a href="#user-content-__input_prompt"><code>prompt</code></a>: _(Optional, default: `You are a helpful assistant.`)_ A string passed to the Qwen Code CLI's [`--prompt` argument](https://github.com/QwenLM/qwen-code-action/blob/main/docs/cli/configuration.md#command-line-arguments).
 
 - <a name="__input_settings"></a><a href="#user-content-__input_settings"><code>settings</code></a>: _(Optional)_ A JSON string written to `.qwen/settings.json` to configure the CLI's _project_ settings.
   For more details, see the documentation on [settings files](https://github.com/QwenLM/qwen-code-action/blob/main/docs/cli/configuration.md#settings-files).
 
-- <a name="__input_use_qwen_code_assist"></a><a href="#user-content-__input_use_qwen_code_assist"><code>use_qwen_code_assist</code></a>: _(Optional, default: `false`)_ Whether to use Code Assist for Qwen Code model access instead of the default Qwen Code API key.
+- <a name="__input_use_qwen_code_assist"></a><a href="#user-content-__input_use_qwen_code_assist"><code>use*qwen_code_assist</code></a>: *(Optional, default: `false`)\_ Whether to use Code Assist for Qwen Code model access instead of the default Qwen Code API key.
   For more information, see the [Qwen Code CLI documentation](https://github.com/QwenLM/qwen-code-action/blob/main/docs/cli/authentication.md).
 
-- <a name="__input_use_vertex_ai"></a><a href="#user-content-__input_use_vertex_ai"><code>use_vertex_ai</code></a>: _(Optional, default: `false`)_ Whether to use Vertex AI for Qwen Code model access instead of the default Qwen Code API key.
+- <a name="__input_use_vertex_ai"></a><a href="#user-content-__input_use_vertex_ai"><code>use*vertex_ai</code></a>: *(Optional, default: `false`)\_ Whether to use Vertex AI for Qwen Code model access instead of the default Qwen Code API key.
   For more information, see the [Qwen Code CLI documentation](https://github.com/QwenLM/qwen-code-action/blob/main/docs/cli/authentication.md).
 
 - <a name="__input_extensions"></a><a href="#user-content-__input_extensions"><code>extensions</code></a>: _(Optional)_ A list of Qwen Code CLI extensions to install.
 
-- <a name="__input_upload_artifacts"></a><a href="#user-content-__input_upload_artifacts"><code>upload_artifacts</code></a>: _(Optional, default: `false`)_ Whether to upload artifacts to the github action.
+- <a name="__input_upload_artifacts"></a><a href="#user-content-__input_upload_artifacts"><code>upload*artifacts</code></a>: *(Optional, default: `false`)\_ Whether to upload artifacts to the github action.
 
-- <a name="__input_use_pnpm"></a><a href="#user-content-__input_use_pnpm"><code>use_pnpm</code></a>: _(Optional, default: `false`)_ Whether or not to use pnpm instead of npm to install qwen-code-cli
+- <a name="__input_use_pnpm"></a><a href="#user-content-__input_use_pnpm"><code>use*pnpm</code></a>: *(Optional, default: `false`)\_ Whether or not to use pnpm instead of npm to install qwen-code-cli
 
-- <a name="__input_workflow_name"></a><a href="#user-content-__input_workflow_name"><code>workflow_name</code></a>: _(Optional, default: `${{ github.workflow }}`)_ The GitHub workflow name, used for telemetry purposes.
+- <a name="__input_workflow_name"></a><a href="#user-content-__input_workflow_name"><code>workflow*name</code></a>: *(Optional, default: `${{ github.workflow }}`)\_ The GitHub workflow name, used for telemetry purposes.
 
 <!-- END_AUTOGEN_INPUTS -->
 

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

@@ -66,7 +66,7 @@ qwen serve
 
 The default bind is `127.0.0.1:4170`. Bearer auth is **off** on loopback so local development "just works". 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.
 
-**Open the Web Shell UI.** Browse to `http://127.0.0.1:4170/` (or start the daemon with `qwen serve --open` to launch it automatically) for the full browser terminal — chat, diffs, commit history, tool calls, and permission prompts. The UI is served at the daemon root on the same origin as the API. The rest of this guide uses raw HTTP so you can script against the API directly.
+**Open the Web Shell UI.** Browse to `http://127.0.0.1:4170/` (or start the daemon with `qwen serve --open` to launch it automatically) for the full browser terminal — chat, diffs, tool calls, and permission prompts. The UI is served at the daemon root on the same origin as the API. The rest of this guide uses raw HTTP so you can script against the API directly.
 
 ### 2. Sanity-check it
 
@@ -397,7 +397,6 @@ Notes:
 | `--mcp-client-budget <n>`               | —               | Positive integer cap on live MCP clients. When `mcp_workspace_pool` is advertised, the cap and transports are shared per workspace runtime; when the tag is absent, the legacy per-session manager enforces it. Combine with `--mcp-budget-mode`. When unset, no accounting-driven enforcement (but `GET /workspace/mcp` still reports `clientCount`). Distinct from claude-code's `MCP_SERVER_CONNECTION_BATCH_SIZE`, which gates startup concurrency rather than total live clients. Pre-flight `caps.features.mcp_guardrails` and `caps.features.mcp_workspace_pool`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | `--mcp-budget-mode <m>`                 | `warn` / `off`  | How `--mcp-client-budget` is enforced. `warn` (default when budget set): no refusal, snapshot's `budgets[0].status` flips to `warning` at ≥75% of budget. `enforce`: connects past the cap are refused, per-server cell shows `disabledReason: 'budget'`, deterministic by `mcpServers` declaration order. `off` (default when budget unset): pure observability. Boot rejects `enforce` without a budget.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | `--http-bridge`                         | `true`          | Stage 1 mode: production attempts to preheat one primary `qwen --acp` child for compatibility and retries on first use after failure, while each trusted secondary can start one child on demand. Sessions targeting a runtime multiplex onto its child via ACP `newSession()`; untrusted secondaries cannot start ACP. Stage 2 native in-process becomes available later.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `--initialize-timeout-ms <n>`           | `10000`         | ACP child request timeout, including the `initialize` handshake (ms). Must be a positive integer up to `2147483647`. Values above the JS timer ceiling (`2^31-1`) are rejected at boot because Node silently compresses them to 1 ms. Cold-container deployments that need extra headroom for child startup can raise this; the same value governs `newSession`, workspace-status polls, and other ACP ext-method deadlines.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | `--allow-origin <pat>`                  | —               | T2.4 ([#4514](https://github.com/QwenLM/qwen-code/issues/4514)). Cross-origin allowlist for browser webui clients. Repeatable. Each value is `*` (any origin — boot refuses if no bearer token is configured; `--require-auth` on loopback is recommended so `/health` and `/demo` are also bearer-gated, since both are pre-auth on loopback by default) or a canonical URL origin (`<scheme>://<host>[:<port>]`, no trailing slash / path / userinfo / query). **Subdomain wildcards (`https://*.example.com`) are intentionally unsupported** — list each subdomain explicitly, or use `*` with a configured token (and `--require-auth` for full hardening). Matched origins receive CORS response headers (`Access-Control-Allow-Origin`, `Vary: Origin`, methods, headers, max-age, and exposed `Retry-After`); unmatched origins still get a 403 with the same envelope as today's wall. `Origin: null` (sandboxed iframes, file:// docs) is always rejected, even under `*`. Pre-flight via `caps.features.allow_origin`. Loopback self-origin hits are unaffected. |
 | `--web` / `--no-web`                    | `true`          | Serve the built Web Shell SPA at the daemon root (`GET /`, `/assets/*`, and SPA deep-link fallback). The static shell is registered **before** the bearer-auth gate — a browser can't attach a token to a `<script>` subresource or an address-bar navigation, the shell carries no secrets, and every API route stays token-gated regardless. On non-loopback binds a one-line stderr warning notes the UI is reachable without auth. Use `--no-web` for an API-only daemon. No effect when the build omits the Web Shell assets (the daemon logs a breadcrumb and runs API-only).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | `--open`                                | `false`         | After the listener is up, open the Web Shell in your default browser at the daemon URL (with `#token=` appended as a URL fragment when a token is configured — a fragment is never sent to the server, keeping the token out of access logs and Referer headers). No-op with `--no-web`, or in headless / CI / SSH environments where no browser is available.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |

package/bundled/review/DESIGN.md

@@ -112,7 +112,7 @@ Chunking itself is unchanged: the plan still tiles every line, tests and generat
 
 Step 3B's chunk agents are defined as "one per entry in `chunks[]`", and only `fetch-pr` produced a chunk plan. A local-diff review, or a cross-repo review in lightweight mode, therefore routed into a topology it had no chunk list for: no receipts, no tiling guarantee, and the orchestrator left to improvise line ranges. Two of the four review paths were promised a mechanism the skill could not deliver.
 
-`qwen review plan-diff <diff-file>` reads a captured diff and emits the same `chunks[]`, `files[]` and topology counts. Redirecting `git diff` or `gh pr diff` to a file bypasses Shell model-output truncation, so all four paths now share one code path. It cannot decide `heavy` — that needs a tree to read the post-change file from — so a bare diff gets chunk agents but no invariant agents.
+`qwen review plan-diff <diff-file>` reads a captured diff and emits the same `chunks[]`, `files[]` and topology counts. Redirecting `git diff` or `gh pr diff` to a file already bypasses the 30 000-char shell cap, so all four paths now share one code path. It cannot decide `heavy` — that needs a tree to read the post-change file from — so a bare diff gets chunk agents but no invariant agents.
 
 ### Why the topology gate ignores prose
 
@@ -448,7 +448,7 @@ Competitors: Copilot uses 1 call, Gemini uses 2, Claude /ultrareview uses 5-20 (
 
 ## Why the diff is a file, not a command
 
-Agents used to be handed `git diff main...HEAD` and told to run it. At the time of the measurements below, Shell tool output passed through `truncateToolOutput` with `ShellTool.maxOutputChars = 30_000` and `keep: 'both'`, and the 30K trigger was also the preview budget: `threshold / 5` characters went to the head and the remainder to the tail. Shell now keeps the 30K persistence trigger but uses an approximately 4K head-and-tail model preview. That makes direct `git diff` output even less suitable for complete review coverage; the file-and-chunk design below remains authoritative.
+Agents used to be handed `git diff main...HEAD` and told to run it. Shell tool output passes through `truncateToolOutput` with `ShellTool.maxOutputChars = 30_000` and `keep: 'both'`, which allocates `threshold / 5` characters to the head and the remainder to the tail.
 
 On PR #6457's 211 000-character diff that yields a 6 000-char head (`QQChannel.ts` lines 41-250) and a 24 000-char tail (`stream.test.ts` and `types.ts`, which sort last by path and together changed 9 lines). 85.8% of the diff — including 19 of the 20 Criticals eventually reported on that PR — was replaced by a `[CONTENT TRUNCATED]` marker. Every agent saw the same window, so the ten-way dimension fan-out multiplied redundancy rather than coverage, and each round of `/review` sampled a different subset of the bugs depending on which files an agent happened to `read_file` on its own initiative.
 

package/bundled/review/SKILL.md

@@ -147,7 +147,7 @@ Based on the parsed `target.type`:
 
 ### Diff capture and the review topology
 
-**Never let a review agent obtain the diff by running `git diff` itself.** Shell keeps a 30 000-character persistence trigger but returns only an approximately 4 000-character head-and-tail model preview, so on a large PR every agent receives a small slice from the first and last files plus a `[CONTENT TRUNCATED]` marker in place of everything between. Under the older 30 000-character preview, a 211 000-character diff exposed only 14% of the changeset; the current preview is smaller still. Every diff-reading agent receives the same slice, so coverage does not grow with the number of agents. The diff is read from a file with `read_file` instead.
+**Never let a review agent obtain the diff by running `git diff` itself.** Shell tool output is capped at 30 000 characters and split head-1/5 / tail-4/5, so on a large PR every agent receives a few hundred lines off the top of the first file, the tail of the last file, and a `[CONTENT TRUNCATED]` marker in place of everything between. On a 211 000-character diff that is 14% of the changeset — and it is the _same_ 14% for every diff-reading agent, so coverage does not grow with the number of agents. The diff is read from a file with `read_file` instead.
 
 Truncation is only half the reason. The other half is the **base**. An agent handed a diff command has to choose a base, and `main..HEAD` and `main...HEAD` differ by one character and by the entire meaning of the review. Two-dot diffs against a `main` that has moved on show every commit main gained since the branch forked, **reversed** — main's fixes appear as the branch's regressions. On PR #6626 a review approved four files and then warned the author, publicly, that their branch carried "typo regressions in `ide-client.ts`" and should be rebased. The branch had done nothing: main had corrected `compatability` → `compatibility` after the fork point, and a two-dot diff showed the branch putting the typo back. The PR's real change set, `merge-base..head`, is four files and does not touch that file at all.
 
@@ -187,7 +187,7 @@ Do **not** hand-type a `git diff` here. Two reasons, and the second is why this
 
 **If the plan comes back empty** (`chunks: []`), stop and take the no-diff branch. Every agent would be given nothing to read, and the review would return a clean verdict over no code at all. For a **file-path** review of a tracked, unmodified file, skip planning entirely: hand every agent the file's absolute path and tell it to read the whole file, paging until `isTruncated` is false. For a **local** review with a genuinely clean tree — nothing staged, nothing unstaged, nothing untracked — tell the user there is nothing to review and stop.
 
-For **cross-repo lightweight reviews**, do the same with the diff GitHub hands you. Redirecting to a file keeps Shell model-output truncation out of it:
+For **cross-repo lightweight reviews**, do the same with the diff GitHub hands you. Redirecting to a file is what keeps the 30 000-char shell cap out of it:
 
 ```bash
 mkdir -p .qwen/tmp
@@ -382,7 +382,7 @@ A check you perform silently is a check you skip, and this one has been skipped:
 
 **Every agent MUST return inline: set `subagent_type: "general-purpose"` and `run_in_background: false` on every `agent` call.** Do NOT fork them — never set `subagent_type: "fork"`. A fork runs fire-and-forget and its findings never come back to you, so the review would stall in Step 4 with nothing to aggregate. You need every agent's findings returned to you inline.
 
-**For same-repo PR reviews (worktree mode), every `agent` call MUST also set `working_dir: "<worktreePath>"`** — the `worktreePath` from the Step 1 fetch report (a repo-relative path like `.qwen/tmp/review-pr-<n>`; pass it through as-is). This sets each agent's working directory to the PR worktree, so its `git diff`, `grep_search`, file reads, and Agent 7's build/test **resolve against the PR's code, not the user's main checkout**. It is a deterministic, harness-level cwd pin — it does NOT depend on the agent remembering to `cd`, and it is what makes reviewing multiple PRs concurrently safe. (It pins the working directory; it is not a hard filesystem sandbox — an absolute path could still reach elsewhere — but normal review operations stay inside the worktree.) This rule applies to **every** agent the review workflow launches — not just the Step 3 dimension agents, but also the Step 4 verification agent and the Step 5 reverse-audit agents (both restated below). Do NOT set `working_dir` for **local-diff, file-path, or cross-repo lightweight** reviews — those have no worktree, so the agents run in the main project directory. **Do NOT set `isolation` on review agents.** The review worktree already exists at `worktreePath`, so `isolation: "worktree"` is redundant. The Agent runtime tolerates strict providers that send both by ignoring `isolation`, but the orchestrator must emit only the specific `working_dir` instruction.
+**For same-repo PR reviews (worktree mode), every `agent` call MUST also set `working_dir: "<worktreePath>"`** — the `worktreePath` from the Step 1 fetch report (a repo-relative path like `.qwen/tmp/review-pr-<n>`; pass it through as-is). This sets each agent's working directory to the PR worktree, so its `git diff`, `grep_search`, file reads, and Agent 7's build/test **resolve against the PR's code, not the user's main checkout**. It is a deterministic, harness-level cwd pin — it does NOT depend on the agent remembering to `cd`, and it is what makes reviewing multiple PRs concurrently safe. (It pins the working directory; it is not a hard filesystem sandbox — an absolute path could still reach elsewhere — but normal review operations stay inside the worktree.) This rule applies to **every** agent the review workflow launches — not just the Step 3 dimension agents, but also the Step 4 verification agent and the Step 5 reverse-audit agents (both restated below). Do NOT set `working_dir` for **local-diff, file-path, or cross-repo lightweight** reviews — those have no worktree, so the agents run in the main project directory.
 
 **You no longer compose these prompts. `qwen review agent-prompt` does** — one `--roster` call builds every one of them, and each block it prints goes to its agent unedited. It already contains everything the list below used to ask you to remember: `diffPathAbsolute` and the exact `read_file` ranges for that role (its own `offset`/`limit` for a chunk agent; every chunk for a whole-diff or 3A agent; the post-change file plus `addedRanges[]` and its own `diffRange` for an invariant agent), the agent's focus areas, the severity definitions verbatim, the finding format, and the project rules. **Never give an agent a `git diff` command** — see "Diff capture and the review topology" in Step 1 for why. In worktree-mode PR reviews the agent's `working_dir` is the PR worktree, so `grep_search` and source-file reads resolve against the PR's code automatically — the agent must NOT `cd` into the worktree or prefix absolute paths for those.
 
@@ -609,7 +609,7 @@ If there are none of these, omit this section.
 
 ### Before an Approve or a zero-Critical verdict: re-check the open Criticals
 
-A `C=0` outcome — Approve, or a Comment with no Critical — is a claim that nothing blocks the merge. It is not the default you fall back to when your own agents surfaced nothing. **If Step 1 set the context-unavailable state** (`pr-context` failed — lightweight or same-repo), there is no context file to read: skip the walk below, record every existing Critical as `cannot tell` by construction, and carry that into the verdict — which the Step 7 invariant already caps at `COMMENT`. Otherwise, take **each live blocker already on the PR — from every comment-bearing section of the context file: "Open inline comments", "Blockers to re-check", "Review summaries", and "Already discussed" (both its inline threads and its issue-level comments)** — and check it against the code as it stands at the reviewed commit. Select **semantically, not by the literal marker**: a `**[Critical]**` prefix qualifies, but so does any body that asserts a blocking defect in other words — a "Critical findings could not be anchored" preamble, an explicit must-fix claim (legacy body-only blockers were emitted markerless, and one such review is exactly what a marker filter once discarded). When unsure whether a body asserts a blocker, re-check it — the cost is one ruling; the alternative is certifying a merge past it. ("Already discussed" stays in scope even though `pr-context` now promotes blocker-bearing bodies out of it: `carriesBlockerSignal` is a **fail-safe floor, not a ceiling** — it recognises the phrasings we have seen, not every phrasing that exists, and a blocker worded around all of them still settles there. That section's "do NOT re-report" header governs duplicate-_reporting_ by the finder agents; it does not exempt a body from this re-check. Read it with the same eyes you bring to the promoted section.) Review-level bodies matter because an unmappable or 422-relocated blocker lives **only** there — and the context file now carries them **in full**: `pr-context` renders every meaningful review body whole under "Review summaries" (no more 240-character snippets), and pulls every blocker-bearing body — replied inline thread or issue comment, marker or no marker — into the "Blockers to re-check" section, rendered in full, because a reply alone never settles a blocker. So the re-check usually needs no separate fetch: read those sections under the file's untrusted-data preamble, paging with `offset`/`limit` until `isTruncated` is false. Review summaries and blocker bodies are rendered in full; the Open and Already-discussed sections use one-line snippets, and **every snippet the renderer cut carries its own `_(truncated — fetch …)_` note naming the exact, already-filled-in command for the rest** — a candidate blocker whose snippet was cut is ruled on only after running that fetch; ruling on the visible prefix alone is the fail-closed violation. Run any such fetch **redirected to a file, never into the terminal** (Shell returns only an approximately 4 000-character model preview for output beyond its 30 000-character persistence trigger, which would re-truncate the very body being completed): append `--jq .body > .qwen/tmp/qwen-review-{target}-body-<id>.md` to the command the note names, then `read_file` that file, paging until `isTruncated` is false, before ruling. **Fail closed either way:** a body you could not read whole — the capped tail unfetched, or the single-object fetch failing (auth, rate limit, network) — is `cannot tell`, not "no Critical in it": it goes to compose-review's `cannotTellCriticals` input, which serializes it and caps the event at `COMMENT`; a blocker you could not read is never approved past. A reply alone does not retire a blocker — "I disagree" or "wontfix" is a reply, which is exactly why `pr-context` quarantines blocker-bearing threads in their own section instead of letting them settle into "Already discussed". Only the code decides: a blocker counts as closed exactly when the re-check below lands on "fixed by this diff", never because the thread has an answer. Record one verdict per blocker:
+A `C=0` outcome — Approve, or a Comment with no Critical — is a claim that nothing blocks the merge. It is not the default you fall back to when your own agents surfaced nothing. **If Step 1 set the context-unavailable state** (`pr-context` failed — lightweight or same-repo), there is no context file to read: skip the walk below, record every existing Critical as `cannot tell` by construction, and carry that into the verdict — which the Step 7 invariant already caps at `COMMENT`. Otherwise, take **each live blocker already on the PR — from every comment-bearing section of the context file: "Open inline comments", "Blockers to re-check", "Review summaries", and "Already discussed" (both its inline threads and its issue-level comments)** — and check it against the code as it stands at the reviewed commit. Select **semantically, not by the literal marker**: a `**[Critical]**` prefix qualifies, but so does any body that asserts a blocking defect in other words — a "Critical findings could not be anchored" preamble, an explicit must-fix claim (legacy body-only blockers were emitted markerless, and one such review is exactly what a marker filter once discarded). When unsure whether a body asserts a blocker, re-check it — the cost is one ruling; the alternative is certifying a merge past it. ("Already discussed" stays in scope even though `pr-context` now promotes blocker-bearing bodies out of it: `carriesBlockerSignal` is a **fail-safe floor, not a ceiling** — it recognises the phrasings we have seen, not every phrasing that exists, and a blocker worded around all of them still settles there. That section's "do NOT re-report" header governs duplicate-_reporting_ by the finder agents; it does not exempt a body from this re-check. Read it with the same eyes you bring to the promoted section.) Review-level bodies matter because an unmappable or 422-relocated blocker lives **only** there — and the context file now carries them **in full**: `pr-context` renders every meaningful review body whole under "Review summaries" (no more 240-character snippets), and pulls every blocker-bearing body — replied inline thread or issue comment, marker or no marker — into the "Blockers to re-check" section, rendered in full, because a reply alone never settles a blocker. So the re-check usually needs no separate fetch: read those sections under the file's untrusted-data preamble, paging with `offset`/`limit` until `isTruncated` is false. Review summaries and blocker bodies are rendered in full; the Open and Already-discussed sections use one-line snippets, and **every snippet the renderer cut carries its own `_(truncated — fetch …)_` note naming the exact, already-filled-in command for the rest** — a candidate blocker whose snippet was cut is ruled on only after running that fetch; ruling on the visible prefix alone is the fail-closed violation. Run any such fetch **redirected to a file, never into the terminal** (shell output truncates at 30 000 chars, which would re-truncate the very body being completed): append `--jq .body > .qwen/tmp/qwen-review-{target}-body-<id>.md` to the command the note names, then `read_file` that file, paging until `isTruncated` is false, before ruling. **Fail closed either way:** a body you could not read whole — the capped tail unfetched, or the single-object fetch failing (auth, rate limit, network) — is `cannot tell`, not "no Critical in it": it goes to compose-review's `cannotTellCriticals` input, which serializes it and caps the event at `COMMENT`; a blocker you could not read is never approved past. A reply alone does not retire a blocker — "I disagree" or "wontfix" is a reply, which is exactly why `pr-context` quarantines blocker-bearing threads in their own section instead of letting them settle into "Already discussed". Only the code decides: a blocker counts as closed exactly when the re-check below lands on "fixed by this diff", never because the thread has an answer. Record one verdict per blocker:
 
 - **still stands** — the defect is present in the code you just read. It blocks: the event is `REQUEST_CHANGES`, and the finding goes inline (or into the body if it cannot be anchored).
 - **fixed by this diff** — you traced the blocker's **mechanism** through the code as it now stands and it can no longer fire. Say nothing; do not re-report it. A GitHub thread can read `isResolved: false, isOutdated: false` for a bug a later commit fixed on an adjacent line — the flag tracks the anchored line, not the fix, so the flag is not evidence either way. Only the code is.

package/chunks/{MaxSizedBox-YO432SD4.js → MaxSizedBox-B5YGZSYE.js}

@@ -4,72 +4,65 @@ import {
   MINIMUM_MAX_HEIGHT,
   MaxSizedBox,
   setMaxSizedBoxDebugging
-} from "./chunk-SP5WRGVG.js";
-import "./chunk-6IL7KRLE.js";
+} from "./chunk-JNWZQ27S.js";
+import "./chunk-GMGDLUC7.js";
 import "./chunk-SV5PQVQE.js";
-import "./chunk-FFFM6NJV.js";
+import "./chunk-AYCDXHZB.js";
+import "./chunk-NEEB7UEN.js";
 import "./chunk-5QWWOFGG.js";
 import "./chunk-NHDKSOEY.js";
-import "./chunk-7Z6JQEL6.js";
 import "./chunk-RS7MT2QG.js";
 import "./chunk-H2XVO6NE.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-RKUWKYED.js";
-import "./chunk-Z2FTZM4Z.js";
+import "./chunk-KX6UK4VJ.js";
+import "./chunk-5M6IDOMF.js";
 import "./chunk-T4TZQJ7W.js";
 import "./chunk-H6XPXXMH.js";
-import "./chunk-5M6IDOMF.js";
-import "./chunk-T2L47JJK.js";
-import "./chunk-GPSKDNEE.js";
-import "./chunk-X6N25LXS.js";
+import "./chunk-EAUYY7SS.js";
+import "./chunk-FSL5W5TI.js";
+import "./chunk-OONJNQ42.js";
+import "./chunk-D2VIDMVM.js";
 import "./chunk-E2UVIFI2.js";
-import "./chunk-Q2YKNMLS.js";
 import "./chunk-XU457J4V.js";
 import "./chunk-VDDGDZMA.js";
-import "./chunk-KHOVYUHX.js";
+import "./chunk-EIAK6Q2B.js";
 import "./chunk-SZRN75WQ.js";
-import "./chunk-6PVPNMXU.js";
-import "./chunk-MMT6IQCT.js";
+import "./chunk-HTO4JFDZ.js";
 import "./chunk-CPBF7KYF.js";
-import "./chunk-NABLFI57.js";
-import "./chunk-QBUDF33N.js";
-import "./chunk-LIZRAKPB.js";
-import "./chunk-WHGVTP7Q.js";
+import "./chunk-CPCVCKKF.js";
 import "./chunk-6AM5D4ME.js";
-import "./chunk-JCW2R7WC.js";
-import "./chunk-57FIIFJN.js";
-import "./chunk-HTO4JFDZ.js";
-import "./chunk-XVNQMZ2I.js";
-import "./chunk-FODK6UMO.js";
-import "./chunk-GLNBDYUX.js";
-import "./chunk-EDANOBFR.js";
+import "./chunk-G45X5TRN.js";
+import "./chunk-PBATSWUQ.js";
+import "./chunk-ZEOZL37W.js";
+import "./chunk-OOCI5VVU.js";
+import "./chunk-BRRF37CO.js";
+import "./chunk-BMWMT5Y2.js";
 import "./chunk-JESCGQM3.js";
-import "./chunk-GMLTZG4O.js";
-import "./chunk-25WFJZL5.js";
-import "./chunk-DJ2GSRLV.js";
-import "./chunk-5I5BM454.js";
-import "./chunk-D7ZI5C7O.js";
+import "./chunk-ZFKNWQGQ.js";
+import "./chunk-4WKAA4KS.js";
+import "./chunk-CR3C7WXL.js";
 import "./chunk-VGC4I5JJ.js";
-import "./chunk-4K56OJFJ.js";
-import "./chunk-JYS55H6Z.js";
+import "./chunk-JD3MKVKL.js";
+import "./chunk-UEY4AYUL.js";
+import "./chunk-BDBMYST4.js";
+import "./chunk-EZVDJFZ7.js";
+import "./chunk-OP4MOGXF.js";
+import "./chunk-XVNQMZ2I.js";
+import "./chunk-FEOZBUMT.js";
+import "./chunk-DJ2GSRLV.js";
+import "./chunk-6EFTQYW7.js";
+import "./chunk-MAQQGNQ5.js";
 import "./chunk-A4UCTEB5.js";
 import "./chunk-XWRJCPHC.js";
-import "./chunk-QNLNLENL.js";
-import "./chunk-6X4GWOPW.js";
 import "./chunk-TYQMGACW.js";
 import "./chunk-TYAMGABM.js";
 import "./chunk-FCMNKVXT.js";
-import "./chunk-7362QS5B.js";
-import "./chunk-HTR4WV6U.js";
-import "./chunk-M7WBGLYP.js";
-import "./chunk-U7ZFW55U.js";
-import "./chunk-NPQDJGKU.js";
-import "./chunk-YM3SZTH4.js";
-import "./chunk-OQB4EXO4.js";
+import "./chunk-C27BYUX6.js";
 import "./chunk-75DOP5OR.js";
 import "./chunk-DMTGGOSA.js";
 import "./chunk-YQ3U5MUC.js";
-import "./chunk-THJNPLI4.js";
+import "./chunk-TB6UDU4T.js";
 import "./chunk-5O2XNYP6.js";
 import "./chunk-J2S4EL5Y.js";
 export {