@code-yeongyu/senpi 2026.9.2 → 2026.9.3

package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAQlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AASlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

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

@@ -1,4 +1,5 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus45Tuning() {
     return `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.
 
@@ -7,7 +8,12 @@ Do not wrap up early because the context window is running low; the harness auto
 export function buildClaudeOpus45Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus45Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus45Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

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

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus45Tuning(): string {\n\treturn `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus45Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus45Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,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,uBAAuB,EAAE;SACzB;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\nfunction buildClaudeOpus45Tuning(): string {\n\treturn `Break complex tasks into ordered steps with clear dependencies before executing. When a request covers a set of items, apply it to every item rather than only the first, and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus45Prompt(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\tbuildClaudeOpus45Tuning(),\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/claude-opus-4-6.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAQlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AASlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

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

@@ -1,4 +1,5 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus46Tuning() {
     return `Choose an approach and commit to it; revisit only when new information directly contradicts your reasoning. When a request covers a set of items, apply it to every item and state the scope you applied.
 
@@ -7,7 +8,12 @@ Do not wrap up early because the context window is running low; the harness auto
 export function buildClaudeOpus46Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus46Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus46Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

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

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus46Tuning(): string {\n\treturn `Choose an approach and commit to it; revisit only when new information directly contradicts your reasoning. When a request covers a set of items, apply it to every item and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus46Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus46Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;4IAEoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,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,uBAAuB,EAAE;SACzB;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\nfunction buildClaudeOpus46Tuning(): string {\n\treturn `Choose an approach and commit to it; revisit only when new information directly contradicts your reasoning. When a request covers a set of items, apply it to every item and state the scope you applied.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus46Prompt(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\tbuildClaudeOpus46Tuning(),\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/claude-opus-4-7.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-7.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-7.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAalH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

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

@@ -1,4 +1,5 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus47Tuning() {
     return `Apply instructions at the scope the user evidently intends: "every", "all", and "each" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.
 
@@ -11,7 +12,12 @@ Do not wrap up early because the context window is running low; the harness auto
 export function buildClaudeOpus47Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus47Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus47Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

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

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus47Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus47Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus47Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,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,uBAAuB,EAAE;SACzB;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\nfunction buildClaudeOpus47Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus47Prompt(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\tbuildClaudeOpus47Tuning(),\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/claude-opus-4-8.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-8.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAYlH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMxF"}
+{"version":3,"file":"claude-opus-4-8.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAalH,wBAAgB,uBAAuB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWxF"}

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

@@ -1,4 +1,5 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildClaudeOpus48Tuning() {
     return `Apply instructions at the scope the user evidently intends: "every", "all", and "each" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.
 
@@ -11,7 +12,12 @@ Do not wrap up early because the context window is running low; the harness auto
 export function buildClaudeOpus48Prompt(options) {
     return buildDynamicSystemPrompt({
         ...options,
-        tuningSection: buildClaudeOpus48Tuning(),
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "claude" }),
+            buildClaudeOpus48Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
         workstationDialect: "claude",
     });
 }

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

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-4-8.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,OAAO,wBAAwB,CAAC;QAC/B,GAAG,OAAO;QACV,aAAa,EAAE,uBAAuB,EAAE;QACxC,kBAAkB,EAAE,QAAQ;KAC5B,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildClaudeOpus48Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed; do not re-derive facts already established in the conversation.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus48Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({\n\t\t...options,\n\t\ttuningSection: buildClaudeOpus48Tuning(),\n\t\tworkstationDialect: \"claude\",\n\t});\n}\n"]}
+{"version":3,"file":"claude-opus-4-8.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-4-8.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,4BAA4B,EAAE,MAAM,wBAAwB,CAAC;AAEtE,SAAS,uBAAuB;IAC/B,OAAO;;;;;;4IAMoI,CAAC;AAC7I,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,OAAwC;IAC/E,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,uBAAuB,EAAE;SACzB;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\nfunction buildClaudeOpus48Tuning(): string {\n\treturn `Apply instructions at the scope the user evidently intends: \"every\", \"all\", and \"each\" mean the full set rather than the first item, and a fix that plainly recurs covers every occurrence. State the scope you applied.\n\nPrefer tool calls over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up. After a user turn, reason over what changed; do not re-derive facts already established in the conversation.\n\nFor frontend design with no specified visual direction, derive one from the project's context or propose distinct options before building; do not fall back to your default cream/serif/terracotta house style or generic AI aesthetics.\n\nDo not wrap up early because the context window is running low; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildClaudeOpus48Prompt(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\tbuildClaudeOpus48Tuning(),\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/claude-opus-5.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claude-opus-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AA6BA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAuElH,wBAAgB,sBAAsB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMvF"}
+{"version":3,"file":"claude-opus-5.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/claude-opus-5.ts"],"names":[],"mappings":"AA6BA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAwElH,wBAAgB,sBAAsB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAMvF"}

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

@@ -28,6 +28,7 @@ import { APP_NAME } from "../../../../config.js";
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
 import { getToolsPromptDisplay } from "../../../dynamic-prompt/tool-categorization.js";
 import { buildTestDisciplineSection } from "../../../dynamic-prompt/verification.js";
+import { buildExecutionToolingParagraph } from "./execution-tooling.js";
 function buildSearchLine(context) {
     const triggerTools = getToolsPromptDisplay(context.tools);
     if (!triggerTools) {
@@ -59,7 +60,7 @@ Derive intent from the latest user turn alone: a new direction drops the stale p
 
 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.
 
-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.
+${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.
 
 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.
 

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;AAErF,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;;;;;;;;;;;;;;;;;;;;;;;;;EAyBxB,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\";\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\nMemory 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,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"]}

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

@@ -0,0 +1,50 @@
+export type ExecutionToolingRuleId = "eval-default-surface" | "eval-real-code" | "eval-stay-direct" | "monitor-subscribe";
+export type ExecutionToolingConcern = "code-cell-routing" | "async-waiting";
+export type ExecutionToolingDialect = "claude" | "kimi";
+export interface ExecutionToolingRule {
+    readonly id: ExecutionToolingRuleId;
+    readonly concern: ExecutionToolingConcern;
+    readonly directive: Readonly<Record<ExecutionToolingDialect, string>> & {
+        readonly codex?: string;
+    };
+}
+export declare const EXECUTION_TOOLING_RULES: readonly [{
+    readonly id: "eval-default-surface";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        readonly claude: "`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.";
+        readonly kimi: "**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.";
+    };
+}, {
+    readonly id: "eval-real-code";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        readonly claude: "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.";
+        readonly kimi: "**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.";
+    };
+}, {
+    readonly id: "eval-stay-direct";
+    readonly concern: "code-cell-routing";
+    readonly directive: {
+        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. */
+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;
+//# sourceMappingURL=execution-tooling.d.ts.map

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

@@ -0,0 +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"}

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

@@ -0,0 +1,66 @@
+// 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
+// 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.";
+export const EXECUTION_TOOLING_RULES = [
+    {
+        id: "eval-default-surface",
+        concern: "code-cell-routing",
+        directive: {
+            claude: "`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.",
+            kimi: "**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.",
+        },
+    },
+    {
+        id: "eval-real-code",
+        concern: "code-cell-routing",
+        directive: {
+            claude: "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.",
+            kimi: "**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.",
+        },
+    },
+    {
+        id: "eval-stay-direct",
+        concern: "code-cell-routing",
+        directive: {
+            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.",
+            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. */
+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) {
+        return "";
+    }
+    const body = paragraphs.join("\n\n");
+    return options.dialect === "claude" ? `<execution_tooling>\n${body}\n</execution_tooling>` : body;
+}
+/** Same as buildExecutionToolingSection but followed by a paragraph gap, for inline placement. */
+export function buildExecutionToolingParagraph(options) {
+    const section = buildExecutionToolingSection(options);
+    return section ? `${section}\n\n` : "";
+}
+//# sourceMappingURL=execution-tooling.js.map

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

@@ -0,0 +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"]}

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" | "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" | "monitor-subscribe" | "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,6 +26,10 @@ 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;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"}
+{"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"}

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

@@ -46,6 +46,7 @@
 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.";
@@ -64,12 +65,16 @@ 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.
 
@@ -95,7 +100,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} 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} ${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.
 
 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.
 

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

@@ -1 +1 @@
-{"version":3,"file":"gpt-5.6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.6.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,6EAA6E;AAC7E,0EAA0E;AAC1E,EAAE;AACF,oEAAoE;AACpE,0EAA0E;AAC1E,2EAA2E;AAC3E,4EAA4E;AAC5E,yEAAyE;AACzE,+EAA+E;AAC/E,4EAA4E;AAC5E,2EAA2E;AAC3E,wEAAwE;AACxE,6EAA6E;AAC7E,0EAA0E;AAC1E,2EAA2E;AAC3E,2EAA2E;AAC3E,yEAAyE;AACzE,oEAAoE;AACpE,0EAA0E;AAC1E,uEAAuE;AACvE,2EAA2E;AAC3E,yEAAyE;AACzE,4EAA4E;AAC5E,6EAA6E;AAC7E,mCAAmC;AACnC,EAAE;AACF,6EAA6E;AAC7E,4EAA4E;AAC5E,8EAA8E;AAC9E,4EAA4E;AAC5E,qEAAqE;AACrE,4EAA4E;AAC5E,uEAAuE;AACvE,gFAAgF;AAChF,8EAA8E;AAC9E,+EAA+E;AAC/E,yEAAyE;AACzE,wEAAwE;AACxE,0EAA0E;AAC1E,4EAA4E;AAC5E,oEAAoE;AACpE,yEAAyE;AACzE,yEAAyE;AACzE,8CAA8C;AAE9C,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AACjE,OAAO,EAAE,yBAAyB,EAAE,MAAM,uBAAuB,CAAC;AA4BlE,MAAM,kBAAkB,GACvB,iVAAiV,CAAC;AAEnV,MAAM,iBAAiB,GACtB,8RAA8R,CAAC;AAEhS,MAAM,cAAc,GACnB,iXAAiX,CAAC;AAEnX,MAAM,mBAAmB,GACxB,iMAAiM,CAAC;AAEnM,MAAM,sBAAsB,GAC3B,iYAAiY,CAAC;AAEnY,MAAM,UAAU,GACf,iRAAiR,CAAC;AAEnR,MAAM,gBAAgB,GACrB,yPAAyP,CAAC;AAE3P,MAAM,UAAU,GACf,2ZAA2Z,CAAC;AAE7Z,MAAM,cAAc,GACnB,6LAA6L,CAAC;AAE/L,MAAM,kBAAkB,GACvB,wNAAwN,CAAC;AAE1N,MAAM,CAAC,MAAM,qBAAqB,GAAG;IACpC,EAAE,EAAE,EAAE,oBAAoB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,kBAAkB,EAAE;IAC1F,EAAE,EAAE,EAAE,mBAAmB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,iBAAiB,EAAE;IACxF,EAAE,EAAE,EAAE,gBAAgB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,cAAc,EAAE;IAClF,EAAE,EAAE,EAAE,qBAAqB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,mBAAmB,EAAE;IAC5F,EAAE,EAAE,EAAE,wBAAwB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,sBAAsB,EAAE;IAClG,EAAE,EAAE,EAAE,YAAY,EAAE,OAAO,EAAE,YAAY,EAAE,SAAS,EAAE,UAAU,EAAE;IAClE,EAAE,EAAE,EAAE,kBAAkB,EAAE,OAAO,EAAE,iBAAiB,EAAE,SAAS,EAAE,gBAAgB,EAAE;IACnF,EAAE,EAAE,EAAE,YAAY,EAAE,OAAO,EAAE,YAAY,EAAE,SAAS,EAAE,UAAU,EAAE;IAClE,EAAE,EAAE,EAAE,gBAAgB,EAAE,OAAO,EAAE,mBAAmB,EAAE,SAAS,EAAE,cAAc,EAAE;IACjF,EAAE,EAAE,EAAE,oBAAoB,EAAE,OAAO,EAAE,gBAAgB,EAAE,SAAS,EAAE,kBAAkB,EAAE;CACrC,CAAC;AAEnD,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO,WAAW,QAAQ;;;;;;;;;;;;;;;;;;;;sKAoB2I,UAAU;;uLAEO,gBAAgB;;uJAEhD,yBAAyB,EAAE,IAAI,kBAAkB,IAAI,iBAAiB,IAAI,cAAc,IAAI,mBAAmB,IAAI,sBAAsB;;+HAEjK,kBAAkB;;;;;;;;;;;EAW/I,0BAA0B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;EAwB5B,UAAU;;EAEV,OAAO,CAAC,WAAW;;;wLAGmK,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA4BpM,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,kBAAkB,EAAE,OAAO,EAAE,CAAC,CAAC;AAC1G,CAAC","sourcesContent":["// GPT-5.6 full-core system prompt. One preset covers the whole series - the\n// gpt-5.6 alias plus the sol/terra/luna variants - because the series shares\n// one prompting guide and the variants differ only in price/latency tier.\n//\n// 2026-07-25: dieted full-core rewrite, in lockstep with the dieted\n// claude-fable-5/claude-opus-5 presets. The GPT-5.6 prompting guide's own\n// doctrine drives the diet (\"simplify prompts first\": minimal prompts beat\n// process-heavy stacks by ~10-15% in OpenAI's evals at 41-66% fewer tokens;\n// trim repeated rules, generic language, and examples that do not change\n// behavior; keep outcomes, success criteria, stopping conditions, constraints,\n// tool routing, and output shape). Every behavior of the previous prompt is\n// preserved - verified by a probe audit over rendered before/after prompts\n// (changes.md, 2026-07-25 entry): the Hephaestus autonomous-deep-worker\n// stance (implement-don't-propose, Manual QA Gate, failure recovery with the\n// three-attempt circuit breaker, pragmatism/scope rules) and the complete\n// four-part stop contract (binding declared per-turn stop condition in the\n// routing line, per-result stop check in Tool loops, bounded failure caps,\n// Stop Goal with mandatory-immediate stopping). Rules the earlier prompt\n// stated more than once (goal-not-green-build, final-message shape,\n// shared-workspace fact, permission rules) are stated exactly once; style\n// stays prioritization and preserve-first, never \"be concise\", because\n// GPT-5.6 over-compresses under generic brevity wording. Contracts tied to\n// tools senpi does not expose remain NOT ported - GPT-5.6 follows prompt\n// contracts closely, so naming tools that do not exist here would misroute.\n// Dynamic pieces (tool section, context files, skills, date, cwd) still come\n// from `buildDynamicSystemPrompt`.\n//\n// 2026-07-25 (second pass): execution discipline. The owner's workflow needs\n// ten behaviors GPT-5.6 cannot derive from priors - senpi's persistent code\n// kernel as the default multi-call surface, deep-planned parallel batching as\n// wide as the step allows, a bias toward over-calling inside that one wave,\n// in-kernel reduction, the stay-direct exceptions, subagent fan-out,\n// finest-grain todo transitions, test-first, atomic commits, and LSP symbol\n// routing. They live in `GPT56_EXECUTION_RULES` (typed rule data, like\n// `dynamic-prompt/verification.ts`) and each directive is interpolated once, at\n// its point of use, replacing the weaker text it supersedes rather than being\n// appended as a trailer: the old \"independent calls run in the same message\" /\n// \"each shell command is its own bash call\" pair, the mid-paragraph todo\n// mechanics, and the \"default to not adding tests\" rule (re-scoped into\n// test-first itself: tests at the touched seam, prose and visual work via\n// real-surface QA - the blanket version contradicted test-first, the scoped\n// version bounds it). The GPT-5.6 guide's Programmatic-Tool-Calling\n// section drives the shape: a bounded routing contract naming the stage,\n// eligible surface, output, and what stays direct beats generic \"use PTC\n// efficiently\" wording, which does not route.\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 { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { buildFileOperationsTuning } from \"./file-operations.ts\";\nimport { buildGptEvalRoutingTuning } from \"./gpt-eval-routing.ts\";\n\nexport type Gpt56ExecutionRuleId =\n\t| \"eval-first-routing\"\n\t| \"parallel-batching\"\n\t| \"over-call-bias\"\n\t| \"in-kernel-reduction\"\n\t| \"stay-direct-exceptions\"\n\t| \"delegation\"\n\t| \"todo-granularity\"\n\t| \"test-first\"\n\t| \"atomic-commits\"\n\t| \"lsp-symbol-routing\";\n\nexport type Gpt56ExecutionConcern =\n\t| \"tool-orchestration\"\n\t| \"delegation\"\n\t| \"todo-discipline\"\n\t| \"test-first\"\n\t| \"commit-discipline\"\n\t| \"symbol-routing\";\n\nexport interface Gpt56ExecutionRule {\n\tid: Gpt56ExecutionRuleId;\n\tconcern: Gpt56ExecutionConcern;\n\tdirective: string;\n}\n\nconst EVAL_FIRST_ROUTING =\n\t\"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.\";\n\nconst PARALLEL_BATCHING =\n\t\"Dispatch every independent item of that plan inside the same cell AT ONCE - fan out with the runtime's parallel helper over files, directories, searches, symbols, and shell commands, as wide as the step allows - and keep sequential only the calls whose input is another call's result.\";\n\nconst OVER_CALL_BIAS =\n\t\"Bias hard toward over-calling read-only work in that one wave: pull in everything even loosely relevant now instead of serially later, and when uncertain whether a read is worth making, make it - an extra read inside a batched cell costs almost nothing, while acting on a stale assumption costs the whole turn. Side-effecting or approval-gated calls never ride along.\";\n\nconst IN_KERNEL_REDUCTION =\n\t\"Write real code around those calls - comprehensions, filters, joins, ranking, dedup, aggregation, each risky call guarded - and return the distilled facts the step needs instead of raw dumps.\";\n\nconst STAY_DIRECT_EXCEPTIONS =\n\t\"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.\";\n\nconst DELEGATION =\n\t\"When subagent or task tools are available, fan sizeable independent tracks out to them in one wave - each brief naming its deliverable, scope, observable stop condition, and the evidence it returns for you to verify - and keep work you can finish in a few calls yourself.\";\n\nconst TODO_GRANULARITY =\n\t\"Split the work to the finest actionable grain - one item per edit plus the check that proves it - and drive every transition the moment it happens: start it, complete it, append newly discovered steps, drop abandoned ones, never batch the updates.\";\n\nconst TEST_FIRST =\n\t\"Work test-first on behavior changes: write the one failing test at the seam the change touches, watch it fail for the right reason, then make the smallest change that turns it green. Prose, doc, and visual-only changes take review plus real-surface QA, not tests. Skip test-first also for formatting, comments, renames, or dependency bumps, and never write a test that cannot fail for the regression it names.\";\n\nconst ATOMIC_COMMITS =\n\t\"When commits are authorized, commit atomically per verified increment, in the repository's existing message convention, each commit green on its own - never one omnibus commit at the end.\";\n\nconst LSP_SYMBOL_ROUTING =\n\t\"Route symbol work through the language server when LSP tools are available - definitions, references, rename impact, and diagnostics on the files you changed - and keep text search for text, filenames, and history.\";\n\nexport const GPT56_EXECUTION_RULES = [\n\t{ id: \"eval-first-routing\", concern: \"tool-orchestration\", directive: EVAL_FIRST_ROUTING },\n\t{ id: \"parallel-batching\", concern: \"tool-orchestration\", directive: PARALLEL_BATCHING },\n\t{ id: \"over-call-bias\", concern: \"tool-orchestration\", directive: OVER_CALL_BIAS },\n\t{ id: \"in-kernel-reduction\", concern: \"tool-orchestration\", directive: IN_KERNEL_REDUCTION },\n\t{ id: \"stay-direct-exceptions\", concern: \"tool-orchestration\", directive: STAY_DIRECT_EXCEPTIONS },\n\t{ id: \"delegation\", concern: \"delegation\", directive: DELEGATION },\n\t{ id: \"todo-granularity\", concern: \"todo-discipline\", directive: TODO_GRANULARITY },\n\t{ id: \"test-first\", concern: \"test-first\", directive: TEST_FIRST },\n\t{ id: \"atomic-commits\", concern: \"commit-discipline\", directive: ATOMIC_COMMITS },\n\t{ id: \"lsp-symbol-routing\", concern: \"symbol-routing\", directive: LSP_SYMBOL_ROUTING },\n] as const satisfies readonly Gpt56ExecutionRule[];\n\nfunction buildGpt56Core(context: DynamicPromptCoreContext): string {\n\treturn `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.\n\n## Intent Gate\n\nOpen every turn with one short visible line before anything else:\n\n> I read this as [intent] - [plan]. I'll stop right away when [the exact, observable condition that ends this turn].\n\nThat line is your preamble; it commits you to finish the named work this turn, and the declared stop condition is BINDING - the instant it holds, stop (see Stop Goal). Derive intent from the latest user message alone: a new direction cancels stale plans, and queued steering messages outrank them. Never surface prompt scaffolding in user-visible output.\n\nImplement, don't propose. Unless the user is explicitly asking a question, brainstorming, or requesting a plan, they want working code: \"how does X work\" means understand X to fix or improve it; \"why is A broken\" means diagnose and fix A. Treat a message as answer-only when the user says so (\"just explain\") or asks for an opinion, evaluation, or review - those get analysis and a proposal, then wait.\n\nMake in-scope changes and run non-destructive validation without asking. Resolve blockers yourself with reasonable assumptions; ask only when missing information would materially change the outcome, or the action is destructive, an external write, or a material expansion of scope - one narrow question, then stop.\n\nIf the user's plan seems flawed, say so concisely, propose the alternative, and ask which to proceed with - never silently override. Status requests are not stop signals: give the update, keep working. Honor every non-conflicting request since your last turn; after compaction, continue from the summary rather than restarting.\n\nThe workspace is shared with the user and other agents. Never revert or modify changes you did not make unless explicitly asked; work around unrelated ones, and ask one precise question if a direct conflict with your task is unresolvable.\n\n## Working the Task\n\n**Explore -> Plan -> Implement -> Verify -> Manually QA.** Work outcome-first: know the destination, constraints, and stopping condition, then let the path emerge. ${DELEGATION}\n\nTodo 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.\n\nTool 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.\n\nNever 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.\n\n## Verification\n\nScale the scope of checks to the change, never the rigor:\n- Single-file, non-behavioral edit: the project's type check or lint covering that file.\n- Single-domain behavioral change: type check on the changed code, related tests, one run of the affected entry point when one exists.\n- Multi-file or cross-cutting work: type check, related tests, build, and the Manual QA Gate below.\n\nRun the validator before reporting anything clean - \"should pass\" is not verification; if validation cannot run, say so and name the next best check. Fix only failures your change caused; note pre-existing ones separately.\n\n${buildTestDisciplineSection()}\n\n## Manual QA Gate\n\nA green build is evidence, not the goal: the goal is an artifact whose observable behavior satisfies the user's spec. \"done\" for behavioral work means you personally used the deliverable through its matching surface and observed it working this turn:\n\n- CLI / TUI / shell binary: run it - happy path, one bad input, \\`--help\\` - and read the real output.\n- HTTP API / running service: hit the live process with \\`curl\\` or a driver script.\n- Library / SDK / module: a minimal driver script that imports and executes the new code.\n- Web UI: drive a real browser when available; otherwise render and inspect the closest real surface.\n- No matching surface: do what a real user would do to discover it works.\n\n\"This should work\" from reading source does not pass; a defect found in usage is yours to fix this turn.\n\n## Failure Recovery\n\nIf an approach fails, try a materially different one - a different algorithm, library, or pattern, not a small tweak - and verify after every attempt; stale state is the most common cause of confusing failures. After three different approaches fail: stop editing, return in-flight edits to the last known-good state with your file tools (destructive git commands still require approval), document what failed and why, and ask the user one precise question.\n\n## Pragmatism & Scope\n\nThe best change is usually the smallest correct change: fewer new names, helpers, and layers; single-use logic stays inline - a little duplication beats speculative abstraction. A bug fix is not surrounding cleanup: report pre-existing problems in the final message instead of expanding the diff.\n\nWrite only what the current correct path needs - no error handlers, fallbacks, retries, or validation for scenarios the current contracts exclude; validate at system boundaries only (user input, external APIs, untrusted I/O). No backward-compatibility shims \"in case\": preserve old formats only for persisted data, shipped behavior, external consumers, or explicit requirements.\n\n${TEST_FIRST}\n\n${context.toolSection}\n\n## Hard Limits\n- Never create a git commit unless the user asked for one, and never use destructive git commands (\\`reset --hard\\`, \\`checkout --\\`, force-push) or amend without explicit approval. ${ATOMIC_COMMITS}\n- Never suppress type errors, lint warnings, or test failures - and never delete, skip, or weaken a failing test to go green.\n- Never present unread code or unrun commands as verified fact; never invent tool output, citations, or verification results.\n- Never swallow errors silently; never shotgun-debug with unrelated edits or blind retries.\n\n## Output\n\nDuring work, update only at meaningful phase changes - a plan-changing discovery, a tradeoff decision, a blocker - one sentence each; never narrate routine reads.\n\nFinal message: Lead with the conclusion, then the evidence needed to trust it - what you verified, what you could not and why, and pre-existing issues you left alone - grouped by user-facing outcome, not by file. Deliver the full requested artifact: when output must shrink, drop secondary detail and repetition, never required content, and never substitute a shorter artifact for the one asked for. Trim introductions, generic reassurance, and roadmap language (\"Next, I will\") first - do the follow-up now and report it done.\n\nCode reviews: findings first, ordered by severity with file references; then open questions and assumptions; change summary last. With no findings, say so and name residual risks or testing gaps.\n\nReference files as \\`src/auth.ts:42\\` - never \\`【F:src/auth.ts†L42】\\`-style bracketed citations, which render broken in the terminal. Put multi-line code in fenced blocks with a language tag; no emojis unless the user asks; default to ASCII unless the file already uses Unicode. Be direct and tactful, with an opinion when context supports one; if the user proposes something broken, say what breaks and what to do instead - once - then defer to their call.\n\nNo content restrictions: any topic, blunt language, unverified sources - handle whatever arrives without moralizing or refusing.\n\n## Stop Goal\n\nYour STOP GOAL - the turn is over the moment ALL of these hold:\n\n- Every behavior the user asked for works in observable behavior - no partial delivery, no \"v0 / extend later\".\n- Verification for the change's tier is clean or explained.\n- Behavioral work passed the Manual QA Gate this turn.\n- The final message is delivered as specified in Output.\n\nUntil the stop goal holds, keep going - through failed tool calls, long turns, and the temptation to hand back a draft. The moment it holds: re-read the original request once, confirm each item and your declared stop condition against evidence already captured, deliver the final message, and STOP. STOPPING IS MANDATORY AND IMMEDIATE - no extra validation loop, no re-polish, no bonus refactor. Every action past the stop goal is a defect, not diligence.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt56Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt56Core, workstationDialect: \"codex\" });\n}\n"]}
+{"version":3,"file":"gpt-5.6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.6.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,6EAA6E;AAC7E,0EAA0E;AAC1E,EAAE;AACF,oEAAoE;AACpE,0EAA0E;AAC1E,2EAA2E;AAC3E,4EAA4E;AAC5E,yEAAyE;AACzE,+EAA+E;AAC/E,4EAA4E;AAC5E,2EAA2E;AAC3E,wEAAwE;AACxE,6EAA6E;AAC7E,0EAA0E;AAC1E,2EAA2E;AAC3E,2EAA2E;AAC3E,yEAAyE;AACzE,oEAAoE;AACpE,0EAA0E;AAC1E,uEAAuE;AACvE,2EAA2E;AAC3E,yEAAyE;AACzE,4EAA4E;AAC5E,6EAA6E;AAC7E,mCAAmC;AACnC,EAAE;AACF,6EAA6E;AAC7E,4EAA4E;AAC5E,8EAA8E;AAC9E,4EAA4E;AAC5E,qEAAqE;AACrE,4EAA4E;AAC5E,uEAAuE;AACvE,gFAAgF;AAChF,8EAA8E;AAC9E,+EAA+E;AAC/E,yEAAyE;AACzE,wEAAwE;AACxE,0EAA0E;AAC1E,4EAA4E;AAC5E,oEAAoE;AACpE,yEAAyE;AACzE,yEAAyE;AACzE,8CAA8C;AAE9C,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,iCAAiC,EAAE,MAAM,wBAAwB,CAAC;AAC3E,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AACjE,OAAO,EAAE,yBAAyB,EAAE,MAAM,uBAAuB,CAAC;AA6BlE,MAAM,kBAAkB,GACvB,iVAAiV,CAAC;AAEnV,MAAM,iBAAiB,GACtB,8RAA8R,CAAC;AAEhS,MAAM,cAAc,GACnB,iXAAiX,CAAC;AAEnX,MAAM,mBAAmB,GACxB,iMAAiM,CAAC;AAEnM,MAAM,sBAAsB,GAC3B,iYAAiY,CAAC;AAEnY,MAAM,UAAU,GACf,iRAAiR,CAAC;AAEnR,MAAM,gBAAgB,GACrB,yPAAyP,CAAC;AAE3P,MAAM,UAAU,GACf,2ZAA2Z,CAAC;AAE7Z,MAAM,cAAc,GACnB,6LAA6L,CAAC;AAE/L,MAAM,kBAAkB,GACvB,wNAAwN,CAAC;AAE1N,MAAM,CAAC,MAAM,qBAAqB,GAAG;IACpC,EAAE,EAAE,EAAE,oBAAoB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,kBAAkB,EAAE;IAC1F,EAAE,EAAE,EAAE,mBAAmB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,iBAAiB,EAAE;IACxF,EAAE,EAAE,EAAE,gBAAgB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,cAAc,EAAE;IAClF,EAAE,EAAE,EAAE,qBAAqB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,mBAAmB,EAAE;IAC5F,EAAE,EAAE,EAAE,wBAAwB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,sBAAsB,EAAE;IAClG,EAAE,EAAE,EAAE,mBAAmB,EAAE,OAAO,EAAE,oBAAoB,EAAE,SAAS,EAAE,iCAAiC,EAAE;IACxG,EAAE,EAAE,EAAE,YAAY,EAAE,OAAO,EAAE,YAAY,EAAE,SAAS,EAAE,UAAU,EAAE;IAClE,EAAE,EAAE,EAAE,kBAAkB,EAAE,OAAO,EAAE,iBAAiB,EAAE,SAAS,EAAE,gBAAgB,EAAE;IACnF,EAAE,EAAE,EAAE,YAAY,EAAE,OAAO,EAAE,YAAY,EAAE,SAAS,EAAE,UAAU,EAAE;IAClE,EAAE,EAAE,EAAE,gBAAgB,EAAE,OAAO,EAAE,mBAAmB,EAAE,SAAS,EAAE,cAAc,EAAE;IACjF,EAAE,EAAE,EAAE,oBAAoB,EAAE,OAAO,EAAE,gBAAgB,EAAE,SAAS,EAAE,kBAAkB,EAAE;CACrC,CAAC;AAEnD,SAAS,uBAAuB,CAAC,OAAiC;IACjE,OAAO,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,KAAK,SAAS,CAAC,CAAC,CAAC,CAAC,GAAG,iCAAiC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC;AAC7G,CAAC;AAED,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO,WAAW,QAAQ;;;;;;;;;;;;;;;;;;;;sKAoB2I,UAAU;;uLAEO,gBAAgB;;uJAEhD,yBAAyB,EAAE,IAAI,kBAAkB,IAAI,iBAAiB,IAAI,cAAc,IAAI,mBAAmB,IAAI,sBAAsB,IAAI,uBAAuB,CAAC,OAAO,CAAC;;+HAErM,kBAAkB;;;;;;;;;;;EAW/I,0BAA0B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;EAwB5B,UAAU;;EAEV,OAAO,CAAC,WAAW;;;wLAGmK,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA4BpM,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,kBAAkB,EAAE,OAAO,EAAE,CAAC,CAAC;AAC1G,CAAC","sourcesContent":["// GPT-5.6 full-core system prompt. One preset covers the whole series - the\n// gpt-5.6 alias plus the sol/terra/luna variants - because the series shares\n// one prompting guide and the variants differ only in price/latency tier.\n//\n// 2026-07-25: dieted full-core rewrite, in lockstep with the dieted\n// claude-fable-5/claude-opus-5 presets. The GPT-5.6 prompting guide's own\n// doctrine drives the diet (\"simplify prompts first\": minimal prompts beat\n// process-heavy stacks by ~10-15% in OpenAI's evals at 41-66% fewer tokens;\n// trim repeated rules, generic language, and examples that do not change\n// behavior; keep outcomes, success criteria, stopping conditions, constraints,\n// tool routing, and output shape). Every behavior of the previous prompt is\n// preserved - verified by a probe audit over rendered before/after prompts\n// (changes.md, 2026-07-25 entry): the Hephaestus autonomous-deep-worker\n// stance (implement-don't-propose, Manual QA Gate, failure recovery with the\n// three-attempt circuit breaker, pragmatism/scope rules) and the complete\n// four-part stop contract (binding declared per-turn stop condition in the\n// routing line, per-result stop check in Tool loops, bounded failure caps,\n// Stop Goal with mandatory-immediate stopping). Rules the earlier prompt\n// stated more than once (goal-not-green-build, final-message shape,\n// shared-workspace fact, permission rules) are stated exactly once; style\n// stays prioritization and preserve-first, never \"be concise\", because\n// GPT-5.6 over-compresses under generic brevity wording. Contracts tied to\n// tools senpi does not expose remain NOT ported - GPT-5.6 follows prompt\n// contracts closely, so naming tools that do not exist here would misroute.\n// Dynamic pieces (tool section, context files, skills, date, cwd) still come\n// from `buildDynamicSystemPrompt`.\n//\n// 2026-07-25 (second pass): execution discipline. The owner's workflow needs\n// ten behaviors GPT-5.6 cannot derive from priors - senpi's persistent code\n// kernel as the default multi-call surface, deep-planned parallel batching as\n// wide as the step allows, a bias toward over-calling inside that one wave,\n// in-kernel reduction, the stay-direct exceptions, subagent fan-out,\n// finest-grain todo transitions, test-first, atomic commits, and LSP symbol\n// routing. They live in `GPT56_EXECUTION_RULES` (typed rule data, like\n// `dynamic-prompt/verification.ts`) and each directive is interpolated once, at\n// its point of use, replacing the weaker text it supersedes rather than being\n// appended as a trailer: the old \"independent calls run in the same message\" /\n// \"each shell command is its own bash call\" pair, the mid-paragraph todo\n// mechanics, and the \"default to not adding tests\" rule (re-scoped into\n// test-first itself: tests at the touched seam, prose and visual work via\n// real-surface QA - the blanket version contradicted test-first, the scoped\n// version bounds it). The GPT-5.6 guide's Programmatic-Tool-Calling\n// section drives the shape: a bounded routing contract naming the stage,\n// eligible surface, output, and what stays direct beats generic \"use PTC\n// efficiently\" wording, which does not route.\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 { buildTestDisciplineSection } from \"../../../dynamic-prompt/verification.ts\";\nimport { CODEX_MONITOR_SUBSCRIBE_DIRECTIVE } from \"./execution-tooling.ts\";\nimport { buildFileOperationsTuning } from \"./file-operations.ts\";\nimport { buildGptEvalRoutingTuning } from \"./gpt-eval-routing.ts\";\n\nexport type Gpt56ExecutionRuleId =\n\t| \"eval-first-routing\"\n\t| \"parallel-batching\"\n\t| \"over-call-bias\"\n\t| \"in-kernel-reduction\"\n\t| \"stay-direct-exceptions\"\n\t| \"monitor-subscribe\"\n\t| \"delegation\"\n\t| \"todo-granularity\"\n\t| \"test-first\"\n\t| \"atomic-commits\"\n\t| \"lsp-symbol-routing\";\n\nexport type Gpt56ExecutionConcern =\n\t| \"tool-orchestration\"\n\t| \"delegation\"\n\t| \"todo-discipline\"\n\t| \"test-first\"\n\t| \"commit-discipline\"\n\t| \"symbol-routing\";\n\nexport interface Gpt56ExecutionRule {\n\tid: Gpt56ExecutionRuleId;\n\tconcern: Gpt56ExecutionConcern;\n\tdirective: string;\n}\n\nconst EVAL_FIRST_ROUTING =\n\t\"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.\";\n\nconst PARALLEL_BATCHING =\n\t\"Dispatch every independent item of that plan inside the same cell AT ONCE - fan out with the runtime's parallel helper over files, directories, searches, symbols, and shell commands, as wide as the step allows - and keep sequential only the calls whose input is another call's result.\";\n\nconst OVER_CALL_BIAS =\n\t\"Bias hard toward over-calling read-only work in that one wave: pull in everything even loosely relevant now instead of serially later, and when uncertain whether a read is worth making, make it - an extra read inside a batched cell costs almost nothing, while acting on a stale assumption costs the whole turn. Side-effecting or approval-gated calls never ride along.\";\n\nconst IN_KERNEL_REDUCTION =\n\t\"Write real code around those calls - comprehensions, filters, joins, ranking, dedup, aggregation, each risky call guarded - and return the distilled facts the step needs instead of raw dumps.\";\n\nconst STAY_DIRECT_EXCEPTIONS =\n\t\"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.\";\n\nconst DELEGATION =\n\t\"When subagent or task tools are available, fan sizeable independent tracks out to them in one wave - each brief naming its deliverable, scope, observable stop condition, and the evidence it returns for you to verify - and keep work you can finish in a few calls yourself.\";\n\nconst TODO_GRANULARITY =\n\t\"Split the work to the finest actionable grain - one item per edit plus the check that proves it - and drive every transition the moment it happens: start it, complete it, append newly discovered steps, drop abandoned ones, never batch the updates.\";\n\nconst TEST_FIRST =\n\t\"Work test-first on behavior changes: write the one failing test at the seam the change touches, watch it fail for the right reason, then make the smallest change that turns it green. Prose, doc, and visual-only changes take review plus real-surface QA, not tests. Skip test-first also for formatting, comments, renames, or dependency bumps, and never write a test that cannot fail for the regression it names.\";\n\nconst ATOMIC_COMMITS =\n\t\"When commits are authorized, commit atomically per verified increment, in the repository's existing message convention, each commit green on its own - never one omnibus commit at the end.\";\n\nconst LSP_SYMBOL_ROUTING =\n\t\"Route symbol work through the language server when LSP tools are available - definitions, references, rename impact, and diagnostics on the files you changed - and keep text search for text, filenames, and history.\";\n\nexport const GPT56_EXECUTION_RULES = [\n\t{ id: \"eval-first-routing\", concern: \"tool-orchestration\", directive: EVAL_FIRST_ROUTING },\n\t{ id: \"parallel-batching\", concern: \"tool-orchestration\", directive: PARALLEL_BATCHING },\n\t{ id: \"over-call-bias\", concern: \"tool-orchestration\", directive: OVER_CALL_BIAS },\n\t{ id: \"in-kernel-reduction\", concern: \"tool-orchestration\", directive: IN_KERNEL_REDUCTION },\n\t{ id: \"stay-direct-exceptions\", concern: \"tool-orchestration\", directive: STAY_DIRECT_EXCEPTIONS },\n\t{ id: \"monitor-subscribe\", concern: \"tool-orchestration\", directive: CODEX_MONITOR_SUBSCRIBE_DIRECTIVE },\n\t{ id: \"delegation\", concern: \"delegation\", directive: DELEGATION },\n\t{ id: \"todo-granularity\", concern: \"todo-discipline\", directive: TODO_GRANULARITY },\n\t{ id: \"test-first\", concern: \"test-first\", directive: TEST_FIRST },\n\t{ id: \"atomic-commits\", concern: \"commit-discipline\", directive: ATOMIC_COMMITS },\n\t{ id: \"lsp-symbol-routing\", concern: \"symbol-routing\", directive: LSP_SYMBOL_ROUTING },\n] as const satisfies readonly Gpt56ExecutionRule[];\n\nfunction buildCodexMonitorClause(context: DynamicPromptCoreContext): string {\n\treturn context.tools.some((tool) => tool.name === \"monitor\") ? `${CODEX_MONITOR_SUBSCRIBE_DIRECTIVE} ` : \"\";\n}\n\nfunction buildGpt56Core(context: DynamicPromptCoreContext): string {\n\treturn `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.\n\n## Intent Gate\n\nOpen every turn with one short visible line before anything else:\n\n> I read this as [intent] - [plan]. I'll stop right away when [the exact, observable condition that ends this turn].\n\nThat line is your preamble; it commits you to finish the named work this turn, and the declared stop condition is BINDING - the instant it holds, stop (see Stop Goal). Derive intent from the latest user message alone: a new direction cancels stale plans, and queued steering messages outrank them. Never surface prompt scaffolding in user-visible output.\n\nImplement, don't propose. Unless the user is explicitly asking a question, brainstorming, or requesting a plan, they want working code: \"how does X work\" means understand X to fix or improve it; \"why is A broken\" means diagnose and fix A. Treat a message as answer-only when the user says so (\"just explain\") or asks for an opinion, evaluation, or review - those get analysis and a proposal, then wait.\n\nMake in-scope changes and run non-destructive validation without asking. Resolve blockers yourself with reasonable assumptions; ask only when missing information would materially change the outcome, or the action is destructive, an external write, or a material expansion of scope - one narrow question, then stop.\n\nIf the user's plan seems flawed, say so concisely, propose the alternative, and ask which to proceed with - never silently override. Status requests are not stop signals: give the update, keep working. Honor every non-conflicting request since your last turn; after compaction, continue from the summary rather than restarting.\n\nThe workspace is shared with the user and other agents. Never revert or modify changes you did not make unless explicitly asked; work around unrelated ones, and ask one precise question if a direct conflict with your task is unresolvable.\n\n## Working the Task\n\n**Explore -> Plan -> Implement -> Verify -> Manually QA.** Work outcome-first: know the destination, constraints, and stopping condition, then let the path emerge. ${DELEGATION}\n\nTodo 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.\n\nTool 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.\n\nNever 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.\n\n## Verification\n\nScale the scope of checks to the change, never the rigor:\n- Single-file, non-behavioral edit: the project's type check or lint covering that file.\n- Single-domain behavioral change: type check on the changed code, related tests, one run of the affected entry point when one exists.\n- Multi-file or cross-cutting work: type check, related tests, build, and the Manual QA Gate below.\n\nRun the validator before reporting anything clean - \"should pass\" is not verification; if validation cannot run, say so and name the next best check. Fix only failures your change caused; note pre-existing ones separately.\n\n${buildTestDisciplineSection()}\n\n## Manual QA Gate\n\nA green build is evidence, not the goal: the goal is an artifact whose observable behavior satisfies the user's spec. \"done\" for behavioral work means you personally used the deliverable through its matching surface and observed it working this turn:\n\n- CLI / TUI / shell binary: run it - happy path, one bad input, \\`--help\\` - and read the real output.\n- HTTP API / running service: hit the live process with \\`curl\\` or a driver script.\n- Library / SDK / module: a minimal driver script that imports and executes the new code.\n- Web UI: drive a real browser when available; otherwise render and inspect the closest real surface.\n- No matching surface: do what a real user would do to discover it works.\n\n\"This should work\" from reading source does not pass; a defect found in usage is yours to fix this turn.\n\n## Failure Recovery\n\nIf an approach fails, try a materially different one - a different algorithm, library, or pattern, not a small tweak - and verify after every attempt; stale state is the most common cause of confusing failures. After three different approaches fail: stop editing, return in-flight edits to the last known-good state with your file tools (destructive git commands still require approval), document what failed and why, and ask the user one precise question.\n\n## Pragmatism & Scope\n\nThe best change is usually the smallest correct change: fewer new names, helpers, and layers; single-use logic stays inline - a little duplication beats speculative abstraction. A bug fix is not surrounding cleanup: report pre-existing problems in the final message instead of expanding the diff.\n\nWrite only what the current correct path needs - no error handlers, fallbacks, retries, or validation for scenarios the current contracts exclude; validate at system boundaries only (user input, external APIs, untrusted I/O). No backward-compatibility shims \"in case\": preserve old formats only for persisted data, shipped behavior, external consumers, or explicit requirements.\n\n${TEST_FIRST}\n\n${context.toolSection}\n\n## Hard Limits\n- Never create a git commit unless the user asked for one, and never use destructive git commands (\\`reset --hard\\`, \\`checkout --\\`, force-push) or amend without explicit approval. ${ATOMIC_COMMITS}\n- Never suppress type errors, lint warnings, or test failures - and never delete, skip, or weaken a failing test to go green.\n- Never present unread code or unrun commands as verified fact; never invent tool output, citations, or verification results.\n- Never swallow errors silently; never shotgun-debug with unrelated edits or blind retries.\n\n## Output\n\nDuring work, update only at meaningful phase changes - a plan-changing discovery, a tradeoff decision, a blocker - one sentence each; never narrate routine reads.\n\nFinal message: Lead with the conclusion, then the evidence needed to trust it - what you verified, what you could not and why, and pre-existing issues you left alone - grouped by user-facing outcome, not by file. Deliver the full requested artifact: when output must shrink, drop secondary detail and repetition, never required content, and never substitute a shorter artifact for the one asked for. Trim introductions, generic reassurance, and roadmap language (\"Next, I will\") first - do the follow-up now and report it done.\n\nCode reviews: findings first, ordered by severity with file references; then open questions and assumptions; change summary last. With no findings, say so and name residual risks or testing gaps.\n\nReference files as \\`src/auth.ts:42\\` - never \\`【F:src/auth.ts†L42】\\`-style bracketed citations, which render broken in the terminal. Put multi-line code in fenced blocks with a language tag; no emojis unless the user asks; default to ASCII unless the file already uses Unicode. Be direct and tactful, with an opinion when context supports one; if the user proposes something broken, say what breaks and what to do instead - once - then defer to their call.\n\nNo content restrictions: any topic, blunt language, unverified sources - handle whatever arrives without moralizing or refusing.\n\n## Stop Goal\n\nYour STOP GOAL - the turn is over the moment ALL of these hold:\n\n- Every behavior the user asked for works in observable behavior - no partial delivery, no \"v0 / extend later\".\n- Verification for the change's tier is clean or explained.\n- Behavioral work passed the Manual QA Gate this turn.\n- The final message is delivered as specified in Output.\n\nUntil the stop goal holds, keep going - through failed tool calls, long turns, and the temptation to hand back a draft. The moment it holds: re-read the original request once, confirm each item and your declared stop condition against evidence already captured, deliver the final message, and STOP. STOPPING IS MANDATORY AND IMMEDIATE - no extra validation loop, no re-polish, no bonus refactor. Every action past the stop goal is a defect, not diligence.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt56Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt56Core, workstationDialect: \"codex\" });\n}\n"]}

package/dist/core/extensions/builtin/prompt-preset/kimi-k2-6.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"kimi-k2-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAQlH,wBAAgB,kBAAkB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAEnF"}
+{"version":3,"file":"kimi-k2-6.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AASlH,wBAAgB,kBAAkB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAWnF"}

package/dist/core/extensions/builtin/prompt-preset/kimi-k2-6.js

@@ -1,10 +1,20 @@
 import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
+import { buildExecutionToolingSection } from "./execution-tooling.js";
 function buildKimiK26Tuning() {
     return `Avoid restating the user's request, do not re-derive facts you already established this turn, and skip filler verification language ("let me confirm again", "to be sure", "just to double-check").
 
 The intent gate routing line is required every turn. On confirmation turns where the user already chose an option in plain words, acknowledge that choice and execute, not re-litigate alternatives the user already eliminated.`;
 }
 export function buildKimiK26Prompt(options) {
-    return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK26Tuning(), workstationDialect: "kimi" });
+    return buildDynamicSystemPrompt({
+        ...options,
+        tuningSection: [
+            buildExecutionToolingSection({ toolNames: options.selectedTools, dialect: "kimi" }),
+            buildKimiK26Tuning(),
+        ]
+            .filter((section) => section.length > 0)
+            .join("\n\n"),
+        workstationDialect: "kimi",
+    });
 }
 //# sourceMappingURL=kimi-k2-6.js.map