agent-sin 0.1.12 → 0.1.16

package/dist/builder/builder-session.js

@@ -6,10 +6,11 @@ import { getAiProvider, } from "../core/ai-provider.js";
 import { findMissingRequiredEnv, runSkill } from "../core/runtime.js";
 import { loadKnownModelIds, validateSkillDirectory, validateSkillId, } from "../core/skill-scaffold.js";
 import { appendConversationLog } from "../core/logger.js";
-import { dotenvPath, loadDotenv } from "../core/secrets.js";
+import { dotenvPath, loadDotenv, removeFromDotenv, upsertDotenv } from "../core/secrets.js";
 import { formatProfileMemoryPromptSection, readProfileMemoryForPrompt, } from "../core/profile-memory.js";
 import { maybePromoteDailyMemory } from "../core/daily-memory-promotion.js";
 import { l } from "../core/i18n.js";
+import { agentSinOperatingModelLines } from "../core/operating-model.js";
 export async function createBuildSession(config, skillId, options = {}) {
     const id = skillId || `new-skill-${timestampId()}`;
     validateSkillId(id);
@@ -507,7 +508,80 @@ async function runBuilderTurn(config, session, state, options) {
     catch {
         // No fenced blocks — agent wrote (or didn't) directly via cwd.
     }
-    return { response, parsedSummary };
+    const envSaved = await applyBuilderEnvAssignments(config, response.text, options.onProgress);
+    return { response, parsedSummary, envSaved };
+}
+function parseBuilderEnvAssignments(text) {
+    const upserts = [];
+    const deletes = [];
+    const seenUpsert = new Set();
+    const seenDelete = new Set();
+    const blockPattern = /```env\s*\n([\s\S]*?)\n```/g;
+    let block;
+    while ((block = blockPattern.exec(text)) !== null) {
+        for (const raw of block[1].split(/\r?\n/)) {
+            const line = raw.trim();
+            if (!line || line.startsWith("#"))
+                continue;
+            const removeMatch = line.match(/^(?:-|delete\s+|remove\s+)([A-Za-z_][A-Za-z0-9_]*)\s*$/i);
+            if (removeMatch) {
+                const key = removeMatch[1];
+                if (/^AGENT_SIN_/i.test(key))
+                    continue;
+                if (seenDelete.has(key))
+                    continue;
+                seenDelete.add(key);
+                deletes.push(key);
+                continue;
+            }
+            const match = line.match(/^(?:export\s+)?([A-Za-z_][A-Za-z0-9_]*)\s*=\s*(.*)$/);
+            if (!match)
+                continue;
+            const key = match[1];
+            if (/^AGENT_SIN_/i.test(key))
+                continue;
+            let value = match[2].trim();
+            if (value.length >= 2) {
+                const first = value.charAt(0);
+                const last = value.charAt(value.length - 1);
+                if ((first === '"' && last === '"') || (first === "'" && last === "'")) {
+                    value = value.slice(1, -1);
+                }
+            }
+            if (!value || seenUpsert.has(key))
+                continue;
+            seenUpsert.add(key);
+            upserts.push({ key, value });
+        }
+    }
+    return { upserts, deletes };
+}
+async function applyBuilderEnvAssignments(config, text, onProgress) {
+    const { upserts, deletes } = parseBuilderEnvAssignments(text);
+    const saved = [];
+    if (upserts.length > 0) {
+        try {
+            await upsertDotenv(config.workspace, upserts);
+            for (const entry of upserts)
+                saved.push(entry.key);
+            emitBuildProgress(onProgress, l(`Saving ${upserts.length} env value(s)`, `${upserts.length}件の環境変数を保存しています`));
+        }
+        catch {
+            // ignore — best effort
+        }
+    }
+    if (deletes.length > 0) {
+        try {
+            const result = await removeFromDotenv(config.workspace, deletes);
+            if (result.removed.length > 0) {
+                emitBuildProgress(onProgress, l(`Removing ${result.removed.length} env value(s)`, `${result.removed.length}件の環境変数を削除しています`));
+            }
+        }
+        catch {
+            // ignore — best effort
+        }
+    }
+    return saved;
 }
 export async function prepareEditDraft(config, skillId) {
     let manifest;
@@ -697,7 +771,7 @@ export function formatDiscordSlashGuidance(context) {
         "- Shape:\n```\ninvocation:\n  phrases: [...]              # required (keep)\n  discord_slash:                # optional (add)\n    description: Flip a coin\n    options:\n      - name: count\n        type: integer           # only string|integer|number|boolean\n        description: number of flips\n        required: false\n```",
         "- Rules: the command name is taken from skill.id (one skill = one command, flat options, no subcommands). `options[*].type` must be string/integer/number/boolean. `choices` must be `[{name, value}]` for string/integer/number only. `required` defaults to false. A Japanese description can be placed in `description_ja`.",
         "- Keep `input.schema` and `discord_slash.options` consistent. Use matching names/meanings (e.g. if the schema has `text`, the option should also be `name: text`).",
-        "- Activation timing: when a skill that adds, changes, or removes `discord_slash` is registered, the Discord slash-command list will only update after the bot restarts (reconnects). Always mention this in the completion message (e.g. \"Restart the bot to use it as a slash command. The chat trigger (phrases) is available now.\"). A skill that only uses `phrases`, or an edit that does not touch `discord_slash`, does not require a restart.",
+        "- Activation timing: when a skill that adds, changes, or removes `discord_slash` is registered, the Discord slash-command list will only update after the bot restarts (reconnects). Do not tell the user only to restart manually. Say that the chat trigger is available now, and that if they want Agent-Sin to restart, they can send \"Agent-Sinを再起動して\" / \"restart Agent-Sin\" next. A skill that only uses `phrases`, or an edit that does not touch `discord_slash`, does not require a restart.",
         "",
     ];
 }
@@ -713,6 +787,9 @@ function formatBuilderRuntimeContext(context) {
         `- agent-sin source tree (read-only, for reference): ${context.install_root}`,
         `- agent-sin workspace: ${context.workspace_dir}`,
         `- Other skills (read-only, for reference): ${context.skills_dir}`,
+        `- Run logs (read-only): ${context.workspace_dir}/logs/runs/<run-id>.json — each file holds one skill execution's input.args, result.summary, result.data and ctx_logs. Useful when the user says "didn't return X" / "was wrong" — read recent runs of this skill to see exactly what the previous version produced vs. what the user wanted.`,
+        `- Conversation logs (read-only): ${context.workspace_dir}/logs/conversations/<YYYY-MM-DD>.jsonl — daily chat history with user, assistant, and skill turns. Useful when you need the surrounding intent that triggered the gap.`,
+        `- Skill data store (read-only, for reference): ${context.workspace_dir}/data/<skill-id>.db — per-skill SQLite history. Open it to see what data the skill has actually accumulated before deciding what to change.`,
         `- .env (update only the env vars this skill needs): ${context.dotenv_path}`,
         "",
         "# Areas you must not touch directly, and how to handle them",
@@ -744,6 +821,8 @@ function buildBuilderMessages(session, state, runtimeContext, profileMemory) {
         "- Your job is to build a skill that runs on agent-sin from the user's request, and to leave it in a state where it can be used immediately after writing.",
         "- The user is not an engineer. Do not ask about function names, commands, or technical jargon. Take requirements in plain language.",
         "",
+        ...agentSinOperatingModelLines("builder"),
+        "",
         "# How to proceed",
         "1. Read the user's requirements. Only when something truly cannot be built without clarification, ask at most three questions at a time. You may ask another batch of up to three if the answer is still insufficient. Iterate as many times as needed. Conversely, when you can decide on your own, go straight to implementation.",
         "2. Once requirements are clear, you *must* emit file blocks in the response body to write the files. The format is `\\`\\`\\`file:<relative-path>` to open, the raw file content, and `\\`\\`\\`` to close. Always emit both skill.yaml and main.py (main.ts if TypeScript). If needed, emit fixtures/input.json in the same format. Do not use language fences like `\\`\\`\\`yaml` / `\\`\\`\\`python`, and do not use plain labels like \"File:\" alone. If you write only a completion report and omit the file blocks, agent-sin writes nothing and the skill stays unfinished. Example:\n```file:skill.yaml\nid: example\nname: Example\ndescription: ...\nruntime: python\ninvocation:\n  phrases:\n    - run the example\noutput_mode: raw\n```\n```file:main.py\nasync def run(ctx, input):\n    return {\"status\": \"ok\", \"summary\": \"hello\"}\n```",
@@ -755,6 +834,7 @@ function buildBuilderMessages(session, state, runtimeContext, profileMemory) {
         "- When the user says \"Discord notification\", they mean the agent-sin notification feature. Call `ctx.notify({ channel: \"discord\", ... })` from the skill. Do not create your own `DISCORD_WEBHOOK_URL` or POST to webhooks directly.",
         "- `AGENT_SIN_DISCORD_*` for Discord notifications is an agent-sin runtime setting. Do not put it in the skill's `required_env` or .env examples. Only if it is not yet configured, briefly tell the user that agent-sin's Discord notification setup is needed.",
         "- When the user says \"Telegram notification\", use `ctx.notify({ channel: \"telegram\", ... })` the same way. `AGENT_SIN_TELEGRAM_*` is also a runtime setting and must not appear in skill.yaml.",
+        "- To send a local image or file from a skill to Discord/Telegram, call `ctx.notify({ channel: \"discord\"|\"telegram\"|\"auto\", title, body, filePath })` or `filePaths`. `imagePath` / `imagePaths` are accepted aliases for image files. The path must point to a readable local file; use an absolute path or a workspace-relative path. Do not upload to Discord/Telegram directly.",
         "",
         "# Hard rules",
         "- Never finish with only a completion report and no skill.yaml / main.*. Don't stop at requirement confirmation.",
@@ -778,6 +858,7 @@ function buildBuilderMessages(session, state, runtimeContext, profileMemory) {
         "",
         "Do include (completion-report template)",
         "1-2 sentences of \"what is now possible\" (e.g. \"Classifies unread Gmail and summarizes it at 3pm.\"). If there is setup the user must do, follow with a brief description. Do not add confirmation prompts like \"Want to test it?\" or \"Should I run it?\". When the user replies with \"run it\" / \"try it\", the system auto-switches back to chat mode and runs the skill, so you do not need to prompt.",
+        "If a restart is required to apply settings, avoid a yes/no confirmation inside build mode. Tell the user they can send \"Agent-Sinを再起動して\" / \"restart Agent-Sin\" and Agent-Sin will ask or perform the restart from chat mode.",
         "",
         "## When credentials are required (API key / OAuth / token / cookie / etc.)",
         "Skills that integrate with external services almost always need credentials. It is normal that the skill cannot run immediately after implementation, so always include the following:",
@@ -785,20 +866,43 @@ function buildBuilderMessages(session, state, runtimeContext, profileMemory) {
         "  Example for Gmail: \"In Google Cloud Console (https://console.cloud.google.com/) create a new project → enable the Gmail API → set up the OAuth consent screen → Credentials → create an OAuth client ID (desktop) → download the JSON\".",
         "- Where to save what: the key names and formats to write to `~/.agent-sin/.env`, one per line.",
         "  Example: `GMAIL_CREDENTIALS_PATH=~/credentials.json`, `OPENAI_API_KEY=sk-...`.",
-        "- If the user pastes a value into chat and you can tell which `required_env` entry it belongs to, you may update `~/.agent-sin/.env` directly. After saving, just reply \"Saved.\" briefly. Only when you cannot tell, ask the user to send it as `env NAME=value`.",
+        "- Always look at the existing .env keys provided in the runtime context. Do not propose keys that are already configured (treat them as present). Propose only what is genuinely missing for this skill.",
+        "- When the user pastes one or more credential values (in any format — `KEY=value`, prose like \"トークンは abc です\", a bare token after asking for it, JSON, etc.), do not stay silent. Compare the values against the skill's `required_env` plus the .env keys you already see, and decide:",
+        "  (a) If the mapping is clear (only one missing slot fits, the user explicitly named the slot, or the value's shape unambiguously matches a documented format like `sk-...`, `GOCSPX-...`, `xoxb-...`, `1//...`), save it by emitting a fenced env block (see below) and tell the user in one short sentence which key was saved.",
+        "  (b) If the mapping is ambiguous (multiple required slots could match, value shape is unclear, or the user mentioned a key that is not in `required_env`), ask the user a short confirmation question before saving anything. Do not guess.",
+        "- To save credentials to `~/.agent-sin/.env`, include a fenced env block in your reply. The block itself is stripped from what the user sees, so still write a short natural-language confirmation in the body. The same block can also tidy up stale keys: prefix a key with `-` (or `delete `) to remove it from `.env`.",
+        "  ```env",
+        "  GOOGLE_CALENDAR_WORK_CLIENT_ID=123-abc.apps.googleusercontent.com",
+        "  GOOGLE_CALENDAR_WORK_CLIENT_SECRET=GOCSPX-1234567890abcd",
+        "  -GOOGLE_CLIENT_ID",
+        "  -GOOGLE_CLIENT_SECRET",
+        "  ```",
+        "- When the skill's `required_env` no longer needs a key that is currently in `.env` (e.g. you renamed `GOOGLE_CLIENT_ID` to `GOOGLE_CALENDAR_WORK_CLIENT_ID`), include the obsolete key with a `-` prefix in the same env block so `.env` stays in sync. Do not just say \"please delete it\" to the user — perform the cleanup yourself.",
+        "- Only put real credential values inside the env block — no quotes around obvious tokens, no placeholders like `<your-key>`, no `AGENT_SIN_*` runtime keys, no commentary lines. Empty or placeholder values are dropped. Never invent or paraphrase a credential value; only emit env entries for values the user actually provided.",
+        "- Never tell the user that .env edits were \"blocked by permissions\" or similar host-internal phrases. The env block is the supported way to read, update, and prune `.env` — use it instead of describing failures.",
         "- Do not push for \"test it\" until setup is finished. Instead write something like \"once you have obtained X and saved it to .env, let me know and I'll verify.\"",
         "",
         "# Skill authoring rules",
         "- skill.yaml requires `id` (kebab-case), `runtime` (python|typescript), `name`, `description`, and `invocation.phrases`. `invocation.phrases` is required for chat invocation; list 3-6 entries combining the skill name, aliases, and example utterances (e.g. for id `flip-coin`: `[\"flip a coin\", \"toss a coin\", \"heads or tails\", \"flip-coin\"]`). `entry` defaults to `main.py` / `main.ts` per runtime, and `handler` defaults to `run`; both can be omitted. `invocation.command`, `input.schema`, `outputs` (only when leaving notes/reports the user reads back), `memory` (only when keeping state), `ai_steps` (only when calling AI), and `required_env` are optional. Do not write empty `outputs: []` / `ai_steps: []` / `retry: max_attempts: 0`. `schema_version` / `type` / `security` / `triggers` are deprecated.",
         "- Handler signature: Python is `async def run(ctx, input)`, TS is `export async function run(ctx, input)`. `input` is a dict of `{args, trigger, sources, memory}`, and `input.args` is already validated against skill.yaml's `input.schema`.",
         "- Return value: `{status: 'ok'|'skipped'|'error', title, summary, outputs, data, suggestions}`.",
-        "- The available ctx surface is: `log.info/warn/error`, `memory.get` (async) / `memory.set` (async), `ai.run(step_id, payload)`, `notify(args)`, and `now()`. Do not touch env or fs directly.",
-        "- File output is done by returning `{content, frontmatter}` under `outputs[id]`. The Runtime saves it according to skill.yaml's `outputs[].path/filename` (you can use `{{yyyy}}/{{MM}}/{{dd}}/{{date}}/{{datetime}}`; `append: true` appends). The skill itself must not open/write files. `outputs[].type` is either `markdown` or `json`.",
+        "- The available ctx surface is: `log.info/warn/error`, `memory.get` (async) / `memory.set` (async), `ai.run(step_id, payload)`, `notify(args)`, `history.append/list/read` (async), and `now()`. Do not touch env or fs directly.",
+        "- Use `ctx.history` whenever the skill should accumulate a *queryable log* the user (or the skill itself) will look back at later — meals, weight, training, mood, expenses, study minutes, watering plants, anything that benefits from \"show me the last week / last month\". Each entry is one SQLite row in `~/.agent-sin/data/<skill-id>.db` (table `entries(id, time, meta JSON, content)`), hidden from the user — they don't see the raw DB. To enable it, declare `history: { read: true, write: true }` in skill.yaml (read-only consumers may set only `read: true`).",
+        "- `ctx.history.append({ time?, meta?, content, replace? })`: insert/upsert one row. `time` defaults to now; `meta` is an arbitrary JSON-serialisable object (typed fields go here — e.g. `{ calories: 500, type: \"lunch\", record: {...} }`); `content` is a short text body; pass `replace: true` together with `meta.id` to upsert the same row on later corrections.",
+        "- `ctx.history.list({ from?, to?, limit? })`: read past rows as a sorted array of `{ time, meta, content }`. Use this when the skill needs to compute aggregates (totals, averages, streaks).",
+        "- `ctx.history.read({ from?, to? })`: read the same range as one concatenated text string. Pipe it into an ai_steps payload when the skill should ask the LLM to *interpret* the history (e.g. \"suggest tomorrow's menu based on the last 7 days\").",
+        "- `outputs` (Markdown reports the user reads back in Obsidian) and `history` (structured per-skill SQLite log queryable by date) are complementary. `history` is the data store; `outputs` is the optional, opt-in human view. For \"log diet meals\" use history. For \"weekly health digest\" add an output that renders a summary into notes/. Do not duplicate the same data in both.",
+        "- **Markdown outputs must be rendered, human-readable content** — a narrative, a summary, a structured report someone would actually open and *read top-to-bottom in Obsidian*. They are NOT an event log: do not append `## 2026-05-22T07:38:07` blocks one per call, do not dump every API row as a markdown table per execution, do not write per-call frontmatter (`type:` / `tags:`) for each entry. Raw structured/event data, per-entry records, and anything the skill itself queries back later belongs in `ctx.history` (SQLite). The litmus test: if the file is mostly machine-shaped data that only makes sense as a sequence of records, it should be `history`, not an output. If it is a *document* (weekly digest, generated script, analysis writeup, review), it can be an output. When the user wants both raw records and a readable summary, store records in `history` and render the summary as a separate `outputs[]` entry.",
+        "- File output is done by returning `{content, frontmatter}` under `outputs[id]`. The Runtime saves it according to skill.yaml's `outputs[].path/filename` (you can use `{{yyyy}}/{{MM}}/{{dd}}/{{date}}/{{datetime}}`; `append: true` appends). The skill itself must not open/write files. `outputs[].type` is either `markdown` or `json`. For per-skill user-visible md, prefer `path: skill-outputs/<this-skill-id>` with a plain `filename` (no `{{yyyy}}/{{MM}}` subdirs) — that path is symlinked into the user's Obsidian Vault as `06 Skills/<skill-id>/`. Do NOT put outputs under `marketing/`, `news/`, `reports/`, `reviews/`, `youtube/`, `health/`, or any other ad-hoc top-level workspace dir; those used to be tolerated and are now considered legacy.",
+        "- As an escape hatch for when the runtime `outputs` block doesn't fit (rotating logs the skill itself rewrites, file lists the skill enumerates, etc.), the skill MAY open and write its own file under `input.sources.skill_output_dir` (TS: `input.sources.skillOutputDir`). The runtime creates that dir (= `~/.agent-sin/skill-outputs/<skill-id>/`) before invoking the skill, and Obsidian exposes it as `06 Skills/<skill-id>/`. Use a plain filename (`marketing-log.md`), never date subdirectories (`2026/05/2026-05-22.md`). This dir is for user-visible markdown only — internal state the user shouldn't see goes in `ctx.memory` / `ctx.history`, not here. Writing to any other absolute path (e.g. `~/.agent-sin/marketing/...`) is forbidden.",
         "- To call AI, first declare it in skill.yaml's `ai_steps` with `id / purpose / model` (optionally `optional: true`), then call `ctx.ai.run(id, payload)`. Ids that were not declared cannot be called.",
+        "- If a skill has local files that should be attached to the current chat reply, return their paths in `data.filePath` / `data.filePaths` (or `data.imagePath` / `data.imagePaths` for image-only results). The host will attach readable local files on Discord/Telegram. If an AI/helper response already contains local path strings, copy those strings into `data.filePaths` or pass them to `ctx.notify({ filePaths })`.",
+        "- If the user explicitly asks for Codex image generation, make the AI step instruction say to use `gpt-image-2` and to actually call the image generation tool, not just describe the image. Then read the returned local image path strings and pass them as `filePaths` / `imagePaths`.",
+        "- If the user asked for a separate notification, use `ctx.notify({ filePath })` / `ctx.notify({ filePaths })` instead of relying on the chat reply attachment.",
         "- Environment variables must be declared in skill.yaml's `required_env: [{name, description, optional}]`. The Runtime checks them before execution and blocks the run if any are missing.",
         "- For simple CRUD-style skills (add todo, list todos, mark done, etc.) where the result should be shown to the user verbatim, add `output_mode: raw` to skill.yaml. The summary then bypasses the LLM reformatting turn and is shown directly. Omit it when complex summarization/rewording is needed (the default behaviour lets the LLM format the result).",
         "- Do not write recurring schedules into skill.yaml (the builder must not touch schedules.yaml). Instead, tell the user that the finished skill can be scheduled by calling the `schedule-add` built-in skill from chat or CLI (`agent-sin run schedule-add --payload '{\"id\":\"...\",\"cron\":\"min hour dom month dow\",\"skill\":\"<this-skill>\"}'`). If the user prefers to edit manually, mention that they may add `- id / cron / skill / args / approve` to the `schedules:` list in `~/.agent-sin/schedules.yaml`.",
-        "- Writable paths are only inside cwd: `skill.yaml` / `main.py` or `main.ts` / `README.md` / `fixtures/` / `tests` / `prompts/`. As an exception, you may add or update only the keys this skill needs in `~/.agent-sin/.env`. Do not write anywhere else outside cwd.",
+        "- Writable paths are only inside cwd: `skill.yaml` / `main.py` or `main.ts` / `README.md` / `fixtures/` / `tests` / `prompts/`. As an exception, you may add or update only the keys this skill needs in `~/.agent-sin/.env`, and at runtime the skill may write user-visible markdown under `input.sources.skill_output_dir`. Do not write anywhere else outside cwd. `outputs` and `ctx.history` are handled by the Runtime — the skill never opens those files itself.",
         "- Reading is unrestricted: feel free to read from the agent-sin source or other skills. A useful reference implementation is `~/.agent-sin/skills/memo-save/`.",
         "- If you feel an urge to edit cross-cutting files (schedules.yaml, other skills, models.yaml, config.toml, etc.), do not touch them yourself. Add a one-line request in the completion report (\"please do XYZ\") and let the host handle it.",
         "",
@@ -945,6 +1049,7 @@ function stripBuilderArtifacts(text) {
         .replace(/```summary\s*\n([\s\S]*?)\n```/g, "$1")
         .replace(/```builder-files[^\n]*\n[\s\S]*?\n```/gi, "")
         .replace(/```file:[^\n]*\n[\s\S]*?\n```/g, "")
+        .replace(/```env\s*\n[\s\S]*?\n```/g, "")
         .trim();
 }
 async function listDraftFiles(draftDir) {

package/dist/builder/conversation-router.d.ts

@@ -1,7 +1,7 @@
 import { type ChatProgressEvent, type ChatTurn } from "../core/chat-engine.js";
 import type { AppConfig } from "../core/config.js";
 import type { AiImagePart, AiProgressHandler } from "../core/ai-provider.js";
-import { type IntentRuntime } from "./build-flow.js";
+import { type BuilderEventSource, type IntentRuntime } from "./build-flow.js";
 export interface BuildProgressReporter {
     onProgress: AiProgressHandler;
     flush(): Promise<void>;
@@ -11,12 +11,14 @@ export interface RouteConversationMessageOptions {
     text: string;
     history: ChatTurn[];
     intentRuntime: IntentRuntime;
-    eventSource: "discord" | "telegram";
+    eventSource: BuilderEventSource;
     images?: AiImagePart[];
     createBuildProgress(): BuildProgressReporter;
     onBuildStart?(): Promise<void>;
     onBuildDone?(): Promise<void>;
     onChatProgress?(event: ChatProgressEvent): void;
     onAiProgress?: AiProgressHandler;
+    onLocalAttachments?: (paths: string[]) => void;
+    onGeneratedImages?: (paths: string[]) => void;
 }
 export declare function routeConversationMessage(options: RouteConversationMessageOptions): Promise<string[]>;

package/dist/builder/conversation-router.js

@@ -1,5 +1,5 @@
 import { chatRespond, } from "../core/chat-engine.js";
-import { classifyPendingHandoff, enterBuildMode, handleBuildModeMessage, } from "./build-flow.js";
+import { classifyPendingHandoff, composeBuildSuggestionReply, enterBuildMode, handleBuildModeMessage, isExplicitBuildModeStartRequest, } from "./build-flow.js";
 import { l } from "../core/i18n.js";
 export async function routeConversationMessage(options) {
     const { config, text, history, intentRuntime, eventSource, images = [], } = options;
@@ -37,6 +37,7 @@ export async function routeConversationMessage(options) {
         // "discuss" → keep pending, fall through to chatRespond.
     }
     let modelFailed = false;
+    let buildSuggestion = null;
     const lines = await chatRespond(config, text, history, {
         eventSource,
         preferredSkillId: intentRuntime.preferred_skill_id || undefined,
@@ -48,12 +49,28 @@ export async function routeConversationMessage(options) {
             options.onChatProgress?.(event);
         },
         onAiProgress: options.onAiProgress,
-        onBuildSuggestion: (suggestion) => setPendingBuildSuggestion(intentRuntime, suggestion, text),
+        onLocalAttachments: options.onLocalAttachments || options.onGeneratedImages,
+        onBuildSuggestion: (suggestion) => {
+            buildSuggestion = suggestion;
+            setPendingBuildSuggestion(intentRuntime, suggestion, text);
+        },
     });
     intentRuntime.preferred_skill_id = null;
     if (modelFailed && lines.length === 0) {
         return [l("The model call failed.", "モデル呼び出しでエラーになりました。")];
     }
+    const suggestion = buildSuggestion;
+    if (suggestion && intentRuntime.pending && isExplicitBuildModeStartRequest(text)) {
+        await options.onBuildStart?.();
+        const buildProgress = options.createBuildProgress();
+        const buildLines = await enterBuildMode(config, history, intentRuntime, { onProgress: buildProgress.onProgress }, undefined, eventSource);
+        await buildProgress.flush();
+        await options.onBuildDone?.();
+        return buildLines;
+    }
+    if (suggestion && intentRuntime.pending) {
+        return composeBuildSuggestionReply(lines, suggestion.type);
+    }
     return lines;
 }
 function setPendingBuildSuggestion(intentRuntime, suggestion, userText) {