@downcity/plugins 1.0.254 → 1.0.280

package/src/sound/Plugin.ts

@@ -3,9 +3,9 @@
  *
  * 关键点（中文）
  * - 对 Agent 暴露 `models`、`asr`、`tts` 三个 action。
- * - 模型目录与真实 ASR/TTS 能力全部由 FED/City constructor 回调注入。
+ * - 模型目录与真实 ASR/TTS 能力从运行时 Context 的 City 环境读取。
  * - 本地音频只负责读取并转换为 data URL，不加载或运行任何本地语音模型。
- * - TTS 返回已经落盘的本地音频 UIMessage Parts，并由 Action 声明 Assistant Message。
+ * - TTS 返回已经落盘的本地音频 Session Parts，并由 Action 声明 Assistant Message。
  */
 
 import fs from "node:fs/promises";
@@ -20,6 +20,7 @@ import type {
 } from "@/chat/types/ChatPlugin.js";
 import type {
   SoundPluginAsrInput,
+  SoundAiService,
   SoundPluginAsrResult,
   SoundPluginAsrSegment,
   SoundPluginCapability,
@@ -36,6 +37,17 @@ const DEFAULT_SOUND_PLUGIN_DESCRIPTION =
   "Transcribe audio and synthesize speech through FED-provided models.";
 const DEFAULT_AUDIO_MEDIA_TYPE = "audio/mpeg";
 
+/** 从 City 注入的 Embassy 获取语音 AI 服务。 */
+function require_sound_ai(context: PluginContext): SoundAiService {
+  const service = context.embassy?.user.ai;
+  if (!service) throw new Error("SoundPlugin requires a City Embassy user AI service");
+  return {
+    catalog: async () => await service.catalog(),
+    asr: async (input) => await service.asr(input as never),
+    tts: async (input) => await service.tts(input as never),
+  };
+}
+
 const AUDIO_MEDIA_TYPES: Record<string, string> = {
   ".aac": "audio/aac",
   ".flac": "audio/flac",
@@ -356,21 +368,21 @@ function normalize_asr_result(result: SoundPluginAsrResult): SoundPluginAsrResul
 }
 
 /**
- * 校验 TTS 返回的 AI SDK UIMessage。
+ * 校验 TTS 返回的 Downcity Session 消息。
  */
 function normalize_tts_result(result: SoundPluginTtsResult): SoundPluginTtsResult {
   const record = to_record(result);
   if (!record || !Array.isArray(record.parts)) {
-    throw new TypeError("SoundPlugin tts function must return an AI SDK UIMessage");
+    throw new TypeError("SoundPlugin tts function must return a Downcity Session message");
   }
   const has_audio_file = record.parts.some((part) => {
     const part_record = to_record(part);
     return part_record?.type === "file"
-      && typeof part_record.mediaType === "string"
-      && part_record.mediaType.startsWith("audio/");
+      && typeof part_record.media_type === "string"
+      && part_record.media_type.startsWith("audio/");
   });
   if (!has_audio_file) {
-    throw new TypeError("SoundPlugin tts UIMessage must contain an audio file part");
+    throw new TypeError("SoundPlugin tts Session message must contain an audio file part");
   }
   for (const part of record.parts) {
     const part_record = to_record(part);
@@ -433,25 +445,15 @@ export class SoundPlugin extends BasePlugin {
   /** Plugin 用途说明。 */
   readonly description: string;
 
-  private readonly asr_handler: SoundPluginOptions["asr"];
-  private readonly tts_handler: SoundPluginOptions["tts"];
-  private readonly list_models?: SoundPluginOptions["list_models"];
   private readonly default_asr_model?: string;
   private readonly default_tts_model?: string;
   private readonly auto_asr: boolean;
   private readonly language?: string;
   private readonly voice?: string;
   private readonly format?: string;
-
   constructor(options: SoundPluginOptions) {
     super();
     const name = normalize_optional_string(options.name) ?? DEFAULT_SOUND_PLUGIN_NAME;
-    if (typeof options.asr !== "function") {
-      throw new TypeError("SoundPlugin requires an asr function");
-    }
-    if (typeof options.tts !== "function") {
-      throw new TypeError("SoundPlugin requires a tts function");
-    }
     const default_asr_model = normalize_optional_string(options.default_asr_model);
     if (options.auto_asr === true && !default_asr_model) {
       throw new TypeError("SoundPlugin auto_asr requires default_asr_model");
@@ -460,9 +462,6 @@ export class SoundPlugin extends BasePlugin {
     this.title = normalize_optional_string(options.title) ?? DEFAULT_SOUND_PLUGIN_TITLE;
     this.description = normalize_optional_string(options.description)
       ?? DEFAULT_SOUND_PLUGIN_DESCRIPTION;
-    this.asr_handler = options.asr;
-    this.tts_handler = options.tts;
-    this.list_models = options.list_models;
     this.default_asr_model = default_asr_model;
     this.default_tts_model = normalize_optional_string(options.default_tts_model);
     this.auto_asr = options.auto_asr === true;
@@ -498,7 +497,7 @@ export class SoundPlugin extends BasePlugin {
       "## Results",
       "",
       "ASR returns transcript text and may include timed segments, language, and duration.",
-      "TTS returns an AI SDK UIMessage whose audio file part already points to a local file, and that part is attached to the assistant response.",
+      "TTS returns a Downcity Session message whose audio file part already points to a local file, and that part is attached to the assistant response.",
       "Do not invent a transcript or audio result when a FED call fails.",
       "",
       `When unsure, use \`plugin_read { plugin: \"${this.name}\", action: \"...\" }\` to inspect the complete schema.`,
@@ -518,22 +517,24 @@ export class SoundPlugin extends BasePlugin {
       ...input,
       model,
     });
-    return normalize_asr_result(await this.asr_handler(resolved_input));
+    return normalize_asr_result(
+      await require_sound_ai(context).asr(resolved_input as unknown as JsonObject) as unknown as SoundPluginAsrResult,
+    );
   }
 
   /**
    * 执行一次 TTS 合成。
    */
-  private async synthesize(input: SoundPluginTtsInput): Promise<SoundPluginTtsResult> {
+  private async synthesize(context: PluginContext, input: SoundPluginTtsInput): Promise<SoundPluginTtsResult> {
     const model = resolve_model_id("tts", input.model, this.default_tts_model);
-    const result = await this.tts_handler({
+    const result = await require_sound_ai(context).tts({
       ...(this.language ? { language: this.language } : {}),
       ...(this.voice ? { voice: this.voice } : {}),
       ...(this.format ? { format: this.format } : {}),
       ...input,
       model,
     });
-    return normalize_tts_result(result);
+    return normalize_tts_result(result as unknown as SoundPluginTtsResult);
   }
 
   /**
@@ -609,13 +610,13 @@ export class SoundPlugin extends BasePlugin {
         { title: "ASR models", payload: { capability: "asr" } },
         { title: "TTS models", payload: { capability: "tts" } },
       ],
-      execute: async ({ input }: { input: JsonValue }) => {
+      execute: async ({ context, input }: { context: PluginContext; input: JsonValue }) => {
         try {
-          if (!this.list_models) {
-            throw new TypeError("SoundPlugin list_models is not configured");
-          }
           const capability = normalize_models_capability(input);
-          const result = normalize_sound_models(await this.list_models(), capability);
+          const result = normalize_sound_models(
+            await require_sound_ai(context).catalog().then((catalog) => catalog.all()) as unknown as SoundPluginModel[],
+            capability,
+          );
           return {
             success: true,
             data: result as unknown as JsonObject,
@@ -666,7 +667,7 @@ export class SoundPlugin extends BasePlugin {
     }),
     tts: create_action({
       description:
-        "Synthesize speech with a FED TTS model and return an AI SDK UIMessage containing audio.",
+        "Synthesize speech with a FED TTS model and return a Downcity Session message containing audio.",
       input_schema: {
         zod: SOUND_TTS_INPUT_SCHEMA,
         json_schema: {
@@ -691,9 +692,9 @@ export class SoundPlugin extends BasePlugin {
           payload: { model: "tts-model-id", text: "Welcome back", voice: "alloy", format: "mp3" },
         },
       ],
-      execute: async ({ input }: { input: JsonValue }) => {
+      execute: async ({ context, input }: { context: PluginContext; input: JsonValue }) => {
         try {
-          const result = await this.synthesize(normalize_tts_payload(input));
+          const result = await this.synthesize(context, normalize_tts_payload(input));
           return {
             success: true,
             message: "speech synthesized",

package/src/sound/types/SoundPlugin.ts

@@ -3,12 +3,23 @@
  *
  * 关键点（中文）
  * - SoundPlugin 统一承载 ASR 与 TTS，不绑定本地模型、Python 或具体 provider。
- * - ASR 结果字段与 AI SDK `TranscriptionResult` 的可序列化核心字段保持一致。
- * - TTS 结果直接使用 AI SDK `UIMessage`，由 agent 统一处理音频 file part。
+ * - ASR 结果只保留跨进程可序列化的核心字段。
+ * - TTS 结果直接使用 Downcity Session 消息，由 Agent 统一处理音频 file part。
  */
 
-import type { UIMessage } from "ai";
-import type { JsonObject, JsonValue } from "@downcity/agent";
+import type { ActionResultMessage, JsonObject, JsonValue } from "@downcity/agent";
+
+/** SoundPlugin 使用的最小语音 AI 服务协议。 */
+export interface SoundAiService {
+  /** 读取当前可用模型目录。 */
+  catalog(): Promise<{ all(): readonly unknown[] }>;
+
+  /** 执行语音识别。 */
+  asr(input: JsonObject): Promise<unknown>;
+
+  /** 执行语音合成。 */
+  tts(input: JsonObject): Promise<unknown>;
+}
 
 /**
  * SoundPlugin 支持的语音能力。
@@ -44,7 +55,7 @@ export interface SoundPluginModelsResult {
 /**
  * ASR 转写分段。
  *
- * 字段命名与 AI SDK `TranscriptionResult.segments` 保持一致。
+ * 字段命名遵循 Downcity ASR 分段协议。
  */
 export interface SoundPluginAsrSegment {
   /** 当前时间片段识别得到的文本。 */
@@ -83,7 +94,7 @@ export interface SoundPluginAsrInput {
  * ASR 输出。
  *
  * 说明（中文）
- * - 只保留 AI SDK `TranscriptionResult` 中适合 JSON 传输的核心字段。
+ * - 只保留适合 JSON 传输的核心字段。
  * - warnings、responses 与 providerMetadata 属于运行期诊断信息，不进入 plugin action 协议。
  */
 export interface SoundPluginAsrResult {
@@ -124,14 +135,14 @@ export interface SoundPluginTtsInput {
 /**
  * TTS 输出。
  *
- * 音频通过 AI SDK `UIMessage` 的 file part 返回。
+ * 音频通过 Downcity Session 消息的 file part 返回。
  */
-export type SoundPluginTtsResult = UIMessage;
+export type SoundPluginTtsResult = ActionResultMessage;
 
 /**
  * SoundPlugin 构造参数。
  */
-export interface SoundPluginOptions {
+export interface SoundPluginProfile {
   /** Plugin 稳定名称，默认 `sound`。 */
   name?: string;
   /** Plugin 展示标题，默认 `Sound`。 */
@@ -150,14 +161,8 @@ export interface SoundPluginOptions {
   voice?: string;
   /** TTS 默认输出格式。 */
   format?: string;
-  /** 调用 FED ASR action 的函数，通常传入 `(input) => city.ai.asr(input)`。 */
-  asr: (
-    input: SoundPluginAsrInput,
-  ) => Promise<SoundPluginAsrResult> | SoundPluginAsrResult;
-  /** 调用 FED TTS action 的函数，通常传入 `(input) => city.ai.tts(input)`。 */
-  tts: (
-    input: SoundPluginTtsInput,
-  ) => Promise<SoundPluginTtsResult> | SoundPluginTtsResult;
-  /** 列出 FED 中支持 ASR 或 TTS 的模型。 */
-  list_models?: () => Promise<SoundPluginModel[]> | SoundPluginModel[];
+}
+
+/** SoundPlugin 构造参数。 */
+export interface SoundPluginOptions extends SoundPluginProfile {
 }

package/src/sound.ts

@@ -6,6 +6,7 @@
 
 export { SoundPlugin } from "./sound/Plugin.js";
 export type {
+  SoundAiService,
   SoundPluginAsrInput,
   SoundPluginAsrResult,
   SoundPluginAsrSegment,
@@ -13,6 +14,7 @@ export type {
   SoundPluginModel,
   SoundPluginModelsResult,
   SoundPluginOptions,
+  SoundPluginProfile,
   SoundPluginTtsInput,
   SoundPluginTtsResult,
 } from "./sound/types/SoundPlugin.js";

package/src/task/Action.ts

@@ -58,7 +58,7 @@ function buildDefaultTaskBody(): string {
     "# 任务目标",
     "",
     "- 明确这次任务最终要交付什么结果，最终回复会由系统自动发送到任务绑定的 chat。",
-    "- 如果需要额外文件，请写入本次 run 目录，便于审计和排查。",
+    "- 如果需要向用户交付额外文件，请写入明确的项目路径。",
     "",
     "# 背景与输入",
     "",
@@ -69,7 +69,7 @@ function buildDefaultTaskBody(): string {
     "",
     "1. 先理解任务目标与完成标准。",
     "2. 按需要收集信息、执行分析或运行命令。",
-    "3. 把关键中间产物写入 run 目录。",
+    "3. 需要文件交付时，把产物写入明确的项目路径。",
     "4. 整理出面向用户可直接阅读的最终结果。",
     "",
     "# 输出要求",
@@ -87,7 +87,7 @@ function buildDefaultTaskBody(): string {
     "# 注意事项",
     "",
     "- 当前是独立 task 上下文，不要假设仍处在原始聊天回合里。",
-    "- 尽量使用可审计的方式：关键中间产物写入 `./.downcity/task/<title>/<timestamp>/` 下的 markdown 文件。",
+    "- 任务运行记录由系统保存在当前 Agent 的私有目录；需要交付给用户的文件应明确写入项目目录。",
     "- 如果任务明确要求跨会话、跨平台或发送额外通知，再显式调用 chat plugin 的发送 action。",
     "",
   ].join("\n");
@@ -95,10 +95,10 @@ function buildDefaultTaskBody(): string {
 
 
 export async function listTaskDefinitions(params: {
-  project_root: string;
+  data_path: string;
   status?: ShipTaskStatus;
 }): Promise<TaskListResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const normalizedStatus = normalizeTaskStatus(params.status);
 
   const tasks = await listTasks(root);
@@ -126,10 +126,10 @@ export async function listTaskDefinitions(params: {
 }
 
 export async function createTaskDefinition(params: {
-  project_root: string;
+  data_path: string;
   request: TaskCreateRequest;
 }): Promise<TaskCreateResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const req = params.request;
 
   const title = String(req.title || "").trim();
@@ -178,7 +178,7 @@ export async function createTaskDefinition(params: {
   try {
     const written = await writeTask({
       taskId: targetTaskId,
-      project_root: root,
+      data_path: root,
       overwrite: Boolean(req.overwrite) || Boolean(duplicated),
       frontmatter: {
         title,
@@ -206,15 +206,15 @@ export async function createTaskDefinition(params: {
 }
 
 export async function updateTaskDefinition(params: {
-  project_root: string;
+  data_path: string;
   request: TaskUpdateRequest;
 }): Promise<TaskUpdateResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const req = params.request;
   const title = String(req.title || "").trim();
   let taskId = "";
   try {
-    taskId = await resolveTaskIdByTitle({ project_root: root, title });
+    taskId = await resolveTaskIdByTitle({ data_path: root, title });
   } catch (error) {
     return { success: false, error: String(error) };
   }
@@ -229,7 +229,7 @@ export async function updateTaskDefinition(params: {
 
   try {
     const current = await readTask({
-      project_root: root,
+      data_path: root,
       taskId,
     });
 
@@ -291,7 +291,7 @@ export async function updateTaskDefinition(params: {
         : current.body;
 
     const written = await writeTask({
-      project_root: root,
+      data_path: root,
       taskId,
       overwrite: true,
       frontmatter: {
@@ -321,15 +321,15 @@ export async function updateTaskDefinition(params: {
 
 export async function runTaskDefinition(params: {
   context: PluginContext;
-  project_root: string;
+  data_path: string;
   request: TaskRunRequest;
   execution_context?: PluginExecutionContext;
 }): Promise<TaskRunResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const title = String(params.request.title || "").trim();
   let taskId = "";
   try {
-    taskId = await resolveTaskIdByTitle({ project_root: root, title });
+    taskId = await resolveTaskIdByTitle({ data_path: root, title });
   } catch (error) {
     return { success: false, error: String(error) };
   }
@@ -343,7 +343,7 @@ export async function runTaskDefinition(params: {
     // 关键点（中文）：run 改为“异步受理”，先做存在性校验，再后台执行。
     await readTask({
       taskId,
-      project_root: root,
+      data_path: root,
     });
 
     params.context.logger.info(
@@ -358,7 +358,7 @@ export async function runTaskDefinition(params: {
     const executionId = `${taskId}:${Date.now()}`;
     void runTaskNow({
       context: params.context,
-      project_root: root,
+      data_path: root,
       taskId,
       trigger,
       executionId,
@@ -417,14 +417,14 @@ export async function runTaskDefinition(params: {
 }
 
 export async function setTaskStatus(params: {
-  project_root: string;
+  data_path: string;
   request: TaskSetStatusRequest;
 }): Promise<TaskSetStatusResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const title = String(params.request.title || "").trim();
   let taskId = "";
   try {
-    taskId = await resolveTaskIdByTitle({ project_root: root, title });
+    taskId = await resolveTaskIdByTitle({ data_path: root, title });
   } catch (error) {
     return { success: false, error: String(error) };
   }
@@ -439,12 +439,12 @@ export async function setTaskStatus(params: {
 
   try {
     const task = await readTask({
-      project_root: root,
+      data_path: root,
       taskId,
     });
 
     await writeTask({
-      project_root: root,
+      data_path: root,
       taskId,
       overwrite: true,
       frontmatter: {
@@ -468,21 +468,21 @@ export async function setTaskStatus(params: {
 }
 
 export async function deleteTaskDefinition(params: {
-  project_root: string;
+  data_path: string;
   request: TaskDeleteRequest;
 }): Promise<TaskDeleteResponse> {
-  const root = path.resolve(params.project_root);
+  const root = path.resolve(params.data_path);
   const title = String(params.request.title || "").trim();
   let taskId = "";
   try {
-    taskId = await resolveTaskIdByTitle({ project_root: root, title });
+    taskId = await resolveTaskIdByTitle({ data_path: root, title });
   } catch (error) {
     return { success: false, error: String(error) };
   }
 
   try {
     const deleted = await deleteTask({
-      project_root: root,
+      data_path: root,
       taskId,
     });
     return {

package/src/task/PROMPT.ts

@@ -4,6 +4,6 @@
  */
 
 // Source: src/task/PROMPT.ts.txt
-const TEXT_MODULE_CONTENT = "# Task Plugin\n\nYou can use the `task` plugin to manage task definitions, execution, scheduling, and status control.\n\n## Task Model\n\nEach task is defined in `./.downcity/task/<title>/task.md` and contains:\n- frontmatter for structured fields\n- body for the task instructions\n\nCore frontmatter fields:\n- `title`: unique task identifier\n- `description`: task description\n- `when`: trigger condition, supporting `@manual`, cron, or `time:<ISO8601-with-timezone>`\n- `session_id`: task execution session\n- `status`: `enabled|paused|disabled`\n- `kind`: `agent|script`, defaulting to `agent`\n\nEach execution creates a run directory:\n- `./.downcity/task/<title>/<timestamp>/`\n\nCommon artifacts:\n- `input.md`\n- `output.md`: final output body for this run\n- `result.md`: execution summary\n- `run.json`\n- `run-progress.json`\n- `dialogue.md` / `dialogue.json`: multi-turn agent dialogue\n- `error.md`: failure details\n\n## Execution Kinds\n\n1. `kind=agent`\n- Sends the task body to an agent for execution.\n- Completes in a single turn by default. Simulated multi-turn review is enabled only when frontmatter explicitly sets `review: true`.\n- Suitable for research, analysis, and report generation.\n\n2. `kind=script`\n- Treats the body as a shell script.\n- The body must be non-empty and executable as a script.\n\n## Available Actions\n\n- `list`\n- `create`\n- `run`\n- `delete`\n- `update`\n- `status`\n- `enable`\n- `disable`\n\n## Action Examples\n\n- `plugin_call({ plugin: \"task\", action: \"list\", payload: { status } })`\n- `plugin_call({ plugin: \"task\", action: \"create\", payload: { title, description, session_id, when, kind, status } })`\n- `plugin_call({ plugin: \"task\", action: \"run\", payload: { title, reason } })`\n- `plugin_call({ plugin: \"task\", action: \"update\", payload: { title, description, when, status, session_id } })`\n- `plugin_call({ plugin: \"task\", action: \"delete\", payload: { title } })`\n\n## Key Constraints\n\n- `title` is unique. `create` deduplicates only by exact `title`.\n- After `when=time:...` triggers, the task is automatically set to `paused` and falls back to `when=@manual`.\n- `run` is accepted asynchronously. It returns `accepted=true`, `message`, and `executionId` immediately. Treat this as \"the task has entered background execution; the result will be sent automatically through the chat plugin runtime, and the current flow does not need to block.\"\n- If `run` returns `accepted=true`:\n  - Do not manually forward task output to the user again.\n  - Do not actively poll the run directory, `run-progress.json`, or `output.md`.\n  - Inspect the run directory only when the user explicitly asks to debug, view artifacts, or confirm execution details.\n- Agent tasks only need to produce valid output by default. They should send to an external channel only when the task body explicitly requires it.\n\n## Designing The Task Body\n\n### Recommended Agent Task Structure\n\nThe body should include at least these headings:\n\n```md\n# Task Goal\n\n- What final result this task must deliver.\n\n# Background And Input\n\n- Data sources, scope, constraints, and reference materials.\n\n# Execution Steps\n\n1. What to do first.\n2. What to do next.\n3. Where key intermediate artifacts should be written.\n\n# Output Requirements\n\n- What format the final result must use.\n- Whether a table, JSON, or Markdown is required.\n- What content must not be included.\n\n# Trigger And Status Recommendation\n\n- Why this task is suitable for `@manual`, cron, or `time:...`.\n- Whether it should currently be `paused` or `enabled`.\n\n# Notes\n\n- Risks, boundaries, and things not to do.\n```\n\n### Agent Task Body Writing Constraints\n\n- The task body must read like a delivery contract, so another executor can run it directly without relying on the current chat context.\n- `# Task Goal` must clearly state the final deliverable. Do not write vague goals such as \"take a look\", \"research this\", or \"handle this\".\n- `# Background And Input` must specify sources, scope, objects, time range, and constraints. Do not assume the executor can see the original chat context.\n- `# Execution Steps` should describe the task workflow, not task-management actions. Do not write \"first check whether a task with the same name exists\", \"then create a task\", or \"then trigger the task\".\n- `# Output Requirements` must clearly specify the final artifact's format, structure, tone, length, and excluded content.\n- Explicitly state that the final assistant message will be written directly to `output.md` and sent to the user. Therefore, the final answer must be exactly the deliverable content.\n- Content-generation tasks such as daily reports, reminders, morning briefings, summaries, and reports must explicitly require \"the final output is the deliverable body itself\". Do not let the executor output process notes.\n- If the task result should be sent to the user, the body should require \"output send-ready message content\" instead of asking the executor to explain what it has sent.\n- Unless truly needed, do not ask the executor to repeat the task title, session_id, execution time, status, or other metadata in the body.\n- Constraints in the body must be executable and checkable. Avoid weak phrases such as \"appropriately\", \"as much as possible\", or \"depending on the situation\".\n- Do not put task creation, task update, task status lookup, or same-title existence checks into the body. Those belong to the task plugin, not to the task deliverable.\n\n### Forbidden Agent Task Body Patterns\n\n- Do not write the body in chat-reply style, for example:\n  - \"I will help you...\"\n  - \"First, let me...\"\n  - \"I will check first...\"\n  - \"I see there is already a task with the same name...\"\n- Do not write the body as task-management instructions, for example:\n  - \"If the task exists, update it; otherwise create it.\"\n  - \"First list, then run.\"\n  - \"Tell the user that the task has started when done.\"\n- Do not write the body as a status-report template, for example:\n  - \"Task status summary\"\n  - \"Sent / completed / updated\"\n  - \"Current task configuration\"\n- Do not describe only actions without describing the deliverable, for example:\n  - \"Go collect some materials.\"\n  - \"Generate some content and see.\"\n  - \"Report back after finishing.\"\n- Do not use references that depend on the current context, for example:\n  - \"Do what was said above.\"\n  - \"Continue the previous one.\"\n  - \"Send this out.\"\n\n### How To Judge Whether The Body Is Good\n\n- If you can copy the task body alone to another agent and it can still understand the goal, input, steps, and deliverable, the body is valid.\n- If deleting the output section leaves only \"go do something\" style instructions, the body is invalid.\n- If the body looks more like instructions for creating or updating a task than instructions for executing the task, the layering is wrong and the body must be rewritten.\n- If the body naturally encourages the executor to output process notes instead of the final artifact, the `# Output Requirements` section is not strong enough and must add explicit prohibitions.\n\n### Recommended Script Task Structure\n\n- The body must be a pure shell script. Do not mix in explanatory natural language.\n- Start with comments that describe the script's purpose, input dependencies, and failure conditions when possible.\n- Keep output stable so it can be sent directly as the final result.\n- If files need to be generated, write them to the run directory or to an explicit project path.\n\n### Output Design Principles\n\n- When a task completes, the system automatically sends the final result body back to the chat bound to `session_id` through the chat plugin runtime's `send`.\n- The current implementation uses the simplest rule: the final assistant message is treated directly as the final result body and written to `output.md`.\n- Therefore, the \"Output Requirements\" section must be written for the final user, not only for developers.\n- For user-facing agent tasks, the body should require \"the final assistant message directly outputs the deliverable itself\". Do not let the executor explain how it created, checked, updated, triggered, or sent the task.\n- For content-generation tasks such as daily reports, reminders, morning briefings, and summaries, the final output should be exactly that content. It should not include process language such as \"I will handle this\", \"task sent\", or \"task status summary\".\n- By default, do not ask the executor to call chat plugin send actions again. The system handles final-result delivery.\n- Explicitly require chat plugin actions only for cross-conversation sending, additional CCs, multi-channel notifications, or similar cases.\n\n### Choosing `when` And `status`\n\n- A task is created as `status=enabled` by default. Set `paused` explicitly only when it is still a draft, likely to fail, or needs human confirmation.\n- For verified stable tasks that need automatic execution, use cron with `status=enabled`.\n- For a clear one-time execution, use `time:<ISO time with timezone>`. After execution, the system automatically falls back to `@manual` and `paused`.\n- If the user only wants to save it for later, do not enable scheduling directly.\n\n## Body Templates\n\n### Agent Template\n\n```md\n# Task Goal\n\n- Produce a final result that can be sent directly to the user.\n\n# Background And Input\n\n- Add context, files, links, scope, and assumptions here.\n\n# Execution Steps\n\n1. Understand the task goal and completion criteria.\n2. Collect necessary information and execute the task.\n3. Write key intermediate artifacts to the run directory.\n4. Output the final result body.\n\n# Output Requirements\n\n- The final assistant message is the final result. Do not include long logs.\n- The final assistant message must output the deliverable itself. Do not output task-management process, sending process, or status reports.\n- Do not use meta language such as \"I will help you...\", \"First, let me...\", or \"sent\".\n- By default, do not call the chat plugin send action again.\n\n# Trigger And Status Recommendation\n\n- Enable by default after creation. If this is only a draft or waiting for human confirmation, set it to `paused`.\n\n# Notes\n\n- Call chat plugin send actions only when cross-conversation or additional notifications are explicitly needed.\n```\n\n### Script Template\n\n```bash\n# Task goal: state in one sentence what the script should do\n# Input dependencies: list environment variables, files, and command dependencies\n# Failure conditions: list cases that should exit 1\n\nset -euo pipefail\n\n# 1. Prepare input\n\n# 2. Execute main logic\n\n# 3. Output final result. This output will be sent directly to the user.\n```\n\n## Recommendations\n\n- Run `list` before `create` or `update`.\n- Keep simple content-generation tasks single-turn by default. Set `review: true` only when you truly need \"draft, review, revise\".\n- Keep script task bodies as pure scripts, without redundant natural-language explanation.\n- If the user only wants to save something for later, create it as `paused`; otherwise keep the default enabled state.\n- The task body must describe what the final result should look like, not only say \"go do this and see\".\n- For content-generation tasks, explicitly require \"the final assistant message can only be the finished content body\" so the executor does not mistake process notes for the final result.\n";
+const TEXT_MODULE_CONTENT = "# Task Plugin\n\nYou can use the `task` plugin to manage task definitions, execution, scheduling, and status control.\n\n## Task Model\n\nEach task is defined in the current Agent private runtime directory private `task/<title>/task.md` and contains:\n- frontmatter for structured fields\n- body for the task instructions\n\nCore frontmatter fields:\n- `title`: unique task identifier\n- `description`: task description\n- `when`: trigger condition, supporting `@manual`, cron, or `time:<ISO8601-with-timezone>`\n- `session_id`: task execution session\n- `status`: `enabled|paused|disabled`\n- `kind`: `agent|script`, defaulting to `agent`\n\nEach execution creates a private run record managed by Downcity under the current Agent private runtime directory.\n\nCommon artifacts:\n- `input.md`\n- `output.md`: final output body for this run\n- `result.md`: execution summary\n- `run.json`\n- `run-progress.json`\n- `dialogue.md` / `dialogue.json`: multi-turn agent dialogue\n- `error.md`: failure details\n\n## Execution Kinds\n\n1. `kind=agent`\n- Sends the task body to an agent for execution.\n- Completes in a single turn by default. Simulated multi-turn review is enabled only when frontmatter explicitly sets `review: true`.\n- Suitable for research, analysis, and report generation.\n\n2. `kind=script`\n- Treats the body as a shell script.\n- The body must be non-empty and executable as a script.\n\n## Available Actions\n\n- `list`\n- `create`\n- `run`\n- `delete`\n- `update`\n- `status`\n- `enable`\n- `disable`\n\n## Action Examples\n\n- `plugin_call({ plugin: \"task\", action: \"list\", payload: { status } })`\n- `plugin_call({ plugin: \"task\", action: \"create\", payload: { title, description, session_id, when, kind, status } })`\n- `plugin_call({ plugin: \"task\", action: \"run\", payload: { title, reason } })`\n- `plugin_call({ plugin: \"task\", action: \"update\", payload: { title, description, when, status, session_id } })`\n- `plugin_call({ plugin: \"task\", action: \"delete\", payload: { title } })`\n\n## Key Constraints\n\n- `title` is unique. `create` deduplicates only by exact `title`.\n- After `when=time:...` triggers, the task is automatically set to `paused` and falls back to `when=@manual`.\n- `run` is accepted asynchronously. It returns `accepted=true`, `message`, and `executionId` immediately. Treat this as \"the task has entered background execution; the result will be sent automatically through the chat plugin runtime, and the current flow does not need to block.\"\n- If `run` returns `accepted=true`:\n  - Do not manually forward task output to the user again.\n  - Do not actively poll the run directory, `run-progress.json`, or `output.md`.\n  - Inspect run details through the task/control API only when the user explicitly asks to debug, view artifacts, or confirm execution details.\n- Agent tasks only need to produce valid output by default. They should send to an external channel only when the task body explicitly requires it.\n\n## Designing The Task Body\n\n### Recommended Agent Task Structure\n\nThe body should include at least these headings:\n\n```md\n# Task Goal\n\n- What final result this task must deliver.\n\n# Background And Input\n\n- Data sources, scope, constraints, and reference materials.\n\n# Execution Steps\n\n1. What to do first.\n2. What to do next.\n3. Where key intermediate artifacts should be written.\n\n# Output Requirements\n\n- What format the final result must use.\n- Whether a table, JSON, or Markdown is required.\n- What content must not be included.\n\n# Trigger And Status Recommendation\n\n- Why this task is suitable for `@manual`, cron, or `time:...`.\n- Whether it should currently be `paused` or `enabled`.\n\n# Notes\n\n- Risks, boundaries, and things not to do.\n```\n\n### Agent Task Body Writing Constraints\n\n- The task body must read like a delivery contract, so another executor can run it directly without relying on the current chat context.\n- `# Task Goal` must clearly state the final deliverable. Do not write vague goals such as \"take a look\", \"research this\", or \"handle this\".\n- `# Background And Input` must specify sources, scope, objects, time range, and constraints. Do not assume the executor can see the original chat context.\n- `# Execution Steps` should describe the task workflow, not task-management actions. Do not write \"first check whether a task with the same name exists\", \"then create a task\", or \"then trigger the task\".\n- `# Output Requirements` must clearly specify the final artifact's format, structure, tone, length, and excluded content.\n- Explicitly state that the final assistant message will be written directly to `output.md` and sent to the user. Therefore, the final answer must be exactly the deliverable content.\n- Content-generation tasks such as daily reports, reminders, morning briefings, summaries, and reports must explicitly require \"the final output is the deliverable body itself\". Do not let the executor output process notes.\n- If the task result should be sent to the user, the body should require \"output send-ready message content\" instead of asking the executor to explain what it has sent.\n- Unless truly needed, do not ask the executor to repeat the task title, session_id, execution time, status, or other metadata in the body.\n- Constraints in the body must be executable and checkable. Avoid weak phrases such as \"appropriately\", \"as much as possible\", or \"depending on the situation\".\n- Do not put task creation, task update, task status lookup, or same-title existence checks into the body. Those belong to the task plugin, not to the task deliverable.\n\n### Forbidden Agent Task Body Patterns\n\n- Do not write the body in chat-reply style, for example:\n  - \"I will help you...\"\n  - \"First, let me...\"\n  - \"I will check first...\"\n  - \"I see there is already a task with the same name...\"\n- Do not write the body as task-management instructions, for example:\n  - \"If the task exists, update it; otherwise create it.\"\n  - \"First list, then run.\"\n  - \"Tell the user that the task has started when done.\"\n- Do not write the body as a status-report template, for example:\n  - \"Task status summary\"\n  - \"Sent / completed / updated\"\n  - \"Current task configuration\"\n- Do not describe only actions without describing the deliverable, for example:\n  - \"Go collect some materials.\"\n  - \"Generate some content and see.\"\n  - \"Report back after finishing.\"\n- Do not use references that depend on the current context, for example:\n  - \"Do what was said above.\"\n  - \"Continue the previous one.\"\n  - \"Send this out.\"\n\n### How To Judge Whether The Body Is Good\n\n- If you can copy the task body alone to another agent and it can still understand the goal, input, steps, and deliverable, the body is valid.\n- If deleting the output section leaves only \"go do something\" style instructions, the body is invalid.\n- If the body looks more like instructions for creating or updating a task than instructions for executing the task, the layering is wrong and the body must be rewritten.\n- If the body naturally encourages the executor to output process notes instead of the final artifact, the `# Output Requirements` section is not strong enough and must add explicit prohibitions.\n\n### Recommended Script Task Structure\n\n- The body must be a pure shell script. Do not mix in explanatory natural language.\n- Start with comments that describe the script's purpose, input dependencies, and failure conditions when possible.\n- Keep output stable so it can be sent directly as the final result.\n- If files need to be delivered to the user, write them to an explicit project path.\n\n### Output Design Principles\n\n- When a task completes, the system automatically sends the final result body back to the chat bound to `session_id` through the chat plugin runtime's `send`.\n- The current implementation uses the simplest rule: the final assistant message is treated directly as the final result body and written to `output.md`.\n- Therefore, the \"Output Requirements\" section must be written for the final user, not only for developers.\n- For user-facing agent tasks, the body should require \"the final assistant message directly outputs the deliverable itself\". Do not let the executor explain how it created, checked, updated, triggered, or sent the task.\n- For content-generation tasks such as daily reports, reminders, morning briefings, and summaries, the final output should be exactly that content. It should not include process language such as \"I will handle this\", \"task sent\", or \"task status summary\".\n- By default, do not ask the executor to call chat plugin send actions again. The system handles final-result delivery.\n- Explicitly require chat plugin actions only for cross-conversation sending, additional CCs, multi-channel notifications, or similar cases.\n\n### Choosing `when` And `status`\n\n- A task is created as `status=enabled` by default. Set `paused` explicitly only when it is still a draft, likely to fail, or needs human confirmation.\n- For verified stable tasks that need automatic execution, use cron with `status=enabled`.\n- For a clear one-time execution, use `time:<ISO time with timezone>`. After execution, the system automatically falls back to `@manual` and `paused`.\n- If the user only wants to save it for later, do not enable scheduling directly.\n\n## Body Templates\n\n### Agent Template\n\n```md\n# Task Goal\n\n- Produce a final result that can be sent directly to the user.\n\n# Background And Input\n\n- Add context, files, links, scope, and assumptions here.\n\n# Execution Steps\n\n1. Understand the task goal and completion criteria.\n2. Collect necessary information and execute the task.\n3. Write user-visible artifacts to an explicit project path when needed.\n4. Output the final result body.\n\n# Output Requirements\n\n- The final assistant message is the final result. Do not include long logs.\n- The final assistant message must output the deliverable itself. Do not output task-management process, sending process, or status reports.\n- Do not use meta language such as \"I will help you...\", \"First, let me...\", or \"sent\".\n- By default, do not call the chat plugin send action again.\n\n# Trigger And Status Recommendation\n\n- Enable by default after creation. If this is only a draft or waiting for human confirmation, set it to `paused`.\n\n# Notes\n\n- Call chat plugin send actions only when cross-conversation or additional notifications are explicitly needed.\n```\n\n### Script Template\n\n```bash\n# Task goal: state in one sentence what the script should do\n# Input dependencies: list environment variables, files, and command dependencies\n# Failure conditions: list cases that should exit 1\n\nset -euo pipefail\n\n# 1. Prepare input\n\n# 2. Execute main logic\n\n# 3. Output final result. This output will be sent directly to the user.\n```\n\n## Recommendations\n\n- Run `list` before `create` or `update`.\n- Keep simple content-generation tasks single-turn by default. Set `review: true` only when you truly need \"draft, review, revise\".\n- Keep script task bodies as pure scripts, without redundant natural-language explanation.\n- If the user only wants to save something for later, create it as `paused`; otherwise keep the default enabled state.\n- The task body must describe what the final result should look like, not only say \"go do this and see\".\n- For content-generation tasks, explicitly require \"the final assistant message can only be the finished content body\" so the executor does not mistake process notes for the final result.\n";
 
 export default TEXT_MODULE_CONTENT;

package/src/task/PROMPT.ts.txt

@@ -4,7 +4,7 @@ You can use the `task` plugin to manage task definitions, execution, scheduling,
 
 ## Task Model
 
-Each task is defined in `./.downcity/task/<title>/task.md` and contains:
+Each task is defined in the current Agent private runtime directory private `task/<title>/task.md` and contains:
 - frontmatter for structured fields
 - body for the task instructions
 
@@ -16,8 +16,7 @@ Core frontmatter fields:
 - `status`: `enabled|paused|disabled`
 - `kind`: `agent|script`, defaulting to `agent`
 
-Each execution creates a run directory:
-- `./.downcity/task/<title>/<timestamp>/`
+Each execution creates a private run record managed by Downcity under the current Agent private runtime directory.
 
 Common artifacts:
 - `input.md`
@@ -66,7 +65,7 @@ Common artifacts:
 - If `run` returns `accepted=true`:
   - Do not manually forward task output to the user again.
   - Do not actively poll the run directory, `run-progress.json`, or `output.md`.
-  - Inspect the run directory only when the user explicitly asks to debug, view artifacts, or confirm execution details.
+  - Inspect run details through the task/control API only when the user explicitly asks to debug, view artifacts, or confirm execution details.
 - Agent tasks only need to produce valid output by default. They should send to an external channel only when the task body explicitly requires it.
 
 ## Designing The Task Body
@@ -156,7 +155,7 @@ The body should include at least these headings:
 - The body must be a pure shell script. Do not mix in explanatory natural language.
 - Start with comments that describe the script's purpose, input dependencies, and failure conditions when possible.
 - Keep output stable so it can be sent directly as the final result.
-- If files need to be generated, write them to the run directory or to an explicit project path.
+- If files need to be delivered to the user, write them to an explicit project path.
 
 ### Output Design Principles
 
@@ -192,7 +191,7 @@ The body should include at least these headings:
 
 1. Understand the task goal and completion criteria.
 2. Collect necessary information and execute the task.
-3. Write key intermediate artifacts to the run directory.
+3. Write user-visible artifacts to an explicit project path when needed.
 4. Output the final result body.
 
 # Output Requirements

package/src/task/Scheduler.ts

@@ -36,7 +36,7 @@ export async function registerTaskCronJobs(params: {
 }): Promise<{ tasksFound: number; jobsScheduled: number }> {
   const context = params.context;
   const logger = context.logger;
-  const tasks = await listTasks(context.workspace_path);
+  const tasks = await listTasks(context.data_path);
   const runtimeTimezone = params.timezone;
 
   let jobsScheduled = 0;
@@ -49,7 +49,7 @@ export async function registerTaskCronJobs(params: {
     try {
       const task = await readTask({
         taskId: item.taskId,
-        project_root: context.workspace_path,
+        data_path: context.data_path,
       });
       latestWhen = task.frontmatter.when;
     } catch {}
@@ -78,7 +78,7 @@ export async function registerTaskCronJobs(params: {
               // 关键点（中文）：触发瞬间复查最新 task.md，避免 status/when 变更后仍沿用旧注册状态。
               const latest = await readTask({
                 taskId,
-                project_root: context.workspace_path,
+                data_path: context.data_path,
               });
               if (String(latest.frontmatter.status).toLowerCase() !== "enabled") {
                 return;
@@ -91,7 +91,7 @@ export async function registerTaskCronJobs(params: {
               const result = await runTaskNow({
                 context,
                 taskId,
-                project_root: context.workspace_path,
+                data_path: context.data_path,
                 trigger: { type: "cron" },
               });
 
@@ -166,7 +166,7 @@ export async function registerTaskCronJobs(params: {
           try {
             const latest = await readTask({
               taskId,
-              project_root: context.workspace_path,
+              data_path: context.data_path,
             });
             if (String(latest.frontmatter.status).toLowerCase() !== "enabled") return;
             const latestPlannedMs = resolveTaskWhenOneShotMs(latest.frontmatter.when);
@@ -177,7 +177,7 @@ export async function registerTaskCronJobs(params: {
             const result = await runTaskNow({
               context,
               taskId,
-              project_root: context.workspace_path,
+              data_path: context.data_path,
               trigger: { type: "time" },
             });
 
@@ -206,10 +206,10 @@ export async function registerTaskCronJobs(params: {
               try {
                 const latest = await readTask({
                   taskId,
-                  project_root: context.workspace_path,
+                  data_path: context.data_path,
                 });
                 await writeTask({
-                  project_root: context.workspace_path,
+                  data_path: context.data_path,
                   taskId,
                   overwrite: true,
                   frontmatter: {