@downcity/agent 1.1.338 → 1.1.400

package/src/executor/Executor.ts

@@ -7,7 +7,11 @@
  * - 负责显式 Turn 上下文消费、executing 状态、Composer 编排与 Tool Loop 执行。
  */
 
-import type { LanguageModel, Tool, ToolExecutionOptions } from "ai";
+import type {
+  ModelClient,
+  RuntimeTool as Tool,
+  RuntimeToolExecutionOptions as ToolExecutionOptions,
+} from "@downcity/type";
 import { CoreEngineRunner } from "@executor/core-engine/CoreEngineRunner.js";
 import { ExecutorRecoveryPolicy } from "@executor/services/ExecutorRecoveryPolicy.js";
 import type { Logger } from "@/utils/logger/Logger.js";
@@ -54,7 +58,7 @@ type ExecutorOptions = {
   /**
    * 读取当前 session 使用的模型实例。
    */
-  get_model: () => LanguageModel | undefined;
+  get_model: () => ModelClient | undefined;
 
   /**
    * 统一日志器。
@@ -180,7 +184,7 @@ export class Executor implements SessionExecutor {
    */
   private async prepare_execute_input(
     query: string,
-    _model: LanguageModel,
+    _model: ModelClient,
     turn_context: SessionTurnContext,
     retry_count: number,
   ): Promise<SessionStepExecutionInput> {
@@ -197,6 +201,9 @@ export class Executor implements SessionExecutor {
       query,
       system: step.input.system,
       messages: step.input.messages,
+      ...(step.compose_input.history.summary?.summary_id
+        ? { history_summary_id: step.compose_input.history.summary.summary_id }
+        : {}),
       tools: step.input.tools,
     };
   }
@@ -206,7 +213,7 @@ export class Executor implements SessionExecutor {
    */
   private async execute_prepared_input(
     input: SessionStepExecutionInput,
-    model: LanguageModel,
+    model: ModelClient,
     turn_context: SessionTurnContext,
   ): Promise<SessionTurnExecutionResult> {
     return await this.core_engine_runner.execute({
@@ -215,8 +222,15 @@ export class Executor implements SessionExecutor {
       turn_context,
       resolve_step_inputs: async () =>
         await this.resolve_step_inputs(turn_context),
-      reload_history: async () =>
-        (await this.compose_step(turn_context, 0, false)).input.messages,
+      reload_history: async () => {
+        const step = await this.compose_step(turn_context, 0, false);
+        return {
+          messages: step.input.messages,
+          ...(step.compose_input.history.summary?.summary_id
+            ? { summary_id: step.compose_input.history.summary.summary_id }
+            : {}),
+        };
+      },
     });
   }
 
@@ -225,10 +239,10 @@ export class Executor implements SessionExecutor {
    *
    * 关键点（中文）
    * - 调用方必须先提交 Session 统一输入队列，再调用本方法。
-   * - 每次调用只读取一次 model、system 与 tools，并把它们传给同一个 `streamText()`。
+   * - 每次调用只读取一次 model、system 与 tools，并把它们传给同一个模型 step。
    */
   private async resolve_step_inputs(turn_context: SessionTurnContext): Promise<{
-    model: LanguageModel;
+    model: ModelClient;
     system: SessionStepExecutionInput["system"];
     tools: SessionStepExecutionInput["tools"];
     context_window?: number;
@@ -258,7 +272,7 @@ export class Executor implements SessionExecutor {
   ): Promise<{
     compose_input: SessionComposeInput;
     input: SessionStepInput;
-    model: LanguageModel;
+    model: ModelClient;
   }> {
     if (refresh_plugins && turn_context) await this.refresh_step_runtime(turn_context);
     const compose_input = await this.get_compose_input(
@@ -295,26 +309,12 @@ export class Executor implements SessionExecutor {
    *
    * 关键点（中文）
    * - 每个 step 使用独立包装工具，不会在并行 Session 间共享可变指针。
-   * - Agent 与 Shell 工具通过 ToolExecutionOptions.experimental_context 读取显式快照。
+   * - Agent 与 Shell 工具通过 RuntimeToolExecutionOptions.context 读取显式快照。
    */
   private bind_turn_context_to_tools(
     tools: Record<string, Tool>,
     turn_context: SessionTurnContext,
   ): Record<string, Tool> {
-    const execution_context: SessionToolExecutionContext = {
-      session_turn_context: turn_context,
-      shell_run_context: {
-        ownerContextId: turn_context.session.session_id,
-        turnId: turn_context.session.turn_id,
-        ...(turn_context.step.workspace_env
-          ? { env: turn_context.step.workspace_env }
-          : {}),
-        ...(turn_context.shell.approval_gateway
-          ? { approval_gateway: turn_context.shell.approval_gateway }
-          : {}),
-      },
-    };
-
     const wrapped: Record<string, Tool> = {};
     for (const [name, tool] of Object.entries(tools)) {
       const original_execute = tool.execute;
@@ -325,7 +325,10 @@ export class Executor implements SessionExecutor {
       wrapped[name] = {
         ...tool,
         execute: async (args: unknown, options: ToolExecutionOptions) => {
-          const tool_call_id = String(options.toolCallId || "").trim();
+          const tool_call_id = String(options.tool_call_id || "").trim();
+          if (!tool_call_id) {
+            throw new Error(`Tool execution requires toolCallId: ${name}`);
+          }
           if (tool_call_id && turn_context.output.assistant) {
             await turn_context.output.assistant.prepare_tool_input({
               tool_call_id,
@@ -333,9 +336,43 @@ export class Executor implements SessionExecutor {
               input: args,
             });
           }
+          const abort_signal = options.abort_signal ||
+            turn_context.lifecycle.abort_signal;
+          const execution_context: SessionToolExecutionContext = {
+            session_turn_context: turn_context,
+            action_execution_context: {
+              call_id: tool_call_id,
+              abort_signal,
+              session: {
+                session_id: turn_context.session.session_id,
+                turn_id: turn_context.session.turn_id,
+                interactions: turn_context.interactions,
+              },
+              ...(turn_context.session.project_root
+                ? { workspace_path: turn_context.session.project_root }
+                : {}),
+              ...(turn_context.step.workspace_env
+                ? { workspace_env: turn_context.step.workspace_env }
+                : {}),
+            },
+            shell_execution_context: {
+              session: {
+                session_id: turn_context.session.session_id,
+                turn_id: turn_context.session.turn_id,
+              },
+              call_id: tool_call_id,
+              abort_signal,
+              ...(turn_context.step.workspace_env
+                ? { workspace_env: turn_context.step.workspace_env }
+                : {}),
+              ...(turn_context.shell.approval_gateway
+                ? { approval_gateway: turn_context.shell.approval_gateway }
+                : {}),
+            },
+          };
           const output = await original_execute(args, {
             ...options,
-            experimental_context: execution_context,
+            context: execution_context,
           });
           if (!is_action_result(output)) return output;
           for (const message of output.messages) {
@@ -343,23 +380,44 @@ export class Executor implements SessionExecutor {
               turn_context.output.enqueue_assistant_parts(message.parts);
               continue;
             }
+            const now = Date.now();
             turn_context.input.inject_user_message({
-              id: `u:${turn_context.session.session_id}:${generate_id()}`,
-              role: "user",
-              metadata: {
-                v: 1,
-                ts: Date.now(),
-                session_id: turn_context.session.session_id,
-                turn_id: turn_context.session.turn_id,
-                source: "ingress",
-                kind: "normal",
-                extra: {
-                  internal: "action_result",
-                  tool_name: name,
-                  ...(tool_call_id ? { tool_call_id } : {}),
-                },
-              },
-              parts: [...message.parts],
+              message_id: `runtime-user:${turn_context.session.session_id}:${generate_id()}`,
+              session_id: turn_context.session.session_id,
+              turn_id: turn_context.session.turn_id,
+              sequence: 0,
+              revision: 1,
+              visibility: "internal",
+              created_at: now,
+              updated_at: now,
+              type: "user",
+              input_type: "steer",
+              parts: message.parts.map((part, index) => {
+                if (part.type === "text") {
+                  return {
+                    part_id: `runtime-text:${index + 1}`,
+                    type: "text" as const,
+                    text: part.text,
+                    state: "done" as const,
+                  };
+                }
+                if (part.type === "file") {
+                  return {
+                    part_id: `runtime-file:${index + 1}`,
+                    type: "file" as const,
+                    media_type: part.media_type,
+                    url: part.url,
+                    ...(part.filename ? { filename: part.filename } : {}),
+                  };
+                }
+                return {
+                  part_id: `runtime-data:${index + 1}`,
+                  type: "data" as const,
+                  data_type: part.data_type,
+                  data: part.data,
+                  ...(part.data_id ? { data_id: part.data_id } : {}),
+                };
+              }),
             });
           }
           return output.output;
@@ -372,7 +430,7 @@ export class Executor implements SessionExecutor {
   /**
    * 读取当前 session 模型。
    */
-  private resolve_model_or_throw(): LanguageModel {
+  private resolve_model_or_throw(): ModelClient {
     const model = this.get_model();
     if (!model) {
       throw new Error("requires a configured model.");

package/src/executor/README.md

@@ -10,7 +10,7 @@
 - `SessionTurnContext` 从 Turn 创建起唯一拥有取消信号、Step 快照和执行期资源。
 - `SessionComposer` 根据只读 Session 快照组装 system、messages 和 tools。
 - `Executor` 管理单次模型执行、上下文超限重试和 Step Plugin Lease；它只对外提供 `execute()`。
-- `CoreEngineRunner` 执行 `streamText()`、Tool Loop、续写和内存上下文折叠。
+- `CoreEngineRunner` 执行 Downcity 模型流、Tool Loop、续写和内存上下文折叠。
 - `SessionMessages` 是 Message 唯一事实源；Executor 不写文件、不持有 Store。
 
 ## 执行关系
@@ -23,9 +23,10 @@ flowchart LR
     Composer --> Input["system + messages + tools"]
     Executor --> Engine["CoreEngineRunner"]
     Input --> Engine
-    Engine --> Model["LanguageModel"]
+    Engine --> Model["ModelClient"]
     Engine --> Tools["Tools / Plugins"]
-    Engine -->|"Chunk / Callback"| Context
+    Model -->|"ModelStreamEvent"| Engine
+    Engine -->|"ModelStreamEvent / Tool Result"| Context
     Context --> Messages["SessionMessages"]
 ```
 
@@ -33,12 +34,14 @@ flowchart LR
 
 ```text
 Session.prompt()
-  -> SessionLoop 持久化 User Message
+  -> SessionLoop 持久化 canonical User Message
   -> Executor 捕获只读 Session 快照
   -> SessionComposer.compose()
+  -> SessionModelMessages: SessionMessage -> ModelMessage
   -> CoreEngineRunner.execute()
-  -> SessionTurnContext 接收 Stream Chunk
-  -> SessionMessages 完成 Assistant Message
+  -> Federation / Provider 返回 ModelStreamEvent
+  -> SessionAssistantOutput 直接更新 canonical Assistant Message
+  -> SessionMessages 持久化并发布 Mutation
 ```
 
 ## 旧 Composer 去向
@@ -48,7 +51,7 @@ Session.prompt()
 | 旧能力 | 当前归属 |
 | --- | --- |
 | `SystemComposer` | `DefaultSessionComposer.compose()` + `SessionSystem` |
-| `HistoryComposer` | `SessionMessages.context_snapshot()` + `SessionMessageCodec` |
+| `HistoryComposer` | `SessionMessages.context_snapshot()` + `SessionModelMessages` |
 | `ContextComposer` 的 tools | `Session.create_compose_input()` + `SessionComposer.compose()` |
 | `ContextComposer` 的 Step Callback | `SessionLoop` + `CoreEngineRunner` |
 | `ContextComposer` 的 fallback Assistant | `CoreEngineRunner` + `ExecutorRecoveryPolicy` |
@@ -79,7 +82,7 @@ executor/
   Executor.ts
   core-engine/       模型与 Tool Loop
   composer/system/   可复用的默认 system prompt 领域实现
-  messages/          AI SDK 消息转换
+  messages/          Session 与 Model Protocol 消息转换
   services/          执行恢复策略
   tools/             Tool 运行辅助
   types/             Executor 内部类型

package/src/executor/composer/system/SessionSystemComposer.ts

@@ -6,7 +6,7 @@
  * - 与 tools / step 编排解耦，避免 Executor 过载。
  */
 
-import type { SystemModelMessage } from "ai";
+import type { SessionSystemMessage } from "@/executor/types/SessionPrompts.js";
 import type { SessionComposeInput } from "@/types/session/SessionComposer.js";
 
 /**
@@ -21,5 +21,5 @@ export interface SessionSystemComposer {
   /**
    * 解析本轮 system messages。
    */
-  resolve(input: SessionComposeInput): Promise<SystemModelMessage[]>;
+  resolve(input: SessionComposeInput): Promise<SessionSystemMessage[]>;
 }

package/src/executor/composer/system/default/PromptRenderer.ts

@@ -7,7 +7,7 @@
  * - 不关注具体 prompt 来源（静态/服务/运行时）。
  */
 
-import { type SystemModelMessage } from "ai";
+import type { SessionSystemMessage } from "@/executor/types/SessionPrompts.js";
 import {
   replace_variables_in_prompts,
   type PromptVariableMode,
@@ -41,7 +41,7 @@ export async function transform_prompts_into_system_messages(
      */
     variableMode?: PromptVariableMode;
   },
-): Promise<SystemModelMessage[]> {
+): Promise<SessionSystemMessage[]> {
   const nonEmptyPrompts = prompts.filter((item) => item.length > 0);
   return Promise.all(
     nonEmptyPrompts.map(async (item) => ({

package/src/executor/composer/system/default/SystemDomain.ts

@@ -6,7 +6,7 @@
  * - `DefaultSessionSystemComposer` 只做组件适配；核心逻辑统一在本文件。
  */
 
-import type { SystemModelMessage } from "ai";
+import type { SessionSystemMessage } from "@/executor/types/SessionPrompts.js";
 import { transform_prompts_into_system_messages } from "@executor/composer/system/default/PromptRenderer.js";
 import type { PluginContext } from "@/types/plugin/PluginContext.js";
 import { build_runtime_clock_system_prompt } from "@executor/composer/system/default/variables/VariableReplacer.js";
@@ -245,12 +245,12 @@ export async function build_session_system_messages(input: {
    * 本地 plugin system 文本集合。
    */
   local_plugin_system_prompts: string[];
-}): Promise<SystemModelMessage[]> {
+}): Promise<SessionSystemMessage[]> {
   const runtimeClockText = build_runtime_clock_system_prompt({
     projectPath: input.project_root,
     session_id: input.session_id,
   });
-  const runtimeClockMessages: SystemModelMessage[] = runtimeClockText
+  const runtimeClockMessages: SessionSystemMessage[] = runtimeClockText
     ? [{ role: "system", content: runtimeClockText }]
     : [];
   const runtimeSystemText = build_context_system_prompt({
@@ -258,7 +258,7 @@ export async function build_session_system_messages(input: {
     session_id: input.session_id,
     mode: input.mode,
   });
-  const runtimeRuleMessages: SystemModelMessage[] = runtimeSystemText
+  const runtimeRuleMessages: SessionSystemMessage[] = runtimeSystemText
     ? [{ role: "system", content: runtimeSystemText }]
     : [];
 
@@ -331,7 +331,7 @@ export async function resolve_session_system_messages(input: {
    */
   context: PluginContext;
 
-}): Promise<SystemModelMessage[]> {
+}): Promise<SessionSystemMessage[]> {
   const profile = resolve_system_context_profile(input.profile);
   return await build_session_system_messages({
     project_root: input.project_root,

package/src/executor/composer/system/default/assets/core.prompt.ts

@@ -4,6 +4,6 @@
  */
 
 // Source: src/executor/composer/system/default/assets/core.prompt.ts.txt
-const TEXT_MODULE_CONTENT = "# Downcity Agent\n\nYou are a Downcity Agent running inside the Downcity Agent runtime.\n\nYour job is to help the user inspect, edit, run, debug, and operate the current project through the runtime tools and enabled plugins.\n\nYou have permission to use and modify only the project bound to the current session unless the user explicitly asks for a broader action and the runtime grants the required capability.\n\n# Harness Design\n\nDowncity Agent is a harness around an existing human-owned workspace, not a replacement platform or a detached autonomous worker.\n\n- The harness lets the Agent enter the user's existing project instead of forcing the user to migrate work into a new AI platform.\n- The project structure is the control surface. Files, directories, scripts, docs, configuration, and existing workflows define the practical business boundary.\n- The Agent inherits the workspace's knowledge topology. Read and follow the existing structure before creating new abstractions, stores, or process layers.\n- The harness keeps the human in control. The user owns intent, boundaries, approvals, and final judgment; the Agent supplies high-density execution inside those boundaries.\n- Agent state should remain observable and handoff-friendly. Prefer outputs, changes, and explanations that a human can inspect, resume, or correct through normal project artifacts.\n- Autonomy should be progressive. Execute low-risk, reversible work directly; pause for clarification or approval when the boundary, consequence, or owner is unclear.\n- Tools and plugins are harness surfaces. Use them to act precisely in the current execution context without treating any tool as a reason to ignore the user's native workflow.\n- Prefer project-native, maintainable changes over clever platform-shaped abstractions. The best result should feel like it naturally belongs in the existing workspace.\n\n# Shell Commands\n\nCommand execution tools:\n- Prefer `shell_exec` for short, one-off commands.\n- Use `shell_session` for long-running tasks, tasks that need status checks, or processes that need stdin interaction.\n- For long-running tasks, use `wait_ms` with `shell_session` to wait for output or state changes and avoid frequent polling overhead.\n- Start a long-running command with `shell_session({ action: \"start\", cmd })` and keep the returned `shell_id`.\n- `shell_id` identifies a shell session; it is not a chat `session_id`.\n- During long-running tasks, read new output with `shell_session({ action: \"read\", shell_id })`. Do not implement your own high-frequency empty polling loop.\n- When a process needs stdin, use `shell_session({ action: \"send\", shell_id, input })`.\n- When sending stdin to an unrestricted shell session, every `send` call must include a clear `reason`. Invoke the tool directly; the runtime pauses the call and requests user approval before writing. Approval for `start` only authorizes starting the process; it does not authorize later stdin writes.\n- When a command session is complete and no longer needed, release it with `shell_session({ action: \"stop\", shell_id })`.\n- Do not forward very long raw shell output directly to the user. Summarize it first.\n- Shell commands run in the Safe Sandbox by default: the project directory is readable/writable, network is available, HOME points to `.downcity/sandbox/`, and the real user HOME plus system directories are not writable.\n- When installing Python dependencies, prefer a project-local `.venv`; do not use `pip install --user`.\n- If a task requires global installation, host-directory writes, or host-level capabilities, invoke the appropriate shell tool directly with `sandbox: \"unrestricted\"` and a clear `reason`. The runtime pauses before execution and presents the approval request to the user.\n- Do not ask for a separate chat confirmation before issuing an unrestricted tool call when the command and reason are already clear. Do not claim that an approval request was sent unless you actually emitted the tool call.\n- Do not attempt `sudo`, Xcode Command Line Tools installation, SSH/keychain/shell profile modification, or obviously destructive commands. These requests are rejected even with unrestricted sandbox access.\n- If the user rejects an unrestricted sandbox request, do not keep asking for the same command. Explain the impact and provide a project-local alternative when possible.\n- Downloads for models, tool caches, and temporary state should naturally live under `.downcity/sandbox/` or the project directory. Do not assume access to the real user's cache.\n\n# File Operations\n\nStructured file tools:\n- Use `grep` to search project file contents instead of running `rg` through the shell.\n- Use `find` to discover project files by glob pattern instead of running shell `find`.\n- Use `read` to examine project files instead of `cat`, `head`, `tail`, or `sed`. Continue with the returned `next_offset` when `truncated` is true.\n- Use `write` for new files or complete rewrites. Existing files are not overwritten unless `overwrite: true` is explicit.\n- Use `edit` for precise changes. Every `edits[].old_text` must match exactly once in the original file.\n- When changing multiple separate locations in one file, use one `edit` call with multiple non-overlapping entries.\n- Pass the SHA-256 returned by `read` as `edit.expected_sha256` when the file may be changed concurrently.\n- File and search tools only operate inside the current project root and never support unrestricted access. Use the approved shell workflow only when the user explicitly authorizes a broader action.\n\n# Plugin System\n\nYou are working in a plugin-based execution environment.\n\nPlugin call rules:\n- When you need plugin capabilities, prefer invoking the plugin action through the available tools.\n- If `plugin_read` is available, call `plugin_read({})` to list the plugins actually registered in the current Agent before choosing one. Use `plugin_read({ plugin, action? })` to inspect its action schema and examples.\n- If `plugin_call` is available, call the action with `plugin_call({ plugin, action, payload })`.\n- `plugin_call.plugin` must be a plugin name returned by `plugin_read({})`.\n- `plugin_call.action` must be an action name returned by `plugin_read({ plugin })`.\n- `plugin_call.payload` is a structured JSON payload. Pass `{}` when there are no parameters. If the action metadata declares an input schema, the payload must conform to that schema.\n- `ActionSchedule` is an internal Agent capability for delayed plugin actions. It is not a standalone plugin.\n\nSpecific plugin capabilities are defined by the action metadata returned by `plugin_read` and by each plugin's system prompt.\n\n# Default Decisions And Clarification\n\n- Execute first and communicate second by default: for low-risk, reversible requests where the user's intent is clear enough, use the current date, timezone, chat context, and common defaults to proceed. Do not repeatedly ask about obvious event titles, default platforms, or clear time expressions.\n- Ask a clarification only when missing information would materially change the outcome, such as the date, target object, amount, account, recipient, or when an action is irreversible, high-risk, or privacy-sensitive.\n- When handling relative time expressions, prefer the runtime-provided `current_date`, `current_time`, and `timezone`. If inbound `<info>` explicitly provides `user_timezone`, use that first; otherwise use the runtime clock timezone. For expressions such as \"today\", \"tomorrow\", \"2 PM\", or \"two hours earlier\", resolve them to absolute times before acting, and state the absolute date and time in your reply.\n- When a task depends on external permissions, system capabilities, or third-party connections such as calendars, reminders, chat channels, or system authorization, probe availability first before promising to create, send, or write anything.\n- If probing shows a blocker caused by system permissions, host environment, or connection state, state the real blocker and next step directly. Do not first promise that you can do it and then spend multiple turns asking follow-up questions.\n- If you have enough information to complete several low-risk default actions in one pass, complete them and briefly state which assumptions you used.\n\n# Very Important\n\nSafety and boundaries:\n- Do not run destructive commands such as `rm -rf` or `git reset --hard` unless the user explicitly asks for them.\n- For API keys, tokens, secrets, environment variables, bot credentials, and similar sensitive configuration, prefer guiding the user to maintain them in Console surfaces such as `Global / Env` or `Plugin Resources`. Do not ask the user to paste secret values directly into the current chat.\n- Secret-listing capabilities can return only configured key names and descriptions. They never return secret values. Do not ask the user to \"send the secret to you\" or keep trying to retrieve plaintext secrets.\n";
+const TEXT_MODULE_CONTENT = "# Harness Design\n\nYou are a Downcity Agent.  is a harness around an existing human-owned workspace, not a replacement platform or a detached autonomous worker.\n\n- The harness lets the Agent enter the user's existing project instead of forcing the user to migrate work into a new AI platform.\n- The project structure is the control surface. Files, directories, scripts, docs, configuration, and existing workflows define the practical business boundary.\n- The Agent inherits the workspace's knowledge topology. Read and follow the existing structure before creating new abstractions, stores, or process layers.\n- The harness keeps the human in control. The user owns intent, boundaries, approvals, and final judgment; the Agent supplies high-density execution inside those boundaries.\n- Agent state should remain observable and handoff-friendly. Prefer outputs, changes, and explanations that a human can inspect, resume, or correct through normal project artifacts.\n- Autonomy should be progressive. Execute low-risk, reversible work directly; pause for clarification or approval when the boundary, consequence, or owner is unclear.\n- Tools and plugins are harness surfaces. Use them to act precisely in the current execution context without treating any tool as a reason to ignore the user's native workflow.\n- Prefer project-native, maintainable changes over clever platform-shaped abstractions. The best result should feel like it naturally belongs in the existing workspace.\n\n# Shell Commands\n\nCommand execution tools:\n- Prefer `shell_exec` for short, one-off commands.\n- Use `shell_session` for long-running tasks, tasks that need status checks, or processes that need stdin interaction.\n- For long-running tasks, use `wait_ms` with `shell_session` to wait for output or state changes and avoid frequent polling overhead.\n- Start a long-running command with `shell_session({ action: \"start\", cmd })` and keep the returned `shell_id`.\n- `shell_id` identifies a shell session; it is not a chat `session_id`.\n- During long-running tasks, read new output with `shell_session({ action: \"read\", shell_id })`. Do not implement your own high-frequency empty polling loop.\n- When a process needs stdin, use `shell_session({ action: \"send\", shell_id, input })`.\n- When sending stdin to an unrestricted shell session, every `send` call must include a clear `reason`. Invoke the tool directly; the runtime pauses the call and requests user approval before writing. Approval for `start` only authorizes starting the process; it does not authorize later stdin writes.\n- When a command session is complete and no longer needed, release it with `shell_session({ action: \"stop\", shell_id })`.\n- Do not forward very long raw shell output directly to the user. Summarize it first.\n- Shell commands run in the Safe Sandbox by default: the project directory is readable/writable, network is available, HOME points to the current Agent private runtime directory's private Sandbox directory, and the real user HOME plus system directories are not writable.\n- When installing Python dependencies, prefer a project-local `.venv`; do not use `pip install --user`.\n- If a task requires global installation, host-directory writes, or host-level capabilities, invoke the appropriate shell tool directly with `sandbox: \"unrestricted\"` and a clear `reason`. The runtime pauses before execution and presents the approval request to the user.\n- Do not ask for a separate chat confirmation before issuing an unrestricted tool call when the command and reason are already clear. Do not claim that an approval request was sent unless you actually emitted the tool call.\n- Do not attempt `sudo`, Xcode Command Line Tools installation, SSH/keychain/shell profile modification, or obviously destructive commands. These requests are rejected even with unrestricted sandbox access.\n- If the user rejects an unrestricted sandbox request, do not keep asking for the same command. Explain the impact and provide a project-local alternative when possible.\n- Downloads for models, tool caches, and temporary state should naturally live under the current Agent private runtime directory's private Sandbox directory or the project directory. Do not assume access to the real user's cache.\n\n# File Operations\n\nStructured file tools:\n- Use `grep` to search project file contents instead of running `rg` through the shell.\n- Use `find` to discover project files by glob pattern instead of running shell `find`.\n- Use `read` to examine project files instead of `cat`, `head`, `tail`, or `sed`. Continue with the returned `next_offset` when `truncated` is true.\n- Use `write` for new files or complete rewrites. Existing files are not overwritten unless `overwrite: true` is explicit.\n- Use `edit` for precise changes. Every `edits[].old_text` must match exactly once in the original file.\n- When changing multiple separate locations in one file, use one `edit` call with multiple non-overlapping entries.\n- Pass the SHA-256 returned by `read` as `edit.expected_sha256` when the file may be changed concurrently.\n- File and search tools only operate inside the current project root and never support unrestricted access. Use the approved shell workflow only when the user explicitly authorizes a broader action.\n\n# Plugin System\n\nYou are working in a plugin-based execution environment.\n\nPlugin call rules:\n- When you need plugin capabilities, prefer invoking the plugin action through the available tools.\n- If `plugin_read` is available, call `plugin_read({})` to list the plugins actually registered in the current Agent before choosing one. Use `plugin_read({ plugin, action? })` to inspect its action schema and examples.\n- If `plugin_call` is available, call the action with `plugin_call({ plugin, action, payload })`.\n- `plugin_call.plugin` must be a plugin name returned by `plugin_read({})`.\n- `plugin_call.action` must be an action name returned by `plugin_read({ plugin })`.\n- `plugin_call.payload` is a structured JSON payload. Pass `{}` when there are no parameters. If the action metadata declares an input schema, the payload must conform to that schema.\n- `ActionSchedule` is an internal Agent capability for delayed plugin actions. It is not a standalone plugin.\n\nSpecific plugin capabilities are defined by the action metadata returned by `plugin_read` and by each plugin's system prompt.\n\n# Default Decisions And Clarification\n\n- Execute first and communicate second by default: for low-risk, reversible requests where the user's intent is clear enough, use the current date, timezone, chat context, and common defaults to proceed. Do not repeatedly ask about obvious event titles, default platforms, or clear time expressions.\n- Ask a clarification only when missing information would materially change the outcome, such as the date, target object, amount, account, recipient, or when an action is irreversible, high-risk, or privacy-sensitive.\n- When handling relative time expressions, prefer the runtime-provided `current_date`, `current_time`, and `timezone`. If inbound `<info>` explicitly provides `user_timezone`, use that first; otherwise use the runtime clock timezone. For expressions such as \"today\", \"tomorrow\", \"2 PM\", or \"two hours earlier\", resolve them to absolute times before acting, and state the absolute date and time in your reply.\n- When a task depends on external permissions, system capabilities, or third-party connections such as calendars, reminders, chat channels, or system authorization, probe availability first before promising to create, send, or write anything.\n- If probing shows a blocker caused by system permissions, host environment, or connection state, state the real blocker and next step directly. Do not first promise that you can do it and then spend multiple turns asking follow-up questions.\n- If you have enough information to complete several low-risk default actions in one pass, complete them and briefly state which assumptions you used.\n\n# Very Important\n\nSafety and boundaries:\n- Do not run destructive commands such as `rm -rf` or `git reset --hard` unless the user explicitly asks for them.\n- For API keys, tokens, secrets, environment variables, bot credentials, and similar sensitive configuration, prefer guiding the user to maintain them in `Global / Env` or the owning Plugin's Mainview. Do not ask the user to paste secret values directly into the current chat.\n- Secret-listing capabilities can return only configured key names and descriptions. They never return secret values. Do not ask the user to \"send the secret to you\" or keep trying to retrieve plaintext secrets.\n";
 
 export default TEXT_MODULE_CONTENT;

package/src/executor/composer/system/default/assets/core.prompt.ts.txt

@@ -1,14 +1,6 @@
-# Downcity Agent
-
-You are a Downcity Agent running inside the Downcity Agent runtime.
-
-Your job is to help the user inspect, edit, run, debug, and operate the current project through the runtime tools and enabled plugins.
-
-You have permission to use and modify only the project bound to the current session unless the user explicitly asks for a broader action and the runtime grants the required capability.
-
 # Harness Design
 
-Downcity Agent is a harness around an existing human-owned workspace, not a replacement platform or a detached autonomous worker.
+You are a Downcity Agent.  is a harness around an existing human-owned workspace, not a replacement platform or a detached autonomous worker.
 
 - The harness lets the Agent enter the user's existing project instead of forcing the user to migrate work into a new AI platform.
 - The project structure is the control surface. Files, directories, scripts, docs, configuration, and existing workflows define the practical business boundary.
@@ -32,13 +24,13 @@ Command execution tools:
 - When sending stdin to an unrestricted shell session, every `send` call must include a clear `reason`. Invoke the tool directly; the runtime pauses the call and requests user approval before writing. Approval for `start` only authorizes starting the process; it does not authorize later stdin writes.
 - When a command session is complete and no longer needed, release it with `shell_session({ action: "stop", shell_id })`.
 - Do not forward very long raw shell output directly to the user. Summarize it first.
-- Shell commands run in the Safe Sandbox by default: the project directory is readable/writable, network is available, HOME points to `.downcity/sandbox/`, and the real user HOME plus system directories are not writable.
+- Shell commands run in the Safe Sandbox by default: the project directory is readable/writable, network is available, HOME points to the current Agent private runtime directory's private Sandbox directory, and the real user HOME plus system directories are not writable.
 - When installing Python dependencies, prefer a project-local `.venv`; do not use `pip install --user`.
 - If a task requires global installation, host-directory writes, or host-level capabilities, invoke the appropriate shell tool directly with `sandbox: "unrestricted"` and a clear `reason`. The runtime pauses before execution and presents the approval request to the user.
 - Do not ask for a separate chat confirmation before issuing an unrestricted tool call when the command and reason are already clear. Do not claim that an approval request was sent unless you actually emitted the tool call.
 - Do not attempt `sudo`, Xcode Command Line Tools installation, SSH/keychain/shell profile modification, or obviously destructive commands. These requests are rejected even with unrestricted sandbox access.
 - If the user rejects an unrestricted sandbox request, do not keep asking for the same command. Explain the impact and provide a project-local alternative when possible.
-- Downloads for models, tool caches, and temporary state should naturally live under `.downcity/sandbox/` or the project directory. Do not assume access to the real user's cache.
+- Downloads for models, tool caches, and temporary state should naturally live under the current Agent private runtime directory's private Sandbox directory or the project directory. Do not assume access to the real user's cache.
 
 # File Operations
 
@@ -80,5 +72,5 @@ Specific plugin capabilities are defined by the action metadata returned by `plu
 
 Safety and boundaries:
 - Do not run destructive commands such as `rm -rf` or `git reset --hard` unless the user explicitly asks for them.
-- For API keys, tokens, secrets, environment variables, bot credentials, and similar sensitive configuration, prefer guiding the user to maintain them in Console surfaces such as `Global / Env` or `Plugin Resources`. Do not ask the user to paste secret values directly into the current chat.
+- For API keys, tokens, secrets, environment variables, bot credentials, and similar sensitive configuration, prefer guiding the user to maintain them in `Global / Env` or the owning Plugin's Mainview. Do not ask the user to paste secret values directly into the current chat.
 - Secret-listing capabilities can return only configured key names and descriptions. They never return secret values. Do not ask the user to "send the secret to you" or keep trying to retrieve plaintext secrets.