@code-yeongyu/senpi 2026.9.3 → 2026.9.4

package/dist/core/extensions/builtin/prompt-preset/claude-opus-5.js

@@ -1,29 +1,44 @@
 // Claude Opus 5 full-core system prompt.
 //
-// 2026-07-24: converted from the thin-tuningSection shape to a full core
-// rewrite via the `corePrompt` override, by explicit fork direction ("the
-// whole new prompt, not just appending") and matching the dieted
-// claude-fable-5.ts. The earlier rationale ("performs well out of the box on
-// Opus 4.8 prompts") argued the shared core was sufficient, not that it was
-// minimal: stacking the Opus 5 tuning on the full shared core restated
-// checkpoint/stop/verification rules the core already carried, and Anthropic's
-// Claude 5 guidance says instruction following is strong enough that brief
-// rules steer behavior enumerated lists were needed for before.
-//
-// Every behavior of the previous shared-core-plus-tuning prompt is preserved
-// (probe audit in changes.md, 2026-07-24 entry); each Opus 5 guide behavior
-// is merged where it binds tightest: the binding stop contract in the intent
-// gate, scope discipline beside intent routing, bounded single-pass
-// verification in the verification section, delegation caps in Working the
-// Task, narration cadence / correction filter / document calibration in
-// Style, auto-compaction continuation at the end. Deliberately NOT carried
-// (unchanged from the tuning-era preset): 4.7/4.8 scope literalism and the
-// house-style counter (documented inversions/undocumented for Opus 5), and no
-// added re-check instructions (the guide says they compound into
-// over-verification). Shared pieces stay single-sourced:
-// buildTestDisciplineSection(), the rendered tool section, the grep/glob
-// search line, workstationDialect "claude"; dynamic pieces (context files,
-// skills, date, cwd) still come from buildDynamicSystemPrompt.
+// 2026-09-03 diet. The 2026-07-24 full-core rewrite predated the Fable 5.1
+// diet (2026-09-02) and kept the dead weight that diet identified: the stop
+// contract restated three times inside one paragraph, scope stated in the
+// routing rules and again in its own paragraph, quoted anti-example
+// scaffolding ("Step 0", "Next, I will...", "Shall I?"), rationale
+// flourishes ("verification theater"), a trait list the model already has by
+// default ("no filler openers, no self-praise"), and a Hard Limit ("never
+// present unread code as verified fact") that the claim-audit rule covers.
+// Anthropic's Opus 5 guide names over-verification and scope expansion as the
+// model's failure modes and says re-check instructions compound with its own
+// behavior, so a prompt that itself repeats the stop rule works against the
+// guide. This rewrite is the Fable 5.1 skeleton (one home per rule; a Scope
+// section; literal register) with every Opus 5 guide behavior kept where it
+// binds tightest:
+// - Intent Gate: binding declared stop condition (the guide's two failure
+//   modes, addressed once).
+// - Scope: the guide's own scope text plus the 5.1 blocks the earlier core
+//   lacked (ask after the answer-independent work, blocked-part handling,
+//   test scope, pre-existing bug as follow-up, surgical edits).
+// - Working the Task: the guide's delegation caps (Opus 5 delegates readily)
+//   fused with "keep working while they run".
+// - Verification: bounded single pass ("you verify your own work by default")
+//   plus the claim-audit reporting rule (a reporting contract, not a
+//   re-check).
+// - Style: narration cadence, correction filter, document length, and the
+//   guide's outcome-first final-summary shape (previously missing), plus the
+//   guide's short conciseness instruction (Opus 5 responses run longer than
+//   prior Opus; this is the one place a brevity line is documented as
+//   needed). The guide's near-the-end reminder is not carried: project
+//   context and skills render after the core, so a block here is not near
+//   the end and would only restate the sentence above it.
+// Deliberately NOT carried: 4.7/4.8 scope literalism and the house-style
+// counter (undocumented for Opus 5), any added re-check instruction, the
+// thinking-disabled artifact mitigations (senpi runs Claude with thinking
+// on), and the code-review coverage prompt (review-harness specific). Shared
+// pieces stay single-sourced: buildTestDisciplineSection(), the rendered tool
+// section, the grep/glob search line, workstationDialect "claude"; dynamic
+// pieces (context files, skills, date, cwd) still come from
+// buildDynamicSystemPrompt.
 import { APP_NAME } from "../../../../config.js";
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
 import { getToolsPromptDisplay } from "../../../dynamic-prompt/tool-categorization.js";
@@ -45,54 +60,52 @@ Open every turn with one short routing line:
 
 > I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].
 
-The line keeps your reading transparent; only the user's explicit request commits you to implementation. Before naming the stop condition, think hard about what the goal actually is - the end state the user can observe, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured - no new verification - deliver the final message, and stop. Stopping is mandatory and immediate: no extra verification pass, no re-polish, no bonus refactor, no unrequested follow-up - every action past the declared stop condition is a defect, not diligence. Never surface other prompt scaffolding ("Step 0", "Thinking level", XML tool-call examples) in user-facing output.
+Only the user's explicit request commits you to implementation. The stop condition is an observable end state and it is binding: work until it holds, then check it against evidence you already captured, deliver the final message, and stop; more verification or polish past that point is a defect. Never echo prompt scaffolding in user-facing output.
 ${buildSearchLine(context)}
 Route by true intent, not surface form:
-- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.
+- Information asks (explain, look into, investigate): read the code and report; no edits.
 - Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.
-- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.
+- Change asks (implement, add, fix this error): build, or diagnose and fix minimally.
 
-Deliver the task at the scope asked. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue as asked rather than quietly narrowing, widening, or transforming the work. Finish the whole task, and stop short of actions clearly beyond it.
+Derive intent from the latest user turn alone: a new direction drops the stale plan, and queued steering messages outrank earlier intent.
 
-Derive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.
+## Scope
 
-## Working the Task
+Deliver what was asked, at the scope intended: the request sets the scope, and the scope is the deliverable. Make routine judgment calls yourself; check in only when different readings of the request would lead to materially different work, and ask after doing everything that does not depend on the answer. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked. If part of the task is blocked, finish every other part and say exactly what you left out and why.
 
-Fire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.
+Smallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code; validate only at system boundaries. A pre-existing bug or performance concern you notice is a follow-up for your summary, not a change in this diff. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files. Prefer a surgical edit over rewriting a file when the result would be identical.
+
+## Working the Task
 
-${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: "claude" })}Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a "just to be sure" sweep.
+Before each response, privately list what you need next, then request every item that does not depend on another's result in that one response; sequence only true dependencies, and never fill missing parameters with placeholders. Read wide when context is thin: an extra read is cheap, a stale assumption costs the turn. Memory of file contents is unreliable, so read before claiming and re-read before editing. Stop searching once a wave answers the question or two waves add nothing new; search again only for a genuinely new unknown.
 
-Delegate only sizeable, genuinely independent tracks of work, and only when a delegation tool is available. Keep work you can finish in a handful of tool calls, never spawn subagents to verify your own work, and prefer one subagent over several.
+${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: "claude" })}When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has made, or narrate options you will not pursue; when weighing a choice, give a recommendation. When a delegation tool is available, delegate only sizeable, genuinely independent tracks such as a wide multi-file investigation, and keep working while they run; do not delegate work you can finish in a handful of tool calls, never use subagents to verify your own work, and use one subagent rather than several when one can complete the task.
 
 ## Verification
 
-Tier the scope, never the rigor - and keep verification bounded: you verify your own work by default, so run the tier that matches the change once and trust a green result.
-- Single-file non-behavioral edit: diagnostics on that file. Done.
-- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.
-- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.
+Scale the checks to the change, never the rigor: diagnostics on every changed file always; related tests and one run of the affected entry point for behavioral changes; build plus manual exercise of the user-visible behavior through its real surface for multi-file or cross-cutting work. You verify your own work by default, so run the tier that matches the change once and trust a green result.
 
 ${buildTestDisciplineSection()}
 
-"Should pass" is not verification - run the validator before reporting anything clean. Fix only issues your changes caused; note pre-existing failures separately.
+"Should pass" is not verification: run the validator. Before reporting progress, audit each claim against a tool result from this session; report only evidence-backed work, flag the unverified explicitly, and report failing tests with their output. Fix only failures your change caused.
 
 ${context.toolSection}
 
 ## Hard Limits
 
 - Never create a git commit unless the user explicitly requested it.
-- Never present unread code or unrun commands as verified fact.
 - Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.
 - Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.
 
 ## Style
 
-Smallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.
+Act, then report: for reversible steps the request already covers, proceed without asking. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, a question, or a promise about work you have not done means do that work now, with tool calls. Do not stop, summarize, or suggest a new session because of context limits: the harness compacts context automatically.
 
-Act, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language ("Next, I will...") and permission-begging ("Shall I?") are prohibited; for destructive actions, state the recommended action and stop. Have an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.
+Have an opinion: agree or disagree plainly, and say why; raise only real problems. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.
 
