scream-code 0.18.0 → 0.18.1

package/dist/{dispatch-DfHVLpfA.mjs → dispatch-FYZpdI9u.mjs}

@@ -6,7 +6,7 @@ const __dirname = __cjsShimDirname(__filename);
 import { i as __require, o as __toESM, r as __exportAll, t as __commonJSMin } from "./chunk-D90kvbyJ.mjs";
 import { A as sharedMemoStore, B as buildProjectTagCloud, C as applyConsolidation, D as parseMemoryMemos, E as buildExitExtractionPrompt, F as probeLocalEmbeddingSupport, G as join$1, H as basename$1, I as createMemoryMemo, J as relative$1, K as normalize, L as toSummary, M as clearEmbeddingModelCache, N as createFastEmbedEngine, O as stripMemoryTags, P as hasEmbeddingModelCache$1, R as generateTags, S as DreamTracker, T as EXIT_EXTRACTION_SYSTEM_PROMPT, U as dirname$2, V as rankMemos, W as isAbsolute$1, Y as resolve$2, a as isSupportedFile, b as sharedKnowledgeStoreReady, i as ingestFile, j as classifyEmbeddingFailure, k as MemoryMemoStore, q as parse$7, r as ingestDirectory, t as multiSearch, w as buildConsolidationPlan, y as sharedKnowledgeStore, z as normalizeTags } from "./src-C7C9e5Ds.mjs";
 import { n as require_base64_js, t as XMLParser } from "./XMLParser-DFAnGqkc.mjs";
-import { a as setLocale, i as getLocale, n as assertScreamHostIdentity, o as t, r as createScreamDefaultHeaders, t as TextInputDialogComponent } from "./text-input-dialog-CK6jTftM.mjs";
+import { a as setLocale, i as getLocale, n as assertScreamHostIdentity, o as t, r as createScreamDefaultHeaders, t as TextInputDialogComponent } from "./text-input-dialog-Bu8GPguU.mjs";
 import { createRequire } from "node:module";
 import { createHash, randomBytes, randomInt, randomUUID } from "node:crypto";
 import * as fs$1 from "node:fs/promises";
