@qwen-code/qwen-code 0.22.0-nightly.20260825.22bb5e8b9f → 0.22.1

package/bundled/coordinate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: coordinate
-description: Coordinate up to three Qwen Code teammates with enforced read-only workers, an optional worktree-pinned writer, shared tasks, peer messages, and existing Agent View tabs. Invoke explicitly with /coordinate.
+description: Coordinate a small team of Qwen Code teammates with enforced read-only workers, an optional worktree-pinned writer, shared tasks, peer messages, and existing Agent View tabs. Invoke explicitly with /coordinate.
 argument-hint: '<goal>'
 disable-model-invocation: true
 ---
@@ -14,7 +14,7 @@ Act as the team leader. Decompose the goal, keep task ownership clear, reconcile
 When `team_create` is available:
 
 1. Create one team and one self-contained task per current investigation workstream. Do not queue an implementation task while read-only teammates are idle because tasks are auto-assigned.
-2. Spawn one to three named investigation teammates with `read_only: true`. Do not pass `model`; use the session-default model unless the selected agent definition explicitly overrides it.
+2. Spawn named investigation teammates with `read_only: true` — one per workstream, and prefer three at most. Never exceed the team's configured cap, which `team_create` reports; spawning past it fails outright. Do not pass `model`; use the session-default model unless the selected agent definition explicitly overrides it.
 3. Assign tasks and let teammates collaborate through `send_message` and the shared task list. Send targeted follow-ups when evidence conflicts, a task needs clarification, or a result is incomplete.
 4. Accept or reject each result based on its evidence. Reassign rejected work instead of silently using it.
 
@@ -42,7 +42,7 @@ If the Agent Team tools are unavailable, say that `experimental.agentTeam` must
 
 ## Keep coordination bounded
 
-- Use one teammate for a narrow task and no more than three for this workflow.
+- Use one teammate for a narrow task. Past roughly three, the leader spends more of its turn reconciling reports than doing the work, so add a fourth only when the workstreams are genuinely independent — and never past the configured cap.
 - Give every task an objective, scope, completion condition, and required evidence.
 - Default every teammate to `read_only: true`; add one worktree writer only when implementation is required.
 - Do not use Arena: it is for competing solutions to the same task, not collaboration on different tasks.

package/bundled/qc-helper/docs/configuration/model-providers.md

@@ -657,6 +657,8 @@ Setting `reasoning: false` (the literal boolean) explicitly disables thinking on
 
 On a `api.deepseek.com` baseURL, the OpenAI pipeline emits the explicit `thinking: { type: 'disabled' }` field that DeepSeek V4+ requires — the server-side default is `'enabled'`, so simply omitting `reasoning_effort` would still pay thinking latency/cost. Self-hosted DeepSeek backends (sglang/vllm) and other OpenAI-compatible servers do **not** receive this field; if you need to disable thinking on those, inject `thinking: { type: 'disabled' }` (or whatever knob your inference framework exposes) via `samplingParams`/`extra_body`.
 
+On an `openrouter.ai` baseURL, the OpenAI pipeline emits OpenRouter's provider-level `reasoning: { enabled: false }` field when reasoning is disabled. Other OpenAI-compatible servers do not receive this OpenRouter-specific field; use `samplingParams`/`extra_body` for their native disable knob.
+
 ### Interaction with `samplingParams` (OpenAI-compatible only)
 
 > [!warning]

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