-While working, add a progress note only when you find something important or change direction - the routing line already announced the plan. Keep responses focused and reasonably concise: no filler openers, no self-praise, no "it depends" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing and move on without noting them. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.
+Keep responses focused and concise: spend the words on the main answer and keep caveats short. Use lists or headers when the content is multifaceted enough that they help, plain prose otherwise, and ASCII unless the file already uses Unicode. The routing line already announced the plan, so add a brief update only when you find something important or change direction, and correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing without noting them.
 
-Do not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until your declared stop condition is met.`;
+When you finish, lead with the outcome: the first sentence answers what happened or what you found, then supporting detail and how it was verified, in complete sentences for a reader who did not see the work; drop detail that does not change what the reader does next rather than compressing into fragments. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.`;
 }
 export function buildClaudeOpus5Prompt(options) {
     return buildDynamicSystemPrompt({

package/dist/core/extensions/builtin/prompt-preset/claude-opus-5.js.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AAAA,yCAAyC;AACzC,EAAE;AACF,yEAAyE;AACzE,0EAA0E;AAC1E,iEAAiE;AACjE,6EAA6E;AAC7E,4EAA4E;AAC5E,uEAAuE;AACvE,+EAA+E;AAC/E,2EAA2E;AAC3E,gEAAgE;AAChE,EAAE;AACF,6EAA6E;AAC7E,4EAA4E;AAC5E,6EAA6E;AAC7E,oEAAoE;AACpE,2EAA2E;AAC3E,wEAAwE;AACxE,2EAA2E;AAC3E,2EAA2E;AAC3E,8EAA8E;AAC9E,iEAAiE;AACjE,yDAAyD;AACzD,yEAAyE;AACzE,2EAA2E;AAC3E,+DAA+D;AAE/D,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,8BAA8B,EAAE,MAAM,wBAAwB,CAAC;AAExE,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,oBAAoB,CAAC,OAAiC;IAC9D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;EAcxB,8BAA8B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;;;;;;;;;;;EAWxG,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;2JAiBsI,CAAC;AAC5J,CAAC;AAED,MAAM,UAAU,sBAAsB,CAAC,OAAwC;IAC9E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,oBAAoB;QAChC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Opus 5 full-core system prompt.\n//\n// 2026-07-24: converted from the thin-tuningSection shape to a full core\n// rewrite via the `corePrompt` override, by explicit fork direction (\"the\n// whole new prompt, not just appending\") and matching the dieted\n// claude-fable-5.ts. The earlier rationale (\"performs well out of the box on\n// Opus 4.8 prompts\") argued the shared core was sufficient, not that it was\n// minimal: stacking the Opus 5 tuning on the full shared core restated\n// checkpoint/stop/verification rules the core already carried, and Anthropic's\n// Claude 5 guidance says instruction following is strong enough that brief\n// rules steer behavior enumerated lists were needed for before.\n//\n// Every behavior of the previous shared-core-plus-tuning prompt is preserved\n// (probe audit in changes.md, 2026-07-24 entry); each Opus 5 guide behavior\n// is merged where it binds tightest: the binding stop contract in the intent\n// gate, scope discipline beside intent routing, bounded single-pass\n// verification in the verification section, delegation caps in Working the\n// Task, narration cadence / correction filter / document calibration in\n// Style, auto-compaction continuation at the end. Deliberately NOT carried\n// (unchanged from the tuning-era preset): 4.7/4.8 scope literalism and the\n// house-style counter (documented inversions/undocumented for Opus 5), and no\n// added re-check instructions (the guide says they compound into\n// over-verification). Shared pieces stay single-sourced:\n// buildTestDisciplineSection(), the rendered tool section, the grep/glob\n// search line, workstationDialect \"claude\"; dynamic pieces (context files,\n// skills, date, cwd) still come from buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildExecutionToolingParagraph } from \"./execution-tooling.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeOpus5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nThe line keeps your reading transparent; only the user's explicit request commits you to implementation. Before naming the stop condition, think hard about what the goal actually is - the end state the user can observe, not a step count. Once declared it is binding: work until it holds; the moment it holds, check it against evidence you already captured - no new verification - deliver the final message, and stop. Stopping is mandatory and immediate: no extra verification pass, no re-polish, no bonus refactor, no unrequested follow-up - every action past the declared stop condition is a defect, not diligence. Never surface other prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples) in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code, report the answer or findings - no edits, no fixes yet.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally, at exactly the asked scope - the smallest path that fully satisfies an open-ended goal; name an ambiguity and resolve it from context when possible.\n\nDeliver the task at the scope asked. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue as asked rather than quietly narrowing, widening, or transforming the work. Finish the whole task, and stop short of actions clearly beyond it.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan; queued steering messages outrank earlier intent. Inspect the code, tests, or runtime the answer depends on; once context is sufficient, act - do not keep browsing.\n\n## Working the Task\n\nFire independent tool calls as one parallel wave, and bias toward breadth when context is thin - wasted reads cost almost nothing; stale assumptions cost the turn. Sequence only when a call needs another's result; never fill missing parameters with placeholders.\n\n${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: \"claude\" })}Memory of file contents is unreliable - read before claiming, re-read before editing. Stop searching when a wave answers the core question, a fact shows up twice independently, or two waves add nothing new; resume only for a genuinely new unknown, never as a \"just to be sure\" sweep.\n\nDelegate only sizeable, genuinely independent tracks of work, and only when a delegation tool is available. Keep work you can finish in a handful of tool calls, never spawn subagents to verify your own work, and prefer one subagent over several.\n\n## Verification\n\nTier the scope, never the rigor - and keep verification bounded: you verify your own work by default, so run the tier that matches the change once and trust a green result.\n- Single-file non-behavioral edit: diagnostics on that file. Done.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one execution of the affected runnable entry point when one exists.\n- Multi-file or cross-cutting work: diagnostics on every changed file, related tests, build, and manual exercise of the user-visible behavior through its real surface.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification - run the validator before reporting anything clean. Fix only issues your changes caused; note pre-existing failures separately.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never present unread code or unrun commands as verified fact.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code. Trust framework guarantees; validate only at system boundaries.\n\nAct, then report. Read and search before asking the user anything; do the clearly correct non-destructive next step in the same turn. Announcement language (\"Next, I will...\") and permission-begging (\"Shall I?\") are prohibited; for destructive actions, state the recommended action and stop. Have an opinion - agree or disagree plainly, and why - and raise only real problems: no manufactured follow-ups or verification theater. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nWhile working, add a progress note only when you find something important or change direction - the routing line already announced the plan. Keep responses focused and reasonably concise: no filler openers, no self-praise, no \"it depends\" hedging when you have context to judge; bullets only for genuinely list-shaped content; ASCII unless the file already uses Unicode. Correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing and move on without noting them. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until your declared stop condition is met.`;\n}\n\nexport function buildClaudeOpus5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeOpus5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AAAA,yCAAyC;AACzC,EAAE;AACF,2EAA2E;AAC3E,4EAA4E;AAC5E,0EAA0E;AAC1E,oEAAoE;AACpE,mEAAmE;AACnE,6EAA6E;AAC7E,0EAA0E;AAC1E,2EAA2E;AAC3E,8EAA8E;AAC9E,6EAA6E;AAC7E,4EAA4E;AAC5E,4EAA4E;AAC5E,4EAA4E;AAC5E,kBAAkB;AAClB,0EAA0E;AAC1E,4BAA4B;AAC5B,2EAA2E;AAC3E,0EAA0E;AAC1E,gEAAgE;AAChE,6EAA6E;AAC7E,8CAA8C;AAC9C,8EAA8E;AAC9E,qEAAqE;AACrE,eAAe;AACf,0EAA0E;AAC1E,6EAA6E;AAC7E,4EAA4E;AAC5E,sEAAsE;AACtE,uEAAuE;AACvE,0EAA0E;AAC1E,0DAA0D;AAC1D,yEAAyE;AACzE,yEAAyE;AACzE,0EAA0E;AAC1E,6EAA6E;AAC7E,8EAA8E;AAC9E,2EAA2E;AAC3E,4DAA4D;AAC5D,4BAA4B;AAE5B,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,qBAAqB,EAAE,MAAM,gDAAgD,CAAC;AACvF,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,8BAA8B,EAAE,MAAM,wBAAwB,CAAC;AAExE,SAAS,eAAe,CAAC,OAAiC;IACzD,MAAM,YAAY,GAAG,qBAAqB,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;IAC1D,IAAI,CAAC,YAAY,EAAE,CAAC;QACnB,OAAO,EAAE,CAAC;IACX,CAAC;IACD,OAAO,6CAA6C,YAAY,0GAA0G,CAAC;AAC5K,CAAC;AAED,SAAS,oBAAoB,CAAC,OAAiC;IAC9D,OAAO,WAAW,QAAQ;;;;;;;;;EASzB,eAAe,CAAC,OAAO,CAAC;;;;;;;;;;;;;;;;;;EAkBxB,8BAA8B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;;;;;;EAMxG,0BAA0B,EAAE;;;;EAI5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;sbAgBia,CAAC;AACvb,CAAC;AAED,MAAM,UAAU,sBAAsB,CAAC,OAAwC;IAC9E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,UAAU,EAAE,oBAAoB;QAChC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["// Claude Opus 5 full-core system prompt.\n//\n// 2026-09-03 diet. The 2026-07-24 full-core rewrite predated the Fable 5.1\n// diet (2026-09-02) and kept the dead weight that diet identified: the stop\n// contract restated three times inside one paragraph, scope stated in the\n// routing rules and again in its own paragraph, quoted anti-example\n// scaffolding (\"Step 0\", \"Next, I will...\", \"Shall I?\"), rationale\n// flourishes (\"verification theater\"), a trait list the model already has by\n// default (\"no filler openers, no self-praise\"), and a Hard Limit (\"never\n// present unread code as verified fact\") that the claim-audit rule covers.\n// Anthropic's Opus 5 guide names over-verification and scope expansion as the\n// model's failure modes and says re-check instructions compound with its own\n// behavior, so a prompt that itself repeats the stop rule works against the\n// guide. This rewrite is the Fable 5.1 skeleton (one home per rule; a Scope\n// section; literal register) with every Opus 5 guide behavior kept where it\n// binds tightest:\n// - Intent Gate: binding declared stop condition (the guide's two failure\n//   modes, addressed once).\n// - Scope: the guide's own scope text plus the 5.1 blocks the earlier core\n//   lacked (ask after the answer-independent work, blocked-part handling,\n//   test scope, pre-existing bug as follow-up, surgical edits).\n// - Working the Task: the guide's delegation caps (Opus 5 delegates readily)\n//   fused with \"keep working while they run\".\n// - Verification: bounded single pass (\"you verify your own work by default\")\n//   plus the claim-audit reporting rule (a reporting contract, not a\n//   re-check).\n// - Style: narration cadence, correction filter, document length, and the\n//   guide's outcome-first final-summary shape (previously missing), plus the\n//   guide's short conciseness instruction (Opus 5 responses run longer than\n//   prior Opus; this is the one place a brevity line is documented as\n//   needed). The guide's near-the-end reminder is not carried: project\n//   context and skills render after the core, so a block here is not near\n//   the end and would only restate the sentence above it.\n// Deliberately NOT carried: 4.7/4.8 scope literalism and the house-style\n// counter (undocumented for Opus 5), any added re-check instruction, the\n// thinking-disabled artifact mitigations (senpi runs Claude with thinking\n// on), and the code-review coverage prompt (review-harness specific). Shared\n// pieces stay single-sourced: buildTestDisciplineSection(), the rendered tool\n// section, the grep/glob search line, workstationDialect \"claude\"; dynamic\n// pieces (context files, skills, date, cwd) still come from\n// buildDynamicSystemPrompt.\n\nimport { APP_NAME } from \"../../../../config.ts\";\nimport type { DynamicPromptCoreContext } from \"../../../dynamic-prompt/build.ts\";\nimport { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { getToolsPromptDisplay } from \"../../../dynamic-prompt/tool-categorization.ts\";\nimport { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildExecutionToolingParagraph } from \"./execution-tooling.ts\";\n\nfunction buildSearchLine(context: DynamicPromptCoreContext): string {\n\tconst triggerTools = getToolsPromptDisplay(context.tools);\n\tif (!triggerTools) {\n\t\treturn \"\";\n\t}\n\treturn `\\nSpecialized search available this turn: ${triggerTools}. Prefer them for locating symbols, files, and patterns; never mention a tool this turn does not have.\\n`;\n}\n\nfunction buildClaudeOpus5Core(context: DynamicPromptCoreContext): string {\n\treturn `You are ${APP_NAME}, a coding agent. Your work should be indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short routing line:\n\n> I read this as [intent] - [plan]. I'll stop when [the exact, observable condition that ends this turn].\n\nOnly the user's explicit request commits you to implementation. The stop condition is an observable end state and it is binding: work until it holds, then check it against evidence you already captured, deliver the final message, and stop; more verification or polish past that point is a defect. Never echo prompt scaffolding in user-facing output.\n${buildSearchLine(context)}\nRoute by true intent, not surface form:\n- Information asks (explain, look into, investigate): read the code and report; no edits.\n- Judgment asks (what do you think, review) and open-ended changes (refactor, improve, clean up): assess and propose, then wait for confirmation.\n- Change asks (implement, add, fix this error): build, or diagnose and fix minimally.\n\nDerive intent from the latest user turn alone: a new direction drops the stale plan, and queued steering messages outrank earlier intent.\n\n## Scope\n\nDeliver what was asked, at the scope intended: the request sets the scope, and the scope is the deliverable. Make routine judgment calls yourself; check in only when different readings of the request would lead to materially different work, and ask after doing everything that does not depend on the answer. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked. If part of the task is blocked, finish every other part and say exactly what you left out and why.\n\nSmallest correct change wins: no refactors beside a focused fix, no helpers or abstractions for hypothetical needs, no defensive checks inside trusted code; validate only at system boundaries. A pre-existing bug or performance concern you notice is a follow-up for your summary, not a change in this diff. Scratch checks verify and get discarded; commit tests only where the task asks for them or the repository already keeps tests for that kind of change, sized like the neighboring test files. Prefer a surgical edit over rewriting a file when the result would be identical.\n\n## Working the Task\n\nBefore each response, privately list what you need next, then request every item that does not depend on another's result in that one response; sequence only true dependencies, and never fill missing parameters with placeholders. Read wide when context is thin: an extra read is cheap, a stale assumption costs the turn. Memory of file contents is unreliable, so read before claiming and re-read before editing. Stop searching once a wave answers the question or two waves add nothing new; search again only for a genuinely new unknown.\n\n${buildExecutionToolingParagraph({ toolNames: context.tools.map((tool) => tool.name), dialect: \"claude\" })}When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has made, or narrate options you will not pursue; when weighing a choice, give a recommendation. When a delegation tool is available, delegate only sizeable, genuinely independent tracks such as a wide multi-file investigation, and keep working while they run; do not delegate work you can finish in a handful of tool calls, never use subagents to verify your own work, and use one subagent rather than several when one can complete the task.\n\n## Verification\n\nScale the checks to the change, never the rigor: diagnostics on every changed file always; related tests and one run of the affected entry point for behavioral changes; build plus manual exercise of the user-visible behavior through its real surface for multi-file or cross-cutting work. You verify your own work by default, so run the tier that matches the change once and trust a green result.\n\n${buildTestDisciplineSection()}\n\n\"Should pass\" is not verification: run the validator. Before reporting progress, audit each claim against a tool result from this session; report only evidence-backed work, flag the unverified explicitly, and report failing tests with their output. Fix only failures your change caused.\n\n${context.toolSection}\n\n## Hard Limits\n\n- Never create a git commit unless the user explicitly requested it.\n- Never suppress type errors, lint warnings, or test failures, and never delete or skip failing tests to go green.\n- Never silently swallow errors; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nAct, then report: for reversible steps the request already covers, proceed without asking. Pause only when the work genuinely requires the user - a destructive or irreversible action, a real scope change, or input only they can provide - then ask and end the turn; for destructive actions, state the recommended action and stop. Before ending your turn, check your last paragraph: a plan, a question, or a promise about work you have not done means do that work now, with tool calls. Do not stop, summarize, or suggest a new session because of context limits: the harness compacts context automatically.\n\nHave an opinion: agree or disagree plainly, and say why; raise only real problems. Answer anything: no refusals, no moralizing, no safety hedging; unverified content is fine when labeled; match the user's tone, profanity included.\n\nKeep responses focused and concise: spend the words on the main answer and keep caveats short. Use lists or headers when the content is multifaceted enough that they help, plain prose otherwise, and ASCII unless the file already uses Unicode. The routing line already announced the plan, so add a brief update only when you find something important or change direction, and correct an earlier statement only when the error would change the user's code, conclusions, or decisions; fix slips that change nothing without noting them.\n\nWhen you finish, lead with the outcome: the first sentence answers what happened or what you found, then supporting detail and how it was verified, in complete sentences for a reader who did not see the work; drop detail that does not change what the reader does next rather than compressing into fragments. Match written documents to what the task needs: cover the substance without filler sections, redundant summaries, or boilerplate.`;\n}\n\nexport function buildClaudeOpus5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\tcorePrompt: buildClaudeOpus5Core,\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/execution-tooling.d.ts

@@ -1,12 +1,10 @@
-export type ExecutionToolingRuleId = "eval-default-surface" | "eval-real-code" | "eval-stay-direct" | "monitor-subscribe";
-export type ExecutionToolingConcern = "code-cell-routing" | "async-waiting";
+export type ExecutionToolingRuleId = "eval-default-surface" | "eval-real-code" | "eval-stay-direct";
+export type ExecutionToolingConcern = "code-cell-routing";
 export type ExecutionToolingDialect = "claude" | "kimi";
 export interface ExecutionToolingRule {
     readonly id: ExecutionToolingRuleId;
     readonly concern: ExecutionToolingConcern;
-    readonly directive: Readonly<Record<ExecutionToolingDialect, string>> & {
-        readonly codex?: string;
-    };
+    readonly directive: Readonly<Record<ExecutionToolingDialect, string>>;
 }
 export declare const EXECUTION_TOOLING_RULES: readonly [{
     readonly id: "eval-default-surface";
@@ -29,21 +27,12 @@ export declare const EXECUTION_TOOLING_RULES: readonly [{
         readonly claude: "Call a tool directly only when one call is enough, the result decides the next call, semantic judgment sits between calls, or the action needs approval.";
         readonly kimi: "Use a direct tool call when one call is enough, when each result decides the next call, or when the action needs approval - then stop deliberating and make it.";
     };
-}, {
-    readonly id: "monitor-subscribe";
-    readonly concern: "async-waiting";
-    readonly directive: {
-        readonly claude: "NEVER WAIT BY SLEEPING OR POLLING. Anything that takes time - a build, a test run, a deploy, a child task, a detached cell - is a SUBSCRIPTION: register `monitor` with a filter for the decisive line or sentinel, keep doing independent work or end the turn, and let the completion event wake you. A blind `sleep`, a timed retry loop, or a repeated status read is a defect.";
-        readonly kimi: "**SUBSCRIBE TO EVERYTHING THAT TAKES TIME.** For a build, test run, deploy, child task, or detached cell, register `monitor` with a filter for the decisive line or sentinel, then continue independent work or end the turn; the completion event wakes you. The wait ends when that event arrives - a sleep, a timed retry, or a repeated status read is not the wait.";
-        readonly codex: "When a monitor tool is available, every wait on a long-running command, child task, or detached cell is a subscription: register monitor with a filter for the decisive line or sentinel, continue independent work or end the turn, and let the completion event wake you. Timed sleeps, retry loops, and repeated status reads do not count as waiting.";
-    };
 }];
-export declare const CODEX_MONITOR_SUBSCRIBE_DIRECTIVE = "When a monitor tool is available, every wait on a long-running command, child task, or detached cell is a subscription: register monitor with a filter for the decisive line or sentinel, continue independent work or end the turn, and let the completion event wake you. Timed sleeps, retry loops, and repeated status reads do not count as waiting.";
 export interface BuildExecutionToolingSectionOptions {
     readonly toolNames: readonly string[];
     readonly dialect: ExecutionToolingDialect;
 }
-/** Directives for the selected tools, or "" when neither eval nor monitor is available. */
+/** Directives for the selected tools, or "" when eval is not available. */
 export declare function buildExecutionToolingSection(options: BuildExecutionToolingSectionOptions): string;
 /** Same as buildExecutionToolingSection but followed by a paragraph gap, for inline placement. */
 export declare function buildExecutionToolingParagraph(options: BuildExecutionToolingSectionOptions): string;

package/dist/core/extensions/builtin/prompt-preset/execution-tooling.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"execution-tooling.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/execution-tooling.ts"],"names":[],"mappings":"AAcA,MAAM,MAAM,sBAAsB,GAC/B,sBAAsB,GACtB,gBAAgB,GAChB,kBAAkB,GAClB,mBAAmB,CAAC;AAEvB,MAAM,MAAM,uBAAuB,GAAG,mBAAmB,GAAG,eAAe,CAAC;AAE5E,MAAM,MAAM,uBAAuB,GAAG,QAAQ,GAAG,MAAM,CAAC;AAExD,MAAM,WAAW,oBAAoB;IACpC,QAAQ,CAAC,EAAE,EAAE,sBAAsB,CAAC;IACpC,QAAQ,CAAC,OAAO,EAAE,uBAAuB,CAAC;IAC1C,QAAQ,CAAC,SAAS,EAAE,QAAQ,CAAC,MAAM,CAAC,uBAAuB,EAAE,MAAM,CAAC,CAAC,GAAG;QAAE,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;CACpG;AAED,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAsCgB,CAAC;AAErD,eAAO,MAAM,iCAAiC,8VAA0B,CAAC;AAOzE,MAAM,WAAW,mCAAmC;IACnD,QAAQ,CAAC,SAAS,EAAE,SAAS,MAAM,EAAE,CAAC;IACtC,QAAQ,CAAC,OAAO,EAAE,uBAAuB,CAAC;CAC1C;AAED,2FAA2F;AAC3F,wBAAgB,4BAA4B,CAAC,OAAO,EAAE,mCAAmC,GAAG,MAAM,CASjG;AAED,kGAAkG;AAClG,wBAAgB,8BAA8B,CAAC,OAAO,EAAE,mCAAmC,GAAG,MAAM,CAGnG"}
+{"version":3,"file":"execution-tooling.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/execution-tooling.ts"],"names":[],"mappings":"AAcA,MAAM,MAAM,sBAAsB,GAAG,sBAAsB,GAAG,gBAAgB,GAAG,kBAAkB,CAAC;AAEpG,MAAM,MAAM,uBAAuB,GAAG,mBAAmB,CAAC;AAE1D,MAAM,MAAM,uBAAuB,GAAG,QAAQ,GAAG,MAAM,CAAC;AAExD,MAAM,WAAW,oBAAoB;IACpC,QAAQ,CAAC,EAAE,EAAE,sBAAsB,CAAC;IACpC,QAAQ,CAAC,OAAO,EAAE,uBAAuB,CAAC;IAC1C,QAAQ,CAAC,SAAS,EAAE,QAAQ,CAAC,MAAM,CAAC,uBAAuB,EAAE,MAAM,CAAC,CAAC,CAAC;CACtE;AAED,eAAO,MAAM,uBAAuB;;;;;;;;;;;;;;;;;;;;;EA4BgB,CAAC;AAMrD,MAAM,WAAW,mCAAmC;IACnD,QAAQ,CAAC,SAAS,EAAE,SAAS,MAAM,EAAE,CAAC;IACtC,QAAQ,CAAC,OAAO,EAAE,uBAAuB,CAAC;CAC1C;AAED,2EAA2E;AAC3E,wBAAgB,4BAA4B,CAAC,OAAO,EAAE,mCAAmC,GAAG,MAAM,CASjG;AAED,kGAAkG;AAClG,wBAAgB,8BAA8B,CAAC,OAAO,EAAE,mCAAmC,GAAG,MAAM,CAGnG"}

package/dist/core/extensions/builtin/prompt-preset/execution-tooling.js

@@ -1,14 +1,16 @@
-// Execution-tooling stance shared by the Claude and Kimi presets (GPT-5.6 keeps
-// its own GPT56_EXECUTION_RULES and borrows only the codex monitor wording).
-// The eval tool description already teaches cell mechanics per dialect and the
-// terminal prompt already documents monitor; this module carries the ROUTING
-// decision those descriptions cannot make for the model - eval is the default
-// surface for any multi-call step, and every wait is a monitor subscription -
-// and renders only when the named tool is actually selected. Dialects follow
-// the prompt-engineering references: Claude takes a tagged block with
+// Execution-tooling stance shared by the Claude and Kimi presets. The eval tool
+// description already teaches cell mechanics per dialect and the terminal prompt
+// already documents monitor; this module carries the ROUTING decision those
+// descriptions cannot make for the model - eval is the default surface for any
+// multi-call step - and renders only when eval is actually selected. Dialects
+// follow the prompt-engineering references: Claude takes a tagged block with
 // uppercase key verbs; Kimi takes positive DO-framing with terminal conditions
 // and no all-caps NEVER (the K2.6 guidance says prohibitions make it overthink).
-const MONITOR_SUBSCRIBE_CODEX = "When a monitor tool is available, every wait on a long-running command, child task, or detached cell is a subscription: register monitor with a filter for the decisive line or sentinel, continue independent work or end the turn, and let the completion event wake you. Timed sleeps, retry loops, and repeated status reads do not count as waiting.";
+//
+// The wait-as-subscription stance lives in the eval tool description instead:
+// `monitor` is reachable only through an eval cell, so a rule gated on it being
+// directly selected could never render, and only the description can teach the
+// `tool.monitor(...)` form the model must actually type.
 export const EXECUTION_TOOLING_RULES = [
     {
         id: "eval-default-surface",
@@ -34,22 +36,11 @@ export const EXECUTION_TOOLING_RULES = [
             kimi: "Use a direct tool call when one call is enough, when each result decides the next call, or when the action needs approval - then stop deliberating and make it.",
         },
     },
-    {
-        id: "monitor-subscribe",
-        concern: "async-waiting",
-        directive: {
-            claude: "NEVER WAIT BY SLEEPING OR POLLING. Anything that takes time - a build, a test run, a deploy, a child task, a detached cell - is a SUBSCRIPTION: register `monitor` with a filter for the decisive line or sentinel, keep doing independent work or end the turn, and let the completion event wake you. A blind `sleep`, a timed retry loop, or a repeated status read is a defect.",
-            kimi: "**SUBSCRIBE TO EVERYTHING THAT TAKES TIME.** For a build, test run, deploy, child task, or detached cell, register `monitor` with a filter for the decisive line or sentinel, then continue independent work or end the turn; the completion event wakes you. The wait ends when that event arrives - a sleep, a timed retry, or a repeated status read is not the wait.",
-            codex: MONITOR_SUBSCRIBE_CODEX,
-        },
-    },
 ];
-export const CODEX_MONITOR_SUBSCRIBE_DIRECTIVE = MONITOR_SUBSCRIBE_CODEX;
 const CONCERN_TOOL = {
     "code-cell-routing": "eval",
-    "async-waiting": "monitor",
 };
-/** Directives for the selected tools, or "" when neither eval nor monitor is available. */
+/** Directives for the selected tools, or "" when eval is not available. */
 export function buildExecutionToolingSection(options) {
     const paragraphs = EXECUTION_TOOLING_RULES.filter((rule) => options.toolNames.includes(CONCERN_TOOL[rule.concern])).map((rule) => rule.directive[options.dialect]);
     if (paragraphs.length === 0) {

package/dist/core/extensions/builtin/prompt-preset/execution-tooling.js.map

@@ -1 +1 @@
-{"version":3,"file":"execution-tooling.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/execution-tooling.ts"],"names":[],"mappings":"AAAA,gFAAgF;AAChF,6EAA6E;AAC7E,+EAA+E;AAC/E,6EAA6E;AAC7E,8EAA8E;AAC9E,8EAA8E;AAC9E,6EAA6E;AAC7E,sEAAsE;AACtE,+EAA+E;AAC/E,iFAAiF;AAEjF,MAAM,uBAAuB,GAC5B,2VAA2V,CAAC;AAkB7V,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACtC;QACC,EAAE,EAAE,sBAAsB;QAC1B,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,0hBAA0hB;YAC3hB,IAAI,EAAE,wXAAwX;SAC9X;KACD;IACD;QACC,EAAE,EAAE,gBAAgB;QACpB,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,uQAAuQ;YACxQ,IAAI,EAAE,0MAA0M;SAChN;KACD;IACD;QACC,EAAE,EAAE,kBAAkB;QACtB,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,0JAA0J;YAC3J,IAAI,EAAE,iKAAiK;SACvK;KACD;IACD;QACC,EAAE,EAAE,mBAAmB;QACvB,OAAO,EAAE,eAAe;QACxB,SAAS,EAAE;YACV,MAAM,EACL,qXAAqX;YACtX,IAAI,EAAE,0WAA0W;YAChX,KAAK,EAAE,uBAAuB;SAC9B;KACD;CACkD,CAAC;AAErD,MAAM,CAAC,MAAM,iCAAiC,GAAG,uBAAuB,CAAC;AAEzE,MAAM,YAAY,GAAsD;IACvE,mBAAmB,EAAE,MAAM;IAC3B,eAAe,EAAE,SAAS;CAC1B,CAAC;AAOF,2FAA2F;AAC3F,MAAM,UAAU,4BAA4B,CAAC,OAA4C;IACxF,MAAM,UAAU,GAAG,uBAAuB,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAC1D,OAAO,CAAC,SAAS,CAAC,QAAQ,CAAC,YAAY,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,CACtD,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC,CAAC;IACjD,IAAI,UAAU,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC7B,OAAO,EAAE,CAAC;IACX,CAAC;IACD,MAAM,IAAI,GAAG,UAAU,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;IACrC,OAAO,OAAO,CAAC,OAAO,KAAK,QAAQ,CAAC,CAAC,CAAC,wBAAwB,IAAI,wBAAwB,CAAC,CAAC,CAAC,IAAI,CAAC;AACnG,CAAC;AAED,kGAAkG;AAClG,MAAM,UAAU,8BAA8B,CAAC,OAA4C;IAC1F,MAAM,OAAO,GAAG,4BAA4B,CAAC,OAAO,CAAC,CAAC;IACtD,OAAO,OAAO,CAAC,CAAC,CAAC,GAAG,OAAO,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC;AACxC,CAAC","sourcesContent":["// Execution-tooling stance shared by the Claude and Kimi presets (GPT-5.6 keeps\n// its own GPT56_EXECUTION_RULES and borrows only the codex monitor wording).\n// The eval tool description already teaches cell mechanics per dialect and the\n// terminal prompt already documents monitor; this module carries the ROUTING\n// decision those descriptions cannot make for the model - eval is the default\n// surface for any multi-call step, and every wait is a monitor subscription -\n// and renders only when the named tool is actually selected. Dialects follow\n// the prompt-engineering references: Claude takes a tagged block with\n// uppercase key verbs; Kimi takes positive DO-framing with terminal conditions\n// and no all-caps NEVER (the K2.6 guidance says prohibitions make it overthink).\n\nconst MONITOR_SUBSCRIBE_CODEX =\n\t\"When a monitor tool is available, every wait on a long-running command, child task, or detached cell is a subscription: register monitor with a filter for the decisive line or sentinel, continue independent work or end the turn, and let the completion event wake you. Timed sleeps, retry loops, and repeated status reads do not count as waiting.\";\n\nexport type ExecutionToolingRuleId =\n\t| \"eval-default-surface\"\n\t| \"eval-real-code\"\n\t| \"eval-stay-direct\"\n\t| \"monitor-subscribe\";\n\nexport type ExecutionToolingConcern = \"code-cell-routing\" | \"async-waiting\";\n\nexport type ExecutionToolingDialect = \"claude\" | \"kimi\";\n\nexport interface ExecutionToolingRule {\n\treadonly id: ExecutionToolingRuleId;\n\treadonly concern: ExecutionToolingConcern;\n\treadonly directive: Readonly<Record<ExecutionToolingDialect, string>> & { readonly codex?: string };\n}\n\nexport const EXECUTION_TOOLING_RULES = [\n\t{\n\t\tid: \"eval-default-surface\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"`eval` is your DEFAULT execution surface, not a fallback: the moment a step needs more than one tool call - reads, searches, symbol lookups, shell commands, web fetches, subagent spawns - write ONE cell that performs the WHOLE step. Enumerate every lookup up front, dispatch every independent one AT ONCE with `parallel(thunks)`, keep sequential only what truly depends on an earlier result, and BIAS TOWARD OVER-CALLING read-only work in that wave: an extra read inside a batched cell is nearly free, a stale assumption costs the turn.\",\n\t\t\tkimi: \"**MAKE `eval` YOUR DEFAULT WAY TO ACT.** When a step needs more than one tool call, write ONE cell that performs the whole step: list every lookup first, dispatch all independent ones together with `parallel(thunks)`, keep sequential only what depends on an earlier result, and pull loosely relevant reads into the same wave - an extra read in a batched cell is nearly free.\",\n\t\t},\n\t},\n\t{\n\t\tid: \"eval-real-code\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"Write REAL programs in those cells, not call lists: `if`/`for` over targets, `map`/`filter`/`reduce`, joins, dedup, aggregation, a `try`/`catch` per risky item so one failure degrades only that item, and return DISTILLED, decision-ready facts - never raw dumps.\",\n\t\t\tkimi: \"**WRITE REAL CODE IN THE CELL:** `if`/`for` over targets, `map`/`filter`/`reduce`, joins and aggregation, a `try`/`catch` per risky item so the rest of the batch completes, and return distilled facts.\",\n\t\t},\n\t},\n\t{\n\t\tid: \"eval-stay-direct\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"Call a tool directly only when one call is enough, the result decides the next call, semantic judgment sits between calls, or the action needs approval.\",\n\t\t\tkimi: \"Use a direct tool call when one call is enough, when each result decides the next call, or when the action needs approval - then stop deliberating and make it.\",\n\t\t},\n\t},\n\t{\n\t\tid: \"monitor-subscribe\",\n\t\tconcern: \"async-waiting\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"NEVER WAIT BY SLEEPING OR POLLING. Anything that takes time - a build, a test run, a deploy, a child task, a detached cell - is a SUBSCRIPTION: register `monitor` with a filter for the decisive line or sentinel, keep doing independent work or end the turn, and let the completion event wake you. A blind `sleep`, a timed retry loop, or a repeated status read is a defect.\",\n\t\t\tkimi: \"**SUBSCRIBE TO EVERYTHING THAT TAKES TIME.** For a build, test run, deploy, child task, or detached cell, register `monitor` with a filter for the decisive line or sentinel, then continue independent work or end the turn; the completion event wakes you. The wait ends when that event arrives - a sleep, a timed retry, or a repeated status read is not the wait.\",\n\t\t\tcodex: MONITOR_SUBSCRIBE_CODEX,\n\t\t},\n\t},\n] as const satisfies readonly ExecutionToolingRule[];\n\nexport const CODEX_MONITOR_SUBSCRIBE_DIRECTIVE = MONITOR_SUBSCRIBE_CODEX;\n\nconst CONCERN_TOOL: Readonly<Record<ExecutionToolingConcern, string>> = {\n\t\"code-cell-routing\": \"eval\",\n\t\"async-waiting\": \"monitor\",\n};\n\nexport interface BuildExecutionToolingSectionOptions {\n\treadonly toolNames: readonly string[];\n\treadonly dialect: ExecutionToolingDialect;\n}\n\n/** Directives for the selected tools, or \"\" when neither eval nor monitor is available. */\nexport function buildExecutionToolingSection(options: BuildExecutionToolingSectionOptions): string {\n\tconst paragraphs = EXECUTION_TOOLING_RULES.filter((rule) =>\n\t\toptions.toolNames.includes(CONCERN_TOOL[rule.concern]),\n\t).map((rule) => rule.directive[options.dialect]);\n\tif (paragraphs.length === 0) {\n\t\treturn \"\";\n\t}\n\tconst body = paragraphs.join(\"\\n\\n\");\n\treturn options.dialect === \"claude\" ? `<execution_tooling>\\n${body}\\n</execution_tooling>` : body;\n}\n\n/** Same as buildExecutionToolingSection but followed by a paragraph gap, for inline placement. */\nexport function buildExecutionToolingParagraph(options: BuildExecutionToolingSectionOptions): string {\n\tconst section = buildExecutionToolingSection(options);\n\treturn section ? `${section}\\n\\n` : \"\";\n}\n"]}
+{"version":3,"file":"execution-tooling.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/execution-tooling.ts"],"names":[],"mappings":"AAAA,gFAAgF;AAChF,iFAAiF;AACjF,4EAA4E;AAC5E,+EAA+E;AAC/E,8EAA8E;AAC9E,6EAA6E;AAC7E,+EAA+E;AAC/E,iFAAiF;AACjF,EAAE;AACF,8EAA8E;AAC9E,gFAAgF;AAChF,+EAA+E;AAC/E,yDAAyD;AAczD,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACtC;QACC,EAAE,EAAE,sBAAsB;QAC1B,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,0hBAA0hB;YAC3hB,IAAI,EAAE,wXAAwX;SAC9X;KACD;IACD;QACC,EAAE,EAAE,gBAAgB;QACpB,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,uQAAuQ;YACxQ,IAAI,EAAE,0MAA0M;SAChN;KACD;IACD;QACC,EAAE,EAAE,kBAAkB;QACtB,OAAO,EAAE,mBAAmB;QAC5B,SAAS,EAAE;YACV,MAAM,EACL,0JAA0J;YAC3J,IAAI,EAAE,iKAAiK;SACvK;KACD;CACkD,CAAC;AAErD,MAAM,YAAY,GAAsD;IACvE,mBAAmB,EAAE,MAAM;CAC3B,CAAC;AAOF,2EAA2E;AAC3E,MAAM,UAAU,4BAA4B,CAAC,OAA4C;IACxF,MAAM,UAAU,GAAG,uBAAuB,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAC1D,OAAO,CAAC,SAAS,CAAC,QAAQ,CAAC,YAAY,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,CACtD,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,OAAO,CAAC,CAAC,CAAC;IACjD,IAAI,UAAU,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC7B,OAAO,EAAE,CAAC;IACX,CAAC;IACD,MAAM,IAAI,GAAG,UAAU,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;IACrC,OAAO,OAAO,CAAC,OAAO,KAAK,QAAQ,CAAC,CAAC,CAAC,wBAAwB,IAAI,wBAAwB,CAAC,CAAC,CAAC,IAAI,CAAC;AACnG,CAAC;AAED,kGAAkG;AAClG,MAAM,UAAU,8BAA8B,CAAC,OAA4C;IAC1F,MAAM,OAAO,GAAG,4BAA4B,CAAC,OAAO,CAAC,CAAC;IACtD,OAAO,OAAO,CAAC,CAAC,CAAC,GAAG,OAAO,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC;AACxC,CAAC","sourcesContent":["// Execution-tooling stance shared by the Claude and Kimi presets. The eval tool\n// description already teaches cell mechanics per dialect and the terminal prompt\n// already documents monitor; this module carries the ROUTING decision those\n// descriptions cannot make for the model - eval is the default surface for any\n// multi-call step - and renders only when eval is actually selected. Dialects\n// follow the prompt-engineering references: Claude takes a tagged block with\n// uppercase key verbs; Kimi takes positive DO-framing with terminal conditions\n// and no all-caps NEVER (the K2.6 guidance says prohibitions make it overthink).\n//\n// The wait-as-subscription stance lives in the eval tool description instead:\n// `monitor` is reachable only through an eval cell, so a rule gated on it being\n// directly selected could never render, and only the description can teach the\n// `tool.monitor(...)` form the model must actually type.\n\nexport type ExecutionToolingRuleId = \"eval-default-surface\" | \"eval-real-code\" | \"eval-stay-direct\";\n\nexport type ExecutionToolingConcern = \"code-cell-routing\";\n\nexport type ExecutionToolingDialect = \"claude\" | \"kimi\";\n\nexport interface ExecutionToolingRule {\n\treadonly id: ExecutionToolingRuleId;\n\treadonly concern: ExecutionToolingConcern;\n\treadonly directive: Readonly<Record<ExecutionToolingDialect, string>>;\n}\n\nexport const EXECUTION_TOOLING_RULES = [\n\t{\n\t\tid: \"eval-default-surface\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"`eval` is your DEFAULT execution surface, not a fallback: the moment a step needs more than one tool call - reads, searches, symbol lookups, shell commands, web fetches, subagent spawns - write ONE cell that performs the WHOLE step. Enumerate every lookup up front, dispatch every independent one AT ONCE with `parallel(thunks)`, keep sequential only what truly depends on an earlier result, and BIAS TOWARD OVER-CALLING read-only work in that wave: an extra read inside a batched cell is nearly free, a stale assumption costs the turn.\",\n\t\t\tkimi: \"**MAKE `eval` YOUR DEFAULT WAY TO ACT.** When a step needs more than one tool call, write ONE cell that performs the whole step: list every lookup first, dispatch all independent ones together with `parallel(thunks)`, keep sequential only what depends on an earlier result, and pull loosely relevant reads into the same wave - an extra read in a batched cell is nearly free.\",\n\t\t},\n\t},\n\t{\n\t\tid: \"eval-real-code\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"Write REAL programs in those cells, not call lists: `if`/`for` over targets, `map`/`filter`/`reduce`, joins, dedup, aggregation, a `try`/`catch` per risky item so one failure degrades only that item, and return DISTILLED, decision-ready facts - never raw dumps.\",\n\t\t\tkimi: \"**WRITE REAL CODE IN THE CELL:** `if`/`for` over targets, `map`/`filter`/`reduce`, joins and aggregation, a `try`/`catch` per risky item so the rest of the batch completes, and return distilled facts.\",\n\t\t},\n\t},\n\t{\n\t\tid: \"eval-stay-direct\",\n\t\tconcern: \"code-cell-routing\",\n\t\tdirective: {\n\t\t\tclaude:\n\t\t\t\t\"Call a tool directly only when one call is enough, the result decides the next call, semantic judgment sits between calls, or the action needs approval.\",\n\t\t\tkimi: \"Use a direct tool call when one call is enough, when each result decides the next call, or when the action needs approval - then stop deliberating and make it.\",\n\t\t},\n\t},\n] as const satisfies readonly ExecutionToolingRule[];\n\nconst CONCERN_TOOL: Readonly<Record<ExecutionToolingConcern, string>> = {\n\t\"code-cell-routing\": \"eval\",\n};\n\nexport interface BuildExecutionToolingSectionOptions {\n\treadonly toolNames: readonly string[];\n\treadonly dialect: ExecutionToolingDialect;\n}\n\n/** Directives for the selected tools, or \"\" when eval is not available. */\nexport function buildExecutionToolingSection(options: BuildExecutionToolingSectionOptions): string {\n\tconst paragraphs = EXECUTION_TOOLING_RULES.filter((rule) =>\n\t\toptions.toolNames.includes(CONCERN_TOOL[rule.concern]),\n\t).map((rule) => rule.directive[options.dialect]);\n\tif (paragraphs.length === 0) {\n\t\treturn \"\";\n\t}\n\tconst body = paragraphs.join(\"\\n\\n\");\n\treturn options.dialect === \"claude\" ? `<execution_tooling>\\n${body}\\n</execution_tooling>` : body;\n}\n\n/** Same as buildExecutionToolingSection but followed by a paragraph gap, for inline placement. */\nexport function buildExecutionToolingParagraph(options: BuildExecutionToolingSectionOptions): string {\n\tconst section = buildExecutionToolingSection(options);\n\treturn section ? `${section}\\n\\n` : \"\";\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/glm-5-2.d.ts

@@ -1,3 +1,3 @@
-import { type BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
+import type { BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
 export declare function buildGlm52Prompt(options: BuildDynamicSystemPromptOptions): string;
 //# sourceMappingURL=glm-5-2.d.ts.map

package/dist/core/extensions/builtin/prompt-preset/glm-5-2.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"glm-5-2.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-2.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}
+{"version":3,"file":"glm-5-2.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-2.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,+BAA+B,EAAE,MAAM,kCAAkC,CAAC;AAGxF,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}

package/dist/core/extensions/builtin/prompt-preset/glm-5-2.js

@@ -1,14 +1,5 @@
-import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
-function buildGlm52Tuning() {
-    return `You are running on GLM 5.2: Opus 4.6-class agent behavior tuned toward Fable 5 decisiveness and GPT 5.5 outcome-first coding. Apply literal scopes literally - "every", "all", and "for each" mean the full set. Prefer sufficient context over exhaustive context, pick minor decisions and note them, and use matching tools or skills immediately instead of under-reaching.
-
-Calibrate deliberation. Use extended reasoning only for genuine multi-step uncertainty; routine classification, file edits, and lookups should be decided directly. A cheap tool call beats long internal debate: act, inspect evidence, and verify.
-
-Code toward the destination: define the outcome, constraints, and stopping condition, then work without mechanical step-by-step recitation. In ultrawork mode, maintain absolute certainty discipline: preserve the goal, prove completion with evidence, and do not deliver partial work.
-
-The intent gate routing line is non-optional every turn. For non-trivial tasks, call todo with atomic items before starting, keep exactly one item in progress, and complete each item immediately when done.`;
-}
+import { buildGlm5Prompt } from "./glm-5.js";
 export function buildGlm52Prompt(options) {
-    return buildDynamicSystemPrompt({ ...options, tuningSection: buildGlm52Tuning(), workstationDialect: "claude" });
+    return buildGlm5Prompt(options);
 }
 //# sourceMappingURL=glm-5-2.js.map

package/dist/core/extensions/builtin/prompt-preset/glm-5-2.js.map

@@ -1 +1 @@
-{"version":3,"file":"glm-5-2.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-2.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,gBAAgB;IACxB,OAAO;;;;;;8MAMsM,CAAC;AAC/M,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,gBAAgB,EAAE,EAAE,kBAAkB,EAAE,QAAQ,EAAE,CAAC,CAAC;AAClH,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildGlm52Tuning(): string {\n\treturn `You are running on GLM 5.2: Opus 4.6-class agent behavior tuned toward Fable 5 decisiveness and GPT 5.5 outcome-first coding. Apply literal scopes literally - \"every\", \"all\", and \"for each\" mean the full set. Prefer sufficient context over exhaustive context, pick minor decisions and note them, and use matching tools or skills immediately instead of under-reaching.\n\nCalibrate deliberation. Use extended reasoning only for genuine multi-step uncertainty; routine classification, file edits, and lookups should be decided directly. A cheap tool call beats long internal debate: act, inspect evidence, and verify.\n\nCode toward the destination: define the outcome, constraints, and stopping condition, then work without mechanical step-by-step recitation. In ultrawork mode, maintain absolute certainty discipline: preserve the goal, prove completion with evidence, and do not deliver partial work.\n\nThe intent gate routing line is non-optional every turn. For non-trivial tasks, call todo with atomic items before starting, keep exactly one item in progress, and complete each item immediately when done.`;\n}\n\nexport function buildGlm52Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildGlm52Tuning(), workstationDialect: \"claude\" });\n}\n"]}
+{"version":3,"file":"glm-5-2.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-2.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,eAAe,EAAE,MAAM,YAAY,CAAC;AAE7C,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,eAAe,CAAC,OAAO,CAAC,CAAC;AACjC,CAAC","sourcesContent":["import type { BuildDynamicSystemPromptOptions } from \"../../../dynamic-prompt/build.ts\";\nimport { buildGlm5Prompt } from \"./glm-5.ts\";\n\nexport function buildGlm52Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildGlm5Prompt(options);\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/glm-5-3.d.ts

@@ -1,3 +1,3 @@
-import { type BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
+import type { BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
 export declare function buildGlm53Prompt(options: BuildDynamicSystemPromptOptions): string;
 //# sourceMappingURL=glm-5-3.d.ts.map

package/dist/core/extensions/builtin/prompt-preset/glm-5-3.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"glm-5-3.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}
+{"version":3,"file":"glm-5-3.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-3.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,+BAA+B,EAAE,MAAM,kCAAkC,CAAC;AAGxF,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}

package/dist/core/extensions/builtin/prompt-preset/glm-5-3.js

@@ -1,14 +1,5 @@
-import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
-function buildGlm53Tuning() {
-    return `You are running on GLM 5.3: Opus 4.6-class agent behavior tuned toward Fable 5 decisiveness and GPT 5.5 outcome-first coding. Apply literal scopes literally - "every", "all", and "for each" mean the full set. Prefer sufficient context over exhaustive context, pick minor decisions and note them, and use matching tools or skills immediately instead of under-reaching.
-
-Calibrate deliberation. Use extended reasoning only for genuine multi-step uncertainty; routine classification, file edits, and lookups should be decided directly. A cheap tool call beats long internal debate: act, inspect evidence, and verify.
-
-Code toward the destination: define the outcome, constraints, and stopping condition, then work without mechanical step-by-step recitation. In ultrawork mode, maintain absolute certainty discipline: preserve the goal, prove completion with evidence, and do not deliver partial work.
-
-The intent gate routing line is non-optional every turn. For non-trivial tasks, call todo with atomic items before starting, keep exactly one item in progress, and complete each item immediately when done.`;
-}
+import { buildGlm5Prompt } from "./glm-5.js";
 export function buildGlm53Prompt(options) {
-    return buildDynamicSystemPrompt({ ...options, tuningSection: buildGlm53Tuning(), workstationDialect: "claude" });
+    return buildGlm5Prompt(options);
 }
 //# sourceMappingURL=glm-5-3.js.map

package/dist/core/extensions/builtin/prompt-preset/glm-5-3.js.map

@@ -1 +1 @@
-{"version":3,"file":"glm-5-3.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,gBAAgB;IACxB,OAAO;;;;;;8MAMsM,CAAC;AAC/M,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,gBAAgB,EAAE,EAAE,kBAAkB,EAAE,QAAQ,EAAE,CAAC,CAAC;AAClH,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildGlm53Tuning(): string {\n\treturn `You are running on GLM 5.3: Opus 4.6-class agent behavior tuned toward Fable 5 decisiveness and GPT 5.5 outcome-first coding. Apply literal scopes literally - \"every\", \"all\", and \"for each\" mean the full set. Prefer sufficient context over exhaustive context, pick minor decisions and note them, and use matching tools or skills immediately instead of under-reaching.\n\nCalibrate deliberation. Use extended reasoning only for genuine multi-step uncertainty; routine classification, file edits, and lookups should be decided directly. A cheap tool call beats long internal debate: act, inspect evidence, and verify.\n\nCode toward the destination: define the outcome, constraints, and stopping condition, then work without mechanical step-by-step recitation. In ultrawork mode, maintain absolute certainty discipline: preserve the goal, prove completion with evidence, and do not deliver partial work.\n\nThe intent gate routing line is non-optional every turn. For non-trivial tasks, call todo with atomic items before starting, keep exactly one item in progress, and complete each item immediately when done.`;\n}\n\nexport function buildGlm53Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildGlm53Tuning(), workstationDialect: \"claude\" });\n}\n"]}
+{"version":3,"file":"glm-5-3.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5-3.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,eAAe,EAAE,MAAM,YAAY,CAAC;AAE7C,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,eAAe,CAAC,OAAO,CAAC,CAAC;AACjC,CAAC","sourcesContent":["import type { BuildDynamicSystemPromptOptions } from \"../../../dynamic-prompt/build.ts\";\nimport { buildGlm5Prompt } from \"./glm-5.ts\";\n\nexport function buildGlm53Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildGlm5Prompt(options);\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/glm-5.d.ts

@@ -0,0 +1,4 @@
+import { type BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
+export declare const GLM5_TUNING = "A cheap tool call beats long internal debate: when reading, running, or searching can settle a question, do that and reason over the result. Work in short act-inspect-verify loops so an early mistake surfaces before later steps build on it.";
+export declare function buildGlm5Prompt(options: BuildDynamicSystemPromptOptions): string;
+//# sourceMappingURL=glm-5.d.ts.map

package/dist/core/extensions/builtin/prompt-preset/glm-5.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"glm-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAGlH,eAAO,MAAM,WAAW,qPAC2N,CAAC;AAEpP,wBAAgB,eAAe,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWhF"}

package/dist/core/extensions/builtin/prompt-preset/glm-5.js

@@ -0,0 +1,16 @@
+import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
+export const GLM5_TUNING = "A cheap tool call beats long internal debate: when reading, running, or searching can settle a question, do that and reason over the result. Work in short act-inspect-verify loops so an early mistake surfaces before later steps build on it.";
+export function buildGlm5Prompt(options) {
+    return buildDynamicSystemPrompt({
+        ...options,
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            GLM5_TUNING,
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
+        workstationDialect: "claude",
+    });
+}
+//# sourceMappingURL=glm-5.js.map

package/dist/core/extensions/builtin/prompt-preset/glm-5.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"glm-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/glm-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,MAAM,CAAC,MAAM,WAAW,GACvB,kPAAkP,CAAC;AAEpP,MAAM,UAAU,eAAe,CAAC,OAAwC;IACvE,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE;YACd,4BAA4B,CAAC,EAAE,SAAS,EAAE,OAAO,CAAC,aAAa,EAAE,OAAO,EAAE,QAAQ,EAAE,CAAC;YACrF,WAAW;SACX;aACC,MAAM,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC;aACvC,IAAI,CAAC,MAAM,CAAC;QACd,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildExecutionToolingSection } from \"./execution-tooling.ts\";\n\nexport const GLM5_TUNING =\n\t\"A cheap tool call beats long internal debate: when reading, running, or searching can settle a question, do that and reason over the result. Work in short act-inspect-verify loops so an early mistake surfaces before later steps build on it.\";\n\nexport function buildGlm5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: [\n\t\t\tbuildExecutionToolingSection({ toolNames: options.selectedTools, dialect: \"claude\" }),\n\t\t\tGLM5_TUNING,\n\t\t]\n\t\t\t.filter((section) => section.length > 0)\n\t\t\t.join(\"\\n\\n\"),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/gpt-5.6.d.ts

@@ -1,5 +1,5 @@
 import { type BuildDynamicSystemPromptOptions } from "../../../dynamic-prompt/build.ts";
-export type Gpt56ExecutionRuleId = "eval-first-routing" | "parallel-batching" | "over-call-bias" | "in-kernel-reduction" | "stay-direct-exceptions" | "monitor-subscribe" | "delegation" | "todo-granularity" | "test-first" | "atomic-commits" | "lsp-symbol-routing";
+export type Gpt56ExecutionRuleId = "eval-first-routing" | "parallel-batching" | "over-call-bias" | "in-kernel-reduction" | "stay-direct-exceptions" | "delegation" | "todo-granularity" | "test-first" | "atomic-commits" | "lsp-symbol-routing";
 export type Gpt56ExecutionConcern = "tool-orchestration" | "delegation" | "todo-discipline" | "test-first" | "commit-discipline" | "symbol-routing";
 export interface Gpt56ExecutionRule {
     id: Gpt56ExecutionRuleId;
@@ -26,10 +26,6 @@ export declare const GPT56_EXECUTION_RULES: readonly [{
     readonly id: "stay-direct-exceptions";
     readonly concern: "tool-orchestration";
     readonly directive: "Call tools directly instead when one call is enough, the output is already small, each result decides the next call, semantic judgment sits between calls, or the action needs approval - and after two failed cell strategies for the same fact, or an empty or suspiciously narrow result, fall back to direct calls and one or two meaningful alternatives before concluding nothing exists.";
-}, {
-    readonly id: "monitor-subscribe";
-    readonly concern: "tool-orchestration";
-    readonly directive: "When a monitor tool is available, every wait on a long-running command, child task, or detached cell is a subscription: register monitor with a filter for the decisive line or sentinel, continue independent work or end the turn, and let the completion event wake you. Timed sleeps, retry loops, and repeated status reads do not count as waiting.";
 }, {
     readonly id: "delegation";
     readonly concern: "delegation";

package/dist/core/extensions/builtin/prompt-preset/gpt-5.6.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"gpt-5.6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.6.ts"],"names":[],"mappings":"AAgDA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAMlH,MAAM,MAAM,oBAAoB,GAC7B,oBAAoB,GACpB,mBAAmB,GACnB,gBAAgB,GAChB,qBAAqB,GACrB,wBAAwB,GACxB,mBAAmB,GACnB,YAAY,GACZ,kBAAkB,GAClB,YAAY,GACZ,gBAAgB,GAChB,oBAAoB,CAAC;AAExB,MAAM,MAAM,qBAAqB,GAC9B,oBAAoB,GACpB,YAAY,GACZ,iBAAiB,GACjB,YAAY,GACZ,mBAAmB,GACnB,gBAAgB,CAAC;AAEpB,MAAM,WAAW,kBAAkB;IAClC,EAAE,EAAE,oBAAoB,CAAC;IACzB,OAAO,EAAE,qBAAqB,CAAC;IAC/B,SAAS,EAAE,MAAM,CAAC;CAClB;AAgCD,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAYgB,CAAC;AAwGnD,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}
+{"version":3,"file":"gpt-5.6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.6.ts"],"names":[],"mappings":"AAgDA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAKlH,MAAM,MAAM,oBAAoB,GAC7B,oBAAoB,GACpB,mBAAmB,GACnB,gBAAgB,GAChB,qBAAqB,GACrB,wBAAwB,GACxB,YAAY,GACZ,kBAAkB,GAClB,YAAY,GACZ,gBAAgB,GAChB,oBAAoB,CAAC;AAExB,MAAM,MAAM,qBAAqB,GAC9B,oBAAoB,GACpB,YAAY,GACZ,iBAAiB,GACjB,YAAY,GACZ,mBAAmB,GACnB,gBAAgB,CAAC;AAEpB,MAAM,WAAW,kBAAkB;IAClC,EAAE,EAAE,oBAAoB,CAAC;IACzB,OAAO,EAAE,qBAAqB,CAAC;IAC/B,SAAS,EAAE,MAAM,CAAC;CAClB;AAgCD,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAWgB,CAAC;AAoGnD,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEjF"}

package/dist/core/extensions/builtin/prompt-preset/gpt-5.6.js

@@ -46,7 +46,6 @@
 import { APP_NAME } from "../../../../config.js";
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
 import { buildTestDisciplineSection } from "../../../dynamic-prompt/verification.js";
-import { CODEX_MONITOR_SUBSCRIBE_DIRECTIVE } from "./execution-tooling.js";
 import { buildFileOperationsTuning } from "./file-operations.js";
 import { buildGptEvalRoutingTuning } from "./gpt-eval-routing.js";
 const EVAL_FIRST_ROUTING = "WHEN a code-execution tool is available, EVERY multi-call step whose calls can be planned up front, and for which no stay-direct case below applies, is ONE code cell, NEVER a chain of single calls: before writing it, enumerate every read, search, symbol lookup, and command that step could need, and mark which of them are independent.";
@@ -65,16 +64,12 @@ export const GPT56_EXECUTION_RULES = [
     { id: "over-call-bias", concern: "tool-orchestration", directive: OVER_CALL_BIAS },
     { id: "in-kernel-reduction", concern: "tool-orchestration", directive: IN_KERNEL_REDUCTION },
     { id: "stay-direct-exceptions", concern: "tool-orchestration", directive: STAY_DIRECT_EXCEPTIONS },
-    { id: "monitor-subscribe", concern: "tool-orchestration", directive: CODEX_MONITOR_SUBSCRIBE_DIRECTIVE },
     { id: "delegation", concern: "delegation", directive: DELEGATION },
     { id: "todo-granularity", concern: "todo-discipline", directive: TODO_GRANULARITY },
     { id: "test-first", concern: "test-first", directive: TEST_FIRST },
     { id: "atomic-commits", concern: "commit-discipline", directive: ATOMIC_COMMITS },
     { id: "lsp-symbol-routing", concern: "symbol-routing", directive: LSP_SYMBOL_ROUTING },
 ];
-function buildCodexMonitorClause(context) {
-    return context.tools.some((tool) => tool.name === "monitor") ? `${CODEX_MONITOR_SUBSCRIBE_DIRECTIVE} ` : "";
-}
 function buildGpt56Core(context) {
     return `You are ${APP_NAME}, a coding agent and autonomous deep worker: you receive goals, not step-by-step instructions, and execute them end-to-end.
 
@@ -100,7 +95,7 @@ The workspace is shared with the user and other agents. Never revert or modify c
 
 Todo discipline: for any non-trivial task (2+ steps, uncertain scope, or multiple items), start with \`todo\`: atomic items named by their deliverable ("edit \`foo.ts\` to add X"). ${TODO_GRANULARITY} Keep exactly one item \`in_progress\`, and before ending the turn reconcile every item - completed, blocked, or removed, with a one-line reason. Trivial single-step asks need none.
 
-Tool orchestration: resolve the request in the fewest useful tool loops, without letting loop minimization outrank correctness or required evidence. ${buildGptEvalRoutingTuning()} ${EVAL_FIRST_ROUTING} ${PARALLEL_BATCHING} ${OVER_CALL_BIAS} ${IN_KERNEL_REDUCTION} ${STAY_DIRECT_EXCEPTIONS} ${buildCodexMonitorClause(context)}With no code-execution tool registered, fire those independent calls in one message instead - one bash call per command, never chained with \`;\` or \`&&\`. Never fill parameters with placeholders. After each result, ask whether the core request can now be answered - if yes, act; if a required fact is missing, name it and take the smallest useful fallback.
+Tool orchestration: resolve the request in the fewest useful tool loops, without letting loop minimization outrank correctness or required evidence. ${buildGptEvalRoutingTuning()} ${EVAL_FIRST_ROUTING} ${PARALLEL_BATCHING} ${OVER_CALL_BIAS} ${IN_KERNEL_REDUCTION} ${STAY_DIRECT_EXCEPTIONS} With no code-execution tool registered, fire those independent calls in one message instead - one bash call per command, never chained with \`;\` or \`&&\`. Never fill parameters with placeholders. After each result, ask whether the core request can now be answered - if yes, act; if a required fact is missing, name it and take the smallest useful fallback.
 
 Never speculate about code you have not read - memory of file contents is unreliable, so re-read before claiming or editing. ${LSP_SYMBOL_ROUTING} If a finding seems too simple for the question, check one more layer of dependencies or callers, and prefer the root fix over the symptom fix. Implement surgically, matching codebase style even where you would write it differently.