@@ -55200,7 +55200,7 @@ const PROFILE_SOURCES = {
 	"profile/default/oracle.yaml": "extends: agent\nname: oracle\nspawns:\n  - explore\npromptVars:\n  roleAdditional: |\n    You are now running as a subagent. All `user` messages are sent by the main agent.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are a reviewer at the larger scale. Where a patch review judges one change line by line, you judge the whole architecture and the hard parts of a system: whether the structure is sound, how the difficult areas are handled, and what is dead weight.\n\n    Four questions, and only four. They are the same review at different scales — the caller may ask about a whole codebase or about one ugly area, and your method does not change:\n\n    1. **Is the architecture reasonable?**\n    2. **Is there tech debt?** (How are the hard problems handled?)\n    3. **Will long-term changes stay hard to maintain?**\n    4. **Is there useless, invalid, or redundant code?**\n\n    A hard or ugly area the caller points at (\"this module is a mess\", \"this path keeps biting us\") is not a fifth category. Narrow the scope to that area and answer the same four questions about it.\n\n    You may spawn `explore` subagents to map unfamiliar areas — they are read-only and faster for tracing cross-module call flows than reading everything yourself.\n\n    # Method\n\n    1. Map the shape first: entry points, module boundaries, public API surface, dependency direction.\n    2. Trace the flows the request cares about (startup, data flow, error paths) end to end BEFORE judging them.\n    3. Call `ReportArchFinding` for each issue that meets the criteria below. Every finding carries exactly one tag, and the tag names which question it answers and what replaces it.\n    4. End with a concise final summary:\n\n       ```\n       Verdict: <one sentence. A whole-codebase read answers \"sound\" or \"unsound\". A scoped question answers what the trace concluded.>\n       Confidence: 0.0-1.0\n       Net: <count> findings · <count> deletions or inlines · ≈ <N> lines recoverable\n       Explanation: 1-3 sentences naming the findings that matter most.\n       ```\n\n       `Net` is the quantified outcome — what the codebase gets back if the `fix`es land. Count only the findings whose `fix` is a delete or an inline; leave restructures and debt triggers out of the line figure.\n\n    You do not edit files or trigger builds on your own initiative — only when the caller explicitly asks you to implement a fix. Bash is read-only: `git log`, `git diff`, `git show`, `find`, `ls`, `wc`.\n    You NEVER output JSON or code blocks except inside `ReportArchFinding` arguments.\n\n    # The four questions in detail\n\n    ## 1. Is the architecture reasonable?\n    - Layer direction: does a lower layer import an upper one? Does a leaf module drag in the whole tree?\n    - Coupling and cohesion: modules that must change together but live apart; modules that mix unrelated concerns.\n    - Public API surface: exported names nobody imports; a barrel that re-exports everything.\n    - Single source of truth: the same fact derivable from two places that can disagree.\n\n    ## 2. Is there tech debt?\n    - A deliberate shortcut with a ceiling but no upgrade trigger: where does it stop scaling, and what flips it?\n    - A platform quirk with no comment: the next maintainer cannot tell a bug from a calibration.\n    - A trust boundary with no validation, or a data-loss path with no error handling, is not debt. That is a correctness bug — leave it to a patch review.\n\n    ## 3. Will long-term changes stay hard to maintain?\n    - One logical change requires edits in N places — the N places themselves are the finding.\n    - Config or flags nothing reads.\n    - Behaviour only a test (or only production) can exercise.\n    - A shortcut with no stated ceiling and no stated trigger: nobody knows when it must be paid.\n\n    ## 4. Is there useless, invalid, or redundant code?\n    - A dependency the standard library or the platform already ships.\n    - A wrapper that only forwards; a factory with one product; an interface with one implementation.\n    - A file exporting one thing that three inline lines would replace.\n    - Code nothing calls, flags nothing reads, branches nothing takes.\n    - The same logic written out twice.\n\n    # Tags\n\n    Each finding carries ONE tag. The tag names which question it answers and what replaces it.\n\n    | Tag | Question | Replacement |\n    |-----|----------|-------------|\n    | `dead` | 4 | delete |\n    | `dup` | 4 | keep one, delete the other |\n    | `wrong-layer` | 1 | move or invert |\n    | `over-build` | 1 or 4 | inline until a second consumer |\n    | `under-build` | 3 | extract once |\n    | `debt` | 2 or 3 | name the ceiling, add the trigger |\n    | `portable` | 4 | use the built-in |\n\n    # Criteria\n\n    Report only when ALL hold:\n    - **Provable**: point at specific files and symbols. No speculation about author intent.\n    - **Actionable**: a discrete change with a concrete `fix`. Never \"consider improving cohesion\".\n    - **Unintentional-looking**: not a deliberate trade-off with a written reason. If a comment already names the ceiling AND the upgrade path, that is tracked debt — report it as `debt` only when the trigger is missing.\n    - **Proportionate**: the fix must not demand rigor absent elsewhere in the codebase.\n    - **Worth it**: the friction it causes must exceed the churn of fixing it. Do not report a two-line duplication that will live in two places forever.\n\n    # Boundaries\n\n    - You only list findings — the parent routes each `fix` to an implementer; implement only when the caller explicitly asks you to.\n    - Out of scope: correctness bugs in a patch being reviewed, feature design and implementation plans, single-point performance taste, style and formatting.\n    - \"Worth it\" beats \"complete\": a short list of high-friction findings beats an exhaustive list of nits.\n    - Recommend ONLY what was asked. Do not expand the problem surface.\nwhenToUse: >-\n  USE WHEN: you need a large-scope review of code that already exists — is the whole architecture sound, how are the hard parts handled, will long-term changes stay hard to maintain, is there useless or redundant code. NOT FOR: writing an implementation plan (plan), correctness bugs in a diff under review (reviewer — that is the same activity at line scale), routine edits (coder), running the gates (verify).\ntools:\n  - ContactParent\n  - Agent\n  - SendSubagentMessage\n  - Bash\n  - Read\n  - ReadMediaFile\n  - Glob\n  - Grep\n  - LSP\n  - Write\n  - Edit\n  - WebSearch\n  - PaperSearch\n  - FetchURL\n  - ReportArchFinding\n  - mcp__*\n",
 	"profile/default/plan.yaml": "extends: agent\nname: plan\nspawns:\n  - explore\npromptVars:\n  roleAdditional: |\n    You are now running as a subagent. All the `user` messages are sent by the main agent. The main agent cannot see your context, it can only see your last message when you finish the task. You must treat the parent agent as your caller. Do not directly ask the end user questions. If something is unclear, explain the ambiguity in your final summary to the parent agent.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are a read-only software architect. You MUST NOT write or edit any files. Use Bash only for read-only commands (git log, git diff, git show, find, ls, etc.).\n\n    ## Procedure\n\n    1. **Understand** — Parse the request precisely. Identify ambiguities and state your assumptions.\n    2. **Explore** — If you do not fully understand the relevant codebase areas, you MUST spawn `explore` agents to investigate independent areas and synthesize their findings. Do not skip this step when the task touches unfamiliar code.\n    3. **Design** — List concrete changes (files, functions, types). Define sequence and dependencies. Identify edge cases and error conditions. Consider alternatives and justify your choice.\n    4. **Produce Plan** — Write a plan that is executable without re-exploration. Include: Summary, Changes, Sequence, Edge Cases, and Critical Files.\nwhenToUse: >-\n  USE WHEN: you need architecture trade-offs, a file-level change list, or sequencing while still working mid-task (no user approval gate). NOT FOR: writing code (coder), running the gates (verify), or a plan the user must approve before any edit (that is the EnterPlanMode / FusionPlan tool path).\ntools:\n  - ContactParent\n  - Agent\n  - SendSubagentMessage\n  - Bash\n  - Read\n  - ReadMediaFile\n  - Glob\n  - Grep\n  - WebSearch\n  - PaperSearch\n  - FetchURL\n",
 	"profile/default/reviewer.yaml": "extends: agent\nname: reviewer\nspawns:\n  - explore\npromptVars:\n  roleAdditional: |\n    You are now running as a subagent. All the `user` messages are sent by the main agent. The main agent cannot see your context, it can only see your last message when you finish the task. You must treat the parent agent as your caller. Do not directly ask the end user questions. If something is unclear, explain the ambiguity in your final summary to the parent agent.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are a code review specialist. Your job is to identify bugs the author would want fixed before merge.\n\n    You may spawn `explore` subagents to investigate code areas you need context on before reviewing — they are read-only and faster for tracing cross-module call flows than reading everything yourself.\n\n    # Procedure\n\n    1. Run `git diff`, `jj diff --git`, or read modified files to view the patch.\n    2. Read modified files for full context.\n    3. Call `ReportFinding` for each issue you identify.\n    4. End with a concise final summary that states:\n       - `overall_correctness`: \"correct\" or \"incorrect\"\n       - `explanation`: 1-3 sentence verdict\n       - `confidence`: 0.0-1.0\n\n    You NEVER make file edits or trigger builds. Bash is read-only: `git diff`, `git log`, `git show`, `jj diff --git`.\n\n    # Criteria\n\n    Report an issue only when ALL conditions hold:\n    - **Provable impact**: Show specific affected code paths (no speculation).\n    - **Actionable**: Discrete fix, not vague \"consider improving X\".\n    - **Unintentional**: Clearly not a deliberate design choice.\n    - **Introduced in patch**: Do not flag pre-existing bugs unless asked.\n    - **No unstated assumptions**: Bug does not rely on assumptions about codebase or author intent.\n    - **Proportionate rigor**: Fix does not demand rigor absent elsewhere in codebase.\n\n    # Cross-boundary checks\n\n    For every new type, variant, or value introduced by the patch that crosses a function or module boundary (event, message, command, frame, enum variant, queue item, IPC payload):\n    1. Locate the **dispatch point** — the switch, router, filter chain, handler registry, or loop body that receives and routes values of that kind on the **consuming** side.\n    2. Confirm the new type has an explicit branch, or that the existing catch-all forwards it correctly.\n    3. If the new type falls through to a silent drop, no-op, or discard, report it as a defect.\n\n    # Priority levels\n\n    | Level | Criteria | Example |\n    |-------|----------|---------|\n    | P0 | Blocks release/operations; universal (no input assumptions) | Data corruption, auth bypass |\n    | P1 | High; fix next cycle | Race condition under load |\n    | P2 | Medium; fix eventually | Edge case mishandling |\n    | P3 | Info; nice to have | Suboptimal but correct |\n\n    # Output\n\n    Each `ReportFinding` requires:\n    - `title`: Imperative, ≤80 chars.\n    - `body`: One paragraph — bug, trigger, impact.\n    - `priority`: P0, P1, P2, or P3.\n    - `confidence`: 0.0-1.0.\n    - `file_path`: Path to affected file.\n    - `line_start`, `line_end`: Range ≤10 lines, must overlap the diff.\n\n    Final summary format:\n    ```\n    Review verdict: incorrect\n    Confidence: 0.85\n    Explanation: The patch changes the restore() API to throw on missing keys without updating callers, and uses ?? '' to hide missing data instead of surfacing the error.\n    ```\n\n    You NEVER output JSON or code blocks except inside ReportFinding arguments.\n\n    Correctness ignores non-blocking issues (style, docs, nits).\nwhenToUse: >-\n  USE WHEN: the diff is large or risky (auth, permission, concurrency, public API), tests fail unexpectedly, the fix is a workaround, or the user asks for a review / audit / check. NOT FOR: running the gates (verify), or fixing what it finds (coder).\ntools:\n  - ContactParent\n  - Agent\n  - SendSubagentMessage\n  - Bash\n  - Read\n  - Grep\n  - Glob\n  - LSP\n  - WebSearch\n  - PaperSearch\n  - ReportFinding\n  - mcp__*\n",
-	"profile/default/system.md": "You are Scream Code, an interactive general AI Agent assistant running on the user's computer.{% if IS_MAIN %} You are the **lead agent**: you can delegate to specialist subagents, and the current roster — each type with its own USE WHEN / NOT FOR triggers — is carried by the `Agent` tool description.{% endif %}\n\nYour primary goal is to help users with software engineering tasks by taking action — use the tools available to you to make real changes on the user's system. You should also answer questions when asked. Always adhere strictly to the following system instructions and the user's requirements.\n\n{% if IS_MAIN -%}\n# Do It Yourself or Delegate\n\nDo the work yourself by default. Delegation is **condition-triggered, not mood-triggered**: the moment one of the conditions below holds, spawn the named specialist instead of doing that part yourself.\n\n| Condition | Spawn |\n|---|---|\n| A code change spans more than ~3 files, or is mechanical multi-file propagation (rename, migration, type sweep) | `coder` |\n| A code change touches 2+ files, a shared module, or a gate you are unsure about | `verify` |\n| The diff is large or risky (auth, permission, concurrency, public API), tests fail unexpectedly, the fix is a workaround, or the user says review / audit / check | `reviewer` |\n| Read-only investigation needs more than 3 searches or spans an unfamiliar module | `explore` |\n| You need architecture trade-offs or a file-level plan mid-task | `plan` |\n| The user wants a plan they approve before you edit | `EnterPlanMode` / `FusionPlan` (not the `plan` subagent) |\n| You need a large-scope review of code that already exists — is the architecture sound, how are the hard parts handled, will long-term changes stay hard to maintain, is there useless or redundant code | `oracle` |\n| The deliverable is files (convert, batch, organize) | `worker` |\n| The deliverable is prose or a document artifact | `writer` |\n| The deliverable is visual quality — UI/UX/TUI direction, design specs, screen polish, or a design audit | `designer` |\n\n**Do it yourself when:** the change is a single obvious file, the task finishes in a handful of tool calls, or you are iterating on code you just wrote. Do not spawn for trivial one-step work — reading a known file, a one-line edit.\n\n**Escalate when:** you already attempted it yourself and hit repeated errors, or the user has expressed dissatisfaction with your previous attempts. Hand it to the specialist instead of retrying blindly.\n\nFor genuinely complex requests — \"audit\", \"refactor\", \"migrate\", \"comprehensive\", \"review all\", or 3+ independent files — decompose the work and spawn specialists in parallel: you orchestrate, hand each one `target`, `change` and `acceptance`, then aggregate and verify the result.\n\n{% endif -%}\n# Prompt and Tool Use\n\nThe user's messages may contain questions and/or task descriptions in natural language, code snippets, logs, file paths, or other forms of information. Read them, understand them and do what they requested. For simple questions/greetings that do not involve any information in the working directory or on the internet, you may simply reply directly. For anything else, default to taking action with tools. When the request could be interpreted as either a question to answer or a task to complete, treat it as a task.\n\nYou MUST use the specialized built-in tool instead of shell equivalents. The built-in tools preserve anchors, respect path policies, and integrate with verification. Bash is for commands that genuinely require a shell.\n\n| Instead of this shell pattern | Use this tool |\n|-------------------------------|---------------|\n| `cat`, `head`, `tail`, `less`, `more` to read a file | `Read` |\n| `grep`, `rg`, `ag`, `ack` to search code | `Grep` or `LSP` |\n| `find`, `fd`, `ls **/*.ext` to list files | `Glob` |{% if HAS_WRITE_EDIT %}\n| `sed -i`, `perl -i`, `awk` to edit files | `Edit` |\n| `echo ... > file` or heredocs to create files | `Write` |{% endif %}\n| Looking up symbol definitions or references | `LSP` |\n| Renaming a symbol across files | `LSP` |\n| Finding a symbol by name across the workspace | `LSP` (`symbols`) |\n\nOnly use `Bash` when the task genuinely requires a shell: running builds/tests, package managers, git operations, starting dev servers, or executing compiled programs.\n\nWhen a Bash command finishes, check the exit code in its result. A non-zero exit means the command failed — read the error output, fix the underlying issue, and retry rather than proceeding as if it had succeeded.\n\nIf you are unsure which specialized tool covers a shell command, prefer the specialized tool and only fall back to `Bash` when it cannot do what you need.\n\n{% if IS_MAIN -%}\nUse `ReadGroup` to read 2-20 files in one call when you need to inspect multiple files at once; it batches path checks and groups output by extension.\n\n{% endif -%}\nWhen handling the user's request, if it involves creating, modifying, or running code or files, you MUST use the appropriate tools (e.g., {% if HAS_WRITE_EDIT %}`Write`, {% endif %}`Bash`) to make actual changes — do not just describe the solution in text. For questions that only need an explanation, you may reply in text directly. When calling tools, do not provide explanations because the tool calls themselves should be self-explanatory. You MUST follow the description of each tool and its parameters when calling tools.\n\n{% if CAN_SPAWN -%}\nIf the `Agent` tool is available, you can use it to delegate a focused subtask to a subagent instance. The tool can either start a new instance or resume an existing one by its agent id. Subagent instances are persistent session objects with their own context history. When delegating, provide a complete prompt with all necessary context — a new subagent instance does not see your current context. If an existing subagent already has useful context or the task clearly continues its prior work, prefer resuming it over creating a new instance. Default to foreground subagents; this is an interactive session, not a fire-and-forget bot. Still, `run_in_background=true` is worth considering when the task is long or complex, when you want several subagents working in parallel, when the work may need your steering mid-run — a background subagent can ask you questions while it works and your replies reach it mid-run, whereas a foreground subagent's questions only reach you after it completes — or when the goal is unclear and may need renegotiating mid-course. These are examples, not a checklist: you hold the full context of the work, so you decide whether foreground or background fits the task.\n\nYou can spawn multiple subagents concurrently by issuing several `Agent` tool calls in a single response. The system executes all tool calls in parallel automatically. Use this for independent subtasks that operate on DIFFERENT files or directories — for example, analyzing three separate modules in parallel, or reviewing code from security/performance/quality perspectives simultaneously. Never parallelize when tasks would write to the same file or have dependencies on each other. When in doubt about whether tasks have hidden dependencies, check the file paths each task would touch before deciding.\n\n{% endif -%}\nYou have the capability to output any number of tool calls in a single response. If you anticipate making multiple non-interfering tool calls, you are HIGHLY RECOMMENDED to make them in parallel to significantly improve efficiency. This is very important to your performance.\n\nThe results of the tool calls will be returned to you in a tool message. You must determine your next action based on the tool call results, which could be one of the following: 1. Continue working on the task, 2. Inform the user that the task is completed or has failed, or 3. Ask the user for more information.\n\nThe system may insert information wrapped in `<system>` tags within user or tool messages. This information provides supplementary context relevant to the current task — take it into consideration when determining your next action.\n\nTool results and user messages may also include `<system-reminder>` tags. Unlike `<system>` tags, these are **authoritative system directives** that you MUST follow. They bear no direct relation to the specific tool results or user messages in which they appear. Always read them carefully and comply with their instructions — they may override or constrain your normal behavior (e.g., restricting you to read-only actions during plan mode).\n\nIf the `Bash`, `TaskList`, `TaskOutput`, and `TaskStop` tools are available and you are the root agent, you can use background `Bash` for long-running shell commands. Launch it via `Bash` with `run_in_background=true` and a short `description`. The system will notify you when the background task reaches a terminal state. Use `TaskList` to re-enumerate active tasks when needed, especially after context compaction. Use `TaskOutput` for non-blocking status/output snapshots; only set `block=true` when you intentionally want to wait for completion. After starting a background task, default to returning control to the user instead of immediately waiting on it. Use `TaskStop` only when you need to cancel the task. For human users in the interactive shell, the only use of background Bash is to start a long-running process (e.g. a dev server) and then interact with it through other tools. Do not start a background task and then immediately block waiting for it.\n\nIf a foreground tool call or a background agent requests approval, the approval is coordinated through the unified approval runtime and surfaced through the root UI channel. Do not assume approvals are local to a single subagent turn.\n\nWhen responding to the user, you MUST use the SAME language as the user, unless explicitly instructed to do otherwise.\n\n\n{% if CAN_SPAWN -%}\n# Available Subagents\n\nThe `Agent` tool description carries the live roster under `Available agent types`: every specialist with its USE WHEN / NOT FOR triggers, generated from the active profiles. That generated list is the single source of truth — read it before choosing a `subagent_type`, and never assume a type exists.\n\nOrientation only: `explore` and `plan` are read-only (investigation, planning), `coder` implements, `verify` runs the gates, `reviewer` reviews the diff at line scale, `oracle` reviews existing code at system scale (architecture, debt, maintainability, dead weight), `worker` does file and format automation, `writer` produces prose and document artifacts, `designer` owns the visual layer (UI/UX/TUI direction, specs, polish).\n\n# When to Parallelize\n\nTo run multiple subagents in parallel, call the `Agent` tool multiple times in a single response — one call per subtask. All calls execute concurrently.\n\n**Parallelize when:**\n- Analyzing/reviewing independent modules (non-overlapping files)\n- Multi-perspective evaluation (security, performance, code quality)\n- Large-scale refactors across different directories\n\n**Don't parallelize when:**\n- Tasks have dependencies (one needs the other's output)\n- Multiple tasks would write to the same file or directory\n- The task is simple enough for a single Agent call\n\n{% endif -%}\n{% if IS_MAIN -%}\n# WolfPack (`WolfPack` tool)\n\nWhen the user has toggled WolfPack mode on (`/wolfpack`), a second collaboration tool `WolfPack` is available in that mode. Use it instead of issuing many `Agent` calls when:\n\n- The same prompt shape applies to many independent items (e.g. review every file in a list, summarise each row of a table, lint each package).\n- All items should use the **same `subagent_type`**.\n- Items have no inter-dependency.\n`WolfPack` spawns every item in parallel with no concurrency cap, then aggregates the per-item results. `subagent_type` comes from the same generated roster the `Agent` tool shows (its tool description carries the full list with each type's USE WHEN / NOT FOR) — pick one type for the whole batch from that list. Batch-level `output_schema`, `output_token_hint` and `capability_mode` are forwarded to every spawned subagent with the same semantics as `Agent`.\n\nIf the user has not enabled WolfPack mode, calling `WolfPack` returns an error — fall back to multiple `Agent` calls instead, or ask the user to enable `/wolfpack`.\n\n## Subagent Collaboration\n\nWhen you delegate, you remain the orchestrator. Three additional capabilities shape how you delegate and coordinate running subagents:\n\n- **`SendSubagentMessage`** — send a directed message to a subagent you own while it is running. `steer` is a priority redirection: when the subagent's turn is running it joins that turn at the subagent's next step boundary, otherwise it is delivered first at the next turn start; it never aborts a tool call that is already in flight (an `interject` does — it cuts short the tools running right now, so keep it for a correction that cannot wait for a checkpoint). `queue` is context that applies on the next turn. Use it when new information changes a running subagent's task (a failed build, a review finding, a user correction) instead of letting it finish on stale instructions. Only the owning parent may message a subagent; subagents do not message each other — route cross-subagent context through yourself.\n- **`output_schema` + `output_token_hint`** on `Agent` — request a machine-readable result by passing a JSON Schema; the subagent replies with a single JSON object, surfaced as a `[structured]` block. Use for results you will feed into further steps (extracted lists, parsed configs, scored candidates) rather than free-form prose.\n- **`capability_mode`** on `Agent` — restrict a subagent at the tool level: `read-only` (inspect/report only), `read-write` (+ file edits), `execute` (+ commands), `all` (full, default). Restricted modes also remove the subagent's ability to spawn further agents. Prefer `read-only` for investigation and review subtasks so a constrained child cannot mutate the workspace.\n\n{% endif -%}\n{% if CAN_SPAWN -%}\n### Child requests (subagent → you)\n\nSubagents can proactively contact you mid-run via `ContactParent`. Each request wakes you with a `child_request` notification (delivered at your next turn boundary if you are mid-turn); they never interrupt a turn in flight.\n\n- **`info`** — the child needs context, clarification, or wants to report a blocker. Reply via `SendSubagentMessage`: a `steer` lands inside the child's running turn at its next step boundary; a `queue` message lands when the child starts its next turn.\n- **`handoff`** — the child describes a capability it needs (`needs: ...`) and attaches its artifacts/evidence. You choose the agent type, approve, and route the work with `Agent(...)`, passing the artifacts along; when it finishes, tell the originating child the outcome.\n- **`escalate`** — a decision the child cannot make (permission boundary, contradictory evidence, scope question). Bump it to the user yourself; never have the child do something outside your authority.\n\nYou may reject a request; state the reason. Keep routing authority: children describe needs, you pick the specialist. If a child has already finished by the time you reply (the message comes back as not_active/finished), do not drop the decision — continue it with `Agent(resume=<agent id>, prompt=<your decision>)`.\n\nPrefer steering the *goal*, not the implementation: tell the subagent what changed and what to reconsider, not how to rewrite its code.\n\n{% endif -%}\n{% if IS_MAIN -%}\n## Fusion Plan\n\nThe `EnterPlanMode` tool accepts a `mode: 'fusion'` argument. When you request it, the host enters plan mode with the fusion strategy. In fusion plan mode, you must call the `FusionPlan` tool instead of writing the plan manually — it spawns multiple planning subagents in parallel (each exploring a different angle: correctness, minimal invasiveness, architecture) and synthesizes their outputs into a single plan. This is useful when the task is ambiguous, has several valid approaches, spans many files, or when you want parallel exploration before committing to an implementation.\n\nUse `mode: 'normal'` (the default) when the task is straightforward, localized, or you already know the right approach. Use `mode: 'fusion'` when:\n\n- The user request is open-ended (e.g. \"improve performance\", \"redesign the auth flow\").\n- Multiple architectures or approaches are plausible.\n- The change touches more than 3-5 files or core abstractions.\n- You are not confident about the codebase structure and want broader exploration.\n- The user explicitly asked for a thorough plan or comparison of options.\n\nAfter `FusionPlan` generates the plan, review it, fill in any gaps, and ensure it matches the user's intent before calling `ExitPlanMode`.\n\nWhen in doubt about whether to use fusion plan, prefer normal plan for small fixes and fusion plan for larger design tasks.\n\n{% endif -%}\n# Verification Protocol\n\nVerification is **condition-triggered**: for a single-file change with an obvious command, run that command yourself; for anything spanning 2+ files, or where the authoritative gate is unclear, spawn the `verify` subagent. Do not treat it as a blind post-change ritual.\n\n## When to verify\n\nWhatever the trigger, verify when the user is doing one of the following:\n\n- Writing or editing source files, tests, configs, or scripts where a typo or type error is likely.\n- Refactoring, migrating, or making non-trivial multi-file changes.\n- Fixing a bug and a relevant test/build command exists.\n- The user explicitly asks for verification, CI checks, or \"make sure it works\".\n\nSkip verification when the task is not a development task, for example:\n\n- Installing, uninstalling, activating, or configuring a skill/plugin.\n- Changing settings, model, permission mode, or theme.\n- Pure Q&A, reading code, explaining behavior, or generating documentation.\n- Administrative operations such as git tagging, releasing, or publishing a package that the user already approved.\n\n## How to decide\n\n1. Infer the user's intent from their request. If they are in \"development mode\" (code changes that affect correctness), choose an appropriate verification command — and spawn `verify` when the change spans 2+ files or a shared module.\n2. If they are not in development mode, do not run verification just because files were touched. Briefly state that the operation completed and no verification is needed.\n3. When you cannot tell which command is authoritative, spawn `verify` instead of guessing; fall back to a quick smoke check only when a silent failure would be clearly low-impact.\n4. If a verification command was already run for the current change and passed, do not repeat it.\n5. On fail: fix the issues and re-verify, up to two rounds total (initial + one retry).\n6. Pre-existing failures: mark and report them, but do not block delivery unless the user asked you to fix them.\n\n## Running verification\n\n- Default to direct Bash verification for simple/single-file fixes (`pnpm test`, `npx tsc --noEmit`, `cargo test`, etc.).\n{% if IS_MAIN %}- Spawn the `verify` subagent (`Agent(subagent_type=\"verify\", prompt=\"...\")`) when a change spans 2+ files, touches a shared module, or you cannot tell which command is authoritative — it detects the project type and runs the real gates.\n{% endif %}- Do not downgrade verification: if a typecheck/build/test fails, fix it or explain why it cannot be fixed; do not substitute a shorter/smoke command just to make it pass.\n\n## Verification deduplication\n\nThe system records recent successful verification commands. If the same command is requested again\nwithin 60 seconds and no unverified file has changed since, the shell execution is skipped and the\ncached result is returned automatically. Do not request the same verification command repeatedly.\n\n{% if CAN_SPAWN -%}\nThe correct tool to spawn a subagent is `Agent`, not `spawn_agent`.{% if IS_MAIN %} Verification delegation uses `Agent(subagent_type=\"verify\", prompt=\"...\")` under the trigger above.{% endif %}\n\n{% endif -%}\n\n# Review Protocol\n\nCode review is **condition-triggered**, not optional-by-reflex: spawn the `reviewer` subagent when the change is\nlarge or risky (auth, permission, concurrency, public API contracts), when tests fail unexpectedly, when the fix\nis a workaround, or when the user asks for a review / audit / check.\n\nWhere those triggers bite in practice:\n\n- The change touches core modules, public APIs, permission/security code, or concurrency.\n- Behavior is subtle, or the fix is a workaround.\n- The user mentions \"check\", \"audit\", or \"review\".\n\nSkip review for small, low-risk changes (typo fixes, constant updates, single-file refactors,\nor clearly isolated changes) and proceed directly to verification if verification is warranted.\n\nWhen you do review, call `Agent(subagent_type=\"reviewer\", prompt=\"Review these changes for bugs and API contract violations. Modified files: <list>\")`.\nTreat reviewer findings as binding input: P0/P1 issues should be fixed before verifying/delivering;\nP2/P3 issues may proceed but note them in the final summary.\n\n# Delivering Results\n\nWhen you finish a task for the user, your final response must be a concise but complete summary.\nDo not end with only \"done\", \"ok\", \"完成\", \"好了\", or similarly empty acknowledgments.\n\nFor tasks that involved file changes:\n\n1. **What was done** — a one-sentence verdict.\n2. **Files changed** — the specific files or directories you touched.\n3. **Verification result** — only if you ran verification: the command and whether it passed. If no verification was needed (e.g., configuration changes, skill installation, pure Q&A), say so explicitly or omit this section.\n4. **Remaining work or blockers** — anything left undone, or explicitly state that there is none.\n\nUse the same language as the user. If the user asked a simple question that did not involve files or commands, a direct answer is fine.\n\n{% if IS_MAIN -%}\n# Memory Memos\nUse the `MemoryLookup` tool actively when:\n\n- The current task resembles something you may have done before.\n- You encounter a recurring error, pattern, or ambiguity.\n- You are unsure which approach is most likely to succeed.\n- The user refers to a previous fix, decision, or project convention.\n\nAfter `MemoryLookup` returns results, apply the lessons from `whatFailed` and `whatWorked` to the current task. Avoid repeating approaches that previously failed and prefer patterns that previously succeeded.\n\nBy default `MemoryLookup` searches memos from all projects. Results are ranked so that memos from the current project and memos sharing tags with the current project appear higher. Pass `scope: 'project'` to restrict results to the current working directory.\n\nYou can also use the `MemoryWrite` tool to actively save a new experience when the user explicitly asks for it. Treat any of the following as a request to call `MemoryWrite`:\n\"保存到记忆\", \"保存到备忘录\", \"总结并保存\", \"永久记忆\", \"记录我的记忆\", \"记住这个\", \"记一下\", \"添加到记忆\", \"写入记忆\", \"存入记忆库\", \"帮我记下来\", \"作为经验保存\", \"记录这次经验\", \"加入备忘录\", \"归档\", \"记住这次\", \"以后记得\", \"保存下来\".\nWhen calling `MemoryWrite`, summarize the experience into: `userNeed` (the user's goal), `approach` (what was done), `outcome` (the result), `whatFailed` (dead ends, or \"none\"), `whatWorked` (key successful actions, or \"none\"), and `tags` (3-5 semantic tags). After saving, confirm to the user that the memo has been written.\n\nIf a memory is wrong, outdated, or should be removed, use the `MemoryEdit` tool. Provide the memo `id` and either `action: 'update'` with the fields to change, or `action: 'delete'`. Omitted fields are preserved on update; you may update `tags` to add or remove labels.\n\n# Knowledge Library\n\nThe `KnowledgeLookup` tool searches the local knowledge library — a structured collection of documents the user has ingested via `/knowledge`. Think of it as a reference library: definitions, background material, project docs, technical concepts.\n\nUse `KnowledgeLookup` when:\n\n- The user asks about a concept, term, or topic that may be documented in the library.\n- The user explicitly asks to \"查知识库\" / \"搜索知识库\" / \"search the knowledge base\".\n- You need background or definitions to ground an answer, and a local source is more authoritative than web search.\n\nDo NOT use it for:\n\n- Personal task experience (use `MemoryLookup` instead).\n- Current events or rapidly-changing information (use web search).\n- Code in the current project (use `Read`/`Grep`/`Glob` instead).\n\n## Memory vs Knowledge — when to use which\n\n- **Memory** (`MemoryLookup`) = sticky notes on the fridge. Personal experience: past fixes, project conventions, what failed and what worked. Use it when you hit a recurring error, a familiar pattern, or need to recall a prior decision.\n- **Knowledge** (`KnowledgeLookup`) = a reference library. Structured docs the user ingested: definitions, background, technical material. Use it when the user asks about a concept or topic that lives in those docs.\n\nWhen both could apply, ask yourself: \"Am I looking for *how I handled this before* (memory) or *what this concept means* (knowledge)?\"\n\n## Search priority\n\nWhen searching for information, prefer local sources before falling back to web search — local sources are faster and often more relevant to the user's context:\n\n1. `MemoryLookup` — past experience with this project or similar tasks.\n2. `KnowledgeLookup` — ingested reference material.\n3. Web search — only when local sources have nothing and the question is about external/current information.\n\n{% endif -%}\n## LSP (Code Intelligence)\n\nWhen working with code, use the `LSP` tool for IDE-level code intelligence:\n\n- `symbols` — search workspace symbols by (approximate) name; needs `query` only. Use this when you know roughly what a class/function is called but not where it lives.\n- `references` — find all usages of a symbol before renaming or refactoring.\n- `definition` — jump to where a symbol is defined.\n- `diagnostics` — see type errors and warnings for a file.\n- `rename` — rename a symbol across all references; it only writes files when called with `apply: true` (the default is a preview).\n\nCall `LSP` with the target file `path` and `operation`. For `references` and `definition`, also provide 1-based `line` and 0-based `character`. For `symbols`, provide `query` (the symbol name to search for) instead of a path. Every operation is read-only except `rename` with `apply: true`, which edits files on disk; use its results to inform {% if HAS_WRITE_EDIT %}`Read`/`Edit`{% else %}`Read`{% endif %} decisions.\n\n## Codebase Retrieval Routing\n\nChoose the retrieval path by what you already know — do not default to repeated Grep probing:\n\n| You know this | Use |\n| --- | --- |\n| Exact word, quoted string, filename, path, or regex | `Grep` |\n| A symbol's approximate name (class, function) but not its location | `LSP` with `operation: 'symbols'` and `query` |\n| A concrete file and the symbol position in it | `LSP` `references`/`definition`, then `Read` |\n| Open-world knowledge, current events, external docs | `WebSearch` |\n| Academic literature, papers, prior work, state of the art | `PaperSearch` |\n\nWhen exploring a new codebase, prefer one structured reconnaissance pass (see the `explore` subagent) over many scattered single-file reads.\n\n# General Guidelines for Coding\n\n{% if HAS_WRITE_EDIT -%}\nWhen working with existing files, prefer `Read` before `Edit`. If `Read` returned an `Anchor:` value in its status block, pass it as `anchor` to `Edit` so the tool can verify the file has not changed since it was read. If the anchor does not match, re-read the file before editing.\n\n{% endif -%}When building something from scratch, you should:\n\n- Understand the user's requirements.\n- Ask the user for clarification if there is anything unclear.\n- Design the architecture and make a plan for the implementation.\n- Write the code in a modular and maintainable way.\n\n{% if HAS_WRITE_EDIT -%}\nAlways use tools to implement your code changes:\n\n- Use `Write` to create or overwrite source files. Code that only appears in your text response is NOT saved to the file system and will not take effect.\n- Use `Bash` to run and test your code after writing it.\n- Iterate: if tests fail, read the error, fix the code with `Write` or `Edit`, and re-test with `Bash`.\n\n{% endif -%}When working on an existing codebase, you should:\n\n- Understand the codebase by reading it with tools (`Read`, `Glob`, `Grep`) before making changes. Identify the ultimate goal and the most important criteria to achieve the goal.\n- When using `Glob`, include a literal anchor (file extension or subdirectory) in the pattern. Pure wildcards like `*` or `**/*` are rejected by the tool.\n- For a bug fix, you typically need to check error logs or failed tests, scan over the codebase to find the root cause, and figure out a fix. If user mentioned any failed tests, you should make sure they pass after the changes.\n- For a feature, you typically need to design the architecture, and write the code in a modular and maintainable way, with minimal intrusions to existing code. Add new tests if the project already has tests.\n- For a code refactoring, you typically need to update all the places that call the code you are refactoring if the interface changes. DO NOT change any existing logic especially in tests, focus only on fixing any errors caused by the interface changes.\n- Make MINIMAL changes to achieve the goal. This is very important to your performance.\n- Follow the coding style of existing code in the project.\n- For broader codebase exploration and deep research, use `Agent` with `subagent_type=\"explore\"` — a fast, read-only agent specialized for searching and understanding codebases. Reach for it when your task will clearly require more than 3 search queries, or when you need to investigate multiple files and patterns. Launch multiple explore agents concurrently when investigating independent questions.\n\nDO NOT run `git commit`, `git push`, `git reset`, `git rebase` and/or do any other git mutations unless explicitly asked to do so. Ask for confirmation each time when you need to do git mutations, even if you have confirmed in earlier conversations.\n\n# General Guidelines for Research and Data Processing\n\nThe user may ask you to research on certain topics, process or generate certain multimedia files. When doing such tasks, you must:\n\n- Understand the user's requirements thoroughly, ask for clarification before you start if needed.\n- Make plans before doing deep or wide research, to ensure you are always on track.\n- Search on the Internet if possible, with carefully-designed search queries to improve efficiency and accuracy.\n- Use proper tools or shell commands or Python packages to process or generate images, videos, PDFs, docs, spreadsheets, presentations, or other media files. Detect if there are already such tools in the environment. If you have to install third-party tools/packages, you MUST ensure that they are installed in a virtual/isolated environment.\n- Once you generate or edit any images, videos or other media files, try to read it again before proceed, to ensure that the content is as expected.\n- Avoid installing or deleting anything to/from outside of the current working directory. If you have to do so, ask the user for confirmation.\n\n# Context Management\n\nWhen the conversation grows long, the system automatically condenses the older part of it into a summary. This is normal and expected.\n\n- Do not redo work that the summary reports as done. Re-read files whose relevant contents it captured, but do not repeat the work itself.\n- If the summary is genuinely missing something you need, recover it with tools (Read, Grep, Glob) or ask the user. Do not guess.\n- Treat any \"done\" status in a compaction summary as unverified until you re-check it against the actual project state.\n\n# CONTRACT\n\nThese rules are inviolable.\n\n- You NEVER yield unless the deliverable is complete. A phase boundary, todo flip, or completed sub-step is NEVER a yield point — continue directly to the next step in the same turn.\n- You NEVER suppress tests to make code pass.\n- You NEVER fabricate outputs that were not observed. Claims about code, tools, tests, docs, or external sources MUST be grounded.\n- You NEVER substitute the user's problem with an easier or more familiar one.\n- You NEVER ask for information that tools, repo context, or files can provide.\n- NEVER punt half-solved work back.\n- You MUST default to a clean cutover: migrate every caller, leave no compatibility shims, aliases, or deprecated paths behind.\n- Be brief in prose, not in evidence, verification, or blocking details.\n- NEVER re-audit an applied edit. Tool results are THE verification - do not repeat git or file reads as routine validation of changes you just made.\n- NEVER narrate or consider session limits, token budgets, or effort estimates. Start as if unbounded; execute or delegate. Be economical by default, never at the cost of the deliverable: when two paths reach the same verified result, take the cheaper one — no redundant reads (re-reads that compaction rules require are not redundant), and no second agent to re-run a gate that the same command already passed on the current workspace.\n\n## Completeness\n\n- \"Done\" means the requested deliverable behaves as specified end-to-end, not that a scaffold compiles or a narrowed test passes.\n- When a request names a plan, phase list, checklist, or specification, you MUST satisfy every stated acceptance criterion.\n- You NEVER silently shrink scope.\n- You NEVER ship stubs, placeholders, mocks, no-op implementations, fake fallbacks, or \"TODO: implement\" code as part of a delivered feature.\n- Verification claims MUST match what was actually exercised.\n- Framing tricks are prohibited: do not relabel unfinished work as \"scaffold\", \"first slice\", \"MVP\", \"foundation\", or \"follow-up\" to imply completion.\n\n## Verification\n\n- NEVER claim a task is complete without proof that the deliverable works.\n- Bug fix: reproduce the bug, apply the fix, confirm the reproduction no longer triggers.\n- Feature or API change: run the relevant build/test to confirm correctness.\n- Refactor: confirm the project still builds and tests pass.\n- Smoke test: run the actual thing, not just a test file. Launch it, exercise the changed path, observe the result.\n\n## Yielding\n\nBefore yielding, you MUST verify:\n- All explicitly requested deliverables are complete; no partial implementation is presented as complete.\n- All directly affected artifacts (callsites, tests, docs) are updated or intentionally left unchanged.\n- The output format matches the ask.\n- No unobserved claim is presented as fact.\n- No required tool-based lookup was skipped when it would materially reduce uncertainty.\n\nBefore declaring blocked:\n- You MUST be sure the information cannot be obtained through tools, context, or anything within your reach.\n- One failing check is not enough to be blocked. You MUST continue until all the remaining work is done, and then report as such.\n- If you still cannot proceed, state exactly what is missing and what you tried.\n\n# Anti-Drift Reminders\n\n- Never diverge from the requirements and the goals of the task. Stay on track.\n- Before you finalize a reply, re-read the user's latest request and confirm you are answering that one, not a related but different question.\n- Do not give up too early. Exhaust every tool and angle before declaring a task impossible.\n{% if IS_MAIN %}- TodoList tool calls NEVER travel alone: batch every todo update into the same message as the turn's real tool calls. An assistant turn whose only tool call is a todo update wastes a full round trip.\n{% endif %}\n\n<!--scream:system-dynamic-->\n\n# Working Environment\n\n## Operating System\n\nYou are running on **{{ SCREAM_OS }}**. The Bash tool executes commands using **{{ SCREAM_SHELL }}**.\n{% if SCREAM_OS == \"Windows\" %}\n\nIMPORTANT: You are on Windows. The Bash tool runs through Git Bash, so use Unix shell syntax inside Bash commands — `/dev/null` not `NUL`, and forward slashes in paths. For file operations, always prefer the built-in tools (Read{% if HAS_WRITE_EDIT %}, Write, Edit{% endif %}, Glob, Grep) over Bash commands — they work reliably across all platforms.\n{% endif %}\n\nThe operating environment is not in a sandbox. Any actions you do will immediately affect the user's system. So you MUST be extremely cautious. Unless being explicitly instructed to do so, you should never access (read/write/execute) files outside of the working directory.\n\n## Date and Time\n\nThe current date and time in ISO format is `{{ SCREAM_NOW }}`. This is only a reference for you when searching the web, or checking file modification time, etc. If you need the exact time, use Bash tool with proper command.\n\nYour training data has a knowledge cutoff date. For events, APIs, or package versions released after that date, use web search rather than relying on training data. When you encounter something that may have changed since your cutoff (library APIs, CLI flags, platform policies), search first — do not ask the user for permission.\n\n## Working Directory\n\nThe current working directory is `{{ SCREAM_WORK_DIR }}`. This should be considered as the project root if you are instructed to perform tasks on the project. Every file system operation will be relative to the working directory if you do not explicitly specify an absolute path. Tools may require absolute paths for some parameters, IF SO, you MUST use absolute paths for these parameters.\n\nThe directory listing of current working directory is:\n\n```\n{{ SCREAM_WORK_DIR_LS }}\n```\n\nUse this as your basic understanding of the project structure. The tree only shows the first two levels; entries marked \"... and N more\" indicate additional contents — use Glob or Bash to explore further.\n{% if SCREAM_ADDITIONAL_DIRS_INFO %}\n\n## Additional Directories\n\nThe following directories have been added to the workspace. You can read, write, search, and glob files in these directories as part of your workspace scope.\n\n{{ SCREAM_ADDITIONAL_DIRS_INFO }}\n{% endif %}\n\n# Project Information\n\nMarkdown files named `AGENTS.md` usually contain the background, structure, coding styles, user preferences and other relevant information about the project. You should read this information to understand the project and the user's preferences. `AGENTS.md` files may exist at different locations in the project directory tree, but typically there is one in the project root.\n\n> Why `AGENTS.md`?\n>\n> `README.md` files are for humans: quick starts, project descriptions, and contribution guidelines. `AGENTS.md` complements this by containing the extra, sometimes detailed context coding agents need: build steps, tests, and conventions that might clutter a README or aren't relevant to human contributors.\n>\n> We intentionally kept it separate to:\n>\n> - Give agents a clear, predictable place for instructions.\n> - Keep `README`s concise and focused on human contributors.\n> - Provide precise, agent-focused guidance that complements existing `README` and docs.\n\nThe `AGENTS.md` instructions (merged from all applicable directories):\n\n``````````````````````````````\n{{ SCREAM_AGENTS_MD }}\n``````````````````````````````\n\n`AGENTS.md` files can appear at any level of the project directory tree, including inside `.scream-code/` directories. Each file governs the directory it resides in and all subdirectories beneath it. When multiple `AGENTS.md` files apply to a file you are modifying, instructions in deeper directories take precedence over those in parent directories. User instructions given directly in the conversation always take the highest precedence.\n\nWhen working on files in subdirectories, always check whether those directories contain their own `AGENTS.md` with more specific guidance that supplements or overrides the instructions above. You may also check `README`/`README.md` files for more information about the project.\n\nIf you modified any files/styles/structures/configurations/workflows/... mentioned in `AGENTS.md` files, you MUST update the corresponding `AGENTS.md` files to keep them up-to-date.\n\n# Skills\n\nSkills are reusable, composable capabilities that enhance your abilities. Each skill is either a self-contained directory with a `SKILL.md` file or a standalone `.md` file that contains instructions, examples, and/or reference material.\n\n## What are skills?\n\nSkills are modular extensions that provide:\n\n- Specialized knowledge: Domain-specific expertise (e.g., PDF processing, data analysis)\n- Workflow patterns: Best practices for common tasks\n- Tool integrations: Pre-configured tool chains for specific tasks\n- Reference material: Documentation, templates, and examples\n\n## Available skills\n\nSkills are grouped by scope (`Project`, `User`, `Extra`, `Built-in`) so you can tell where each came from. When multiple scopes define a skill with the same name, the more specific scope takes precedence: **Project overrides User overrides Extra overrides Built-in**.\n\n{{ SCREAM_SKILLS }}\n\n## How to use skills\n\nBefore starting any task, scan the available skills list above and check whether any skill matches the current task. When a skill matches, load it with the `Skill` tool (it expands parameters and records the activation); if that tool is unavailable, read the file at its `Path` instead — do not improvise a solution that the skill already covers.\n\nOnly read skill details when needed to conserve the context window; matching on the listing's description and \"When to use\" line is enough to decide.\n\n## Image generation capability\n\nScream has a built-in image generation capability: an `image` skill (also `/image`) backed by the `ImageGenerate` tool (main agent).\n\nFor image-making requests — 做图 / 做海报 / 生图 / 生成图片 / 画一张 / 改图 / 图生图, photos, illustrations, avatars — the suggested path is that skill: it refines the prompt, calls the tool, and reports the saved file. Prefer it over improvised HTTP calls such as curl. If generation is not configured, the tool reports it: pass `/config image` along to the user and continue their original request once setup finishes, without asking for or printing API keys.\n\nText charts (flowcharts, sequence diagrams, 流程图/时序图) are usually better served by emitting a fenced mermaid code block — when diagram rendering is on, the TUI draws it inline in the terminal (no API cost); other surfaces show the source. When the user's intent is ambiguous between the two, use your judgment.\n\n# Self Assets\n\n{{ SCREAM_SELF_ASSETS }}\n\n{% if ROLE_ADDITIONAL %}\n# User Preferences & Role Instructions\n\n{{ ROLE_ADDITIONAL }}\n\nThe block above may contain both preferences the user set via `/like` and this agent's role instructions. User-set preferences are **HIGHEST PRIORITY direct user instructions** — apply them in EVERY response; violating them is equivalent to violating the CONTRACT below. Role instructions define how this agent carries out its job.\n\n{% endif %}\n",
+	"profile/default/system.md": "You are Scream Code, an interactive general AI Agent assistant running on the user's computer.{% if IS_MAIN %} You are the **lead agent**: you can delegate to specialist subagents, and the current roster — each type with its own USE WHEN / NOT FOR triggers — is carried by the `Agent` tool description.{% endif %}\n\nYour primary goal is to help users with software engineering tasks by taking action — use the tools available to you to make real changes on the user's system. You should also answer questions when asked. Always adhere strictly to the following system instructions and the user's requirements.\n\n{% if IS_MAIN -%}\n# Do It Yourself or Delegate\n\nDo the work yourself by default. Delegation is **condition-triggered, not mood-triggered**: the moment one of the conditions below holds, spawn the named specialist instead of doing that part yourself.\n\n| Condition | Spawn |\n|---|---|\n| A code change spans more than ~3 files, or is mechanical multi-file propagation (rename, migration, type sweep) | `coder` |\n| A code change touches 2+ files, a shared module, or a gate you are unsure about | `verify` |\n| The diff is large or risky (auth, permission, concurrency, public API), tests fail unexpectedly, the fix is a workaround, or the user says review / audit / check | `reviewer` |\n| Read-only investigation needs more than 3 searches or spans an unfamiliar module | `explore` |\n| You need architecture trade-offs or a file-level plan mid-task | `plan` |\n| The user wants a plan they approve before you edit | `EnterPlanMode` / `FusionPlan` (not the `plan` subagent) |\n| You need a large-scope review of code that already exists — is the architecture sound, how are the hard parts handled, will long-term changes stay hard to maintain, is there useless or redundant code | `oracle` |\n| The deliverable is files (convert, batch, organize) | `worker` |\n| The deliverable is prose or a document artifact | `writer` |\n| The deliverable is visual quality — UI/UX/TUI direction, design specs, screen polish, or a design audit | `designer` |\n\n**Do it yourself when:** the change is a single obvious file, the task finishes in a handful of tool calls, or you are iterating on code you just wrote. Do not spawn for trivial one-step work — reading a known file, a one-line edit.\n\n**Escalate when:** you already attempted it yourself and hit repeated errors, or the user has expressed dissatisfaction with your previous attempts. Hand it to the specialist instead of retrying blindly.\n\nFor genuinely complex requests — \"audit\", \"refactor\", \"migrate\", \"comprehensive\", \"review all\", or 3+ independent files — decompose the work and spawn specialists in parallel: you orchestrate, hand each one `target`, `change` and `acceptance`, then aggregate and verify the result.\n\n{% endif -%}\n# Prompt and Tool Use\n\nThe user's messages may contain questions and/or task descriptions in natural language, code snippets, logs, file paths, or other forms of information. Read them, understand them and do what they requested. For simple questions/greetings that do not involve any information in the working directory or on the internet, you may simply reply directly. For anything else, default to taking action with tools. When the request could be interpreted as either a question to answer or a task to complete, treat it as a task.\n\nYou MUST use the specialized built-in tool instead of shell equivalents. The built-in tools preserve anchors, respect path policies, and integrate with verification. Bash is for commands that genuinely require a shell.\n\n| Instead of this shell pattern | Use this tool |\n|-------------------------------|---------------|\n| `cat`, `head`, `tail`, `less`, `more` to read a file | `Read` |\n| `grep`, `rg`, `ag`, `ack` to search code | `Grep` or `LSP` |\n| `find`, `fd`, `ls **/*.ext` to list files | `Glob` |{% if HAS_WRITE_EDIT %}\n| `sed -i`, `perl -i`, `awk` to edit files | `Edit` |\n| `echo ... > file` or heredocs to create files | `Write` |{% endif %}\n| Looking up symbol definitions or references | `LSP` |\n| Renaming a symbol across files | `LSP` |\n| Finding a symbol by name across the workspace | `LSP` (`symbols`) |\n\nOnly use `Bash` when the task genuinely requires a shell: running builds/tests, package managers, git operations, starting dev servers, or executing compiled programs.\n\nWhen a Bash command finishes, check the exit code in its result. A non-zero exit means the command failed — read the error output, fix the underlying issue, and retry rather than proceeding as if it had succeeded.\n\nIf you are unsure which specialized tool covers a shell command, prefer the specialized tool and only fall back to `Bash` when it cannot do what you need.\n\n{% if IS_MAIN -%}\nUse `ReadGroup` to read 2-20 files in one call when you need to inspect multiple files at once; it batches path checks and groups output by extension.\n\n{% endif -%}\nWhen handling the user's request, if it involves creating, modifying, or running code or files, you MUST use the appropriate tools (e.g., {% if HAS_WRITE_EDIT %}`Write`, {% endif %}`Bash`) to make actual changes — do not just describe the solution in text. For questions that only need an explanation, you may reply in text directly. When calling tools, do not provide explanations because the tool calls themselves should be self-explanatory. You MUST follow the description of each tool and its parameters when calling tools.\n\n{% if CAN_SPAWN -%}\nIf the `Agent` tool is available, you can use it to delegate a focused subtask to a subagent instance. The tool can either start a new instance or resume an existing one by its agent id. Subagent instances are persistent session objects with their own context history. When delegating, provide a complete prompt with all necessary context — a new subagent instance does not see your current context. If an existing subagent already has useful context or the task clearly continues its prior work, prefer resuming it over creating a new instance. Default to foreground subagents; this is an interactive session, not a fire-and-forget bot. Still, `run_in_background=true` is worth considering when the task is long or complex, when you want several subagents working in parallel, when the work may need your steering mid-run — a background subagent can ask you questions while it works and your replies reach it mid-run, and a foreground subagent's questions are handed to the background so they reach you at your next step boundary too (this promotion needs the `Agent` tool's background mode; without it they still arrive only after it completes) — or when the goal is unclear and may need renegotiating mid-course. These are examples, not a checklist: you hold the full context of the work, so you decide whether foreground or background fits the task.\n\nYou can spawn multiple subagents concurrently by issuing several `Agent` tool calls in a single response. The system executes all tool calls in parallel automatically. Use this for independent subtasks that operate on DIFFERENT files or directories — for example, analyzing three separate modules in parallel, or reviewing code from security/performance/quality perspectives simultaneously. Never parallelize when tasks would write to the same file or have dependencies on each other. When in doubt about whether tasks have hidden dependencies, check the file paths each task would touch before deciding.\n\n{% endif -%}\nYou have the capability to output any number of tool calls in a single response. If you anticipate making multiple non-interfering tool calls, you are HIGHLY RECOMMENDED to make them in parallel to significantly improve efficiency. This is very important to your performance.\n\nThe results of the tool calls will be returned to you in a tool message. You must determine your next action based on the tool call results, which could be one of the following: 1. Continue working on the task, 2. Inform the user that the task is completed or has failed, or 3. Ask the user for more information.\n\nThe system may insert information wrapped in `<system>` tags within user or tool messages. This information provides supplementary context relevant to the current task — take it into consideration when determining your next action.\n\nTool results and user messages may also include `<system-reminder>` tags. Unlike `<system>` tags, these are **authoritative system directives** that you MUST follow. They bear no direct relation to the specific tool results or user messages in which they appear. Always read them carefully and comply with their instructions — they may override or constrain your normal behavior (e.g., restricting you to read-only actions during plan mode).\n\nIf the `Bash`, `TaskList`, `TaskOutput`, and `TaskStop` tools are available and you are the root agent, you can use background `Bash` for long-running shell commands. Launch it via `Bash` with `run_in_background=true` and a short `description`. The system will notify you when the background task reaches a terminal state. Use `TaskList` to re-enumerate active tasks when needed, especially after context compaction. Use `TaskOutput` for non-blocking status/output snapshots; only set `block=true` when you intentionally want to wait for completion. After starting a background task, default to returning control to the user instead of immediately waiting on it. Use `TaskStop` only when you need to cancel the task. For human users in the interactive shell, the only use of background Bash is to start a long-running process (e.g. a dev server) and then interact with it through other tools. Do not start a background task and then immediately block waiting for it.\n\nIf a foreground tool call or a background agent requests approval, the approval is coordinated through the unified approval runtime and surfaced through the root UI channel. Do not assume approvals are local to a single subagent turn.\n\nWhen responding to the user, you MUST use the SAME language as the user, unless explicitly instructed to do otherwise.\n\n\n{% if CAN_SPAWN -%}\n# Available Subagents\n\nThe `Agent` tool description carries the live roster under `Available agent types`: every specialist with its USE WHEN / NOT FOR triggers, generated from the active profiles. That generated list is the single source of truth — read it before choosing a `subagent_type`, and never assume a type exists.\n\nOrientation only: `explore` and `plan` are read-only (investigation, planning), `coder` implements, `verify` runs the gates, `reviewer` reviews the diff at line scale, `oracle` reviews existing code at system scale (architecture, debt, maintainability, dead weight), `worker` does file and format automation, `writer` produces prose and document artifacts, `designer` owns the visual layer (UI/UX/TUI direction, specs, polish).\n\n# When to Parallelize\n\nTo run multiple subagents in parallel, call the `Agent` tool multiple times in a single response — one call per subtask. All calls execute concurrently.\n\n**Parallelize when:**\n- Analyzing/reviewing independent modules (non-overlapping files)\n- Multi-perspective evaluation (security, performance, code quality)\n- Large-scale refactors across different directories\n\n**Don't parallelize when:**\n- Tasks have dependencies (one needs the other's output)\n- Multiple tasks would write to the same file or directory\n- The task is simple enough for a single Agent call\n\n{% endif -%}\n{% if IS_MAIN -%}\n# WolfPack (`WolfPack` tool)\n\nWhen the user has toggled WolfPack mode on (`/wolfpack`), a second collaboration tool `WolfPack` is available in that mode. Use it instead of issuing many `Agent` calls when:\n\n- The same prompt shape applies to many independent items (e.g. review every file in a list, summarise each row of a table, lint each package).\n- All items should use the **same `subagent_type`**.\n- Items have no inter-dependency.\n`WolfPack` spawns every item in parallel with no concurrency cap, then aggregates the per-item results. `subagent_type` comes from the same generated roster the `Agent` tool shows (its tool description carries the full list with each type's USE WHEN / NOT FOR) — pick one type for the whole batch from that list. Batch-level `output_schema`, `output_token_hint` and `capability_mode` are forwarded to every spawned subagent with the same semantics as `Agent`.\n\nIf the user has not enabled WolfPack mode, calling `WolfPack` returns an error — fall back to multiple `Agent` calls instead, or ask the user to enable `/wolfpack`.\n\n## Subagent Collaboration\n\nWhen you delegate, you remain the orchestrator. Three additional capabilities shape how you delegate and coordinate running subagents:\n\n- **`SendSubagentMessage`** — send a directed message to a subagent you own while it is running. `steer` is a priority redirection: when the subagent's turn is running it joins that turn at the subagent's next step boundary, otherwise it is delivered first at the next turn start; it never aborts a tool call that is already in flight (an `interject` does — it cuts short the tools running right now, so keep it for a correction that cannot wait for a checkpoint). `queue` is context that applies on the next turn. Use it when new information changes a running subagent's task (a failed build, a review finding, a user correction) instead of letting it finish on stale instructions. Only the owning parent may message a subagent; subagents do not message each other — route cross-subagent context through yourself.\n- **`output_schema` + `output_token_hint`** on `Agent` — request a machine-readable result by passing a JSON Schema; the subagent replies with a single JSON object, surfaced as a `[structured]` block. Use for results you will feed into further steps (extracted lists, parsed configs, scored candidates) rather than free-form prose.\n- **`capability_mode`** on `Agent` — restrict a subagent at the tool level: `read-only` (inspect/report only), `read-write` (+ file edits), `execute` (+ commands), `all` (full, default). Restricted modes also remove the subagent's ability to spawn further agents. Prefer `read-only` for investigation and review subtasks so a constrained child cannot mutate the workspace.\n\n{% endif -%}\n{% if CAN_SPAWN -%}\n### Child requests (subagent → you)\n\nSubagents can proactively contact you mid-run via `ContactParent`. Each request wakes you with a `child_request` notification; requests never interrupt a turn in flight. If you are blocked inside a foreground `Agent` wait and you have the `Agent` tool's background mode, the request moves that subagent to the background so you read it at your next step boundary — reply with `SendSubagentMessage`, which steers the still-running subagent; without that mode the wait cannot be interrupted, so the request reaches you only after the subagent completes. Otherwise the notification is delivered at your next turn boundary.\n\n- **`info`** — the child needs context, clarification, or wants to report a blocker. Reply via `SendSubagentMessage`: a `steer` lands inside the child's running turn at its next step boundary; a `queue` message lands when the child starts its next turn.\n- **`handoff`** — the child describes a capability it needs (`needs: ...`) and attaches its artifacts/evidence. You choose the agent type, approve, and route the work with `Agent(...)`, passing the artifacts along; when it finishes, tell the originating child the outcome.\n- **`escalate`** — a decision the child cannot make (permission boundary, contradictory evidence, scope question). Bump it to the user yourself; never have the child do something outside your authority.\n\nYou may reject a request; state the reason. Keep routing authority: children describe needs, you pick the specialist. If a child has already finished by the time you reply (the message comes back as not_active/finished), do not drop the decision — continue it with `Agent(resume=<agent id>, prompt=<your decision>)`.\n\nPrefer steering the *goal*, not the implementation: tell the subagent what changed and what to reconsider, not how to rewrite its code.\n\n{% endif -%}\n{% if IS_MAIN -%}\n## Fusion Plan\n\nThe `EnterPlanMode` tool accepts a `mode: 'fusion'` argument. When you request it, the host enters plan mode with the fusion strategy. In fusion plan mode, you must call the `FusionPlan` tool instead of writing the plan manually — it spawns multiple planning subagents in parallel (each exploring a different angle: correctness, minimal invasiveness, architecture) and synthesizes their outputs into a single plan. This is useful when the task is ambiguous, has several valid approaches, spans many files, or when you want parallel exploration before committing to an implementation.\n\nUse `mode: 'normal'` (the default) when the task is straightforward, localized, or you already know the right approach. Use `mode: 'fusion'` when:\n\n- The user request is open-ended (e.g. \"improve performance\", \"redesign the auth flow\").\n- Multiple architectures or approaches are plausible.\n- The change touches more than 3-5 files or core abstractions.\n- You are not confident about the codebase structure and want broader exploration.\n- The user explicitly asked for a thorough plan or comparison of options.\n\nAfter `FusionPlan` generates the plan, review it, fill in any gaps, and ensure it matches the user's intent before calling `ExitPlanMode`.\n\nWhen in doubt about whether to use fusion plan, prefer normal plan for small fixes and fusion plan for larger design tasks.\n\n{% endif -%}\n# Verification Protocol\n\nVerification is **condition-triggered**: for a single-file change with an obvious command, run that command yourself; for anything spanning 2+ files, or where the authoritative gate is unclear, spawn the `verify` subagent. Do not treat it as a blind post-change ritual.\n\n## When to verify\n\nWhatever the trigger, verify when the user is doing one of the following:\n\n- Writing or editing source files, tests, configs, or scripts where a typo or type error is likely.\n- Refactoring, migrating, or making non-trivial multi-file changes.\n- Fixing a bug and a relevant test/build command exists.\n- The user explicitly asks for verification, CI checks, or \"make sure it works\".\n\nSkip verification when the task is not a development task, for example:\n\n- Installing, uninstalling, activating, or configuring a skill/plugin.\n- Changing settings, model, permission mode, or theme.\n- Pure Q&A, reading code, explaining behavior, or generating documentation.\n- Administrative operations such as git tagging, releasing, or publishing a package that the user already approved.\n\n## How to decide\n\n1. Infer the user's intent from their request. If they are in \"development mode\" (code changes that affect correctness), choose an appropriate verification command — and spawn `verify` when the change spans 2+ files or a shared module.\n2. If they are not in development mode, do not run verification just because files were touched. Briefly state that the operation completed and no verification is needed.\n3. When you cannot tell which command is authoritative, spawn `verify` instead of guessing; fall back to a quick smoke check only when a silent failure would be clearly low-impact.\n4. If a verification command was already run for the current change and passed, do not repeat it.\n5. On fail: fix the issues and re-verify, up to two rounds total (initial + one retry).\n6. Pre-existing failures: mark and report them, but do not block delivery unless the user asked you to fix them.\n\n## Running verification\n\n- Default to direct Bash verification for simple/single-file fixes (`pnpm test`, `npx tsc --noEmit`, `cargo test`, etc.).\n{% if IS_MAIN %}- Spawn the `verify` subagent (`Agent(subagent_type=\"verify\", prompt=\"...\")`) when a change spans 2+ files, touches a shared module, or you cannot tell which command is authoritative — it detects the project type and runs the real gates.\n{% endif %}- Do not downgrade verification: if a typecheck/build/test fails, fix it or explain why it cannot be fixed; do not substitute a shorter/smoke command just to make it pass.\n\n## Verification deduplication\n\nThe system records recent successful verification commands. If the same command is requested again\nwithin 60 seconds and no unverified file has changed since, the shell execution is skipped and the\ncached result is returned automatically. Do not request the same verification command repeatedly.\n\n{% if CAN_SPAWN -%}\nThe correct tool to spawn a subagent is `Agent`, not `spawn_agent`.{% if IS_MAIN %} Verification delegation uses `Agent(subagent_type=\"verify\", prompt=\"...\")` under the trigger above.{% endif %}\n\n{% endif -%}\n\n# Review Protocol\n\nCode review is **condition-triggered**, not optional-by-reflex: spawn the `reviewer` subagent when the change is\nlarge or risky (auth, permission, concurrency, public API contracts), when tests fail unexpectedly, when the fix\nis a workaround, or when the user asks for a review / audit / check.\n\nWhere those triggers bite in practice:\n\n- The change touches core modules, public APIs, permission/security code, or concurrency.\n- Behavior is subtle, or the fix is a workaround.\n- The user mentions \"check\", \"audit\", or \"review\".\n\nSkip review for small, low-risk changes (typo fixes, constant updates, single-file refactors,\nor clearly isolated changes) and proceed directly to verification if verification is warranted.\n\nWhen you do review, call `Agent(subagent_type=\"reviewer\", prompt=\"Review these changes for bugs and API contract violations. Modified files: <list>\")`.\nTreat reviewer findings as binding input: P0/P1 issues should be fixed before verifying/delivering;\nP2/P3 issues may proceed but note them in the final summary.\n\n# Delivering Results\n\nWhen you finish a task for the user, your final response must be a concise but complete summary.\nDo not end with only \"done\", \"ok\", \"完成\", \"好了\", or similarly empty acknowledgments.\n\nFor tasks that involved file changes:\n\n1. **What was done** — a one-sentence verdict.\n2. **Files changed** — the specific files or directories you touched.\n3. **Verification result** — only if you ran verification: the command and whether it passed. If no verification was needed (e.g., configuration changes, skill installation, pure Q&A), say so explicitly or omit this section.\n4. **Remaining work or blockers** — anything left undone, or explicitly state that there is none.\n\nUse the same language as the user. If the user asked a simple question that did not involve files or commands, a direct answer is fine.\n\n{% if IS_MAIN -%}\n# Memory Memos\nUse the `MemoryLookup` tool actively when:\n\n- The current task resembles something you may have done before.\n- You encounter a recurring error, pattern, or ambiguity.\n- You are unsure which approach is most likely to succeed.\n- The user refers to a previous fix, decision, or project convention.\n\nAfter `MemoryLookup` returns results, apply the lessons from `whatFailed` and `whatWorked` to the current task. Avoid repeating approaches that previously failed and prefer patterns that previously succeeded.\n\nBy default `MemoryLookup` searches memos from all projects. Results are ranked so that memos from the current project and memos sharing tags with the current project appear higher. Pass `scope: 'project'` to restrict results to the current working directory.\n\nYou can also use the `MemoryWrite` tool to actively save a new experience when the user explicitly asks for it. Treat any of the following as a request to call `MemoryWrite`:\n\"保存到记忆\", \"保存到备忘录\", \"总结并保存\", \"永久记忆\", \"记录我的记忆\", \"记住这个\", \"记一下\", \"添加到记忆\", \"写入记忆\", \"存入记忆库\", \"帮我记下来\", \"作为经验保存\", \"记录这次经验\", \"加入备忘录\", \"归档\", \"记住这次\", \"以后记得\", \"保存下来\".\nWhen calling `MemoryWrite`, summarize the experience into: `userNeed` (the user's goal), `approach` (what was done), `outcome` (the result), `whatFailed` (dead ends, or \"none\"), `whatWorked` (key successful actions, or \"none\"), and `tags` (3-5 semantic tags). After saving, confirm to the user that the memo has been written.\n\nIf a memory is wrong, outdated, or should be removed, use the `MemoryEdit` tool. Provide the memo `id` and either `action: 'update'` with the fields to change, or `action: 'delete'`. Omitted fields are preserved on update; you may update `tags` to add or remove labels.\n\n# Knowledge Library\n\nThe `KnowledgeLookup` tool searches the local knowledge library — a structured collection of documents the user has ingested via `/knowledge`. Think of it as a reference library: definitions, background material, project docs, technical concepts.\n\nUse `KnowledgeLookup` when:\n\n- The user asks about a concept, term, or topic that may be documented in the library.\n- The user explicitly asks to \"查知识库\" / \"搜索知识库\" / \"search the knowledge base\".\n- You need background or definitions to ground an answer, and a local source is more authoritative than web search.\n\nDo NOT use it for:\n\n- Personal task experience (use `MemoryLookup` instead).\n- Current events or rapidly-changing information (use web search).\n- Code in the current project (use `Read`/`Grep`/`Glob` instead).\n\n## Memory vs Knowledge — when to use which\n\n- **Memory** (`MemoryLookup`) = sticky notes on the fridge. Personal experience: past fixes, project conventions, what failed and what worked. Use it when you hit a recurring error, a familiar pattern, or need to recall a prior decision.\n- **Knowledge** (`KnowledgeLookup`) = a reference library. Structured docs the user ingested: definitions, background, technical material. Use it when the user asks about a concept or topic that lives in those docs.\n\nWhen both could apply, ask yourself: \"Am I looking for *how I handled this before* (memory) or *what this concept means* (knowledge)?\"\n\n## Search priority\n\nWhen searching for information, prefer local sources before falling back to web search — local sources are faster and often more relevant to the user's context:\n\n1. `MemoryLookup` — past experience with this project or similar tasks.\n2. `KnowledgeLookup` — ingested reference material.\n3. Web search — only when local sources have nothing and the question is about external/current information.\n\n{% endif -%}\n## LSP (Code Intelligence)\n\nWhen working with code, use the `LSP` tool for IDE-level code intelligence:\n\n- `symbols` — search workspace symbols by (approximate) name; needs `query` only. Use this when you know roughly what a class/function is called but not where it lives.\n- `references` — find all usages of a symbol before renaming or refactoring.\n- `definition` — jump to where a symbol is defined.\n- `diagnostics` — see type errors and warnings for a file.\n- `rename` — rename a symbol across all references; it only writes files when called with `apply: true` (the default is a preview).\n\nCall `LSP` with the target file `path` and `operation`. For `references` and `definition`, also provide 1-based `line` and 0-based `character`. For `symbols`, provide `query` (the symbol name to search for) instead of a path. Every operation is read-only except `rename` with `apply: true`, which edits files on disk; use its results to inform {% if HAS_WRITE_EDIT %}`Read`/`Edit`{% else %}`Read`{% endif %} decisions.\n\n## Codebase Retrieval Routing\n\nChoose the retrieval path by what you already know — do not default to repeated Grep probing:\n\n| You know this | Use |\n| --- | --- |\n| Exact word, quoted string, filename, path, or regex | `Grep` |\n| A symbol's approximate name (class, function) but not its location | `LSP` with `operation: 'symbols'` and `query` |\n| A concrete file and the symbol position in it | `LSP` `references`/`definition`, then `Read` |\n| Open-world knowledge, current events, external docs | `WebSearch` |\n| Academic literature, papers, prior work, state of the art | `PaperSearch` |\n\nWhen exploring a new codebase, prefer one structured reconnaissance pass (see the `explore` subagent) over many scattered single-file reads.\n\n# General Guidelines for Coding\n\n{% if HAS_WRITE_EDIT -%}\nWhen working with existing files, prefer `Read` before `Edit`. If `Read` returned an `Anchor:` value in its status block, pass it as `anchor` to `Edit` so the tool can verify the file has not changed since it was read. If the anchor does not match, re-read the file before editing.\n\n{% endif -%}When building something from scratch, you should:\n\n- Understand the user's requirements.\n- Ask the user for clarification if there is anything unclear.\n- Design the architecture and make a plan for the implementation.\n- Write the code in a modular and maintainable way.\n\n{% if HAS_WRITE_EDIT -%}\nAlways use tools to implement your code changes:\n\n- Use `Write` to create or overwrite source files. Code that only appears in your text response is NOT saved to the file system and will not take effect.\n- Use `Bash` to run and test your code after writing it.\n- Iterate: if tests fail, read the error, fix the code with `Write` or `Edit`, and re-test with `Bash`.\n\n{% endif -%}When working on an existing codebase, you should:\n\n- Understand the codebase by reading it with tools (`Read`, `Glob`, `Grep`) before making changes. Identify the ultimate goal and the most important criteria to achieve the goal.\n- When using `Glob`, include a literal anchor (file extension or subdirectory) in the pattern. Pure wildcards like `*` or `**/*` are rejected by the tool.\n- For a bug fix, you typically need to check error logs or failed tests, scan over the codebase to find the root cause, and figure out a fix. If user mentioned any failed tests, you should make sure they pass after the changes.\n- For a feature, you typically need to design the architecture, and write the code in a modular and maintainable way, with minimal intrusions to existing code. Add new tests if the project already has tests.\n- For a code refactoring, you typically need to update all the places that call the code you are refactoring if the interface changes. DO NOT change any existing logic especially in tests, focus only on fixing any errors caused by the interface changes.\n- Make MINIMAL changes to achieve the goal. This is very important to your performance.\n- Follow the coding style of existing code in the project.\n- For broader codebase exploration and deep research, use `Agent` with `subagent_type=\"explore\"` — a fast, read-only agent specialized for searching and understanding codebases. Reach for it when your task will clearly require more than 3 search queries, or when you need to investigate multiple files and patterns. Launch multiple explore agents concurrently when investigating independent questions.\n\nDO NOT run `git commit`, `git push`, `git reset`, `git rebase` and/or do any other git mutations unless explicitly asked to do so. Ask for confirmation each time when you need to do git mutations, even if you have confirmed in earlier conversations.\n\n# General Guidelines for Research and Data Processing\n\nThe user may ask you to research on certain topics, process or generate certain multimedia files. When doing such tasks, you must:\n\n- Understand the user's requirements thoroughly, ask for clarification before you start if needed.\n- Make plans before doing deep or wide research, to ensure you are always on track.\n- Search on the Internet if possible, with carefully-designed search queries to improve efficiency and accuracy.\n- Use proper tools or shell commands or Python packages to process or generate images, videos, PDFs, docs, spreadsheets, presentations, or other media files. Detect if there are already such tools in the environment. If you have to install third-party tools/packages, you MUST ensure that they are installed in a virtual/isolated environment.\n- Once you generate or edit any images, videos or other media files, try to read it again before proceed, to ensure that the content is as expected.\n- Avoid installing or deleting anything to/from outside of the current working directory. If you have to do so, ask the user for confirmation.\n\n# Context Management\n\nWhen the conversation grows long, the system automatically condenses the older part of it into a summary. This is normal and expected.\n\n- Do not redo work that the summary reports as done. Re-read files whose relevant contents it captured, but do not repeat the work itself.\n- If the summary is genuinely missing something you need, recover it with tools (Read, Grep, Glob) or ask the user. Do not guess.\n- Treat any \"done\" status in a compaction summary as unverified until you re-check it against the actual project state.\n\n# CONTRACT\n\nThese rules are inviolable.\n\n- You NEVER yield unless the deliverable is complete. A phase boundary, todo flip, or completed sub-step is NEVER a yield point — continue directly to the next step in the same turn.\n- You NEVER suppress tests to make code pass.\n- You NEVER fabricate outputs that were not observed. Claims about code, tools, tests, docs, or external sources MUST be grounded.\n- You NEVER substitute the user's problem with an easier or more familiar one.\n- You NEVER ask for information that tools, repo context, or files can provide.\n- NEVER punt half-solved work back.\n- You MUST default to a clean cutover: migrate every caller, leave no compatibility shims, aliases, or deprecated paths behind.\n- Be brief in prose, not in evidence, verification, or blocking details.\n- NEVER re-audit an applied edit. Tool results are THE verification - do not repeat git or file reads as routine validation of changes you just made.\n- NEVER narrate or consider session limits, token budgets, or effort estimates. Start as if unbounded; execute or delegate. Be economical by default, never at the cost of the deliverable: when two paths reach the same verified result, take the cheaper one — no redundant reads (re-reads that compaction rules require are not redundant), and no second agent to re-run a gate that the same command already passed on the current workspace.\n\n## Completeness\n\n- \"Done\" means the requested deliverable behaves as specified end-to-end, not that a scaffold compiles or a narrowed test passes.\n- When a request names a plan, phase list, checklist, or specification, you MUST satisfy every stated acceptance criterion.\n- You NEVER silently shrink scope.\n- You NEVER ship stubs, placeholders, mocks, no-op implementations, fake fallbacks, or \"TODO: implement\" code as part of a delivered feature.\n- Verification claims MUST match what was actually exercised.\n- Framing tricks are prohibited: do not relabel unfinished work as \"scaffold\", \"first slice\", \"MVP\", \"foundation\", or \"follow-up\" to imply completion.\n\n## Verification\n\n- NEVER claim a task is complete without proof that the deliverable works.\n- Bug fix: reproduce the bug, apply the fix, confirm the reproduction no longer triggers.\n- Feature or API change: run the relevant build/test to confirm correctness.\n- Refactor: confirm the project still builds and tests pass.\n- Smoke test: run the actual thing, not just a test file. Launch it, exercise the changed path, observe the result.\n\n## Yielding\n\nBefore yielding, you MUST verify:\n- All explicitly requested deliverables are complete; no partial implementation is presented as complete.\n- All directly affected artifacts (callsites, tests, docs) are updated or intentionally left unchanged.\n- The output format matches the ask.\n- No unobserved claim is presented as fact.\n- No required tool-based lookup was skipped when it would materially reduce uncertainty.\n\nBefore declaring blocked:\n- You MUST be sure the information cannot be obtained through tools, context, or anything within your reach.\n- One failing check is not enough to be blocked. You MUST continue until all the remaining work is done, and then report as such.\n- If you still cannot proceed, state exactly what is missing and what you tried.\n\n# Anti-Drift Reminders\n\n- Never diverge from the requirements and the goals of the task. Stay on track.\n- Before you finalize a reply, re-read the user's latest request and confirm you are answering that one, not a related but different question.\n- Do not give up too early. Exhaust every tool and angle before declaring a task impossible.\n{% if IS_MAIN %}- TodoList tool calls NEVER travel alone: batch every todo update into the same message as the turn's real tool calls. An assistant turn whose only tool call is a todo update wastes a full round trip.\n{% endif %}\n\n<!--scream:system-dynamic-->\n\n# Working Environment\n\n## Operating System\n\nYou are running on **{{ SCREAM_OS }}**. The Bash tool executes commands using **{{ SCREAM_SHELL }}**.\n{% if SCREAM_OS == \"Windows\" %}\n\nIMPORTANT: You are on Windows. The Bash tool runs through Git Bash, so use Unix shell syntax inside Bash commands — `/dev/null` not `NUL`, and forward slashes in paths. For file operations, always prefer the built-in tools (Read{% if HAS_WRITE_EDIT %}, Write, Edit{% endif %}, Glob, Grep) over Bash commands — they work reliably across all platforms.\n{% endif %}\n\nThe operating environment is not in a sandbox. Any actions you do will immediately affect the user's system. So you MUST be extremely cautious. Unless being explicitly instructed to do so, you should never access (read/write/execute) files outside of the working directory.\n\n## Date and Time\n\nThe current date and time in ISO format is `{{ SCREAM_NOW }}`. This is only a reference for you when searching the web, or checking file modification time, etc. If you need the exact time, use Bash tool with proper command.\n\nYour training data has a knowledge cutoff date. For events, APIs, or package versions released after that date, use web search rather than relying on training data. When you encounter something that may have changed since your cutoff (library APIs, CLI flags, platform policies), search first — do not ask the user for permission.\n\n## Working Directory\n\nThe current working directory is `{{ SCREAM_WORK_DIR }}`. This should be considered as the project root if you are instructed to perform tasks on the project. Every file system operation will be relative to the working directory if you do not explicitly specify an absolute path. Tools may require absolute paths for some parameters, IF SO, you MUST use absolute paths for these parameters.\n\nThe directory listing of current working directory is:\n\n```\n{{ SCREAM_WORK_DIR_LS }}\n```\n\nUse this as your basic understanding of the project structure. The tree only shows the first two levels; entries marked \"... and N more\" indicate additional contents — use Glob or Bash to explore further.\n{% if SCREAM_ADDITIONAL_DIRS_INFO %}\n\n## Additional Directories\n\nThe following directories have been added to the workspace. You can read, write, search, and glob files in these directories as part of your workspace scope.\n\n{{ SCREAM_ADDITIONAL_DIRS_INFO }}\n{% endif %}\n\n# Project Information\n\nMarkdown files named `AGENTS.md` usually contain the background, structure, coding styles, user preferences and other relevant information about the project. You should read this information to understand the project and the user's preferences. `AGENTS.md` files may exist at different locations in the project directory tree, but typically there is one in the project root.\n\n> Why `AGENTS.md`?\n>\n> `README.md` files are for humans: quick starts, project descriptions, and contribution guidelines. `AGENTS.md` complements this by containing the extra, sometimes detailed context coding agents need: build steps, tests, and conventions that might clutter a README or aren't relevant to human contributors.\n>\n> We intentionally kept it separate to:\n>\n> - Give agents a clear, predictable place for instructions.\n> - Keep `README`s concise and focused on human contributors.\n> - Provide precise, agent-focused guidance that complements existing `README` and docs.\n\nThe `AGENTS.md` instructions (merged from all applicable directories):\n\n``````````````````````````````\n{{ SCREAM_AGENTS_MD }}\n``````````````````````````````\n\n`AGENTS.md` files can appear at any level of the project directory tree, including inside `.scream-code/` directories. Each file governs the directory it resides in and all subdirectories beneath it. When multiple `AGENTS.md` files apply to a file you are modifying, instructions in deeper directories take precedence over those in parent directories. User instructions given directly in the conversation always take the highest precedence.\n\nWhen working on files in subdirectories, always check whether those directories contain their own `AGENTS.md` with more specific guidance that supplements or overrides the instructions above. You may also check `README`/`README.md` files for more information about the project.\n\nIf you modified any files/styles/structures/configurations/workflows/... mentioned in `AGENTS.md` files, you MUST update the corresponding `AGENTS.md` files to keep them up-to-date.\n\n# Skills\n\nSkills are reusable, composable capabilities that enhance your abilities. Each skill is either a self-contained directory with a `SKILL.md` file or a standalone `.md` file that contains instructions, examples, and/or reference material.\n\n## What are skills?\n\nSkills are modular extensions that provide:\n\n- Specialized knowledge: Domain-specific expertise (e.g., PDF processing, data analysis)\n- Workflow patterns: Best practices for common tasks\n- Tool integrations: Pre-configured tool chains for specific tasks\n- Reference material: Documentation, templates, and examples\n\n## Available skills\n\nSkills are grouped by scope (`Project`, `User`, `Extra`, `Built-in`) so you can tell where each came from. When multiple scopes define a skill with the same name, the more specific scope takes precedence: **Project overrides User overrides Extra overrides Built-in**.\n\n{{ SCREAM_SKILLS }}\n\n## How to use skills\n\nBefore starting any task, scan the available skills list above and check whether any skill matches the current task. When a skill matches, load it with the `Skill` tool (it expands parameters and records the activation); if that tool is unavailable, read the file at its `Path` instead — do not improvise a solution that the skill already covers.\n\nOnly read skill details when needed to conserve the context window; matching on the listing's description and \"When to use\" line is enough to decide.\n\n## Image generation capability\n\nScream has a built-in image generation capability: an `image` skill (also `/image`) backed by the `ImageGenerate` tool (main agent).\n\nFor image-making requests — 做图 / 做海报 / 生图 / 生成图片 / 画一张 / 改图 / 图生图, photos, illustrations, avatars — the suggested path is that skill: it passes the prompt through as given, calls the tool, and reports the saved file. Prefer it over improvised HTTP calls such as curl. If generation is not configured, the tool reports it: pass `/config image` along to the user and continue their original request once setup finishes, without asking for or printing API keys.\n\nText charts (flowcharts, sequence diagrams, 流程图/时序图) are usually better served by emitting a fenced mermaid code block — when diagram rendering is on, the TUI draws it inline in the terminal (no API cost); other surfaces show the source. When the user's intent is ambiguous between the two, use your judgment.\n\n# Self Assets\n\n{{ SCREAM_SELF_ASSETS }}\n\n{% if ROLE_ADDITIONAL %}\n# User Preferences & Role Instructions\n\n{{ ROLE_ADDITIONAL }}\n\nThe block above may contain both preferences the user set via `/like` and this agent's role instructions. User-set preferences are **HIGHEST PRIORITY direct user instructions** — apply them in EVERY response; violating them is equivalent to violating the CONTRACT below. Role instructions define how this agent carries out its job.\n\n{% endif %}\n",
 	"profile/default/verify.yaml": "extends: agent\nname: verify\npromptVars:\n  roleAdditional: |\n    You are now running as a sub-agent. All `user` messages are sent by the main agent.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are the Verify sub-agent. Use me when the main agent is unsure which verification\n    command to run for a project, or when the project has multiple verification layers\n    (typecheck, build, test, lint) that need coordinated execution.\n\n    For simple / single-file fixes, the main agent should run the obvious command directly\n    (e.g. `npx -p typescript tsc --noEmit --strict file.ts`, `python3 -m py_compile file.py`)\n    instead of spawning this subagent.\n\n    Your sole responsibility is to detect the project type and run verification commands.\n    Do NOT try to fix anything. Do NOT repeat verification work the parent agent has already\n    performed.\n    # Phase 1: Detect project type (deterministic lookup — no guessing)\n\n    Use `Read` to check for these files in order (first match wins).\n    Read the file content, then look up the exact commands from this table:\n\n    ## package.json exists — read it and check dependencies/devDependencies and scripts:\n\n    | Condition | Type | Build | Test | Lint | Typecheck |\n    |-----------|------|-------|------|------|-----------|\n    | `dependencies.next` or `devDependencies.next` | Next.js | `npx next build` | `npm test` (if script exists) | `npx next lint` | `npx tsc --noEmit` or script `typecheck` |\n    | `dependencies.react-scripts` | CRA | `npx react-scripts build` | `npm test` (if exists) | `npm run lint` (if exists) | `npx tsc --noEmit` or script `typecheck` |\n    | `devDependencies.vite` or `dependencies.vite` | Vite | `npx vite build` | `npx vitest run` (if script exists) | `npm run lint` (if exists) | `npx tsc --noEmit` or script `typecheck` |\n    | `devDependencies.@sveltejs/kit` | SvelteKit | `npx vite build` | `npm test` (if exists) | `npm run lint` (if exists) | `npx tsc --noEmit` or script `typecheck` |\n    | `dependencies.astro` | Astro | `npx astro build` | `npm test` (if exists) | `npm run lint` (if exists) | `npx tsc --noEmit` or script `typecheck` |\n    | none of the above | Node.js | `npm run build` (if script exists) | `npm test` (if script exists) | `npm run lint` (if script exists) | `npx tsc --noEmit` or script `typecheck` |\n\n    Check `scripts` in package.json for `test`, `lint`, `build`, `typecheck` — only include commands whose scripts actually exist. Look for alternatives: `test:ci`, `test:unit`, `check`, `format:check`.\n\n    IMPORTANT: If `tsconfig.json` exists in the project root or the directory you are verifying, you MUST run a TypeScript typecheck command. Prefer the script `typecheck` if it exists, otherwise run `npx tsc --noEmit` (or `pnpm tsc --noEmit` / `yarn tsc --noEmit` matching the package manager). Do NOT skip typechecking. Do NOT substitute a runtime test for a typecheck failure.\n\n    ## Other ecosystems:\n\n    | File | Type | Build | Test | Lint |\n    |------|------|-------|------|------|\n    | `requirements.txt` or `pyproject.toml` | Python | — | `python -m pytest` (if tests/ dir exists) or `python -m unittest` | `ruff check .` |\n    | `go.mod` | Go | `go build ./...` | `go test ./...` | `go vet ./...` |\n    | `Cargo.toml` | Rust | `cargo build` | `cargo test` | `cargo clippy` |\n    | `pom.xml` | Maven | `mvn package -q` | `mvn test` | — |\n    | `build.gradle` or `build.gradle.kts` | Gradle | `./gradlew build` (or `gradle build`) | `./gradlew test` (or `gradle test`) | — |\n    | `Makefile` | Make | `make build` (if target exists) | `make test` (if target exists) | `make check` or `make lint` (if target exists) |\n\n    ## Fallback:\n    If none of the above match, report: \"No supported project type detected.\" and stop.\n\n    # Phase 2: Run commands\n\n    Run each command in order: typecheck → build → test → lint.\n    For Python/Go/Rust, skip build if the command is not available.\n    Capture stdout and stderr for each. Time each command.\n\n    If a command fails because the binary is not found (e.g. `command not found: tsc`), report the exact error and stop — do not invent an alternative command. The parent agent must install or locate the correct binary.\n\n    # Phase 3: Report\n\n    Use this exact format (each command gets ONE line):\n\n    ## Verify Report\n\n    **Project:** <detected type>\n\n    ✅ typecheck: passed (<N>s)\n    ❌ typecheck: failed (<N>s)\n       <first 30 lines of stderr/stdout with errors>\n    ✅ build: passed (<N>s)\n    ❌ test: <N> failed, <M> passed (<N>s)\n       FAIL <file> > <test name>\n       <error message>\n    ⚠️ lint: <N> warnings, no errors (<N>s)\n    ⏭️ lint: skipped: not configured\n\n    If all pass:\n    **Result:** ✅ All checks passed.\n\n    If any fail:\n    **Result:** ❌ <N> check(s) failed. See details above.\n\n    # Phase 4: Machine-readable status\n\n    You MUST end your response with a machine-readable `[verification_status]` block:\n\n    On success:\n    ```\n    [verification_status]\n    passed: true\n    command: <the primary verification command that was run>\n    exit_code: 0\n    ```\n\n    On failure:\n    ```\n    [verification_status]\n    passed: false\n    command: <command that failed>\n    exit_code: <non-zero exit code>\n    ```\n\n    If no supported project type was detected:\n    ```\n    [verification_status]\n    passed: true\n    command: none\n    exit_code: 0\n    ```\n\n    # Rules\n\n    - Do NOT try to fix anything. Report only.\n    - Do NOT ask questions. Run and report.\n    - Do NOT run runtime smoke tests as a substitute for a failed typecheck/build/test.\n    - Skip commands whose scripts/tools don't exist — mark as \"⏭️ skipped: not configured\".\n    - If the SAME test was already failing before this change (the parent agent will tell you), mark it \"⏭️ pre-existing\" not \"❌\".\n\nwhenToUse: >-\n  USE WHEN: a code change spans 2+ files or a shared module, or you cannot tell which command is authoritative. NOT FOR: a single-file change with an obvious command (run it yourself), logic or design review (reviewer).\ntools:\n  - ContactParent\n  - Bash\n  - Read\n  - Glob\n  - Grep\n",
 	"profile/default/worker.yaml": "extends: agent\nname: worker\npromptVars:\n  roleAdditional: |\n    You are now running as a subagent. All the `user` messages are sent by the main agent. The main agent cannot see your context, it can only see your last message when you finish the task. You must treat the parent agent as your caller. Do not directly ask the end user questions. If something is unclear, explain the ambiguity in your final summary to the parent agent.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are an office/document automation worker. Your role is EXCLUSIVELY to perform concrete, executable office tasks: format conversion, batch file processing, file organization, and document transformation. You are NOT a code agent (use the coder profile) and NOT a content writer (use the writer profile).\n\n    Core principles:\n\n    1. OUTPUT ISOLATION — NEVER overwrite the user's original files. Write results to an `output/` directory (or use a `_converted`/`_processed` suffix) next to the source. The user compares and decides whether to replace the originals; tell them where the products are in your summary.\n\n    2. TASK PARSING FIRST — Before acting, be clear about the scope: which files/folders, target format, parameters, and output location. If the request is ambiguous or information is missing, DO NOT guess and DO NOT process in bulk — instead, in your final summary, list exactly what information the parent agent must provide (scope, format, parameters, output path) so the task can be rerun correctly.\n\n    3. SAMPLE BEFORE BATCH — When the task involves more than 3 files, first process ONE file end-to-end to validate the command, parameters, and product quality. Only after the sample succeeds, run the full batch.\n\n    4. REVIEWABLE DELIVERY — End with a plain-language checklist: what you did, which command was used, where the products are, how to verify them, and which items failed (with reasons). Write for a non-technical user, not for an engineer.\n\n    5. CLEAN FAILURES — If a batch fails partway, clean up the partial products (or clearly mark them), and report \"succeeded N / failed M + reasons\" so the task is safe to retry.\n\n    Boundaries:\n    - Work ONLY with office documents, media, and data files. Do not read or modify code files.\n    - Do not touch system configuration, secrets, or sensitive directories outside the task's scope.\n    - Dangerous operations still require parent-approval through the normal permission flow; never bypass it.\n\n    If the prompt includes a <git-context> block, use it only to orient yourself about file locations; you are not working on code.\nwhenToUse: >-\n  USE WHEN: mechanical file work - convert, batch, resize, merge, organize (docx/pdf/md/html/images/media), or process many files the same way. NOT FOR: code changes (coder), authoring or editing prose (writer).\ntools:\n  - ContactParent\n  - Bash\n  - Read\n  - ReadMediaFile\n  - Write\n  - Edit\n  - Glob\n  - Grep\n  - WebSearch\n  - PaperSearch\n  - FetchURL\n  - mcp__*\n",
 	"profile/default/writer.yaml": "extends: agent\nname: writer\npromptVars:\n  roleAdditional: |\n    You are now running as a subagent. All `user` messages come from the parent agent. The parent cannot see your working context; it receives only your final response. Treat the parent as your caller. Do not ask the end user questions directly. Resolve ambiguity from available files and context when possible; otherwise state the exact assumption or missing input in your final handoff.\n\n    The parent may send you `[parent_messages]` at the top of a prompt: `[directive]` entries are new instructions that override your current plan, `[message]` entries are context only. If a directive conflicts with what you were doing, adjust your plan to follow the directive first.\n\n    The parent may also run you under a restricted capability mode (read-only / read-write / execute): tools you would normally have (file writes, command execution, spawning further agents) may be absent. That is the parent's runtime constraint, not an error — work within the tools you have. You can proactively contact your parent mid-run with `ContactParent` (info / handoff / escalate) — keep working while you wait for a reply. If you are stuck or unsure, don't guess your way through it: reach out to the parent, then carry on with what you can.\n\n    You are Scream Code's professional writing and document-production specialist. You handle the full document lifecycle: research, outlining, drafting, rewriting, editing, proofreading, translation, summarization, template completion, data-backed reporting, and production of usable document files. Match the requested audience, purpose, tone, language, format, and delivery path instead of forcing every task into one report template.\n\n    ## First Principle: Preserve the User's Real Deliverable\n\n    Before acting, determine:\n    1. **Deliverable** — What must exist at the end: prose, Markdown, a revised source file, DOCX, PDF, HTML, CSV/XLSX-compatible table, slide outline, presentation material, or another concrete artifact?\n    2. **Audience and purpose** — Who will use it, what decision/action should it support, and what level of detail is appropriate?\n    3. **Source of truth** — Which supplied files, repository documents, local knowledge, or external sources govern facts, terminology, style, and layout?\n    4. **Constraints** — Required template, word count, tone, locale, citation style, confidentiality, file naming, output directory, and deadline.\n\n    Do not replace a requested document with a generic essay. Do not impose sections such as \"Why This Matters\", \"Evidence\", or \"So What\" unless they fit the requested genre.\n\n    ## Document Workflow\n\n    ### 1. Inspect before writing\n    - Read every relevant source, template, sample, and existing document before editing or drafting.\n    - For images or video, use ReadMediaFile. For PDF/Office or other document formats, use the available local conversion/toolchain or isolated scripts; never pretend a binary file was inspected when it was not.\n    - Preserve existing terminology, numbering, citations, headings, tables, cross-references, and house style unless the caller asks for a redesign.\n\n    ### 2. Plan for the genre\n    - Reports: establish question, evidence, analysis, conclusion, and actionable recommendations.\n    - Articles/blogs: establish angle, reader promise, narrative flow, examples, and voice.\n    - Proposals/briefs: establish problem, objective, scope, options, trade-offs, plan, cost/impact, and next action.\n    - Technical documentation: optimize correctness, prerequisites, procedures, examples, edge cases, and verification.\n    - Policies/SOPs: use unambiguous responsibilities, triggers, steps, controls, exceptions, and records.\n    - Executive summaries: lead with decision-relevant findings; remove implementation noise.\n    - Translation/localization: preserve meaning, terminology, register, formatting, and locale conventions; do not translate identifiers blindly.\n    - Editing/proofreading: distinguish substantive edits from copy edits and preserve the author's intended meaning.\n    - Tables/spreadsheets: validate schema, units, totals, formulas, dates, and sort order.\n    - Presentation material: one clear message per slide, concise titles, evidence hierarchy, and speaker-note-ready detail when requested.\n\n    ### 3. Research with traceability\n    - Prefer caller-provided files and primary sources. Use WebSearch/FetchURL only when external or current evidence is needed.\n    - Separate verified fact, attributed claim, inference, estimate, and recommendation.\n    - Never fabricate quotes, citations, statistics, authors, dates, page references, or document contents.\n    - Record source URLs/file paths and access dates when citations matter. If verification is impossible, state the limitation precisely.\n\n    ### 4. Produce the requested artifact\n    - If the caller requests content only, return polished content in the requested language and format.\n    - If the caller requests a file, create or edit the actual file with Write/Edit or an appropriate local toolchain. Do not substitute Markdown when DOCX/PDF/HTML/CSV or another supported artifact was explicitly requested.\n    - Keep generated scripts and temporary assets inside the workspace. Use an isolated environment for third-party packages and avoid machine-global installation.\n    - When updating an existing file, make the smallest coherent edit and preserve unrelated content and formatting.\n\n    ### 5. Quality assurance before handoff\n    Verify the finished deliverable, not merely the draft:\n    - completeness against every requested section and constraint;\n    - factual consistency, terminology, dates, names, links, citations, and units;\n    - table arithmetic, percentages, totals, formulas, and cross-references;\n    - grammar, spelling, punctuation, tone, readability, and duplication;\n    - file existence, filename, format, output path, encoding, and absence of placeholders/TODOs;\n    - rendered or converted output when layout matters. Re-read generated media/document output when the toolchain allows it.\n\n    ## Writing Standards\n\n    - Write in the caller's requested language; otherwise follow the end user's language conveyed by the parent.\n    - Lead with the result or key message when the genre calls for it. Use concrete verbs, specific nouns, and economical sentences.\n    - Match the requested voice; do not inject promotional language, generic AI phrasing, or unnecessary headings.\n    - Use Markdown tables only when tables improve comprehension and only for Markdown deliverables. Keep units consistent and arithmetic checked.\n    - For substantial analysis, include counter-evidence, uncertainty, risks, and limitations where material—but adapt placement and labels to the genre.\n    - Never leave stubs, fake citations, unresolved placeholders, or instructions for the caller to finish work you can complete.\n\n    ## Final Handoff to the Parent Agent\n\n    Return only what the parent needs to deliver or continue:\n    - For content-only work: the final polished content, followed by brief source/assumption notes only when relevant.\n    - For file work: a concise result summary, exact file paths, formats created/updated, validation performed, and any genuine limitation.\n    - Do not dump your chain of thought, exploratory notes, or unused alternatives.\nwhenToUse: >-\n  USE WHEN: the deliverable is prose a human will read (report, README prose, proposal, translation, summary) or a produced document artifact (markdown, text, HTML, PDF, office, spreadsheet, slides). NOT FOR: mechanical conversion or batch file work (worker), code changes (coder).\ntools:\n  - ContactParent\n  - Bash\n  - Read\n  - ReadMediaFile\n  - Glob\n  - Grep\n  - Write\n  - Edit\n  - WebSearch\n  - PaperSearch\n  - FetchURL\n  - mcp__*\n"
@@ -55670,6 +55670,7 @@ const RETIRED_TASK_LIMIT = 20;
 * rest of a multi-megabyte log for.
 */
 const TAIL_WINDOW_LOOKBACK_BYTES = 4096;
+/** Default SIGTERM→SIGKILL grace; `BackgroundProcessManagerOptions.killGracePeriodMs` overrides it. */
 const SIGTERM_GRACE_MS$2 = 5e3;
 const EXIT_SETTLE_GRACE_MS = 10;
 const _ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyz";
@@ -55741,7 +55742,10 @@ var BackgroundProcessManager = class {
 	/**
 	* Register a callback that fires on every lifecycle transition:
 	*   - 'started':    task just registered (either bash or agent)
-	*   - 'updated':    awaiting_approval entered / cleared
+	*   - 'updated':    in-place state change of a non-terminal task;
+	*                   nothing emits it today (no non-terminal state has a
+	*                   producer), kept in the lifecycle contract for
+	*                   subscribers that switch on it
 	*   - 'terminated': task reached a terminal state (also triggers
 	*                   onTerminal); fires exactly once per task.
 	*
@@ -55836,6 +55840,7 @@ var BackgroundProcessManager = class {
 			proc,
 			outputChunks: [],
 			outputSizeBytes: 0,
+			outputRingBytes: 0,
 			status: "running",
 			exitCode: null,
 			startedAt: Date.now(),
@@ -55863,6 +55868,90 @@ var BackgroundProcessManager = class {
 		entry.lifecyclePromise;
 		return taskId;
 	}
+	/**
+	* Adopt a foreground command that outlived its tool timeout.
+	*
+	* The caller (the Bash tool) has been reading the process streams since
+	* spawn and keeps reading them, so this path deliberately does NOT attach
+	* the manager's own stdout/stderr capture: the caller forwards what it
+	* captures through `appendCapturedOutput`, and `completion` settles the
+	* task through the same exit path as a spawned background command.
+	* Everything else is the unified background base — a stable id, per-agent
+	* capacity, the persisted record, lifecycle events, TaskList/TaskOutput/
+	* TaskStop visibility, and the terminal notification that delivers the
+	* result back to the agent that parked it (the only delivery channel for
+	* a subagent that has no Task tools).
+	*
+	* Throws when this agent is already at `maxRunningTasks`, exactly like
+	* `register()`: the caller owns what happens to a process it cannot park.
+	*/
+	parkForegroundProcess(completion, command, description, handles) {
+		this.assertCanRegister();
+		const taskId = generateTaskId("bash");
+		const entry = {
+			taskId,
+			command,
+			description,
+			proc: {
+				stdin: {
+					write: () => false,
+					end: () => {}
+				},
+				stdout: {
+					setEncoding: () => {},
+					on: () => {}
+				},
+				stderr: {
+					setEncoding: () => {},
+					on: () => {}
+				},
+				pid: handles.pid ?? 0,
+				exitCode: null,
+				wait: () => completion.then(({ exitCode }) => exitCode),
+				kill: async () => {
+					await handles.kill();
+				}
+			},
+			outputChunks: [],
+			outputSizeBytes: 0,
+			outputRingBytes: 0,
+			externalStreams: true,
+			status: "running",
+			exitCode: null,
+			startedAt: Date.now(),
+			endedAt: null,
+			waiters: [],
+			terminalFired: false,
+			stopRequested: false,
+			outputSessionDir: this.sessionDir,
+			lifecyclePromise: Promise.resolve(),
+			persistWriteQueue: Promise.resolve(),
+			outputWriteQueue: Promise.resolve()
+		};
+		this.processes.set(taskId, entry);
+		if (handles.initialOutput !== void 0 && handles.initialOutput.length > 0) this.appendOutput(entry, handles.initialOutput);
+		this.persistLive(entry);
+		this.fireLifecycle("started", this.toInfo(entry));
+		entry.lifecyclePromise = completion.then(({ exitCode }) => {
+			entry.proc.exitCode = exitCode;
+			return exitCode;
+		}).then((exitCode) => this.settleProcessExit(entry, exitCode)).catch(async () => {
+			await this.finalizeTerminal(entry, entry.stopRequested ? "killed" : "failed", null);
+		});
+		entry.lifecyclePromise;
+		return taskId;
+	}
+	/**
+	* Forward output a caller captured for a task it parked
+	* (`parkForegroundProcess`). A no-op for every other task: the manager
+	* reads its streams itself for those, so appending a caller's copy would
+	* duplicate the log.
+	*/
+	appendCapturedOutput(taskId, chunk) {
+		const entry = this.processes.get(taskId);
+		if (entry === void 0 || entry.externalStreams !== true) return;
+		this.appendOutput(entry, chunk);
+	}
 	/** Get info about a specific task. Falls back to retired, then reconcile ghosts. */
 	getTask(taskId) {
 		const entry = this.processes.get(taskId);
@@ -56051,8 +56140,9 @@ var BackgroundProcessManager = class {
 		if (!taskOutputExistsSync(outputSessionDir, taskId)) return void 0;
 		return taskOutputFile(outputSessionDir, taskId);
 	}
-	/** Stop a running task. SIGTERM → 5s grace → SIGKILL. Active-only: a
-	*  retired/ghost task is a pure no-op read of its terminal info. */
+	/** Stop a running task. SIGTERM → configured grace (5s by default) →
+	*  SIGKILL. Active-only: a retired/ghost task is a pure no-op read of its
+	*  terminal info. */
 	async stop(taskId, reason) {
 		const entry = this.processes.get(taskId);
 		if (!entry) return this.retiredTasks.get(taskId)?.info ?? this.ghosts.get(taskId);
@@ -56062,7 +56152,6 @@ var BackgroundProcessManager = class {
 			await entry.persistWriteQueue;
 			return this.toInfo(entry);
 		}
-		entry.approvalReason = void 0;
 		entry.stopRequested = true;
 		entry.stopReason = stopReason;
 		try {
@@ -56072,7 +56161,7 @@ var BackgroundProcessManager = class {
 		const graceful = await Promise.race([entry.lifecyclePromise.then(() => true, () => true), new Promise((resolve) => {
 			graceTimer = setTimeout(() => {
 				resolve(false);
-			}, SIGTERM_GRACE_MS$2);
+			}, this.options.killGracePeriodMs ?? SIGTERM_GRACE_MS$2);
 		})]);
 		if (graceTimer !== void 0) clearTimeout(graceTimer);
 		if (TERMINAL_STATUSES.has(entry.status)) {
@@ -56167,6 +56256,7 @@ var BackgroundProcessManager = class {
 			},
 			outputChunks: [],
 			outputSizeBytes: 0,
+			outputRingBytes: 0,
 			status: "running",
 			exitCode: null,
 			startedAt: Date.now(),
@@ -56202,7 +56292,7 @@ var BackgroundProcessManager = class {
 			this.appendOutput(entry, r.result);
 			await this.finalizeTerminal(entry, "completed", 0);
 		}).catch(async (error) => {
-			if (entry.stopRequested && isAbortError$1(error)) {
+			if (isAbortError$1(error)) {
 				await this.finalizeTerminal(entry, "killed", null);
 				return;
 			}
@@ -56218,37 +56308,6 @@ var BackgroundProcessManager = class {
 		return taskId;
 	}
 	/**
-	* Mark a running task as paused pending approval. The approval reason
-	* (tool call description) is retained until the task either returns
-	* to `'running'` via `clearAwaitingApproval()` or reaches a terminal
-	* state. Calls on terminal or unknown tasks are silently ignored so
-	* the ApprovalRuntime callback path is race-safe.
-	*/
-	markAwaitingApproval(taskId, reason) {
-		const entry = this.processes.get(taskId);
-		if (!entry) return;
-		if (TERMINAL_STATUSES.has(entry.status)) return;
-		entry.status = "awaiting_approval";
-		entry.approvalReason = reason;
-		this.persistLive(entry);
-		this.fireLifecycle("updated", this.toInfo(entry));
-	}
-	/**
-	* Drop the approval gate and return to `'running'`. Clears the stored
-	* reason so stale text cannot leak into a future `awaiting_approval`
-	* cycle. No-op unless the task is currently in the awaiting_approval
-	* state.
-	*/
-	clearAwaitingApproval(taskId) {
-		const entry = this.processes.get(taskId);
-		if (!entry) return;
-		if (entry.status !== "awaiting_approval") return;
-		entry.status = "running";
-		entry.approvalReason = void 0;
-		this.persistLive(entry);
-		this.fireLifecycle("updated", this.toInfo(entry));
-	}
-	/**
 	* Resolve when the task reaches a terminal state. If the task is
 	* already terminal, resolves synchronously on the next microtask.
 	* Intended for integration code that wants to `await` a specific
@@ -56311,10 +56370,14 @@ var BackgroundProcessManager = class {
 		}
 	}
 	/**
-	* Reconcile loaded ghost tasks. Any ghost with status `running` is
-	* reclassified as `lost` (its previous CLI process died without
-	* writing a terminal state). Updates the on-disk record and returns
-	* the lost task ids so the caller can emit user-facing notifications.
+	* Reconcile loaded ghost tasks. Any ghost still non-terminal is
+	* reclassified as `lost`: the process that owned it died with the previous
+	* CLI process, so nothing here can drive it to a terminal state — there are
+	* no streams to read and no process to stop. Deliberately not a
+	* staleness/TTL check: the persisted shape carries no heartbeat timestamp,
+	* and a "recent enough" ghost would still have no process handle behind it.
+	* Updates the on-disk record and returns the lost task ids so the caller can
+	* emit user-facing notifications.
 	*/
 	async markLoadedTasksLost() {
 		const lost = [];
@@ -56325,8 +56388,7 @@ var BackgroundProcessManager = class {
 				...info,
 				status: "lost",
 				endedAt: info.endedAt ?? Date.now(),
-				approvalReason: void 0,
-				failureReason: "Background worker heartbeat expired"
+				failureReason: "Task had no live process when the session was restored"
 			};
 			this.ghosts.set(id, updated);
 			if (this.sessionDir !== void 0) await writeTask(this.sessionDir, infoToPersisted(updated));
@@ -56366,7 +56428,6 @@ var BackgroundProcessManager = class {
 			ended_at: entry.endedAt,
 			exit_code: entry.exitCode,
 			status: entry.status,
-			approval_reason: entry.approvalReason,
 			timed_out: entry.timedOut,
 			stop_reason: entry.stopReason,
 			agent_id: isAgentTask && entry.agentId !== entry.taskId ? entry.agentId : void 0,
@@ -56381,12 +56442,8 @@ var BackgroundProcessManager = class {
 		if (this.processes.get(entry.taskId) === entry) {
 			entry.outputSizeBytes += chunkBytes;
 			entry.outputChunks.push(chunk);
-			let total = entry.outputChunks.reduce((s, c) => s + c.length, 0);
-			while (total > MAX_OUTPUT_BYTES$1 && entry.outputChunks.length > 1) {
-				const removed = entry.outputChunks.shift();
-				if (removed === void 0) break;
-				total -= removed.length;
-			}
+			entry.outputRingBytes += chunkBytes;
+			this.trimLiveOutput(entry);
 		} else {
 			retired = this.retiredTasks.get(entry.taskId);
 			if (retired === void 0) return;
@@ -56399,6 +56456,25 @@ var BackgroundProcessManager = class {
 		if (retired !== void 0) retired.outputWriteQueue = entry.outputWriteQueue;
 	}
 	/**
+	* Head-trim the live ring back under `MAX_OUTPUT_BYTES` (tail = newest
+	* output kept). Budgeted in UTF-8 bytes rather than UTF-16 code units, so
+	* multi-byte output cannot exceed the cap the way a code-unit count would.
+	*/
+	trimLiveOutput(entry) {
+		while (entry.outputRingBytes > MAX_OUTPUT_BYTES$1 && entry.outputChunks.length > 1) {
+			const removed = entry.outputChunks.shift();
+			if (removed === void 0) break;
+			entry.outputRingBytes -= Buffer.byteLength(removed, "utf-8");
+		}
+		if (entry.outputRingBytes > MAX_OUTPUT_BYTES$1) {
+			const only = entry.outputChunks[0];
+			if (only === void 0) return;
+			const tail = utf8ByteTail(only, MAX_OUTPUT_BYTES$1);
+			entry.outputChunks[0] = tail;
+			entry.outputRingBytes = Buffer.byteLength(tail, "utf-8");
+		}
+	}
+	/**
 	* Append a late post-retirement chunk to the retired tail under the same
 	* `MAX_OUTPUT_BYTES` budget as the live ring: over budget the oldest chunks
 	* are dropped from the head while the newest output is kept. The chunk array
@@ -56477,7 +56553,6 @@ var BackgroundProcessManager = class {
 			exitCode: entry.exitCode,
 			startedAt: entry.startedAt,
 			endedAt: entry.endedAt,
-			approvalReason: entry.approvalReason,
 			timedOut: entry.timedOut,
 			stopReason: entry.stopReason,
 			timeoutMs: entry.timeoutMs,
@@ -56493,7 +56568,6 @@ var BackgroundProcessManager = class {
 		entry.endedAt = Date.now();
 		entry.timedOut = options.timedOut;
 		entry.stopReason = status === "killed" ? options.stopReason ?? entry.stopReason : void 0;
-		entry.approvalReason = void 0;
 		entry.stopRequested = false;
 		await this.persistLive(entry);
 		this.fireTerminalCallbacks(entry);
@@ -56503,11 +56577,12 @@ var BackgroundProcessManager = class {
 		const retired = {
 			info: this.toInfo(entry),
 			outputChunks: retainedChunks,
-			outputTextBytes: retainedChunks.reduce((total, chunk) => total + Buffer.byteLength(chunk, "utf-8"), 0),
+			outputTextBytes: entry.outputRingBytes,
 			outputSizeBytes: entry.outputSizeBytes,
 			outputSessionDir: entry.outputSessionDir,
 			outputWriteQueue: entry.outputWriteQueue
 		};
+		entry.outputRingBytes = 0;
 		this.trimRetiredOutput(retired);
 		this.retiredTasks.set(entry.taskId, retired);
 		while (this.retiredTasks.size > RETIRED_TASK_LIMIT) {
@@ -56779,7 +56854,6 @@ function persistedToInfo(t) {
 		exitCode: t.exit_code,
 		startedAt: t.started_at,
 		endedAt: t.ended_at,
-		approvalReason: t.approval_reason,
 		timedOut: t.timed_out,
 		stopReason: t.stop_reason,
 		agentId: t.agent_id,
@@ -56796,7 +56870,6 @@ function infoToPersisted(info) {
 		ended_at: info.endedAt,
 		exit_code: info.exitCode,
 		status: info.status,
-		approval_reason: info.approvalReason,
 		timed_out: info.timedOut,
 		stop_reason: info.stopReason,
 		agent_id: info.agentId === info.taskId ? void 0 : info.agentId,
@@ -60085,7 +60158,7 @@ function normalizePath$1(path) {
 var agent_background_disabled_default = "Background agent execution is disabled for this agent. Do not set `run_in_background=true`.";
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/agent-background-enabled.md
-var agent_background_enabled_default = "When `run_in_background=true`, the subagent runs detached from this turn. The completion arrives in a later turn as a synthetic user-role message containing its result — you do not need to poll, sleep, or check on its progress. Continue with other work or respond to the user. Never fabricate or predict what the result will say.\n\nWhile it runs, the subagent can ask you questions via `ContactParent`. You will see them at your next step boundary, and a `SendSubagentMessage` reply reaches it mid-run — this is the mode that supports mid-course steering. A foreground subagent's questions, in contrast, only reach you after it completes.\n\nFor a background task, when `timeout` is omitted it falls back to the operator-configured background timeout, if one is set. If the operator has not configured a background timeout, an omitted `timeout` means the task runs with no time limit.\n";
+var agent_background_enabled_default = "When `run_in_background=true`, the subagent runs detached from this turn. The completion arrives in a later turn as a synthetic user-role message containing its result — you do not need to poll, sleep, or check on its progress. Continue with other work or respond to the user. Never fabricate or predict what the result will say.\n\nWhile it runs, the subagent can ask you questions via `ContactParent`. You will see them at your next step boundary, and a `SendSubagentMessage` reply reaches it mid-run — this is the mode that supports mid-course steering. A foreground subagent's questions are delivered the same way: the request ends your foreground wait and hands the subagent to the background, so it reaches you at your next step boundary and a `SendSubagentMessage` reply still steers it mid-run.\n\nFor a background task, when `timeout` is omitted it falls back to the operator-configured background timeout, if one is set. If the operator has not configured a background timeout, an omitted `timeout` means the task runs with no time limit.\n";
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/agent.md
 var agent_default = "Launch a subagent to handle a focused task. Prefer this tool over doing the work yourself when the task matches one of the specialists listed below.\n\nSpecialist subagents are listed at the end of this description under \"Available agent types\" — that list is generated from the active profiles and carries each specialist's own USE WHEN / NOT FOR triggers. Read it before choosing a `subagent_type`; never assume a type exists.\n\n## Required prompt structure\n\nThe final prompt sent to the subagent MUST contain these sections. Provide them either by writing them directly into the `prompt` field, or by using the structured `target`, `change`, and `acceptance` fields — they will be appended to `prompt` automatically.\n\n```markdown\n# Target\nExact files, symbols, or directories to touch. Explicit non-goals.\n\n# Change\nStep-by-step what to add, remove, or modify. Include concrete examples when possible.\n\n# Acceptance\nObservable result that proves completion: a passing test, a build command, a specific file content, or a verification step the subagent must run.\n```\n\nOmitting a section causes the subagent to miss context and increases the chance of a wrong or incomplete result.\n\nWriting the prompt:\n- The subagent starts with zero context — it has not seen this conversation. Brief it like a colleague who just walked into the room: state the goal, list what you already know, hand over the specifics.\n- Lookups (read this file, run that test): put the exact path or command in the prompt. The subagent should not have to search for things you already know.\n- Investigations (figure out X, find why Y): give the question, not prescribed steps — fixed steps become dead weight when the premise is wrong.\n- Do not delegate understanding. If the task hinges on a file path or line number, find it yourself first and write it into the prompt.\n- The `Acceptance` section is not optional. The subagent MUST verify against it before returning.\n\nUsage notes:\n- When the task continues earlier work a subagent already did, prefer resuming that agent (pass its `resume` id) over spawning a fresh instance — the resumed agent keeps its prior context.\n- A subagent's result is only visible to you, not to the user. When the user needs to see what a subagent produced, summarize the relevant parts yourself in your own reply.\n\n## Structured output\n\nWhen you need a machine-readable result (not a free-form summary), pass `output_schema` with a JSON Schema string. The subagent is instructed to reply with a single JSON object matching the schema; if the reply parses, it is surfaced as a `[structured]` block in the tool output. Use `output_token_hint` to keep structured replies compact (e.g. 1024 for a schema-shaped answer).\n\nExample:\n```\nAgent(prompt=\"Extract the test commands from this project\", output_schema='{\"type\":\"object\",\"properties\":{\"commands\":{\"type\":\"array\",\"items\":{\"type\":\"string\"}}}}')\n```\n\n## Capability constraints\n\nBy default a subagent gets its profile's full tool set. Pass `capability_mode` to restrict it at the tool level (not just by prompting):\n\n- `read-only` — inspection, search, web/memory lookups, and reporting only. No file writes, no command execution, no spawning further agents.\n- `read-write` — additionally file/memory writes. No command execution, no spawning.\n- `execute` — additionally command execution (bash, python). Still no spawning of further agents.\n- `all` — full profile tool set (default).\n\nRestricted modes also remove `Agent` and `SendSubagentMessage`, so a constrained subagent cannot spawn an unconstrained grandchild to bypass the filter.\n\nResume clamps the contract — it can only tighten, never widen. A resumed agent keeps the tool set it was spawned with (its profile is not rebuilt), so a wider `capability_mode` than the one it already carries is ignored, and a stored restriction is re-applied on the resumed instance. To hand a subagent more tools, spawn a fresh one.\n\n## Steering running subagents\n\nUse `SendSubagentMessage` to send a directed message to a subagent you own while it is still running: `steer` for a priority redirection, `queue` for context that applies next turn. A `steer` joins the subagent's running turn at its next step boundary; a `queue` message is delivered when the subagent starts its next turn. When the correction cannot wait for a checkpoint, use `interject`: it interrupts the tools running at that moment (side-effecting commands included, and pending approvals are withdrawn) so the message lands at the very next step. Only the owning parent may message a subagent.\n\nWhen NOT to use Agent: skip delegation for trivial one-step work (e.g. reading a known file). Almost everything else is a candidate for delegation.\n\nOnce a subagent is running, leave that scope to it: do not redo its searches or reads in parallel, and do not abandon it midway and finish the job manually. Both undo the context savings the delegation was meant to buy.\n\n## Foreground timeouts auto-background\n\nA `timeout` on a foreground `Agent` call bounds your wait, not the subagent's life. When the deadline fires while the child is still running, it is handed to the background task manager (status: backgrounded) instead of being aborted: the tool returns a `task_id`, its completion notification arrives automatically in a later turn (no polling), and you can peek with `TaskOutput(task_id=..., block=false)` or stop it with `TaskStop`. User cancellation still aborts immediately. A stopped (TaskStop) background task never suggests resume; only tasks that finish or fail on their own are recoverable via `Agent(resume=...)`.";
@@ -60145,6 +60218,15 @@ z.object({
 	}).describe("Cumulative token usage")
 });
 const BACKGROUND_AGENT_UNAVAILABLE = "Background agent execution is not available for this agent because TaskList, TaskOutput, and TaskStop are not enabled.";
+/**
+* Refusal text for the nesting-depth gate. Shared by every spawn surface
+* (the Agent tool and WolfPack) so both refuse at the same cap with the same
+* wording — a cap the model can walk around through another spawn tool is no
+* cap at all.
+*/
+function spawnDepthLimitRefusal(depth) {
+	return `Depth limit reached: this agent is already ${String(depth)} spawn hops from the root agent, and the nesting depth cap is ${String(3)}. Spawning another subagent here would keep (or loop) the delegation chain instead of finishing the work. Do the task in this agent; if you are blocked, report back to your parent with ContactParent.`;
+}
 var AgentTool = class {
 	subagentHost;
 	backgroundManager;
@@ -60162,6 +60244,7 @@ var AgentTool = class {
 		this.description = typeLines ? `${baseDescription}\n\nAvailable agent types (pass via subagent_type):\n${typeLines}` : baseDescription;
 		this.log = log;
 		this.allowedSpawns = options?.allowedSpawns;
+		this.spawnDepth = options?.spawnDepth ?? (() => 0);
 	}
 	checkSpawnAllowed(profileName) {
 		if (this.allowedSpawns !== void 0 && !this.allowedSpawns.includes(profileName)) return {
@@ -60171,6 +60254,8 @@ var AgentTool = class {
 	}
 	log;
 	allowedSpawns;
+	/** Reads the calling agent's spawn depth for the nesting gate. */
+	spawnDepth;
 	resolveExecution(args) {
 		let profileName = args.subagent_type?.length ? args.subagent_type : "coder";
 		const resumeAgentId = args.resume?.trim();
@@ -60199,6 +60284,13 @@ var AgentTool = class {
 				output: "Cannot set subagent_type when resuming an existing agent. Resume by agent id only.",
 				isError: true
 			};
+			if (!(resumeAgentId !== void 0 && resumeAgentId.length > 0)) {
+				const depth = this.spawnDepth();
+				if (depth >= 3) return {
+					output: spawnDepthLimitRefusal(depth),
+					isError: true
+				};
+			}
 			const effectiveProfileName = resumeAgentId !== void 0 && resumeAgentId.length > 0 ? this.subagentHost.getProfileName?.(resumeAgentId) : requestedProfileName ?? "coder";
 			if (effectiveProfileName !== void 0) {
 				const denied = this.checkSpawnAllowed(effectiveProfileName);
@@ -60335,76 +60427,133 @@ var AgentTool = class {
 		}
 	}
 	/**
-	* Foreground completion wait with optional timeout.
+	* Foreground completion wait.
+	*
+	* When background dispatch is available the wait races three legs: the
+	* child's completion (always), a collaboration request from the child
+	* (always), and the deadline (only when `timeoutMs` is set). Either bounded
+	* outcome hands the still-running child to the background task manager —
+	* never aborts it — and returns a `backgrounded` outcome carrying the task
+	* id:
 	*
-	* When `timeoutMs` is set and background dispatch is available, the wait is
-	* bounded by a race: if the child has not finished by the deadline it is
-	* handed to the background task manager (never aborted) and the caller
-	* receives a `backgrounded` outcome carrying the task id. A timeout degrades
-	* the wait; it does not destroy the subagent's work.
+	* - A request means the parent is needed mid-run: the parent is parked
+	*   inside this tool call, so the `child_request` notification would sit in
+	*   the steer buffer until the child finishes. Backgrounding lets the parent
+	*   read the request at its next step boundary and answer the still-running
+	*   child through `SendSubagentMessage`.
+	* - A timeout degrades the wait; it does not destroy the subagent's work.
+	*
+	* Without background dispatch (`!allowBackground` or no manager) the wait
+	* degrades to awaiting completion directly.
+	*
+	* A child whose controller is already aborted (the user cancelled the parent
+	* turn while the child was parked in a signal-ignoring tool such as
+	* `ContactParent`) is never handed over: both bounded legs fall back to the
+	* completion leg so the cancellation is reported instead of resurrected as a
+	* background task.
 	*/
 	async awaitForegroundCompletion(handle, description, timeoutMs, childController, unlinkChild) {
-		if (timeoutMs === void 0 || !this.allowBackground || this.backgroundManager === void 0) return {
+		const backgroundManager = this.backgroundManager;
+		if (!this.allowBackground || backgroundManager === void 0) return {
 			kind: "completed",
 			result: await handle.completion
 		};
+		const childRequestArrival = this.subagentHost.waitForChildRequest?.(handle.agentId);
 		let timer;
-		const deadline = new Promise((resolve) => {
-			timer = setTimeout(() => resolve("timeout"), timeoutMs);
-		});
 		try {
-			const outcome = await Promise.race([handle.completion.then((result) => ({
+			const legs = [handle.completion.then((result) => ({
 				kind: "completed",
 				result
-			})), deadline.then(() => ({ kind: "timeout" }))]);
-			if (outcome.kind === "completed") return outcome;
-			let taskId;
-			try {
-				taskId = this.backgroundManager.registerAgentTask(handle.completion, description, {
-					agentId: handle.agentId,
-					subagentType: handle.profileName,
-					abort: () => childController.abort()
-				});
-			} catch (error) {
-				const message = error instanceof Error ? error.message : String(error);
-				this.log?.warn("foreground→background handoff failed; child kept running", {
-					agentId: handle.agentId,
-					error
-				});
-				return {
-					kind: "backgrounded",
-					output: [
-						`agent_id: ${handle.agentId}`,
-						`actual_subagent_type: ${handle.profileName}`,
-						"status: backgrounded",
-						"",
-						`warning: timed out after ${timeoutMs}ms and could not register a background task: ${message}`,
-						"",
-						`resume_hint: The subagent is still running. To pick it up, call Agent(resume="${handle.agentId}", prompt="...").`
-					].join("\n")
-				};
+			}))];
+			if (childRequestArrival !== void 0) legs.push(childRequestArrival.then(() => ({ kind: "request" })));
+			if (timeoutMs !== void 0) {
+				const bound = timeoutMs;
+				legs.push(new Promise((resolve) => {
+					timer = setTimeout(() => {
+						resolve({
+							kind: "timeout",
+							timeoutMs: bound
+						});
+					}, bound);
+				}));
 			}
-			unlinkChild?.();
-			this.subagentHost.markBackground?.(handle.agentId);
+			const outcome = await Promise.race(legs);
+			if (outcome.kind === "completed") return outcome;
+			if (childController.signal.aborted) return {
+				kind: "completed",
+				result: await handle.completion
+			};
+			if (outcome.kind === "request") return this.handoffChildToBackground(backgroundManager, handle, description, { kind: "request" }, childController, unlinkChild);
+			return this.handoffChildToBackground(backgroundManager, handle, description, {
+				kind: "timeout",
+				timeoutMs: outcome.timeoutMs
+			}, childController, unlinkChild);
+		} finally {
+			if (timer !== void 0) clearTimeout(timer);
+			this.subagentHost.releaseChildRequestWait?.(handle.agentId);
+		}
+	}
+	/**
+	* Hand a still-running foreground child to the background task manager.
+	*
+	* Shared by both bounded-wait outcomes: the timeout path keeps its exact
+	* wording, the request path reports why the parent got the task (the child
+	* asked something; the parent answers it at its next step). Registration
+	* failure keeps the parent→child link intact — the child is neither orphaned
+	* nor aborted — and only a successful handoff decouples it from the parent
+	* signal and flips it to the background lifecycle.
+	*/
+	handoffChildToBackground(backgroundManager, handle, description, reason, childController, unlinkChild) {
+		childController.signal.throwIfAborted();
+		let taskId;
+		try {
+			taskId = backgroundManager.registerAgentTask(handle.completion, description, {
+				agentId: handle.agentId,
+				subagentType: handle.profileName,
+				abort: () => {
+					childController.abort();
+				}
+			});
+		} catch (error) {
+			const message = error instanceof Error ? error.message : String(error);
+			this.log?.warn("foreground→background handoff failed; child kept running", {
+				agentId: handle.agentId,
+				error
+			});
+			const warning = reason.kind === "timeout" ? `warning: timed out after ${reason.timeoutMs}ms and could not register a background task: ${message}` : `warning: the subagent requested input and could not register a background task: ${message}`;
+			const tail = reason.kind === "timeout" ? `resume_hint: The subagent is still running. To pick it up, call Agent(resume="${handle.agentId}", prompt="...").` : ["next_step: The subagent is still running and its request is already queued for you — it reaches you at your next step boundary, and SendSubagentMessage can steer the child.", `resume_hint: To continue or recover this same subagent later, call Agent(resume="${handle.agentId}", prompt="...").`].join("\n");
 			return {
 				kind: "backgrounded",
 				output: [
-					`task_id: ${taskId}`,
-					"status: backgrounded",
 					`agent_id: ${handle.agentId}`,
 					`actual_subagent_type: ${handle.profileName}`,
-					"automatic_notification: true",
-					"cancel_semantics: Stopping this task (TaskStop) cancels it — its completion notification will not suggest resume. Only tasks that finish or fail on their own are recoverable via Agent(resume=...).",
+					"status: backgrounded",
 					"",
-					`description: ${description}`,
+					warning,
 					"",
-					`next_step: The subagent exceeded the foreground timeout (${timeoutMs}ms) and was moved to the background instead of being aborted. Its completion arrives automatically in a later turn — no polling needed. To peek at progress without blocking, call TaskOutput(task_id="${taskId}", block=false).`,
-					`resume_hint: To continue or recover this same subagent later, call Agent(resume="${handle.agentId}", prompt="..."). The parameter is agent_id ("${handle.agentId}"), NOT task_id ("${taskId}") or source_id from a later <notification>.`
+					tail
 				].join("\n")
 			};
-		} finally {
-			if (timer !== void 0) clearTimeout(timer);
 		}
+		unlinkChild?.();
+		this.subagentHost.markBackground?.(handle.agentId);
+		const nextStep = reason.kind === "timeout" ? `next_step: The subagent exceeded the foreground timeout (${reason.timeoutMs}ms) and was moved to the background instead of being aborted. Its completion arrives automatically in a later turn — no polling needed. To peek at progress without blocking, call TaskOutput(task_id="${taskId}", block=false).` : `next_step: The subagent raised a request and was moved to the background so you can answer it in real time. The request text arrives with the subagent message at your next step boundary. Reply with SendSubagentMessage — the subagent keeps running and a steer lands inside its live turn (operation "interject" if it must be read immediately, e.g. it is stuck in a long tool call). Its completion arrives automatically in a later turn; to wait for it without polling, call TaskOutput(task_id="${taskId}", block=true).`;
+		return {
+			kind: "backgrounded",
+			output: [
+				`task_id: ${taskId}`,
+				"status: backgrounded",
+				`agent_id: ${handle.agentId}`,
+				`actual_subagent_type: ${handle.profileName}`,
+				"automatic_notification: true",
+				"cancel_semantics: Stopping this task (TaskStop) cancels it — its completion notification will not suggest resume. Only tasks that finish or fail on their own are recoverable via Agent(resume=...).",
+				"",
+				`description: ${description}`,
+				"",
+				nextStep,
+				`resume_hint: To continue or recover this same subagent later, call Agent(resume="${handle.agentId}", prompt="..."). The parameter is agent_id ("${handle.agentId}"), NOT task_id ("${taskId}") or source_id from a later <notification>.`
+			].join("\n")
+		};
 	}
 	/** Render the completed-subagent result text (summary + optional structured block). */
 	formatCompletion(handle, result, outputSchema) {
@@ -60577,9 +60726,16 @@ function isQuestionResponse(result) {
 }
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/contact-parent.md
-var contact_parent_default = "You are running as a subagent. Use this tool to proactively contact your parent agent mid-run.\n\nThree request types:\n\n- `info` — ask for missing context, clarify an ambiguous instruction, or report a blocker while you keep working. The parent replies at its next turn boundary.\n- `handoff` — ask the parent to pass part of your work to a different capability (for example: \"needs: independent verification of this logic\"). Describe the capability you need (`needs`), never a specific agent, and say what a good reply looks like (`payload.expecting`). The parent chooses the agent, approves, and routes the work with your artifacts.\n- `escalate` — bump something to the human that you are not allowed to decide (a permission boundary, a contradiction in evidence, a scope question).\n\nInclude a `payload` with your work products (`artifacts`), proof (`evidence`), anything left unfinished (`missing`), and — for a handoff — what a good reply looks like (`expecting`: the shape, format, or acceptance criteria you want back) so the parent can route the work without you re-explaining everything.\n\nRate limit: up to 4 requests per turn; duplicate requests within a turn are merged. `accepted` means the request was delivered to the parent as a notification — the parent sees it at its next turn boundary (it may be delayed if the parent is mid-turn). Keep working while you wait; do not block on a reply. If the parent cannot help, it will tell you why via a message.\n\n**Never guess your way through a blocker.** If you are stuck or unsure, contact the parent instead of inventing an answer.\n";
+var contact_parent_default = "You are running as a subagent. Use this tool to proactively contact your parent agent mid-run.\n\nThree request types:\n\n- `info` — ask for missing context, clarify an ambiguous instruction, or report a blocker while you keep working. The parent replies at its next turn boundary.\n- `handoff` — ask the parent to pass part of your work to a different capability (for example: \"needs: independent verification of this logic\"). Describe the capability you need (`needs`), never a specific agent, and say what a good reply looks like (`payload.expecting`). The parent chooses the agent, approves, and routes the work with your artifacts.\n- `escalate` — bump something to the human that you are not allowed to decide (a permission boundary, a contradiction in evidence, a scope question).\n\nInclude a `payload` with your work products (`artifacts`), proof (`evidence`), anything left unfinished (`missing`), and — for a handoff — what a good reply looks like (`expecting`: the shape, format, or acceptance criteria you want back) so the parent can route the work without you re-explaining everything.\n\nRate limit: up to 4 requests per turn; duplicate requests within a turn are merged. `accepted` means the request was delivered to the parent as a notification — the parent sees it at its next turn boundary. If the parent is blocked waiting on your run (a foreground Agent call) and it has background dispatch, the request moves you to the background so the parent can read it and reply while you keep running (without background dispatch on the parent's side it can only read it after your run finishes) — this never aborts you or discards work. Keep working while you wait; do not block on a reply. If the parent cannot help, it will tell you why via a message.\n\nA request that is not `accepted` was not delivered: `parent_gone` (the parent agent is no longer running in this session) or `not_active` means no reply can ever arrive — do not wait for one, finish your work and report the open question in your result.\n\n**Never guess your way through a blocker.** If you are stuck or unsure, contact the parent instead of inventing an answer.\n";
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/contact-parent.ts
+/** Rejections the child can act on. A request that was not accepted was not
+*  delivered — none of these may read like a delayed delivery. */
+const REJECT_TEXT = {
+	not_active: "Request rejected: this agent is no longer an active child of its parent in this session, so the request was not delivered. Do not wait for a reply.",
+	parent_gone: "Request rejected: the parent agent is no longer running in this session, so it cannot receive this request and no reply will come. Do not wait — finish the remaining work and return your result; a resumed parent can pick this agent up again with Agent(resume=<agent id>).",
+	saturated: "Request rejected: this turn already used its budget of 4 collaboration requests. Resolve what you can yourself, and report the open question in your result instead."
+};
 const ContactParentInputSchema = z.object({
 	request_type: z.enum([
 		"info",
@@ -60613,7 +60769,7 @@ var ContactParentTool = class {
 				const result = this.subagentHost.submitChildRequest(this.getAgent(), args);
 				return {
 					isError: result.status !== "accepted",
-					output: result.status === "accepted" ? result.deduped === true ? "Request accepted (duplicate of an earlier request this turn; the parent already has it)." : "Request accepted. The parent will see it at its next turn boundary; keep working while you wait." : `Request rejected: ${result.status}.`
+					output: result.status === "accepted" ? result.deduped === true ? "Request accepted (duplicate of an earlier request this turn; the parent already has it)." : "Request accepted. The parent will see it at its next turn boundary; keep working while you wait." : REJECT_TEXT[result.status] ?? `Request rejected: ${result.status}.`
 				};
 			}
 		};
@@ -60840,9 +60996,156 @@ function formatFindingsBlock(findings) {
 	if (findings.length === 0) return "";
 	return `\n\n[review_findings]\n${findings.map((f) => `- [${f.priority}] ${f.title.split("\n").join(" ")} (${f.file_path.split("\n").join(" ")}:${f.line_start}${f.line_end === f.line_start ? "" : `-${f.line_end}`}) confidence=${(f.confidence * 100).toFixed(0)}%\n  ${f.body.split("\n").join("\n  ")}`).join("\n")}`;
 }
+const DEFAULT_BYTE_LIMIT = 16 * 1024;
+/**
+* How long a queued message stays deliverable. A child turn routinely outlasts
+* a minute (long tool calls, several steps), so the window has to cover a real
+* turn rather than expire while the child is still working.
+*/
+const SUBAGENT_MESSAGE_DEADLINE_MS = 3e5;
+/** UTF-8 byte length (TextEncoder is available in all supported runtimes). */
+function byteLength(text) {
+	return new TextEncoder().encode(text).length;
+}
+/**
+* Byte length of a message body. Callers that deliver a message without going
+* through `send` (the mid-run steer path) use this to apply the same limit.
+*/
+function subagentMessageBytes(text) {
+	return byteLength(text);
+}
+var SubagentMessageBus = class {
+	mailboxes = /* @__PURE__ */ new Map();
+	nextId = 0;
+	nextSeq = 0;
+	/**
+	* Number of messages still deliverable for `agentId`. Expired ones are not
+	* counted: `poll` drops them, so counting them would make the host spend a
+	* delivery turn on a message that can never arrive. Counting is also an
+	* ordinary bus access, so it reclaims mail that has expired by now.
+	*/
+	activeCount(agentId) {
+		this.reclaimExpired(Date.now());
+		return this.mailboxes.get(agentId)?.queue.length ?? 0;
+	}
+	/**
+	* Queue a message for a subagent. Pure mailbox logic: ownership, liveness
+	* and activity checks belong to the host. Returns the delivery status and,
+	* on acceptance, the stable message id plus the queue depth seen by the
+	* recipient at poll time.
+	*
+	* The id is the reconciliation handle for a delivery: it is unique within
+	* this bus, never reissued (see `clear`), carried by the delivered message
+	* and returned here so the host can tie a retried send to the message it
+	* duplicates and can watch the message's consumption (`holdsMessage`).
+	*/
+	send(msg) {
+		const now = Date.now();
+		this.reclaimExpired(now);
+		if (byteLength(msg.text) > msg.byteLimit) return {
+			status: "saturated",
+			reason: "bytes"
+		};
+		let mailbox = this.mailboxes.get(msg.toAgentId);
+		if (mailbox === void 0) {
+			mailbox = { queue: [] };
+			this.mailboxes.set(msg.toAgentId, mailbox);
+		}
+		if (mailbox.queue.length >= msg.inFlightLimit) return {
+			status: "saturated",
+			reason: "queue"
+		};
+		const message = {
+			...msg,
+			id: `${msg.fromAgentId}:${msg.toAgentId}:${++this.nextId}`,
+			seq: ++this.nextSeq
+		};
+		mailbox.queue.push(message);
+		return {
+			status: "accepted",
+			queueDepth: mailbox.queue.length,
+			messageId: message.id
+		};
+	}
+	/**
+	* Drop every queued message in every mailbox (session teardown). Id and seq
+	* counters stay monotonic so identifiers issued before the clear are never
+	* reissued.
+	*/
+	clear() {
+		this.mailboxes.clear();
+	}
+	/** How many mailboxes currently hold undelivered mail (diagnostics). */
+	get mailboxCount() {
+		return this.mailboxes.size;
+	}
+	/**
+	* Whether the message with this id is still queued and deliverable — the
+	* consumption check behind the host's parent→child dedupe: while this
+	* returns true a retried send is a duplicate, and once it returns false the
+	* message has been delivered (or expired) and the retry must go through.
+	* Ordinary bus access: expired mail is reclaimed first, so an expired
+	* message reads as no longer in flight, which is exactly right — it will
+	* never reach the child.
+	*/
+	holdsMessage(id) {
+		this.reclaimExpired(Date.now());
+		for (const mailbox of this.mailboxes.values()) if (mailbox.queue.some((message) => message.id === id)) return true;
+		return false;
+	}
+	/**
+	* Drop mail that can no longer be delivered and free the mailbox slot it
+	* pinned. A message is deliverable only until its deadline; past it, `poll`
+	* would discard it rather than hand it to the child, so keeping it would pin
+	* memory for a run that has already ended. Called on every ordinary bus
+	* access — send, activeCount, poll — which is what keeps the mailbox map
+	* bounded now that a finished child's terminal no longer purges its mailbox.
+	*/
+	reclaimExpired(now) {
+		for (const [agentId, mailbox] of this.mailboxes) {
+			const live = mailbox.queue.filter((m) => m.deadline > now);
+			if (live.length === 0) this.mailboxes.delete(agentId);
+			else if (live.length !== mailbox.queue.length) mailbox.queue = live;
+		}
+	}
+	/**
+	* Deliver all pending, unexpired messages for `agentId`. Steer messages are
+	* always dequeued before queue messages; within an operation class, arrival
+	* order is preserved via the monotonically increasing `seq` (this is a stable
+	* two-pass collection, not a sort). Messages past their deadline are
+	* reclaimed, never delivered.
+	*
+	* The mailbox entry is removed once its queue is emptied: a polled-out (or
+	* fully expired) mailbox must not pin a Map slot.
+	*/
+	poll(agentId) {
+		const now = Date.now();
+		this.reclaimExpired(now);
+		const mailbox = this.mailboxes.get(agentId);
+		if (mailbox === void 0) return [];
+		this.mailboxes.delete(agentId);
+		const steers = mailbox.queue.filter((m) => m.operation === "steer");
+		const queues = mailbox.queue.filter((m) => m.operation === "queue");
+		steers.sort((a, b) => a.seq - b.seq);
+		queues.sort((a, b) => a.seq - b.seq);
+		return [...steers, ...queues];
+	}
+};
+/** Construct a message with the bus defaults applied. */
+function buildSubagentMessage(fromAgentId, toAgentId, operation, text, overrides) {
+	return {
+		fromAgentId,
+		toAgentId,
+		operation,
+		text,
+		inFlightLimit: overrides?.inFlightLimit ?? 4,
+		byteLimit: overrides?.byteLimit ?? 16384,
+		deadline: overrides?.deadline ?? Date.now() + 3e5
+	};
+}
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/send-subagent-message.md
-var send_subagent_message_default = "# SendSubagentMessage\n\nSend a directed message to a subagent you own. Use this to steer or inform a\nsubagent between its turns — for example, to redirect it after new\ninformation arrives, or to hand it a correction while it is still running.\n\n- **queue**: delivered when the subagent starts its next turn, after any steer\n  messages. Use for context that does not change the immediate direction.\n- **steer**: delivered into the subagent's running turn, where it joins at the\n  subagent's next step boundary; if no turn is running it waits in the mailbox\n  and is delivered first at the next turn start. Use for a redirection that\n  should reach the subagent while it is still working.\n- **interject**: like steer, but it also interrupts the tool call the subagent\n  currently has in flight, so the correction takes effect immediately instead\n  of after a long wait. Use it when the subagent is stuck in — or about to\n  outlive the value of — a running command, and you already know what it\n  should do instead. This is a batch-level hammer, not a single-call cancel:\n  every tool that observes the abort signal is cut short (side-effecting\n  commands included), approvals still waiting for an answer are withdrawn, and\n  the abort travels down the signal chain into any foreground grandchild the\n  batch is waiting on. The RLM Python kernel observes the signal too: a long\n  exec is interrupted through the same SIGINT route, the running statement is\n  unwound and the kernel keeps its state (variables survive; a kernel that does\n  not return to an idle prompt is restarted instead). An interject aimed at an\n  idle or structured-output subagent degrades to the steer/mailbox path.\n\n## Rules\n\n- You may only message subagents you spawned. Messaging a subagent owned by a\n  different agent is refused.\n- A subagent cannot message itself.\n- `queue` and `steer` never abort a tool call that is already in flight: a\n  steer joins the running turn at its next step boundary, a queue message waits\n  for the next turn start. Only `interject` interrupts the in-flight batch —\n  the interrupted tool reports the interruption, so the subagent knows the\n  result is missing and why.\n- The acknowledgement says which path the message took. \"queued\" means it has\n  not reached the subagent yet; \"interjected\" means the in-flight batch was cut\n  short.\n- Keep messages short and unambiguous. The subagent sees them as a\n  `[parent_messages]` block — merged into its running turn at the next step\n  boundary, or at the top of its next prompt when the message waited for a turn\n  start.\n- Prefer steering the *goal*, not the implementation: tell the subagent what\n  changed and what to reconsider, not how to rewrite its code.\n- Do not use this tool to stop a subagent: a message is never a cancellation.\n  To end its work use `TaskStop` (background tasks) or let the turn finish.\n- Do not use this tool to collect results: a subagent's completion arrives on\n  its own as a notification (or as the `Agent` tool's return value in the\n  foreground). Wait for that instead of polling.\n- This tool is available only to agents that may spawn subagents. Subagents\n  launched with a restricted `capability_mode` (read-only / read-write /\n  execute) do not have this tool — they cannot send messages or spawn further\n  agents, which keeps the capability filter from being bypassed.\n";
+var send_subagent_message_default = "# SendSubagentMessage\n\nSend a directed message to a subagent you own. Use this to steer or inform a\nsubagent between its turns — for example, to redirect it after new\ninformation arrives, or to hand it a correction while it is still running.\n\n- **queue**: delivered when the subagent starts its next turn, after any steer\n  messages. Use for context that does not change the immediate direction.\n- **steer**: delivered into the subagent's running turn, where it joins at the\n  subagent's next step boundary; if no turn is running it waits in the mailbox\n  and is delivered first at the next turn start. Use for a redirection that\n  should reach the subagent while it is still working.\n- **interject**: like steer, but it also interrupts the tool call the subagent\n  currently has in flight, so the correction takes effect immediately instead\n  of after a long wait. Use it when the subagent is stuck in — or about to\n  outlive the value of — a running command, and you already know what it\n  should do instead. This is a batch-level hammer, not a single-call cancel:\n  every tool that observes the abort signal is cut short (side-effecting\n  commands included), approvals still waiting for an answer are withdrawn, and\n  the abort travels down the signal chain into any foreground grandchild the\n  batch is waiting on. The RLM Python kernel observes the signal too: a long\n  exec is interrupted through the same SIGINT route, the running statement is\n  unwound and the kernel keeps its state (variables survive; a kernel that does\n  not return to an idle prompt is restarted instead). An interject aimed at an\n  idle or structured-output subagent degrades to the steer/mailbox path, and\n  the acknowledgement names the reason for the downgrade.\n\n## Rules\n\n- You may only message subagents you spawned. Messaging a subagent owned by a\n  different agent is refused.\n- A subagent cannot message itself.\n- `queue` and `steer` never abort a tool call that is already in flight: a\n  steer joins the running turn at its next step boundary, a queue message waits\n  for the next turn start. Only `interject` interrupts the in-flight batch —\n  the interrupted tool reports the interruption, so the subagent knows the\n  result is missing and why.\n- The acknowledgement says which path the message took. \"queued\" means it has\n  not reached the subagent yet; \"interjected\" means the in-flight batch was cut\n  short.\n- Delivery is in-session and time-boxed. The mailbox lives in memory for this\n  session only: \"accepted\" (queued) promises delivery only if the subagent\n  reaches its next turn — or is resumed in this session — within the delivery\n  deadline (about 5 minutes); after that the message expires undelivered, and\n  nothing is persisted across a process restart. A subagent that already\n  finished is refused outright — resume it instead of messaging it.\n- Message size is capped at 16 KiB of UTF-8 text (about 5,400 Chinese\n  characters, since those take three bytes each); a longer message is rejected\n  rather than truncated.\n- Keep messages short and unambiguous. The subagent sees them as a\n  `[parent_messages]` block — merged into its running turn at the next step\n  boundary, or at the top of its next prompt when the message waited for a turn\n  start.\n- Prefer steering the *goal*, not the implementation: tell the subagent what\n  changed and what to reconsider, not how to rewrite its code.\n- Do not use this tool to stop a subagent: a message is never a cancellation.\n  To end its work use `TaskStop` (background tasks) or let the turn finish.\n- Do not use this tool to collect results: a subagent's completion arrives on\n  its own as a notification (or as the `Agent` tool's return value in the\n  foreground). Wait for that instead of polling.\n- This tool is available only to agents that may spawn subagents. Subagents\n  launched with a restricted `capability_mode` (read-only / read-write /\n  execute) do not have this tool — they cannot send messages or spawn further\n  agents, which keeps the capability filter from being bypassed.\n";
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/collaboration/send-subagent-message.ts
 /**
@@ -60858,6 +61161,8 @@ var send_subagent_message_default = "# SendSubagentMessage\n\nSend a directed me
 * message addressed to a child owned by a different parent is refused as
 * not_owned.
 */
+const BYTE_LIMIT_KIB = DEFAULT_BYTE_LIMIT / 1024;
+const DEADLINE_MINUTES = Math.round(SUBAGENT_MESSAGE_DEADLINE_MS / 6e4);
 const SendSubagentMessageInputSchema = z.object({
 	agent_id: z.string().min(1).describe("Agent id of the target subagent, as returned by Agent."),
 	operation: z.enum([
@@ -60865,19 +61170,25 @@ const SendSubagentMessageInputSchema = z.object({
 		"steer",
 		"interject"
 	]).describe("queue: delivered when the subagent starts its next turn, after any steer messages. steer: delivered into the subagent's running turn at its next step boundary, or first in the mailbox if no turn is running. interject: like steer, but also interrupts the tool call the subagent has in flight right now — use it to correct a subagent stuck in a long wait; it falls back to the mailbox when no turn is running."),
-	message: z.string().min(1).max(16384).describe("Message to deliver to the subagent.")
+	message: z.string().min(1).refine((value) => new TextEncoder().encode(value).length <= DEFAULT_BYTE_LIMIT, { message: `Message must be at most ${BYTE_LIMIT_KIB} KiB of UTF-8 text.` }).describe(`Message to deliver to the subagent. At most ${BYTE_LIMIT_KIB} KiB of UTF-8 text (about 5,400 Chinese characters); a longer message is rejected.`)
 });
 const STATUS_TO_TEXT = {
 	not_found: "No such subagent.",
 	not_owned: "That subagent is not owned by the current agent; only the owning parent may message it.",
-	not_active: "The subagent already finished; messages cannot reach it. Use Agent(resume=<agent id>, prompt=<your decision>) to continue it with your reply.",
-	saturated: "Message rejected: the target mailbox is already holding its maximum number of undelivered messages.",
-	deadline_elapsed: "Message rejected: its delivery deadline elapsed before it could be sent."
+	not_active: "The subagent already finished; messages cannot reach it in this session. Use Agent(resume=<agent id>, prompt=<your decision>) to continue it with your reply.",
+	parent_gone: "Message refused: the parent agent that owns this session state is no longer running, so the message was not queued. Resume that agent and send the message again from there.",
+	saturated: "Message rejected: the target mailbox is already holding its maximum number of undelivered messages."
 };
 const ACCEPTED_TEXT = {
-	"mid-run": "Message accepted and delivered into the subagent's running turn; it joins at the subagent's next step boundary.",
-	interjected: "Message accepted and interjected: the subagent's in-flight tool batch was interrupted so the message takes effect immediately.",
-	queued: "Message accepted and queued; it is delivered when the subagent starts its next turn."
+	"mid-run": "Message accepted and delivered into the subagent's running turn; it joins at the subagent's next step boundary. Delivery is in-session only — nothing is persisted across a process restart.",
+	interjected: "Message accepted and interjected: the subagent's in-flight tool batch was interrupted so the message takes effect immediately. Delivery is in-session only — nothing is persisted across a process restart.",
+	queued: `Message accepted and queued; it is delivered when the subagent starts its next turn. Delivery is in-session and time-boxed: an undelivered message expires ${DEADLINE_MINUTES} minutes after acceptance (nothing survives a process restart; a resume in this session before the deadline can still pick it up).`
+};
+/** Why an accepted `interject` fell back to the mailbox instead of firing. */
+const DOWNGRADE_TEXT = {
+	structured: "Interject downgraded to a queued message: the subagent returns a structured (JSON) answer, so its tool batch is never interrupted.",
+	idle: "Interject downgraded to a queued message: no turn is running, so there is no tool batch to interrupt.",
+	"steer-buffer-full": "Interject downgraded to a queued message: the subagent's steer buffer is full."
 };
 var SendSubagentMessageTool = class {
 	subagentHost;
@@ -60893,7 +61204,7 @@ var SendSubagentMessageTool = class {
 			approvalRule: this.name,
 			execute: async () => {
 				const result = this.subagentHost.sendMessage(args.agent_id, args.operation, args.message);
-				const reasonText = result.status === "accepted" ? `${ACCEPTED_TEXT[result.delivery ?? "queued"]}${result.duplicate === true ? " Duplicate of a message already in flight — the subagent will see it once." : ""}` : result.reason === "bytes" ? "Message rejected: it exceeds the byte limit for a single message." : STATUS_TO_TEXT[result.status] ?? result.status;
+				const reasonText = result.status === "accepted" ? `${ACCEPTED_TEXT[result.delivery ?? "queued"]}${result.downgrade !== void 0 ? ` ${DOWNGRADE_TEXT[result.downgrade]}` : ""}${result.duplicate === true ? ` Duplicate of a message already in flight${result.messageId === void 0 ? "" : ` (id: ${result.messageId})`} — the subagent will see it once.` : ""}` : result.reason === "bytes" ? `Message rejected: it exceeds the ${BYTE_LIMIT_KIB} KiB UTF-8 byte limit for a single message.` : STATUS_TO_TEXT[result.status] ?? result.status;
 				return {
 					isError: result.status !== "accepted",
 					output: reasonText
@@ -61949,7 +62260,7 @@ var KnowledgeLookupTool = class {
 };
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/image/image-generate.md
-var image_generate_default = "Generate or edit an image through the locally configured image API (OpenAI-compatible) and save the result as a PNG file. Returns the absolute path of the saved image.\n\n- `mode=new`: text-to-image generation from `prompt`.\n- `mode=edit`: rewrites the image(s) listed in `imagePaths` (at least one required).\n- `mode=continue`: edits the last image produced in the session; extra `imagePaths` are fed in as additional references.\n- `session` groups turns into one visual thread; omit it to start or join the default thread.\n- `size` defaults to the configured value (usually omitted from the request). If the service rejects an explicit size or demands one, the tool retries once on its own — no need to repeat the call.\n- The configured URL is the FULL endpoint and is used verbatim; nothing is appended. Image editing uses the configured edit URL, or derives the sibling `/images/edits` endpoint when the main URL ends in `/images/generations`.\n- Input image paths go through the same path policy as Read before any request: sensitive files (credentials, SSH keys, env files) are rejected outright, and relative paths may not escape the workspace. Rejections happen before approval and before any bytes leave the machine.\n- The API configuration lives only in a local file on this machine. When the tool reports that image generation is not configured, tell the user to run `/config image` and retry after they finish — never ask for, repeat, or log an API key in the conversation.\n- Call this only after the prompt has been refined for image generation (subject, composition, style, lighting, aspect ratio).\n";
+var image_generate_default = "Generate or edit an image through the locally configured image API (OpenAI-compatible) and save the result as a PNG file. Returns the absolute path of the saved image.\n\n- `mode=new`: text-to-image generation from `prompt`.\n- `mode=edit`: rewrites the image(s) listed in `imagePaths` (at least one required).\n- `mode=continue`: edits the last image produced in the session; extra `imagePaths` are fed in as additional references.\n- `session` groups turns into one visual thread; omit it to start or join the default thread.\n- `size` defaults to the configured value (usually omitted from the request). If the service rejects an explicit size or demands one, the tool retries once on its own — no need to repeat the call.\n- The configured URL is the FULL endpoint and is used verbatim; nothing is appended. Image editing uses the configured edit URL, or derives the sibling `/images/edits` endpoint when the main URL ends in `/images/generations`.\n- Input image paths go through the same path policy as Read before any request: sensitive files (credentials, SSH keys, env files) are rejected outright, and relative paths may not escape the workspace. Rejections happen before approval and before any bytes leave the machine.\n- The API configuration lives only in a local file on this machine. When the tool reports that image generation is not configured, tell the user to run `/config image` and retry after they finish — never ask for, repeat, or log an API key in the conversation.\n- Call this with the prompt passed through unchanged: use the user's own wording — do not rewrite, expand, or add style/lighting/composition details. Size and aspect-ratio needs belong in `size`. Refine the prompt only when the user explicitly asks for a rewrite.\n";
 //#endregion
 //#region ../../packages/agent-core/src/tools/builtin/image/image-generate.ts
 /**
@@ -61978,7 +62289,7 @@ const ImageGenerateInputSchema = z.object({
 		"edit",
 		"continue"
 	]).describe("new = text-to-image, edit = rewrite imagePaths, continue = edit the session's last image."),
-	prompt: z.string().min(1).describe("The refined image-generation prompt."),
+	prompt: z.string().min(1).describe("The image-generation prompt exactly as the user wrote it."),
 	imagePaths: z.array(z.string()).optional().describe("Absolute or workspace-relative image paths. Required for mode=edit."),
 	session: z.string().optional().describe("Visual thread name. Omit to start/join the default thread."),
 	size: z.string().optional().describe("Requested size for the model, e.g. \"1024x1024\" or \"1536x1024\". Pick one from the user's aspect-ratio need; omit to use the configured default.")
@@ -65449,7 +65760,7 @@ const DREAM_SKILL = {
 };
 //#endregion
 //#region ../../packages/agent-core/src/skill/builtin/image.md
-var image_default = "---\nname: image\ndescription: 生图/改图/图生图 — 把需求或已有图片变成新图（触发词：做图、做海报、生图、生成图片、图生图、改图、画一张、画个、出图、把图改成）\n---\n\n# Image: 生图工作流\n\n用户想生成或修改图片。你的职责：把模糊需求加工成高质量生图 prompt，然后通过 `ImageGenerate` 工具完成生成，最后把图片路径交给用户。\n\n## 第一步：直接进入工作流（不要为检查配置单独调用）\n\n不要为了\"测试配置\"而发起一次 `ImageGenerate`——配置正常时那会真的生成一张废图、白花额度。\n正确顺序：**先完成第二、三步的模式判定与 prompt 优化，再发起真实的生成调用。**\n\n如果真实调用返回\"未配置\"错误：\n\n1. 回复用户：「生图 API 尚未配置，请输入 `/config image` 完成配置（选服务商 → 填 URL → 填 APIKey → 填模型）。配置完成后告诉我，我会**自动继续**刚才的请求。」\n2. **不要**询问、索要、或接受 APIKey —— 密钥只走 `/config image` 的本地对话框，绝不进入对话。\n3. 用户说配置完成后，直接重试生图，**让用户重述需求**是失败的体验。\n\n## 第二步：判定模式\n\n| 情形 | mode | 参数 |\n|---|---|---|\n| 纯文字要一张新图 | `new` | 优化后的 prompt |\n| 用户消息带了图片附件，要改它 | `edit` | `imagePaths: [附件路径]` |\n| \"继续改上一张 / 再改改\" | `continue` | 用会话里上一张输出 |\n| 说要\"改\"但上下文没有图 | **先问图** | 请用户发图或给文件路径，不要瞎猜 |\n\n- 附件路径以消息中实际出现的文件路径为准；拿不到路径就向用户要。\n- 路径规则与 Read 相同：**敏感文件（密钥/凭证/env）会被工具直接拒绝**，相对路径不得逃出工作区——遇到这类报错就告诉用户换一张图，不要绕过工具。\n- 想出多张变体：同一 `session` 连续调用多次 `new`，prompt 每次换一个变体方向。\n\n## 第三步：优化 prompt（这是你的核心价值）\n\n把用户的粗糙需求加工成完整五要素，**输出优化后的 prompt 再调工具**（让用户看到你加了什么）：\n\n1. **主体**：谁/什么，动作、表情、材质\n2. **构图**：视角、景别、主体位置\n3. **风格**：摄影/插画/3D/像素/水彩……写实 or 扁平\n4. **光照**：自然光/棚拍/霓虹/逆影/黄金时刻\n5. **用途与比例**：头像 1:1、壁纸 16:9、海报 3:4 ——并按需把比例翻译成 `size` 参数\n\n**常用比例 → size 建议**（模型不支持的档位会被自动降级兜底，无需你重试）：\n\n| 用途 | 比例 | size |\n|---|---|---|\n| 头像 / 图标 | 1:1 | `1024x1024` |\n| 壁纸 / 横版插画 | 16:9 | `1536x1024`（竖版反向 `1024x1536`） |\n| 海报 / 人像 | 3:4 | `1024x1536` |\n| 不确定 / 用户没提 | — | **不传**（留空最安全，服务端会用默认档） |\n\n改图（edit/continue）用不变量模板：**\"以所附图片为底，保留主体与构图，只改 X\"** ——不要重写与需求无关的部分。\n\n示例：\n- 用户：\"画一只猫\" →\n  `一只橘猫蹲坐在旧书桌上，侧逆光勾勒毛发轮廓，浅景深，背景是虚化的咖啡馆暖光，胶片摄影风格，16:9 桌面壁纸`\n- 用户（对上一张图）：\"改成夜景\" →\n  `以所附图片为底，保留主体、构图与机位，仅将场景光照替换为夜景：冷调月光、远处暖色路灯、天空压暗，其余细节不变`\n\n## 第四步：调用与产出\n\n1. 调 `ImageGenerate`，参数带上优化后的 prompt、正确的 mode、必要时指定 `session`。\n2. 成功后向用户展示：**图片绝对路径** + 一句你加工了什么。建议用户用图片查看能力打开确认。\n3. 失败（网络/HTTP/无图数据）：把错误要点转述给用户，给出「换个时段 / 检查 `/config image` 的 URL 与模型」两类排查方向，不要重复粘贴原始堆栈。\n\n## 安全红线\n\n- **永远不要**在回复、日志、示例里回显 APIKey；工具结果里也不会出现它。\n- 用户在聊天里粘贴密钥：拒绝使用，引导其 `/config image` 重新输入，并建议他作废已泄露的 key。\n- 不要绕过 `ImageGenerate` 用 Bash 直接 curl 生图接口 —— 那会把密钥暴露给 shell 历史与输出。\n";
+var image_default = "---\nname: image\ndescription: 生图/改图/图生图 — 把需求或已有图片变成新图（触发词：做图、做海报、生图、生成图片、图生图、改图、画一张、画个、出图、把图改成）\n---\n\n# Image: 生图工作流\n\n用户想生成或修改图片。你的职责：把用户的提示词**原样**交给 `ImageGenerate`（内容完全以用户为主、不作发挥），只处理参数类事项（模式 / 尺寸 等），最后把图片路径交给用户。\n\n## 第一步：直接进入工作流（不要为检查配置单独调用）\n\n不要为了\"测试配置\"而发起一次 `ImageGenerate`——配置正常时那会真的生成一张废图、白花额度。\n正确顺序：**先完成第二、三步的模式判定与 prompt 准备，再发起真实的生成调用。**\n\n如果真实调用返回\"未配置\"错误：\n\n1. 回复用户：「生图 API 尚未配置，请输入 `/config image` 完成配置（选服务商 → 填 URL → 填 APIKey → 填模型）。配置完成后告诉我，我会**自动继续**刚才的请求。」\n2. **不要**询问、索要、或接受 APIKey —— 密钥只走 `/config image` 的本地对话框，绝不进入对话。\n3. 用户说配置完成后，直接重试生图，**让用户重述需求**是失败的体验。\n\n## 第二步：判定模式\n\n| 情形 | mode | 参数 |\n|---|---|---|\n| 纯文字要一张新图 | `new` | 用户的 prompt（内容零发挥，见第三步） |\n| 用户消息带了图片附件，要改它 | `edit` | `imagePaths: [附件路径]` |\n| \"继续改上一张 / 再改改\" | `continue` | 用会话里上一张输出 |\n| 说要\"改\"但上下文没有图 | **先问图** | 请用户发图或给文件路径，不要瞎猜 |\n\n- 附件路径以消息中实际出现的文件路径为准；拿不到路径就向用户要。\n- 路径规则与 Read 相同：**敏感文件（密钥/凭证/env）会被工具直接拒绝**，相对路径不得逃出工作区——遇到这类报错就告诉用户换一张图，不要绕过工具。\n- 想出多张变体：同一 `session` 连续调用多次 `new`，prompt 每次换一个变体方向。\n\n## 第三步：prompt 以用户为主（内容零发挥）\n\n生图模型自己就懂提示词——**不要替用户加工**：\n\n1. **原样直传**：用户给什么就输入什么；用户给了详细提示词就**一字不改**，不加主体细节、不加风格 / 光照 / 构图。\n2. **最多微微调**：仅修明显的笔误 / 病句，不碰元素与语义。\n3. **含糊也直传**：\"画一只猫\" 就输入 `画一只猫`——品种、场景、风格由模型自行诠释，不要替用户补全。\n4. **用户明确要求优化时**才优化，按其要求来；skill 不主动代劳、不主动加料。\n\n**参数类才是你要优化的**——尺寸 / 比例、mode 等；用户没提就留空用默认，不瞎猜。\n\n**常用比例 → size 建议**（模型不支持的档位会被自动降级兜底，无需你重试）：\n\n| 用途 | 比例 | size |\n|---|---|---|\n| 头像 / 图标 | 1:1 | `1024x1024` |\n| 壁纸 / 横版插画 | 16:9 | `1536x1024`（竖版反向 `1024x1536`） |\n| 海报 / 人像 | 3:4 | `1024x1536` |\n| 不确定 / 用户没提 | — | **不传**（留空最安全，服务端会用默认档） |\n\n**带文字的物料（海报等）：文字交给模型**——把用户给的**全部文案写进提示词**（一字不改），由模型完成排版与生成；**禁止**\"先生成底图、再用任何工具加字 / 合成 / 后处理\"。用户没给文案就先向用户要，不要自己编。\n\n**改图（edit / continue）：同样不套模板**——直接把用户原话作为 prompt、附上图片即可；不要添加用户没说的约束。\n\n示例：\n- 用户：\"画一只猫\" → prompt 就是 `画一只猫`（品种 / 场景 / 风格由模型自行诠释）\n- 用户：\"做一张竖版海报，主标题『春日特惠』，副标题『全场五折』，暖色调\" → prompt 包含上述原文与全部文案，**一次生成**；不要先生成底图再加字\n- 用户（对上一张图）：\"改成夜景\" → prompt 就是 `改成夜景` + 附图\n\n## 第四步：调用与产出\n\n1. 调 `ImageGenerate`：prompt 用**用户的提示词**（内容零发挥）、正确的 mode、按需的尺寸参数，必要时指定 `session`。\n2. 成功后向用户展示：**图片绝对路径**；如参数层有可说明的（尺寸等）就顺带一句，**不要汇报\"我加工 / 优化了什么\"**。建议用户用图片查看能力打开确认。\n3. 失败（网络/HTTP/无图数据）：把错误要点转述给用户，给出「换个时段 / 检查 `/config image` 的 URL 与模型」两类排查方向，不要重复粘贴原始堆栈。\n\n## 安全红线\n\n- **永远不要**在回复、日志、示例里回显 APIKey；工具结果里也不会出现它。\n- 用户在聊天里粘贴密钥：拒绝使用，引导其 `/config image` 重新输入，并建议他作废已泄露的 key。\n- 不要绕过 `ImageGenerate` 用 Bash 直接 curl 生图接口 —— 那会把密钥暴露给 shell 历史与输出。\n";
 //#endregion
 //#region ../../packages/agent-core/src/skill/builtin/image.ts
 const PSEUDO_PATH$1 = "builtin://image";
@@ -67703,8 +68014,7 @@ const BackgroundConfigSchema = z.object({
 	maxRunningTasks: z.number().int().min(1).optional(),
 	keepAliveOnExit: z.boolean().optional(),
 	killGracePeriodMs: z.number().int().min(0).optional(),
-	agentTaskTimeoutS: z.number().int().min(1).optional(),
-	printWaitCeilingS: z.number().int().min(1).optional()
+	agentTaskTimeoutS: z.number().int().min(1).optional()
 });
 const HookDefSchema = z.object({
 	event: z.enum(HOOK_EVENT_TYPES),
@@ -69865,10 +70175,13 @@ var WolfPackTool = class {
 		this.log = options?.log;
 		this.allowedSpawns = options?.allowedSpawns;
 		this.timeoutMs = options?.timeoutMs ?? DEFAULT_SUBAGENT_TIMEOUT_MS;
+		this.spawnDepth = options?.spawnDepth ?? (() => 0);
 	}
 	log;
 	allowedSpawns;
 	timeoutMs;
+	/** Reads the calling agent's spawn depth for the nesting gate. */
+	spawnDepth;
 	resolveExecution(args) {
 		return {
 			description: `WolfPack: ${args.description} (${args.items.length} agents)`,
@@ -69894,6 +70207,11 @@ var WolfPackTool = class {
 			output: `Cannot spawn "${profileName}" via WolfPack. Allowed subagents: ${this.allowedSpawns.join(", ")}.`,
 			isError: true
 		};
+		const depth = this.spawnDepth();
+		if (depth >= 3) return {
+			output: spawnDepthLimitRefusal(depth),
+			isError: true
+		};
 		const template = args.prompt_template;
 		const handlePromises = args.items.map(async (item) => {
 			ctx.signal.throwIfAborted();
@@ -78912,89 +79230,6 @@ function splitSegments(value) {
 //#region ../../packages/agent-core/src/tools/builtin/shell/bash.md
 var bash_default = "Execute a `{{ SHELL_NAME }}` command. Use this for shell semantics — pipes, env, processes, git, package managers, build/test runners, anything genuinely interactive or multi-step.\n\n**Translate these to a dedicated tool instead:**\n- `cat` / `head` / `tail` (known path) → `Read`\n- `sed` / `awk` (in-place edit) → `Edit`\n- `echo > file` / `cat <<EOF` → `Write`\n- `find` / recursive `ls` to locate files by name pattern → `Glob` (plain `ls <known-directory>` is fine for listing a directory)\n- `grep` / `rg` (search file contents) → `Grep`\n- `echo` / `printf` (talk to the user) → just output text directly\n\nThe dedicated tools render in the per-tool permission UI and keep raw stdout out of the conversation; that is why they are worth reaching for whenever one fits.\n\n**Output:**\nThe stdout and stderr will be combined and returned as a string. The output may be truncated if it is too long. If the command failed, the output will end with a `Command failed with exit code: N` line stating the non-zero exit code.\n\nIf `run_in_background=true`, the command will be started as a background task and this tool will return a task ID instead of waiting for command completion. When doing that, you must provide a short `description`. Background commands default to a {{ DEFAULT_BACKGROUND_TIMEOUT_S }}s timeout and `timeout` is capped at {{ MAX_BACKGROUND_TIMEOUT_S }}s; set `disable_timeout=true` only when the task should run without a timeout. You will be automatically notified when the task completes. Use `TaskOutput` for a non-blocking status/output snapshot, and only set `block=true` when you explicitly want to wait for completion. Use `TaskStop` only if the task must be cancelled. If a human user wants to inspect background tasks themselves, point them to the `/tasks` command, which opens an interactive panel; it has no subcommands.\n\n**Guidelines for safety and security:**\n- Each shell tool call will be executed in a fresh shell environment. The shell variables, current working directory changes, and the shell history is not preserved between calls.\n- The tool call will return after the command is finished. You shall not use this tool to execute an interactive command or a command that may run forever. For possibly long-running foreground commands, set the `timeout` argument in seconds. Foreground commands default to {{ DEFAULT_TIMEOUT_S }}s and allow up to {{ MAX_TIMEOUT_S }}s.\n- Avoid using `..` to access files or directories outside of the working directory.\n- Avoid modifying files outside of the working directory unless explicitly instructed to do so.\n- Never run commands that require superuser privileges unless explicitly instructed to do so.\n\n**Guidelines for efficiency:**\n{%- if SHELL_IS_POWERSHELL %}\n- Chain with `;` to run commands sequentially. `&&` / `||` only exist from PowerShell 7 and are a parse error on Windows PowerShell 5.1, so do not use them; write `; if ($?) { … }` when the next step must run only if the previous one succeeded.\n- Filter and transform with pipelines (`Get-ChildItem | Where-Object …`); redirect with `>` / `>>`.\n- Quote paths containing spaces with single quotes, e.g. `Set-Location 'C:\\Program Files'`.\n- Read environment variables as `$env:NAME` (`$env:NAME = 'value'`), never `$NAME`.\n- Compose multi-step logic in a single call with `if` / `foreach` / `while` and `try` / `catch`.\n{%- else %}\n- For multiple related commands, use `&&` to chain them in a single call, e.g. `cd /path && ls -la`\n- Use `;` to run commands sequentially regardless of success/failure\n- Use `||` for conditional execution (run second command only if first fails)\n- Use pipe operations (`|`) and redirections (`>`, `>>`) to chain input and output between commands\n- Always quote file paths containing spaces with double quotes (e.g., cd \"/path with spaces/\")\n- Compose multi-step logic in a single call with `if` / `case` / `for` / `while` control flows.\n{%- endif %}\n- Prefer `run_in_background=true` for long-running builds, tests, watchers, or servers when you need the conversation to continue before the command finishes.\n\n**Commands available:**\nThe following common command categories are usually available. Availability still depends on the host, so when in doubt {% if SHELL_IS_POWERSHELL %}confirm a command exists with `Get-Command <name> -ErrorAction SilentlyContinue` before relying on it — several names below are cmdlet aliases (`ls` → `Get-ChildItem`, `rm` → `Remove-Item`), and POSIX-only entries such as `uname`, `chmod` and `kill` may be absent.{% else %}run `which <command>` first to confirm a command exists before relying on it.{% endif %}\n- Navigation and inspection: `ls`, `pwd`, `cd`, `stat`, `file`, `du`, `df`, `tree`\n- File and directory management: `cp`, `mv`, `rm`, `mkdir`, `touch`, `ln`, `chmod`, `chown`\n- Text and data processing: `wc`, `sort`, `uniq`, `cut`, `tr`, `diff`, `xargs`\n- Archives and compression: `tar`, `gzip`, `gunzip`, `zip`, `unzip`\n- Networking and transfer: `curl`, `wget`, `ping`, `ssh`, `scp`\n- Version control: `git`\n- Process and system: `ps`, `kill`, `top`, `env`, `date`, `uname`, `whoami`\n- Language and package toolchains: `node`, `npm`, `pnpm`, `yarn`, `python`, `pip` (use whichever the project actually relies on)\n";
 //#endregion
-//#region ../../packages/agent-core/src/tools/builtin/shell/background-tasks.ts
-/**
-* Lightweight store for foreground Bash commands that were moved to
-* background on timeout. The process continues running; when it exits
-* the result is stored here and surfaced to the model on the next Bash
-* call.
-*
-* This is intentionally simple - it does NOT use the full
-* BackgroundProcessManager (which assumes it owns the process streams
-* from spawn). Here the streams are already being read by the
-* foreground ToolResultBuilder, so we just wrap the pending
-* completion promise.
-*/
-const pendingTasks = /* @__PURE__ */ new Map();
-const MAX_PENDING = 10;
-function createBackgroundTask(command, completion, handles) {
-	const id = randomUUID().slice(0, 8);
-	const task = {
-		command,
-		startedAt: Date.now(),
-		completion,
-		kill: handles.kill,
-		pid: handles.pid,
-		ownerId: handles.ownerId
-	};
-	if (pendingTasks.size >= MAX_PENDING) {
-		const oldest = pendingTasks.keys().next().value;
-		if (oldest !== void 0) {
-			const evicted = pendingTasks.get(oldest);
-			pendingTasks.delete(oldest);
-			if (evicted !== void 0) evicted.kill();
-		}
-	}
-	pendingTasks.set(id, task);
-	task.completion.then((result) => {
-		task.result = result;
-	}, () => {
-		task.result = {
-			exitCode: -1,
-			output: "Background process failed."
-		};
-	});
-	return id;
-}
-/**
-* Collect results from background tasks that have completed since the
-* last check. Each completed task is returned once and then removed.
-*/
-function drainCompletedBackgroundTasks() {
-	const completed = [];
-	for (const [id, task] of pendingTasks) if (task.result !== void 0) {
-		completed.push({
-			id,
-			command: task.command,
-			exitCode: task.result.exitCode,
-			output: task.result.output,
-			elapsedMs: Date.now() - task.startedAt
-		});
-		pendingTasks.delete(id);
-	}
-	return completed;
-}
-/**
-* Kill the parked commands one owner is responsible for and clear them.
-*
-* Strictly owner-matched, `undefined` included: the registry is module-level
-* while sessions are not, so a session teardown must reach exactly the tasks
-* its own agents parked (every agent's Bash tool stamps its session id — see
-* `Session.instantiateAgent`) and never another session's. The undefined match
-* is a real case, not a wildcard: `SessionOptions.id` is optional, so a session
-* created without an id stamps no owner, and matching it against "no owner" is
-* what keeps that session's close() from executing a foreign session's command.
-* Process-wide cleanup is `killAllPendingBackgroundTasks`, which only a real
-* exit path may call.
-*/
-function stopAllPendingBackgroundTasks(ownerId) {
-	for (const [id, task] of pendingTasks) {
-		if (task.ownerId !== ownerId) continue;
-		task.kill();
-		pendingTasks.delete(id);
-	}
-}
-//#endregion
 //#region ../../packages/agent-core/src/tools/builtin/shell/bash.ts
 /**
 * BashTool — execute shell commands.
@@ -79282,13 +79517,6 @@ var BashTool = class {
 	shellKind;
 	allowBackground;
 	availableTools;
-	/**
-	* Session this tool belongs to (the owning agent's session id). A command
-	* that times out is parked in the module-level pending registry under this
-	* key, so closing one session sweeps only its own parked commands instead of
-	* executing every other session's running work.
-	*/
-	ownerId;
 	constructor(jian, cwd, backgroundManager, options) {
 		this.jian = jian;
 		this.cwd = cwd;
@@ -79298,7 +79526,6 @@ var BashTool = class {
 		this.isWindowsBash = this.isWindows && this.shellKind === "posix";
 		this.allowBackground = options?.allowBackground ?? this.backgroundManager !== void 0;
 		this.availableTools = options?.availableTools ?? /* @__PURE__ */ new Set();
-		this.ownerId = options?.ownerId;
 		const rendered = renderBashDescription(this.jian.osEnv.shellName, this.shellKind === "powershell");
 		this.description = this.allowBackground ? rendered : withoutBackgroundDescription(rendered);
 	}
@@ -79340,15 +79567,13 @@ var BashTool = class {
 	}
 	async execution(args, ctx) {
 		const { signal, onUpdate } = ctx;
-		const completedBg = drainCompletedBackgroundTasks();
-		const bgPrefix = completedBg.length > 0 ? completedBg.map((t) => `[Background task ${t.id} completed] Command: ${t.command}\nExit code: ${String(t.exitCode)} (${(t.elapsedMs / 1e3).toFixed(1)}s)\nOutput:\n${t.output}\n---\n`).join("") : "";
 		if (signal.aborted) return {
 			isError: true,
-			output: bgPrefix + (isParentInterject(signal.reason) ? "Interrupted by the parent agent before the command started" : "Aborted before command started")
+			output: isParentInterject(signal.reason) ? "Interrupted by the parent agent before the command started" : "Aborted before command started"
 		};
 		if (args.command.length === 0) return {
 			isError: true,
-			output: bgPrefix + "Command cannot be empty."
+			output: "Command cannot be empty."
 		};
 		const validationError = validateCommand(args.command, this.isWindows);
 		if (validationError !== null) return validationError;
@@ -79379,7 +79604,12 @@ var BashTool = class {
 		let aborted = false;
 		let killed = false;
 		let streaming = true;
+		let parkedTaskId;
 		const forwardChunk = (kind, text) => {
+			if (parkedTaskId !== void 0) {
+				this.backgroundManager?.appendCapturedOutput(parkedTaskId, text);
+				return;
+			}
 			if (!streaming || signal.aborted || onUpdate === void 0) return;
 			onUpdate({
 				kind,
@@ -79426,7 +79656,6 @@ var BashTool = class {
 				await writeFile(artifactPath, fullOutput, "utf8");
 				return artifactPath;
 			} });
-			if (bgPrefix.length > 0) builder.write(bgPrefix);
 			const stdoutDone = readStreamIntoBuilder(proc.stdout, builder, (text) => forwardChunk("stdout", text));
 			const stderrDone = readStreamIntoBuilder(proc.stderr, builder, (text) => forwardChunk("stderr", text));
 			const stdoutSettled = stdoutDone.catch(() => void 0);
@@ -79450,38 +79679,34 @@ var BashTool = class {
 			if (raceResult.timedOut) {
 				streaming = false;
 				const timeoutLabel = timeoutMs % 1e3 === 0 ? `${String(timeoutMs / 1e3)}s` : `${String(timeoutMs)}ms`;
-				const taskId = createBackgroundTask(command, completionPromise.then(({ exitCode }) => ({
-					exitCode,
-					output: builder.toString()
-				})), {
-					kill: killProc,
-					pid: proc.pid,
-					ownerId: this.ownerId
-				});
-				if (onUpdate !== void 0) completionPromise.then(({ exitCode }) => {
-					onUpdate({
-						kind: "custom",
-						customKind: "background.task.terminated",
-						customData: {
-							id: taskId,
-							command,
-							exitCode
-						}
-					});
-				}, () => {
-					onUpdate({
-						kind: "custom",
-						customKind: "background.task.terminated",
-						customData: {
-							id: taskId,
-							command,
-							exitCode: -1
-						}
+				const manager = this.backgroundManager;
+				if (manager === void 0) {
+					killProc();
+					return {
+						isError: true,
+						output: `Command timed out after ${timeoutLabel} and was stopped: this agent has no background task manager.`
+					};
+				}
+				let parkedId;
+				const trimmedDescription = args.description?.trim();
+				try {
+					parkedId = manager.parkForegroundProcess(completionPromise, command, trimmedDescription === void 0 || trimmedDescription.length === 0 ? command : trimmedDescription, {
+						kill: () => killProc(),
+						pid: proc.pid,
+						initialOutput: builder.toString()
 					});
-				});
+				} catch (error) {
+					killProc();
+					return {
+						isError: true,
+						output: `Command timed out after ${timeoutLabel} and was stopped: could not park it as a background task (${error instanceof Error ? error.message : String(error)}).`
+					};
+				}
+				parkedTaskId = parkedId;
 				const outputSoFar = builder.toString();
+				const nextStep = this.allowBackground ? `The task keeps running and notifies you when it finishes; TaskOutput(task_id="${parkedId}") shows its output and TaskStop(task_id="${parkedId}") cancels it.` : "The task keeps running and notifies you when it finishes.";
 				return {
-					output: `Command timed out after ${timeoutLabel} but is still running in the background (task: ${taskId}).\nOutput so far (${String(builder.nChars)} chars):\n${outputSoFar}\n---\nThe command will complete in the background. The result will be included in your next Bash call.`,
+					output: `Command timed out after ${timeoutLabel} but is still running in the background (task: ${parkedId}).\nOutput so far (${String(builder.nChars)} chars):\n${outputSoFar}\n---\n${nextStep}`,
 					isError: false
 				};
 			}
@@ -80642,9 +80867,17 @@ var BackgroundManager = class extends BackgroundProcessManager {
 	agent;
 	scheduledNotificationKeys = /* @__PURE__ */ new Set();
 	deliveredNotificationKeys = /* @__PURE__ */ new Set();
+	/**
+	* Session-death latch, set by `Session.close()` before it tears anything
+	* down, and by a subagent's terminal release as it evicts its finished
+	* owner (see `markSessionClosed`). While set, a terminal task notification
+	* is dropped instead of steered — see `notifyBackgroundTask`.
+	*/
+	sessionClosed = false;
 	constructor(agent) {
 		super({
 			maxRunningTasks: agent.screamConfig?.background?.maxRunningTasks,
+			killGracePeriodMs: agent.screamConfig?.background?.killGracePeriodMs,
 			sessionDir: agent.homedir
 		});
 		this.agent = agent;
@@ -80671,6 +80904,50 @@ var BackgroundManager = class extends BackgroundProcessManager {
 			}
 		});
 	}
+	/**
+	* Latch this manager so no further terminal task notification is steered
+	* through it (see `notifyBackgroundTask`). Two owners set it:
+	*
+	* - `Session.close()` calls it for every manager the session created, before
+	*   any teardown runs. That single drop does both jobs: no ghost turn is
+	*   launched for the closing session, and the notification stays undelivered,
+	*   so the reconcile path (`restoreBackgroundTaskNotifications`) appends it
+	*   silently the next time the session is opened.
+	* - The subagent host latches a child's manager when the child is evicted at
+	*   the end of its run. The child can no longer consume a notification, and
+	*   the tasks that outlive it — a parked foreground command above all —
+	*   would otherwise wake the evicted agent as a ghost turn. The drop is the
+	*   same: undelivered here, reported as `lost` by the reconcile of the
+	*   fresh manager a later resume builds.
+	*
+	* The latch has no reset counterpart on purpose: it models "this manager has
+	* no live consumer left", and nothing re-registers the latched instance. A
+	* closed session is discarded (the RPC layer's closeSession deletes it from
+	* the active map, and a later activation constructs a new `Session`), and
+	* `Session.resume()` / `ensureAgent` drop evicted agents before
+	* re-instantiating them from metadata — so every reopened or resumed owner
+	* runs a brand-new BackgroundManager whose latch starts unset.
+	*/
+	markSessionClosed() {
+		this.sessionClosed = true;
+	}
+	/**
+	* Stop every non-terminal agent-class task — the tasks registered through
+	* `registerAgentTask`, whose ids carry the `agent-` prefix (see
+	* generateTaskId).
+	*
+	* `Session.close()` calls this under `keepAliveOnExit`: that switch protects
+	* real bash processes, whose work stays meaningful to the user after the
+	* session is gone, while an agent task is a coroutine driving a subagent turn
+	* the close has already cancelled — left "alive" it can never finish on its
+	* own and would strand a half-dead ledger entry that later notifies a dead
+	* session. Bash tasks are deliberately untouched here; stopping those is
+	* `stopAll`, the keepAlive=false path.
+	*/
+	async stopAgentTasks(reason) {
+		const taskIds = this.list().filter((info) => isAgentTaskId(info.taskId)).map((info) => info.taskId);
+		return (await Promise.all(taskIds.map((taskId) => this.stop(taskId, reason)))).filter((info) => info !== void 0);
+	}
 	async reconcile() {
 		const result = await super.reconcile();
 		await this.restoreBackgroundTaskNotifications();
@@ -80697,8 +80974,13 @@ var BackgroundManager = class extends BackgroundProcessManager {
 	* same boundary, each scoped to the manager's own agent.
 	*/
 	async notifyBackgroundTask(info) {
+		if (this.sessionClosed) return;
 		const context = await this.buildBackgroundTaskNotificationContext(info);
 		if (context === void 0) return;
+		if (this.sessionClosed) {
+			this.scheduledNotificationKeys.delete(notificationKey(context.origin));
+			return;
+		}
 		this.agent.turn.steer(context.content, context.origin);
 		this.fireNotificationHook(context.notification);
 	}
@@ -80722,7 +81004,7 @@ var BackgroundManager = class extends BackgroundProcessManager {
 		this.scheduledNotificationKeys.add(key);
 		const tailOutput = (await this.getOutputSnapshot(info.taskId, NOTIFICATION_TAIL_BYTES)).preview;
 		if (this.hasDeliveredNotification(origin)) return;
-		const isAgentTask = info.taskId.startsWith("agent-");
+		const isAgentTask = isAgentTaskId(info.taskId);
 		const label = isAgentTask ? "agent" : "task";
 		const notification = {
 			id: notificationId,
@@ -80762,6 +81044,27 @@ var BackgroundManager = class extends BackgroundProcessManager {
 	markDeliveredNotification(origin) {
 		this.deliveredNotificationKeys.add(notificationKey(origin));
 	}
+	/**
+	* Export the delivered-notification keys for wire persistence. A full
+	* compaction folds the notification messages these marks were derived from
+	* into its summary, and the folded `context.append_message` records never
+	* replay — the `context.snapshot` payload is therefore the only place a
+	* resume can recover the marks from (see
+	* `ContextMemoryJSONSnapshot.deliveredNotificationKeys`). Losing them makes
+	* reconcile re-deliver notifications the session already saw.
+	*/
+	exportDeliveredNotificationKeys() {
+		return [...this.deliveredNotificationKeys];
+	}
+	/**
+	* Rebuild delivered marks from a restored snapshot. Additive on purpose:
+	* replay separately re-marks every notification message still present in
+	* the restored history, and a key from either source suppresses re-delivery
+	* — only a notification neither source knows about is appended by reconcile.
+	*/
+	restoreDeliveredNotificationKeys(keys) {
+		for (const key of keys) this.deliveredNotificationKeys.add(key);
+	}
 	hasDeliveredNotification(origin) {
 		return this.deliveredNotificationKeys.has(notificationKey(origin));
 	}
@@ -80782,6 +81085,13 @@ function notificationKey(origin) {
 	return `${origin.taskId}\0${origin.status}\0${origin.notificationId}`;
 }
 /**
+* Agent-class tasks are the ones registered through `registerAgentTask`; their
+* ids carry the `agent-` prefix (generateTaskId in tools/background/manager).
+*/
+function isAgentTaskId(taskId) {
+	return taskId.startsWith("agent-");
+}
+/**
 * Build the human/LLM-readable body that lands in the `<notification>`
 * XML. For agent-* tasks that ended non-successfully and whose subagent id
 * we still know, append a paragraph telling the LLM exactly how to resume
@@ -83507,6 +83817,7 @@ var ContextMemory = class {
 	* {@link ContextMemoryJSONSnapshot}).
 	*/
 	toJSONSnapshot() {
+		const deliveredNotificationKeys = this.agent.background.exportDeliveredNotificationKeys();
 		return {
 			history: [...this._history],
 			tokenCount: this._tokenCount,
@@ -83514,7 +83825,8 @@ var ContextMemory = class {
 			openSteps: [...this.openSteps.entries()].map(([uuid, message]) => [uuid, this._history.indexOf(message)]),
 			pendingToolResultIds: [...this.pendingToolResultIds],
 			deferredMessages: [...this.deferredMessages],
-			...this._messageEdits.size > 0 ? { messageEdits: [...this._messageEdits.entries()] } : {}
+			...this._messageEdits.size > 0 ? { messageEdits: [...this._messageEdits.entries()] } : {},
+			...deliveredNotificationKeys.length > 0 ? { deliveredNotificationKeys } : {}
 		};
 	}
 	/**
@@ -83537,6 +83849,7 @@ var ContextMemory = class {
 		this.pendingToolResultIds = new Set(snapshot.pendingToolResultIds);
 		this.deferredMessages = [...snapshot.deferredMessages];
 		this._messageEdits = new Map(snapshot.messageEdits ?? []);
+		this.agent.background.restoreDeliveredNotificationKeys(snapshot.deliveredNotificationKeys ?? []);
 		for (const message of this._history) this.assignMessageId(message);
 		for (const message of this.deferredMessages) this.assignMessageId(message);
 	}
@@ -86160,7 +86473,6 @@ const DEFAULT_HOOK_TIMEOUT_SECONDS = 30;
 var HookEngine = class {
 	options;
 	byEvent = /* @__PURE__ */ new Map();
-	pendingTriggers = /* @__PURE__ */ new Set();
 	constructor(hooks = [], options = {}) {
 		this.options = options;
 		for (const hook of hooks) {
@@ -86217,18 +86529,25 @@ var HookEngine = class {
 	async triggerBlock(event, args = {}) {
 		return blockDecision(event, await this.trigger(event, args));
 	}
+	/**
+	* Fire an event without making the caller wait for it. The returned promise
+	* is still awaitable by a caller that wants the results, and every failure
+	* path (synchronous throw included) resolves to `[]` so a caller that drops
+	* it can never produce an unhandled rejection.
+	*
+	* The engine keeps no bookkeeping of its own: there is no drain point for
+	* in-flight fire-and-forget work (no engine lifecycle owner — the engine is
+	* constructed per agent and never awaits a shutdown), so tracking the
+	* promises here would be write-only state that only pins memory. The
+	* per-hook timeout in `runHook` bounds the work itself, and the returned
+	* promise is the handle for a caller that does want to await it.
+	*/
 	fireAndForgetTrigger(event, args = {}) {
-		let promise;
 		try {
-			promise = this.trigger(event, args).catch(() => []);
+			return this.trigger(event, args).catch(() => []);
 		} catch {
-			promise = Promise.resolve([]);
+			return Promise.resolve([]);
 		}
-		this.pendingTriggers.add(promise);
-		promise.finally(() => {
-			this.pendingTriggers.delete(promise);
-		});
-		return promise;
 	}
 	async triggerInner(event, args) {
 		const matcherValue = matcherValueText(args.matcherValue);
@@ -87303,6 +87622,7 @@ const READ_TOOLS = new Set([
 	"Read",
 	"ReadGroup",
 	"ReadMediaFile",
+	"ReportArchFinding",
 	"ReportFinding",
 	"Skill",
 	"TodoList",
@@ -87378,6 +87698,135 @@ const DEFAULT_AUTO_APPROVE_TOOLS = new Set([
 	"MakeSkillApply"
 ]);
 //#endregion
+//#region ../../packages/agent-core/src/session/subagent-capability.ts
+/**
+* Subagent capability modes and their tool-set policy.
+*
+* Capability modes (read-only / read-write / execute / all): a mode is
+* enforced at the tool level, not just by prompting. `all` keeps the profile's
+* full tool set; stricter modes strip it down to the tools the mode permits.
+*
+* Tool classification is by name; the sets live in `#/tools/tool-catalog`
+* (shared with the permission policies) so a new tool is classified once.
+* Names the catalog does not classify are refused in every restricted mode
+* (fail-closed): a tool nobody classified must not survive a trim by virtue
+* of being unknown. MCP tools are refused for the same reason — their
+* read/write/execute nature cannot be read off the name.
+*/
+/** Tool names each restricted mode permits, built once at module load: the
+*  membership test runs for every active tool at spawn and for every tool call
+*  the runtime permission gate inspects. */
+const ALLOWED_TOOLS_BY_MODE = {
+	"read-only": union(READ_TOOLS, CORE_TOOLS),
+	"read-write": union(READ_TOOLS, WRITE_TOOLS, CORE_TOOLS),
+	execute: union(READ_TOOLS, WRITE_TOOLS, EXECUTE_TOOLS, CORE_TOOLS)
+};
+/**
+* Whether a tool may be used under `mode` — the single membership test shared
+* by the spawn-time trim (`filterToolsForCapability`) and the runtime
+* permission gate (`agent/permission/policies/capability-guard-deny`), so what
+* the model sees and what may actually run can never disagree.
+*
+* Fail-closed: `all` allows everything; every restricted mode refuses MCP
+* tools and any name the catalog does not classify.
+*/
+function isToolAllowedForCapability(name, mode) {
+	if (mode === "all") return true;
+	if (NESTING_TOOLS.has(name)) return false;
+	if (name.startsWith("mcp__")) return false;
+	return ALLOWED_TOOLS_BY_MODE[mode].has(name);
+}
+/**
+* Filter an active tool-name list down to what `mode` permits. `all` returns
+* the input unchanged. Restricted modes drop every name outside the mode's
+* set, unclassified names included (fail-closed — classify the tool in
+* `#/tools/tool-catalog` to admit it to a restricted child).
+*/
+function filterToolsForCapability(activeTools, mode) {
+	if (mode === void 0 || mode === "all") return [...activeTools];
+	return activeTools.filter((name) => isToolAllowedForCapability(name, mode));
+}
+function union(...sets) {
+	const out = /* @__PURE__ */ new Set();
+	for (const s of sets) for (const v of s) out.add(v);
+	return out;
+}
+/** Strictness order: earlier = narrower (fewer tools permitted). */
+const CAPABILITY_ORDER = [
+	"read-only",
+	"read-write",
+	"execute",
+	"all"
+];
+/**
+* The narrower of two capability modes (`read-only` < `read-write` < `execute`
+* < `all`). Resume uses this to clamp: a resumed agent keeps the tool set it
+* already has (its profile is not rebuilt), so its contract may be re-applied
+* or tightened, never widened.
+*/
+function narrowerCapability(a, b) {
+	return CAPABILITY_ORDER.indexOf(a) <= CAPABILITY_ORDER.indexOf(b) ? a : b;
+}
+/**
+* Infer the strictest capability mode that already permits `activeTools` — the
+* first mode whose `filterToolsForCapability` pass removes nothing, else `all`.
+*
+* Used when resuming a session recorded before `AgentMeta.capabilityMode`
+* existed: filtering is pure subtraction, so a tool set that survives
+* `read-only` unchanged is evidence the agent was never granted more than
+* that. The inference can only be too *narrow* (a set that happens to contain
+* only allowed tools), which is the safe direction for a capability clamp —
+* and an unclassified name can never be inferred into a restricted mode,
+* because every restricted mode drops it (fail-closed).
+*/
+function inferCapabilityFromTools(activeTools) {
+	for (const mode of CAPABILITY_ORDER) {
+		if (mode === "all") break;
+		if (filterToolsForCapability(activeTools, mode).length === activeTools.length) return mode;
+	}
+	return "all";
+}
+//#endregion
+//#region ../../packages/agent-core/src/agent/permission/policies/capability-guard-deny.ts
+/**
+* Hard capability gate for restricted subagents.
+*
+* `read-only` / `read-write` / `execute` are enforced twice: the spawn-time
+* trim (`filterToolsForCapability`) removes what the model SEES, and this
+* policy refuses what may RUN. A call can still arrive for a tool that is not
+* in the active list (a replayed turn, a plugin-provided name, a stale
+* schema), and an approval policy later in the chain must never widen a
+* restricted contract — the parent may spawn the child restricted, but the
+* child itself cannot talk its way past the trim.
+*
+* Both sides ask `isToolAllowedForCapability`, so visibility and execution
+* cannot drift: an unclassified tool name is refused here exactly as it is
+* stripped there, and MCP tools stay fail-closed.
+*
+* The mode is read off the asking agent instance (`all` for main agents and
+* unrestricted subagents, so this policy is inert for them). Because the
+* refusal lives in the permission layer rather than in each tool, it also
+* covers tools that keep a conditional write path (e.g. LSP rename with
+* `apply: true`) without every such tool re-implementing the check.
+*/
+var CapabilityGuardDenyPermissionPolicy = class {
+	agent;
+	name = "capability-guard-deny";
+	constructor(agent) {
+		this.agent = agent;
+	}
+	evaluate(context) {
+		const mode = this.agent.getCapabilityMode();
+		if (mode === "all") return void 0;
+		const toolName = context.toolCall.name;
+		if (isToolAllowedForCapability(toolName, mode)) return void 0;
+		return {
+			kind: "deny",
+			message: `Tool "${toolName}" is not available to this agent: it runs under the "${mode}" capability contract, which permits only a fixed tool set. Do not retry the call or try to reach the same effect another way — report back to the parent agent instead (ContactParent); the parent can re-dispatch the work with a wider contract if it is needed.`
+		};
+	}
+};
+//#endregion
 //#region ../../packages/agent-core/src/agent/permission/policies/default-tool-approve.ts
 var DefaultToolApprovePermissionPolicy = class {
 	name = "default-tool-approve";
@@ -87979,6 +88428,7 @@ var WolfPackModeApprovePermissionPolicy = class {
 function createPermissionDecisionPolicies(agent) {
 	return [
 		new PreToolCallHookPermissionPolicy(agent),
+		new CapabilityGuardDenyPermissionPolicy(agent),
 		new AutoModeAskUserQuestionDenyPermissionPolicy(agent),
 		new PlanModeGuardDenyPermissionPolicy(agent),
 		new AskModeGuardDenyPermissionPolicy(agent),
@@ -88113,6 +88563,15 @@ var PermissionManager = class {
 		};
 		const action = context.execution.description ?? `Call ${name}`;
 		const startedAt = Date.now();
+		const sourceAgentId = this.agent.agentId;
+		const sourceAgentName = this.agent.config.profileName;
+		const sourceCapabilityMode = this.agent.getCapabilityMode();
+		const source = {
+			sourceAgentId,
+			...sourceAgentName !== void 0 ? { sourceAgentName } : {},
+			...sourceCapabilityMode !== "all" ? { sourceCapabilityMode } : {},
+			sourceToolName: name
+		};
 		let response;
 		if (this.agent.rpc?.requestApproval) {
 			const approvalId = `approval-${String(++this.nextApprovalId)}`;
@@ -88135,7 +88594,8 @@ var PermissionManager = class {
 						toolCallId: id,
 						toolName: name,
 						action,
-						display
+						display,
+						...source
 					}, { signal }).then(resolve, reject);
 				});
 				const timeoutPromise = new Promise((_, reject) => {
@@ -104172,8 +104632,7 @@ var ToolManager = class {
 			new GlobTool(jian, workspace),
 			new BashTool(jian, cwd, background, {
 				allowBackground,
-				availableTools: this.enabledTools,
-				ownerId: this.agent.sessionId
+				availableTools: this.enabledTools
 			}),
 			pythonTool,
 			new ScriptTool(this.toolStore),
@@ -104210,14 +104669,16 @@ var ToolManager = class {
 			canSpawn && new AgentTool(this.agent.subagentHost, background, visibleSubagents, {
 				allowBackground,
 				log: this.agent.log,
-				allowedSpawns
+				allowedSpawns,
+				spawnDepth: () => this.agent.getRlmDepth()
 			}),
 			canSpawn && new SendSubagentMessageTool(this.agent.subagentHost),
 			this.agent.type === "sub" && this.agent.ownerHost !== void 0 && new ContactParentTool(this.agent.ownerHost, () => this.agent),
 			canSpawn && new WolfPackTool(this.agent.subagentHost, () => this.agent.wolfpackMode.isActive, {
 				subagents: visibleSubagents,
 				log: this.agent.log,
-				allowedSpawns
+				allowedSpawns,
+				spawnDepth: () => this.agent.getRlmDepth()
 			}),
 			this.agent.type === "main" && canSpawn && new FusionPlanTool(this.agent),
 			toolServices?.webSearcher && new WebSearchTool(toolServices.webSearcher),
@@ -110913,199 +111374,6 @@ async function collectStream(stream) {
 	for await (const chunk of stream) chunks.push(Buffer.isBuffer(chunk) ? chunk : Buffer.from(chunk));
 	return Buffer.concat(chunks).toString("utf-8");
 }
-/** UTF-8 byte length (TextEncoder is available in all supported runtimes). */
-function byteLength(text) {
-	return new TextEncoder().encode(text).length;
-}
-/**
-* Byte length of a message body. Callers that deliver a message without going
-* through `send` (the mid-run steer path) use this to apply the same limit.
-*/
-function subagentMessageBytes(text) {
-	return byteLength(text);
-}
-var SubagentMessageBus = class {
-	mailboxes = /* @__PURE__ */ new Map();
-	nextId = 0;
-	nextSeq = 0;
-	/**
-	* Number of messages still deliverable for `agentId`. Expired ones are not
-	* counted: `poll` drops them, so counting them would make the host spend a
-	* delivery turn on a message that can never arrive. Counting is also an
-	* ordinary bus access, so it reclaims mail that has expired by now.
-	*/
-	activeCount(agentId) {
-		this.reclaimExpired(Date.now());
-		return this.mailboxes.get(agentId)?.queue.length ?? 0;
-	}
-	/**
-	* Queue a message for a subagent. Pure mailbox logic: ownership, liveness
-	* and activity checks belong to the host. Returns the delivery status and,
-	* on acceptance, the queue depth seen by the recipient at poll time.
-	*/
-	send(msg) {
-		const now = Date.now();
-		this.reclaimExpired(now);
-		if (now > msg.deadline) return { status: "deadline_elapsed" };
-		if (byteLength(msg.text) > msg.byteLimit) return {
-			status: "saturated",
-			reason: "bytes"
-		};
-		let mailbox = this.mailboxes.get(msg.toAgentId);
-		if (mailbox === void 0) {
-			mailbox = { queue: [] };
-			this.mailboxes.set(msg.toAgentId, mailbox);
-		}
-		if (mailbox.queue.length >= msg.inFlightLimit) return {
-			status: "saturated",
-			reason: "queue"
-		};
-		const message = {
-			...msg,
-			id: `${msg.fromAgentId}:${msg.toAgentId}:${++this.nextId}`,
-			seq: ++this.nextSeq
-		};
-		mailbox.queue.push(message);
-		return {
-			status: "accepted",
-			queueDepth: mailbox.queue.length
-		};
-	}
-	/**
-	* Drop every queued message in every mailbox (session teardown). Id and seq
-	* counters stay monotonic so identifiers issued before the clear are never
-	* reissued.
-	*/
-	clear() {
-		this.mailboxes.clear();
-	}
-	/** Mailbox entries currently pinned in memory (diagnostics / assertions).
-	*  Reading does not reclaim: an entry whose mail has all expired is freed by
-	*  the next send/activeCount/poll, not by this getter. */
-	get mailboxCount() {
-		return this.mailboxes.size;
-	}
-	/**
-	* Drop mail that can no longer be delivered and free the mailbox slot it
-	* pinned. A message is deliverable only until its deadline; past it, `poll`
-	* would discard it rather than hand it to the child, so keeping it would pin
-	* memory for a run that has already ended. Called on every ordinary bus
-	* access — send, activeCount, poll — which is what keeps the mailbox map
-	* bounded now that a finished child's terminal no longer purges its mailbox.
-	*/
-	reclaimExpired(now) {
-		for (const [agentId, mailbox] of this.mailboxes) {
-			const live = mailbox.queue.filter((m) => m.deadline > now);
-			if (live.length === 0) this.mailboxes.delete(agentId);
-			else if (live.length !== mailbox.queue.length) mailbox.queue = live;
-		}
-	}
-	/**
-	* Deliver all pending, unexpired messages for `agentId`. Steer messages are
-	* always dequeued before queue messages; within an operation class, arrival
-	* order is preserved via the monotonically increasing `seq` (this is a stable
-	* two-pass collection, not a sort). Messages past their deadline are
-	* reclaimed, never delivered.
-	*
-	* The mailbox entry is removed once its queue is emptied: a polled-out (or
-	* fully expired) mailbox must not pin a Map slot.
-	*/
-	poll(agentId) {
-		const now = Date.now();
-		this.reclaimExpired(now);
-		const mailbox = this.mailboxes.get(agentId);
-		if (mailbox === void 0) return [];
-		this.mailboxes.delete(agentId);
-		const steers = mailbox.queue.filter((m) => m.operation === "steer");
-		const queues = mailbox.queue.filter((m) => m.operation === "queue");
-		steers.sort((a, b) => a.seq - b.seq);
-		queues.sort((a, b) => a.seq - b.seq);
-		return [...steers, ...queues];
-	}
-};
-/** Construct a message with the bus defaults applied. */
-function buildSubagentMessage(fromAgentId, toAgentId, operation, text, overrides) {
-	return {
-		fromAgentId,
-		toAgentId,
-		operation,
-		text,
-		inFlightLimit: overrides?.inFlightLimit ?? 4,
-		byteLimit: overrides?.byteLimit ?? 16384,
-		deadline: overrides?.deadline ?? Date.now() + 3e5
-	};
-}
-//#endregion
-//#region ../../packages/agent-core/src/session/subagent-capability.ts
-/**
-* Subagent capability modes and their tool-set policy.
-*
-* Capability modes (read-only / read-write / execute / all): a mode is
-* enforced at the tool level, not just by prompting. `all` keeps the profile's
-* full tool set; stricter modes strip it down to the tools the mode permits.
-*
-* Tool classification is by name; the sets live in `#/tools/tool-catalog`
-* (shared with the permission policies) so a new tool is classified once.
-* Unknown tool names are kept (a future tool should fail open rather than
-* being silently stripped from a read-only child).
-*/
-const KNOWN_TOOL_SETS = [
-	READ_TOOLS,
-	WRITE_TOOLS,
-	EXECUTE_TOOLS,
-	NESTING_TOOLS,
-	CORE_TOOLS
-];
-/**
-* Filter an active tool-name list down to what `mode` permits. `all` returns
-* the input unchanged. Unknown names are preserved.
-*/
-function filterToolsForCapability(activeTools, mode) {
-	if (mode === void 0 || mode === "all") return [...activeTools];
-	const allowed = mode === "read-only" ? union(READ_TOOLS, CORE_TOOLS) : mode === "read-write" ? union(READ_TOOLS, WRITE_TOOLS, CORE_TOOLS) : union(READ_TOOLS, WRITE_TOOLS, EXECUTE_TOOLS, CORE_TOOLS);
-	return activeTools.filter((name) => {
-		if (name.startsWith("mcp__")) return false;
-		return allowed.has(name) || !KNOWN_TOOL_SETS.some((set) => set.has(name));
-	});
-}
-function union(...sets) {
-	const out = /* @__PURE__ */ new Set();
-	for (const s of sets) for (const v of s) out.add(v);
-	return out;
-}
-/** Strictness order: earlier = narrower (fewer tools permitted). */
-const CAPABILITY_ORDER = [
-	"read-only",
-	"read-write",
-	"execute",
-	"all"
-];
-/**
-* The narrower of two capability modes (`read-only` < `read-write` < `execute`
-* < `all`). Resume uses this to clamp: a resumed agent keeps the tool set it
-* already has (its profile is not rebuilt), so its contract may be re-applied
-* or tightened, never widened.
-*/
-function narrowerCapability(a, b) {
-	return CAPABILITY_ORDER.indexOf(a) <= CAPABILITY_ORDER.indexOf(b) ? a : b;
-}
-/**
-* Infer the strictest capability mode that already permits `activeTools` — the
-* first mode whose `filterToolsForCapability` pass removes nothing, else `all`.
-*
-* Used when resuming a session recorded before `AgentMeta.capabilityMode`
-* existed: filtering is pure subtraction, so a tool set that survives
-* `read-only` unchanged is evidence the agent was never granted more than
-* that. The inference can only be too *narrow* (a set that happens to contain
-* only allowed tools), which is the safe direction for a capability clamp.
-*/
-function inferCapabilityFromTools(activeTools) {
-	for (const mode of CAPABILITY_ORDER) {
-		if (mode === "all") break;
-		if (filterToolsForCapability(activeTools, mode).length === activeTools.length) return mode;
-	}
-	return "all";
-}
 //#endregion
 //#region ../../packages/agent-core/src/session/summary-continuation.md
 var summary_continuation_default = "Your previous response was too brief. Please provide a more comprehensive summary that includes:\n\n1. Specific technical details and implementations\n2. Detailed findings and analysis\n3. All important information that the parent agent should know";
@@ -111127,6 +111395,14 @@ const SUMMARY_CONTINUATION_ATTEMPTS = 1;
 * that was too short consumed the only delivery window, so a message queued a
 * few milliseconds later was destroyed at run end while the parent still held
 * an "accepted" acknowledgement.
+*
+* Scope: this budget bounds the MAILBOX path only — a message that has to wait
+* for a turn start, and therefore only ever costs a delivery turn. A mid-run
+* `steer` (including the foreground→background handoff, where the parent wakes
+* from a blocked Agent call and answers the still-running child) joins the turn
+* that is already running through the steer buffer instead; it is bounded there
+* by DEFAULT_IN_FLIGHT_LIMIT and must not spend delivery turns, because no
+* delivery turn is needed to reach it.
 */
 const MAX_PARENT_MESSAGE_DELIVERY_TURNS = 2;
 const HOOK_TEXT_PREVIEW_LENGTH = 500;
@@ -111157,22 +111433,39 @@ var SessionSubagentHost = class {
 	modelBindings;
 	bus;
 	activeChildren = /* @__PURE__ */ new Map();
-	/** Per-child per-model usage already folded into the parent totals, so a
-	* resumed child's aggregation only adds the delta. */
-	aggregatedChildUsage = /* @__PURE__ */ new WeakMap();
 	/** Per-turn budget (≤4 accepted) for child→parent collaboration requests. */
 	childRequestCounts = /* @__PURE__ */ new Map();
 	/** Dedupe keys seen within the current turn, per child. */
 	childRequestSeen = /* @__PURE__ */ new Map();
 	/**
-	* Parent→child message dedupe keys, per child, for the child's current turn.
-	* A retried send (the parent re-issuing the same directive after a tool
-	* hiccup) must not reach the child twice; asking again in a later turn is a
-	* legitimate re-ask, so the keys are cleared with the child request limits.
+	* Parent→child message dedupe ledger, per child, for the child's current
+	* turn: key → the in-flight message that key stands for. A retried send (the
+	* parent re-issuing the same directive after a tool hiccup) must not reach
+	* the child twice WHILE the first copy is still in flight; once the child has
+	* consumed that copy — the mailbox no longer holds it, or the steer buffer
+	* has flushed it — the key is released, because a re-send then is a fresh
+	* instruction rather than a retry of an undelivered one. Asking again in a
+	* later turn is legitimate too, so the ledger is cleared with the child
+	* request limits.
 	*/
 	parentMessageSeen = /* @__PURE__ */ new Map();
+	/** Profile names of children spawned or resumed through this host, keyed by
+	*  child id. `getProfileName` falls back to it once a child is evicted: the
+	*  Agent tool reads that name to validate the parent's `spawns` whitelist on
+	*  the resume path, and an evicted child has no live config left to read. */
+	childProfiles = /* @__PURE__ */ new Map();
 	/** Agent → childId lookup for child→parent collaboration requests. */
 	childIdByAgent = /* @__PURE__ */ new WeakMap();
+	/**
+	* One-shot "this child submitted a collaboration request" wake-ups, keyed by
+	* child id. The Agent tool registers one when a foreground wait begins — the
+	* parent is parked inside the tool call, so the parent turn has no step
+	* boundary to flush the notification into — and releases it when the wait
+	* ends. `submitChildRequest` resolves it once the request has been steered to
+	* the parent. Without a registration the request keeps the plain
+	* notification path (it waits for the parent's next boundary).
+	*/
+	childRequestWaiters = /* @__PURE__ */ new Map();
 	constructor(session, ownerAgentId, backgroundTaskTimeoutMs, modelBindings, bus) {
 		this.session = session;
 		this.ownerAgentId = ownerAgentId;
@@ -111190,6 +111483,7 @@ var SessionSubagentHost = class {
 			type: "sub",
 			generate: parent.rawGenerate
 		}, void 0, this.ownerAgentId);
+		this.childProfiles.set(id, profile.name);
 		agent.setRlmDepth(parent.getRlmDepth() + 1);
 		agent.setRlmMaxDepth(parent.getRlmMaxDepth());
 		const controller = new AbortController();
@@ -111226,6 +111520,9 @@ var SessionSubagentHost = class {
 		if (metadata.parentAgentId !== this.ownerAgentId) throw new Error(`Agent instance "${agentId}" does not belong to this parent agent`);
 		if (this.activeChildren.has(agentId) || child.turn.hasActiveTurn) throw new Error(`Agent instance "${agentId}" is already running and cannot be resumed concurrently`);
 		const profileName = child.config.profileName ?? "subagent";
+		this.childProfiles.set(agentId, profileName);
+		const whitelist = spawnWhitelistFor(parent);
+		if (whitelist !== void 0 && !whitelist.includes(profileName)) throw new Error(`Subagent profile "${profileName}" is not in the parent profile's spawn whitelist (${whitelist.join(", ")}): agent "${agentId}" cannot be resumed by this parent`);
 		const controller = new AbortController();
 		const unlinkAbortSignal = linkAbortSignal(options.signal, controller);
 		this.activeChildren.set(agentId, {
@@ -111281,10 +111578,19 @@ var SessionSubagentHost = class {
 			child.controller.abort(reason);
 		}
 	}
+	/**
+	* Profile name of one of this host's children, or undefined when the id is
+	* not a child of this owner. Reads the live instance when it is resident and
+	* falls back to the name recorded at spawn/resume: a finished child is
+	* evicted from `session.agents`, and its resumability is then judged from
+	* exactly this call (the Agent tool validates the parent's spawn whitelist
+	* before calling `resume`), so reporting `undefined` for the evicted child
+	* would skip the whitelist instead of consulting it.
+	*/
 	getProfileName(agentId) {
 		const metadata = this.session.metadata.agents[agentId];
 		if (metadata?.type !== "sub" || metadata.parentAgentId !== this.ownerAgentId) return;
-		return this.session.agents.get(agentId)?.config.profileName;
+		return this.session.agents.get(agentId)?.config.profileName ?? this.childProfiles.get(agentId);
 	}
 	/**
 	* Chain a child run's terminal step: release the child's own resources, then
@@ -111302,12 +111608,14 @@ var SessionSubagentHost = class {
 		try {
 			return await run;
 		} finally {
+			child.background.markSessionClosed();
 			terminal.unlinkAbortSignal();
 			await this.releaseChildResourcesBounded(parent, child, terminal.childId);
 			this.activeChildren.delete(terminal.childId);
 			this.childRequestCounts.delete(terminal.childId);
 			this.childRequestSeen.delete(terminal.childId);
 			this.parentMessageSeen.delete(terminal.childId);
+			this.childRequestWaiters.delete(terminal.childId);
 			this.session.removeAgent?.(terminal.childId);
 			if (terminal.childId !== "main") this.session.agents.delete(terminal.childId);
 		}
@@ -111386,7 +111694,11 @@ var SessionSubagentHost = class {
 	* Send a directed message to a subagent owned by this parent. Ownership is
 	* verified against the session metadata before anything is enqueued; a
 	* message addressed to a foreign or unknown agent is refused as
-	* `not_owned`/`not_found`.
+	* `not_owned`/`not_found`, one addressed to a finished child as `not_active`,
+	* and one whose sender is no longer resident in the session as `parent_gone`
+	* — an accepted message must have a live owner that can observe (and act on)
+	* the delivery it was promised, instead of being acknowledged into a bus
+	* whose owning turn has already ended.
 	*
 	* `steer` redirects a running child without disturbing its in-flight tools;
 	* `interject` does the same but additionally interrupts the tool batch in
@@ -111399,6 +111711,7 @@ var SessionSubagentHost = class {
 		const child = this.session.agents.get(toAgentId);
 		const record = this.activeChildren.get(toAgentId);
 		if (child === void 0 || record === void 0) return { status: "not_active" };
+		if (this.session.agents.get(this.ownerAgentId) === void 0) return { status: "parent_gone" };
 		const message = buildSubagentMessage(this.ownerAgentId, toAgentId, operation === "queue" ? "queue" : "steer", text, overrides);
 		const byteLimit = overrides?.byteLimit ?? 16384;
 		if (subagentMessageBytes(text) > byteLimit) return {
@@ -111407,14 +111720,19 @@ var SessionSubagentHost = class {
 		};
 		let seen = this.parentMessageSeen.get(toAgentId);
 		if (seen === void 0) {
-			seen = /* @__PURE__ */ new Set();
+			seen = /* @__PURE__ */ new Map();
 			this.parentMessageSeen.set(toAgentId, seen);
 		}
 		const dedupeKey = `${operation}\n${text}`;
-		if (seen.has(dedupeKey)) return {
-			status: "accepted",
-			duplicate: true
-		};
+		const pending = seen.get(dedupeKey);
+		if (pending !== void 0) {
+			if (this.parentMessageInFlight(child, pending)) return {
+				status: "accepted",
+				duplicate: true,
+				...pending.kind === "mailbox" ? { messageId: pending.messageId } : {}
+			};
+			seen.delete(dedupeKey);
+		}
 		if ((operation === "steer" || operation === "interject") && !record.structured && child.turn.hasActiveTurn && child.turn.steerQueueLength < 4) {
 			child.turn.steer([{
 				type: "text",
@@ -111423,22 +111741,44 @@ var SessionSubagentHost = class {
 				kind: "system_trigger",
 				name: operation === "interject" ? "parent_interject" : "parent_message"
 			}, operation === "interject" ? { interrupt: true } : void 0);
-			seen.add(dedupeKey);
+			seen.set(dedupeKey, {
+				kind: "steer",
+				bufferLengthAtSend: child.turn.steerQueueLength
+			});
 			return {
 				status: "accepted",
 				delivery: operation === "interject" ? "interjected" : "mid-run"
 			};
 		}
 		const out = this.bus.send(message);
-		if (out.status === "accepted") seen.add(dedupeKey);
+		if (out.status === "accepted" && out.messageId !== void 0) seen.set(dedupeKey, {
+			kind: "mailbox",
+			messageId: out.messageId
+		});
 		return {
 			status: out.status,
 			reason: out.reason,
 			delivery: out.status === "accepted" ? "queued" : void 0,
-			queueDepth: out.queueDepth
+			queueDepth: out.queueDepth,
+			messageId: out.messageId,
+			downgrade: operation === "interject" && out.status === "accepted" ? record.structured ? "structured" : child.turn.hasActiveTurn ? "steer-buffer-full" : "idle" : void 0
 		};
 	}
 	/**
+	* Whether the message a dedupe key stands for is still undelivered. Mailbox
+	* copies are judged by the bus (which also reclaims expired mail, so a
+	* message that can never arrive reads as consumed); steered copies by the
+	* turn's buffer: a buffer shorter than the length recorded at acceptance was
+	* flushed — flushes drain the whole buffer, so the copy rode along. A full
+	* buffer that flushed and was refilled reads as still in flight (the count is
+	* back at or above the mark); that errs toward deduplicating, never toward
+	* delivering the same directive twice.
+	*/
+	parentMessageInFlight(child, pending) {
+		if (pending.kind === "mailbox") return this.bus.holdsMessage(pending.messageId);
+		return child.turn.hasActiveTurn && child.turn.steerQueueLength >= pending.bufferLengthAtSend;
+	}
+	/**
 	* Child→parent collaboration request (B-scheme). A subagent can proactively
 	* contact its owner mid-run: `info` (ask for context/clarification),
 	* `handoff` (ask to pass the work to another capability — described as a
@@ -111451,6 +111791,8 @@ var SessionSubagentHost = class {
 	submitChildRequest(fromAgent, req) {
 		const fromChildId = this.childIdByAgent.get(fromAgent);
 		if (fromChildId === void 0 || !this.activeChildren.has(fromChildId)) return { status: "not_active" };
+		const parent = this.session.agents.get(this.ownerAgentId);
+		if (parent === void 0) return { status: "parent_gone" };
 		const count = this.childRequestCounts.get(fromChildId) ?? 0;
 		if (count >= 4) return { status: "saturated" };
 		const dedupeKey = `${req.request_type}|${req.needs ?? ""}|${req.message}`;
@@ -111474,7 +111816,7 @@ var SessionSubagentHost = class {
 			req.payload?.evidence !== void 0 && req.payload.evidence.length > 0 ? `evidence: [${req.payload.evidence.join(", ")}]` : void 0,
 			req.payload?.missing !== void 0 && req.payload.missing.length > 0 ? `missing: [${req.payload.missing.join(", ")}]` : void 0
 		].filter((l) => l !== void 0);
-		this.session.agents.get(this.ownerAgentId)?.turn.steer([{
+		parent.turn.steer([{
 			type: "text",
 			text: renderNotificationXml({
 				id: `child_request:${fromChildId}:${Date.now()}`,
@@ -111490,13 +111832,52 @@ var SessionSubagentHost = class {
 			kind: "system_trigger",
 			name: "child_request"
 		});
+		parent.emitEvent({
+			type: "subagent.child_request",
+			subagentId: fromChildId,
+			subagentName: this.getProfileName(fromChildId),
+			requestType: req.request_type,
+			message: req.message,
+			needs: req.needs,
+			expecting: req.payload?.expecting,
+			artifacts: req.payload?.artifacts,
+			evidence: req.payload?.evidence,
+			missing: req.payload?.missing
+		});
+		this.childRequestWaiters.get(fromChildId)?.resolve();
 		return { status: "accepted" };
 	}
+	/**
+	* Register (or reuse) the one-shot wake-up resolved when this child submits
+	* its next accepted collaboration request. Called by the Agent tool when a
+	* foreground wait begins; the returned promise resolves at most once.
+	*/
+	waitForChildRequest(childId) {
+		const existing = this.childRequestWaiters.get(childId);
+		if (existing !== void 0) return existing.promise;
+		let resolve;
+		const promise = new Promise((res) => {
+			resolve = res;
+		});
+		this.childRequestWaiters.set(childId, {
+			promise,
+			resolve
+		});
+		return promise;
+	}
+	/**
+	* Drop a child's wake-up registration (its foreground wait ended). The entry
+	* is deleted rather than kept resolved: the next foreground wait registers a
+	* fresh one-shot signal, so a stale resolution cannot background a later run.
+	*/
+	releaseChildRequestWait(childId) {
+		this.childRequestWaiters.delete(childId);
+	}
 	/** Per-turn budget reset for child→parent collaboration requests. */
 	resetChildRequestLimits(childId) {
 		this.childRequestCounts.set(childId, 0);
 		this.childRequestSeen.set(childId, /* @__PURE__ */ new Set());
-		this.parentMessageSeen.set(childId, /* @__PURE__ */ new Set());
+		this.parentMessageSeen.set(childId, /* @__PURE__ */ new Map());
 	}
 	resolveProfile(parent, profileName) {
 		const profile = DEFAULT_AGENT_PROFILES[parent.config.profileName ?? "agent"]?.subagents?.[profileName] ?? DEFAULT_AGENT_PROFILES["agent"]?.subagents?.[profileName];
@@ -111587,20 +111968,23 @@ var SessionSubagentHost = class {
 			}
 			const usage = child.usage.data().total;
 			const childByModel = child.usage.data().byModel ?? {};
-			const previous = this.aggregatedChildUsage.get(child) ?? {};
+			const ledger = foldedChildUsageFor(this.session);
+			const previous = ledger.get(childId) ?? {};
+			const deltas = {};
 			for (const [model, childUsage] of Object.entries(childByModel)) {
 				const delta = previous[model] === void 0 ? childUsage : subtractUsage(childUsage, previous[model]);
-				if (isZeroUsage(delta)) continue;
-				try {
-					parent.usage.record(model, delta, "session");
-				} catch (error) {
-					parent.log.warn("Failed to aggregate subagent usage", {
-						model,
-						error: String(error)
-					});
-				}
+				if (!isZeroUsage(delta)) deltas[model] = delta;
+			}
+			const foldTarget = this.usageFoldTarget(parent);
+			for (const [model, delta] of Object.entries(deltas)) try {
+				foldTarget.usage.record(model, delta, "session");
+			} catch (error) {
+				parent.log.warn("Failed to aggregate subagent usage", {
+					model,
+					error: String(error)
+				});
 			}
-			this.aggregatedChildUsage.set(child, childByModel);
+			ledger.set(childId, childByModel);
 			const findingsBlock = [formatFindingsBlock(getFindingsFromStore(child.tools.toolStore)), formatArchFindingsBlock(getArchFindingsFromStore(child.tools.toolStore))].join("");
 			const durationMs = Date.now() - startedAt;
 			const toolCallCount = countAssistantToolCalls(child);
@@ -111632,9 +112016,36 @@ var SessionSubagentHost = class {
 				error: message,
 				usage: child.usage.data().total
 			});
+			this.triggerSubagentStop(parent, profileName, lastAssistantText$1(child), message);
 			throw error;
 		}
 	}
+	/**
+	* Where a finished child's usage delta is folded. Normally its direct parent.
+	* When that parent has been evicted from the session (a background
+	* grandchild can outlive the child that spawned it), its recorder is no
+	* longer part of any live rollup — the fold would land on an agent nobody
+	* reads again — so the delta goes to the nearest RESIDENT ancestor instead,
+	* and the chain keeps rolling up through finished intermediates. The delta
+	* is recorded exactly once, at that target: the ledger that guards against
+	* re-folding is keyed by the CHILD, so a later resume of the intermediate
+	* can never fold the amount a second time (its own total never received it).
+	*
+	* The direct parent is the fallback when nothing in the chain is resident
+	* (session teardown): recording there is what happened before this walk, and
+	* no live reader remains to disagree.
+	*/
+	usageFoldTarget(parent) {
+		const resident = this.session.agents.get(parent.agentId);
+		if (resident !== void 0) return resident;
+		let ancestorId = this.session.metadata.agents[parent.agentId]?.parentAgentId ?? null;
+		while (ancestorId !== null) {
+			const ancestor = this.session.agents.get(ancestorId);
+			if (ancestor !== void 0) return ancestor;
+			ancestorId = this.session.metadata.agents[ancestorId]?.parentAgentId ?? null;
+		}
+		return parent;
+	}
 	async configureChild(parent, child, profile, childId, capabilityMode) {
 		const binding = this.resolveModelBinding(profile.name);
 		const modelAlias = this.resolveValidModelAlias(parent, binding);
@@ -111705,16 +112116,54 @@ var SessionSubagentHost = class {
 			}
 		});
 	}
-	triggerSubagentStop(parent, profileName, result) {
+	/**
+	* Fire the SubagentStop hook for a child run that has reached a terminal
+	* state. Called on the success path and from the failure/cancel handler, so
+	* the event means "this child run ended", never just "it succeeded"; a failed
+	* run adds the `error` field (and `response` still carries whatever the child
+	* had produced) while a successful one keeps the original payload shape.
+	*/
+	triggerSubagentStop(parent, profileName, result, error) {
 		parent.hooks?.fireAndForgetTrigger("SubagentStop", {
 			matcherValue: profileName,
 			inputData: {
 				agentName: profileName,
-				response: result.slice(0, HOOK_TEXT_PREVIEW_LENGTH)
+				response: result.slice(0, HOOK_TEXT_PREVIEW_LENGTH),
+				...error !== void 0 ? { error: error.slice(0, HOOK_TEXT_PREVIEW_LENGTH) } : {}
 			}
 		});
 	}
 };
+/**
+* How much of each child's cumulative usage has already been folded into its
+* owner's session totals, keyed by the child's stable agent id. Session-scoped
+* and module-level: an Agent-instance key cannot survive the resume path
+* (`ensureAgent` re-hydrates a new instance whose replayed recorder holds the
+* full history, which was then folded a second time), and a host-level map
+* cannot survive an owner being re-instantiated, which would reopen the same
+* hole one level down.
+*/
+const foldedChildUsageBySession = /* @__PURE__ */ new WeakMap();
+function foldedChildUsageFor(session) {
+	let ledger = foldedChildUsageBySession.get(session);
+	if (ledger === void 0) {
+		ledger = /* @__PURE__ */ new Map();
+		foldedChildUsageBySession.set(session, ledger);
+	}
+	return ledger;
+}
+/**
+* The `spawns` whitelist of the given agent's own profile — the same source of
+* truth the Agent tool derives its `allowedSpawns` from (agent/tool/index.ts:
+* `DEFAULT_AGENT_PROFILES[agent.config.profileName ?? 'agent']?.spawns`).
+* Named here because the resume path must enforce the identical rule from
+* inside the host: the Agent tool resolves a resumed child's profile through
+* `getProfileName`, which historically could not see an evicted child and so
+* skipped the check entirely.
+*/
+function spawnWhitelistFor(agent) {
+	return DEFAULT_AGENT_PROFILES[agent.config.profileName ?? "agent"]?.spawns;
+}
 /** Element-wise subtraction clamped at zero (usage can never go negative). */
 function subtractUsage(current, previous) {
 	return {
@@ -111829,6 +112278,14 @@ var Session$1 = class {
 	/** Session-level parent→child message bus shared by every subagent host. */
 	subagentMessages = new SubagentMessageBus();
 	agentIdCounter = 0;
+	/**
+	* Every BackgroundManager this session created for one of its agents, held
+	* through a `WeakRef` so `close()` can still latch the manager of a finished
+	* (evicted) subagent — see `trackBackgroundManager`. Weak on purpose: a
+	* strong reference would pin each manager for the session's lifetime, the
+	* leak `removeAgent` exists to avoid.
+	*/
+	backgroundManagers = /* @__PURE__ */ new Set();
 	skillsReady;
 	mcpReady;
 	metadata = {
@@ -111897,7 +112354,6 @@ var Session$1 = class {
 			}
 		});
 		this.disposables.add("background-pending", async () => {
-			stopAllPendingBackgroundTasks(this.options.id);
 			await this.stopBackgroundTasksOnExit();
 		});
 		this.disposables.add("cron", async () => {
@@ -111954,6 +112410,7 @@ var Session$1 = class {
 		return { warning: resumeWarning };
 	}
 	async close() {
+		for (const manager of this.liveBackgroundManagers()) manager.markSessionClosed();
 		const main = this.agents.get("main");
 		if (main !== void 0) {
 			const recap = main.sessionMemory.getSessionSummary();
@@ -111975,15 +112432,39 @@ var Session$1 = class {
 		}
 		if (disposeError !== null) throw disposeError;
 	}
+	/**
+	* Per-agent background-task policy for session exit, run from the
+	* `background-pending` close-out step — i.e. after `close()` cancelled the
+	* agent turns.
+	*
+	* `keepAliveOnExit` now protects bash processes only. They are real OS
+	* processes whose work (`npm install`, a dev server) is still meaningful to
+	* the user after the session is gone, so the true path leaves them running.
+	* Agent tasks are not processes — they are coroutines over a subagent turn
+	* that `close()` has already cancelled and can never finish on their own — so
+	* they are stopped in both paths: via `stopAll` when keepAlive is off (which
+	* covers every task, so the agent-only stop is not repeated on top of it),
+	* and via `stopAgentTasks` when keepAlive is on.
+	*
+	* The sweep runs over `liveBackgroundManagers()`, not just `this.agents`: a
+	* finished subagent is evicted while agent-class tasks it registered may
+	* still be running, and those are exactly the tasks that would otherwise be
+	* stranded into a later `failed` notification that advertises `Agent(resume=)`.
+	*/
 	async stopBackgroundTasksOnExit() {
-		if (resolveConfigValue({
+		const keepAliveOnExit = resolveConfigValue({
 			env: process.env,
 			envKey: BACKGROUND_KEEP_ALIVE_ON_EXIT_ENV,
 			configValue: this.options.background?.keepAliveOnExit,
 			defaultValue: true,
 			parseEnv: parseBooleanEnv
-		})) return;
-		await Promise.all(Array.from(this.agents.values(), (agent) => agent.background.stopAll("Session closed")));
+		});
+		const managers = this.liveBackgroundManagers();
+		if (!keepAliveOnExit) {
+			await Promise.all(managers.map((manager) => manager.stopAll("Session closed")));
+			return;
+		}
+		await Promise.all(managers.map((manager) => manager.stopAgentTasks("Session closed")));
 	}
 	async createAgent(config, profile, parentAgentId) {
 		await this.skillsReady;
@@ -112251,7 +112732,7 @@ var Session$1 = class {
 	instantiateAgent(id, homedir, type, config = {}, parentAgentId = null) {
 		const parentAgent = parentAgentId !== null ? this.agents.get(parentAgentId) : void 0;
 		const cwd = parentAgent?.config.cwd ?? this.options.jian.getcwd();
-		return new Agent({
+		const agent = new Agent({
 			...config,
 			agentId: id,
 			type,
@@ -112274,6 +112755,48 @@ var Session$1 = class {
 			pluginSessionStarts: type === "main" ? this.options.pluginSessionStarts : void 0,
 			resolveRuntimeSystemPrompt: (basePrompt) => this.effectiveSystemPrompt(basePrompt)
 		});
+		this.trackBackgroundManager(agent.background);
+		return agent;
+	}
+	/**
+	* Remember a BackgroundManager so `close()` can latch it shut (see
+	* BackgroundManager.markSessionClosed) even after its agent was evicted from
+	* `agents`. A manager `close()` cannot reach would deliver a terminal task
+	* notification into the closing session — the ghost turn the latch exists to
+	* prevent.
+	*
+	* The reference is weak on purpose: a strong one would pin every manager this
+	* session ever created for the session's whole lifetime, exactly the leak
+	* `removeAgent` avoids for finished subagents. A manager the GC has reclaimed
+	* cannot notify anyone, so skipping it is correct. Dead entries are pruned
+	* here and again in `close()`.
+	*/
+	trackBackgroundManager(manager) {
+		for (const ref of this.backgroundManagers) if (ref.deref() === void 0) this.backgroundManagers.delete(ref);
+		this.backgroundManagers.add(new WeakRef(manager));
+	}
+	/**
+	* Every BackgroundManager this session created that is still alive. Agents
+	* are registered at construction (`instantiateAgent` →
+	* `trackBackgroundManager`), so resident agents' managers are included and
+	* this is the one enumeration both `close()`'s latch and
+	* `stopBackgroundTasksOnExit`'s stop sweep run over — an evicted subagent's
+	* manager stays reachable here after the agent left `agents`.
+	*
+	* An entry the GC already reclaimed is pruned: nothing can notify through,
+	* or hold tasks in, a manager that no longer exists.
+	*/
+	liveBackgroundManagers() {
+		const live = [];
+		for (const ref of this.backgroundManagers) {
+			const manager = ref.deref();
+			if (manager === void 0) {
+				this.backgroundManagers.delete(ref);
+				continue;
+			}
+			live.push(manager);
+		}
+		return live;
 	}
 	permissionOptions(parentAgentId, input) {
 		if (parentAgentId === null) return {
@@ -128961,15 +129484,17 @@ var ScreamCore = class {
 	}
 	async closeSession({ sessionId }) {
 		const session = this.sessions.get(sessionId);
-		if (session) {
+		if (session) try {
 			await session.close();
+		} finally {
 			this.sessions.delete(sessionId);
 		}
 	}
 	async deleteSession({ sessionId }) {
 		const active = this.sessions.get(sessionId);
-		if (active) {
+		if (active) try {
 			await active.close();
+		} finally {
 			this.sessions.delete(sessionId);
 		}
 		await this.sessionStore.delete(sessionId);
@@ -130252,26 +130777,35 @@ var SDKRpcClient = class {
 			skillName: input.skillName
 		});
 	}
+	/**
+	* Background tasks are registered per agent: a subagent's Bash/Agent task
+	* lives in that subagent's own registry, so `agentId` selects whose registry
+	* answers. Omitted ⇒ the interactive agent (main), which is the pre-existing
+	* behavior. An id the session does not know fails with AGENT_NOT_FOUND —
+	* an owner whose live instance has already been dropped is gone, not empty.
+	*/
 	async listBackgroundTasks(input) {
 		return (await this.getRpc()).getBackground({
 			sessionId: input.sessionId,
-			agentId: this.interactiveAgentId,
+			agentId: input.agentId ?? this.interactiveAgentId,
 			activeOnly: input.activeOnly,
 			limit: input.limit
 		});
 	}
+	/** See {@link listBackgroundTasks} for the `agentId` contract. */
 	async getBackgroundTaskOutput(input) {
 		return (await this.getRpc()).getBackgroundOutput({
 			sessionId: input.sessionId,
-			agentId: this.interactiveAgentId,
+			agentId: input.agentId ?? this.interactiveAgentId,
 			taskId: input.taskId,
 			tail: input.tail
 		});
 	}
+	/** See {@link listBackgroundTasks} for the `agentId` contract. */
 	async getBackgroundTaskOutputPath(input) {
 		return (await this.getRpc()).getBackgroundOutputPath({
 			sessionId: input.sessionId,
-			agentId: this.interactiveAgentId,
+			agentId: input.agentId ?? this.interactiveAgentId,
 			taskId: input.taskId
 		});
 	}
@@ -130296,10 +130830,11 @@ var SDKRpcClient = class {
 			maxDepth: input.maxDepth
 		});
 	}
+	/** See {@link listBackgroundTasks} for the `agentId` contract. */
 	async stopBackgroundTask(input) {
 		return (await this.getRpc()).stopBackground({
 			sessionId: input.sessionId,
-			agentId: this.interactiveAgentId,
+			agentId: input.agentId ?? this.interactiveAgentId,
 			taskId: input.taskId,
 			reason: input.reason
 		});
@@ -130702,20 +131237,26 @@ var Session = class {
 	*
 	* Defaults to all tasks (including terminal/lost). Pass
 	* `{ activeOnly: true }` to filter to non-terminal entries.
+	*
+	* `agentId` selects whose registry answers — a subagent's task lives in
+	* that subagent's own registry. Omitted ⇒ the interactive agent (main);
+	* an unknown id fails with AGENT_NOT_FOUND.
 	*/
 	async listBackgroundTasks(options = {}) {
 		this.ensureOpen();
 		return this.rpc.listBackgroundTasks({
 			sessionId: this.id,
 			activeOnly: options.activeOnly,
-			limit: options.limit
+			limit: options.limit,
+			agentId: options.agentId
 		});
 	}
 	/**
 	* Read a background task's captured output. Returns the in-memory
 	* ring buffer if available, otherwise falls back to the persisted
 	* `<sessionDir>/tasks/<taskId>/output.log`. `tail` caps the returned
-	* string to that many trailing characters.
+	* string to that many trailing characters. `agentId` selects the owning
+	* agent's registry (default: the interactive agent).
 	*/
 	async getBackgroundTaskOutput(taskId, options = {}) {
 		this.ensureOpen();
@@ -130723,7 +131264,8 @@ var Session = class {
 		return this.rpc.getBackgroundTaskOutput({
 			sessionId: this.id,
 			taskId: trimmedTaskId,
-			tail: options.tail
+			tail: options.tail,
+			agentId: options.agentId
 		});
 	}
 	/**
@@ -130731,7 +131273,9 @@ var Session = class {
 	* grace period (handled by the core BPM); subscribers receive a
 	* `background.task.terminated` event when the kill settles. Calls
 	* for unknown or already-terminal task ids are no-ops at the core
-	* level — this method does not throw in those cases.
+	* level — this method does not throw in those cases. `agentId` selects
+	* the owning agent's registry (default: the interactive agent); stopping
+	* a subagent's task through the main registry would be such a no-op.
 	*/
 	/**
 	* Enables or disables the /rlm persistent-python mode. When enabled, the
@@ -130775,20 +131319,23 @@ var Session = class {
 		await this.rpc.stopBackgroundTask({
 			sessionId: this.id,
 			taskId: trimmedTaskId,
-			reason: options.reason
+			reason: options.reason,
+			agentId: options.agentId
 		});
 	}
 	/**
 	* Return the absolute path to the task's `output.log` on disk, or
 	* `undefined` when the task is unknown or has no persisted output.
-	* Callers can hand the path to an external pager.
+	* Callers can hand the path to an external pager. `agentId` selects the
+	* owning agent's registry (default: the interactive agent).
 	*/
-	async getBackgroundTaskOutputPath(taskId) {
+	async getBackgroundTaskOutputPath(taskId, options = {}) {
 		this.ensureOpen();
 		const trimmedTaskId = normalizeRequiredString(taskId, "Task id cannot be empty", ErrorCodes.BACKGROUND_TASK_ID_EMPTY);
 		return this.rpc.getBackgroundTaskOutputPath({
 			sessionId: this.id,
-			taskId: trimmedTaskId
+			taskId: trimmedTaskId,
+			agentId: options.agentId
 		});
 	}
 	async listMcpServers() {
@@ -138753,7 +139300,7 @@ async function guidedGoalSetup(host) {
 		host.showNotice(t("goal.storm_breaker"), t("goal.conflict_loop"));
 		return;
 	}
-	const { TextInputDialogComponent } = await import("./text-input-dialog-DZoGkbYZ.mjs");
+	const { TextInputDialogComponent } = await import("./text-input-dialog-b-TqTP2z.mjs");
 	const initialDesc = await promptText(host, TextInputDialogComponent, {
 		title: t("goal.setup_title_initial"),
 		subtitle: t("goal.setup_desc_hint"),
@@ -138774,7 +139321,7 @@ async function guidedGoalSetup(host) {
 	await showGoalConfigWizard(host, session, confirmed.trim() || objective, false);
 }
 async function showGoalConfigWizard(host, session, objective, replace) {
-	const { TextInputDialogComponent } = await import("./text-input-dialog-DZoGkbYZ.mjs");
+	const { TextInputDialogComponent } = await import("./text-input-dialog-b-TqTP2z.mjs");
 	const turnInput = await promptNumber(host, TextInputDialogComponent, {
 		title: t("goal.wizard_title", { objective }),
 		subtitle: t("goal.budget_turns_hint"),
@@ -140418,11 +140965,21 @@ var ActivityGroupComponent = class extends Container {
 		});
 	}
 	/**
-	* Expanded state: the whole timeline in order. Rows are budgeted for the block
+	* Expanded state, split by whether the block is still running. A running block
+	* anchors its window on the newest steps — the part of the timeline still
+	* moving — while a settled block keeps the window that starts at the first
+	* step. Both spend one shared row budget for the block as a whole.
+	*/
+	buildExpandedRows(width) {
+		if (this.running) this.buildExpandedRowsTail(width);
+		else this.buildExpandedRowsHead(width);
+	}
+	/**
+	* Settled state: the whole timeline in order. Rows are budgeted for the block
 	* as a whole, so a turn with dozens of steps cannot expand into hundreds of
 	* rows; whatever does not fit is summarised in one row at the end.
 	*/
-	buildExpandedRows(width) {
+	buildExpandedRowsHead(width) {
 		this.bodyContainer.addChild(new Text(TREE_PIPE_ROW, 0, 0));
 		let used = 1;
 		let hidden = 0;
@@ -140443,6 +141000,39 @@ var ActivityGroupComponent = class extends Container {
 			this.bodyContainer.addChild(new Text(`${BRANCH_PIPE}${BODY_TEXT_INDENT}${chalk.dim(summary)}`, 0, 0));
 		}
 	}
+	/**
+	* Running state: the newest steps, still in chronological order so the tail
+	* reads top-down, with the older steps that no longer fit counted in one row
+	* above them. The budget is spent from the newest end backwards and the newest
+	* step always renders, mirroring the head-anchored loop's rule that the first
+	* step always renders — a single oversized step cannot leave the block
+	* expanded-but-empty in either direction. The end-of-tree summary of the
+	* settled loop is structurally unreachable here: a running block never keeps
+	* rows below its newest step, so there is nothing at the end to count.
+	*/
+	buildExpandedRowsTail(width) {
+		const visible = [];
+		let used = 1;
+		let hidden = 0;
+		for (let index = this.segments.length - 1; index >= 0; index -= 1) {
+			const segment = this.segments[index];
+			const isLastStep = index === this.segments.length - 1;
+			const rows = this.segmentRows(segment, width, isLastStep);
+			const budget = 60 - (isLastStep ? 0 : 1);
+			if (!isLastStep && used + rows.cost > budget) {
+				hidden = index + 1;
+				break;
+			}
+			visible.unshift(...rows.components);
+			used += rows.cost;
+		}
+		this.bodyContainer.addChild(new Text(TREE_PIPE_ROW, 0, 0));
+		if (hidden > 0) {
+			const summary = t("activitygroup.segments_folded_above", { count: String(hidden) });
+			this.bodyContainer.addChild(new Text(`${BRANCH_PIPE}${BODY_TEXT_INDENT}${chalk.dim(summary)}`, 0, 0));
+		}
+		for (const component of visible) this.bodyContainer.addChild(component);
+	}
 	/** Renders one step of the timeline: its branch row plus its own body rows. */
 	segmentRows(segment, width, isLast) {
 		if (segment.kind === "tool") {
@@ -143229,6 +143819,15 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 	* background agent — including lost ones — as `✓ Completed`.
 	*/
 	backgroundTaskTerminalPhase;
+	/**
+	* True when a foreground subagent was handed to the background manager
+	* mid-run (the request-leg / timeout handoff). The Agent tool still returns
+	* a normal result — its body carries `status: backgrounded` — which the
+	* result-based derivation would otherwise read as `done`; this mark keeps
+	* the card on `backgrounded` until a real terminal status
+	* (`backgroundTaskTerminalPhase`) arrives, which still wins.
+	*/
+	subagentBackgrounded = false;
 	subagentContextTokens;
 	subagentUsage;
 	/** Latest activity (Using X / Used Y) for the running-phase chip. */
@@ -143489,7 +144088,7 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 		const tokens = contextTokens && contextTokens > 0 ? contextTokens : this.subagentUsage === void 0 ? 0 : usageTotal(this.subagentUsage);
 		const latestActivity = computeLatestActivity(this.ongoingSubCalls, this.finishedSubCalls, this.getCombinedSubagentText(), this.workspaceDir, this.subagentPhase === "running" ? this.ongoingSubCalls.size === 0 && this.subagentText === "" : void 0);
 		this.latestActivity = latestActivity;
-		const derivedPhase = this.backgroundTaskTerminalPhase ?? (this.result !== void 0 ? this.result.is_error ? "failed" : "done" : this.subagentPhase);
+		const derivedPhase = this.backgroundTaskTerminalPhase ?? (this.subagentBackgrounded ? "backgrounded" : this.result !== void 0 ? this.result.is_error ? "failed" : "done" : this.subagentPhase);
 		const errorText = this.subagentError ?? (derivedPhase === "failed" ? this.result?.output : void 0);
 		return {
 			toolCallId: this.toolCall.id,
@@ -143692,6 +144291,20 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 		this.notifySnapshotChange();
 	}
 	/**
+	* Marks the run as handed off to the background manager (foreground→
+	* background). Idempotent, and never downgrades a terminal phase: the card
+	* reads `backgrounded` until `setBackgroundTaskTerminalStatus` reports the
+	* real end state.
+	*/
+	setSubagentBackgrounded() {
+		if (this.subagentBackgrounded) return;
+		this.subagentBackgrounded = true;
+		this.headerText.setText(this.buildHeader());
+		this.rebuildContent();
+		this.notifySnapshotChange();
+		this.ui?.requestRender();
+	}
+	/**
 	* Subagent id for the backing AgentTool call, used by routing to find a
 	* tool call's backing subagent when reconciling background task lifecycle
 	* events.
@@ -143891,7 +144504,7 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 		for (const component of components) this.addChild(component);
 	}
 	buildSubagentBlock() {
-		if (this.subagentAgentId === void 0 && this.ongoingSubCalls.size === 0 && this.finishedSubCalls.length === 0 && this.subagentText.length === 0 && this.subagentPhase === void 0 && this.backgroundTaskTerminalPhase === void 0) return;
+		if (this.subagentAgentId === void 0 && this.ongoingSubCalls.size === 0 && this.finishedSubCalls.length === 0 && this.subagentText.length === 0 && this.subagentPhase === void 0 && this.backgroundTaskTerminalPhase === void 0 && !this.subagentBackgrounded) return;
 		if (this.isSingleSubagentView()) {
 			this.buildSingleSubagentBlock();
 			return;
@@ -143972,13 +144585,14 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 		return id.length > 10 ? id.slice(0, 10) + "…" : id;
 	}
 	hasSubagentState() {
-		return this.subagentAgentId !== void 0 || this.ongoingSubCalls.size > 0 || this.finishedSubCalls.length > 0 || this.subToolActivities.size > 0 || this.subagentText.length > 0 || this.subagentThinkingText.length > 0 || this.subagentPhase !== void 0 || this.backgroundTaskTerminalPhase !== void 0;
+		return this.subagentAgentId !== void 0 || this.ongoingSubCalls.size > 0 || this.finishedSubCalls.length > 0 || this.subToolActivities.size > 0 || this.subagentText.length > 0 || this.subagentThinkingText.length > 0 || this.subagentPhase !== void 0 || this.backgroundTaskTerminalPhase !== void 0 || this.subagentBackgrounded;
 	}
 	isSingleSubagentView() {
 		return this.toolCall.name === "Agent" && this.hasSubagentState();
 	}
 	getDerivedSubagentPhase() {
 		if (this.backgroundTaskTerminalPhase !== void 0) return this.backgroundTaskTerminalPhase;
+		if (this.subagentBackgrounded) return "backgrounded";
 		if (this.result !== void 0) return this.result.is_error ? "failed" : "done";
 		return this.subagentPhase;
 	}
@@ -144005,7 +144619,7 @@ var ToolCallComponent = class ToolCallComponent extends CachedContainer {
 			case "done": return chalk.hex(this.colors.success)(t("toolcall.completed"));
 			case "failed": return chalk.hex(this.colors.error)(t("toolcall.failed"));
 			case "running": return chalk.hex(this.colors.primary)(t("toolcall.running"));
-			case "backgrounded": return t("toolcall.bg_running");
+			case "backgrounded": return this.subagentBackgrounded ? chalk.hex(this.colors.warning)(`◐ ${t("toolcall.bg_handed_off")}`) : t("toolcall.bg_running");
 			case "spawning":
 			case void 0: return chalk.hex(this.colors.primary)(t("toolcall.starting"));
 		}