@qwen-code/qwen-code 0.21.1 → 0.21.2

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

@@ -337,6 +337,7 @@ If you are experiencing performance issues with file searching (e.g., with `@` c
 | `tools.computerUse.maxImageDimension` | number            | Longest-edge pixel cap applied to cua-driver screenshots (via `set_config`'s `max_image_dimension`). `-1` (default) keeps cua-driver's built-in default (1568); `0` disables resizing (full resolution); a positive value caps the longest edge. Lower caps cut vision-token cost at the expense of fine detail.                                                                                                                                                                                                                                                                                                                                                                                                                                     | `-1`        | Requires restart: Yes. Env override: `QWEN_COMPUTER_USE_MAX_IMAGE_DIMENSION` (a non-negative integer; takes precedence over this setting)                                                                                                                                                                                   |
 | `tools.computerUse.idleTimeoutMs`     | number            | Milliseconds to keep the cua-driver process alive after the last `computer_use__*` call. The default is `300000` (5 minutes). Set to `0` to keep it running until Qwen Code exits.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | `300000`    | Requires restart: Yes                                                                                                                                                                                                                                                                                                       |
 | `tools.toolSearch.enabled`            | boolean           | Load MCP tools on demand via ToolSearch to reduce prompt size. Disable this for models that rely on prefix-based KV caching (e.g. DeepSeek) to keep the prompt prefix stable and maximize cache hit rates.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `true`      | Requires restart: Yes                                                                                                                                                                                                                                                                                                       |
+| `tools.toolSearch.threshold`          | number            | Context-window percentage used as the session-start budget for preloading deferred tools (bundled built-ins and MCP alike). When the combined schemas of every deferred tool fit within this budget, they are all declared upfront instead of loaded on demand via ToolSearch — a stable declaration list keeps prefix KV caches valid for the whole session. Set `0` to always load deferred tools on demand.                                                                                                                                                                                                                                                                                                                                       | `10`        | Requires restart: Yes                                                                                                                                                                                                                                                                                                       |
 
 > [!note]
 >

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

@@ -7,5 +7,6 @@ export default {
   feishu: 'Feishu',
   qqbot: 'QQ Bot',
   github: 'GitHub',
+  gitlab: 'GitLab',
   plugins: 'Plugins',
 };

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

@@ -4,7 +4,8 @@ This guide covers setting up a Qwen Code channel that monitors GitHub notificati
 
 ## Prerequisites
 
-- A GitHub account (or a dedicated bot account)
+- A GitHub account for the channel. Use a dedicated bot account when the PAT
+  owner also needs to operate the channel.
 - A GitHub Personal Access Token (PAT) with `notifications` and `public_repo` (or `repo`) scopes
 
 ## Creating a Token
@@ -26,10 +27,12 @@ Add the channel to `~/.qwen/settings.json`:
       "type": "github",
       "token": "$GITHUB_TOKEN",
       "pollInterval": 60000,
+      "reasonFilter": ["mention", "review_requested", "assign"],
       "senderPolicy": "allowlist",
-      "allowedUsers": ["your-github-username"],
+      "allowedUsers": ["operator-github-username"],
       "sessionScope": "chat_thread",
       "cwd": "/path/to/your/project",
+      "blockStreaming": "off",
       "groupPolicy": "open",
       "groups": {
         "*": { "requireMention": true }
@@ -45,6 +48,13 @@ Set the token as an environment variable:
 export GITHUB_TOKEN="ghp_your_token_here"
 ```
 
+The PAT owner cannot trigger its own channel: GitHub self-activity does not
+provide a usable notification, and the adapter intentionally ignores its own
+comments to prevent reply loops. If the PAT owner needs to operate the channel,
+use a separate bot-owned PAT and put only operator accounts in `allowedUsers`.
+Startup rejects an allowlist containing only the PAT owner and warns when the
+PAT owner appears alongside other operators.
+
 ### GitHub Enterprise
 
 For GitHub Enterprise Server, set `baseUrl`:
@@ -57,14 +67,22 @@ For GitHub Enterprise Server, set `baseUrl`:
 
 ## Configuration Options
 
-| Option                    | Default                  | Description                                                                      |
-| ------------------------- | ------------------------ | -------------------------------------------------------------------------------- |
-| `token`                   | (required)               | Classic PAT with `notifications` scope                                           |
-| `pollInterval`            | `60000`                  | Poll interval in ms                                                              |
-| `baseUrl`                 | `https://api.github.com` | API base URL (for GHE)                                                           |
-| `groupPolicy`             | `"disabled"`             | Must be `"open"` for notifications to flow                                       |
-| `senderPolicy`            | `"allowlist"`            | Who can trigger the bot                                                          |
-| `groups.*.requireMention` | `true`                   | Require @mentions for ordinary comments; directed notification reasons still run |
+| Option                    | Default                  | Description                                                                                   |
+| ------------------------- | ------------------------ | --------------------------------------------------------------------------------------------- |
+| `token`                   | (required)               | Classic PAT with `notifications` scope                                                        |
+| `pollInterval`            | `60000`                  | Poll interval in ms                                                                           |
+| `baseUrl`                 | `https://api.github.com` | API base URL (for GHE)                                                                        |
+| `groupPolicy`             | `"disabled"`             | Must be `"open"` for notifications to flow                                                    |
+| `senderPolicy`            | `"allowlist"`            | Who can trigger the bot                                                                       |
+| `groups.*.requireMention` | `true`                   | Require @mentions for ordinary comments; directed notification reasons still run              |
+| `blockStreaming`          | `"off"`                  | Always forced to `"off"`; intermediate model chunks aren't published; `"on"` is not supported |
+| `reasonFilter`            | unset                    | Optional allowlist of GitHub notification reasons to process                                  |
+
+Use `reasonFilter` to drop noisy notification classes such as `ci_activity` or `state_change`. Do not use `reasonFilter: ["mention"]` as a replacement for `groups.*.requireMention`: GitHub's `mention` reason is sticky at the thread level, so real new @mentions can arrive later under `comment`, `subscribed`, `author`, or other reasons and would be skipped.
+
+Valid `reasonFilter` values are `mention`, `review_requested`, `assign`, `author`, `comment`, `ci_activity`, `manual`, `state_change`, `subscribed`, `team_mention`, `security_alert`, `approval_requested`, `invitation`, `member_feature_requested`, and `security_advisory_credit`.
+
+Filtered notifications are still marked read before they are skipped. Removing the filter later will not replay notifications the channel already skipped.
 
 ## ⚠️ Security
 
@@ -92,6 +110,20 @@ The comment window is `(previousCursor, currentMaxUpdatedAt]` — comments alrea
 
 Non-comment activity (push, label changes) bumps the notification's `updated_at` but produces zero new comments in the window, so re-fetched threads are skipped without triggering the agent.
 
+## Response Feedback
+
+For an accepted issue or pull-request comment, the channel adds GitHub's `👀` reaction while the agent is working, then removes it when the run completes, fails, or is cancelled. Both operations are best-effort: a reaction API or permission failure is logged and never prevents the final response.
+
+### Final-only output
+
+The GitHub channel always forces final-only delivery. The adapter sets `blockStreaming` to `"off"`, so intermediate model chunks are never published as separate comments and `blockStreaming: "on"` is not supported.
+
+```json
+{
+  "blockStreaming": "off"
+}
+```
+
 ## Known Limitations
 
 - **First start skips existing unread notifications.** The cursor initializes to "now" on first launch. Notifications created before the bot starts are not processed unless the thread receives new activity afterwards.

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

@@ -0,0 +1,171 @@
+# GitLab
+
+This guide covers setting up a Qwen Code channel that monitors GitLab todos and responds to mentions on issues and merge requests.
+
+## Prerequisites
+
+- A GitLab account (or a dedicated bot account)
+- A GitLab Personal Access Token with `read_api` and `api` scopes
+
+## Creating a Token
+
+1. Go to **Preferences → Access Tokens**
+2. Create a token with these scopes:
+   - **read_api** — read todos and project data
+   - **api** — post notes (comments) on issues/MRs
+3. Save the token securely as an environment variable
+
+## Configuration
+
+Add the channel to `~/.qwen/settings.json`:
+
+```json
+{
+  "channels": {
+    "my-gitlab": {
+      "type": "gitlab",
+      "token": "$GITLAB_TOKEN",
+      "pollInterval": 60000,
+      "senderPolicy": "open",
+      "sessionScope": "chat_thread",
+      "cwd": "/path/to/your/project",
+      "groupPolicy": "open",
+      "action_prompt_template": {
+        "mentioned": "Project: %project% | URL: %project_url% | Author: %author% | Type: %target_type% | IID: %iid% | Title: %title% | Description: %description% | TodoID: %todo_id%"
+      }
+    }
+  }
+}
+```
+
+Set the token as an environment variable:
+
+```bash
+export GITLAB_TOKEN="glpat-your_token_here"
+```
+
+### Self-hosted GitLab
+
+For self-hosted instances, set `baseUrl`:
+
+```json
+{
+  "baseUrl": "https://gitlab.example.com"
+}
+```
+
+## Configuration Options
+
+| Option                   | Default                   | Description                                                |
+| ------------------------ | ------------------------- | ---------------------------------------------------------- |
+| `token`                  | (required)                | PAT with `read_api` + `api` scopes                         |
+| `pollInterval`           | `60000`                   | Poll interval in ms                                        |
+| `baseUrl`                | `https://gitlab.com`      | GitLab instance URL                                        |
+| `action_prompt_template` | (required for processing) | Maps GitLab action names to metadata templates             |
+| `groupPolicy`            | `"disabled"`              | Must be `"open"`, or `"allowlist"` with the project listed |
+| `senderPolicy`           | `"allowlist"`             | Who can trigger the bot                                    |
+
+## action_prompt_template
+
+This field controls which todo actions are processed and how metadata is rendered. Only actions with a configured template are dispatched; all others are skipped and marked done.
+
+```json
+{
+  "action_prompt_template": {
+    "mentioned": "Project: %project% | Author: %author% | Title: %title%"
+  }
+}
+```
+
+The `directly_addressed` action (comment starting with `@bot`) automatically falls back to the `mentioned` template if not explicitly configured.
+
+### Available Action Keys
+
+| Key                   | Trigger                                                                  |
+| --------------------- | ------------------------------------------------------------------------ |
+| `mentioned`           | Someone @mentions the bot in a comment or description (not at the start) |
+| `directly_addressed`  | A comment **starts with** `@bot` (falls back to `mentioned` template)    |
+| `assigned`            | Someone assigns the bot to an issue/MR                                   |
+| `review_requested`    | Someone requests the bot as a reviewer on an MR                          |
+| `approval_required`   | An MR requires the bot's approval (approval rules)                       |
+| `marked`              | Someone marks the bot's comment/issue/MR (star)                          |
+| `build_failed`        | A CI/CD pipeline fails on the bot's branch/MR                            |
+| `unmergeable`         | An MR the bot is involved with becomes unmergeable (conflicts)           |
+| `merge_train_removed` | An MR is removed from the merge train                                    |
+
+Only keys present in `action_prompt_template` are processed. Unconfigured actions are skipped and marked done silently.
+
+### Template Variables
+
+| Variable        | Value                             |
+| --------------- | --------------------------------- |
+| `%project%`     | Project path (e.g., `owner/repo`) |
+| `%project_url%` | Full project URL                  |
+| `%author%`      | Todo author username              |
+| `%target_type%` | `Issue` or `MergeRequest`         |
+| `%iid%`         | Issue/MR internal ID              |
+| `%title%`       | Issue/MR title                    |
+| `%description%` | Issue/MR description body         |
+| `%todo_id%`     | GitLab todo ID                    |
+| `%%`            | Literal `%` (escape)              |
+
+Unknown variables are preserved as-is in the output.
+
+### Prompt Assembly
+
+The template renders into `envelope.metadata` (structured context). The triggering text (`todo.body` or description) goes into `envelope.text` (primary prompt). The base class assembles the final prompt sent to the agent:
+
+```
+[alice] please fix this bug
+
+Project: owner/repo | URL: https://gitlab.com/owner/repo | Author: alice | Type: Issue | IID: 42 | Title: Test Issue | Description: ... | TodoID: 100
+```
+
+- Line 1: `[sender]` prefix + `envelope.text` (with `@bot` stripped)
+- Line 3: `envelope.metadata` (rendered template, sanitized)
+
+You do **not** need a `%body%` variable — the comment/description text is always the primary prompt content, and the template provides supplementary context below it.
+
+## ⚠️ Security
+
+On a **public project**, setting `senderPolicy: "open"` allows **any GitLab user** who @mentions the bot to submit prompts that drive the agent in your `cwd`.
+
+Always use `senderPolicy: "allowlist"` with explicit `allowedUsers` on public projects.
+
+## Mention Detection
+
+The adapter always sets `isMentioned = true` on dispatched envelopes, because GitLab has already determined the mention when creating the todo. The `action_prompt_template` config is the real event filter — only actions with a configured template are processed. The `@bot` mention is stripped from the message text before dispatch via `stripBotMention`.
+
+### ⚠️ groupPolicy Must Be "open" or "allowlist"
+
+`groupPolicy` must be set to `"open"`, or `"allowlist"` with the project explicitly listed, for todos to be processed. The default value `"disabled"` drops all mentions: todos are marked done and the cursor advances, but no dispatch occurs. A rejection is logged (`preflight rejected reason=group_disabled`) but the todo is still consumed. If your bot is not responding to mentions, check that `groupPolicy` is not `"disabled"`.
+
+## How It Works
+
+The adapter uses GitLab's Todos API as the message source:
+
+1. **Poll** `GET /todos?state=pending` for new todos
+2. **First-poll drain**: if the cursor has never been initialized (`initialized: false`), all pending todos are marked done without dispatch and the cursor advances to the max todo ID. This prevents a backlog flood on first start.
+3. **Clean up stale todos**: todos with `id <= cursor` are marked done (best-effort) to prevent them from being re-fetched on every poll
+4. **Filter** by `id > cursor` and configured `action_prompt_template`
+5. **Detect mention type** via `target_url` anchor:
+   - `#note_123` present → comment mention → text is `todo.body` (the comment)
+   - No anchor → description mention → text is the issue/MR description
+6. **Dispatch** the envelope through `handleInbound` (requires `groupPolicy: "open"` or `"allowlist"` with the project listed)
+7. **Advance cursor** and **mark todo done** (best-effort)
+
+The cursor (`lastProcessedId`) advances regardless of dispatch success or failure. Failed dispatches post a ⚠️ error comment on the issue/MR and are not retried — the user can re-mention the bot to trigger a new todo.
+
+## Known Limitations
+
+- **First start skips existing pending todos.** The cursor initializes to `{ lastProcessedId: 0, initialized: false }` on first launch. On the first poll cycle, all pre-existing pending todos are marked done without dispatch (the `initialized` flag gates this one-time drain), preventing a backlog flood.
+- The bot does not read prior conversation history — only the triggering content is processed.
+- **Confidential (internal) notes:** If someone @mentions the bot in a confidential note, the todo body contains that internal text and the agent will process it. The bot's reply is always posted as a **public** note, potentially exposing internal discussion. GitLab's todo API does not expose note visibility, so the adapter cannot filter this. Avoid @mentioning the bot in confidential notes.
+- Requires `read_api` + `api` PAT scopes. Group-level or project-level tokens work if they have these scopes.
+- Todos for Epics, Designs, and Alerts are skipped (only Issues and MRs are processed).
+
+## Starting the Channel
+
+```bash
+qwen channel start my-gitlab
+```

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

@@ -277,6 +277,26 @@ The deterministic halves of the pipeline — argument parsing (`qwen review pars
 
 Every run ends with one machine-readable line (`Review complete: <target> — <disposition>`), so scripts and CI wrappers can detect completion and outcome with a single `^Review complete: ` match.
 
+## Headless runs (`qwen review run`)
+
+`/review` is interactive. When a script or CI job needs to run a review and act on its outcome, use the headless wrapper:
+
+```bash
+qwen review run [target] [--json] [--fail-on request-changes] [--comment] [--quiet]
+```
+
+`target` is a PR number, a PR URL, or a file path; omit it to review the local working tree. The command runs this build's own CLI non-interactively (with stdin closed, so slash-command detection survives), streams the child's progress to **stderr**, and prints the verdict to **stdout** — or, with `--json`, the full result object. The verdict is read from the artifact `compose-review` writes (the same JSON the skill treats as the verdict authority), never parsed from the model's prose.
+
+The exit code is the contract a gate should read:
+
+| Exit | Meaning                                                                                           |
+| ---- | ------------------------------------------------------------------------------------------------- |
+| `0`  | The review completed (whatever it decided)                                                        |
+| `1`  | It never reached a verdict — the child failed, timed out, or left no composed artifact            |
+| `3`  | It completed with `REQUEST_CHANGES` **and** `--fail-on request-changes` was set (opt-in blocking) |
+
+`3` (not `2`) lets a gate distinguish "the review is blocking" from "the tool broke" — yargs already uses `1` for usage errors — without parsing any output. `--timeout-minutes` (default 120, floored at 1) terminates a hung review and exits `1`, and cancelling the command (Ctrl+C / SIGTERM) terminates the review's process group rather than orphaning it.
+
 ## Cross-file Impact Analysis
 
 A dedicated cross-file tracer (Agent 1c) owns this walk end-to-end. When code changes modify exported functions, classes, or interfaces, it searches for all callers and checks compatibility:

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

@@ -103,6 +103,24 @@ HTTP hooks send hook input as POST requests to specified URLs. They support URL
 - **DNS Validation**: Validates domain resolution before requests to prevent DNS rebinding attacks
 - **Environment Variable Interpolation**: `${VAR}` syntax, only allows variables in `allowedEnvVars` whitelist
 
+#### Allowing private-network hooks (managed environments only)
+
+By default, HTTP hooks cannot target private or link-local IP ranges. In platform-managed environments where the hook receiver is a first-party, VPC-internal endpoint (for example, an internal API gateway resolving to `172.16.0.0/12`), you can relax the IP-range checks with:
+
+```json
+{
+  "security": {
+    "allowPrivateNetworkHooks": true
+  }
+}
+```
+
+- This setting is **only honored from User, System, and SystemDefaults settings scopes**. A value set in Workspace (project) settings is ignored and logged as a warning, so a cloned repository can never self-grant this bypass.
+- The flag relaxes only the general private/CGNAT/link-local **range** checks. Cloud metadata endpoints stay blocked in every configuration: the `BLOCKED_HOSTS` list is matched literally (`metadata.google.internal`, `metadata.azure.internal`, ...), and the metadata IPs `169.254.169.254` and `100.100.100.200` are blocked in all serialized forms (including IPv4-mapped IPv6 such as `::ffff:a9fe:a9fe`) and after DNS resolution.
+- The `security.allowedHttpHookUrls` whitelist still applies independently. In managed environments, pair this flag with a whitelist so only the intended internal endpoints are reachable.
+
+> **Warning:** Enabling this flag lets hooks reach internal infrastructure on your network. Enable it only in trusted, managed settings — never in a repository you do not control.
+
 **Example:**
 
 ```json
@@ -539,6 +557,8 @@ Sequential UserPromptSubmit hooks can append `additionalContext` to `prompt`; `s
 - `reason`: human-readable explanation for the decision
 - `hookSpecificOutput.additionalContext`: additional context to append to the prompt (optional)
 
+When sent to the model, injected `additionalContext` is appended as its own message part wrapped in a reserved `<qwen:user-prompt-submit-context>...</qwen:user-prompt-submit-context>` tag, so it stays distinguishable from user-authored text in model history and session transcripts. Angle brackets in hook output are escaped before wrapping, so hook content cannot close or forge the tag. The session transcript also records the user's original prompt text separately; the interactive TUI and the ACP/export transcript-replay path display that original text rather than the injected context.
+
 **Note**: Since UserPromptSubmitOutput extends HookOutput, all standard fields are available but only additionalContext in hookSpecificOutput is specifically defined for this event.
 
 **Example Output**:

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

@@ -25,14 +25,28 @@ Only `subagent_type: "fork"` accepts `fork_turns`:
 
 Tool responses and pure system reminders do not count as user turns. Regular named subagents and agent-team teammates do not accept `fork_turns`; they keep their separate conversation context.
 
+## Restricting Fork Tool Execution with `fork_tools`
+
+Only `subagent_type: "fork"` accepts `fork_tools`. The array may contain exact canonical tool names, such as `read_file` and `grep_search`, or MCP server patterns such as `mcp__github`. The fork still receives the same model-visible tool declarations as an unrestricted fork, preserving its prompt-cache prefix, but its task prompt identifies the restriction and a call not matched by `fork_tools` is rejected before scheduling or approval.
+
+- Omitting `fork_tools` preserves unrestricted fork execution.
+- An empty array rejects every tool call.
+- `*` is not accepted; omit `fork_tools` when unrestricted execution is intended.
+- Tool names cannot have surrounding whitespace. Wildcards are accepted only as `mcp__*` or as a trailing MCP tool-prefix pattern such as `mcp__github__read_*`.
+- `mcp__*` intentionally allows every MCP tool while still denying unlisted built-in tools.
+- Shell command argument patterns are not supported. Listing `run_shell_command` allows that tool to proceed through its normal permission checks but does not pre-approve any command.
+
+This is a per-invocation restriction supplied by the caller. It narrows a child fork's capabilities but is not an administrator-enforced security sandbox because the caller can omit or expand the list.
+
 ### How Fork Differs from Named Subagents
 
-|               | Named Subagent                                                 | Fork Subagent                                                                           |
-| ------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
-| Context       | Starts fresh with no parent conversation history               | Inherits all parent history by default; `fork_turns` can select a bounded recent window |
-| System prompt | Uses its own configured prompt                                 | Uses parent's exact system prompt (for cache sharing)                                   |
-| Execution     | Background by default; supports an explicit foreground opt-out | Always detached; parent continues immediately                                           |
-| Use case      | Specialized tasks (testing, docs)                              | Parallel tasks that need the current context                                            |
+|               | Named Subagent                                                 | Fork Subagent                                                                                                       |
+| ------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| Context       | Starts fresh with no parent conversation history               | Inherits all parent history by default; `fork_turns` can select a bounded recent window                             |
+| System prompt | Uses its own configured prompt                                 | Uses parent's exact system prompt (for cache sharing)                                                               |
+| Tools         | Configured declaration set                                     | Keeps the parent-derived declaration set; `fork_tools` can independently narrow execution without changing that set |
+| Execution     | Background by default; supports an explicit foreground opt-out | Always detached; parent continues immediately                                                                       |
+| Use case      | Specialized tasks (testing, docs)                              | Parallel tasks that need the current context                                                                        |
 
 ### When Fork is Used
 
@@ -46,9 +60,9 @@ The AI automatically uses fork when it needs to:
 
 All forks share the parent's exact API request prefix (system prompt, tools, conversation history), enabling DashScope prompt cache hits. When 3 forks run in parallel, the shared prefix is cached once and reused — saving 80%+ token costs compared to independent subagents.
 
-### Recursive Fork Prevention
+### Recursive Delegation Prevention
 
-Fork children cannot create further forks. This is enforced at runtime — if a fork attempts to spawn another fork, it receives an error instructing it to execute tasks directly.
+Fork children cannot spawn any further sub-agent. This is enforced at runtime — if a fork calls the Agent tool, it receives an error instructing it to execute tasks directly.
 
 ### Current Limitation
 

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

@@ -218,17 +218,19 @@ remediation.
 
 The daemon also exposes workspace file helpers:
 
-- `GET /file` reads text files and returns a raw-byte `sha256:<hex>` hash.
+- `GET /file` reads text files. Full-snapshot responses return a raw-byte
+  `sha256:<hex>` hash; finite-line windows from files above 256 KiB omit it.
 - `GET /file/bytes` reads bounded raw byte windows and returns base64 content.
 - `POST /file/write` creates or replaces text files.
 - `POST /file/edit` applies one exact text replacement.
 
 Write/edit are **strict mutation routes**: even on loopback they require a
 configured bearer token, otherwise they return `token_required`. Replacements
-and edits require the latest `expectedHash` from `GET /file` (or a full-window
-`GET /file/bytes`). `create` never overwrites. Explicit writes to ignored paths
-are allowed but audited. Binary writes, delete/move/mkdir, and recursive parent
-creation are not part of this surface.
+and edits require the latest `expectedHash` from a full-snapshot `GET /file`
+(or a full-window `GET /file/bytes`). A partial large-file window cannot be
+used as an optimistic-concurrency token. `create` never overwrites. Explicit
+writes to ignored paths are allowed but audited. Binary writes,
+delete/move/mkdir, and recursive parent creation are not part of this surface.
 
 ### 3. Open a session
 

package/bundled/review/SKILL.md

@@ -444,7 +444,7 @@ An agent that finds nothing must say so **and say what it walked** — `No issue
 | `4`                                       | **Performance & efficiency.** N+1s, leaks, needless re-renders, bad data structures, bundle size. **Reproduces the PR's claimed numbers** rather than trusting them — confirms a cheap deterministic claim (bundle bytes, tree-shake) or flags an unreproducible/unsubstantiated benchmark as unverified.                                                                                                                                                                                                                                                                                                                |
 | `5`                                       | **Test coverage.** Specific untested paths in the diff, never "coverage is low"; a missing test is a Suggestion. **Mutation-tests the tests the diff adds/changes** — a test that stays green when the code under it is broken is vacuous — a Suggestion, Critical only when it asserts the opposite, was weakened in-diff, or lets a named incorrect behaviour ship (report the behaviour, not the gap).                                                                                                                                                                                                                |
 | `6a` `6b` `6c`                            | **Undirected audit, three personas** — attacker, 3 AM oncall, six-months-later maintainer. The framings force diverse paths; the union of what they find is the point, so all three run.                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| `7`                                       | **Build & test verification** (needs a local tree). Runs _one_ build and _one_ test command, and the **test-efficacy probe** — which reverts the diff's source, keeps its tests, and reports the ones that pass anyway. Its evidence is the commands it ran. `Source: [build]` / `[test]`, never `[review]`.                                                                                                                                                                                                                                                                                                             |
+| `7`                                       | **Build & test verification** (needs a local tree). Runs _one_ build and _one_ test command, and the **test-efficacy probe** — which reverts the diff's source, keeps its tests, and reports the ones that pass anyway, and deletes individual added safety statements (mutants) to find the ones no test notices. Its evidence is the commands it ran. `Source: [build]` / `[test]`, never `[review]`.                                                                                                                                                                                                                  |
 | `test-matrix`                             | **Test coverage matrix** (Step 3B). Maps each behavioural change to the test that exercises it — the pairing a territory agent cannot see, because it holds either the implementation or the test, rarely both.                                                                                                                                                                                                                                                                                                                                                                                                          |
 | `invariant-a` `invariant-b` `invariant-c` | **Whole-file invariants** on a `heavy` file, one checklist slice each: (a) mutable fields, timers, collections; (b) retry counters, ignored return values, error taxonomies; (c) config fields, early returns.                                                                                                                                                                                                                                                                                                                                                                                                           |
 

package/chunks/{MaxSizedBox-VI3ROJJA.js → MaxSizedBox-TQBQ247P.js}

@@ -4,71 +4,75 @@ import {
   MINIMUM_MAX_HEIGHT,
   MaxSizedBox,
   setMaxSizedBoxDebugging
-} from "./chunk-U3E3UQAA.js";
-import "./chunk-GKX7E4CO.js";
+} from "./chunk-FS674JW4.js";
+import "./chunk-45IOTAUS.js";
 import "./chunk-SV5PQVQE.js";
-import "./chunk-GATT5TKW.js";
-import "./chunk-UWMLWVCA.js";
+import "./chunk-2IIJTXYF.js";
+import "./chunk-IGTHU3T4.js";
 import "./chunk-5QWWOFGG.js";
 import "./chunk-YDLJGZHL.js";
 import "./chunk-2MIN6GRR.js";
 import "./chunk-QHTIBUWB.js";
 import "./chunk-RKUWKYED.js";
-import "./chunk-X5WNMMIA.js";
+import "./chunk-54YCNSK5.js";
+import "./chunk-5M6IDOMF.js";
 import "./chunk-TWPJO254.js";
 import "./chunk-H6XPXXMH.js";
-import "./chunk-5M6IDOMF.js";
-import "./chunk-UPUG4GXM.js";
-import "./chunk-64LQLPL7.js";
-import "./chunk-2LQTH543.js";
+import "./chunk-AOHY3QJ3.js";
+import "./chunk-5NNHICSA.js";
+import "./chunk-SHN4KHDK.js";
+import "./chunk-JXVC2PL3.js";
 import "./chunk-KRXPRVGL.js";
-import "./chunk-BMFALVGQ.js";
-import "./chunk-CVHIL5IG.js";
+import "./chunk-6PVPNMXU.js";
+import "./chunk-ZMOJ7ISP.js";
 import "./chunk-IRH27ZC2.js";
 import "./chunk-QHWCP53L.js";
-import "./chunk-PONHVBRT.js";
+import "./chunk-TEGJSJDF.js";
+import "./chunk-TIRRPCFS.js";
+import "./chunk-O6GEWCJA.js";
 import "./chunk-T26EAKDL.js";
-import "./chunk-6PVPNMXU.js";
 import "./chunk-CPBF7KYF.js";
-import "./chunk-6QIGFD5W.js";
-import "./chunk-XWWKIXVD.js";
-import "./chunk-75GFAX4R.js";
-import "./chunk-OKF7JF3R.js";
-import "./chunk-JSD33JG6.js";
+import "./chunk-4KP2F2TE.js";
+import "./chunk-3APUUXRF.js";
+import "./chunk-THVU3RNH.js";
+import "./chunk-LHKCY7DY.js";
+import "./chunk-6FMJLI5M.js";
+import "./chunk-CBBP4BMC.js";
 import "./chunk-S6LOFUVP.js";
-import "./chunk-JCW2R7WC.js";
-import "./chunk-2DN4J57Y.js";
+import "./chunk-K623ENWT.js";
+import "./chunk-AQ37AY7B.js";
+import "./chunk-N4ACHWNH.js";
 import "./chunk-ZPJWUGCS.js";
-import "./chunk-2LKVPASC.js";
+import "./chunk-D4HTUMGX.js";
 import "./chunk-NAVJD2PQ.js";
-import "./chunk-LW3RFMG7.js";
-import "./chunk-W4MIWP6M.js";
+import "./chunk-LOY7RWQG.js";
+import "./chunk-E6CJ2SMM.js";
 import "./chunk-DGEIYUC3.js";
 import "./chunk-MPHPFVKK.js";
 import "./chunk-GLNBDYUX.js";
 import "./chunk-DJ2GSRLV.js";
-import "./chunk-5KTQXHPY.js";
-import "./chunk-75MIQ3LV.js";
+import "./chunk-6CQWRWUC.js";
+import "./chunk-Z3S5EMOW.js";
 import "./chunk-2J3OJGTL.js";
 import "./chunk-P3QQPMQA.js";
-import "./chunk-RPLGZJV2.js";
+import "./chunk-XQK4XXTN.js";
 import "./chunk-GLCZKT5V.js";
-import "./chunk-DZLYR4U3.js";
-import "./chunk-PT722TDT.js";
+import "./chunk-QDK4F2N5.js";
+import "./chunk-DUNI4EBW.js";
 import "./chunk-VGC4I5JJ.js";
-import "./chunk-SGFT55XI.js";
-import "./chunk-Y4IHBGBP.js";
-import "./chunk-Y6AXW2OG.js";
-import "./chunk-VCPIZRYH.js";
+import "./chunk-3I6DUGQD.js";
+import "./chunk-7ULQIS27.js";
+import "./chunk-MM7TH7ZM.js";
+import "./chunk-HIVKI6O6.js";
 import "./chunk-46UV252V.js";
 import "./chunk-ZBVS26BY.js";
-import "./chunk-WZRWHXFE.js";
-import "./chunk-A3NDJ5SB.js";
-import "./chunk-7XATOOE7.js";
-import "./chunk-BGTQCTQW.js";
+import "./chunk-Q3T5KA2V.js";
+import "./chunk-R2XWGR75.js";
+import "./chunk-HC45LTEN.js";
+import "./chunk-QARJNL2V.js";
 import "./chunk-W4RQUHY3.js";
-import "./chunk-S7W2GKIO.js";
-import "./chunk-UHUSJ6X7.js";
+import "./chunk-G7XXKQYS.js";
+import "./chunk-E2BHWIDT.js";
 import "./chunk-VOQXFAY5.js";
 import "./chunk-75DOP5OR.js";
 import "./chunk-DMTGGOSA.js";