@qwen-code/qwen-code 0.23.0 → 0.23.1-preview.1

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

@@ -37,7 +37,7 @@ If there are no uncommitted changes, `/review` will let you know and stop — no
 
 | Level    | What runs                                                                                                                                                   | Findings cap        | Verdict                             | Posts to PR      |
 | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------- | ---------------- |
-| `low`    | 3-6 directed inline angles over the diff (scaled by diff size) plus a gap sweep — no subagents, no build/test, no project rules                             | 10 (unverified)     | None                                | Never            |
+| `low`    | 3-6 directed inline angles over the diff (scaled by diff size) plus a gap sweep and an under-floor re-pass — no subagents, no build/test, no project rules  | 10 (unverified)     | None                                | Never            |
 | `medium` | The high pipeline minus its most expensive passes: the parallel finder fan-out over a reduced dimension set, plus build/test and a single verification pass | Uncapped (verified) | Approve capped at Comment           | Never            |
 | `high`   | Full pipeline: up to 16 parallel agents → sharded verification → iterative reverse audit                                                                    | Uncapped (verified) | Approve / Request changes / Comment | With `--comment` |
 
@@ -51,7 +51,8 @@ The `/review` command runs a multi-stage pipeline:
 Step 1:  Determine scope + effort level (local diff / PR worktree / file)
          Capture the diff to a file + partition it into chunks
 Step 2:  Load project review rules (medium/high)
-Step 3C: low effort: 3-6 inline angles + gap sweep     [0 subagent calls]
+Step 3C: low effort: 3-6 inline angles + gap sweep + under-floor re-pass
+                                                               [0 subagent calls]
 Step 3A: high, <=500 src AND <=3200 total: up to 16 agents  [16+ LLM calls]
            |-- Agent 0: Issue Fidelity & Root-Cause Ownership
            |-- Agent 1a: Correctness — line-by-line scan
@@ -115,17 +116,18 @@ Steps 3A/3B/4/5 are the high-effort pipeline; at `--effort low|medium` a single
 | Agent 3c: Consistency & clarity   | Sibling consistency (a guard one member of a parallel family has but its twin lacks), convention drift against a cited local example, misleading names/comments, needless complexity                                                                                                            |
 | Agent 4: Performance & Efficiency | N+1 queries, memory leaks, unnecessary re-renders, bundle size                                                                                                                                                                                                                                  |
 | Agent 5: Test Coverage            | Untested code paths in the diff, missing branch coverage, weak assertions                                                                                                                                                                                                                       |
-| Agent 6: Undirected Audit         | 3 parallel personas (attacker / 3am-oncall / maintainer) — catches cross-dimensional issues                                                                                                                                                                                                     |
+| Agent 6: Undirected Audit         | 3 parallel personas (attacker / 3am-oncall / maintainer) — catches cross-dimensional issues — plus the counter-frame audit (6d, PR targets at high effort): reads the PR description only to EXCLUDE its nominated topics and replay its motivating incident the day after the merge            |
 | Agent 7: Build & Test             | Runs build and test commands, reports failures                                                                                                                                                                                                                                                  |
 | Agent 8: Diff-specialized finders | 0-2 extra finders written per-review when the diff concentrates in a domain with known failure modes (reconnect logic, module loaders, schedulers, codecs)                                                                                                                                      |
+| `prose-exec`: Prose execution     | When the diff touches an instruction file (a `SKILL.md`, `AGENTS.md`/`CLAUDE.md`/`QWEN.md`, an agent or command definition, a `prompts/` file) and the review has a tree: EXECUTES the changed instructions in a disposable copy and files the gap between the run and what the prose promises  |
 
