@code-yeongyu/senpi 2026.7.17-4 → 2026.7.17
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +0 -47
- package/dist/core/dynamic-prompt/build.d.ts +0 -7
- package/dist/core/dynamic-prompt/build.d.ts.map +1 -1
- package/dist/core/dynamic-prompt/build.js +0 -5
- package/dist/core/dynamic-prompt/build.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/native-search.d.ts +1 -1
- package/dist/core/extensions/builtin/mcp/expose/native-search.d.ts.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/native-search.js +1 -1
- package/dist/core/extensions/builtin/mcp/expose/native-search.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/policy.js +1 -1
- package/dist/core/extensions/builtin/mcp/expose/policy.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/status.js +1 -1
- package/dist/core/extensions/builtin/mcp/expose/status.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/tier-b.d.ts +3 -3
- package/dist/core/extensions/builtin/mcp/expose/tier-b.d.ts.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/tier-b.js +10 -10
- package/dist/core/extensions/builtin/mcp/expose/tier-b.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/tool-search.d.ts +3 -3
- package/dist/core/extensions/builtin/mcp/expose/tool-search.d.ts.map +1 -1
- package/dist/core/extensions/builtin/mcp/expose/tool-search.js +14 -14
- package/dist/core/extensions/builtin/mcp/expose/tool-search.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/index.js +5 -5
- package/dist/core/extensions/builtin/mcp/index.js.map +1 -1
- package/dist/core/extensions/builtin/mcp/service.d.ts +2 -2
- package/dist/core/extensions/builtin/mcp/service.d.ts.map +1 -1
- package/dist/core/extensions/builtin/mcp/service.js +2 -2
- package/dist/core/extensions/builtin/mcp/service.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.js +1 -5
- package/dist/core/extensions/builtin/prompt-preset/claude-fable-5.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.js +1 -5
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-5.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.js +1 -5
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-6.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.js +1 -5
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-7.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.js +1 -5
- package/dist/core/extensions/builtin/prompt-preset/claude-opus-4-8.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/glm-5-2.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/glm-5-2.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.2.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.2.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.3-codex.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.3-codex.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.4.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.4.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.5.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.5.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.6.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.6.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/gpt-5.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k2-6.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k2-6.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k2-7.js +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k2-7.js.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k3.d.ts.map +1 -1
- package/dist/core/extensions/builtin/prompt-preset/kimi-k3.js +7 -5
- package/dist/core/extensions/builtin/prompt-preset/kimi-k3.js.map +1 -1
- package/dist/core/extensions/builtin/websearch/index.d.ts.map +1 -1
- package/dist/core/extensions/builtin/websearch/index.js +3 -20
- package/dist/core/extensions/builtin/websearch/index.js.map +1 -1
- package/docs/mcp.md +5 -5
- package/examples/AGENTS.md +0 -3
- package/node_modules/@code-yeongyu/senpi-codemode/CHANGELOG.md +0 -35
- package/node_modules/@code-yeongyu/senpi-codemode/package.json +3 -3
- package/node_modules/@code-yeongyu/senpi-codemode/src/index.ts +19 -59
- package/node_modules/@code-yeongyu/senpi-codemode/src/prompt/eval-prompt.ts +2 -68
- package/node_modules/@code-yeongyu/senpi-codemode/src/tool/eval-tool.ts +0 -6
- package/node_modules/@earendil-works/pi-agent-core/package.json +2 -2
- package/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.d.ts +1 -2
- package/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.d.ts.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.js +1 -25
- package/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.js.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/models.generated.d.ts +21 -0
- package/node_modules/@earendil-works/pi-ai/dist/models.generated.d.ts.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/providers/opencode-go.models.js +6 -6
- package/node_modules/@earendil-works/pi-ai/dist/providers/opencode-go.models.js.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/providers/openrouter.models.d.ts +21 -0
- package/node_modules/@earendil-works/pi-ai/dist/providers/openrouter.models.d.ts.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/providers/openrouter.models.js +25 -7
- package/node_modules/@earendil-works/pi-ai/dist/providers/openrouter.models.js.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/types.d.ts +0 -5
- package/node_modules/@earendil-works/pi-ai/dist/types.d.ts.map +1 -1
- package/node_modules/@earendil-works/pi-ai/dist/types.js.map +1 -1
- package/node_modules/@earendil-works/pi-ai/package.json +1 -1
- package/node_modules/@earendil-works/pi-pty/package.json +1 -1
- package/node_modules/@earendil-works/pi-tui/package.json +1 -1
- package/package.json +6 -6
- package/dist/core/dynamic-prompt/workstation.d.ts +0 -35
- package/dist/core/dynamic-prompt/workstation.d.ts.map +0 -1
- package/dist/core/dynamic-prompt/workstation.js +0 -81
- package/dist/core/dynamic-prompt/workstation.js.map +0 -1
- package/docs/AGENTS.md +0 -70
- package/node_modules/@earendil-works/pi-ai/dist/utils/tool-schema-compat.d.ts +0 -19
- package/node_modules/@earendil-works/pi-ai/dist/utils/tool-schema-compat.d.ts.map +0 -1
- package/node_modules/@earendil-works/pi-ai/dist/utils/tool-schema-compat.js +0 -215
- package/node_modules/@earendil-works/pi-ai/dist/utils/tool-schema-compat.js.map +0 -1
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"gpt-5.3-codex.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.3-codex.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,qBAAqB;IAC7B,OAAO;;;;;;EAMN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,qBAAqB,CAAC,OAAwC;IAC7E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,qBAAqB,EAAE,EAAE,
|
|
1
|
+
{"version":3,"file":"gpt-5.3-codex.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.3-codex.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,qBAAqB;IAC7B,OAAO;;;;;;EAMN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,qBAAqB,CAAC,OAAwC;IAC7E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,qBAAqB,EAAE,EAAE,CAAC,CAAC;AACzF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildFileOperationsTuning } from \"./file-operations.ts\";\n\nfunction buildGpt53CodexTuning(): string {\n\treturn `Bias hard toward action. Implement directly with reasonable assumptions rather than stopping to ask. Do not produce upfront plans or preambles before acting — start working immediately.\n\nDo not re-state the goal between steps. When a milestone completes, move to the next without summarizing unless the user asked for a summary.\n\nAfter compaction, continue from the current state rather than re-deriving prior conclusions. Treat compacted items as opaque.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt53CodexPrompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt53CodexTuning() });\n}\n"]}
|
|
@@ -10,6 +10,6 @@ State when each tool should and should not be called. Specify parallel vs sequen
|
|
|
10
10
|
${buildFileOperationsTuning()}`;
|
|
11
11
|
}
|
|
12
12
|
export function buildGpt54Prompt(options) {
|
|
13
|
-
return buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt54Tuning()
|
|
13
|
+
return buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt54Tuning() });
|
|
14
14
|
}
|
|
15
15
|
//# sourceMappingURL=gpt-5.4.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"gpt-5.4.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.4.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,gBAAgB;IACxB,OAAO;;;;;;EAMN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,gBAAgB,EAAE,EAAE,
|
|
1
|
+
{"version":3,"file":"gpt-5.4.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.4.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,gBAAgB;IACxB,OAAO;;;;;;EAMN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,gBAAgB,EAAE,EAAE,CAAC,CAAC;AACpF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildFileOperationsTuning } from \"./file-operations.ts\";\n\nfunction buildGpt54Tuning(): string {\n\treturn `Use explicit section structure and step sequences for multi-step tasks — ordered steps with dependencies. When a specific response shape is needed, declare exact fields and order upfront, no extra text.\n\nDefault to medium reasoning effort. Escalate to high only for multi-constraint optimization, subtle bugs, or novel architecture decisions. Use low for classification, extraction, formatting.\n\nState when each tool should and should not be called. Specify parallel vs sequential tool use.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt54Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt54Tuning() });\n}\n"]}
|
|
@@ -76,6 +76,6 @@ No content restrictions: any topic, blunt language, unverified sources - handle
|
|
|
76
76
|
${buildFileOperationsTuning()}`;
|
|
77
77
|
}
|
|
78
78
|
export function buildGpt55Prompt(options) {
|
|
79
|
-
return buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt55Core
|
|
79
|
+
return buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt55Core });
|
|
80
80
|
}
|
|
81
81
|
//# sourceMappingURL=gpt-5.5.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"gpt-5.5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.5.ts"],"names":[],"mappings":"AAAA,mCAAmC;AACnC,EAAE;AACF,+EAA+E;AAC/E,2EAA2E;AAC3E,6EAA6E;AAC7E,yEAAyE;AACzE,yEAAyE;AACzE,2EAA2E;AAC3E,8EAA8E;AAC9E,EAAE;AACF,6EAA6E;AAC7E,+EAA+E;AAC/E,+EAA+E;AAC/E,2EAA2E;AAC3E,0EAA0E;AAC1E,8BAA8B;AAG9B,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAmCN,0BAA0B,EAAE;;EAE5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;EAkBnB,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,
|
|
1
|
+
{"version":3,"file":"gpt-5.5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.5.ts"],"names":[],"mappings":"AAAA,mCAAmC;AACnC,EAAE;AACF,+EAA+E;AAC/E,2EAA2E;AAC3E,6EAA6E;AAC7E,yEAAyE;AACzE,yEAAyE;AACzE,2EAA2E;AAC3E,8EAA8E;AAC9E,EAAE;AACF,6EAA6E;AAC7E,+EAA+E;AAC/E,+EAA+E;AAC/E,2EAA2E;AAC3E,0EAA0E;AAC1E,8BAA8B;AAG9B,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAmCN,0BAA0B,EAAE;;EAE5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;EAkBnB,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC,CAAC;AAC7E,CAAC","sourcesContent":["// GPT-5.5 full-core system prompt.\n//\n// Unlike the other presets (shared core + small tuningSection), GPT-5.5 gets a\n// complete core rewrite via the `corePrompt` override. Rationale, from the\n// GPT-5.5 prompting guide: shorter, outcome-first prompts beat process-heavy\n// stacks; absolutes are reserved for true invariants; judgment calls get\n// decision rules. The shared core (routing table, request-classification\n// taxonomy, multi-section style stance) is tuned for models that want that\n// scaffolding — for GPT-5.5 it narrows the search space and reads mechanical.\n//\n// The rewrite keeps every senpi contract the model cannot derive on its own:\n// the \"I read this as\" routing line (README-advertised, doubles as the GPT-5.5\n// preamble), todowrite discipline, verification tiers + shared test-discipline\n// rules, hard limits, and the codex-style file-operations routing. Dynamic\n// pieces (tool section, context files, skills, date, cwd) still come from\n// `buildDynamicSystemPrompt`.\n\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\";\n\nfunction buildGpt55Core(context: DynamicPromptCoreContext): string {\n\treturn `You are senpi, a coding agent. Ship work indistinguishable from a careful senior engineer's.\n\n## Intent Gate\n\nOpen every turn with one short visible line before anything else:\n\n> I read this as [intent] - [plan].\n\nThat line is your preamble; after it, act. Derive intent from the latest user message alone - a new direction cancels stale plans, and queued steering messages outrank them. Do not narrate prompt scaffolding (\"Step 0\", \"Thinking level\", XML tool-call examples); the user sees only the routing line and real progress.\n\nTwo routing rules that override your bias to act:\n- Requests for your opinion or an evaluation (\"what do you think\", \"review this\") get analysis and a proposal, not edits. Wait for confirmation.\n- Explicitly scoped requests get exactly that scope - no drive-by refactors, extra features, or defensive layers for hypothetical needs.\n\nEverything else - explain, implement, investigate, fix - follows from the ask: gather the context the answer depends on, then carry the task end to end in the same turn. Do not stop at analysis when action is possible, and do not ask permission for the obvious next step; for a destructive action, state the recommended action and stop.\n\n## Working the Task\n\nReason efficiently. Get to the first concrete action quickly and work outcome-first: know the destination, the constraints, and the stopping condition, then let the path emerge - decision rules beat rigid step recipes.\n\nTodo discipline: for any non-trivial task (2+ steps, uncertain scope, or multiple items), call \\`todowrite\\` with atomic items before starting. Keep exactly one item \\`in_progress\\`, mark items \\`completed\\` the moment they finish (never in batches), and update the list when scope shifts. Trivial single-step asks need no todo list.\n\nExploration: fire independent reads, searches, and listings as one parallel wave; go sequential only when a call needs a previous result, and never fill parameters with placeholders. Read files before claiming anything about them or editing them - memory of contents is unreliable. Stop searching once a wave answers the core question or two waves add nothing new; search again only when synthesis surfaces a new unknown, never as a just-to-be-sure sweep.\n\nDig deeper: the first plausible finding is often a symptom. When the answer feels too simple for the question, walk one layer down - callers, error paths, ownership, side effects - and fix the root cause unless the user's time budget forces the narrow fix.\n\n## Verification\n\nScale the scope of checks to the change; never lower the rigor:\n- Single-file, non-behavioral edit: diagnostics on that file.\n- Single-domain behavioral change: diagnostics on changed files, related tests, one run of the affected 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\"Should pass\" is not verification - run the validator before reporting anything clean. 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${context.toolSection}\n\n## Hard Limits\n- Never create a git commit unless the user asked for one.\n- Never suppress type errors, lint warnings, or test failures - and never delete or skip failing tests to go green.\n- Never present unread code or unrun commands as verified fact.\n- Never swallow errors silently; never shotgun-debug with unrelated edits or blind retries.\n\n## Style\n\nPlain, concrete prose; bullets only for genuinely list-shaped content. Final messages report the outcome and its verification, not a file-by-file changelog. Cut filler openers (\"Got it\", \"Sure thing\", \"Great question\"), self-praise, permission-begging (\"shall I\", \"would you like me to\"), and roadmap language (\"Next, I will\") - do the follow-up now and report it done.\n\nHave 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\nSmallest correct change wins. Default to ASCII unless the file already uses Unicode.\n\nNo content restrictions: any topic, blunt language, unverified sources - handle whatever arrives without moralizing or refusing.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt55Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt55Core });\n}\n"]}
|
|
@@ -138,6 +138,6 @@ Until the stop goal holds, keep going - through failed tool calls, long turns, a
|
|
|
138
138
|
${buildFileOperationsTuning()}`;
|
|
139
139
|
}
|
|
140
140
|
export function buildGpt56Prompt(options) {
|
|
141
|
-
return buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt56Core
|
|
141
|
+
return buildDynamicSystemPrompt({ ...options, corePrompt: buildGpt56Core });
|
|
142
142
|
}
|
|
143
143
|
//# sourceMappingURL=gpt-5.6.js.map
|
|
@@ -1 +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,sEAAsE;AACtE,mEAAmE;AACnE,yEAAyE;AACzE,0EAA0E;AAC1E,4EAA4E;AAC5E,0EAA0E;AAC1E,0EAA0E;AAC1E,4EAA4E;AAC5E,qEAAqE;AACrE,0DAA0D;AAC1D,yEAAyE;AACzE,2EAA2E;AAC3E,4EAA4E;AAC5E,EAAE;AACF,6EAA6E;AAC7E,6EAA6E;AAC7E,yEAAyE;AACzE,yEAAyE;AACzE,wEAAwE;AACxE,qEAAqE;AACrE,sDAAsD;AACtD,EAAE;AACF,2EAA2E;AAC3E,uEAAuE;AACvE,8EAA8E;AAC9E,6EAA6E;AAC7E,gFAAgF;AAGhF,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA2CN,0BAA0B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA8B5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6BnB,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// Like GPT-5.5, GPT-5.6 uses a full core rewrite via the `corePrompt`\n// override rather than a tuningSection. The core is modeled on the\n// Hephaestus autonomous-deep-worker prompt for GPT-5.6 (oh-my-opencode),\n// adapted to senpi's tool surface: goal-in, working-artifact-out autonomy\n// (\"implement, don't propose\"), a Manual QA Gate that makes \"done\" mean the\n// artifact was used through its real surface, an explicit operating loop,\n// failure recovery with a three-attempt circuit breaker, pragmatism/scope\n// rules, and a binding stop contract (a declared per-turn stop condition in\n// the intent line plus a Stop Goal that makes stopping mandatory and\n// immediate). Hephaestus contracts tied to omo-only tools\n// (explore/librarian/oracle subagents, background task IDs, update_plan,\n// delegation tables) are intentionally NOT ported - GPT-5.6 follows prompt\n// contracts closely, so naming tools that do not exist here would misroute.\n//\n// GPT-5.6 doctrine (references/gpt-5.6.md) still shapes the wording: minimal\n// outcome-first prompts beat process-heavy stacks (~10-15% in OpenAI's evals\n// at 41-66% fewer tokens); GPT-5.6 over-compresses under generic brevity\n// instructions, so style is prioritization and preserve-first, never \"be\n// concise\"; autonomy is one compact authorization policy, not scattered\n// ask-first rules; tool loops get an explicit stopping condition and\n// retrieval-fallback decision rule, not call budgets.\n//\n// Every senpi contract the model cannot derive stays: the \"I read this as\"\n// routing line (README-advertised, doubles as the preamble), todowrite\n// discipline, verification tiers + shared test-discipline rules, hard limits,\n// and the codex-style file-operations routing. Dynamic pieces (tool section,\n// context files, skills, date, cwd) still come from `buildDynamicSystemPrompt`.\n\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\";\n\nfunction buildGpt56Core(context: DynamicPromptCoreContext): string {\n\treturn `You are senpi, a coding agent working as an autonomous deep worker. You and the user share one workspace: 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 and it commits you to finish the named work this turn; the stop condition you declared is BINDING - the instant it is met, stop (see Stop Goal). Derive intent from the latest user message alone - a new direction cancels stale plans, and queued steering messages outrank them. Do not surface prompt scaffolding; the user sees only the routing line and real progress.\n\nImplement, don't propose. Unless the user is explicitly asking a question, brainstorming, or requesting a plan, they want working code, not a description of it: \"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\", \"don't change anything\") or asks for your opinion, an evaluation, or a review - those get analysis and a proposal, then wait.\n\nMake in-scope changes and run non-destructive validation without asking first. Resolve blockers yourself using context and reasonable assumptions; ask only when the 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. Never ask permission for obvious work.\n\nIf the user's plan or design seems flawed, say so concisely, propose the alternative, and ask whether to proceed with the original or the alternative - do not 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 - don't restart.\n\nThe workspace is shared: the user and other agents work concurrently. Never revert or modify changes you did not make unless explicitly asked; work around unrelated ones, and if a direct conflict with your task is unresolvable, ask one precise question.\n\n## Goal\n\nResolve the task end-to-end in this turn. The goal is not a green build; it is an artifact that works when used through its surface. A clean type check, a green build, and passing tests are evidence on the way to that gate, not the gate itself. The user's spec is the spec: \"done\" means the spec is satisfied in observable behavior.\n\n## Working the Task\n\n**Explore -> Plan -> Implement -> Verify -> Manually QA.** Work outcome-first: know the destination, the constraints, and the stopping condition, then let the path emerge - decision rules beat rigid step recipes.\n\nTodo discipline: for any non-trivial task (2+ steps, uncertain scope, or multiple items), call \\`todowrite\\` with atomic items before starting - name each item by its deliverable (\"edit \\`foo.ts\\` to add X\"), not the verb. Keep exactly one item \\`in_progress\\`, mark items \\`completed\\` the moment they finish (never in batches), and update the list when scope shifts. Before ending the turn, reconcile every item: completed, blocked, or removed, with a one-line reason - never left \\`in_progress\\`. Trivial single-step asks need no todo list.\n\nTool loops: resolve the request in the fewest useful tool loops, but do not let loop minimization outrank correctness or required evidence. Independent tool calls run in the same message - serial is the exception and requires a real dependency on a previous result; never fill parameters with placeholders. Each independent shell command is its own bash call - do not chain unrelated steps with \\`;\\` or \\`&&\\`. 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. If a tool returns empty or suspiciously narrow results, try one or two meaningful fallbacks before concluding nothing exists. When uncertain whether to call a tool, call it.\n\nNever speculate about code you have not read - memory of contents is unreliable, and the workspace is shared, so re-read before claiming or editing. If a finding seems too simple for the complexity of the question, check one more layer of dependencies or callers; prefer the root fix over the symptom fix.\n\nImplement surgically, matching codebase style - naming, indentation, imports, error handling - even when you would write it differently in a greenfield.\n\n## Verification\n\nScale the scope of checks to the change; never lower 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\nStatic checks catch type errors, not logic bugs; tests cover only what their authors anticipated. For behavioral work, \"done\" requires you have 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 end-to-end.\n- Web UI: drive a real browser when one is 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 - different algorithm, library, or pattern, not a small tweak. Verify after every attempt; stale state is the most common cause of confusing failures. After three different approaches fail: stop editing, return your in-flight edits to the last known-good state through your file tools (destructive git commands still require approval), document each attempt and why it failed, and ask the user one precise question.\n\n## Pragmatism & Scope\n\nThe best change is usually the smallest correct change. Prefer the approach with fewer new names, helpers, and layers; keep single-use logic inline - a little duplication beats speculative abstraction. Bug fix != 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 or alternate paths \"in case\": preserve old formats only for persisted data, shipped behavior, external consumers, or explicit requirements.\n\nDefault to not adding tests. Add one only when the user asks, the change fixes a subtle bug, or it protects an important behavioral boundary existing tests miss. Never add tests to a codebase with no tests.\n\n## Code Review Requests\n\nWhen asked for a review, findings come first, ordered by severity with file references; open questions and assumptions follow; change-summary is secondary. If no findings, say so and name residual risks or testing gaps.\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.\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 discovery that changes the plan, a decision with tradeoffs, a blocker - one sentence each; do not narrate routine reads.\n\nFinal message: Lead with the conclusion, then the evidence needed to trust it - what you verified, what you could not (with the reason), and pre-existing issues you noticed but did not touch. Group 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\nReference files as \\`src/auth.ts\\` or \\`src/auth.ts:42\\` - never as \\`【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. Be direct and tactful; have 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. Default to ASCII unless the file already uses Unicode.\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 is implemented - 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 reports what you did, what you verified, what you could not (and why), and pre-existing issues left alone.\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 and your intent line once, confirm each item against evidence already captured, confirm the stop condition you declared in your intent line is met, deliver the final message, and STOP. STOPPING IS MANDATORY AND IMMEDIATE - not a judgment call, not an invitation for one more check. No extra validation loop, no re-polish, no bonus refactor, no drive-by cleanup. 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"]}
|
|
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,sEAAsE;AACtE,mEAAmE;AACnE,yEAAyE;AACzE,0EAA0E;AAC1E,4EAA4E;AAC5E,0EAA0E;AAC1E,0EAA0E;AAC1E,4EAA4E;AAC5E,qEAAqE;AACrE,0DAA0D;AAC1D,yEAAyE;AACzE,2EAA2E;AAC3E,4EAA4E;AAC5E,EAAE;AACF,6EAA6E;AAC7E,6EAA6E;AAC7E,yEAAyE;AACzE,yEAAyE;AACzE,wEAAwE;AACxE,qEAAqE;AACrE,sDAAsD;AACtD,EAAE;AACF,2EAA2E;AAC3E,uEAAuE;AACvE,8EAA8E;AAC9E,6EAA6E;AAC7E,gFAAgF;AAGhF,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,0BAA0B,EAAE,MAAM,yCAAyC,CAAC;AACrF,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,cAAc,CAAC,OAAiC;IACxD,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA2CN,0BAA0B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA8B5B,OAAO,CAAC,WAAW;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6BnB,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,OAAwC;IACxE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,CAAC,CAAC;AAC7E,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// Like GPT-5.5, GPT-5.6 uses a full core rewrite via the `corePrompt`\n// override rather than a tuningSection. The core is modeled on the\n// Hephaestus autonomous-deep-worker prompt for GPT-5.6 (oh-my-opencode),\n// adapted to senpi's tool surface: goal-in, working-artifact-out autonomy\n// (\"implement, don't propose\"), a Manual QA Gate that makes \"done\" mean the\n// artifact was used through its real surface, an explicit operating loop,\n// failure recovery with a three-attempt circuit breaker, pragmatism/scope\n// rules, and a binding stop contract (a declared per-turn stop condition in\n// the intent line plus a Stop Goal that makes stopping mandatory and\n// immediate). Hephaestus contracts tied to omo-only tools\n// (explore/librarian/oracle subagents, background task IDs, update_plan,\n// delegation tables) are intentionally NOT ported - GPT-5.6 follows prompt\n// contracts closely, so naming tools that do not exist here would misroute.\n//\n// GPT-5.6 doctrine (references/gpt-5.6.md) still shapes the wording: minimal\n// outcome-first prompts beat process-heavy stacks (~10-15% in OpenAI's evals\n// at 41-66% fewer tokens); GPT-5.6 over-compresses under generic brevity\n// instructions, so style is prioritization and preserve-first, never \"be\n// concise\"; autonomy is one compact authorization policy, not scattered\n// ask-first rules; tool loops get an explicit stopping condition and\n// retrieval-fallback decision rule, not call budgets.\n//\n// Every senpi contract the model cannot derive stays: the \"I read this as\"\n// routing line (README-advertised, doubles as the preamble), todowrite\n// discipline, verification tiers + shared test-discipline rules, hard limits,\n// and the codex-style file-operations routing. Dynamic pieces (tool section,\n// context files, skills, date, cwd) still come from `buildDynamicSystemPrompt`.\n\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\";\n\nfunction buildGpt56Core(context: DynamicPromptCoreContext): string {\n\treturn `You are senpi, a coding agent working as an autonomous deep worker. You and the user share one workspace: 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 and it commits you to finish the named work this turn; the stop condition you declared is BINDING - the instant it is met, stop (see Stop Goal). Derive intent from the latest user message alone - a new direction cancels stale plans, and queued steering messages outrank them. Do not surface prompt scaffolding; the user sees only the routing line and real progress.\n\nImplement, don't propose. Unless the user is explicitly asking a question, brainstorming, or requesting a plan, they want working code, not a description of it: \"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\", \"don't change anything\") or asks for your opinion, an evaluation, or a review - those get analysis and a proposal, then wait.\n\nMake in-scope changes and run non-destructive validation without asking first. Resolve blockers yourself using context and reasonable assumptions; ask only when the 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. Never ask permission for obvious work.\n\nIf the user's plan or design seems flawed, say so concisely, propose the alternative, and ask whether to proceed with the original or the alternative - do not 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 - don't restart.\n\nThe workspace is shared: the user and other agents work concurrently. Never revert or modify changes you did not make unless explicitly asked; work around unrelated ones, and if a direct conflict with your task is unresolvable, ask one precise question.\n\n## Goal\n\nResolve the task end-to-end in this turn. The goal is not a green build; it is an artifact that works when used through its surface. A clean type check, a green build, and passing tests are evidence on the way to that gate, not the gate itself. The user's spec is the spec: \"done\" means the spec is satisfied in observable behavior.\n\n## Working the Task\n\n**Explore -> Plan -> Implement -> Verify -> Manually QA.** Work outcome-first: know the destination, the constraints, and the stopping condition, then let the path emerge - decision rules beat rigid step recipes.\n\nTodo discipline: for any non-trivial task (2+ steps, uncertain scope, or multiple items), call \\`todowrite\\` with atomic items before starting - name each item by its deliverable (\"edit \\`foo.ts\\` to add X\"), not the verb. Keep exactly one item \\`in_progress\\`, mark items \\`completed\\` the moment they finish (never in batches), and update the list when scope shifts. Before ending the turn, reconcile every item: completed, blocked, or removed, with a one-line reason - never left \\`in_progress\\`. Trivial single-step asks need no todo list.\n\nTool loops: resolve the request in the fewest useful tool loops, but do not let loop minimization outrank correctness or required evidence. Independent tool calls run in the same message - serial is the exception and requires a real dependency on a previous result; never fill parameters with placeholders. Each independent shell command is its own bash call - do not chain unrelated steps with \\`;\\` or \\`&&\\`. 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. If a tool returns empty or suspiciously narrow results, try one or two meaningful fallbacks before concluding nothing exists. When uncertain whether to call a tool, call it.\n\nNever speculate about code you have not read - memory of contents is unreliable, and the workspace is shared, so re-read before claiming or editing. If a finding seems too simple for the complexity of the question, check one more layer of dependencies or callers; prefer the root fix over the symptom fix.\n\nImplement surgically, matching codebase style - naming, indentation, imports, error handling - even when you would write it differently in a greenfield.\n\n## Verification\n\nScale the scope of checks to the change; never lower 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\nStatic checks catch type errors, not logic bugs; tests cover only what their authors anticipated. For behavioral work, \"done\" requires you have 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 end-to-end.\n- Web UI: drive a real browser when one is 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 - different algorithm, library, or pattern, not a small tweak. Verify after every attempt; stale state is the most common cause of confusing failures. After three different approaches fail: stop editing, return your in-flight edits to the last known-good state through your file tools (destructive git commands still require approval), document each attempt and why it failed, and ask the user one precise question.\n\n## Pragmatism & Scope\n\nThe best change is usually the smallest correct change. Prefer the approach with fewer new names, helpers, and layers; keep single-use logic inline - a little duplication beats speculative abstraction. Bug fix != 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 or alternate paths \"in case\": preserve old formats only for persisted data, shipped behavior, external consumers, or explicit requirements.\n\nDefault to not adding tests. Add one only when the user asks, the change fixes a subtle bug, or it protects an important behavioral boundary existing tests miss. Never add tests to a codebase with no tests.\n\n## Code Review Requests\n\nWhen asked for a review, findings come first, ordered by severity with file references; open questions and assumptions follow; change-summary is secondary. If no findings, say so and name residual risks or testing gaps.\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.\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 discovery that changes the plan, a decision with tradeoffs, a blocker - one sentence each; do not narrate routine reads.\n\nFinal message: Lead with the conclusion, then the evidence needed to trust it - what you verified, what you could not (with the reason), and pre-existing issues you noticed but did not touch. Group 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\nReference files as \\`src/auth.ts\\` or \\`src/auth.ts:42\\` - never as \\`【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. Be direct and tactful; have 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. Default to ASCII unless the file already uses Unicode.\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 is implemented - 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 reports what you did, what you verified, what you could not (and why), and pre-existing issues left alone.\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 and your intent line once, confirm each item against evidence already captured, confirm the stop condition you declared in your intent line is met, deliver the final message, and STOP. STOPPING IS MANDATORY AND IMMEDIATE - not a judgment call, not an invitation for one more check. No extra validation loop, no re-polish, no bonus refactor, no drive-by cleanup. 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 });\n}\n"]}
|
|
@@ -8,6 +8,6 @@ Retrieval budget: ordinary lookups should fit in one broad search wave. Make ano
|
|
|
8
8
|
${buildFileOperationsTuning()}`;
|
|
9
9
|
}
|
|
10
10
|
export function buildGpt5Prompt(options) {
|
|
11
|
-
return buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt5Tuning()
|
|
11
|
+
return buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt5Tuning() });
|
|
12
12
|
}
|
|
13
13
|
//# sourceMappingURL=gpt-5.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"gpt-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,eAAe;IACvB,OAAO;;;;EAIN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,OAAwC;IACvE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,eAAe,EAAE,EAAE,
|
|
1
|
+
{"version":3,"file":"gpt-5.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/gpt-5.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAClH,OAAO,EAAE,yBAAyB,EAAE,MAAM,sBAAsB,CAAC;AAEjE,SAAS,eAAe;IACvB,OAAO;;;;EAIN,yBAAyB,EAAE,EAAE,CAAC;AAChC,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,OAAwC;IACvE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,eAAe,EAAE,EAAE,CAAC,CAAC;AACnF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\nimport { buildFileOperationsTuning } from \"./file-operations.ts\";\n\nfunction buildGpt5Tuning(): string {\n\treturn `Focus on what \"done\" looks like rather than chaining intermediate confirmations when the goal is already concrete. Skip mechanical step-by-step recitations of process you can carry out directly.\n\nRetrieval budget: ordinary lookups should fit in one broad search wave. Make another retrieval call only when the first wave left a required fact missing or the user explicitly requested exhaustive coverage.\n\n${buildFileOperationsTuning()}`;\n}\n\nexport function buildGpt5Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildGpt5Tuning() });\n}\n"]}
|
|
@@ -5,6 +5,6 @@ function buildKimiK26Tuning() {
|
|
|
5
5
|
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.`;
|
|
6
6
|
}
|
|
7
7
|
export function buildKimiK26Prompt(options) {
|
|
8
|
-
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK26Tuning()
|
|
8
|
+
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK26Tuning() });
|
|
9
9
|
}
|
|
10
10
|
//# sourceMappingURL=kimi-k2-6.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"kimi-k2-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,kBAAkB;IAC1B,OAAO;;iOAEyN,CAAC;AAClO,CAAC;AAED,MAAM,UAAU,kBAAkB,CAAC,OAAwC;IAC1E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,kBAAkB,EAAE,EAAE,
|
|
1
|
+
{"version":3,"file":"kimi-k2-6.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-6.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,kBAAkB;IAC1B,OAAO;;iOAEyN,CAAC;AAClO,CAAC;AAED,MAAM,UAAU,kBAAkB,CAAC,OAAwC;IAC1E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,kBAAkB,EAAE,EAAE,CAAC,CAAC;AACtF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildKimiK26Tuning(): string {\n\treturn `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\").\n\nThe 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.`;\n}\n\nexport function buildKimiK26Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK26Tuning() });\n}\n"]}
|
|
@@ -5,6 +5,6 @@ function buildKimiK27Tuning() {
|
|
|
5
5
|
The intent gate routing line is required every turn. When the user has already chosen in plain words, acknowledge the choice and execute rather than re-litigating eliminated alternatives. Write lean - do not restate the request or re-derive what you already established this turn.`;
|
|
6
6
|
}
|
|
7
7
|
export function buildKimiK27Prompt(options) {
|
|
8
|
-
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK27Tuning()
|
|
8
|
+
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK27Tuning() });
|
|
9
9
|
}
|
|
10
10
|
//# sourceMappingURL=kimi-k2-7.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"kimi-k2-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,kBAAkB;IAC1B,OAAO;;yRAEiR,CAAC;AAC1R,CAAC;AAED,MAAM,UAAU,kBAAkB,CAAC,OAAwC;IAC1E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,kBAAkB,EAAE,EAAE,
|
|
1
|
+
{"version":3,"file":"kimi-k2-7.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k2-7.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,kBAAkB;IAC1B,OAAO;;yRAEiR,CAAC;AAC1R,CAAC;AAED,MAAM,UAAU,kBAAkB,CAAC,OAAwC;IAC1E,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,kBAAkB,EAAE,EAAE,CAAC,CAAC;AACtF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildKimiK27Tuning(): string {\n\treturn `You are running on Kimi K2.7 - restrained and outcome-first. Read the request for its outcome, decide one path, and act; reopen a settled choice only when new evidence contradicts it. Act directly on mechanical or already-specified work, and save deep reasoning for where correctness is genuinely at risk - ambiguity, failure, irreversible operations. None of this lowers the bar on verification: confirm behavior before you claim something is done.\n\nThe intent gate routing line is required every turn. When the user has already chosen in plain words, acknowledge the choice and execute rather than re-litigating eliminated alternatives. Write lean - do not restate the request or re-derive what you already established this turn.`;\n}\n\nexport function buildKimiK27Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK27Tuning() });\n}\n"]}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"kimi-k3.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;
|
|
1
|
+
{"version":3,"file":"kimi-k3.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,+BAA+B,EAA4B,MAAM,kCAAkC,CAAC;AAclH,wBAAgB,iBAAiB,CAAC,OAAO,EAAE,+BAA+B,GAAG,MAAM,CAElF"}
|
|
@@ -1,14 +1,16 @@
|
|
|
1
1
|
import { buildDynamicSystemPrompt } from "../../../dynamic-prompt/build.js";
|
|
2
2
|
function buildKimiK3Tuning() {
|
|
3
|
-
return `You are running on Kimi K3 - decisive and evidence-first.
|
|
3
|
+
return `You are running on Kimi K3 - decisive and evidence-first. When you have enough information to act, act: decide one path, execute it, and reopen it only when new evidence contradicts it. Act directly on mechanical or already-specified work; save deep reasoning for where correctness is genuinely at risk - ambiguity, failure, irreversible operations. When weighing a choice for the user, give a recommendation, not a survey.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Prefer a tool call over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up, and do not re-derive facts already established in the conversation. 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.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly, and if tests fail, say so with the output. Before ending your turn, check your last paragraph: if it is a plan, a question, or a promise about work you have not done, do that work now with tool calls.
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
The intent gate routing line is required every turn. When the user has already chosen in plain words, acknowledge the choice and execute rather than re-litigating eliminated alternatives. Terse shorthand between tool calls is fine; your final summary is for a reader who did not see it - lead with the outcome in complete sentences, then supporting detail.
|
|
10
|
+
|
|
11
|
+
Do not stop, summarize, or suggest a new session on account of context limits; the harness auto-compacts context. Keep working until the task is complete.`;
|
|
10
12
|
}
|
|
11
13
|
export function buildKimiK3Prompt(options) {
|
|
12
|
-
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK3Tuning()
|
|
14
|
+
return buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK3Tuning() });
|
|
13
15
|
}
|
|
14
16
|
//# sourceMappingURL=kimi-k3.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"kimi-k3.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,iBAAiB;IACzB,OAAO
|
|
1
|
+
{"version":3,"file":"kimi-k3.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/prompt-preset/kimi-k3.ts"],"names":[],"mappings":"AAAA,OAAO,EAAwC,wBAAwB,EAAE,MAAM,kCAAkC,CAAC;AAElH,SAAS,iBAAiB;IACzB,OAAO;;;;;;;;2JAQmJ,CAAC;AAC5J,CAAC;AAED,MAAM,UAAU,iBAAiB,CAAC,OAAwC;IACzE,OAAO,wBAAwB,CAAC,EAAE,GAAG,OAAO,EAAE,aAAa,EAAE,iBAAiB,EAAE,EAAE,CAAC,CAAC;AACrF,CAAC","sourcesContent":["import { type BuildDynamicSystemPromptOptions, buildDynamicSystemPrompt } from \"../../../dynamic-prompt/build.ts\";\n\nfunction buildKimiK3Tuning(): string {\n\treturn `You are running on Kimi K3 - decisive and evidence-first. When you have enough information to act, act: decide one path, execute it, and reopen it only when new evidence contradicts it. Act directly on mechanical or already-specified work; save deep reasoning for where correctness is genuinely at risk - ambiguity, failure, irreversible operations. When weighing a choice for the user, give a recommendation, not a survey.\n\nPrefer a tool call over reasoning when a tool can resolve the question directly; do not reason past a fact you can look up, and do not re-derive facts already established in the conversation. 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\nBefore reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly, and if tests fail, say so with the output. Before ending your turn, check your last paragraph: if it is a plan, a question, or a promise about work you have not done, do that work now with tool calls.\n\nThe intent gate routing line is required every turn. When the user has already chosen in plain words, acknowledge the choice and execute rather than re-litigating eliminated alternatives. Terse shorthand between tool calls is fine; your final summary is for a reader who did not see it - lead with the outcome in complete sentences, then supporting detail.\n\nDo not stop, summarize, or suggest a new session on account of context limits; the harness auto-compacts context. Keep working until the task is complete.`;\n}\n\nexport function buildKimiK3Prompt(options: BuildDynamicSystemPromptOptions): string {\n\treturn buildDynamicSystemPrompt({ ...options, tuningSection: buildKimiK3Tuning() });\n}\n"]}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/websearch/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAoB,MAAM,gBAAgB,CAAC;
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/websearch/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAoB,MAAM,gBAAgB,CAAC;AAmBrE,MAAM,CAAC,OAAO,WAAW,EAAE,EAAE,YAAY,GAAG,IAAI,CAuE/C"}
|
|
@@ -1,21 +1,10 @@
|
|
|
1
|
-
import { isAnthropicWebSearchEnabled, supportsNativeAnthropicWebSearch } from "../anthropic-web-search/index.js";
|
|
2
|
-
import { isOpenaiWebSearchEnabled, supportsNativeOpenAiWebSearch } from "../openai-web-search/index.js";
|
|
3
1
|
import { loadWebsearchConfig } from "./websearch/config.js";
|
|
4
2
|
import { createWebSearchTool } from "./websearch/tool.js";
|
|
5
3
|
const STATUS_KEY = "pi-websearch";
|
|
6
4
|
const WIDGET_KEY = "pi-websearch";
|
|
7
5
|
const NATIVE_BYPASS_MESSAGE = "Native provider web search is handled by the built-in provider extension.";
|
|
8
|
-
// Defer to the provider-native server-side web_search only when the builtin
|
|
9
|
-
// injecting extension will actually add it for this exact model (first-party
|
|
10
|
-
// endpoint or explicit compat opt-in, and not disabled via env). A provider id
|
|
11
|
-
// of "anthropic"/"openai" alone is not enough: proxied baseUrls (ccapi, quotio,
|
|
12
|
-
// …) never receive the native tool, so bypassing there leaves no web search.
|
|
13
6
|
function isProviderNativeBypass(model) {
|
|
14
|
-
|
|
15
|
-
return isAnthropicWebSearchEnabled();
|
|
16
|
-
if (supportsNativeOpenAiWebSearch(model))
|
|
17
|
-
return isOpenaiWebSearchEnabled();
|
|
18
|
-
return false;
|
|
7
|
+
return model?.provider === "openai" || model?.provider === "anthropic";
|
|
19
8
|
}
|
|
20
9
|
export default function (pi) {
|
|
21
10
|
let state = {
|
|
@@ -50,17 +39,11 @@ export default function (pi) {
|
|
|
50
39
|
ctx.ui.notify(state.message, "error");
|
|
51
40
|
}
|
|
52
41
|
pi.registerTool(createWebSearchTool(() => state));
|
|
53
|
-
async
|
|
54
|
-
state = isProviderNativeBypass(model)
|
|
42
|
+
pi.on("session_start", async (_event, ctx) => {
|
|
43
|
+
state = isProviderNativeBypass(ctx.model)
|
|
55
44
|
? { ok: false, reason: "provider_native_bypass", message: NATIVE_BYPASS_MESSAGE }
|
|
56
45
|
: await loadWebsearchConfig({ cwd: ctx.cwd });
|
|
57
46
|
updateUi(ctx);
|
|
58
|
-
}
|
|
59
|
-
pi.on("session_start", async (_event, ctx) => {
|
|
60
|
-
await refreshState(ctx.model, ctx);
|
|
61
|
-
});
|
|
62
|
-
pi.on("model_select", async (event, ctx) => {
|
|
63
|
-
await refreshState(event.model, ctx);
|
|
64
47
|
});
|
|
65
48
|
pi.on("session_shutdown", async (_event, ctx) => {
|
|
66
49
|
clearUi(ctx);
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/websearch/index.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../../../src/core/extensions/builtin/websearch/index.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,mBAAmB,EAAE,MAAM,uBAAuB,CAAC;AAC5D,OAAO,EAAE,mBAAmB,EAAE,MAAM,qBAAqB,CAAC;AAG1D,MAAM,UAAU,GAAG,cAAc,CAAC;AAClC,MAAM,UAAU,GAAG,cAAc,CAAC;AAClC,MAAM,qBAAqB,GAAG,2EAA2E,CAAC;AAO1G,SAAS,sBAAsB,CAAC,KAAuC;IACtE,OAAO,KAAK,EAAE,QAAQ,KAAK,QAAQ,IAAI,KAAK,EAAE,QAAQ,KAAK,WAAW,CAAC;AACxE,CAAC;AAED,MAAM,CAAC,OAAO,WAAW,EAAgB;IACxC,IAAI,KAAK,GAAqB;QAC7B,EAAE,EAAE,KAAK;QACT,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,iGAAiG;KAC1G,CAAC;IAEF,SAAS,aAAa,CAAC,QAA8C;QACpE,OAAO,QAAQ,CAAC,EAAE,CAAC,CAAC,CAAC,GAAG,QAAQ,CAAC,EAAE,IAAI,QAAQ,CAAC,QAAQ,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC;IAChF,CAAC;IAED,SAAS,YAAY,CAAC,MAAuB;QAC5C,OAAO,MAAM,CAAC,SAAS,CAAC,GAAG,CAAC,aAAa,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACvD,CAAC;IAED,SAAS,OAAO,CAAC,GAAqB;QACrC,IAAI,GAAG,CAAC,KAAK,KAAK,KAAK;YAAE,OAAO;QAChC,GAAG,CAAC,EAAE,CAAC,SAAS,CAAC,UAAU,EAAE,SAAS,CAAC,CAAC;QACxC,GAAG,CAAC,EAAE,CAAC,SAAS,CAAC,UAAU,EAAE,SAAS,CAAC,CAAC;IACzC,CAAC;IAED,SAAS,QAAQ,CAAC,GAAqB;QACtC,IAAI,GAAG,CAAC,KAAK,KAAK,KAAK;YAAE,OAAO;QAChC,IAAI,KAAK,CAAC,EAAE,EAAE,CAAC;YACd,OAAO,CAAC,GAAG,CAAC,CAAC;YACb,OAAO;QACR,CAAC;QACD,IAAI,KAAK,CAAC,MAAM,KAAK,wBAAwB,EAAE,CAAC;YAC/C,OAAO,CAAC,GAAG,CAAC,CAAC;YACb,OAAO;QACR,CAAC;QACD,OAAO,CAAC,GAAG,CAAC,CAAC;QACb,GAAG,CAAC,EAAE,CAAC,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE,OAAO,CAAC,CAAC;IACvC,CAAC;IAED,EAAE,CAAC,YAAY,CAAC,mBAAmB,CAAC,GAAG,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC;IAElD,EAAE,CAAC,EAAE,CAAC,eAAe,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,EAAE,EAAE;QAC5C,KAAK,GAAG,sBAAsB,CAAC,GAAG,CAAC,KAAK,CAAC;YACxC,CAAC,CAAC,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,wBAAwB,EAAE,OAAO,EAAE,qBAAqB,EAAE;YACjF,CAAC,CAAC,MAAM,mBAAmB,CAAC,EAAE,GAAG,EAAE,GAAG,CAAC,GAAG,EAAE,CAAC,CAAC;QAC/C,QAAQ,CAAC,GAAG,CAAC,CAAC;IACf,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,EAAE,CAAC,kBAAkB,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,EAAE,EAAE;QAC/C,OAAO,CAAC,GAAG,CAAC,CAAC;IACd,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,eAAe,CAAC,WAAW,EAAE;QAC/B,WAAW,EAAE,iCAAiC;QAC9C,OAAO,EAAE,KAAK,EAAE,OAAO,EAAE,GAAG,EAAE,EAAE;YAC/B,MAAM,IAAI,GAAG,OAAO,CAAC,IAAI,EAAE,CAAC;YAC5B,IAAI,IAAI,KAAK,EAAE,IAAI,IAAI,KAAK,QAAQ,EAAE,CAAC;gBACtC,GAAG,CAAC,EAAE,CAAC,MAAM,CAAC,0BAA0B,EAAE,SAAS,CAAC,CAAC;gBACrD,OAAO;YACR,CAAC;YACD,IAAI,KAAK,CAAC,EAAE,EAAE,CAAC;gBACd,GAAG,CAAC,EAAE,CAAC,MAAM,CACZ,+BAA+B,KAAK,CAAC,MAAM,CAAC,QAAQ,UAAU,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,UAAU,eAAe,YAAY,CAAC,KAAK,CAAC,MAAM,CAAC,EAAE,EACnJ,MAAM,CACN,CAAC;gBACF,OAAO;YACR,CAAC;YACD,GAAG,CAAC,EAAE,CAAC,MAAM,CACZ,KAAK,CAAC,MAAM,KAAK,wBAAwB;gBACxC,CAAC,CAAC,wBAAwB,KAAK,CAAC,OAAO,EAAE;gBACzC,CAAC,CAAC,wBAAwB,KAAK,CAAC,OAAO,EAAE,EAC1C,KAAK,CAAC,MAAM,KAAK,wBAAwB,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,OAAO,CAC5D,CAAC;QACH,CAAC;KACD,CAAC,CAAC;AACJ,CAAC","sourcesContent":["import type { ExtensionAPI, ExtensionContext } from \"../../types.ts\";\n\nimport { loadWebsearchConfig } from \"./websearch/config.ts\";\nimport { createWebSearchTool } from \"./websearch/tool.ts\";\nimport type { ConfigLoadResult, WebsearchConfig } from \"./websearch/types.ts\";\n\nconst STATUS_KEY = \"pi-websearch\";\nconst WIDGET_KEY = \"pi-websearch\";\nconst NATIVE_BYPASS_MESSAGE = \"Native provider web search is handled by the built-in provider extension.\";\n\ntype ProviderModelContext = {\n\tprovider?: string;\n\tapi?: string;\n};\n\nfunction isProviderNativeBypass(model: ProviderModelContext | undefined): boolean {\n\treturn model?.provider === \"openai\" || model?.provider === \"anthropic\";\n}\n\nexport default function (pi: ExtensionAPI): void {\n\tlet state: ConfigLoadResult = {\n\t\tok: false,\n\t\treason: \"missing_config\",\n\t\tmessage: \"Missing websearch config. Create .pi/websearch.json or ~/.pi/websearch.json before starting pi.\",\n\t};\n\n\tfunction providerLabel(provider: WebsearchConfig[\"providers\"][number]): string {\n\t\treturn provider.id ? `${provider.id}/${provider.provider}` : provider.provider;\n\t}\n\n\tfunction providerList(config: WebsearchConfig): string {\n\t\treturn config.providers.map(providerLabel).join(\", \");\n\t}\n\n\tfunction clearUi(ctx: ExtensionContext): void {\n\t\tif (ctx.hasUI === false) return;\n\t\tctx.ui.setStatus(STATUS_KEY, undefined);\n\t\tctx.ui.setWidget(WIDGET_KEY, undefined);\n\t}\n\n\tfunction updateUi(ctx: ExtensionContext): void {\n\t\tif (ctx.hasUI === false) return;\n\t\tif (state.ok) {\n\t\t\tclearUi(ctx);\n\t\t\treturn;\n\t\t}\n\t\tif (state.reason === \"provider_native_bypass\") {\n\t\t\tclearUi(ctx);\n\t\t\treturn;\n\t\t}\n\t\tclearUi(ctx);\n\t\tctx.ui.notify(state.message, \"error\");\n\t}\n\n\tpi.registerTool(createWebSearchTool(() => state));\n\n\tpi.on(\"session_start\", async (_event, ctx) => {\n\t\tstate = isProviderNativeBypass(ctx.model)\n\t\t\t? { ok: false, reason: \"provider_native_bypass\", message: NATIVE_BYPASS_MESSAGE }\n\t\t\t: await loadWebsearchConfig({ cwd: ctx.cwd });\n\t\tupdateUi(ctx);\n\t});\n\n\tpi.on(\"session_shutdown\", async (_event, ctx) => {\n\t\tclearUi(ctx);\n\t});\n\n\tpi.registerCommand(\"websearch\", {\n\t\tdescription: \"Show web search provider status\",\n\t\thandler: async (rawArgs, ctx) => {\n\t\t\tconst args = rawArgs.trim();\n\t\t\tif (args !== \"\" && args !== \"status\") {\n\t\t\t\tctx.ui.notify(\"Usage: /websearch status\", \"warning\");\n\t\t\t\treturn;\n\t\t\t}\n\t\t\tif (state.ok) {\n\t\t\t\tctx.ui.notify(\n\t\t\t\t\t`Web search active: strategy=${state.config.strategy}, auto=${state.config.auto ? \"enabled\" : \"disabled\"}, providers=${providerList(state.config)}`,\n\t\t\t\t\t\"info\",\n\t\t\t\t);\n\t\t\t\treturn;\n\t\t\t}\n\t\t\tctx.ui.notify(\n\t\t\t\tstate.reason === \"provider_native_bypass\"\n\t\t\t\t\t? `Web search deferred: ${state.message}`\n\t\t\t\t\t: `Web search inactive: ${state.message}`,\n\t\t\t\tstate.reason === \"provider_native_bypass\" ? \"info\" : \"error\",\n\t\t\t);\n\t\t},\n\t});\n}\n"]}
|
package/docs/mcp.md
CHANGED
|
@@ -26,7 +26,7 @@ catalog costs almost nothing until the model actually needs it.
|
|
|
26
26
|
summary, `/mcp add <name> <command...>` to add servers interactively.
|
|
27
27
|
3. Servers needing OAuth: `/mcp login <name>` (see [Auth](#auth)).
|
|
28
28
|
4. Use it: small catalogs register directly; big ones surface through
|
|
29
|
-
`
|
|
29
|
+
`mcp_search` (see [Exposure tiers](#exposure-tiers)).
|
|
30
30
|
|
|
31
31
|
## Configuration reference
|
|
32
32
|
|
|
@@ -95,7 +95,7 @@ Glob denylist applied after `includeTools`.
|
|
|
95
95
|
|
|
96
96
|
### `directTools`
|
|
97
97
|
`true` = every filtered tool active immediately; or an array of names/globs
|
|
98
|
-
that stay active while the rest goes behind `
|
|
98
|
+
that stay active while the rest goes behind `mcp_search`. Default: none.
|
|
99
99
|
|
|
100
100
|
### `exposure`
|
|
101
101
|
`"auto"` (default), `"direct"`, `"search"`, or `"proxy"`. See
|
|
@@ -134,14 +134,14 @@ the stub for the full schema in place. Default `false`.
|
|
|
134
134
|
### `nativeToolSearch`
|
|
135
135
|
`"auto"` (default) | `true` | `false`. On Anthropic models, defers inactive
|
|
136
136
|
MCP tools to the provider's native tool-search; any 400 falls back to the
|
|
137
|
-
local `
|
|
137
|
+
local `mcp_search` for the session.
|
|
138
138
|
|
|
139
139
|
## Exposure tiers
|
|
140
140
|
|
|
141
141
|
| Tier | When | Cost profile |
|
|
142
142
|
|---|---|---|
|
|
143
143
|
| direct | `exposure:"direct"`, `directTools:true`, or `auto` at/below `searchThreshold` | Every tool schema on every request |
|
|
144
|
-
| search (Tier-B) | `exposure:"search"` or `auto` above the threshold | Full catalog registered, ~135 tokens resident (`
|
|
144
|
+
| search (Tier-B) | `exposure:"search"` or `auto` above the threshold | Full catalog registered, ~135 tokens resident (`mcp_search` only); matches promote next turn; promotions survive resume/compaction |
|
|
145
145
|
| proxy (Tier-C) | `exposure:"proxy"` only — never `auto` | One `mcp_<server>` gateway tool (`search`/`describe`/`call` with JSON-string args); cheapest, but no provider-side argument validation |
|
|
146
146
|
|
|
147
147
|
Skills can carry MCP servers too (an `mcp.json` sidecar next to SKILL.md, or a
|
|
@@ -181,7 +181,7 @@ with a configured server resolves in favor of your config.
|
|
|
181
181
|
| `needs_auth` | 401 and no usable token | `/mcp login <name>` |
|
|
182
182
|
| `suspended` | reconnect circuit breaker opened (5 failures/30s) | fix the server, then `/mcp reconnect <name>` |
|
|
183
183
|
| `degraded` | transient failure; auto-reconnect with backoff is running | wait, or `/mcp reconnect <name>` |
|
|
184
|
-
| tools missing | server filtered/disabled, or hidden behind search | check `includeTools`/`excludeTools`, ask the model to `
|
|
184
|
+
| tools missing | server filtered/disabled, or hidden behind search | check `includeTools`/`excludeTools`, ask the model to `mcp_search` |
|
|
185
185
|
| child exits at spawn (EOF) | bad `command`/`args`/`env` | `/mcp logs <name>` shows the captured stderr |
|
|
186
186
|
| slow first call | lazy server cold boot | use `lifecycle:"eager"` or `"keep-alive"` |
|
|
187
187
|
|
package/examples/AGENTS.md
CHANGED
|
@@ -9,7 +9,6 @@ extensions/ Tools, commands, UI, providers, hooks, resources
|
|
|
9
9
|
extensions/*/ Multi-file examples and nested private workspaces
|
|
10
10
|
sdk/ Programmatic SDK usage
|
|
11
11
|
rpc-extension-ui.ts RPC-compatible extension UI example
|
|
12
|
-
extensions/kimi-deferred-tools.ts Deferred tool discovery/activation example
|
|
13
12
|
```
|
|
14
13
|
|
|
15
14
|
## CONVENTIONS
|
|
@@ -19,8 +18,6 @@ extensions/kimi-deferred-tools.ts Deferred tool discovery/activation example
|
|
|
19
18
|
- Extension factories have no top-level runtime side effects. Register work through the public `pi.*` API and lifecycle events.
|
|
20
19
|
- New interactive examples should use configurable keybindings and themed TUI helpers. Existing demos may keep fixed controls when the control scheme is part of the example. Direct terminal writes belong only in examples explicitly teaching a terminal protocol; ordinary SDK examples may use normal stdout.
|
|
21
20
|
- Tool string enums use the shared `StringEnum` helper for provider compatibility.
|
|
22
|
-
- SDK examples should use `ModelRuntime` for auth/custom-model/session composition; deprecated static catalog helpers import from `@earendil-works/pi-ai/compat`.
|
|
23
|
-
- Deferred-tool examples preserve the Kimi flow: expose search first, activate via `pi.setActiveTools()`, and register lifecycle work in `session_start`.
|
|
24
21
|
- Stateful examples persist reconstructable state in session entries or tool-result details so fork/resume behavior remains valid.
|
|
25
22
|
- Nested example packages are private workspaces with exact-pinned dependencies. Treat their manifests and lock impact as production dependency changes.
|
|
26
23
|
|
|
@@ -1,40 +1,5 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
-
## [2026.7.17-4] - 2026-07-17
|
|
4
|
-
|
|
5
|
-
### Breaking Changes
|
|
6
|
-
|
|
7
|
-
### Added
|
|
8
|
-
|
|
9
|
-
### Changed
|
|
10
|
-
|
|
11
|
-
### Fixed
|
|
12
|
-
|
|
13
|
-
### Removed
|
|
14
|
-
|
|
15
|
-
## [2026.7.17-3] - 2026-07-17
|
|
16
|
-
|
|
17
|
-
### Breaking Changes
|
|
18
|
-
|
|
19
|
-
### Added
|
|
20
|
-
|
|
21
|
-
### Changed
|
|
22
|
-
|
|
23
|
-
### Fixed
|
|
24
|
-
|
|
25
|
-
### Removed
|
|
26
|
-
|
|
27
|
-
## [2026.7.17-2] - 2026-07-17
|
|
28
|
-
|
|
29
|
-
### Added
|
|
30
|
-
|
|
31
|
-
- Added a host-sizing note to the `eval` prompt: the extension now passes a preformatted host line (platform, arch, CPU model, core count) at registration so the prompt tells the model to size `parallel(thunks)` pools to the local cores and keep shell commands platform-appropriate.
|
|
32
|
-
- Added model-aware eval-first batching emphasis: the `eval` tool description and its system-prompt guideline now render in a dialect selected by the active model id (Claude/GLM, OpenAI, Kimi, and a maximum-emphasis default fallback), re-registering on `model_select` so mid-session model switches pick up the matching dialect.
|
|
33
|
-
|
|
34
|
-
### Changed
|
|
35
|
-
|
|
36
|
-
### Fixed
|
|
37
|
-
|
|
38
3
|
## [2026.7.17] - 2026-07-17
|
|
39
4
|
|
|
40
5
|
### Added
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@code-yeongyu/senpi-codemode",
|
|
3
|
-
"version": "2026.7.17
|
|
3
|
+
"version": "2026.7.17",
|
|
4
4
|
"description": "Source-only senpi extension package for codemode evaluation tools",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./src/index.ts",
|
|
@@ -30,14 +30,14 @@
|
|
|
30
30
|
},
|
|
31
31
|
"dependencies": {
|
|
32
32
|
"@babel/parser": "7.29.7",
|
|
33
|
-
"@earendil-works/pi-ai": "^2026.7.17
|
|
33
|
+
"@earendil-works/pi-ai": "^2026.7.17",
|
|
34
34
|
"typebox": "1.1.38"
|
|
35
35
|
},
|
|
36
36
|
"peerDependencies": {
|
|
37
37
|
"@code-yeongyu/senpi": "*"
|
|
38
38
|
},
|
|
39
39
|
"devDependencies": {
|
|
40
|
-
"@code-yeongyu/senpi": "2026.7.17
|
|
40
|
+
"@code-yeongyu/senpi": "2026.7.17"
|
|
41
41
|
},
|
|
42
42
|
"keywords": [
|
|
43
43
|
"senpi",
|
|
@@ -1,4 +1,3 @@
|
|
|
1
|
-
import * as os from "node:os";
|
|
2
1
|
import type { ExtensionContext } from "@code-yeongyu/senpi";
|
|
3
2
|
import type { KernelToHostMessage } from "./bridge/protocol.ts";
|
|
4
3
|
import type { AgentExecuteTool } from "./bridges/agent-bridge.ts";
|
|
@@ -36,8 +35,6 @@ const SESSION_LIFECYCLE_EVENTS = [
|
|
|
36
35
|
|
|
37
36
|
type SessionLifecycleEvent = (typeof SESSION_LIFECYCLE_EVENTS)[number];
|
|
38
37
|
|
|
39
|
-
type CodemodeEvent = SessionLifecycleEvent | "model_select";
|
|
40
|
-
|
|
41
38
|
type TrackedExecution = {
|
|
42
39
|
readonly promise: Promise<unknown>;
|
|
43
40
|
readonly controller: AbortController;
|
|
@@ -54,7 +51,7 @@ type SessionRuntime = {
|
|
|
54
51
|
|
|
55
52
|
export interface CodemodeExtensionAPI {
|
|
56
53
|
registerTool(tool: ReturnType<typeof createEvalTool>): void;
|
|
57
|
-
on(event:
|
|
54
|
+
on(event: SessionLifecycleEvent, handler: (event: unknown, ctx: ExtensionContext) => Promise<void> | void): void;
|
|
58
55
|
executeTool: AgentExecuteTool;
|
|
59
56
|
getActiveTools(): string[];
|
|
60
57
|
}
|
|
@@ -78,32 +75,6 @@ export default function senpiCodemode(pi: CodemodeExtensionAPI, options: SenpiCo
|
|
|
78
75
|
const manager = new SessionManagerProxy();
|
|
79
76
|
const complete = options.complete ?? ((request, ctx) => createCompletionHandler()(ctx)(request));
|
|
80
77
|
const renderers = { renderCall: renderEvalCall, renderResult: renderEvalResult };
|
|
81
|
-
let activeRuntime: SessionRuntime | undefined;
|
|
82
|
-
let activeModelId: string | undefined;
|
|
83
|
-
const registerEvalForRuntime = (runtime: SessionRuntime, modelId: string | undefined): void => {
|
|
84
|
-
pi.registerTool(
|
|
85
|
-
createEvalTool({
|
|
86
|
-
enabledLanguages: runtime.enabledLanguages,
|
|
87
|
-
kernelManager: manager,
|
|
88
|
-
cellTimeoutSeconds: runtime.settings.cellTimeoutSeconds,
|
|
89
|
-
executeTool: runtime.executeTool,
|
|
90
|
-
complete,
|
|
91
|
-
settings: runtime.settings,
|
|
92
|
-
artifactsDir: runtime.artifactsDir,
|
|
93
|
-
executionTracker: manager,
|
|
94
|
-
renderers,
|
|
95
|
-
spawns: runtime.spawns,
|
|
96
|
-
spawnDefaultAgent: runtime.settings.taskTools.task,
|
|
97
|
-
hostLine: hostLine(),
|
|
98
|
-
...(modelId === undefined ? {} : { modelId }),
|
|
99
|
-
}),
|
|
100
|
-
);
|
|
101
|
-
};
|
|
102
|
-
const dropRuntime = async (): Promise<void> => {
|
|
103
|
-
activeRuntime = undefined;
|
|
104
|
-
activeModelId = undefined;
|
|
105
|
-
await manager.dispose();
|
|
106
|
-
};
|
|
107
78
|
pi.registerTool(
|
|
108
79
|
createEvalTool({
|
|
109
80
|
enabledLanguages: { py: true, js: true, rb: true, jl: true },
|
|
@@ -114,7 +85,6 @@ export default function senpiCodemode(pi: CodemodeExtensionAPI, options: SenpiCo
|
|
|
114
85
|
settings: defaultCodemodeSettings,
|
|
115
86
|
executionTracker: manager,
|
|
116
87
|
renderers,
|
|
117
|
-
hostLine: hostLine(),
|
|
118
88
|
}),
|
|
119
89
|
);
|
|
120
90
|
|
|
@@ -122,35 +92,25 @@ export default function senpiCodemode(pi: CodemodeExtensionAPI, options: SenpiCo
|
|
|
122
92
|
const generation = manager.beginReplacement();
|
|
123
93
|
const runtime = await createRuntime(pi, ctx, event, complete, options);
|
|
124
94
|
if (!(await manager.replace(generation, runtime.manager))) return;
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
95
|
+
pi.registerTool(
|
|
96
|
+
createEvalTool({
|
|
97
|
+
enabledLanguages: runtime.enabledLanguages,
|
|
98
|
+
kernelManager: manager,
|
|
99
|
+
cellTimeoutSeconds: runtime.settings.cellTimeoutSeconds,
|
|
100
|
+
executeTool: runtime.executeTool,
|
|
101
|
+
complete,
|
|
102
|
+
settings: runtime.settings,
|
|
103
|
+
artifactsDir: runtime.artifactsDir,
|
|
104
|
+
executionTracker: manager,
|
|
105
|
+
renderers,
|
|
106
|
+
spawns: runtime.spawns,
|
|
107
|
+
spawnDefaultAgent: runtime.settings.taskTools.task,
|
|
108
|
+
}),
|
|
109
|
+
);
|
|
139
110
|
});
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
const cpu = os.cpus()[0]?.model?.trim();
|
|
144
|
-
return [`${os.platform()} ${os.arch()}`, cpu, `${os.availableParallelism()} cores`]
|
|
145
|
-
.filter((part): part is string => !!part)
|
|
146
|
-
.join(" \u00b7 ");
|
|
147
|
-
}
|
|
148
|
-
|
|
149
|
-
function modelIdFrom(event: unknown): string | undefined {
|
|
150
|
-
if (typeof event !== "object" || event === null || !("model" in event)) return undefined;
|
|
151
|
-
const model = event.model;
|
|
152
|
-
if (typeof model !== "object" || model === null || !("id" in model)) return undefined;
|
|
153
|
-
return typeof model.id === "string" ? model.id : undefined;
|
|
111
|
+
pi.on("session_shutdown", async () => manager.dispose());
|
|
112
|
+
pi.on("session_before_switch", async () => manager.dispose());
|
|
113
|
+
pi.on("session_before_fork", async () => manager.dispose());
|
|
154
114
|
}
|
|
155
115
|
|
|
156
116
|
class SessionManagerProxy implements CodemodeSessionManager, EvalExecutionTracker {
|