@@ -370,7 +370,7 @@ If you are experiencing performance issues with file searching (e.g., with `@` c
 | `tools.visible`                      | array of strings  | Deferred tool names made visible at startup without requiring `tool_search`. Listed tools appear alongside core tools in the initial session. Merged as a union across scopes.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | `undefined` |                                                                                                                                                                                                                                                                                                                             |
 | `tools.allowed`                      | array of strings  | **Deprecated.** Use `permissions.allow` instead. Tool names that bypass the confirmation dialog. Automatically migrated to the `permissions` format on first load.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | `undefined` |                                                                                                                                                                                                                                                                                                                             |
 | `tools.approvalMode`                 | string            | Sets the default approval mode for tool usage.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | `auto`      | Possible values: `plan` (analyze only, do not modify files or execute commands), `default` (require approval before file edits or shell commands run), `auto-edit` (automatically approve file edits), `auto` (LLM classifier auto-approves safe actions, blocks risky ones), `yolo` (automatically approve all tool calls) |
-| `tools.discoveryCommand`             | string            | Command to run for tool discovery.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | `undefined` |                                                                                                                                                                                                                                                                                                                             |
+| `tools.discoveryCommand`             | string            | Command to run for tool discovery. When the `permissions.allow` registry allowlist is active, a discovered tool is registered only if an allow or ask rule covers it; uncovered discovered tools are hidden from the model instead of being advertised and then rejected at runtime.                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | `undefined` |                                                                                                                                                                                                                                                                                                                             |
 | `tools.callCommand`                  | string            | Defines a custom shell command for calling a specific tool that was discovered using `tools.discoveryCommand`. The shell command must meet the following criteria: It must take function `name` (exactly as in [function declaration](https://ai.google.dev/gemini-api/docs/function-calling#function-declarations)) as first command line argument. It must read function arguments as JSON on `stdin`, analogous to [`functionCall.args`](https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/inference#functioncall). It must return function output as JSON on `stdout`, analogous to [`functionResponse.response.content`](https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/inference#functionresponse). | `undefined` |                                                                                                                                                                                                                                                                                                                             |
 | `tools.useRipgrep`                   | boolean           | Use ripgrep for file content search instead of the fallback implementation. Provides faster search performance.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | `true`      |                                                                                                                                                                                                                                                                                                                             |
 | `tools.useBuiltinRipgrep`            | boolean           | Use the bundled ripgrep binary. When set to `false`, the system-level `rg` command will be used instead. This setting is only effective when `tools.useRipgrep` is `true`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `true`      |                                                                                                                                                                                                                                                                                                                             |
@@ -416,11 +416,11 @@ The permissions system provides fine-grained control over which tools can run, w
 
 The first matching rule wins. Rules use the format `"ToolName"` or `"ToolName(specifier)"`.
 
-| Setting             | Type             | Description                                                                                                      | Default     |
-| ------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------- | ----------- |
-| `permissions.allow` | array of strings | Rules for auto-approved tool calls (no confirmation needed). Merged across all scopes (user + project + system). | `undefined` |
-| `permissions.ask`   | array of strings | Rules for tool calls that always require user confirmation. Takes priority over `allow`.                         | `undefined` |
-| `permissions.deny`  | array of strings | Rules for blocked tool calls. Highest priority — overrides both `allow` and `ask`.                               | `undefined` |
+| Setting             | Type             | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | Default     |
+| ------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
+| `permissions.allow` | array of strings | Rules for auto-approved tool calls (no confirmation needed). Merged across all scopes (user + project + system). Also acts as a registry-level allowlist: when at least one valid allow rule is configured (malformed entries do not count, and auto-approval-only sources such as the `--allowed-tools` CLI flag do not activate it), built-in tools not covered by any allow or ask rule are not registered at all — they disappear from `/tools` and their schemas are never sent to the model (MCP tools, the `--json-schema` `structured_output` contract, the plan-mode lifecycle tools `exit_plan_mode` / `enter_plan_mode` / `ask_user_question`, `task_stop`, `tool_search`, and the deferred `computer_use__*` family are exempt). Removing a rule mid-session revokes its auto-approval immediately but does not deregister an already-registered tool; deregistration takes effect on restart. Exception: under the AUTO approval mode, dangerous allow rules are stashed rather than active, so a mid-session removal cannot touch the stash — when AUTO mode is exited the stashed rule is restored and auto-approves again until the session restarts. Requires restart. | `undefined` |
+| `permissions.ask`   | array of strings | Rules for tool calls that always require user confirmation. Takes priority over `allow`. Ask rules also count toward the registry allowlist: a tool covered by an ask rule stays registered even when an allowlist is active, so "always require confirmation" never silently becomes "tool unavailable".                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | `undefined` |
+| `permissions.deny`  | array of strings | Rules for blocked tool calls. Highest priority — overrides both `allow` and `ask`. A whole-tool deny rule (no specifier) also removes the tool from the registry — for built-in tools and tools found via `tools.discoveryCommand`. MCP tools are exempt (their registration path only honours `disabledTools`): hide them with the per-server `excludeTools` / `tools.disabled` filters instead. Deny rules still block MCP tool calls at runtime.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | `undefined` |
 
 **Tool name aliases (any of these work in rules):**
 

package/bundled/qc-helper/docs/features/channels/_meta.ts

@@ -3,6 +3,7 @@ export default {
   telegram: 'Telegram',
   weixin: 'WeChat',
   dingtalk: 'DingTalk',
+  dws: 'DingTalk Workspace',
   wecom: 'WeCom',
   feishu: 'Feishu',
   qqbot: 'QQ Bot',

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

@@ -0,0 +1,120 @@
+# DingTalk Workspace (DWS)
+
+The DWS channel uses an account already authenticated by the DingTalk Workspace CLI. It receives direct and group messages, recognizes DingTalk document-mention notification cards, and publishes the agent's response back to the originating message or document comment.
+
+This is separate from the [DingTalk bot channel](./dingtalk). Keep using `type: "dingtalk"` for a dedicated application bot; use `type: "dws"` when Qwen Code should act through an existing DWS login.
+
+## Prerequisites
+
+Install DWS CLI 1.0.57 or newer on the host that runs Qwen Code, and ensure `dws` resolves from that process's `PATH`:
+
+```bash
+dws version --format json
+```
+
+Authenticate on the same host:
+
+```bash
+dws auth login
+dws profile list --format json
+dws auth status --format json
+```
+
+On a headless server, use `dws auth login --device`. A channel pins exactly one existing profile at startup. Set `profile` to an exact profile name or corpId, or omit it to pin the entry marked `isCurrent`. The channel treats every DWS login the same and does not depend on `user_id` metadata.
+
+## Configuration
+
+Add a channel to `~/.qwen/settings.json`:
+
+```json
+{
+  "channels": {
+    "dws-work": {
+      "type": "dws",
+      "profile": "profile-name-or-corp-id",
+      "senderPolicy": "pairing",
+      "groupPolicy": "pairing",
+      "watchTodos": true,
+      "groups": {
+        "*": { "requireMention": true }
+      },
+      "sessionScope": "chat_thread",
+      "cwd": "/path/to/your/project"
+    }
+  }
+}
+```
+
+YOLO approval mode is available for answer bots that should run tool calls
+without interactive confirmations:
+
+```json
+{
+  "channels": {
+    "dws-answers": {
+      "type": "dws",
+      "senderPolicy": "pairing",
+      "groupPolicy": "pairing",
+      "approvalMode": "yolo",
+      "cwd": "/path/to/answer-bot"
+    }
+  }
+}
+```
+
+YOLO mode auto-approves every tool call. Use it only for a trusted bot account
+and workspace.
+
+`senderPolicy` and `groupPolicy` default to `pairing` for a newly managed DWS channel. Approve a user or group with the code returned by the channel:
+
+```bash
+qwen channel pairing approve dws-work CODE
+```
+
+`senderPolicy` controls direct-message senders, document-notification authors, native-todo creators, and senders in `open` or `allowlist` groups. `groupPolicy` controls group conversations. An approved pairing group follows the shared channel behavior and authorizes its members; open and allowlist groups must also pass `senderPolicy`.
+
+`groups` controls mention behavior. A concrete group ID overrides `"*"`. With `requireMention: true`, only an @ message wakes the channel. With `requireMention: false`, ordinary messages are also received after the group and sender policies pass.
+
+Group mentions use the real-time personal event stream first. The channel also checks recent `@` message history every five seconds, so mentions from external groups are recovered when DingTalk omits them from the personal event stream. Messages are deduplicated by conversation and message ID across both paths.
+
+When a message quotes another DingTalk message, the quoted text is included as reply context for the agent on both the real-time and history fallback paths.
+
+## Document Mentions
+
+There is no document or knowledge-base watch list. To start a document task:
+
+1. Add a DingTalk document comment that @mentions the authenticated account.
+2. Enable the option that sends a DingTalk notification to that account.
+3. DWS delivers the notification card through the account's direct-message history.
+
+The channel extracts the document ID, comment key, and request from that notification. It reads the referenced document for context, adds DingTalk's `暗中观察` eyes reaction while the task runs, and replies to the original document comment. The real-time DWS event stream is used when it contains the card; a five-second incremental history check covers cards omitted by the current event stream.
+
+Comments that do not generate a notification are ignored by design. Duplicate notification messages for the same document comment execute only once. Document tasks follow `senderPolicy` and support `approvalMode` `default`, `plan`, or `yolo`; `default` is used when omitted.
+
+## Native Todo Changes
+
+Set `watchTodos: true` to poll the selected DWS profile's pending native todos where the account is an executor. The option defaults to `false` so adding a DWS channel never executes existing todos implicitly.
+
+The first successful scan establishes a baseline and does not start historical todos. Later scans run a task when a todo is newly assigned, reopened, or its actionable fields change, including its title, priority, deadline, or assignees. The final response is added as a comment on the originating todo. Comment-only metadata and modification timestamps are excluded from change detection so the channel's own response cannot trigger a loop. Completion or removal drops the todo from the pending set; reopening it creates a new trigger.
+
+Native todos follow `senderPolicy` using the todo creator identity. Under `pairing`, the channel adds one pairing-code comment and keeps the todo pending; after the creator is approved locally, a later poll can process the unchanged todo. Polling runs every 30 seconds and remains scoped to the pinned profile's current organization.
+
+## Starting and Verifying
+
+Run the channel directly:
+
+```bash
+qwen channel start dws-work
+```
+
+Or let the daemon own it:
+
+```bash
+qwen serve --workspace /path/to/your/project --channel dws-work
+```
+
+Do not run both forms at once because they share the channel-service lease.
+
+For local verification, send a direct message from another account, approve pairing if required, and verify the eyes reaction appears while the task runs. Then add a document comment with @mention notification enabled. The channel should react to the notification message, read the document, and post the final answer under the original comment. A comment with notification disabled should produce no task.
+
+The channel ignores events from sender IDs that DWS identifies as the authenticated account, preventing reply and pairing loops without inferring identity from message text. Starting the IM sources requires that authoritative self-identity: if the authenticated account exposes no openDingTalkId and no earlier session under the same profile recorded one, the channel refuses to connect. A reconnect that temporarily loses the ID keeps filtering on the previously recorded self sender IDs.

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

@@ -2,7 +2,7 @@
 
 Channels let you interact with a Qwen Code agent from messaging platforms like Telegram, WeChat, QQ, DingTalk, WeCom, or Feishu, instead of the terminal. You send messages from your phone or desktop chat app, and the agent responds just like it would in the CLI.
 
-Code-hosting platforms (starting with [GitHub](./github)) are also supported via polling adapters — the agent monitors notifications and responds to @mentions on issues and pull requests.
+Code-hosting platforms (starting with [GitHub](./github)) and authenticated workspace accounts (starting with [DingTalk Workspace](./dws)) are also supported through channels.
 
 ## How It Works
 
@@ -17,7 +17,7 @@ All channels share one agent process with isolated sessions per user. Each chann
 
 ## Quick Start
 
-1. Set up a bot on your messaging platform (see channel-specific guides: [Telegram](./telegram), [WeChat](./weixin), [QQ Bot](./qqbot), [DingTalk](./dingtalk), [WeCom](./wecom), [Feishu](./feishu), [GitHub](./github))
+1. Set up a bot or authenticated workspace account (see channel-specific guides: [Telegram](./telegram), [WeChat](./weixin), [QQ Bot](./qqbot), [DingTalk](./dingtalk), [DingTalk Workspace](./dws), [WeCom](./wecom), [Feishu](./feishu), [GitHub](./github))
 2. Add the channel configuration to `~/.qwen/settings.json`
 3. Run `qwen channel start` to start all channels, or `qwen channel start <name>` for a single channel
 
@@ -52,7 +52,7 @@ Channels are configured under the `channels` key in `settings.json`. Each channe
 
 | Option                   | Required         | Description                                                                                                                                                                                                             |
 | ------------------------ | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `type`                   | Yes              | Channel type: `telegram`, `weixin`, `qq`, `dingtalk`, `wecom`, `feishu`, `github`, or a custom type from an extension (see [Plugins](./plugins))                                                                        |
+| `type`                   | Yes              | Channel type: `telegram`, `weixin`, `qq`, `dingtalk`, `dws`, `wecom`, `feishu`, `github`, `gitlab`, or a custom type from an extension (see [Plugins](./plugins))                                                       |
 | `token`                  | Telegram         | Bot token. Supports `$ENV_VAR` syntax to read from environment variables. Not needed for WeChat, DingTalk, WeCom, or Feishu                                                                                             |
 | `clientId`               | DingTalk, Feishu | DingTalk AppKey or Feishu App ID. Supports `$ENV_VAR` syntax                                                                                                                                                            |
 | `clientSecret`           | DingTalk, Feishu | DingTalk AppSecret or Feishu App Secret. Supports `$ENV_VAR` syntax                                                                                                                                                     |

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

@@ -365,7 +365,7 @@ If you switch models (via `/model`) and re-review the same PR, `/review` detects
 # → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."
 ```
 
-The model match also gates incremental scoping, not just the skip: "clean up to the cached commit" is the previous model's verdict, so when new commits have landed since the cached review, a model mismatch never scopes to `lastCommitSha..HEAD` — the range is the full diff, noting "Previous round was reviewed by qwen3-coder. Running full review with gpt-4o." — unless an anchor certified by the model now running is recovered from the last posted review (below), which scopes the range instead. The previous round's findings still carry over to be re-ruled; only the anchor does not. The same gate binds the anchor recovered from the last posted review's machine-ledger marker when the cache is absent or its anchor is unusable (CI, another clone): it scopes the incremental range only if the model now running certified it — a marker certified by a different model, or carrying no model (a review posted with `review.attribution` off, or one from before the field), falls back to the full diff.
+The model match also gates incremental scoping, not just the skip: "clean up to the cached commit" is the previous model's verdict, so when new commits have landed since the cached review, a model mismatch never scopes to `lastCommitSha..HEAD` — the range is the full diff, noting "Previous round was reviewed by qwen3-coder. Running full review with gpt-4o." — unless an anchor certified by the model now running is recovered from the last posted review (below), which scopes the range instead. The previous round's findings still carry over to be re-ruled; only the anchor does not. The same gate binds the anchor recovered from the last posted review's machine-ledger marker when the cache is absent or its anchor is unusable (CI, another clone): it scopes the incremental range only if the model now running certified it — a marker certified by a different model, or carrying no model (a review posted with `review.attribution` off, or one from before the field), falls back to the full diff. A round that did not close cleanly posts its marker without an anchor (it cannot certify a range), but that loss is not sticky when the round's work list survived whole: recovery grafts the anchor forward from the most recent earlier marker your own account posted with one, so a single non-clean round no longer forces every later round to re-read the full diff — the next round scopes `anchor..HEAD`, which re-covers the range the non-clean round could not certify. A size-capped round's graft is refused (dropped findings would fall outside the grafted scope and retire silently), so later rounds keep re-reading the full diff until a complete marker lands.
 
 Cache is stored in `.qwen/review-cache/` and tracks both the commit SHA and model ID. Make sure this directory is in your `.gitignore` (a broader rule like `.qwen/*` also works). On GitHub, if the cached commit was rebased or force-pushed away, it falls back to a full review; Aone rules the cached anchor differently — see its paragraph below. Only high-effort reviews consult or write the cache — a `--effort low|medium` quick pass never counts as "already reviewed".
 

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

@@ -396,6 +396,8 @@ Notes:
 - **Both flags or neither** — boot fails if only one is given (a cert with no key can't start an HTTPS listener).
 - **TLS is orthogonal to auth** — HTTPS encrypts the transport; the bearer token still gates every API route. Non-loopback binds require a token with or without TLS.
 - **Scope is TLS termination only** — no auto-generation, no ACME / Let's Encrypt. This is a LAN / dev convenience; for internet-facing deployments terminate TLS at a reverse proxy (see the threat model below).
+- **Channel workers dial the daemon back over `https://`** — so they need to trust the serving certificate too. A self-signed cert (or a fullchain that carries its own root) needs nothing: the daemon injects it into each worker's `NODE_EXTRA_CA_CERTS`. The mkcert flow above is **CA-issued**, so the leaf alone cannot anchor the chain — export `NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"` in the daemon's launch environment before starting with `--channel`. An operator-set value is _merged_ with the daemon cert, not replaced. Without it the daemon boots green while every channel worker restart-loops on `UNABLE_TO_VERIFY_LEAF_SIGNATURE`; the daemon log names the gap at boot.
+- **Rotating `--tls-cert` in place needs a daemon restart** — the daemon serves the bytes it read at boot, so until it restarts, respawned workers can load newer contents than the daemon presents and their handshakes fail.
 
 ## CLI flags
 

package/bundled/review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review
-description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, `/review <pr-number> --comment` to post inline comments on the PR, `/review --fix` to apply the findings to your working tree, or `/review <pr-number> --resume` to continue an interrupted review of that PR instead of starting over. Add `--effort low|medium|high` to trade depth for speed (defaults to high for PRs, medium for local changes).
-argument-hint: '[pr-number|file-path] [--effort low|medium|high] [--severity-floor critical|suggestion] [--comment] [--fix] [--resume]'
+description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, `/review <pr-number> --comment` to post inline comments on the PR, `/review --fix` to apply the findings to your working tree, or `/review <pr-number> --resume` to continue an interrupted review of that PR instead of starting over. Add `--effort low|medium|high` to trade depth for speed (defaults to high for PRs, medium for local changes). Add `--topology minimal` to run the single-pass A/B comparison arm instead of the pipeline.
+argument-hint: '[pr-number|file-path] [--effort low|medium|high] [--severity-floor critical|suggestion] [--topology minimal] [--comment] [--fix] [--resume]'
 allowedTools:
   - task
   - run_shell_command
@@ -11,6 +11,7 @@ allowedTools:
   - edit
   - glob
   - record_artifact
+  - report_findings
 ---
 
 # Code Review
@@ -67,8 +68,9 @@ It prints a JSON verdict; use it **verbatim**:
 - `effort` + `effortSource` — the resolved level after defaults (**high** for PR targets, **medium** for local/file) and the `--comment` override (an **effective** `--comment` forces `high`; an ignored one on a non-PR target changes nothing). Two `settings.json` keys feed the defaults: `review.effort` replaces the built-in default when `--effort` is absent (`effortSource: "configured"`), and `review.comment: true` makes every PR review behave as if `--comment` was passed — the forcings above still apply. Both resolve from operator scopes only (system/user); a repository's `.qwen/settings.json` cannot set them. Do not re-derive it.
 - `comment.requested` / `comment.effective` — `effective` is what gates Step 7 (true also when only the `review.comment` setting is on); `requested && !effective` means the user asked on a non-PR target, and the warning for that is already in `warnings`.
 - `fix.requested` / `fix.effective` — `--fix` is `--comment` reflected, and gated on the opposite target. `--comment` writes to a **pull request**, so it needs one; `--fix` writes to a **working tree**, so it needs one that outlives the review. A PR review's tree is the ephemeral worktree `fetch-pr` creates and Step 9 deletes, so `--fix` on a PR target is ignored with a warning — edits there are discarded minutes later, and reporting findings as "fixed" into a directory that no longer exists is worse than not fixing them. `effective` is what gates Step 6B. An effective `--fix` also floors the effort at **medium**: it edits the user's files, and low runs no verification, so applying an unverified finding is the same mistake as posting one, aimed at their working tree instead of a pull request. It does not force **high** — medium's findings are verified, and the reverse audit high adds hunts for findings that are _missing_, which is not what deciding whether to apply one turns on.
-- `severityFloor` + `severityFloorSource` — the posting floor for a PR review: `critical` posts only Criticals (otherwise-postable high-confidence Suggestions are recorded and deferred — Step 6's convergence posture; low-confidence and Nice-to-have findings stay terminal-only as ever), `suggestion` posts Criticals and Suggestions at every round, and `auto` — the default — is the **round-adaptive rule you resolve in Step 6**, where the round is known: `suggestion` through round 5, `critical` from round 6. The parser cannot resolve `auto` itself (the round comes from the previous posted round's ledger, not fetched yet), so carry the verdict's value forward and resolve it there. Explicit flag beats the `review.severityFloor` setting beats `auto`; a non-PR target has no rounds, so the flag warns and is ignored there. The floor governs what the review **posts**, never what it finds, verifies, or reports in the terminal.
-- `resume.requested` / `resume.effective` — `--resume` continues an interrupted run of the same PR instead of starting over. `effective` is what gates the resume branch below, and it is a TARGET-SHAPE gate rather than a promise: a cross-repo `pr-url` with no matching remote is `effective: true` but routes to lightweight mode, which never calls `fetch-pr` — item 3 below owns telling the user the flag is inert there. `requested && !effective` means a local or file target, already warned in `warnings`. It never changes the effort: a continuation is pinned to the interrupted run's recorded level, and an explicitly different `--effort` makes `fetch-pr` refuse the resume and run fresh at the requested one.
+- `severityFloor` + `severityFloorSource` — the posting floor for a PR review: `critical` posts only Criticals (otherwise-postable high-confidence Suggestions are recorded and deferred — Step 6's convergence posture; low-confidence and Nice-to-have findings stay terminal-only as ever), `suggestion` posts Criticals and Suggestions at every round, and `auto` — the default — is the **round-adaptive rule you resolve in Step 6**, where the round is known: `suggestion` through round 5, `critical` from round 6 — **or `critical` from any round once the recovered ledger's `flatRounds` streak has reached its bar** (Step 6's signal-driven trigger: the first-time-finding rate has not fallen for that many consecutive rounds, so the loop is re-deriving the same set and the floor stems it early). The parser cannot resolve `auto` itself (the round comes from the previous posted round's ledger, not fetched yet), so carry the verdict's value forward and resolve it there. Explicit flag beats the `review.severityFloor` setting beats `auto`; a non-PR target has no rounds, so the flag warns and is ignored there. The floor governs what the review **posts**, never what it finds, verifies, or reports in the terminal.
+- `topology` + `topologySource` — the shape of the run. `auto` (the default) runs the standing effort-driven pipeline described below. `minimal` runs the single-pass A/B comparison arm (Step 3M) instead — and when it is set, it OVERRIDES the effort dispatch entirely. In this step you run `parse-args` and the **diff capture only** (`fetch-pr` for a same-repo PR, the lightweight `fetch-diff` for a cross-repo PR, or the local capture for a local/file target — exactly as below), then jump straight to **Step 3M**. You SKIP the rest of Step 1's setup — the rules load, `pr-context`, `comment-status`, and the incremental-cache check — and you skip the fan-out, verification, reverse audit, and posting. `minimal` is terminal-only; the parser has already forced `comment.effective`, `fix.effective`, and `resume.effective` to false, and its warnings for that are in `warnings`. There is no configured topology — it is only ever an explicit flag.
+- `resume.requested` / `resume.effective` — `--resume` continues an interrupted run of the same PR instead of starting over. `effective` is what gates the resume branch below, and it is a TARGET-SHAPE gate rather than a promise: a cross-repo `pr-url` with no matching remote is `effective: true` but routes to lightweight mode, which never calls `fetch-pr` — item 3 below owns telling the user the flag is inert there. `requested && !effective` means a local or file target, or `--topology minimal` (a fresh single pass neither continues nor consumes an interrupted run), already warned in `warnings`. It never changes the effort: a continuation is pinned to the interrupted run's recorded level, and an explicitly different `--effort` makes `fetch-pr` refuse the resume and run fresh at the requested one.
 - `warnings` — surface every entry to the user, word for word.
 - `extraTokens` / `unknownFlags` — leftover input the parser refused to guess about; mention them to the user rather than silently dropping them.
 
@@ -84,7 +86,9 @@ What each level runs:
 - **medium** — **balanced**: the high pipeline with its most expensive passes removed. It runs the parallel review agents (Step 3A/3B) over a **reduced dimension set** — issue fidelity (Agent 0, PR targets only), correctness (Agents 1a/1b/1c), **security (Agent 2)**, quality (Agents 3a/3b/3c), performance (Agent 4), **test coverage (Agent 5)**, and **build & test (Agent 7)** — followed by a **single verification pass** (Step 4). It loads and enforces project rules (Step 2) and runs `comment-status` like high. It **skips** the adversarial-persona agents (6a/6b/6c), the language-pitfall and wrapper/proxy specialists (Agents 1d/1e), the diff-specialist finders (Agent 8), the **reverse audit** (Step 5), the incremental cache, and PR posting (`--comment` still forces high). Findings are **verified** (Step 4 ran — they are not "unverified" the way low's are), but without the reverse-audit second pass. Reach for it when high is too slow/expensive but a real bug-catching review is still needed: it keeps the two things that reliably catch bugs cheaply — the finder fan-out and `build-test` (which mechanically catches compile/test failures) — and drops the depth passes with the lowest marginal yield. Measured against high on the same PR it lands at roughly **one-third to one-half** the time and tokens. It reliably catches mechanical defects (compile errors, failing tests) and obvious correctness bugs, but is **not an exhaustive correctness audit** — a subtle Critical that only the reverse audit or the adversarial personas would surface can slip; for a security-sensitive or pre-release review, use `--effort high`.
 - **high** — the full pipeline: parallel review agents (Step 3A/3B — the full dimension set including security, test-coverage, the language-pitfall and wrapper/proxy specialists 1d/1e, the adversarial personas 6a/6b/6c, and Agent 8), verification (Step 4), iterative reverse audit (Step 5), PR submission (Step 7), incremental cache (Step 8).
 
-At every effort level, the mechanics of obtaining the diff — worktree flow, diff capture, base resolution, chunk plan — are shared: the truncation and wrong-base traps this step exists for do not care how fast you want the answer. The _reviewed range_ can still differ: the incremental cache is a high-only feature, so a high re-review of a previously-reviewed PR may scope to `lastCommitSha..HEAD` while a low/medium pass (which never consults the cache) always reviews the full PR diff.
+The three levels above are the standing effort axis. **`--topology minimal` is a separate axis — a different _shape_ of review, not a depth of one — and it overrides the effort dispatch.** It is the A/B comparison arm from issue #9783: a single careful senior-engineer pass over the diff in this context, at most fifteen findings, each carrying a concrete failure scenario; no subagents, no build/test, no verification, no reverse audit, no posting, no incremental cache, no project rules. It exists so the full pipeline and this minimal prompt can be run over the same PR set and compared per model — the hypothesis being that the scaffolding's marginal value shrinks (even turns negative) as the model gets stronger. When the verdict's `topology` is `minimal`, capture the diff exactly as this step describes, then run **Step 3M** and skip everything else.
+
+At every effort level — and under `--topology minimal` — the mechanics of obtaining the diff — worktree flow, diff capture, base resolution, chunk plan — are shared: the truncation and wrong-base traps this step exists for do not care how fast you want the answer. The _reviewed range_ can still differ: the incremental cache is a high-only feature, so a high re-review of a previously-reviewed PR may scope to `lastCommitSha..HEAD` while a low/medium/minimal pass (which never consults the cache) always reviews the full PR diff.
 
 The parser already classified the target, so there is nothing to disambiguate by hand. For a `pr-url` target, determine if the local repo can access this PR:
 
@@ -165,7 +169,7 @@ Based on the parsed `target.type`:
     - `reason: cross-model-anchor` → the cached anchor was certified by another identity, so it was not used. Continue on the full-range plan (or, when `diffPath` is null, on the degraded state its siblings name). The command already said which identity certified it and which is running; repeat that to the user rather than restating it from the cache.
     - `effective: false` → the anchor was refused and the report says why. **Every reason names a CAUSE** — `not-an-ancestor` (a rebase or force-push); `unknown-commit`; `behind-merge-base` (the base moved past the anchor, e.g. a partial merge landed, and scoping to it would review base history the PR does not contain); `nothing-to-narrow` (the narrowing found nothing it could publish — all deterministic and all safe, because the round keeps the full range: an ordinary "undo per feedback" revert that puts lines back the way the base had them, so the PR's own diff no longer displays the undone FILE at all (a file the PR still displays does not refuse — the join fails closed and publishes its section whole instead); a capture on either side whose bytes do not survive a UTF-8 round trip; a delta the parser cannot read; and a fail-closed refusal where the two captures key the same change differently — a path or a rename git resolves differently across the two ranges — so narrowing would drop a change the PR's diff displays); `base-untrusted` (the base could not be fetched, so the clamp that keeps an anchor from scoping wider than the PR's diff could not be ruled); `capture-failed` (a capture threw, or the base fetch or merge-base resolution failed); `partition-failed` (the diff would not tile). **Whether a PLAN exists is a separate field: `diffPath`.** Non-null → the diff and plan are the full range; continue as a full review. Null → no diff exists at all: that is the `diffPath: null` degraded state (partial coverage, disclosed), whatever the reason says. Do not read one field for both facts — a reason that meant "planless" as well as "why" is what put deterministic refusals into the retry class below. The previous round's ledger is still owed its rulings in every refusal.
 
-  - **When the cache has no anchor, the PR itself carries one** (high effort only, same as the cache). The file being absent is the NORMAL state everywhere except the machine that ran the last review — CI, another clone, a colleague's checkout — and it used to mean the incremental range silently degraded to the full diff every time, which is precisely the cost incremental review exists to avoid. The anchor now rides the posted review: the machine ledger's marker carries `sha`, the head the last clean round reviewed, and `pr-context` writes it into the side file `qwen-review-pr-<n>-prev-ledger.json` with the rest of the ledger. So when the cache had no anchor to pass — 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 reviewed-at sha as `--since`**". Obey that sentence and do not compare the two identities yourself: the marker's `model` is a PROVIDER-QUALIFIED identity (`<model>@<digest>`) while `{{model}}` above is the bare model id, so they are not the same kind of string — comparing them by hand either never matches, which throws away this whole recovery path, or matches loosely, which accepts another provider's same-named model and scopes past code it never reviewed. A ledger section that states no verdict — because the side file survived from an earlier round the recovery could not re-vouch — is a mismatch: review the full range. The ledger's round is used only for precedence, and an `upToDate` anchor from the side file stops only when `comment.effective` is false). The decision lands AFTER the setup batch but BEFORE any agent launches, which is where the money is (a same-SHA stop still runs `cleanup`; it just fires three cheap commands later than the cache's fast path would have). An anchor that fails validation falls back to the full diff with the reason in the report, exactly as a rebased cache sha does. Two edges, both decided for you: if the side file's `round` is **higher** than the cache's, prefer the side file's sha — the cache is stale by a round some other environment posted; and a side file with no `sha` field means the last posted round was fail-closed (`compose-review` withholds the anchor then — Step 8 names the conditions), had its ledger truncated by the marker's size caps (a partial work list must not certify a range — the dropped entries would fall outside the next round's scope and retire silently), or predates the field — in every case there is no anchor to recover, and the review is full-range. (The side file may also carry `commitId` — the previous review's own `commit_id`. That is Step 6's **age reference** for the convergence posture, present even on fail-closed rounds; it is never an anchor, and scoping the diff to it would skip exactly the range a fail-closed round could not certify.)
+  - **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, and decide `--effort` off `effortSource`, not off whether the word `--effort` was typed. Pass the resolved level whenever `effortSource` is `explicit` **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`, or the high that `--comment` forces — that differs from the recorded one is NOT a passed-through default: pass it, so a recorded lower level refuses (`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:
     - **`{"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:
@@ -329,6 +333,8 @@ Do NOT inject review rules into Agent 7 (Build & Test) — it runs deterministic
 
 ## Step 3: Parallel review (high and medium effort)
 
+**If the verdict's `topology` is `minimal`, skip everything in this step and its sub-steps and run Step 3M instead** — the single-pass A/B arm defined after Step 3C. The rest of this dispatch applies only to `topology: auto`.
+
 **Steps 3A/3B and 4 run at high and medium effort; Step 5 (reverse audit) is high only.** At **low** effort skip 3A/3B/4/5 and run **Step 3C** instead — an inline pass with no subagents, defined after the agent dimensions. **Medium** runs 3A/3B and Step 4 with the reductions the effort table names: a smaller dimension set (skip the adversarial personas 6a/6b/6c, the language-pitfall and wrapper/proxy specialists 1d/1e, and the Agent 8 diff-specialists), a capped territory fan-out on large diffs (Step 3B below), and **no reverse audit** — it stops after Step 4. The incremental cache and PR posting stay high-only at medium too.
 
 Launch review agents by invoking all `agent` tools in a **single response**. The runtime executes agent tools concurrently — they will run in parallel. You MUST include all tool calls in one response; do NOT send them one at a time.
@@ -581,12 +587,36 @@ Low uses the standard finding format, including **Failure scenario**, and the re
 Then skip Steps 4 and 5 entirely and go to Step 6 with these adjustments:
 
 - Use Step 6's structure, but label the review **"Quick pass (effort: low) — findings are unverified"** (translated per output language) in the Summary, and skip verification stats (there was no verification).
+- Still make Step 6's `report_findings` call, with `level: "low"`. No findings artifact exists at this tier, so the entries come from the pooled list you just composed — `severity`, `file`/`line`, `summary`, `shortSummary`, `failureScenario` — with `confidence: "low"` only on the candidates you kept under `Confidence: low`, omitted elsewhere: the `low` level already labels the whole list unverified, and a blanket `confidence` would erase the one distinction the pass recorded. Step 6's delivery rule applies unchanged — a failure is disclosed and moved past, never a reason to change the findings.
 - Emit **no verdict** — no Approve / Request changes / Comment, and skip the open-Criticals re-check (that gate defends a verdict this pass does not claim). Chunks that are uncoverable by `maxLineChars` are still listed under "Not reviewed".
 - Follow-up tip (translated per output language, critical rule 2 — command keywords stay verbatim): "Tip: run `/review <target> --effort medium` for a verified balanced review, or `--effort high` for the full verified review." For a local review with findings, also offer the `fix these issues` tip.
 - Step 7 never runs — `--comment` forces high effort, and if the user asks to "post comments" after a quick pass, decline and point at `--effort high` (unverified findings must not be posted publicly).
 - Step 6B never runs either, and cannot: an effective `--fix` floors the effort at medium (Step 1), so no low pass is ever a `--fix` run. If the user asks to apply the findings after a quick pass, the same reasoning as posting applies with the target changed — editing their files on the strength of an unverified finding is the mistake, not publishing it — so point at `/review --fix`, which re-runs at medium and produces findings a verifier has ruled on.
 - In Step 8, save the report (marked with the effort level) but do **not** write the incremental cache — a quick pass must never make a later full review report "No new changes since last review". Step 9 cleanup runs as usual.
 
+## Step 3M: Minimal single pass (`--topology minimal`, the A/B arm)
+
+This arm exists for one reason: to be run over the same PR set as the full pipeline and compared, per model, so we learn whether the scaffolding still earns its cost (issue #9783). It is deliberately **not** the low-effort angle rotation — it is a single careful pass with no angle list, no sweep, no fan-out, and no verification. Do not "improve" it by re-adding the scaffolding; the whole point is to measure the pass without it.
+
+There are no subagents: you are the reviewer, in this context. Read the diff via the chunk plan — `read_file` per chunk range, paging oversized chunks; the read-cap rules from Step 1 apply unchanged, and chunks whose `maxLineChars` exceeds the read cap are uncoverable here exactly as in 3A. (For a file-path review of an unchanged file there is no plan — read the whole file, paging until `isTruncated` is false, per Step 1's no-diff branch.) Where a hunk is ambiguous without its surroundings, you may read the enclosing function (cross-repo lightweight mode has no tree — review from the diff alone there); do **not** grep the codebase and do **not** build or run anything. Project rules are not loaded (Step 2 is skipped).
+
+Review this diff the way a careful senior engineer would, in one pass. For every changed line ask what input, state, timing, or platform makes it wrong; for every deleted or replaced line ask where the invariant it enforced is re-established; watch for the failure modes the change itself introduces. Do not rotate the pass into separate angle walks — that is the low tier, not this one.
+
+Report **at most fifteen findings**, most severe first, each in the standard finding format. The quality bar that stands in for the scaffolding is the **Failure scenario**: every finding must name the concrete input/state/timing that triggers it and the wrong outcome that results (or, for a quality finding, the concrete cost). A finding for which you cannot construct a scenario is not reported — drop it at the source rather than filing it half-believed. The reporting gate applies unchanged: a Suggestion with no concrete scenario or cost is dropped; a suspected Critical you cannot pin down is kept with `Confidence: low`. Sort by severity. If the diff is genuinely clean, report nothing — do not pad toward the cap.
+
+Then skip Steps 4 and 5 entirely and go to Step 6 with these adjustments:
+
+- Use Step 6's structure, but label the review **"Minimal pass (topology: minimal) — findings are unverified"** (translated per output language) in the Summary, and skip verification stats (there was no verification).
+- Still make Step 6's `report_findings` call, with `level: "low"`. No findings artifact exists on this arm (the Step 8 bullet forbids creating one), so the entries come from the composed finding list — `severity`, `file`/`line`, `summary`, `shortSummary`, `failureScenario` — with `confidence: "low"` only on the candidates you kept under `Confidence: low`, omitted elsewhere: the `low` level is the only one clients render the unverified marker for, and it already labels the whole list unverified — passing the resolved effort instead (high on a PR target) would render these unverified findings indistinguishably from a verified high-effort review, and a blanket `confidence` would erase the one distinction the pass recorded. Step 6's delivery rule applies unchanged — a failure is disclosed and moved past, never a reason to change the findings.
+- Emit **no verdict** — no Approve / Request changes / Comment, and skip the open-Criticals re-check. Chunks that are uncoverable by `maxLineChars` are still listed under "Not reviewed".
+- Offer no follow-up tip from Step 6's list — its `post comments` tips key on `comment.effective` being false, which this arm forces, so they would invite exactly the posting this arm declines, and Step 6's trigger-phrase handler routes that ask toward Step 7. The only follow-up this arm offers is the pointer to `/review <target> --effort high`.
+- Step 7 never runs and cannot: the parser forced `comment.effective` to false for this topology. If the user asks to post the findings, decline and point at `/review <target> --effort high` (unverified findings must not be posted publicly).
+- Step 6B never runs either: the parser forced `fix.effective` to false. If the user asks to apply the findings, point at `/review --fix`, which re-runs at medium with verified findings.
+- In Step 8, save the report (marked `topology: minimal`) but do **not** create or register the structured artifact and do **not** write the incremental cache — the artifact persists a composed verdict and this pass emits none, so there is no composed input for `save-artifact` to read, and a cache write would make a later full review report "No new changes since last review". Step 9 cleanup runs as usual.
+- Step 9's completion line takes the `minimal pass, not posted (<N> unverified findings)` disposition — the one Step 9's list reserves for this topology.
+
+(Why Step 3M repeats Step 3C's closing adjustments almost verbatim rather than referencing them: the two passes are different experiments and each must stay readable on its own. The shared parts — no posting, no fix, no cache, no verdict — are the same for the same reason in both: an unverified single-context pass must not publish, edit, or certify.)
+
 ## Step 4: Deduplicate, verify, and aggregate (high and medium effort)
 
 ### Deduplication
@@ -818,11 +848,11 @@ Render the rulings as a short table at the top of the Findings section — id, o
 
 **A re-review that keeps posting new non-Critical findings is the motor of a feedback loop this pipeline has measured from the outside**: every push triggers a fresh review, the review files findings on code the previous round just added, the next push implements them, and the diff widens — which allocates more agents, which file more findings. One managed PR rode that loop to +13k lines across 8 rounds with its per-round Critical count flat, and was closed unmerged; the growth was 78–86% test lines. Bug-finding never converges a loop — only the **posting bar** can, and it must rise as rounds accumulate, exactly the discipline a senior reviewer applies by hand ("after ~5 rounds, only blockers; defer the rest, on the record"). This posture is that discipline, made the default. It governs **what posts to the PR**, never what is found, verified, or reported in the terminal: `RECALL` still binds every finder, Step 4 still verifies, the artifact and the terminal report still carry everything.
 
-**Resolve the floor first.** The Step 1 verdict's `severityFloor` is `critical`, `suggestion`, or `auto`. Explicit values are the operator's call: `critical` applies the Critical-only posture from round 1; `suggestion` turns the posture **off** — every round posts Suggestions, and the code-age rule below does not run. `auto` — the default — resolves here, where the round is known: **this review is round `prev ledger round + 1`**, and the round that decides the posture is the SIDE FILE's — the same read `compose-review` stamps into the marker and the deferral clause; the local cache's round scopes the diff but never decides the posture, or the body and the marker would disagree about which round ran (no recovered ledger → round 1 → no posture). Through round 5 the floor is `suggestion`; **from round 6 it is `critical`**. In the **context-unavailable** state the round is unknowable — the ledger this rule counts from could not be recovered by a run that could not read the PR — so treat `auto` as round 1: no posture, full posting, and say so in the terminal report (the deterministic marker still stamps its own count from the side file; a posting bar in doubt fails open, bookkeeping does not). Carry the **verdict's `severityFloor` into the compose state UNRESOLVED** — explicit values as they are, and `auto` as the literal string `auto`, never as the level it resolved to this round: the module licenses `auto` by the round it derives itself, and a round-resolved `suggestion` is indistinguishable from the operator's explicit posture-off override — passing it would turn every legal rounds-2–5 age-rule deferral into an unlicensed one. The resolution in this paragraph decides what YOU post; the state field carries the policy. **The module also enforces the floor itself**: a Suggestion still drafted inline past a resolved `critical` floor is moved into the deferral list mechanically by `compose-review`/`submit` (the composed result's `floorEnforced` names the moved indices, the posted body discloses the move, and `submit` drops those comments from the write). Your Step 6 routing stays the primary path — the enforcement is the backstop that keeps the posted set lawful when the routing drifts, so a submit report showing fewer inline comments than you drafted under a critical floor is the floor working, not a lost finding. Three consequences of it being mechanical: the backstop classifies by the drafted severity MARKER alone — it cannot re-derive confidence or a Nice-to-have, so keeping low-confidence and Nice-to-have findings OUT of the drafted comments (as this step already mandates) is what keeps them out of the published deferral list too; **leave moved comments IN the comments file and the submit payload** — the CLI removes them from the write itself, and hand-removing them "to match" makes both boundaries recompute over the reduced set and erases the deferral record the move exists to keep; and the floor it enforces is the RESOLVED one (an explicit `critical`, or `auto` from round 6), recovered where possible from the CLI's own record of the invocation rather than the state field alone.
+**Resolve the floor first.** The Step 1 verdict's `severityFloor` is `critical`, `suggestion`, or `auto`. Explicit values are the operator's call: `critical` applies the Critical-only posture from round 1; `suggestion` turns the posture **off** — every round posts Suggestions, and the code-age rule below does not run. `auto` — the default — resolves here, where the round is known: **this review is round `prev ledger round + 1`**, and the round that decides the posture is the SIDE FILE's — the same read `compose-review` stamps into the marker and the deferral clause; the local cache's round scopes the diff but never decides the posture, or the body and the marker would disagree about which round ran (no recovered ledger → round 1 → no posture). Through round 5 the floor is `suggestion`; **from round 6 it is `critical`** — **and it is `critical` from ANY round once the side file's `flatRounds` is at its bar of 2**. That streak is the signal-driven early trigger: `compose-review` measures each round's first-time-finding rate against the previous round's, stamps the consecutive not-falling count into the marker as `flatRounds`, and engages the floor ahead of schedule when the count reaches 2 — acting on the convergence paragraph's own "drop to `--severity-floor critical`" advice instead of only printing it. You cannot evaluate that trend yourself (it is a deterministic join over the ledger, which is exactly why the module owns it), so your routing follows the **marker**: `flatRounds >= 2` in the side file means the floor is `critical` for this round and every later round of this PR — route Suggestions to the deferral channel accordingly. On the round the streak first reaches the bar you will usually have drafted under the open posture; the enforcement backstop below moves those Suggestions mechanically and the posted body discloses the move with the streak that armed it — that is the trigger working, not a lost finding. Once engaged the trigger **latches**: the streak is pinned in the marker rather than re-measured (the floor itself quiets the posted-set trend it reads), so it does not release on a quiet round — an explicit `--severity-floor suggestion` remains the only way back to full posting. In the **context-unavailable** state the round is unknowable — the ledger this rule counts from could not be recovered by a run that could not read the PR — so treat `auto` as round 1: no posture, full posting, and say so in the terminal report (the deterministic marker still stamps its own count from the side file; a posting bar in doubt fails open, bookkeeping does not). Carry the **verdict's `severityFloor` into the compose state UNRESOLVED** — explicit values as they are, and `auto` as the literal string `auto`, never as the level it resolved to this round: the module licenses `auto` by the round it derives itself, and a round-resolved `suggestion` is indistinguishable from the operator's explicit posture-off override — passing it would turn every legal rounds-2–5 age-rule deferral into an unlicensed one. The resolution in this paragraph decides what YOU post; the state field carries the policy. **The module also enforces the floor itself**: a Suggestion still drafted inline past a resolved `critical` floor is moved into the deferral list mechanically by `compose-review`/`submit` (the composed result's `floorEnforced` names the moved indices, the posted body discloses the move, and `submit` drops those comments from the write). Your Step 6 routing stays the primary path — the enforcement is the backstop that keeps the posted set lawful when the routing drifts, so a submit report showing fewer inline comments than you drafted under a critical floor is the floor working, not a lost finding. Three consequences of it being mechanical: the backstop classifies by the drafted severity MARKER alone — it cannot re-derive confidence or a Nice-to-have, so keeping low-confidence and Nice-to-have findings OUT of the drafted comments (as this step already mandates) is what keeps them out of the published deferral list too; **leave moved comments IN the comments file and the submit payload** — the CLI removes them from the write itself, and hand-removing them "to match" makes both boundaries recompute over the reduced set and erases the deferral record the move exists to keep; and the floor it enforces is the RESOLVED one (an explicit `critical`, `auto` from round 6, or `auto` with the `flatRounds` streak at its bar), recovered where possible from the CLI's own record of the invocation rather than the state field alone.
 
 **At floor `critical`, a non-Critical finding that would otherwise post is recorded, not requested.** The deferrable set is exactly the set the floor takes away: **high-confidence Suggestions** — the findings a `suggestion`-floor round would have drafted inline. Low-confidence findings and Nice-to-haves were never posted at any floor and **stay terminal-only exactly as before**: routing them through the deferral list would _publish_ to the PR what the review contract keeps out of it, and inflate the list the posture exists to keep small. A deferred finding has been through Step 4 like any posted one — the deferral list publishes its one-line claims in the body, so `compose-review`'s verifier-delivery floor counts deferred findings exactly as posted ones; an unverified claim does not become publishable by being deferred. (Deterministic findings are the exception on both sides at once: a `[build]`/`[test]`/`[probe]` finding is pre-confirmed, Step 4 launches no verifier for it, and the floor excludes it — by its `source` field.) Each deferred finding stays in the findings artifact and the terminal report under its own grouping — "Deferred (convergence posture)" — and enters the compose state's `deferredSuggestions` as a **TYPED entry, one object per finding, copied from the artifact's own fields**: `{"file": "src/a.ts", "line": 42, "source": "test", "severity": "Suggestion", "title": "mutation survivor on the retry guard"}` (`line` optional; a pattern aggregate adds `"locations": N` for its further locations). This is a data field, not a sentence: `compose-review` derives deterministic from `source`, relocates a `severity: "Critical"` entry into the body Criticals (a Critical is never deferred), refuses a `"Nice to have"` (terminal-only) or any malformed entry, and RENDERS the human line `file:line — [source] title` itself — never write that line into the state, and never re-type the fields: read them out of the findings artifact you just wrote. It is **not** drafted into the `comments` array, **not** counted toward `S`, and casts no vote on the event: `compose-review` renders the list as a disclosed, non-capping paragraph — up to 20 entries, each capped at 240 characters, with an overflow count pointing at the run report — so the deferral is on the PR record without opening a thread that regenerates a round, and anything past the rendered cap survives in full in the findings artifact and the terminal report (say so there when the cap trims the list). A previous-round **non-Critical** ledger entry that still stands is ruled in the status table as `still stands — deferred (convergence posture)` and is likewise not re-posted; it leaves the machine ledger (`buildLedger` ingests only posted findings), and the deferral list plus the original round's thread remain its record. **A Critical is never deferred — any round, any floor**: new Criticals post, still-standing ledger Criticals re-post under their original ids, and every Critical ruling above runs unchanged. An APPROVE composed over a non-empty deferral list opens "No blocking issues" instead of "No issues found" — `compose-review` owns that wording.
 
-**Rounds 2–5 carry a narrower gate: the code-age rule.** With an `auto` floor resolved to `suggestion` — never under an explicit `--severity-floor suggestion`, which turns the posture off, this rule included — a **new otherwise-postable finding — the same deferrable set as above, high-confidence Suggestions only, never low-confidence or Nice-to-have entries** — anchored on code **unchanged since the previous round's reviewed head** is deferred the same way — the previous round read that code and did not flag it, so filing a nit on it now is re-derivation churn, not signal. (Carried-forward entries keep their original ids and are not "new"; this gates first appearances only.) The age reference is the side file's `commitId` — the previous review's own `commit_id`, set by GitHub when the round posted. It is an **age reference, never an incremental anchor**: the ledger's `sha` stays the only range certification, withheld on fail-closed rounds on purpose, while `commit_id` exists on every posted round — a posting bar needs a reference point, not a certification, which is exactly why the fail-closed full-range re-review (the common case in a bot loop) can still apply this rule. Validate it inside the worktree — `git cat-file -e <commitId>^{commit}` and `git merge-base --is-ancestor <commitId> HEAD` — and decide age with `git --literal-pathspecs diff <commitId>..HEAD --unified=0 -- '<file>'`: a finding whose anchor line falls inside a changed hunk is new-code and posts. **Two diff-output doubt states fail OPEN like every other arm, never toward suppression**: run the command from the worktree ROOT, and before reading its silence, prove the pathspec matches — `git cat-file -e HEAD:'<file>'` (tree-relative, cwd-independent); a non-matching pathspec means the diff's emptiness is about the PATH, not the code — skip the age rule for that finding, it posts. And a NON-empty diff with zero `@@` hunks (a `.gitattributes` `binary`/`-diff` mark, which the PR controls) is a file-level CHANGE — the finding posts; only a matching pathspec with a genuinely empty diff reads as unchanged. **A pattern aggregate is aged per location**: it posts (as the usual aggregated comment) if ANY of its `locations[]` falls inside a changed hunk — the changed entrance is new-code and must not ride out a round inside a deferral line — and defers only when EVERY location is unchanged and covered; its deferral line names the root anchor with the location count (`a.ts:10 (+2 locations)`). **Both operands are hostile-input-hardened, and neither hardening is optional.** The path is PR-controlled: unquoted, a filename like `x;touch PWNED` ends the argument and executes the tail as a command, so the path rides in single quotes (a `'` inside the name becomes `'\''`); and without `--literal-pathspecs` (a global option — it must precede `diff`) a name carrying glob metacharacters is a wildcard pathspec, so `foo[1].ts` matches the _sibling_ `foo1.ts` and the finding is aged against the wrong file's hunks. **The rule also needs the previous round to have actually read the code it vouches for.** Its premise is "the previous round saw this code and did not flag it" — so before deferring, check the previous round's own review body: **the review whose id the side file's `reviewId` names** (pr-context renders review bodies whole up to an 8,000-character cap, with a fetch note at the cut; with several summaries on the PR, the id decides which body's disclosures bind — checking a different body can vouch for code the true previous round never read). A body whose render carries the truncation note is consulted only after running that note's fetch, redirected to a file exactly as the blocker re-check prescribes — a "Not reviewed" disclosure past the cap is invisible, and ruling on the visible prefix would defer a finding on code nobody read. A body that cannot be read whole: skip the age rule. One absence is benign and decided, not skipped: a previous round that converged clean posts the canonical LGTM body, which pr-context filters from the render — that body has no disclosures BY DEFINITION (a capped or partial round never composes it), so a `reviewId` whose body is absent because it matched the canonical LGTM filter is disclosure-free, and the age rule proceeds. A finding whose file falls in scope that round disclosed as not reviewed — a named unread chunk or dimension covering it, or the scope-wide "could not certify that any of this diff was reviewed" opener — gets no age suppression; the premise is false there, and a first-time Suggestion in code nobody read must post like any round-1 finding. When the `commitId` field is absent (older rounds, or a run whose recovery came up empty — pr-context strips a stale file's `commitId` then), the recorded `commitId` fails the validation above (rebase), there is no worktree (lightweight mode), or Step 1 set the **context-unavailable** state (this run's pr-context failed, so the side file may be a previous run's leftovers), **skip the age rule, not the review** — full posting, exactly as before. The Exclusion Criteria's newly-reachable exception extends across rounds unchanged: a finding on unchanged code that this round's changes make **newly reachable or newly wrong** is new-code by that fact, and posts.
+**Rounds 2–5 carry a narrower gate: the code-age rule.** With an `auto` floor resolved to `suggestion` — never under an explicit `--severity-floor suggestion`, which turns the posture off, this rule included — a **new otherwise-postable finding — the same deferrable set as above, high-confidence Suggestions only, never low-confidence or Nice-to-have entries** — anchored on code **unchanged since the previous round's reviewed head** is deferred the same way — the previous round read that code and did not flag it, so filing a nit on it now is re-derivation churn, not signal. (Carried-forward entries keep their original ids and are not "new"; this gates first appearances only.) The age reference is the side file's `commitId` — the previous review's own `commit_id`, set by GitHub when the round posted. It is an **age reference, never an incremental anchor**: the ledger's `sha` stays the only range certification, withheld on fail-closed rounds on purpose, while `commit_id` exists on every posted round — a posting bar needs a reference point, not a certification, which is exactly why a full-range re-review (still the shape whenever no own anchor is usable — no own marker on the PR carries one, the graft's certifier mismatches this round's identity, or the markers predate the field) can still apply this rule. Validate it inside the worktree — `git cat-file -e <commitId>^{commit}` and `git merge-base --is-ancestor <commitId> HEAD` — and decide age with `git --literal-pathspecs diff <commitId>..HEAD --unified=0 -- '<file>'`: a finding whose anchor line falls inside a changed hunk is new-code and posts. **Two diff-output doubt states fail OPEN like every other arm, never toward suppression**: run the command from the worktree ROOT, and before reading its silence, prove the pathspec matches — `git cat-file -e HEAD:'<file>'` (tree-relative, cwd-independent); a non-matching pathspec means the diff's emptiness is about the PATH, not the code — skip the age rule for that finding, it posts. And a NON-empty diff with zero `@@` hunks (a `.gitattributes` `binary`/`-diff` mark, which the PR controls) is a file-level CHANGE — the finding posts; only a matching pathspec with a genuinely empty diff reads as unchanged. **A pattern aggregate is aged per location**: it posts (as the usual aggregated comment) if ANY of its `locations[]` falls inside a changed hunk — the changed entrance is new-code and must not ride out a round inside a deferral line — and defers only when EVERY location is unchanged and covered; its deferral line names the root anchor with the location count (`a.ts:10 (+2 locations)`). **Both operands are hostile-input-hardened, and neither hardening is optional.** The path is PR-controlled: unquoted, a filename like `x;touch PWNED` ends the argument and executes the tail as a command, so the path rides in single quotes (a `'` inside the name becomes `'\''`); and without `--literal-pathspecs` (a global option — it must precede `diff`) a name carrying glob metacharacters is a wildcard pathspec, so `foo[1].ts` matches the _sibling_ `foo1.ts` and the finding is aged against the wrong file's hunks. **The rule also needs the previous round to have actually read the code it vouches for.** Its premise is "the previous round saw this code and did not flag it" — so before deferring, check the previous round's own review body: **the review whose id the side file's `reviewId` names** (pr-context renders review bodies whole up to an 8,000-character cap, with a fetch note at the cut; with several summaries on the PR, the id decides which body's disclosures bind — checking a different body can vouch for code the true previous round never read). A body whose render carries the truncation note is consulted only after running that note's fetch, redirected to a file exactly as the blocker re-check prescribes — a "Not reviewed" disclosure past the cap is invisible, and ruling on the visible prefix would defer a finding on code nobody read. A body that cannot be read whole: skip the age rule. One absence is benign and decided, not skipped: a previous round that converged clean posts the canonical LGTM body, which pr-context filters from the render — that body has no disclosures BY DEFINITION (a capped or partial round never composes it), so a `reviewId` whose body is absent because it matched the canonical LGTM filter is disclosure-free, and the age rule proceeds. A finding whose file falls in scope that round disclosed as not reviewed — a named unread chunk or dimension covering it, or the scope-wide "could not certify that any of this diff was reviewed" opener — gets no age suppression; the premise is false there, and a first-time Suggestion in code nobody read must post like any round-1 finding. When the `commitId` field is absent (older rounds, or a run whose recovery came up empty — pr-context strips a stale file's `commitId` then), the recorded `commitId` fails the validation above (rebase), there is no worktree (lightweight mode), or Step 1 set the **context-unavailable** state (this run's pr-context failed, so the side file may be a previous run's leftovers), **skip the age rule, not the review** — full posting, exactly as before. The Exclusion Criteria's newly-reachable exception extends across rounds unchanged: a finding on unchanged code that this round's changes make **newly reachable or newly wrong** is new-code by that fact, and posts.
 
 The posture binds the posting path; low and medium never post, so for them it changes only the terminal grouping. It is also why a braked or human-fatigued PR can converge: a clean late round with only deferrals composes an APPROVE that ends the loop, with the deferred list on the record for a follow-up.
 
@@ -910,6 +940,8 @@ Write every confirmed finding — high and low confidence alike — as a JSON ar
 
 Each entry carries `id` (unique — outcomes and resolved anchors both join on it), `severity`, `confidence`, `source`, `summary`, `failureScenario`, and either `file`/`line`/`anchor` or, for a pattern aggregate, a `locations[]` array with **one entry per location** (`suggestedFix`, `fixWitness`, `category`, `shortSummary` and `witness` are optional; `shortSummary` is derived from `summary` when absent; `witness` is the Step 4 witness — the executed evidence, or its `not run — <reason>` line — carried as data so the report and the comment bodies quote one recorded string instead of transcribing it twice more; `fixWitness` is the acceptance criterion the finding format asks for — the test that must go red if the suggested fix is removed, or `N/A` — carried for the same reason and read back by Step 7's comment body). The command validates the shape, refuses a duplicate id, refuses a finding with no failure scenario, sorts by severity → confidence → file → line → id, and writes counts nobody then recomputes by hand. Read the artifact for the numbers you quote in the Summary. This is a **canonicalization**, not a gate: it does not decide the verdict — `compose-review` does that, from the same findings — and it does not run at low effort, where the pass is unverified and emits no verdict.
 
+**Then speak the same list to the client, in-band — one `report_findings` tool call.** The artifact is the canonical record, but it is a file on disk registered after the fact (Step 8); every client rendering this session live — the TUI, the Web Shell transcript, an ACP host — otherwise sees only the prose restatement, which is the transcription surface the artifact exists to close. Immediately after the artifact is written, call the `report_findings` tool once (load it via `tool_search` if it is not in your tool list) — each call replaces the whole list, and Step 6B re-issues it with outcomes after a fix run — with `level` set to this review's effort and one entry per finding **copied from the artifact you just wrote** — `id`, `severity`, `confidence`, `source`, `file`/`line` (a pattern aggregate passes its first location; the artifact keeps the rest), `summary`, `shortSummary`, `failureScenario`, `category` — never re-typed from the terminal prose: the artifact is the oracle, and a re-derived severity here is the same drift the marker rule below closes. A finding the convergence posture deferred is still a finding — report it under its `D<round>-<n>` id like any other. **The tool's contract is harder-bounded than the artifact's, and a violation refuses the whole call**: at most 50 findings, with per-field length caps the schema states. When the artifact outgrows those bounds, do not let the call die on them — pass the first 50 findings in artifact order (the artifact is already sorted most-severe-first) and say in the terminal summary how many the cap cut, and shorten an over-cap `summary`/`failureScenario` — or `outcomeNote` on the Step 6B re-report — to fit rather than dropping the entry (the artifact keeps the full-length text, so nothing is lost by a delivery-only shortening). This is the one sanctioned departure from copy-verbatim, and it is a departure of length only, never of severity, confidence, or meaning — a bounded list delivered beats a complete list refused. This call is UI delivery, not bookkeeping: it persists nothing and decides nothing, and a failure (or an environment where the tool is not registered and `tool_search` cannot find it) is disclosed and moved past — never a reason to touch the artifact, the compose state, or the verdict, exactly the rule `record_artifact` follows in Step 8.
+
 **The severities in this artifact are the canonical ones — draft the inline markers and the compose state FROM it, not from the list you typed by hand.** Ordering alone does not close the loop: `compose-review` reads `comments.json` and `compose.json`, both hand-written, so a hold that lowered a severity here still ships as `**[Critical]**` in the payload if the marker was copied from the draft instead of the artifact. Read `severity` out of `findings.json` for every marker and for the body Criticals.
 
 **This section sits before `### Verdict` on purpose.** `--test-delta` can lower a severity, and a Critical held back after `compose-review` has run reaches only the Step 8 report: the verdict line, the drafted `**[Critical]**` marker and the payload Step 7 recounts were all fixed before the measurement was consulted (measured; DESIGN.md — The four-round misattributed Critical (#8368)). If a hold does land after composing — a later round, a re-verified finding — treat it as a comment-set change: redraft the marker, update the comments file, and run `compose-review` again.
@@ -991,9 +1023,11 @@ 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.
+
 Report the outcome counts in the terminal summary, and list each `skipped` finding with its reason. **Do not re-run Steps 1–6** to check your own work: a re-review of a tree you just edited is a new review of different code, and its verdict is not this review's.
 
-Append a follow-up tip after the verdict (high and medium effort — only a **low** quick pass emits no verdict and uses Step 3C's tip instead; its "post comments" follow-up is declined per Step 3C). **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, and Agent 8 — and can certify Approve)." Choose the rest based on remaining state:
+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, 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.
@@ -1001,16 +1035,16 @@ Append a follow-up tip after the verdict (high and medium effort — only a **lo
 - **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`) rather than leaving the list and the tree disagreeing about what was applied.
+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 "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.
+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.
 
 ## Step 7: Submit PR review
 
 **This step lives in `references/posting.md` — read it with `read_file` from this skill's base directory the moment posting becomes live for this run, and follow it.** Posting is live when the Step 1 verdict reported `comment.effective: true`, or when the user asks in this session to post or publish the comments. Do not read it on a run that will not post. What binds every run, posted or not:
 
 - Never run a `gh` command that writes to the pull request — nor an `a1` command that writes to the MR — `qwen review submit` is the only write path in this skill, and it refuses when the run is not authorised. The one carve-out is Step 4's render-adjudication post to the user-designated `QWEN_REVIEW_SCRATCH_REPO` — that repo, that check, nothing else.
-- Posting is a PR-only, high-only action: on a non-PR target there is nothing to post to, and at **low or medium** effort a "post comments" follow-up is declined with a pointer at `--effort high` (low's findings are unverified; medium's verdict is capped at Comment — `--comment` forces high).
+- Posting is a PR-only, high-only action: on a non-PR target there is nothing to post to, and at **low or medium** effort — or under `--topology minimal` — a "post comments" follow-up is declined with a pointer at `--effort high` (low's findings are unverified; medium's verdict is capped at Comment — `--comment` forces high; minimal's findings are unverified and the arm posts nothing).
 - You do not author PR-facing prose: `compose-review` computes the review body, and the only text that reaches the PR is that computed body plus the inline finding comments, both riding the one sanctioned write `references/posting.md` defines.
 
 ## Step 8: Save review report and cache
@@ -1041,6 +1075,7 @@ where `<target>` is the same suffix as above (`pr-6740`, `local`, a filename) an
 - `<verdict>, not posted (<C> Critical, <S> Suggestion)` — **high or medium** effort without `--comment`/publish authorization (medium never posts — `--comment` forces high); `<verdict>` is Approve / Request changes / Comment (a medium verdict never exceeds Comment — see Step 5).
 - `<verdict>, partial (<N> inline posted, summary posted)` — Aone mid-batch failure only: `submit` answered `{"posted": false, "partial": true}` (part of the review IS on the MR). Use `summary not posted` when `summaryPosted` is false. This disposition is NEITHER `posted` NOR `not posted` — see the Aone refinements below — and it never carries a `Posted:` line.
 - `quick pass, not posted (<N> unverified findings)` — **low** effort only.
+- `minimal pass, not posted (<N> unverified findings)` — `--topology minimal` only (Step 3M). Minimal emits no verdict, so it cannot take a `<verdict>, not posted` form, and it is not the low tier, so it cannot take the quick-pass form either — this disposition is the only contract-conformant line for the arm.
 
 For any `posted` disposition, the line immediately **above** this one is `Posted: <url>` — the review link `submit` returned (Step 7) — or, when Step 7's platform fallback says the link was not returned, the no-link note that fallback prescribes. The link rides its own line because the completion line's shape is fixed and scrapers must not have to strip a URL out of it.