dominds 1.26.1 → 1.26.3

package/dist/server.js

@@ -121,16 +121,16 @@ async function startServer(opts = {}) {
     }
     const tls = certificateLookup.kind === 'found' && !strictPort ? certificateLookup.certificate : undefined;
     const urlHost = (0, network_hosts_1.resolveHttpUrlHostForBindHost)(host);
-    log.info(`Starting server in ${mode} mode on ${(0, auth_1.formatServerOrigin)({
+    log.debug(`Starting server in ${mode} mode on ${(0, auth_1.formatServerOrigin)({
         scheme: 'http',
         host: urlHost,
         port: preferredPort,
     })} (bind ${host}; ${strictPort ? 'strict port' : `auto port ${portAutoDirection}`}; working language: ${(0, work_language_1.getWorkLanguage)()} from ${source})`);
     if (certificateLookup.kind === 'found' && strictPort) {
-        log.info(`HTTPS certificate found but Dominds HTTPS is disabled for strict --port; assuming HTTPS, if needed, is handled by a front proxy (${certificateLookup.certificate.certPath})`);
+        log.debug(`HTTPS certificate found but Dominds HTTPS is disabled for strict --port; assuming HTTPS, if needed, is handled by a front proxy (${certificateLookup.certificate.certPath})`);
     }
     else if (tls !== undefined) {
-        log.info(`HTTPS certificate available: ${tls.certPath} (matched host ${tls.matchedHost})`);
+        log.debug(`HTTPS certificate available: ${tls.certPath} (matched host ${tls.matchedHost})`);
     }
     let startedCore = null;
     let boundPort = null;
@@ -208,7 +208,7 @@ async function startServer(opts = {}) {
             await startedCore.stop();
             throw new Error(`Failed to start WebUI HTTPS: no available adjacent port found from ${preferredHttpsPort}`);
         }
-        log.info(`HTTPS WebUI ready: ${(0, auth_1.formatServerOrigin)({
+        log.debug(`HTTPS WebUI ready: ${(0, auth_1.formatServerOrigin)({
             scheme: 'https',
             host: httpsUrlHost,
             port: httpsPort,

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`。
 
 ### 示例
 

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

@@ -23,7 +23,7 @@
 
 这些函数的**工具自身说明**刻意保持最小规格风格；这里负责补充“何时会出现、出现后怎么选”的最小速查。
 
-| 函数                      | 最小参数契约                 | runtime 何时暴露                                                     | 调用后语义                          |
+| 函数                      | 最小参数契约                 | Dominds 何时显示                                                     | 调用后语义                          |
 | ------------------------- | ---------------------------- | -------------------------------------------------------------------- | ----------------------------------- |
 | `replyTellask`            | `{ replyContent: string }`   | 当前支线承接的是 sessioned `tellask`，且已进入可交付完成态           | 把最终结果回复给当前 `tellask` 会话 |
 | `replyTellaskSessionless` | `{ replyContent: string }`   | 当前支线承接的是 one-shot `tellaskSessionless`，且已进入可交付完成态 | 把最终结果回复给当前一次性诉请      |
@@ -32,11 +32,11 @@
 
 ### 最小使用规则
 
-- 先专注把当前任务做对；只有真到最终对诉请者交付时，才进入 `reply*` 收口
-- 看见哪一个 `reply*` 被 runtime 暴露，就调用哪一个；不要自行改选别的 reply 变体
-- assignment 头部若已点名 reply 函数名，以那个名字为准
+- 先专注把当前任务做对；只有最终内容准备好、且 Dominds 点名了回复工具时，才发送最终回贴
+- 看见 Dominds 当前显示哪一个回复工具，就调用哪一个；不要自行改选别的回复工具
+- 任务开头若已点名回复工具名，以那个名字为准
 - `replyContent` 只放最终交付正文，不要再包一层“我现在调用了 replyXXX”
-- 如果你直接产出最终回贴内容而没调 reply 工具，runtime 可能插入一条 `role=user` 的 runtime reminder 纠正你；不要依赖 direct-reply fallback，它只是运行时临时过渡兜底，不是正式回复机制
+- 如果你直接写出了最终回贴内容但没按 Dominds 点名的回复工具发送，Dominds 可能临时提醒你改用那个工具；不要把普通文本当成正式回贴路径，对方可能收不到正式回贴
 
 ### 1. add_reminder
 
@@ -45,8 +45,8 @@
 **适用：**
 
 - 添加新的临时手头工作条目
-- 若准备 `clear_mind`，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再新建接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若当前程已被系统置于吃紧/告急处置态，支线提醒项长度没有技术限制，先记粗略过桥信息也可以
-- 只记录需要你手工维护的手头工作/接续细节；不要在手工提醒项里记录后台进程状态、后台进行中诉请、会话附件状态等 Dominds 系统环境会自动维护的信息
+- 若准备 `clear_mind`，主线对话先把应由下一程知会的未落文档讨论细节补进差遣牒，再新建接续包提醒项；支线对话直接维护足够详尽的接续包提醒项。若 Dominds 已提醒上下文吃紧/告急，支线提醒项没有固定长度限制，先记粗略过桥信息也可以
+- 只记录需要你手工维护的手头工作/接续细节；不要在手工提醒项里记录后台进程状态、后台进行中诉请、会话附件状态等 Dominds 会自动维护的信息
 
 **参数：**
 
@@ -90,9 +90,9 @@ deleted_at: <删除时间戳>
 **适用：**
 
 - 压缩/合并现有提醒项
-- 把换程前需要保留的信息整理成接续包；若当前程已被系统置于吃紧/告急处置态，也可先保留多条粗略提醒项
+- 把换程前需要保留的信息整理成接续包；若 Dominds 已提醒当前程吃紧/告急，也可先保留多条粗略提醒项
 - 删除已写入差遣牒、无需在提醒项重复保留的内容
-- 删除/改写手工提醒项里误记录的系统环境状态；这类状态以 runtime 自动维护的提醒/面板/工具输出为 single source of truth
+- 删除/改写手工提醒项里误记录的系统环境状态；这类状态以 Dominds 自动维护的提醒、面板和工具输出为准
 
 **参数：**
 
@@ -353,7 +353,7 @@ message: <错误消息>
 
 - 默认提醒项应保持短、新、能直接指导下一步，常见 1–3 条
 - 若用于接续包，默认优先结构化内容：下一步行动、关键定位、运行/验证、容易丢的临时细节
-- 若已吃紧/告急：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再保留必要的接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项，长度没有技术限制；多条粗略提醒项也可以，系统真正开启新一程后第一步再收敛整理
+- 若 Dominds 已提醒上下文吃紧/告急：主线对话先把尚未落实到文档、且下一程需要知会的讨论细节写入差遣牒合适章节，再保留必要的接续包提醒项；支线对话不要维护差遣牒，也不要整理差遣牒更新提案，直接维护足够详尽的接续包提醒项，没有固定长度限制；多条粗略提醒项也可以，Dominds 真正开启新一程后第一步再收敛整理
 - 接续包只保留差遣牒仍未覆盖的细节；不要重复团队共享状态。要向全队同步“现在到哪了 / 哪些决策已生效 / 下一步是什么 / 哪些阻塞仍成立”，请写回 Taskdoc `progress`
-- 不要手工记录 Dominds 系统环境会自动维护的状态，例如后台进程是否仍在运行、后台进行中的诉请/协作、浏览器/会话附件状态等；手工记录很容易过时，并与 runtime 自动维护的 single source of truth 冲突，造成认知干扰
+- 不要手工记录 Dominds 会自动维护的系统状态，例如后台进程是否仍在运行、后台进行中的诉请/协作、浏览器/会话附件状态等；手工记录很容易过时，并与 Dominds 自动维护的状态冲突，造成认知干扰
 - 不要把长日志、大段 tool output、原始材料直接塞进提醒项

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

@@ -37,15 +37,15 @@ MCP (Model Context Protocol) is a protocol for connecting to external services.
 
 ### 2. MCP Lease
 
-MCP uses a lease mechanism to manage runtime resources such as HTTP connections and stdio processes. Lease ownership is about who holds a runtime instance; it does not define global MCP tool registration or visibility.
+MCP uses a lease mechanism to manage connection/process resources such as HTTP connections and stdio processes. Lease ownership is about who holds a connection/process; it does not define global MCP tool registration or visibility.
 
 **Lifecycle:**
 
-- **Acquire lease**: Establish or hold a runtime instance
-- **Hold lease**: Keep using that runtime instance
+- **Acquire lease**: Establish or hold a connection/process
+- **Hold lease**: Keep using that connection/process
 - **Release lease**: Stop/disconnect and release resources
 
-`mcp_restart` changes the target server from `enabled: false` back to `enabled: true`, then tries to start it. When it succeeds, it replaces the global MCP runtime and clears all dialog leases on the old runtime; you do not need to call `mcp_release` first. To force a server into the disabled state, use `mcp_disable`.
+`mcp_restart` changes the target server from `enabled: false` back to `enabled: true`, then tries to start it. When it succeeds, it replaces the global MCP service connection and clears all dialog leases on the old connection/process; you do not need to call `mcp_release` first. To force a server into the disabled state, use `mcp_disable`.
 
 ### 3. Environment Variables
 

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

@@ -17,7 +17,7 @@
 
 When an MCP service has issues, needs to refresh the connection, or is currently disabled with `enabled: false`, enable and restart the MCP service.
 
-`mcp_restart` writes `enabled: true` when the server is currently `enabled: false`, then tries to start it. After it succeeds, it clears every dialog lease on the old runtime; you do not need to call `mcp_release` first.
+`mcp_restart` writes `enabled: true` when the server is currently `enabled: false`, then tries to start it. After it succeeds, it clears every dialog lease on the old connection/process; you do not need to call `mcp_release` first.
 
 ### Example
 

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

@@ -21,7 +21,7 @@
 
 ### 1. mcp_restart
 
-Enable and rebuild an MCP service using the current `.minds/mcp.yaml` config. If the target server is currently `enabled: false`, this writes `enabled: true` before trying to start it. After a successful restart, Dominds replaces the global MCP runtime/tool registration and clears all dialog leases held on the old runtime. If restart fails, the old runtime/leases are kept so troubleshooting does not tear down a still-working connection.
+Enable and rebuild an MCP service using the current `.minds/mcp.yaml` config. If the target server is currently `enabled: false`, this writes `enabled: true` before trying to start it. After a successful restart, Dominds replaces the global MCP tool registration and clears all dialog leases held on the old connection/process. If restart fails, the old connection/process and leases are kept so troubleshooting does not tear down a still-working connection.
 
 **Parameters:**
 
@@ -39,7 +39,7 @@ ok: restarted <MCP service identifier>
 
 ### 2. mcp_release
 
-Release the current dialog's leased MCP runtime instance for a server. This stops/releases the underlying HTTP connection or stdio process, but does not define global tool registration/visibility.
+Release the current dialog's leased MCP connection/process for a server. This stops/releases the underlying HTTP connection or stdio process, but does not define global tool registration/visibility.
 
 **Parameters:**
 
@@ -64,7 +64,7 @@ ok: no active lease for <MCP service identifier> (or server is truely-stateless)
 
 ### 3. mcp_disable
 
-Disable an MCP service and write `enabled: false` for that server in `.minds/mcp.yaml`. This does not wait for a replacement service to become available: it unconditionally clears the loaded runtime/leases. The disabled server remains visible as a zero-tool MCP toolset, with its manual clearly marked disabled.
+Disable an MCP service and write `enabled: false` for that server in `.minds/mcp.yaml`. This does not wait for a replacement service to become available: it unconditionally clears the loaded MCP connection/leases. The disabled server remains visible as a zero-tool MCP toolset, with its manual clearly marked disabled.
 
 **Parameters:**
 

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

@@ -37,15 +37,15 @@ MCP（Model Context Protocol）是连接外部服务的协议。
 
 ### 2. MCP 租约
 
-MCP 使用租约机制管理运行时资源，例如 HTTP 连接和 stdio 进程。租约只表示谁持有某个运行时实例，不决定 MCP 工具的全局注册或可见性。
+MCP 使用租约机制管理连接/进程资源，例如 HTTP 连接和 stdio 进程。租约只表示谁持有某个连接/进程，不决定 MCP 工具的全局注册或可见性。
 
 **生命周期：**
 
-- **获取租约**：建立或持有一个运行时实例
-- **持有租约**：继续使用该运行时实例
+- **获取租约**：建立或持有一个连接/进程
+- **持有租约**：继续使用该连接/进程
 - **释放租约**：停止/断开并释放资源
 
-`mcp_restart` 会把目标 server 的 `enabled: false` 改回 `enabled: true`，然后尝试启动；成功时会替换全局 MCP runtime 并清掉旧 runtime 的所有对话 lease；不需要先逐个 `mcp_release`。如果需要强制禁用某个 server，使用 `mcp_disable`。
+`mcp_restart` 会把目标 server 的 `enabled: false` 改回 `enabled: true`，然后尝试启动；成功时会替换全局 MCP 服务连接，并清掉旧连接/进程的所有对话 lease；不需要先逐个 `mcp_release`。如果需要强制禁用某个 server，使用 `mcp_disable`。
 
 ### 3. 环境变量
 

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

@@ -17,7 +17,7 @@
 
 当 MCP 服务出现故障、需要刷新连接，或当前被 `enabled: false` 禁用时，启用并重启 MCP 服务。
 
-`mcp_restart` 会把 `enabled: false` 写回 `enabled: true` 后尝试启动；成功后会清理旧 runtime 的全部对话 lease，不需要先 `mcp_release`。
+`mcp_restart` 会把 `enabled: false` 写回 `enabled: true` 后尝试启动；成功后会清理旧连接/进程 的全部对话 lease，不需要先 `mcp_release`。
 
 ### 示例
 

package/dist/tools/prompts/mcp_admin/zh/tools.md

@@ -21,7 +21,7 @@
 
 ### 1. mcp_restart
 
-按当前 `.minds/mcp.yaml` 配置启用并重建 MCP 服务。如果目标 server 当前是 `enabled: false`，会先写回 `enabled: true` 再尝试启动。重启成功后会替换全局 MCP runtime/tool 注册，并清理旧 runtime 上所有对话持有的 lease；重启失败时保留旧 runtime/lease，避免排障过程中把仍可用的连接拆掉。
+按当前 `.minds/mcp.yaml` 配置启用并重建 MCP 服务。如果目标 server 当前是 `enabled: false`，会先写回 `enabled: true` 再尝试启动。重启成功后会替换全局 MCP 工具注册，并清理旧连接/进程上所有对话持有的 lease；重启失败时保留旧连接/进程和 lease，避免排障过程中把仍可用的连接拆掉。
 
 **参数：**
 
@@ -39,7 +39,7 @@ ok: restarted <MCP 服务标识符>
 
 ### 2. mcp_release
 
-释放当前对话为某个 server 持有的 MCP 运行时实例。它会停止/释放底层 HTTP 连接或 stdio 进程，但不决定工具的全局注册或可见性。
+释放当前对话为某个 server 持有的 MCP 连接/进程。它会停止/释放底层 HTTP 连接或 stdio 进程，但不决定工具的全局注册或可见性。
 
 **参数：**
 
@@ -64,7 +64,7 @@ ok: no active lease for <MCP 服务标识符> (or server is truely-stateless)
 
 ### 3. mcp_disable
 
-禁用 MCP 服务并将 `.minds/mcp.yaml` 中对应 server 写为 `enabled: false`。该操作不等待新服务可用：会无条件清理已加载 runtime/lease。禁用后的 server 仍作为 0 工具 MCP toolset 可见，并在手册中明确标记为 disabled。
+禁用 MCP 服务并将 `.minds/mcp.yaml` 中对应 server 写为 `enabled: false`。该操作不等待新服务可用：会无条件清理已加载 MCP 连接/lease。禁用后的 server 仍作为 0 工具 MCP toolset 可见，并在手册中明确标记为 disabled。
 
 **参数：**