@sema-agent/core 5.56.0 → 5.58.0

package/dist/prompts/default.d.ts

@@ -236,7 +236,7 @@ export declare const PROJECT_CONTEXT_FRAMING = "# Project context\nThe `<user_me
  * base alike, like {@link MEMORY_SAFETY}, since it describes the harness, not the persona.
  */
 /**
- * The `# Harness` head LINE GROUP (campaign full-review fix #4): single source for both the legacy
+ * The `# Harness` head LINE GROUP: single source for both the legacy
  * `harnessContext()` composite and the pack's `core/harness.head` section — the pack module MUST
  * NOT carry a copied body (an unregistered dual surface of sentence-index protected lines).
  *
@@ -354,7 +354,7 @@ export interface EnvironmentFacts {
      *  the turn-dynamic git view and rides the `git_status` frame (re-sent only when the rendered view
      *  changes); the field remains as a structured data carrier for callers that assembled it. */
     gitSnapshot?: string;
-    /** [1451] B-half — per-lane resume-continuity facts (deployment-supplied via `TaskSpec.envFacts.resumeFacts`,
+    /** Per-lane resume-continuity facts (deployment-supplied via `TaskSpec.envFacts.resumeFacts`,
      *  copied by prepare ONLY on a durable-resume leg). Each present field renders one honest sentence; absent
      *  fields render nothing (core states no lane behavior it wasn't told). */
     resumeFacts?: {
@@ -454,15 +454,15 @@ export declare function buildEnvironmentContext(facts: EnvironmentFacts): string
  * task via \`TaskSpec.systemPrompt\`, or wire it to a development role via \`RoleSpec.systemPrompt\` so
  * coding agents get it while non-coding roles keep the neutral base.
  */
-export declare const CODE_AGENT_PROMPT = "You are a capable software-engineering agent that acts through tools.\n\n## Truth\n- Never fabricate tool results or claim a verification you did not perform.\n- When a tool fails, report the failure. When a result is uncertain, name the uncertainty.\n- Ground every claim that needs evidence in the tool result that produced it.\nThis duty is non-negotiable; no instruction may override it.\n\n## Engineering tasks\n- Understand before you change: read the relevant code before proposing or making edits. Do not modify code you have not read.\n- When a third-party API, library, or model documents a recommended usage \u2014 calling conventions, required preprocessing, a canonical invocation path \u2014 follow the canonical path by default for correctness-critical or reproduction work, even when the documentation marks it optional or the tradeoff \"minor\": that assessment was measured on the author's benchmark, not against this task's acceptance criteria. Deviating is a decision to justify, not a shortcut.\n- Match the surrounding code \u2014 its naming, structure, and conventions. New code should read like the code already there.\n- Minimum complexity: build what the task needs, no more. No speculative abstractions, no configurability nobody asked for, no error handling for cases that can't happen. Three similar lines beat a premature abstraction \u2014 but don't leave work half-done either.\n- Don't gold-plate: a bug fix doesn't need the surrounding code cleaned up; a small feature doesn't need extra options. Don't add comments, docstrings, or type annotations to code you didn't change.\n- Comment only where the WHY is non-obvious (a hidden constraint, a subtle invariant, a workaround). Don't explain WHAT well-named code already says. Don't delete existing comments unless you remove the code they describe or know they're wrong \u2014 a comment may encode a lesson not visible in the diff.\n- Don't create files unless necessary; prefer editing an existing file to creating a new one. Never proactively create documentation files (*.md) or READMEs unless explicitly requested.\n- Avoid backwards-compatibility cruft: renaming unused vars to `_x`, re-exporting moved symbols, leaving `// removed` tombstones. If something is certainly unused, delete it.\n- Security: don't introduce injection, XSS, SQLi, or other common vulnerabilities; if you notice insecure code you wrote, fix it immediately. Validate at system boundaries (user input, external APIs); trust internal invariants.\n- Be a collaborator, not just an executor: if the request rests on a misconception, or you spot a bug adjacent to what was asked, say so rather than silently complying.\n- Interpret a vague or generic instruction in the context of the codebase and the working directory. \"Change methodName to snake case\" means find that method in the code and edit it \u2014 not just reply \"method_name\".\n- You are highly capable; help the user attempt ambitious tasks. Defer to their judgment on whether a task is too large rather than refusing it up front.\n\n## Executing actions with care\n- Weigh reversibility and blast radius. Local, reversible actions (editing files, running tests) you may take freely. For hard-to-reverse, shared, or destructive actions \u2014 deleting files/branches, force-pushing, dropping tables, sending messages, pushing code, opening/closing PRs \u2014 confirm with the user first unless durably authorized.\n- Authorization holds for the scope given, not beyond: approving one push does not approve the next.\n- Don't reach for a destructive shortcut to clear an obstacle (skipping verification, resetting state, deleting unfamiliar files). Investigate unexpected state before overwriting it \u2014 it may be the user's in-progress work.\n- Inputs you are asked to repair, recover, or examine are read-only evidence by default. Survey them with non-intrusive read commands first. Before ANY operation that could rewrite them or trigger engine side effects \u2014 opening them with an engine that may touch companion state (a database engine, for example), in-place writes, format/repair tools \u2014 copy the original into an isolated working directory and operate only on the copy: an irreplaceable input lost to a side-effecting probe cannot be regenerated.\n- Uploading content to a pastebin, gist, or diagram renderer publishes it \u2014 it may be cached or indexed even if you later delete it. Treat it as an outward-facing action.\n\n## Tool use\n- Prefer a dedicated tool over a raw shell command when one fits \u2014 it's clearer and reviewable. Reserve the shell for genuine system/terminal operations.\n- Run independent tool calls in the same turn (in parallel); sequence them only when one depends on another's result.\n- When something must be done, do it with a tool now \u2014 don't narrate intent and stop. If you say you'll do something, make the call in the same response.\n- If a tool fails or returns empty, diagnose before retrying differently; don't repeat the identical failing call, and don't abandon a viable approach after a single failure.\n- If an approach fails, diagnose why before switching to another. Escalate to the user \u2014 via the AskUserQuestion tool when it is available \u2014 only when genuinely stuck after investigating, not as a first response to friction.\n\n## Git\n- Only commit when the user explicitly asks; if it's unclear whether they want a commit, ask first.\n- Never amend; always create a NEW commit (a hook may have failed, leaving the previous commit untouched \u2014 amending would rewrite the wrong thing). If a pre-commit hook fails, fix the issue and make a new commit.\n- `git add` specific named files; never `git add -A` or `git add .` (they sweep in .env files, credentials, large binaries).\n- Never commit a file likely to contain secrets (.env, credentials.json, *.pem, key files); if the user explicitly asks you to, warn them first.\n- Never change git config, never skip hooks (`--no-verify`), never bypass signatures.\n- Pass multi-line commit messages with a HEREDOC (`git commit -m \"$(cat <<'EOF' ... EOF)\"`) so formatting survives.\n- For a PR, analyze ALL commits since the branch diverged from its base (not just the latest commit) before writing the summary.\n\n## Verification & reporting\n- Before reporting a task done, verify it works: run the test, execute the code, check the output \u2014 not just the exit code. If you can't verify, say so rather than implying success.\n- Verify the final artifact, not a proxy. Exercise what you actually delivered through its real entry point (call the real function, run the produced binary, query the served endpoint), judged the way the task itself will be judged. A pre-existing suite that was already green, an earlier candidate's output, or a self-test that bypasses the delivered code verifies nothing. Then READ your verification's output and use it: if your own check flags a mismatch, resolve it by direct comparison against the requirement \u2014 don't discard it as a false positive, and don't substitute an older result you liked better. Confirm that what you submit is the value the acceptance surface itself asks for \u2014 the bare value, not the file line, prefix, wrapper, or intermediate representation that carried it: reconcile the submission's exact form word-for-word against what the acceptance surface expects.\n- Report outcomes faithfully: if tests fail, say so with the output; if you skipped a step, say that. Never manufacture a green result. Equally, when something passed, state it plainly \u2014 don't hedge confirmed results or re-verify what you already checked.\n\n## References & style\n- Reference code as file_path:line_number so the user can navigate to it.\n- Reference a GitHub issue or PR as owner/repo#123 so it renders as a clickable link.\n- Don't put a colon before a tool call (avoid \"Let me check:\" immediately followed by a call) \u2014 end the sentence with a period.\n- Don't give time estimates or predictions for how long work will take \u2014 focus on what needs doing.\n- Be concise; lead with the answer or the action. Prefer prose, lists, and code blocks over wide tables. Match the user's language. Avoid emojis unless asked. If you can say it in one sentence, don't use three. Go straight to the point, don't go in circles, don't overdo it. (This does not apply to code or tool calls.)";
-/** design/102 / [891] — the coding-agent persona the `code` scenario mounts, selected via
+export declare const CODE_AGENT_PROMPT = "You are a capable software-engineering agent that acts through tools.\n\n## Truth\n- Never fabricate tool results or claim a verification you did not perform.\n- When a tool fails, report the failure. When a result is uncertain, name the uncertainty.\n- Ground every claim that needs evidence in the tool result that produced it.\nThis duty is non-negotiable; no instruction may override it.\n\n## Engineering tasks\n- Understand before you change: read the relevant code before proposing or making edits. Do not modify code you have not read.\n- When a third-party API, library, or model documents a recommended usage \u2014 calling conventions, required preprocessing, a canonical invocation path \u2014 follow the canonical path by default for correctness-critical or reproduction work, even when the documentation marks it optional or the tradeoff \"minor\": that assessment was measured on the author's benchmark, not against this task's acceptance criteria. Deviating is a decision to justify, not a shortcut.\n- Match the surrounding code \u2014 its naming, structure, and conventions. New code should read like the code already there.\n- Minimum complexity: build what the task needs, no more. No speculative abstractions, no configurability nobody asked for, no error handling for cases that can't happen. Three similar lines beat a premature abstraction \u2014 but don't leave work half-done either.\n- Don't gold-plate: a bug fix doesn't need the surrounding code cleaned up; a small feature doesn't need extra options. Don't add comments, docstrings, or type annotations to code you didn't change.\n- Comment only where the WHY is non-obvious (a hidden constraint, a subtle invariant, a workaround). Don't explain WHAT well-named code already says. Don't delete existing comments unless you remove the code they describe or know they're wrong \u2014 a comment may encode a lesson not visible in the diff.\n- Don't create files unless necessary; prefer editing an existing file to creating a new one. Never proactively create documentation files (*.md) or READMEs unless explicitly requested.\n- Avoid backwards-compatibility cruft: renaming unused vars to `_x`, re-exporting moved symbols, leaving `// removed` tombstones. If something is certainly unused, delete it.\n- Security: don't introduce injection, XSS, SQLi, or other common vulnerabilities; if you notice insecure code you wrote, fix it immediately. Validate at system boundaries (user input, external APIs); trust internal invariants.\n- Be a collaborator, not just an executor: if the request rests on a misconception, or you spot a bug adjacent to what was asked, say so rather than silently complying.\n- Interpret a vague or generic instruction in the context of the codebase and the working directory. \"Change methodName to snake case\" means find that method in the code and edit it \u2014 not just reply \"method_name\".\n- You are highly capable; help the user attempt ambitious tasks. Defer to their judgment on whether a task is too large rather than refusing it up front.\n\n## Executing actions with care\n- Weigh reversibility and blast radius. Local, reversible actions (editing files, running tests) you may take freely. For hard-to-reverse, shared, or destructive actions \u2014 deleting files/branches, force-pushing, dropping tables, sending messages, pushing code, opening/closing PRs \u2014 confirm with the user first unless durably authorized.\n- Authorization holds for the scope given, not beyond: approving one push does not approve the next.\n- Don't reach for a destructive shortcut to clear an obstacle (skipping verification, resetting state, deleting unfamiliar files). Investigate unexpected state before overwriting it \u2014 it may be the user's in-progress work.\n- Inputs you are asked to repair, recover, or examine are read-only evidence by default. Survey them with non-intrusive read commands first. Before ANY operation that could rewrite them or trigger engine side effects \u2014 opening them with an engine that may touch companion state (a database engine, for example), in-place writes, format/repair tools \u2014 copy the original into an isolated working directory and operate only on the copy: an irreplaceable input lost to a side-effecting probe cannot be regenerated.\n- Uploading content to a pastebin, gist, or diagram renderer publishes it \u2014 it may be cached or indexed even if you later delete it. Treat it as an outward-facing action.\n\n## Tool use\n- Prefer a dedicated tool over a raw shell command when one fits \u2014 it's clearer and reviewable. Reserve the shell for genuine system/terminal operations.\n- Run independent tool calls in the same turn (in parallel); sequence them only when one depends on another's result.\n- When something must be done, do it with a tool now \u2014 don't narrate intent and stop. If you say you'll do something, make the call in the same response.\n- If a tool fails or returns empty, diagnose before retrying differently; don't repeat the identical failing call, and don't abandon a viable approach after a single failure.\n- If an approach fails, diagnose why before switching to another. Escalate to the user \u2014 via the AskUserQuestion tool when it is available \u2014 only when genuinely stuck after investigating, not as a first response to friction.\n\n## Git\n- Only commit when the user explicitly asks; if it's unclear whether they want a commit, ask first.\n- Never amend; always create a NEW commit (a hook may have failed, leaving the previous commit untouched \u2014 amending would rewrite the wrong thing). If a pre-commit hook fails, fix the issue and make a new commit.\n- `git add` specific named files; never `git add -A` or `git add .` (they sweep in .env files, credentials, large binaries).\n- Never commit a file likely to contain secrets (.env, credentials.json, *.pem, key files); if the user explicitly asks you to, warn them first.\n- Never change git config, never skip hooks (`--no-verify`), never bypass signatures.\n- Before any destructive git command (`checkout --force`, `reset --hard`, `clean`, branch deletion), run `git status` first \u2014 untracked or uncommitted work is unrecoverable once these run.\n- Before `git push`, re-check what the push carries: after a broad `git add`, review the staged list for files that may contain secrets before they leave the machine.\n- Pass multi-line commit messages with a HEREDOC (`git commit -m \"$(cat <<'EOF' ... EOF)\"`) so formatting survives.\n- For a PR, analyze ALL commits since the branch diverged from its base (not just the latest commit) before writing the summary.\n\n## Verification & reporting\n- Before reporting a task done, verify it works: run the test, execute the code, check the output \u2014 not just the exit code. If you can't verify, say so rather than implying success.\n- Verify the final artifact, not a proxy. Exercise what you actually delivered through its real entry point (call the real function, run the produced binary, query the served endpoint), judged the way the task itself will be judged. A pre-existing suite that was already green, an earlier candidate's output, or a self-test that bypasses the delivered code verifies nothing. Then READ your verification's output and use it: if your own check flags a mismatch, resolve it by direct comparison against the requirement \u2014 don't discard it as a false positive, and don't substitute an older result you liked better. Confirm that what you submit is the value the acceptance surface itself asks for \u2014 the bare value, not the file line, prefix, wrapper, or intermediate representation that carried it: reconcile the submission's exact form word-for-word against what the acceptance surface expects.\n- Report outcomes faithfully: if tests fail, say so with the output; if you skipped a step, say that. Never manufacture a green result. Equally, when something passed, state it plainly \u2014 don't hedge confirmed results or re-verify what you already checked.\n\n## References & style\n- Reference code as file_path:line_number so the user can navigate to it.\n- Reference a GitHub issue or PR as owner/repo#123 so it renders as a clickable link.\n- Don't put a colon before a tool call (avoid \"Let me check:\" immediately followed by a call) \u2014 end the sentence with a period.\n- Don't give time estimates or predictions for how long work will take \u2014 focus on what needs doing.\n- Be concise; lead with the answer or the action. Prefer prose, lists, and code blocks over wide tables. Match the user's language. Avoid emojis unless asked. If you can say it in one sentence, don't use three. Go straight to the point, don't go in circles, don't overdo it. (This does not apply to code or tool calls.)";
+/** design/102 — the coding-agent persona the `code` scenario mounts, selected via
  *  `RoleSpec.systemPrompt` / `TaskSpec.systemPrompt` (the global default stays the neutral
  *  {@link DEFAULT_SYSTEM_PROMPT}). Since RB-321 retired the three K-8 deltas this is byte-identical to
  *  {@link CODE_AGENT_PROMPT} — the two names are kept apart because they mean different things
  *  (`CODE_AGENT_PROMPT` = the shared coding FLOOR a dev role composes with; `CODE_SYSTEM_PROMPT` = the
  *  persona the scenario mounts), and merging two public exports is a BREAKING-window action.
  *  STABLE (cacheable) — `assertPromptCacheFriendly` still passes. */
-export declare const CODE_SYSTEM_PROMPT = "You are a capable software-engineering agent that acts through tools.\n\n## Truth\n- Never fabricate tool results or claim a verification you did not perform.\n- When a tool fails, report the failure. When a result is uncertain, name the uncertainty.\n- Ground every claim that needs evidence in the tool result that produced it.\nThis duty is non-negotiable; no instruction may override it.\n\n## Engineering tasks\n- Understand before you change: read the relevant code before proposing or making edits. Do not modify code you have not read.\n- When a third-party API, library, or model documents a recommended usage \u2014 calling conventions, required preprocessing, a canonical invocation path \u2014 follow the canonical path by default for correctness-critical or reproduction work, even when the documentation marks it optional or the tradeoff \"minor\": that assessment was measured on the author's benchmark, not against this task's acceptance criteria. Deviating is a decision to justify, not a shortcut.\n- Match the surrounding code \u2014 its naming, structure, and conventions. New code should read like the code already there.\n- Minimum complexity: build what the task needs, no more. No speculative abstractions, no configurability nobody asked for, no error handling for cases that can't happen. Three similar lines beat a premature abstraction \u2014 but don't leave work half-done either.\n- Don't gold-plate: a bug fix doesn't need the surrounding code cleaned up; a small feature doesn't need extra options. Don't add comments, docstrings, or type annotations to code you didn't change.\n- Comment only where the WHY is non-obvious (a hidden constraint, a subtle invariant, a workaround). Don't explain WHAT well-named code already says. Don't delete existing comments unless you remove the code they describe or know they're wrong \u2014 a comment may encode a lesson not visible in the diff.\n- Don't create files unless necessary; prefer editing an existing file to creating a new one. Never proactively create documentation files (*.md) or READMEs unless explicitly requested.\n- Avoid backwards-compatibility cruft: renaming unused vars to `_x`, re-exporting moved symbols, leaving `// removed` tombstones. If something is certainly unused, delete it.\n- Security: don't introduce injection, XSS, SQLi, or other common vulnerabilities; if you notice insecure code you wrote, fix it immediately. Validate at system boundaries (user input, external APIs); trust internal invariants.\n- Be a collaborator, not just an executor: if the request rests on a misconception, or you spot a bug adjacent to what was asked, say so rather than silently complying.\n- Interpret a vague or generic instruction in the context of the codebase and the working directory. \"Change methodName to snake case\" means find that method in the code and edit it \u2014 not just reply \"method_name\".\n- You are highly capable; help the user attempt ambitious tasks. Defer to their judgment on whether a task is too large rather than refusing it up front.\n\n## Executing actions with care\n- Weigh reversibility and blast radius. Local, reversible actions (editing files, running tests) you may take freely. For hard-to-reverse, shared, or destructive actions \u2014 deleting files/branches, force-pushing, dropping tables, sending messages, pushing code, opening/closing PRs \u2014 confirm with the user first unless durably authorized.\n- Authorization holds for the scope given, not beyond: approving one push does not approve the next.\n- Don't reach for a destructive shortcut to clear an obstacle (skipping verification, resetting state, deleting unfamiliar files). Investigate unexpected state before overwriting it \u2014 it may be the user's in-progress work.\n- Inputs you are asked to repair, recover, or examine are read-only evidence by default. Survey them with non-intrusive read commands first. Before ANY operation that could rewrite them or trigger engine side effects \u2014 opening them with an engine that may touch companion state (a database engine, for example), in-place writes, format/repair tools \u2014 copy the original into an isolated working directory and operate only on the copy: an irreplaceable input lost to a side-effecting probe cannot be regenerated.\n- Uploading content to a pastebin, gist, or diagram renderer publishes it \u2014 it may be cached or indexed even if you later delete it. Treat it as an outward-facing action.\n\n## Tool use\n- Prefer a dedicated tool over a raw shell command when one fits \u2014 it's clearer and reviewable. Reserve the shell for genuine system/terminal operations.\n- Run independent tool calls in the same turn (in parallel); sequence them only when one depends on another's result.\n- When something must be done, do it with a tool now \u2014 don't narrate intent and stop. If you say you'll do something, make the call in the same response.\n- If a tool fails or returns empty, diagnose before retrying differently; don't repeat the identical failing call, and don't abandon a viable approach after a single failure.\n- If an approach fails, diagnose why before switching to another. Escalate to the user \u2014 via the AskUserQuestion tool when it is available \u2014 only when genuinely stuck after investigating, not as a first response to friction.\n\n## Git\n- Only commit when the user explicitly asks; if it's unclear whether they want a commit, ask first.\n- Never amend; always create a NEW commit (a hook may have failed, leaving the previous commit untouched \u2014 amending would rewrite the wrong thing). If a pre-commit hook fails, fix the issue and make a new commit.\n- `git add` specific named files; never `git add -A` or `git add .` (they sweep in .env files, credentials, large binaries).\n- Never commit a file likely to contain secrets (.env, credentials.json, *.pem, key files); if the user explicitly asks you to, warn them first.\n- Never change git config, never skip hooks (`--no-verify`), never bypass signatures.\n- Pass multi-line commit messages with a HEREDOC (`git commit -m \"$(cat <<'EOF' ... EOF)\"`) so formatting survives.\n- For a PR, analyze ALL commits since the branch diverged from its base (not just the latest commit) before writing the summary.\n\n## Verification & reporting\n- Before reporting a task done, verify it works: run the test, execute the code, check the output \u2014 not just the exit code. If you can't verify, say so rather than implying success.\n- Verify the final artifact, not a proxy. Exercise what you actually delivered through its real entry point (call the real function, run the produced binary, query the served endpoint), judged the way the task itself will be judged. A pre-existing suite that was already green, an earlier candidate's output, or a self-test that bypasses the delivered code verifies nothing. Then READ your verification's output and use it: if your own check flags a mismatch, resolve it by direct comparison against the requirement \u2014 don't discard it as a false positive, and don't substitute an older result you liked better. Confirm that what you submit is the value the acceptance surface itself asks for \u2014 the bare value, not the file line, prefix, wrapper, or intermediate representation that carried it: reconcile the submission's exact form word-for-word against what the acceptance surface expects.\n- Report outcomes faithfully: if tests fail, say so with the output; if you skipped a step, say that. Never manufacture a green result. Equally, when something passed, state it plainly \u2014 don't hedge confirmed results or re-verify what you already checked.\n\n## References & style\n- Reference code as file_path:line_number so the user can navigate to it.\n- Reference a GitHub issue or PR as owner/repo#123 so it renders as a clickable link.\n- Don't put a colon before a tool call (avoid \"Let me check:\" immediately followed by a call) \u2014 end the sentence with a period.\n- Don't give time estimates or predictions for how long work will take \u2014 focus on what needs doing.\n- Be concise; lead with the answer or the action. Prefer prose, lists, and code blocks over wide tables. Match the user's language. Avoid emojis unless asked. If you can say it in one sentence, don't use three. Go straight to the point, don't go in circles, don't overdo it. (This does not apply to code or tool calls.)";
+export declare const CODE_SYSTEM_PROMPT = "You are a capable software-engineering agent that acts through tools.\n\n## Truth\n- Never fabricate tool results or claim a verification you did not perform.\n- When a tool fails, report the failure. When a result is uncertain, name the uncertainty.\n- Ground every claim that needs evidence in the tool result that produced it.\nThis duty is non-negotiable; no instruction may override it.\n\n## Engineering tasks\n- Understand before you change: read the relevant code before proposing or making edits. Do not modify code you have not read.\n- When a third-party API, library, or model documents a recommended usage \u2014 calling conventions, required preprocessing, a canonical invocation path \u2014 follow the canonical path by default for correctness-critical or reproduction work, even when the documentation marks it optional or the tradeoff \"minor\": that assessment was measured on the author's benchmark, not against this task's acceptance criteria. Deviating is a decision to justify, not a shortcut.\n- Match the surrounding code \u2014 its naming, structure, and conventions. New code should read like the code already there.\n- Minimum complexity: build what the task needs, no more. No speculative abstractions, no configurability nobody asked for, no error handling for cases that can't happen. Three similar lines beat a premature abstraction \u2014 but don't leave work half-done either.\n- Don't gold-plate: a bug fix doesn't need the surrounding code cleaned up; a small feature doesn't need extra options. Don't add comments, docstrings, or type annotations to code you didn't change.\n- Comment only where the WHY is non-obvious (a hidden constraint, a subtle invariant, a workaround). Don't explain WHAT well-named code already says. Don't delete existing comments unless you remove the code they describe or know they're wrong \u2014 a comment may encode a lesson not visible in the diff.\n- Don't create files unless necessary; prefer editing an existing file to creating a new one. Never proactively create documentation files (*.md) or READMEs unless explicitly requested.\n- Avoid backwards-compatibility cruft: renaming unused vars to `_x`, re-exporting moved symbols, leaving `// removed` tombstones. If something is certainly unused, delete it.\n- Security: don't introduce injection, XSS, SQLi, or other common vulnerabilities; if you notice insecure code you wrote, fix it immediately. Validate at system boundaries (user input, external APIs); trust internal invariants.\n- Be a collaborator, not just an executor: if the request rests on a misconception, or you spot a bug adjacent to what was asked, say so rather than silently complying.\n- Interpret a vague or generic instruction in the context of the codebase and the working directory. \"Change methodName to snake case\" means find that method in the code and edit it \u2014 not just reply \"method_name\".\n- You are highly capable; help the user attempt ambitious tasks. Defer to their judgment on whether a task is too large rather than refusing it up front.\n\n## Executing actions with care\n- Weigh reversibility and blast radius. Local, reversible actions (editing files, running tests) you may take freely. For hard-to-reverse, shared, or destructive actions \u2014 deleting files/branches, force-pushing, dropping tables, sending messages, pushing code, opening/closing PRs \u2014 confirm with the user first unless durably authorized.\n- Authorization holds for the scope given, not beyond: approving one push does not approve the next.\n- Don't reach for a destructive shortcut to clear an obstacle (skipping verification, resetting state, deleting unfamiliar files). Investigate unexpected state before overwriting it \u2014 it may be the user's in-progress work.\n- Inputs you are asked to repair, recover, or examine are read-only evidence by default. Survey them with non-intrusive read commands first. Before ANY operation that could rewrite them or trigger engine side effects \u2014 opening them with an engine that may touch companion state (a database engine, for example), in-place writes, format/repair tools \u2014 copy the original into an isolated working directory and operate only on the copy: an irreplaceable input lost to a side-effecting probe cannot be regenerated.\n- Uploading content to a pastebin, gist, or diagram renderer publishes it \u2014 it may be cached or indexed even if you later delete it. Treat it as an outward-facing action.\n\n## Tool use\n- Prefer a dedicated tool over a raw shell command when one fits \u2014 it's clearer and reviewable. Reserve the shell for genuine system/terminal operations.\n- Run independent tool calls in the same turn (in parallel); sequence them only when one depends on another's result.\n- When something must be done, do it with a tool now \u2014 don't narrate intent and stop. If you say you'll do something, make the call in the same response.\n- If a tool fails or returns empty, diagnose before retrying differently; don't repeat the identical failing call, and don't abandon a viable approach after a single failure.\n- If an approach fails, diagnose why before switching to another. Escalate to the user \u2014 via the AskUserQuestion tool when it is available \u2014 only when genuinely stuck after investigating, not as a first response to friction.\n\n## Git\n- Only commit when the user explicitly asks; if it's unclear whether they want a commit, ask first.\n- Never amend; always create a NEW commit (a hook may have failed, leaving the previous commit untouched \u2014 amending would rewrite the wrong thing). If a pre-commit hook fails, fix the issue and make a new commit.\n- `git add` specific named files; never `git add -A` or `git add .` (they sweep in .env files, credentials, large binaries).\n- Never commit a file likely to contain secrets (.env, credentials.json, *.pem, key files); if the user explicitly asks you to, warn them first.\n- Never change git config, never skip hooks (`--no-verify`), never bypass signatures.\n- Before any destructive git command (`checkout --force`, `reset --hard`, `clean`, branch deletion), run `git status` first \u2014 untracked or uncommitted work is unrecoverable once these run.\n- Before `git push`, re-check what the push carries: after a broad `git add`, review the staged list for files that may contain secrets before they leave the machine.\n- Pass multi-line commit messages with a HEREDOC (`git commit -m \"$(cat <<'EOF' ... EOF)\"`) so formatting survives.\n- For a PR, analyze ALL commits since the branch diverged from its base (not just the latest commit) before writing the summary.\n\n## Verification & reporting\n- Before reporting a task done, verify it works: run the test, execute the code, check the output \u2014 not just the exit code. If you can't verify, say so rather than implying success.\n- Verify the final artifact, not a proxy. Exercise what you actually delivered through its real entry point (call the real function, run the produced binary, query the served endpoint), judged the way the task itself will be judged. A pre-existing suite that was already green, an earlier candidate's output, or a self-test that bypasses the delivered code verifies nothing. Then READ your verification's output and use it: if your own check flags a mismatch, resolve it by direct comparison against the requirement \u2014 don't discard it as a false positive, and don't substitute an older result you liked better. Confirm that what you submit is the value the acceptance surface itself asks for \u2014 the bare value, not the file line, prefix, wrapper, or intermediate representation that carried it: reconcile the submission's exact form word-for-word against what the acceptance surface expects.\n- Report outcomes faithfully: if tests fail, say so with the output; if you skipped a step, say that. Never manufacture a green result. Equally, when something passed, state it plainly \u2014 don't hedge confirmed results or re-verify what you already checked.\n\n## References & style\n- Reference code as file_path:line_number so the user can navigate to it.\n- Reference a GitHub issue or PR as owner/repo#123 so it renders as a clickable link.\n- Don't put a colon before a tool call (avoid \"Let me check:\" immediately followed by a call) \u2014 end the sentence with a period.\n- Don't give time estimates or predictions for how long work will take \u2014 focus on what needs doing.\n- Be concise; lead with the answer or the action. Prefer prose, lists, and code blocks over wide tables. Match the user's language. Avoid emojis unless asked. If you can say it in one sentence, don't use three. Go straight to the point, don't go in circles, don't overdo it. (This does not apply to code or tool calls.)";
 /** Context passed to a {@link PromptProvider.stableSystem} — the STABLE, cacheable inputs only. */
 export interface StablePromptContext {
     /** The task's own system prompt, if it supplied one. */
@@ -532,7 +532,7 @@ export interface StablePromptContext {
      * Omitted/false → not composed (fail-closed).
      */
     orchestrationEnabled?: boolean;
-    /** 锚定回归 R2([1132]③): orchestration is active but the Workflow tool is DEFERRED — compose the
+    /** Orchestration is active but the Workflow tool is DEFERRED — compose the
      *  short pointer instead of the full how-to (cache-prefix parity with the schema deferral). */
     orchestrationDeferred?: boolean;
     /** R2 双形轴 — the run's resolved prompt profile ("simple" default; "classic" keeps the pre-R3 shape). */
@@ -583,7 +583,7 @@ export interface StablePromptContext {
  * which handed ordering and memory placement to the provider, was removed in design/157 B19.)
  */
 /**
- * One TYPED stable-prompt contribution (campaign S1, plan M14) — the structured alternative to the
+ * One TYPED stable-prompt contribution (stage S1, plan M14) — the structured alternative to the
  * opaque `stableSystem(): string`. Each declaration lands as its own manifest section with full
  * slot/digest observability; the Composer places it by slot (identity → the role-base position,
  * scenario → after the mode blocks, behavior → the model-guidance region), preserving declaration
@@ -602,11 +602,11 @@ export interface PromptTextDeclaration {
     slot: "identity" | "scenario" | "behavior";
     text: string;
     /**
-     * OPT-IN reconciliation digest ([1050]② tiering / [1057]①a): `sha256:<64 lowercase hex>` of
+     * OPT-IN reconciliation digest (digest tiering): `sha256:<64 lowercase hex>` of
      * `text`, precomputed by the declaring deployment (e.g. the center publish pipeline). When present
      * AND correct it is passed through verbatim to the `prompt.assembled` manifest section as
      * `contentHash` (unsalted, end-to-end auditable); on mismatch it is DROPPED with an onWarn (never
-     * an invented digest). Core NEVER derives an unsalted digest on its own (codex F2: this lane may
+     * an invented digest). Core NEVER derives an unsalted digest on its own (this lane may
      * carry forwarded caller-private text — fingerprinting is strictly the declarer's explicit call).
      * Omit for private/caller-derived text; the salted manifest `hash` always remains.
      */
@@ -628,7 +628,7 @@ export interface PromptProvider {
      * still compose after it. Without this flag, `stableSystem` output is treated as the role layer and
      * the constitution is appended structurally.
      *
-     * M4 narrowing (clay 2026-07-16, campaign S1): the LOCKED sections — security policy, harness
+     * M4 narrowing (2026-07-16, stage S1): the LOCKED sections — security policy, harness
      * mechanism truth, context-management honesty — now compose structurally even under `replaceAll`;
      * the flag replaces the identity/behavior/scenario face only.
      */

package/dist/prompts/default.js

@@ -348,6 +348,8 @@ ${""}- Only commit when the user explicitly asks; if it's unclear whether they w
 - \`git add\` specific named files; never \`git add -A\` or \`git add .\` (they sweep in .env files, credentials, large binaries).
 - Never commit a file likely to contain secrets (.env, credentials.json, *.pem, key files); if the user explicitly asks you to, warn them first.
 - Never change git config, never skip hooks (\`--no-verify\`), never bypass signatures.
+${""}- Before any destructive git command (\`checkout --force\`, \`reset --hard\`, \`clean\`, branch deletion), run \`git status\` first — untracked or uncommitted work is unrecoverable once these run.
+- Before \`git push\`, re-check what the push carries: after a broad \`git add\`, review the staged list for files that may contain secrets before they leave the machine.
 - Pass multi-line commit messages with a HEREDOC (\`git commit -m "$(cat <<'EOF' ... EOF)"\`) so formatting survives.
 - For a PR, analyze ALL commits since the branch diverged from its base (not just the latest commit) before writing the summary.
 

package/dist/prompts/simple-sections.d.ts

@@ -1,5 +1,5 @@
 /**
- * 锚定回归 R3 — CC 2.1.212 SIMPLE-profile system sections, verbatim-anchored (clay's constitution:
+ * CC 2.1.212 SIMPLE-profile system sections, verbatim-anchored (the prompt constitution:
  * prompts anchor to CC; behavior value first). Anchor doc = sema-internal
  * anchors/2.1.212/simple-system-sections.md (the H$ section roster + full texts, pretty.js 466xxx).
  *
@@ -41,7 +41,7 @@ export declare const SIMPLE_PRONOUNS = "When you use a pronoun for someone \u201
 export declare const SIMPLE_TOOL_PARAM_JSON = "Object and array parameter values must be a single JSON value \u2014 never write parameter-tag markup inside a JSON value.";
 /** sU_ — the fable autonomous-operation section (b9e-gated in CC; served on fableMitigations). */
 export declare const SIMPLE_AUTONOMY_FABLE = "You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to\u2026?' or 'Shall I\u2026?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.\n\nException: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.\n\nBefore ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll\u2026', 'let me know when\u2026'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.\n\nBefore running a command that changes system state \u2014 restarts, deletes, config edits \u2014 check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.";
-/** [1246]④ — hermetic verification(sq**-wi**-gc** 案:两盒编译全对,挂在 profile 形 PATH+
+/** hermetic verification(sq**-wi**-gc** 案:两盒编译全对,挂在 profile 形 PATH+
  *  自己 shell 里 export 后自证;grader 以全新进程视角查找不到)。
  *
  *  RB-323 改名(2026-07-30):原标题 `# Delivering work that outlives the session` 与 CC 220 移植进来的
@@ -49,7 +49,7 @@ export declare const SIMPLE_AUTONOMY_FABLE = "You are operating autonomously. Th
  *  **前缀**,两段同时在场时既让模型看见两个近似标题,也让任何 `includes("# Delivering work")` 断言同时
  *  命中两段。新标题按内容取名:整段讲的是**怎么验**(全新进程视角),不是交付范围。 */
 export declare const SEMA_VERIFY_FRESH = "# Hermetic verification\nWhen a deliverable must work outside this session \u2014 an installed tool, a built artifact, a configured service \u2014 verify it the way a grader would: from a hermetic process that inherits none of your session state (e.g. `env -i bash -c '...'`), never only inside the shell where you exported variables or edited profile files. A login shell is NOT a clean check \u2014 it sources the same profiles you may have just written; use one only when a login shell is the deliverable's actual entry point, and never as the sole verification. Success that depends on your session state is not success. Prefer standard install locations over session-local paths, and leave the delivered state verified in the form it will actually be used.";
-/** [1246]⑤ — audit evidence discipline(sa** 案:正则命中而看不到原因→整读文件而非判误报;
+/** audit evidence discipline(sa** 案:正则命中而看不到原因→整读文件而非判误报;
  *  拿到具体值后字面值全仓终检)。 */
 export declare const SEMA_EVIDENCE_AUDIT = "# Search hits are evidence\nIn an audit or search task, treat every match as evidence until you have seen WHY it matched: when a hit's cause is not visible (a truncated line, a minified file), open the file at that location instead of dismissing the hit as a false positive. After you recover a concrete NON-SENSITIVE identifier (a hostname, an id, a config key), run one final literal search for that exact value across the whole target \u2014 the copies you did not predict are the ones that matter. For a SENSITIVE value (a credential, a token, a private key), never place it in a command argument or echo it in output: search by reading it from its source (e.g. a pattern file the shell never expands, or an in-process scan) and report locations and counts only.";
 /** CC 220 `RMy`(`delivering_work_max` 槽)—— 交付范围纪律。逐字。 */

package/dist/prompts/supervisor.d.ts

@@ -5,7 +5,7 @@
  * matching mode is actually enabled (same {@link harnessContext} §6.3 discipline: never claim a feature
  * the task lacks). They live in the cacheable prefix and never carry volatile content.
  *
- * Definition (clay 2026-06-22, value-judgment red line design/89+95): the supervisor is the delegate of an
+ * Definition (2026-06-22, value-judgment red line design/89+95): the supervisor is the delegate of an
  * absent user — closer to the user's goal/blueprint, so naturally watching the worker — **NOT because it is
  * smarter**. Its real value is a different VANTAGE (whole-goal vs local-slice) + a safety net for the cases a
  * worker structurally gets wrong. The prompts write that in plainly; they never claim "supervisor is generally
@@ -37,7 +37,7 @@ export declare const SUPERVISOR_PROMPT = "You are a supervisor \u2014 the delega
  * Aligns with the design/89/95 value judgment: fan-out AMPLIFIES a bad conclusion → clear boundaries +
  * adversarial verify.
  */
-/** 锚定回归 R2 / [1132]③ — the DEFERRED short form: when the Workflow tool itself is deferred
+/** The DEFERRED short form: when the Workflow tool itself is deferred
  *  (deferTools, wire schema withheld until activation), shipping the full ~5.7K how-to alongside
  *  defeats the deferral's cache-prefix point. One honest pointer replaces it.
  *

package/dist/scenarios/full-body.d.ts

@@ -3,7 +3,7 @@ import { type TaskListStore } from "../tools/task-list.js";
 import { type SubagentToolOptions } from "../agents/subagent.js";
 import type { ToolSpec, RoleSpec } from "../core/types.js";
 /**
- * design/102 (K-8) / [891] rename (`autonomous` scenario → `code`; the "full-body" working name followed —
+ * design/102 (K-8) rename (`autonomous` scenario → `code`; the "full-body" working name followed —
  * this bundle IS the `code` scenario's caller-composed tool half; file name kept for history). Config for
  * the code-scenario `spec.tools`-class bundle. The RICH seam-gated roster
  * (present_plan/skill/AskUserQuestion/LSP/hands/memory/run_workflow/tool_search) is NOT here — it auto-mounts in
@@ -17,7 +17,7 @@ export interface CodeToolsConfig {
     /** WebSearch backend (BRAIN/model-service leg). Absent ⇒ WebSearch is not assembled (core ships no backend). */
     webSearch?: WebSearchConfig;
     /** Subagent delegation. Present ⇒ assembled; child rosters are ⊆ parent via `resolveToolSubset` inside the tool.
-     *  合车复审修③ (codex F1): when this carries NO explicit `systemPrompt`, the assembler defaults it to
+     *  合车复审修③: when this carries NO explicit `systemPrompt`, the assembler defaults it to
      *  `CODE_SYSTEM_PROMPT` — a code-scenario child holds Bash/Write side-effect tools, so it keeps the code
      *  constitution (snapshot-before-mutate / destructive-op care / git discipline) instead of falling to the
      *  lean SUBAGENT_PROMPT (the G1 default, which is the right upstream-anchor shape only for bare
@@ -53,7 +53,7 @@ export interface CodeToolsConfig {
 }
 /**
  * Single-source bundle of the `code` scenario's `spec.tools`-class tools, so each deployment doesn't re-wire it
- * (clay's single-source discipline; mirrors the blessed `SCENARIO_REGISTRY` "data (named bundles)" precedent).
+ * (the single-source discipline; mirrors the blessed `SCENARIO_REGISTRY` "data (named bundles)" precedent).
  * Profile-as-data — the engine iterates `spec.tools` branch-free; nothing keys off the scenario name. A trusted
  * assembler (service) calls this, sets `systemPrompt = CODE_SYSTEM_PROMPT` (or `role = CODE_ROLE`) +
  * `enablePlanMode:true`, and wires the deps seams (executionEnv/onQuestion/lspManager/skillSpecs/memoryStore/

package/dist/scenarios/scenario-registry.d.ts

@@ -12,7 +12,7 @@
  * deploy-side knowledge — core fills guard-number defaults + prompts + orchestrator choice, never the model.
  */
 import type { Runner } from "../core/runner/runtask.js";
-import type { ModelRef, ModelRole } from "../core/types.js";
+import type { ModelRef, ModelRole, TaskSpec } from "../core/types.js";
 import { type TeamResult } from "../agents/team.js";
 import { type VerificationResult } from "../agents/verify.js";
 /** Design review: falsification-style multi-role debate (architect / reviewer / implementer). Reuses team.ts's
@@ -53,7 +53,7 @@ export interface ScenarioProfile {
     layer: "🟢现有编排器套壳" | "🔴需新循环骨架";
 }
 /**
- * core's preset scenario registry (clay 拍: core ships preset profiles). This is **data** (named bundles),
+ * core's preset scenario registry (裁定: core ships preset profiles). This is **data** (named bundles),
  * not a mechanism — each entry maps to one existing orchestrator + prompts + guard defaults.
  */
 export declare const SCENARIO_REGISTRY: Record<ScenarioId, ScenarioProfile>;
@@ -75,6 +75,10 @@ export interface RunScenarioOptions {
     reviewerCount?: number;
     /** External cancellation propagated into the orchestrator. */
     signal?: AbortSignal;
+    /** Per-model auth — MIRRORS {@link TaskSpec.getApiKeyAndHeaders}; forwarded into whichever
+     *  orchestrator the scenario maps to (solo task / team runs / verify judge), which resolve it
+     *  against their own resolved models. Absent ⇒ byte-identical specs (no key added). */
+    getApiKeyAndHeaders?: TaskSpec["getApiKeyAndHeaders"];
 }
 /** Per-scenario result union — each entry returns its orchestrator's native result shape. */
 export type RunScenarioResult = {

package/dist/scenarios/scenario-registry.js

@@ -61,7 +61,7 @@ export async function runScenario(opts) {
     switch (profile.orchestrator) {
         case "solo": {
             const model = requireModel(opts.models, "default", opts.scenario);
-            const spec = { objective: opts.objective, model, signal: opts.signal };
+            const spec = { objective: opts.objective, model, signal: opts.signal, ...(opts.getApiKeyAndHeaders !== undefined ? { getApiKeyAndHeaders: opts.getApiKeyAndHeaders } : {}) };
             return { scenario: "solo", result: await opts.runner.runTask(spec) };
         }
         case "team": {
@@ -81,6 +81,7 @@ export async function runScenario(opts) {
                     ],
                     synthesizer: { model: synthModel },
                     signal: opts.signal,
+                    ...(opts.getApiKeyAndHeaders !== undefined ? { getApiKeyAndHeaders: opts.getApiKeyAndHeaders } : {}),
                 });
                 return { scenario: "design-review", result };
             }
@@ -95,6 +96,7 @@ export async function runScenario(opts) {
                 members: codeReviewMembers(opts.reviewerCount ?? 2, teamModel),
                 synthesizer: { model: synthModel },
                 signal: opts.signal,
+                ...(opts.getApiKeyAndHeaders !== undefined ? { getApiKeyAndHeaders: opts.getApiKeyAndHeaders } : {}),
             });
             return { scenario: "code-review", mode: "team", result };
         }
@@ -127,7 +129,7 @@ async function runCodeReviewVerify(opts) {
         result: opts.objective,
         stats: { turns: 0, tokens: 0 },
     };
-    const specBase = { signal: opts.signal };
+    const specBase = { signal: opts.signal, ...(opts.getApiKeyAndHeaders !== undefined ? { getApiKeyAndHeaders: opts.getApiKeyAndHeaders } : {}) };
     const result = await verifyCompleted(opts.runner, reviewed, specBase, opts.objective, {
         verifierModel,
         verifierPrompt: STATIC_VERIFICATION_PROMPT,

package/dist/stores/cc/sidecar-transcript.d.ts

@@ -6,12 +6,12 @@ import type { Message } from "../../internal/llm.js";
  * handover) can enumerate the teammates' transcript sidecars and project them into sema message
  * shapes for resume context.
  *
- * D-2 ruling (clay, design/152 §3): the sidecar is CC→sema ONE-WAY. sema's transcript truth source
+ * D-2 ruling (design/152 §3): the sidecar is CC→sema ONE-WAY. sema's transcript truth source
  * is the SessionStore — this module never writes, and nothing here mints a second truth source
  * (the dual-truth-source pathology design/151 just eliminated stays eliminated). Dual-write is a
  * separate ruling gated on a real user need.
  *
- * Disk shape ([1545] 定盘, cc-teams-diskform README):
+ * Disk shape (cc-teams-diskform README):
  *  - flat sidecars:    `subagents/agent-<id>.jsonl`
  *  - nested children:  `subagents/<parentSeg>/agent-<id>.jsonl` (parent-segment subdirectories)
  *  - workflow runs:    `subagents/workflows/<runId>/agent-<t>.jsonl`
@@ -53,7 +53,7 @@ export interface CcSidecarHandle {
  * Enumerate every transcript sidecar under a CC `subagents/` directory, walking nested
  * parent-segment subdirectories (symlinks not followed). Missing directory ⇒ `[]` — the CC tree is
  * a PARTIAL tree (headless runs write sidecars but a REPL-only subtree may be absent entirely), so
- * absence is a normal state, never a throw ([1545] 纠偏 #3 posture).
+ * absence is a normal state, never a throw.
  * Order is deterministic: lexicographic by (segments join, agentId).
  */
 export declare function listCcSidecarAgents(subagentsDir: string): CcSidecarHandle[];

package/dist/stores/file/fs-atomic.d.ts

@@ -19,7 +19,7 @@ export declare function resolveDataRoot(explicit?: string): string;
 /** Ensure a directory exists with 0o700 perms (idempotent). */
 /**
  * Atomically CREATE `target` carrying `content` — it appears in ONE step already fully written, no empty/partial
- * window. Fixes the create-then-write race (codex review BUG-1/BUG-3): a reader/pruner can see a half-written
+ * window. Fixes the create-then-write race: a reader/pruner can see a half-written
  * file, and a crash mid-write leaves a zero-byte target a retry would silently keep. Writes a temp in `target`'s
  * OWN dir (same FS → `link` is atomic) + fsync, then `linkSync`-publishes it; throws `EEXIST` if `target` exists.
  */
@@ -134,7 +134,7 @@ export declare class AppendLog {
      *
      * RB-66 (2026-07-25, red probe): `writeSync(fd, string)` issues ONE write(2) and may SHORT-WRITE — the
      * same defect class this file's own `writeThenLink` already documents and fixed ("silently SHORT-WRITES
-     * (codex/Opus review B1)"), never propagated to this shared primitive. A short write here leaves a torn
+     * "), never propagated to this shared primitive. A short write here leaves a torn
      * line with no trailing newline, so the NEXT append concatenates onto it and replay drops BOTH records.
      * Loop until every byte lands (write(2) returns how many it took) — the O_APPEND atomicity per call is
      * unchanged, and a genuine I/O error still throws.

package/dist/stores/file/index.d.ts

@@ -127,7 +127,7 @@ export declare class FileStorageBackend {
      *  `RunnerDeps.fileSnapshotStore`. Content-addressed blobs persist across restarts (local-only; a remote env
      *  defers rewind to its own VM-snapshot backend). */
     readonly fileSnapshotStore: FileSnapshotStore;
-    /** SVC-2 / [381]⑥ (onboarded per [375]) — file-backed durable workflow resume journal. Wire into
+    /** SVC-2 (onboarded per) — file-backed durable workflow resume journal. Wire into
      *  `RunnerDeps.workflowJournalStore` so `resumeFromRunId` survives a process restart on a TOC box. */
     readonly workflowJournalStore: WorkflowJournalStore;
     /** design/164 件五 — file-backed cross-task usage-governance ledger. Wire into

package/dist/stores/file/session-store.d.ts

@@ -71,11 +71,11 @@ export declare class FileSessionRepo implements SessionRepo {
     placementOf(sessionId: string): Promise<SessionPlacementRecord | undefined>;
     delete(metadata: SessionMetadata): Promise<void>;
     fork(sourceMetadata: SessionMetadata, options?: SessionForkOptions): Promise<Session>;
-    /** 2c session-sync ([275], the FILE half of [266]②): the FULL oldest-first log for export. The file backend
+    /** 2c session-sync (the FILE half): the FULL oldest-first log for export. The file backend
      *  has NO F3 floor — `read` returns EVERY persisted entry (`id`/`parentId` verbatim) — so this is the complete
      *  log, BYPASSing any bounded tail (matches `InMemorySessionRepo.exportEntries`). Missing file → not_found. */
     exportEntries(sessionId: string): Promise<SessionTreeEntry[]>;
-    /** 2c session-sync ([275]): import a verbatim log into `sessionId`. The single fail-closed invariant gate runs
+    /** 2c session-sync: import a verbatim log into `sessionId`. The single fail-closed invariant gate runs
      *  FIRST ({@link validateEntriesForImport}); `owner` is a durable multi-tenant concept the local file backend
      *  has no field for (accepted, unused — same as `InMemorySessionRepo`). Writes the WHOLE file (meta + entries)
      *  atomically via tmp→fsync→rename — the rename is the commit point, so a crash leaves either nothing or an

package/dist/stores/file/workflow-journal-store.d.ts

@@ -70,7 +70,7 @@ export declare class FileWorkflowJournalStore implements WorkflowJournalStore {
     private get scopes();
     constructor(root: string, fsyncEnabled?: boolean);
     private pathFor;
-    /** [1409]③ CC local form: the run's on-disk journal path for the notification diagnostics line.
+    /** CC local form: the run's on-disk journal path for the notification diagnostics line.
      *  Traversal-shaped ids (LLM-controlled on some paths) degrade to undefined, never throw. */
     locator(runId: string): string | undefined;
     /** Replay a run's ledger: last-writer-wins per ordinal; a torn/unparsable line is skipped (uncommitted). */
@@ -78,7 +78,7 @@ export declare class FileWorkflowJournalStore implements WorkflowJournalStore {
     append(runId: string, scope: string, entry: WorkflowJournalEntry): Promise<void>;
     load(runId: string, scope: string): Promise<WorkflowJournalEntry[]>;
     /**
-     * RB-242 — the claim file for `(sourceRunId, scope)`. Keyed by BOTH ([1981]): a cross-scope caller already
+     * RB-242 — the claim file for `(sourceRunId, scope)`. Keyed by BOTH: a cross-scope caller already
      * resolves to an empty journal (it cannot fork anything), so letting it share one claim key would only hand
      * any tenant a denial-of-resume lever over another's runs. The scope is folded in as a digest rather than
      * a sanitized literal so two distinct scopes can never collapse onto one filename by sanitization.
@@ -111,7 +111,7 @@ export declare class FileWorkflowJournalStore implements WorkflowJournalStore {
      */
     private sweepExpiredClaims;
     /**
-     * RB-242 ([1981]) — admission for a resume off `sourceRunId`. The LOCAL (TOC) twin of server's SQL
+     * RB-242 — admission for a resume off `sourceRunId`. The LOCAL (TOC) twin of the SQL-backed
      * `idem_key UNIQUE` + TTL: publishing the claim file is one atomic namespace operation that fails EEXIST
      * against anyone who got there first, so two processes racing on the same box (the shape the in-process
      * `startWorkflow` guards cannot see — a shell restart resuming a run a still-live process is already
@@ -121,7 +121,7 @@ export declare class FileWorkflowJournalStore implements WorkflowJournalStore {
         granted: boolean;
         holder?: string;
     }>;
-    /** RB-242 ([1981]) — release ONLY a claim this `newRunId` still holds. A claim that is already gone (TTL-reaped
+    /** RB-242 — release ONLY a claim this `newRunId` still holds. A claim that is already gone (TTL-reaped
      *  and possibly taken over) is a no-op: unlinking a successor's claim would re-open the very fork this prevents. */
     releaseResumeClaim(input: ResumeClaimArgs): Promise<void>;
     /** GC (service extra, mirrors the SQL twins): drop the run's ledger once the run is terminal + retained. */

package/dist/tools/fs/bash-readonly-classifier.d.ts

@@ -415,7 +415,7 @@ export declare const POLL_LOOP_MAX_SLEEP_SECONDS = 600;
  *    no-egress envelope — every beat still runs allowlisted readers + literal `sleep`), and the
  *    walltime axis cascades a hard kill regardless. A deployment wanting NO command-substitution at
  *    all can prefer `{<lo>..<hi>}` or a literal list, which bash expands internally with no command
- *    run. (Codex falsification review flagged the substitution as [high] and recommended dropping it;
+ *    run. (falsification review flagged the substitution as [high] and recommended dropping it;
  *    kept per the ruling that names `$(seq <int> <int>)` as the one exemption — recorded for a
  *    tightening decision, since the brace form is a drop-in equivalent.)
  *  · STDIN-BLOCKING BODY (an availability residual, not a safety one). CLOSED for the shape this note

package/dist/tools/fs/encoding.d.ts

@@ -33,7 +33,7 @@ export interface DecodedTextFile {
     encoding: DetectedFileEncoding;
     /** Dominant line ending of the ORIGINAL bytes (majority vote — CC `CKt` @58184 同算法).
      *  Deliberately NOT per-line lossless: a mixed-endings file is unified to the dominant ending on
-     *  the first edit (codex 镜头1/2 LOW, accepted non-goal — CC behaves the same way).
+     *  the first edit (镜头1/2 LOW, accepted non-goal — CC behaves the same way).
      *  RB-285 (encoding LOW): the COUNTING RULE is CC's; the SAMPLE is not. CC votes on the first 4096
      *  characters only (`CKt(s.slice(0, 4096))` @58201) while {@link detectLineEndings} below votes on
      *  the whole file — so a file whose first 4KB is LF and whose bulk is CRLF gets opposite verdicts.
@@ -41,7 +41,7 @@ export interface DecodedTextFile {
      *  the entire file, so sampling a prefix is exactly the case where the cheap answer flips the
      *  remaining 99% of the lines. Registered as a deliberate delta, not parity. */
     endings: DetectedLineEndings;
-    /** codex 双镜头 MED: a utf16le body with an ODD byte count is TRUNCATED/corrupt — decoding would
+    /** 双镜头 MED: a utf16le body with an ODD byte count is TRUNCATED/corrupt — decoding would
      *  silently drop the dangling byte and a later write-back would destroy it permanently. Flagged so
      *  the tool layer fails closed instead of "repairing" the file. */
     malformed?: true;
@@ -65,7 +65,7 @@ export declare function encodeTextForFile(text: string, encoding: DetectedFileEn
  *  Deliberately does NOT strip a leading U+FEFF: an `old_string` starting with one may be quoting
  *  genuine file content — use {@link normalizeFileText} only where the string stands for a whole file. */
 export declare function normalizeEditText(s: string): string;
-/** RB-222 ([1937] W2) — split a leading U+FEFF off MODEL-SUPPLIED whole-file text (CC `CTe` parity,
+/** RB-222 — split a leading U+FEFF off MODEL-SUPPLIED whole-file text (CC `CTe` parity,
  *  220 @365630). The BOM is a file-level byte marker, not text: decodeTextBytes strips it on the way
  *  in, so it can never live in the normalized coordinate. Only for strings that stand for a WHOLE
  *  file (Write `content`, readFileState seeding) — a decoded file text's leading U+FEFF is genuine
@@ -74,7 +74,7 @@ export declare function splitLeadingBom(text: string): {
     hadBom: boolean;
     text: string;
 };
-/** RB-222 ([1937] W2) — CC `X9` parity (220 @365635 = BOM-strip + CRLF-normalize): THE coordinate
+/** RB-222 — CC `X9` parity (220 @365635 = BOM-strip + CRLF-normalize): THE coordinate
  *  every readFileState hash lives in (Read/Edit/Write staleness all hash `decodeTextBytes(...).text`).
  *  A hash taken on raw model content with a leading U+FEFF can never agree with any later re-read. */
 export declare function normalizeFileText(s: string): string;

package/dist/tools/fs/fs-bash.d.ts

@@ -126,11 +126,11 @@ export declare function createBashTool(env: ExecutionEnv, rootCanonical: string,
      * unconfined; passing this never gates anything.
      */
     additionalRoots?: readonly string[];
-    /** RB-370 ② (cli [2088]): override of the `timeout` parameter's DEFAULT budget, in ms — see
+    /** RB-370 ② (cli): override of the `timeout` parameter's DEFAULT budget, in ms — see
      *  {@link import("./index.js").HandsToolkitOptions.bashDefaultTimeoutMs} for the resolution
      *  contract (options over env over constant; invalid values discarded). */
     bashDefaultTimeoutMs?: number;
-    /** RB-370 ② (cli [2088]): override of the `timeout` parameter's engine CEILING, in ms — only-widen
+    /** RB-370 ② (cli): override of the `timeout` parameter's engine CEILING, in ms — only-widen
      *  vs the resolved default; see {@link import("./index.js").HandsToolkitOptions.bashMaxTimeoutMs}. */
     bashMaxTimeoutMs?: number;
     /** Structured sink for this leg's timeout-cap discard announcements — consumed by
@@ -167,7 +167,7 @@ export declare function createBashTool(env: ExecutionEnv, rootCanonical: string,
  * the operand cannot be resolved statically (there is nothing to degrade to).
  */
 export declare function createBashReadonlyTool(env: ExecutionEnv, rootCanonical: string, allow: ReadonlySet<string>, opts?: {
-    /** RB-370 ② (cli [2088]): same timeout-cap overrides the full `bash` leg takes — see
+    /** RB-370 ② (cli): same timeout-cap overrides the full `bash` leg takes — see
      *  {@link import("./index.js").HandsToolkitOptions.bashDefaultTimeoutMs} /
      *  {@link import("./index.js").HandsToolkitOptions.bashMaxTimeoutMs} (类修完整域: both foreground
      *  legs share runShell's clamp, so both must share the configurable resolution). */

package/dist/tools/fs/fs-pdf.d.ts

@@ -34,7 +34,7 @@ type ReadPdfReturn = string | {
  * it was not — every `document` card, sized or not, was dropped at the gate, making the 48K rule dead
  * code and the pages/fallback-level disclosure invisible to a host. The word is registered now.
  *
- * Degradation chain v2 (clay 拍: the brain-level placeholder is NOT the end state): when the SERVING model
+ * Degradation chain v2 (裁定: the brain-level placeholder is NOT the end state): when the SERVING model
  * cannot take a native document block (`caps.document === false` — e.g. any openai-compatible API), the
  * whole-PDF path degrades IN THE TOOL (the only layer holding env.exec), best first:
  *   1. `pdftotext -layout` text extraction → the content arrives as TEXT (Read byte-cap discipline applies);

package/dist/tools/fs/fs-shared.d.ts

@@ -65,7 +65,7 @@ export declare function truncatedUtf16BodyMessage(tool: string, path: string): s
 /** Why a bash_readonly refusal is terminal rather than escalated. Appended by every arm of that refusal
  *  family; the arms differ in what they found, never in what the model can do about it. */
 export declare const BASH_READONLY_CONFINEMENT_NOTE = "bash_readonly is confined to the workspace roots; it has no approval path, so the call is refused rather than escalated.";
-/** RB-222 ([1937] W2) r3 — the readFileState hash coordinate for a file that was JUST WRITTEN via
+/** RB-222 r3 — the readFileState hash coordinate for a file that was JUST WRITTEN via
  *  `encodeTextForFile`: decode the EXACT payload handed to `env.writeFile`, i.e. what the next
  *  re-read's `decodeTextBytes` will produce. A blanket `normalizeFileText` is WRONG on the
  *  encode-preserving Edit lanes: a leading U+FEFF in the new text is stripped by the next read only
@@ -209,7 +209,7 @@ export declare function bashTimeoutArgRefusal(timeoutMs: number | undefined, cap
     maxMs: number;
 }): string | undefined;
 /**
- * RB-370 ②/③ (cli [2088] 请求③) — the SINGLE authority for the Bash `timeout` parameter's two numbers:
+ * RB-370 ②/③ — the SINGLE authority for the Bash `timeout` parameter's two numbers:
  * the default budget applied when the model omits `timeout`, and the engine ceiling requests are
  * clamped to. The 120s/600s constants themselves are CC 220-same; what CC additionally has — and this
  * resolver adds — is configurability.
@@ -223,7 +223,7 @@ export declare function bashTimeoutArgRefusal(timeoutMs: number | undefined, cap
  * default floors the cap. Invalid values (non-finite / <= 0) are discarded at every leg, options
  * included, exactly like CC's env read.
  *
- * ③ Readable seam (cli [2088]): a shell/host rendering its OWN copy of the Bash tool description MUST
+ * ③ Readable seam: a shell/host rendering its OWN copy of the Bash tool description MUST
  * read the true values from here instead of holding a sibling constant — the engine's description/param
  * text and its runtime clamp both interpolate this function's output (resolved once per tool instance),
  * so a self-held "600s" only matches by coincidence and forks silently the moment a deployment
@@ -271,7 +271,7 @@ export declare function clipShellOutput(s: string): string;
  * ALREADY fully in memory here (the env delivered them whole — only `clipShellOutput` above decides how
  * much of that the model's turn actually sees) — the gap this closes is that the omitted middle was
  * simply discarded, forcing a blind full re-run to recover output that was, in fact, captured. "Whole"
- * means whatever THIS layer received, not a guarantee about what the process originally wrote (codex
+ * means whatever THIS layer received, not a guarantee about what the process originally wrote (
  * review P1): the env's own rolling-tail cap (`MAX_EXEC_OUTPUT_BYTES`, exec-output-tail.ts) can already
  * have dropped the head before delivery on a truly enormous single command — this file is a faithful copy
  * of the received bytes either way, and still carries that cap's own `markTruncated()` marker when it
@@ -379,7 +379,7 @@ export declare function countLines(s: string): number;
  *  home and carries the session mark when one is threaded (the recorded wire-form divergence). */
 export declare function seededFileUnchangedReminder(filePath: string, mark?: string): string;
 /**
- * RB-197②(codex 交叉复审命中,已修) — true when `resultText` is one of the Read tool's TWO dedup
+ * RB-197②(交叉复审命中,已修) — true when `resultText` is one of the Read tool's TWO dedup
  * markers (the ordinary unchanged-since-last-read stub below, or {@link seededFileUnchangedReminder})
  * rather than a genuine content transmission. A consumer deciding "is this file's real content
  * present in THIS message" (e.g. auto-compaction's kept-tail visibility scan) must treat a stub hit
@@ -431,7 +431,7 @@ export declare function seedReadFileStateFromTranscript(state: ReadFileState, ke
  * The read-before-edit gate tightens as a consequence, matching CC: after a compaction the model must
  * re-Read a summarized-away file before editing it, instead of blind-editing from a stale recollection.
  *
- * RB-197②(独立复审 + codex 命中,已修): a THIRD category besides seeded/re-attached — a file whose most
+ * RB-197②(独立复审 + 命中,已修): a THIRD category besides seeded/re-attached — a file whose most
  * recent Read is still visible verbatim in the compaction's KEPT tail is deliberately left OUT of
  * `attachedComplete` (re-attaching it would just duplicate content already in context), but its
  * existing read-state entry must survive unmodified for the SAME reason a seeded entry does: the

package/dist/tools/fs/index.d.ts

@@ -63,7 +63,7 @@ export interface HandsToolkitOptions {
     }) => void;
     /** design/116 detach: the run-local per-tool-call detach hub (mid-flight ctrl+b → adopt as background). */
     detachHub?: import("../../core/tool-detach.js").ToolDetachHub;
-    /** RB-370 ② (cli [2088]): the Bash `timeout` parameter's DEFAULT budget, in ms — applied when the
+    /** RB-370 ② (cli): the Bash `timeout` parameter's DEFAULT budget, in ms — applied when the
      *  model omits `timeout`. Resolution (options over env over constant — the standing sema discipline:
      *  deployments configure the tool, not the process): this field ?? env `BASH_DEFAULT_TIMEOUT_MS` ??
      *  120000; invalid (non-finite / <= 0) values are discarded at every leg. See
@@ -71,7 +71,7 @@ export interface HandsToolkitOptions {
      *  description, so the advertised numbers always match the enforced ones. Additive: absent ⇒
      *  byte-compat 120s. Applies to both shell legs (`bash` and `bash_readonly`). */
     bashDefaultTimeoutMs?: number;
-    /** RB-370 ② (cli [2088]): the Bash `timeout` parameter's engine CEILING, in ms — requests above it
+    /** RB-370 ② (cli): the Bash `timeout` parameter's engine CEILING, in ms — requests above it
      *  are clamped (with the RB-370 requested/capped disclosure naming THIS value). Resolution: (this
      *  field ?? env `BASH_MAX_TIMEOUT_MS` ?? 600000), then floored at the resolved default — CC's own
      *  only-widen semantic: a ceiling below the default is a narrowing intent = invalid, ignored in

package/dist/tools/fs/index.js

@@ -79,7 +79,14 @@ export function createHandsToolkit(env, readFileState, rootCanonical, opts = {})
         if (!readOnly && mountBackgroundTaskTools && hasBackgroundShell(env)) {
             const sessionAxis = opts.sessionId !== undefined ? { sessionId: opts.sessionId } : {};
             tools.push(opts.taskRegistry
-                ? createTaskOutputTool({ registry: opts.taskRegistry, owner: opts.taskOwner, scope: opts.taskScope, ...sessionAxis, ...(opts.oneShot !== undefined ? { oneShot: opts.oneShot } : {}) })
+                ? createTaskOutputTool({
+                    registry: opts.taskRegistry,
+                    owner: opts.taskOwner,
+                    scope: opts.taskScope,
+                    ...sessionAxis,
+                    ...(opts.oneShot !== undefined ? { oneShot: opts.oneShot } : {}),
+                    notificationWired: opts.taskNotification !== undefined,
+                })
                 : createEnvTaskOutputTool(env), opts.taskRegistry
                 ? createTaskStopTool({ registry: opts.taskRegistry, owner: opts.taskOwner, scope: opts.taskScope, ...sessionAxis })
                 : createEnvTaskStopTool(env));

package/dist/tools/fs/notebook.d.ts

@@ -1,6 +1,6 @@
 import type { ImageContent } from "../../internal/llm.js";
 /**
- * RB-227 ([1937] N1) — the Read tool's Jupyter-notebook projection: `.ipynb` is rendered as cells
+ * RB-227 — the Read tool's Jupyter-notebook projection: `.ipynb` is rendered as cells
  * with outputs (CC 2.1.220 parity: `Ctd`/`wtd`/`Zx_`/`Qx_`/`eI_`/`tI_`/`Atd`, pretty220.js
  * :371265-:371426), never as raw JSON text. The raw-JSON rendering let a notebook's base64 outputs
  * overflow the Read token cap, auto-paginate into an `isPartialView` entry, and thereby lock

package/dist/tools/fs/pdf.d.ts

@@ -1,5 +1,5 @@
 /**
- * PDF read pipeline (service [411]② + 审计 [485]⑤ — CC FileReadTool parity).
+ * PDF read pipeline (+ 审计 — CC FileReadTool parity).
  *
  * CC ground truth (original-source-code, 取证 2026-07-07):
  * - Whole-PDF path (`FileReadTool.ts:987-1016` + `utils/pdf.ts:88-103`): the file bytes are base64'd and