-The three Correctness agents are **procedural**: each is defined by how it walks the diff (line-by-line / deleted lines / cross-file edges), not by a bug taxonomy — so their coverage is complementary instead of overlapping. Two further dedicated angles (1d/1e) split the language-pitfall checklist and wrapper/proxy routing out of the line-by-line walk: a checklist pattern-match and a structural routing expectation are different attention modes, and folded into the walk they were diluted by its rhythm. The same reasoning splits **code quality into three** (3a/3b/3c): one agent holding a six-item checklist finishes one item — measured on a heavily-rewritten file, one agent holding an eight-item checklist found 1 of 5 defects and the same model split three ways found all 5 — so the quality checklist is cut where the questions genuinely differ. All agents run in parallel (Agent 1 launches 3 procedural variants and 2 dedicated angles, Agent 3 launches 3 checklist slices, and Agent 6 launches 3 persona variants concurrently, totaling up to 16 parallel tasks for same-repo PR reviews — Agent 1e runs only when the diff signals a wrapping type — plus 0-2 Agent 8 finders when the diff's domain calls for them, so 15-18 in practice; Agent 0 is skipped for local-diff and file-path reviews, which run 14-17; cross-repo lightweight mode also skips Agents 1c and 7, running 13-16).
+The three Correctness agents are **procedural**: each is defined by how it walks the diff (line-by-line / deleted lines / cross-file edges), not by a bug taxonomy — so their coverage is complementary instead of overlapping. Two further dedicated angles (1d/1e) split the language-pitfall checklist and wrapper/proxy routing out of the line-by-line walk: a checklist pattern-match and a structural routing expectation are different attention modes, and folded into the walk they were diluted by its rhythm. The same reasoning splits **code quality into three** (3a/3b/3c): one agent holding a six-item checklist finishes one item — measured on a heavily-rewritten file, one agent holding an eight-item checklist found 1 of 5 defects and the same model split three ways found all 5 — so the quality checklist is cut where the questions genuinely differ. All agents run in parallel (Agent 1 launches 3 procedural variants and 2 dedicated angles, Agent 3 launches 3 checklist slices, and Agent 6 launches 3 persona variants and the counter-frame audit 6d concurrently, totaling up to 17 parallel tasks for same-repo PR reviews — Agent 1e runs only when the diff signals a wrapping type — plus 0-2 Agent 8 finders when the diff's domain calls for them, so 16-19 in practice, and one more (`prose-exec`) when the diff touches an instruction file; Agent 0 and 6d are skipped for local-diff and file-path reviews, which run 14-17; cross-repo lightweight mode also skips Agents 1c and 7, running 14-17 with the PR identity and 12-15 without it).
 
 Every finding must state a **failure scenario** — the concrete input, state, or timing that triggers it and the wrong outcome that results (for quality findings, the concrete cost instead). A finding that cannot name its scenario is dropped at the source, and verification re-traces the claimed scenario through the real code rather than judging the finding's prose.
 
-Once a PR carries more than 500 lines of **source** change — or more than 3 200 diff lines in total, past which the fifteen whole-diff readers are each too diluted to read carefully (an attention bound, not a promise of fewer calls — heavy files and specialized finders can make 3B cost more) — this dimension fan-out is replaced by a **territory × dimension** fan-out: the diff is split into ~400-line chunks — boundaries fall on hunk boundaries, and a hunk too large to fit is split only at a top-level declaration, never inside a function — and each chunk gets its own agent that applies every review dimension to that chunk alone.
+Once a PR carries more than 500 lines of **source** change — or more than 3 200 diff lines in total, past which the sixteen whole-diff readers are each too diluted to read carefully (an attention bound, not a promise of fewer calls — heavy files and specialized finders can make 3B cost more) — this dimension fan-out is replaced by a **territory × dimension** fan-out: the diff is split into ~400-line chunks — boundaries fall on hunk boundaries, and a hunk too large to fit is split only at a top-level declaration, never inside a function — and each chunk gets its own agent that applies every review dimension to that chunk alone.
 
-The gate deliberately counts source lines rather than diff lines. Test code, prose and lockfiles dominate diff size — across this repo's last 40 merged PRs the median diff is 41% tests — so a gate on raw size would carve a 173-line production change into territories just because it shipped 489 lines of new tests, leaving that production code with one reviewer instead of fourteen lenses (the diff-reading dimension agents — sixteen minus Issue Fidelity and Build & Test). Chunking still covers every line either way, tests included; what the gate decides is how many reviewers there are and what each is asked to do. Fourteen diff-reading lenses all walking one large diff read the same early hunks fourteen times over; one agent per chunk means every line of the diff has exactly one accountable reviewer. Each chunk agent returns a `Covered:` receipt, and a chunk with no receipt is re-reviewed before the run proceeds — so "no blockers" can never be reported over code that nobody read.
+The gate deliberately counts source lines rather than diff lines. Test code, prose and lockfiles dominate diff size — across this repo's last 40 merged PRs the median diff is 41% tests — so a gate on raw size would carve a 173-line production change into territories just because it shipped 489 lines of new tests, leaving that production code with one reviewer instead of fifteen lenses (the diff-reading dimension agents — seventeen minus Issue Fidelity and Build & Test). Chunking still covers every line either way, tests included; what the gate decides is how many reviewers there are and what each is asked to do. Fifteen diff-reading lenses all walking one large diff read the same early hunks fifteen times over; one agent per chunk means every line of the diff has exactly one accountable reviewer. Each chunk agent returns a `Covered:` receipt, and a chunk with no receipt is re-reviewed before the run proceeds — so "no blockers" can never be reported over code that nobody read.
 
 A **source** file that is largely rewritten (an existing file of 300+ lines that is now 40%+ new, or has 800+ changed lines) also gets **three whole-file invariant agents**. Test and generated files never qualify — the checklist asks about fields, timers, and error taxonomies, which a rewritten test file does not have. Its bugs are usually not inside any one hunk but _between_ the new lines — a timer armed near the top of the file and a teardown path two thousand lines below. Each agent reads the whole post-change file and walks two or three items of a fixed checklist: mutable fields cleared on every exit path, timers cancelled on every close (and cancellation not discarding captured data), map inserts matched by deletes, retry counters incremented at every entry, status return values actually checked, error codes exhaustively classified permanent vs transient, config fields honoured on every path, and early returns that skip a required side effect.
 
@@ -433,27 +435,28 @@ For large diffs (>10 modified symbols), the caller-direction analysis prioritize
 
 The parts of the pipeline that are elastic in diff size are scaled from it, and the scaling is written into the diff plan so every stage reads one number rather than each deciding for itself:
 
-| Budget field    | What it scopes                      | How it scales                                                      |
-| --------------- | ----------------------------------- | ------------------------------------------------------------------ |
-| `inlineAngles`  | How many `low` angles run (Step 3C) | 3, plus one per 60 source lines, capped at the 6 angles that exist |
-| `sweep`         | Whether `low`'s gap sweep runs      | Off below 25 source lines                                          |
-| `specialistCap` | The Agent 8 ceiling                 | 0 below 80 source lines, otherwise 2                               |
-| `verifyShard`   | Findings per verification agent     | Flat at 8 — a property of the verifier, not of the diff            |
+| Budget field     | What it scopes                                   | How it scales                                                      |
+| ---------------- | ------------------------------------------------ | ------------------------------------------------------------------ |
+| `inlineAngles`   | How many `low` angles run (Step 3C)              | 3, plus one per 60 source lines, capped at the 6 angles that exist |
+| `candidateFloor` | When `low` owes one deterministic recall re-pass | `min(changed files, 4)`                                            |
+| `sweep`          | Whether `low`'s gap sweep runs                   | Off below 25 source lines                                          |
+| `specialistCap`  | The Agent 8 ceiling                              | 0 below 80 source lines, otherwise 2                               |
+| `verifyShard`    | Findings per verification agent                  | Flat at 8 — a property of the verifier, not of the diff            |
 
 Two things it deliberately does not do. It **never scales a dimension away**: which agents a review owes is decided by the roster, which reads the effort level, so a small diff still gets its security pass and its test-coverage pass. And it reads **source** lines, not diff lines — a 40-line production change shipping 900 lines of new tests is a small change, and the same reasoning already governs the territory-fan-out gate.
 
-Why the floors are where they are: on a nine-line typo fix, six inline walks are five walks over nothing, and the sweep — a fresh reader hunting what the first pass did not get to — has nothing to hunt when the first pass got to all of it. Agent 8's floor is the substantive one: "one domain dominates the diff" is a judgement, and a judgement made about forty lines finds a dominant domain every time, because forty lines are usually all one thing.
+Why the floors are where they are: on a nine-line typo fix, six inline walks are five walks over nothing, and the sweep — a fresh reader hunting what the first pass did not get to — has nothing to hunt when the first pass got to all of it. When a low-effort pass stays below `candidateFloor`, it takes one deterministic second look at every coverable hunk in the largest changed source file (falling back to the largest coverable file of any kind) and every coverable removed block. Files touching an uncoverable chunk are excluded from the target selection, and the pass always emits a receipt naming its target, new-candidate count, and any uncoverable chunks; when no file is coverable, it still checks the coverable removed blocks and discloses the missing target. The floor is a stopping signal, not a quota: a clean diff can still report no findings after that re-pass. Agent 8's floor is the substantive one: "one domain dominates the diff" is a judgement, and a judgement made about forty lines finds a dominant domain every time, because forty lines are usually all one thing.
 
 ## Token Efficiency
 
 The high-effort pipeline bounds each stage (shard size, audit rounds), but total calls scale with findings — `ceil(F/8)` verification shards — and, under 3B, with chunk count (reverse audit runs per chunk per round). Typical 3A profile:
 
-| Stage                            | LLM calls                       | Notes                                                                                                                                                                                               |
-| -------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Review agents (Step 3)           | 16 (+0-2)                       | Run in parallel; Agent 1e only when the diff signals a wrapping type (15 without it); cross-repo skips Agents 1c and 7 (14), local/file skips Agent 0 (15)                                          |
-| Sharded verification (Step 4)    | ceil(F/8)                       | F = findings; at most 8 per verification agent, launched together                                                                                                                                   |
-| Iterative reverse audit (Step 5) | 2-10 (3A); rounds × chunks (3B) | Two consecutive dry rounds to stop; the cap follows the topology — 10 on a small diff, 5 on a chunked one, 3 on a huge one when the run has a deadline. 3B fans out one auditor per chunk per round |
-| **Total**                        | **~19-30 (~17-29)**             | 3A same-repo: ~19-30 (typical ~19-21); cross-repo or local/file: ~17-29; one fewer when Agent 1e is not rostered; 3B scales with chunks (see DESIGN.md)                                             |
+| Stage                            | LLM calls                       | Notes                                                                                                                                                                                                                                                                                                                                                                          |
+| -------------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Review agents (Step 3)           | 17 (+0-2)                       | Run in parallel; Agent 1e only when the diff signals a wrapping type (16 without it); cross-repo skips Agents 1c and 7 (15 while the plan carries the PR identity, 13 without it — Agent 0 and 6d drop together); local/file skips Agent 0 and the counter-frame audit 6d (15); one more (`prose-exec`) on a diff that touches an instruction file, when the review has a tree |
+| Sharded verification (Step 4)    | ceil(F/8)                       | F = findings; at most 8 per verification agent, launched together                                                                                                                                                                                                                                                                                                              |
+| Iterative reverse audit (Step 5) | 2-10 (3A); rounds × chunks (3B) | Two consecutive dry rounds to stop; the cap follows the topology — 10 on a small diff, 5 on a chunked one, 3 on a huge one when the run has a deadline. 3B fans out one auditor per chunk per round                                                                                                                                                                            |
+| **Total**                        | **~20-31 (~16-29)**             | 3A same-repo: ~20-31 (typical ~20-22); cross-repo or local/file: ~16-29 (the floor is the identity-less cross-repo roster of 13); one fewer when Agent 1e is not rostered, one more when `prose-exec` is owed; 3B scales with chunks (see DESIGN.md)                                                                                                                           |
 
 Most PRs converge to the lower end of the range; the caps prevent runaway cost on pathological cases. At `--effort low` the review runs entirely inline — **0 subagent calls** — walking the diff once per angle instead of once in total.
 

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

@@ -34,6 +34,10 @@ These commands help you save, restore, and summarize work progress.
 | `/export`        | Export session history to file                                           | `/export html`, `/export md`, `/export json`, `/export jsonl` |
 | `/rename`        | Rename or tag the current session                                        | `/rename My Feature` or `/tag`                                |
 
+> [!note]
+>
+> Opening an HTML export loads the renderer for that exact Qwen Code version from `unpkg.com`. If the version has not been published or the renderer cannot be reached, the file shows a load error. Markdown, JSON, and JSONL exports remain self-contained.
+
 > [!note]
 >
 > `/summarize` is an alias for `/compress` (it compresses chat history — a destructive operation). To generate a non-destructive project summary instead, use `/summary`.
@@ -824,19 +828,56 @@ session, not from its user, and carries none of your authority there:
 the receiving session acts on it only within its own permission settings.
 Its user can choose what happens to incoming messages with
 `agents.crossSessionInbound` (`accept`, `hold`, or `refuse`). When unset,
-a message is delivered if the receiving session still reviews each
-action (default or plan mode), or if both sessions are in a mode that
-applies actions without per-action review; otherwise it is held for
-review. Held messages are listed and released with `/peers` in the
-receiving session.
+a message is delivered only when both sessions are in the same review
+class: both still review each action (default or plan mode), or both
+are in a mode that applies some actions without per-action review
+(auto-edit, auto, or yolo). A message from a session in the other class,
+or from a sender that does not say which class it is in, is held for
+review — in both directions. A session that reviews each action holds a
+message from one that does not, because that message was written by a
+model nobody was watching, and the per-action prompts guard actions, not
+what the session is being talked into. Held messages are listed and
+released with `/peers` in the receiving session, and a message held
+only because the modes differed is released on its own once they agree.
+
+A repository can make sessions opened in it more cautious, never less:
+a workspace `.qwen/settings.json` may set `agents.crossSessionInbound`
+to `hold` or `refuse`, or `agents.crossSessionMessaging` to `false`, and
+that value wins over a looser one in your user settings. A workspace
+value that would loosen your setting (`accept`, or `true` for the
+switch) is ignored with a warning, and a value the CLI does not
+recognize holds every message whenever it is the effective value.
+System settings override all of this, as they do for every setting.
+
+A hold does not wait forever. A message nobody decides on expires after
+`agents.crossSessionHeldExpiry` — `1m`, `5m`, `10m`, or `never`, five
+minutes by default — and the sending session is told that no decision
+came. Shortening the setting applies to messages already waiting.
+
+If the session cannot bind its inbox — the runtime directory is missing,
+owned by another user, or read-only, as it can be inside a container —
+it first tries a private directory under the temp directory, and only
+if that fails too does it start without one. When that happens the
+session says so at startup, and `/peers` repeats the reason and what to
+change (usually `XDG_RUNTIME_DIR` or `TMPDIR`).
+
+Two sessions can also resolve the same inbox address, because the address
+is keyed by process id and process ids repeat across containers that share
+a runtime directory. The session starting second takes a neighbouring
+address instead of taking over the one in use, so neither becomes
+unreachable. Peers are unaffected: they read a session's address from the
+session registry rather than deriving it.
 
 The `send_message` call only confirms the message was handed to the other
 session. What became of it arrives later as a receipt: if it was held,
-declined, expired, or misaddressed (the address changed hands — list the
-agents again) — or released after a hold — a notice appears in the
-sending session's transcript (`Message to <name>: …`). The model that
-sent it is not told; if the other session replies, the reply arrives as a
-cross-session message.
+declined, refused, expired, or misaddressed (the address changed hands —
+list the agents again) — or released after a hold — a notice appears in
+the sending session's transcript (`Message to <name>: …`). Declined and
+refused are different answers: declined means someone reviewed the
+message and said no, while refused means that session's
+`agents.crossSessionInbound` is `refuse` and nobody saw it at all. The
+model that sent it is not told; if the other session replies, the reply
+arrives as a cross-session message.
 
 ### Inbox authentication and scripted injection
 

package/bundled/qc-helper/docs/features/followup-suggestions.md

@@ -2,7 +2,7 @@
 
 Qwen Code can predict what you want to type next and show it as placeholder text in the input area. This feature uses an LLM call to analyze the conversation context and generate a natural next step suggestion.
 
-This feature works end-to-end in the CLI. In the WebUI, the hook and UI plumbing are available, but host applications must trigger suggestion generation and wire the followup state for suggestions to appear.
+This feature works end-to-end in both the CLI and Web Shell. Generation is automatic and server-side: after each completed turn the daemon emits the suggestion on the session stream (on by default; set `ui.enableFollowupSuggestions` to `false` to opt out), and Web Shell's composer already wires the `useDaemonFollowupSuggestion` hook, so suggestions render and accept with no additional host wiring.
 
 ## How It Works
 

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

@@ -16,6 +16,14 @@ A Goal keeps Qwen Code working across turns until a stated condition is met. Set
 
 Creating, editing, or resuming a Goal requires a trusted workspace (`/trust`). Headless usage is covered in [Headless Mode](./headless.md#run-a-persistent-goal).
 
+## Interrupting a Goal
+
+Cancelling a Goal turn pauses the Goal. Press Esc while the model is answering or while its tools are still running, and the turn stops, the Goal moves to `paused`, and the card and `/goal` both say why it stopped. Nothing continues until you run `/goal resume`.
+
+Typing a message while a Goal is active does not pause it. Your message runs as the next Goal turn, so use it to steer the work; use `/goal pause` or `/goal clear` to stop it.
+
+Every pause states its reason: that you interrupted it, that you ran `/goal pause`, that the session token limit blocked the next model request, or that the turn failed. A Goal stopped by a limit keeps the reason for that limit instead.
+
 ## How a Goal is judged
 
 The verifier never runs commands or reads files on its own. It only sees what is already in the transcript:

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

@@ -121,7 +121,7 @@ qwen -p "Summarize this repository" \
 
 ### Choose an Output Style
 
-Use `--output-style` to pick one of the built-in output styles for this run. A style is a named block of instructions layered onto the built-in prompt that changes how the answer is written — `Concise` leads with the result and drops preamble and narration, `Proactive` starts working instead of proposing, `Explanatory` adds short notes about the codebase along the way. It overrides the `general.outputStyle` setting; `default` selects no style.
+Use `--output-style` to pick an [output style](./output-styles) — built-in or custom — for this run. A style is a named block of instructions layered onto the built-in prompt that changes how the answer is written — `Concise` leads with the result and drops preamble and narration, `Proactive` starts working instead of proposing, `Explanatory` adds short notes about the codebase along the way. It overrides the `general.outputStyle` setting; `default` selects no style.
 
 ```bash
 qwen -p "Why does the build fail on Windows?" --output-style Concise
@@ -286,7 +286,7 @@ Key command-line options for headless usage:
 | `--include-partial-messages` | Include partial messages in stream-json output                                                                                                                                                                                                                                                                                                                                                                                 | `qwen -p "query" --output-format stream-json --include-partial-messages` |
 | `--system-prompt`            | Override the main session system prompt for this run                                                                                                                                                                                                                                                                                                                                                                           | `qwen -p "query" --system-prompt "You are a terse reviewer."`            |
 | `--append-system-prompt`     | Append extra instructions to the main session system prompt for this run                                                                                                                                                                                                                                                                                                                                                       | `qwen -p "query" --append-system-prompt "Focus on concrete findings."`   |
-| `--output-style`             | Output style for this run (`Concise`, `Proactive`, `Explanatory`, `Learning`, or `default` for none); overrides `general.outputStyle`                                                                                                                                                                                                                                                                                          | `qwen -p "query" --output-style Concise`                                 |
+| `--output-style`             | Output style for this run (`Concise`, `Proactive`, `Explanatory`, `Learning`, a custom style's name, or `default` for none); overrides `general.outputStyle`                                                                                                                                                                                                                                                                   | `qwen -p "query" --output-style Concise`                                 |
 | `--debug`, `-d`              | Enable debug mode                                                                                                                                                                                                                                                                                                                                                                                                              | `qwen -p "query" --debug`                                                |
 | `--safe-mode`                | Disable all customizations — context files, hooks, extensions, skills, MCP servers, custom subagents (only built-in subagents load), permission rules, settings-sourced approval mode overrides, memory features, and sandbox settings — to isolate problems; the CLI flags `--yolo` and `--approval-mode` still take effect. See [Troubleshooting](../support/troubleshooting). Also settable via `QWEN_CODE_SAFE_MODE=true`. | `qwen -p "query" --safe-mode`                                            |
 | `--model`, `-m`              | Model to use for this run                                                                                                                                                                                                                                                                                                                                                                                                      | `qwen -p "query" --model qwen3-coder-plus`                               |

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

@@ -337,25 +337,25 @@ When `ok` is `false`, Qwen Code will continue working and use the `reason` as co
 
 Hooks fire at specific points during a Qwen Code session. Different events support different matchers to filter trigger conditions.
 
-| Event                | Triggered When                                  | Matcher Target                                                 |
-| :------------------- | :---------------------------------------------- | :------------------------------------------------------------- |
-| `PreToolUse`         | Before tool execution                           | Tool id (`write_file`, `read_file`, `run_shell_command`, etc.) |
-| `PostToolUse`        | After successful tool execution                 | Tool id                                                        |
-| `PostToolUseFailure` | After tool execution fails                      | Tool id                                                        |
-| `UserPromptSubmit`   | Before supported model invocations              | None                                                           |
-| `SessionStart`       | When session starts or resumes                  | Source (`startup`, `resume`, `clear`, `compact`)               |
-| `SessionEnd`         | When session ends                               | Reason (`clear`, `logout`, `prompt_input_exit`, etc.)          |
-| `SessionDelete`      | After an explicitly selected session is deleted | None                                                           |
-| `MessageDisplay`     | Repeatedly, as the reply streams                | None (always fires)                                            |
-| `Stop`               | When Claude prepares to conclude response       | None (always fires)                                            |
-| `SubagentStart`      | When subagent starts                            | Agent type (`Bash`, `Explorer`, `Plan`, etc.)                  |
-| `SubagentStop`       | When subagent stops                             | Agent type                                                     |
-| `PreCompact`         | Before conversation compaction                  | Trigger (`manual`, `auto`)                                     |
-| `Notification`       | When notifications are sent                     | Type (`permission_prompt`, `idle_prompt`, `auth_success`)      |
-| `PermissionRequest`  | When permission dialog is shown                 | Tool id                                                        |
-| `PermissionDenied`   | When tool permission is denied                  | Tool id                                                        |
-| `TodoCreated`        | When a new todo item is created                 | None (always fires)                                            |
-| `TodoCompleted`      | When a todo item is marked as completed         | None (always fires)                                            |
+| Event                | Triggered When                                   | Matcher Target                                                 |
+| :------------------- | :----------------------------------------------- | :------------------------------------------------------------- |
+| `PreToolUse`         | Before tool execution                            | Tool id (`write_file`, `read_file`, `run_shell_command`, etc.) |
+| `PostToolUse`        | After successful tool execution                  | Tool id                                                        |
+| `PostToolUseFailure` | After tool execution fails                       | Tool id                                                        |
+| `UserPromptSubmit`   | Before supported model invocations               | None                                                           |
+| `SessionStart`       | When session starts or resumes                   | Source (`startup`, `resume`, `clear`, `compact`)               |
+| `SessionEnd`         | When session ends                                | Reason (`clear`, `logout`, `prompt_input_exit`, etc.)          |
+| `SessionDelete`      | After an explicitly selected session is deleted  | None                                                           |
+| `MessageDisplay`     | Repeatedly, as the reply streams                 | None (always fires)                                            |
+| `Stop`               | When Claude prepares to conclude response        | None (always fires)                                            |
+| `SubagentStart`      | When subagent starts                             | Agent type (`Bash`, `Explorer`, `Plan`, etc.)                  |
+| `SubagentStop`       | When subagent stops                              | Agent type                                                     |
+| `PreCompact`         | Before conversation compaction                   | Trigger (`manual`, `auto`)                                     |
+| `Notification`       | When notifications are sent                      | Type (`permission_prompt`, `idle_prompt`, `auth_success`)      |
+| `PermissionRequest`  | When permission dialog is shown                  | Tool id                                                        |
+| `PermissionDenied`   | When AUTO-mode classification denies a tool call | Tool id                                                        |
+| `TodoCreated`        | When a new todo item is created                  | None (always fires)                                            |
+| `TodoCompleted`      | When a todo item is marked as completed          | None (always fires)                                            |
 
 ### Matcher Patterns
 

package/bundled/qc-helper/docs/features/output-styles.md

@@ -25,13 +25,46 @@ The change applies to the running session immediately — the system prompt is r
 
 You can also set the style without the command:
 
-- **Settings**: `"general": { "outputStyle": "Concise" }` in `settings.json` (user or project scope). A hand edit takes effect on the next start.
+- **Settings**: `"general": { "outputStyle": "Concise" }` in `settings.json` (user or project scope). The value is a built-in or [custom](#custom-styles) style name. A hand edit takes effect on the next start.
 - **One run**: `qwen -p "..." --output-style Concise` overrides the setting for that run. See [Headless Mode](./headless).
 
+## Custom styles
+
+A custom style is a Markdown file whose body is the style's instructions. Put it in one of two directories:
+
+| Location                             | Scope                                                         |
+| ------------------------------------ | ------------------------------------------------------------- |
+| `~/.qwen/output-styles/<name>.md`    | Your styles, available in every project                       |
+| `<project>/.qwen/output-styles/*.md` | The project's styles, read only when the workspace is trusted |
+
+Trust is checked whenever the style is used, not only when the file is read, so revoking trust mid-session stops a project style from shaping the conversation.
+
+```markdown
+---
+name: Reviewer
+description: Reviews code and reports findings without editing anything
+keep-coding-instructions: false
+---
+
+You are reviewing, not implementing. Read the code the user points you at, list concrete findings ordered by severity, and never edit files unless the user asks for a fix.
+```
+
+The frontmatter is optional. Each field has a default:
+
+- `name` — the style's name, used with `/output-style <name>` and in `general.outputStyle`. Defaults to the file name without `.md`. `default` is reserved.
+- `description` — the one-line summary shown in the picker. Defaults to the first line of the body.
+- `keep-coding-instructions` — `true` keeps the built-in software-engineering workflow guidance in the prompt alongside your style; `false` drops that one section, for a style whose work is not coding. A file that says nothing inherits the value of the built-in style it overrides, so rewriting `concise.md` changes the wording without dropping that guidance; a file with no built-in counterpart defaults to `false`. Everything else in the built-in prompt — identity, safety rules, tool guidance — stays in force under every style.
+
+Custom styles appear in the `/output-style` picker after the built-ins, labelled with their source, and are re-read each time the picker opens or a name is given, so a new file needs no restart. Names are matched case-insensitively and must be unique: a project style overrides a user style of the same name, and either overrides a built-in of that name. A file that cannot be loaded is skipped and reported in the debug log while the other files still load — an empty body, an invalid name, a file larger than 25 kB (a style is a prompt, not a document), one that is not UTF-8 text, or one whose whole body is an HTML comment. HTML comments are stripped from the body, so a note to your teammates is not sent to the model.
+
+A style file may only read itself: a project file that is a symlink is skipped, a user file may be a symlink into your own home (a dotfiles setup) but not outside it, and a hard link is refused at either level.
+
+Custom styles are ignored in `--bare` and `--safe-mode`, which keep the built-ins only.
+
 ## Scope and interactions
 
 - A style layers onto the built-in prompt. When `--system-prompt` or `QWEN_SYSTEM_MD` replaces the prompt entirely, the style (and its per-turn reminder) is not applied.
-- Styles apply to the main conversation only; subagents run their own system prompts.
+- Styles apply to the main conversation only. Subagents run their own system prompts, and an arena peer inherits the session's style only when that style keeps the coding instructions — a peer is judged on the diff it produces, so it never runs with the software-engineering guidance removed.
 - `--bare` and `--safe-mode` ignore the setting and do not allow `/output-style` changes.
 - Changing the style mid-session invalidates the cached prompt prefix once; after that, caching works as usual.