dominds 1.26.2 → 1.26.4

package/dist/server/dominds-self-update.js

@@ -9,6 +9,7 @@ exports.setDomindsSelfUpdateBroadcaster = setDomindsSelfUpdateBroadcaster;
 exports.getDomindsSelfUpdateStatus = getDomindsSelfUpdateStatus;
 exports.installLatestDominds = installLatestDominds;
 exports.restartDomindsIntoLatest = restartDomindsIntoLatest;
+exports.forceRestartDominds = forceRestartDominds;
 const child_process_1 = require("child_process");
 const crypto_1 = require("crypto");
 const promises_1 = __importDefault(require("fs/promises"));
@@ -1099,10 +1100,11 @@ async function getDomindsSelfUpdateStatus() {
         });
     }
     if (restartPromise !== null) {
+        const targetVersion = latestObservation.kind === 'ok' ? latestObservation.latestVersion : null;
         return buildStatus({
             currentVersion: runningVersion,
-            installedVersion: runningVersion,
-            latestVersion: latestObservation.kind === 'ok' ? latestObservation.latestVersion : null,
+            installedVersion: targetVersion ?? runningVersion,
+            latestVersion: targetVersion,
             checkedAt: latestObservation.kind === 'unknown' ? null : latestObservation.checkedAt,
             mode: cfg.mode,
             runKind,
@@ -1110,7 +1112,7 @@ async function getDomindsSelfUpdateStatus() {
             busy: 'restarting',
             reason: 'restart_required',
             message: 'Dominds restart is in progress',
-            targetVersion: latestObservation.kind === 'ok' ? latestObservation.latestVersion : null,
+            targetVersion,
         });
     }
     if (latestObservation.kind === 'unknown') {
@@ -1353,7 +1355,7 @@ async function requestSupervisorRestart(params) {
         debugDir: params.trace.debugDir,
         currentVersion: params.currentVersion,
         targetVersion: params.targetVersion,
-        runKind: params.runKind,
+        restartStrategy: params.restartStrategy,
     };
     await new Promise((resolve, reject) => {
         process.send?.(message, (error) => {
@@ -1422,6 +1424,69 @@ async function stopAndExitForRestart() {
     }
     process.exit(0);
 }
+async function requestDomindsRestart(params) {
+    const cfg = assertRuntimeConfig();
+    const runKind = detectRunKind(cfg.mode);
+    if (runKind === 'disabled') {
+        throw new Error('Dominds restart requires a production run kind');
+    }
+    restartState = { kind: 'restarting', targetVersion: params.targetVersion };
+    publishStatusUpdateSoon();
+    const restartCwd = process.cwd();
+    const trace = buildRestartTraceContext();
+    activeRestartTraceFile = trace.traceFile;
+    try {
+        await appendRestartTraceBestEffort(trace, params.traceEvent, {
+            runKind,
+            restartStrategy: params.restartStrategy,
+            currentVersion: params.currentVersion,
+            targetVersion: params.targetVersion,
+            restartCwd,
+            host: cfg.host,
+            port: cfg.port,
+            traceFile: trace.traceFile,
+        });
+        await requestSupervisorRestart({
+            trace,
+            restartStrategy: params.restartStrategy,
+            currentVersion: params.currentVersion,
+            targetVersion: params.targetVersion,
+        });
+        await appendRestartTraceBestEffort(trace, 'parent.supervisor_restart_requested', {
+            retiringPid: process.pid,
+            host: cfg.host,
+            port: cfg.port,
+        });
+        log.info('Dominds supervisor restart requested', undefined, {
+            traceFile: trace.traceFile,
+            forced: params.traceEvent === 'parent.force_restart_requested',
+            restartStrategy: params.restartStrategy,
+        });
+        setImmediate(() => {
+            void stopAndExitForRestart().catch((error) => {
+                void appendRestartTraceBestEffort(trace, 'parent.stop_and_exit.error', {
+                    message: error instanceof Error ? error.message : String(error),
+                    stack: error instanceof Error ? (error.stack ?? null) : null,
+                });
+                log.error('Failed to stop Dominds server during restart', error);
+                restartState = params.rollbackState;
+                activeRestartTraceFile = null;
+                publishStatusUpdateSoon();
+            });
+        });
+    }
+    catch (error) {
+        await appendRestartTraceBestEffort(trace, 'parent.restart_error', {
+            message: error instanceof Error ? error.message : String(error),
+            stack: error instanceof Error ? (error.stack ?? null) : null,
+        });
+        restartState = params.rollbackState;
+        activeRestartTraceFile = null;
+        publishStatusUpdateSoon();
+        throw error;
+    }
+    return await getDomindsSelfUpdateStatus();
+}
 async function restartDomindsIntoLatest() {
     const cfg = assertRuntimeConfig();
     if (cfg.mode !== 'production') {
@@ -1452,63 +1517,55 @@ async function restartDomindsIntoLatest() {
         else if (previousRestartRequiredState === null) {
             throw new Error('Dominds restart requires a completed install or a restartable session');
         }
-        restartState = { kind: 'restarting', targetVersion: status.targetVersion };
+        return await requestDomindsRestart({
+            traceEvent: 'parent.restart_requested',
+            restartStrategy: runKind === 'npx' ? 'npx_latest' : 'current_entrypoint',
+            currentVersion: status.currentVersion,
+            targetVersion: status.targetVersion,
+            rollbackState: previousRestartRequiredState ?? IDLE_RESTART_STATE,
+        });
+    })()
+        .catch((error) => {
+        const statusSnapshot = restartState.kind === 'restarting' ? restartState : null;
+        log.error('Dominds version restart failed', error, {
+            runKind: detectRunKind(cfg.mode),
+            restartState: statusSnapshot,
+        });
+        throw error;
+    })
+        .finally(() => {
+        restartPromise = null;
         publishStatusUpdateSoon();
-        const restartCwd = process.cwd();
-        const trace = buildRestartTraceContext();
-        activeRestartTraceFile = trace.traceFile;
-        try {
-            await appendRestartTraceBestEffort(trace, 'parent.restart_requested', {
-                runKind,
-                currentVersion: status.currentVersion,
-                targetVersion: status.targetVersion,
-                restartCwd,
-                host: cfg.host,
-                port: cfg.port,
-                traceFile: trace.traceFile,
-            });
-            await requestSupervisorRestart({
-                trace,
-                runKind,
-                currentVersion: status.currentVersion,
-                targetVersion: status.targetVersion,
-            });
-            await appendRestartTraceBestEffort(trace, 'parent.supervisor_restart_requested', {
-                retiringPid: process.pid,
-                host: cfg.host,
-                port: cfg.port,
-            });
-            log.info('Dominds supervisor restart requested', undefined, {
-                traceFile: trace.traceFile,
-            });
-            setImmediate(() => {
-                void stopAndExitForRestart().catch((error) => {
-                    void appendRestartTraceBestEffort(trace, 'parent.stop_and_exit.error', {
-                        message: error instanceof Error ? error.message : String(error),
-                        stack: error instanceof Error ? (error.stack ?? null) : null,
-                    });
-                    log.error('Failed to stop Dominds server during restart', error);
-                    restartState = previousRestartRequiredState ?? IDLE_RESTART_STATE;
-                    activeRestartTraceFile = null;
-                    publishStatusUpdateSoon();
-                });
-            });
-        }
-        catch (error) {
-            await appendRestartTraceBestEffort(trace, 'parent.restart_error', {
-                message: error instanceof Error ? error.message : String(error),
-                stack: error instanceof Error ? (error.stack ?? null) : null,
-            });
-            restartState = previousRestartRequiredState ?? IDLE_RESTART_STATE;
-            activeRestartTraceFile = null;
-            publishStatusUpdateSoon();
-            throw error;
-        }
+    });
+    return await restartPromise;
+}
+async function forceRestartDominds() {
+    const cfg = assertRuntimeConfig();
+    if (cfg.mode !== 'production') {
+        throw new Error('Dominds force restart is disabled in development mode');
+    }
+    if (installPromise !== null) {
+        throw new Error('Dominds force restart is blocked while installation is in progress');
+    }
+    if (restartPromise !== null) {
         return await getDomindsSelfUpdateStatus();
+    }
+    if (restartState.kind === 'restarting') {
+        return await getDomindsSelfUpdateStatus();
+    }
+    restartPromise = (async () => {
+        const runningVersion = getRunningVersion();
+        return await requestDomindsRestart({
+            traceEvent: 'parent.force_restart_requested',
+            restartStrategy: 'current_entrypoint',
+            currentVersion: runningVersion,
+            targetVersion: runningVersion,
+            rollbackState: IDLE_RESTART_STATE,
+        });
     })()
         .catch((error) => {
         const statusSnapshot = restartState.kind === 'restarting' ? restartState : null;
-        log.error('Dominds version restart failed', error, {
+        log.error('Dominds force restart failed', error, {
             runKind: detectRunKind(cfg.mode),
             restartState: statusSnapshot,
         });

package/dist/supervisor-protocol.d.ts

@@ -1,6 +1,5 @@
-import type { DomindsSelfUpdateRunKind } from '@longrun-ai/kernel/types';
 export declare const DOMINDS_SUPERVISOR_RESTART_WEBUI = "dominds.supervisor.restart_webui.v1";
-export type DomindsSupervisorRestartRunKind = Extract<DomindsSelfUpdateRunKind, 'global' | 'npx'>;
+export type DomindsSupervisorRestartStrategy = 'current_entrypoint' | 'npx_latest';
 export type DomindsSupervisorRestartWebuiMessage = Readonly<{
     type: typeof DOMINDS_SUPERVISOR_RESTART_WEBUI;
     cwd: string;
@@ -10,6 +9,6 @@ export type DomindsSupervisorRestartWebuiMessage = Readonly<{
     debugDir: string;
     currentVersion: string;
     targetVersion: string | null;
-    runKind: DomindsSupervisorRestartRunKind;
+    restartStrategy: DomindsSupervisorRestartStrategy;
 }>;
 export type DomindsRunnerToSupervisorMessage = DomindsSupervisorRestartWebuiMessage;

package/dist/tools/mcp.js

@@ -57,7 +57,7 @@ const mcpReleaseSchema = {
     properties: {
         serverId: {
             type: 'string',
-            description: "MCP server id from `.minds/mcp.yaml` (e.g., 'playwright'). Releases this dialog's current leased MCP runtime instance/process for that server.",
+            description: "MCP server id from `.minds/mcp.yaml` (e.g., 'playwright'). Releases this dialog's current leased MCP connection/process for that server.",
         },
     },
     required: ['serverId'],
@@ -68,7 +68,7 @@ const mcpDisableSchema = {
     properties: {
         serverId: {
             type: 'string',
-            description: "MCP server id from `.minds/mcp.yaml` (e.g., 'playwright'). Stops any loaded runtime/leases and writes servers.<id>.enabled=false.",
+            description: "MCP server id from `.minds/mcp.yaml` (e.g., 'playwright'). Stops any loaded MCP connection/leases and writes servers.<id>.enabled=false.",
         },
     },
     required: ['serverId'],
@@ -109,10 +109,10 @@ exports.mcpRestartTool = {
 exports.mcpReleaseTool = {
     type: 'func',
     name: 'mcp_release',
-    description: "Release this dialog's current leased MCP runtime instance for a server (stops the underlying process/connection).",
+    description: "Release this dialog's current leased MCP connection/process for a server.",
     descriptionI18n: {
-        en: "Release this dialog's current leased MCP runtime instance for a server (stops the underlying process/connection).",
-        zh: '释放当前对话为某个 server 持有的 MCP 运行时实例（停止底层进程/连接）。',
+        en: "Release this dialog's current leased MCP connection/process for a server.",
+        zh: '释放当前对话为某个 server 持有的 MCP 连接/进程。',
     },
     parameters: mcpReleaseSchema,
     argsValidation: 'dominds',
@@ -147,10 +147,10 @@ exports.mcpReleaseTool = {
 exports.mcpDisableTool = {
     type: 'func',
     name: 'mcp_disable',
-    description: 'Disable a configured MCP server, clear its loaded runtime/leases, and persist enabled=false in `.minds/mcp.yaml`.',
+    description: 'Disable a configured MCP server, clear its loaded MCP connection/leases, and persist enabled=false in `.minds/mcp.yaml`.',
     descriptionI18n: {
-        en: 'Disable a configured MCP server, clear its loaded runtime/leases, and persist enabled=false in `.minds/mcp.yaml`.',
-        zh: '禁用指定 MCP 服务器，清理其已加载运行时/租约，并在 `.minds/mcp.yaml` 中持久写入 enabled=false。',
+        en: 'Disable a configured MCP server, clear its loaded MCP connection/leases, and persist enabled=false in `.minds/mcp.yaml`.',
+        zh: '禁用指定 MCP 服务器，清理其已加载 MCP 连接/租约，并在 `.minds/mcp.yaml` 中持久写入 enabled=false。',
     },
     parameters: mcpDisableSchema,
     argsValidation: 'dominds',
@@ -210,18 +210,18 @@ exports.mcpLeaseReminderOwner = {
                 ? [
                     `${prefix} MCP 工具集租约 [${reminder.id}]: \`${serverId}\``,
                     '',
-                    `你当前看到的是系统维护的 MCP 租约状态。该 MCP server 被视为非“真正无状态”；当前对话持有一个 MCP 运行时实例（HTTP 连接或 stdio 进程）。`,
+                    `你当前看到的是系统维护的 MCP 租约状态。该 MCP server 被视为非“真正无状态”；当前对话持有一个 MCP 连接/进程（HTTP 连接或 stdio 进程）。`,
                     (0, driver_messages_1.formatAutoMaintainedReminderManualMirrorBan)(workLanguage),
                     '',
-                    `该提醒项只说明当前对话持有的运行时实例；它不决定该 server 的全局工具注册/可见性。`,
+                    `该提醒项只说明当前对话持有的连接/进程；它不决定该 server 的全局工具注册/可见性。`,
                 ].join('\n')
                 : [
                     `${prefix} MCP toolset lease [${reminder.id}]: \`${serverId}\``,
                     '',
-                    `You are looking at system-maintained MCP lease state. This MCP server is treated as non-stateless, and the current dialog holds one MCP runtime instance for it (an HTTP connection or stdio process).`,
+                    `You are looking at system-maintained MCP lease state. This MCP server is treated as non-stateless, and the current dialog holds one MCP connection/process for it (an HTTP connection or stdio process).`,
                     (0, driver_messages_1.formatAutoMaintainedReminderManualMirrorBan)(workLanguage),
                     '',
-                    `This reminder only describes the runtime instance held by the current dialog; it does not determine global tool registration/visibility for that server.`,
+                    `This reminder only describes the connection/process held by the current dialog; it does not determine global tool registration/visibility for that server.`,
                 ].join('\n'),
         };
     },

package/dist/tools/prompts/control/en/index.md

@@ -29,7 +29,7 @@ control is Dominds' **dialog control toolset** for managing dialog state, remind
 - **Reminder management**: Three reminder scopes: `dialog` / `task` / `agent`. Default to `task` for current work under the same Taskdoc; use `dialog` only for truly dialog-local notes; use `agent` only for urgent, short-lived, globally visible cues
 - **Taskdoc operations**: Append to, replace, or delete task contract sections (goals/constraints/progress); within Taskdoc, `progress` is the team-shared, quasi-real-time, scannable task bulletin board
 - **Context maintenance**: Reduce cognitive load without losing key resume state
-- **Reply routing**: Separate `tellaskBack`, `replyTellask*`, and plain text by responsibility in Side Dialog / ask-back flows
+- **Reply routing**: Separate asking the tellasker back, sending the final reply, and ordinary plain text in Side Dialog / ask-back flows
 
 ## Quick Navigation
 
@@ -58,7 +58,7 @@ Reminders are temporary current-work information for:
 - Recording blocking issues
 - Holding continuation-package bridge notes before `clear_mind`
 
-Reminders are not for manually copying Dominds runtime-maintained environment state, such as background process status, in-flight background asks/collaboration, or browser/session attachment state. Runtime-managed reminders, panels, and tool outputs are the single source of truth; manual notes go stale easily and create cognitive noise.
+Reminders are not for manually copying environment state automatically maintained by Dominds, such as background process status, in-flight background asks/collaboration, or browser/session attachment state. Dominds-managed reminders, panels, and tool outputs are the authoritative place for that state; manual notes go stale easily and create cognitive noise.
 
 Scope rule:
 

package/dist/tools/prompts/control/en/principles.md

@@ -42,7 +42,7 @@ Default to `task`. Use `dialog` only when the note is truly dialog-local; use `a
 - `agent` reminders stay visible in all later dialogs you lead
 - Can be added, modified, or deleted at any time
 - Should stay compact, scannable, and directly actionable by default
-- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates a structured continuation-package reminder; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. If the current course is already under system remediation, Side Dialog reminder length has no technical limit and rough multi-reminder carry-over is acceptable
+- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates a structured continuation-package reminder; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. If Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough multi-reminder carry-over is acceptable
 
 **Difference from memory:**
 | Feature | dialog reminder | task reminder | agent reminder | personal memory |
@@ -104,17 +104,17 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 - Do not treat an agent teammate like a human coworker who can only handle one conversation at a time. Same teammate + same `sessionSlug` = continue the same task and update that task; `tellaskSessionless` or a different `sessionSlug` = another independent task
 - Call `tellaskBack({ tellaskContent })` only when the tellasker must clarify the request, decide a tradeoff, confirm acceptance criteria, provide missing input, or current SOP cannot determine ownership
 - If a human must personally perform login / GUI / captcha / high-risk authorization: call `askHuman({ tellaskContent })`
-- If the current Side Dialog is complete and the assignment header says `replyTellask`: call `replyTellask({ replyContent })`
-- If the current Side Dialog is complete and the assignment header says `replyTellaskSessionless`: call `replyTellaskSessionless({ replyContent })`
-- If you are answering a tellasker `tellaskBack` follow-up and runtime exposes `replyTellaskBack`: call `replyTellaskBack({ replyContent })`
-- Plain text is not the completion channel for inter-dialog delivery; if you produce final deliverable content instead of the reply tool, runtime may temporarily inject a `role=user` reminder telling you to use the correct reply function. Do not rely on direct-reply fallback; it is only a temporary runtime transition safeguard, not the formal reply mechanism
+- If the current Side Dialog is complete and the task header says `replyTellask`: call `replyTellask({ replyContent })`
+- If the current Side Dialog is complete and the task header says `replyTellaskSessionless`: call `replyTellaskSessionless({ replyContent })`
+- If you are answering a tellasker `tellaskBack` follow-up and Dominds shows `replyTellaskBack`: call `replyTellaskBack({ replyContent })`
+- Plain text is not the completion channel for inter-dialog delivery. If you write final content for the requester but do not send it through the reply tool named by Dominds, Dominds may temporarily remind you to use that tool. Do not treat plain text as the formal reply path; the other dialog may not receive a formal reply that way.
 
 ### Low-Burden Rule
 
-- Focus on doing the current task correctly first; use `reply*` only when final tellasker delivery is actually ready
-- Do not memorize reply variants by yourself; follow the current assignment header and the function currently exposed by runtime
-- `reply*` tool descriptions are intentionally minimal and spec-like; use this manual's principles / scenarios for situational guidance
-- If runtime exposes only one `reply*`, that is the only correct completion path for the current state
+- Focus on doing the current task correctly first; send the final reply only when the final content is ready and Dominds names a reply tool
+- Do not memorize reply variants by yourself; follow the current task header and the reply tool currently named/shown by Dominds
+- Reply tool descriptions are intentionally minimal and spec-like; use this manual's principles / scenarios for situational guidance
+- If Dominds names/shows only one reply tool, that is the only correct completion path for the current state
 - `tellaskBack` is valid only when ownership cannot be determined from existing SOP, or when the tellasker must answer; it is not the default first move for every blocked state
 
 ## Best Practices
@@ -137,10 +137,10 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 
 - Keep concise: reminders are often 1-3 items; prefer `update_reminder` to compress/merge
 - Separate carriers: information that must synchronize the team's current effective state, key decisions, next steps, or still-active blockers belongs in `progress`, the quasi-real-time task bulletin board; reminders keep local resume details
-- Do not duplicate system state: background process status, in-flight background asks/collaboration, browser/session attachment state, and similar Dominds runtime-maintained environment state do not belong in manual reminders. Runtime-managed reminders, panels, and tool outputs are the single source of truth; manual copies go stale easily and create cognitive noise
+- Do not duplicate system state: background process status, in-flight background asks/collaboration, browser/session attachment state, and similar environment state automatically maintained by Dominds do not belong in manual reminders. Dominds-managed reminders, panels, and tool outputs are the authoritative place for that state; manual copies go stale easily and create cognitive noise
 - Team-facing: keep `progress` scannable and centered on what is still effective now; do not let it degrade into a personal log, raw chronology, scratchpad, or stale history pile. Use `mind_more` for small additions; when cleanup/reordering/compression is needed, call `recall_taskdoc` first and then use `change_mind` with the returned `content_hash` as `previous_content_hash`
 - Condense when needed: `mind_more` is not the default bookkeeping move. If one topic already has several phase notes, prefer `change_mind` to merge them into the current summary; put the detailed expansion in formal rtws documentation and keep a document pointer in Taskdoc. If the replacement would overwrite existing content, proceed only with direct human confirmation or after applying a human-approved SOP/acceptance standard that considers the existing content
-- Collapse before clearing: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then creates a structured continuation-package reminder; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders. If the current course is already under system remediation, rough multi-reminder carry-over is acceptable but must be reconciled first in the new course
+- Collapse before clearing: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then creates a structured continuation-package reminder; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders. If Dominds has already warned that context is tight or critical, rough multi-reminder carry-over is acceptable but must be reconciled first in the new course
 - Avoid raw-material dumps: do not paste long logs or large tool outputs into reminders
 - Documentation layering: Taskdoc says “what the team should sync on / do next now”; formal rtws documentation carries “why, how, detailed evidence, and the full process”. When Taskdoc references formal rtws documentation, use a stable path/section name/relevant command instead of copying the full content
 
@@ -164,5 +164,5 @@ Taskdoc is a **task contract** and the task's **team-shared source of current tr
 1. `dialog` reminders end with the dialog; `task` reminders stay visible under the current Taskdoc; `agent` reminders stay visible in all later dialogs you lead
 2. Use `do_mind` to create missing Taskdoc sections; use `mind_more` for small Taskdoc additions; use `change_mind` for full-section replacement of existing sections only after merging existing content and calling `recall_taskdoc` for the current `content_hash`; use `never_mind` when a whole section file should be deleted. Do not treat `mind_more` as a chronology tool; when cleanup, stale-entry removal, or same-topic consolidation is needed, use `recall_taskdoc` then `change_mind`
 3. `do_mind` / `mind_more` / `change_mind` / `never_mind` do not start a new course
-4. A continuation-package reminder should keep only details still not covered by Taskdoc but easy to lose during resume; in the Main Dialog, undocumented discussion details from current dialog history that the next course needs to know should be written to the appropriate Taskdoc sections first; in a Side Dialog under caution/critical remediation, maintain sufficiently detailed continuation-package reminders only
+4. A continuation-package reminder should keep only details still not covered by Taskdoc but easy to lose during resume; in the Main Dialog, undocumented discussion details from current dialog history that the next course needs to know should be written to the appropriate Taskdoc sections first; in a Side Dialog after Dominds warns that context is tight or critical, maintain sufficiently detailed continuation-package reminders only
 5. Do not turn `task` / `agent` reminders into a long-term fact dump; move durable knowledge into `personal_memory`

package/dist/tools/prompts/control/en/scenarios.md

@@ -57,11 +57,11 @@ delete_reminder({
 - If the information should synchronize the whole team's current effective state, put it in Taskdoc `progress` instead
 - If the note is durable knowledge rather than an active current-work cue, move it to `personal_memory` instead
 
-## Scenario 2: Side Dialog is complete, and the assignment header requires replyTellask
+## Scenario 2: Side Dialog is complete, and the task header requires replyTellask
 
 ### Scenario Description
 
-The current Side Dialog is finished, and the assignment header explicitly says "when complete, call `replyTellask`".
+The current Side Dialog is finished, and the task header explicitly says "when complete, call `replyTellask`".
 
 ### Example
 
@@ -74,7 +74,7 @@ replyTellask({
 
 ### Key Points
 
-- Do not replace this with a plain final message; direct-reply fallback is only a temporary runtime transition safeguard, not a valid planned completion method
+- Do not replace this with a plain final message; formal delivery must use the reply tool named by Dominds, or the other dialog may not receive a formal reply
 - Put the final deliverable body directly in `replyContent`
 - If the header says `replyTellaskSessionless`, use the same shape with that exact function name
 
@@ -97,13 +97,13 @@ tellaskBack({
 
 - This example uses `tellaskBack` because tellasker input is specifically required
 - If team SOP / role ownership already identifies the responsible executor, directly use `tellask` / `tellaskSessionless` for that owner instead of mapping every unfinished state to `tellaskBack`
-- Do not use `replyTellask*` for intermediate clarifications
+- Do not use reply tools for intermediate clarifications
 
 ## Scenario 4: Tellasker answered the ask-back, so use replyTellaskBack to close
 
 ### Scenario Description
 
-You previously sent a `tellaskBack`, the tellasker has now replied, and runtime exposes `replyTellaskBack`.
+You previously sent a `tellaskBack`, the tellasker has now replied, and Dominds shows `replyTellaskBack`.
 
 ### Example
 

package/dist/tools/prompts/control/en/tools.md

@@ -23,7 +23,7 @@
 
 The **tool descriptions themselves** for these functions intentionally stay minimal and spec-like. This section carries the smallest practical lookup for when they appear and how to choose among them.
 
-| Function                  | Minimal parameter contract   | When runtime exposes it                                                                                     | Effect                                                         |
+| Function                  | Minimal parameter contract   | When Dominds shows it                                                                                       | Effect                                                         |
 | ------------------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
 | `replyTellask`            | `{ replyContent: string }`   | Current Side Dialog comes from a sessioned `tellask` and is ready for final delivery                        | Delivers the final result for the current tellask session      |
 | `replyTellaskSessionless` | `{ replyContent: string }`   | Current Side Dialog comes from a one-shot `tellaskSessionless` and is ready for final delivery              | Delivers the final result for the current one-shot tellask     |
@@ -32,11 +32,11 @@ The **tool descriptions themselves** for these functions intentionally stay mini
 
 ### Minimal Usage Rules
 
-- Focus on doing the current task correctly first; only move into `reply*` closure when final tellasker delivery is actually ready
-- Call whichever `reply*` runtime currently exposes; do not switch to another reply variant by yourself
-- If the assignment header explicitly names a reply function, follow that exact name
+- Focus on doing the current task correctly first; send the final reply only when the final content is ready and Dominds names a reply tool
+- Call whichever reply tool Dominds currently shows; do not switch to another reply tool by yourself
+- If the task header explicitly names a reply tool, follow that exact name
 - Put only the final deliverable body in `replyContent`; do not wrap it in meta-explanations like "I am now calling replyTellask"
-- If you produce final deliverable content instead of the reply tool, runtime may inject a temporary `role=user` reminder telling you to use the correct reply function; do not rely on direct-reply fallback, which is only a temporary runtime transition safeguard, not the formal reply mechanism
+- If you write final deliverable content but do not send it through the reply tool named by Dominds, Dominds may temporarily remind you to use that tool; do not treat plain text as the formal reply path, because the other dialog may not receive a formal reply that way
 
 ### 1. add_reminder
 
@@ -45,8 +45,8 @@ Add reminder.
 Use when:
 
 - Adding a new temporary current-work item
-- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates continuation-package notes; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. When the current course is already under caution/critical remediation, Side Dialog reminder length has no technical limit and rough bridge notes are acceptable
-- Record only manually maintained current-work / continuation details; do not put runtime-maintained environment state such as background process status, in-flight background asks, or session attachment state into manual reminders
+- Before `clear_mind`, the Main Dialog first records undocumented discussion details the next course needs to know into Taskdoc, then creates continuation-package notes; a Side Dialog directly maintains sufficiently detailed continuation-package reminders. When Dominds has already warned that context is tight or critical, Side Dialog reminders have no fixed length limit and rough bridge notes are acceptable
+- Record only manually maintained current-work / continuation details; do not put environment state automatically maintained by Dominds, such as background process status, in-flight background asks, or session attachment state, into manual reminders
 
 **Parameters:**
 
@@ -92,7 +92,7 @@ Use when:
 - Compressing / merging existing reminders
 - Rewriting pre-clear resume info into continuation-package notes
 - Removing details that have already been promoted into Taskdoc
-- Removing or rewriting system environment state that was mistakenly captured in a manual reminder; runtime-managed reminders, panels, and tool outputs are the single source of truth for that state
+- Removing or rewriting system environment state that was mistakenly captured in a manual reminder; Dominds-managed reminders, panels, and tool outputs are the authoritative place for that state
 
 **Parameters:**
 
@@ -360,7 +360,7 @@ message: <error message>
 
 - Normal reminders should stay concise, fresh, and directly actionable; often 1-3 items total
 - For a continuation package, use structured notes by default: next step, key pointers, run/verify, easy-to-lose volatile details
-- If the current course is already under caution/critical remediation: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then keeps necessary continuation-package reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders with no technical length limit. Rough multi-reminder bridge notes are acceptable and should be reconciled as the first step only after the system actually starts the new course
+- If Dominds has already warned that context is tight or critical: the Main Dialog first records undocumented discussion details the next course needs to know into the appropriate Taskdoc sections, then keeps necessary continuation-package reminders; a Side Dialog must not maintain Taskdoc or draft Taskdoc update proposals, and should directly maintain sufficiently detailed continuation-package reminders with no fixed length limit. Rough multi-reminder bridge notes are acceptable and should be reconciled as the first step only after Dominds actually starts the new course
 - Keep only details still not covered by Taskdoc; do not repeat team-shared status. If the team needs “where we are now / which decisions are in effect / what is next / which blockers still hold”, write it back to Taskdoc `progress`
-- Do not manually record Dominds runtime-maintained environment state, such as whether background processes are still running, in-flight background asks/collaboration, or browser/session attachment state. Manual copies go stale easily and conflict with the runtime-maintained single source of truth, creating cognitive noise
+- Do not manually record environment state automatically maintained by Dominds, such as whether background processes are still running, in-flight background asks/collaboration, or browser/session attachment state. Manual copies go stale easily and conflict with the Dominds-managed status, creating cognitive noise
 - Do not paste long logs, large tool outputs, or raw material into reminders

package/dist/tools/prompts/control/zh/index.md

@@ -29,7 +29,7 @@ control 是 Dominds 的**对话控制工具集**，用于管理对话状态、
 - **提醒管理**：提醒分 `dialog` / `task` / `agent` 三个 scope；默认是 `task`，用于同一差遣牒任务下的手头工作；`dialog` 只用于真正对话局部的提醒；`agent` 只用于紧急、短期、全局刺眼提醒
 - **差遣牒操作**：追加、替换或删除任务契约章节（goals/constraints/progress）；其中 `progress` 是全队共享、准实时、可扫读的任务公告牌
 - **上下文维护**：在不丢关键恢复线索的前提下降低认知负载
-- **回复路由**：在支线/回问语境下，区分 `tellaskBack`、`replyTellask*` 与普通文本的职责边界
+- **回复路由**：在支线/回问语境下，区分回问诉请者、发送最终回贴与普通文本的职责边界
 
 ## 快速导航
 
@@ -56,9 +56,9 @@ control 是 Dominds 的**对话控制工具集**，用于管理对话状态、
 - 标记待处理事项
 - 追踪当前下一步/阻塞
 - 记录阻塞问题
-- 在 `clear_mind` 前承载接续包；若当前程已被系统置于吃紧/告急处置态，可先带多条粗略提醒项过桥
+- 在 `clear_mind` 前承载接续包；若 Dominds 已提醒当前程吃紧/告急，可先带多条粗略提醒项过桥
 
-提醒不用于手工复制 Dominds 系统环境会自动维护的状态，例如后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等。这些状态以 runtime 自动维护的提醒/面板/工具输出为 single source of truth；手工记录很容易过时并造成认知干扰。
+提醒不用于手工复制 Dominds 会自动维护的系统状态，例如后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等。这些状态以 Dominds 自动维护的提醒、面板和工具输出为准；手工记录很容易过时并造成认知干扰。
 
 scope 规则：
 

package/dist/tools/prompts/control/zh/principles.md

@@ -42,7 +42,7 @@
 - `agent` 提醒会在所有由你主理的后续对话里继续可见
 - 可随时添加、修改、删除
 - 默认应保持少量、可扫读、可直接指导下一步
-- 准备 `clear_mind` 时，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再压缩成结构化接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若当前程已被系统置于吃紧/告急处置态，支线提醒项长度没有技术限制，也可先保留多条粗略提醒项过桥
+- 准备 `clear_mind` 时，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再压缩成结构化接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，也可先保留多条粗略提醒项过桥
 
 **与 memory 的区别：**
 | 特性 | dialog reminder | task reminder | agent reminder | personal memory |
@@ -103,17 +103,17 @@
 - 不要把智能体队友当成真人同事：祂不会因为你又发一条诉请而被打扰。同一个队友 + 同一个 `sessionSlug` = 接着同一件事说，并更新那件正在做的事；`tellaskSessionless` 或不同 `sessionSlug` = 另一件独立任务
 - 只有当必须向诉请者补需求、澄清目标、裁决取舍、确认验收口径、提供缺失输入，或现有规程无法明确判责时：调用 `tellaskBack({ tellaskContent })`
 - 需要人类亲自登录 / GUI / 验证码 / 高风险授权时：调用 `askHuman({ tellaskContent })`
-- 当前支线已经完成，且当前 assignment 明确要求 `replyTellask`：调用 `replyTellask({ replyContent })`
-- 当前支线已经完成，且当前 assignment 明确要求 `replyTellaskSessionless`：调用 `replyTellaskSessionless({ replyContent })`
-- 当前是在回复一条诉请者发来的 `tellaskBack` 续诉请，且 runtime 暴露了 `replyTellaskBack`：调用 `replyTellaskBack({ replyContent })`
-- 普通文本不是跨对话完成交付通道；如果你直接产出可作为最终回贴的内容而没调 reply 工具，runtime 可能临时插入一条 `role=user` 的提醒要求你改用正确的 reply 函数。不要依赖 direct-reply fallback；它只是运行时临时过渡兜底，不是正式回复机制
+- 当前支线已经完成，且当前任务开头明确要求 `replyTellask`：调用 `replyTellask({ replyContent })`
+- 当前支线已经完成，且当前任务开头明确要求 `replyTellaskSessionless`：调用 `replyTellaskSessionless({ replyContent })`
+- 当前是在回复一条诉请者发来的 `tellaskBack` 续诉请，且 Dominds 显示了 `replyTellaskBack`：调用 `replyTellaskBack({ replyContent })`
+- 普通文本不是跨对话完成交付通道；如果你直接写出了可回给诉请者的最终内容但没按 Dominds 点名的回复工具发送，Dominds 可能临时提醒你改用那个工具。不要把普通文本当成正式回贴路径；对方可能收不到正式回贴。
 
 ### 心智负担最小化规则
 
-- 先专注把当前任务做对；`reply*` 只在最终对诉请者交付时用于收口
-- 不要靠记忆硬选 reply 变体；以当前 assignment 头部和 runtime 当前暴露的函数名为准
-- `reply*` 函数自身说明文案故意保持极简，只承载最小规格；情景判断看本手册的 principles / scenarios
-- 若 runtime 只暴露一个 `reply*`，那就是当前应调用的唯一完成路径
+- 先专注把当前任务做对；只有最终内容准备好、且 Dominds 点名了回复工具时，才发送最终回贴
+- 不要靠记忆硬选回复工具；以当前任务开头和 Dominds 当前点名/显示的回复工具为准
+- 回复工具自身说明文案故意保持极简，只承载最小规格；情景判断看本手册的 principles / scenarios
+- 若 Dominds 只点名/显示一个回复工具，那就是当前应调用的唯一完成路径
 - `tellaskBack` 只在“无法按现有规程明确判责，或必须回问诉请者”时成立，不是所有阻塞的默认第一动作
 
 ## 最佳实践
@@ -122,7 +122,7 @@
 
 - **当前手头工作**：当前下一步、阻塞、关键定位信息
 - **易丢细节**：临时路径、id、命令、样例输入
-- **换程接续**：在 `clear_mind` 前整理接续包；若当前程已被系统置于吃紧/告急处置态，可先保留多条粗略提醒项
+- **换程接续**：在 `clear_mind` 前整理接续包；若 Dominds 已提醒当前程吃紧/告急，可先保留多条粗略提醒项
 - **任务延续提示**：如果在当前差遣牒任务内都应该继续看到它，用 `task`
 - **全局刺眼提示**：如果它应该在所有由你主理的后续对话里继续看到，而且是短期、紧急、全局刺眼提醒，用 `agent`
 
@@ -136,10 +136,10 @@
 
 - 保持简洁：默认提醒项常见 1–3 条，优先 `update_reminder` 压缩/合并
 - 区分载体：需要向全队同步的当前有效状态、关键决策、下一步与仍成立阻塞，写入 `progress` 这一准实时任务公告牌；提醒项只留个人/当前对话恢复所需细节
-- 避免重复系统状态：后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等 Dominds 系统环境会自动维护的信息，不要写进手工提醒项；这些状态以 runtime 自动维护的提醒/面板/工具输出为 single source of truth，手工副本容易过时并造成认知干扰
+- 避免重复系统状态：后台进程状态、后台进行中诉请/协作、浏览器/会话附件状态等 Dominds 会自动维护的信息，不要写进手工提醒项；这些状态以 Dominds 自动维护的提醒、面板和工具输出为准，手工副本容易过时并造成认知干扰
 - 面向全队：`progress` 应保持可扫读、以“当前仍有效”为准，不要退化成个人日志、流水账、临时便签或历史残影堆积；少量新增用 `mind_more`，需要清旧/重排/压缩时先调用 `recall_taskdoc`，再用 `change_mind` 并携带返回的 `content_hash` 作为 `previous_content_hash`
 - 按需整理：`mind_more` 不是默认记账动作。若同一主题已有多条阶段性记录，优先用 `change_mind` 合并成当前摘要；把细节放进 rtws 正式文档，并在差遣牒里保留文档定位 pointer。若会冲掉原有内容，必须有直接人类确认，或已按人类认可 SOP/验收标准充分考虑原有内容后再改写
-- 换程前收束：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再整理结构化接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项。若系统已把当前程切到吃紧/告急处置态，则先保留多条粗略提醒项过桥也可以；当前程只做落文档/保信息 + `clear_mind`（支线只做保信息 + `clear_mind`），系统真正开启新一程后第一步再收敛
+- 换程前收束：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再整理结构化接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，则先保留多条粗略提醒项过桥也可以；当前程只做落文档/保信息 + `clear_mind`（支线只做保信息 + `clear_mind`），Dominds 真正开启新一程后第一步再收敛
 - 拒绝原料堆积：不要把长日志/大段 tool output 直接塞进提醒项
 - 文档分层：差遣牒写“现在应如何同步/推进”，正式文档写“为什么、怎么做、详细证据和完整过程”。差遣牒需要引用正式文档时，写稳定路径/章节名/相关命令，而不是复制整段内容
 

package/dist/tools/prompts/control/zh/scenarios.md

@@ -57,11 +57,11 @@ delete_reminder({
 - 如果信息需要向全队同步当前有效状态、关键决策、下一步或仍成立阻塞，应写入 Taskdoc `progress`
 - 如果内容本质上是长期知识而不是当前手头工作提示，应改存到 `personal_memory`
 
-## 场景 2：支线已完成，按 assignment 头部要求调用 replyTellask
+## 场景 2：支线已完成，按任务开头要求调用 replyTellask
 
 ### 场景描述
 
-当前支线处理完毕，assignment 头部明确写着“完成任务时必须调用 `replyTellask`”。
+当前支线处理完毕，任务开头明确写着“完成任务时必须调用 `replyTellask`”。
 
 ### 示例
 
@@ -73,9 +73,9 @@ replyTellask({
 
 ### 关键点
 
-- 不要再发一条普通最终消息代替；direct-reply fallback 只是运行时临时过渡兜底，不是可规划使用的收口方式
+- 不要再发一条普通最终消息代替；正式回贴必须走 Dominds 点名的回复工具，否则对方可能收不到正式回贴
 - `replyContent` 直接放最终交付正文
-- 若 assignment 头部写的是 `replyTellaskSessionless`，则同结构替换函数名
+- 若任务开头写的是 `replyTellaskSessionless`，则同结构替换函数名
 
 ## 场景 3：当前未完成，需要回问诉请者
 
@@ -90,20 +90,20 @@ tellaskBack({
   tellaskContent: '还缺少生产环境端口与部署入口信息。请补充这两项后我再继续给出最终方案。',
 });
 
-// 等诉请者补充后，runtime 会在当前对话里继续推进
+// 等诉请者补充后，Dominds 会在当前对话里继续推进
 ```
 
 ### 关键点
 
 - 这里只是“必须向诉请者补输入”的例子，所以用 `tellaskBack`
 - 若团队规程 / SOP / 职责卡已经能明确执行负责人，应直接 `tellask` / `tellaskSessionless` 对应负责人，而不是机械因为“未完成态”就用 `tellaskBack`
-- `tellaskBack` 只负责把问题问回去，不负责最终交付
+- `tellaskBack` 只负责把问题问回去，不负责最终交付；中间澄清不要调用回复工具
 
 ## 场景 4：收到 ask-back 续诉请后，用 replyTellaskBack 收口
 
 ### 场景描述
 
-你之前发过 `tellaskBack`，诉请者现在补回了所需信息，runtime 暴露了 `replyTellaskBack`。
+你之前发过 `tellaskBack`，诉请者现在补回了所需信息，Dominds 显示了 `replyTellaskBack`。
 
 ### 示例