dominds 1.18.2 → 1.19.3

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

@@ -51,11 +51,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 working-set cue, move it to `personal_memory` instead
 
-## Scenario 2: Sideline is complete, and the assignment header requires replyTellask
+## Scenario 2: Side Dialog is complete, and the assignment header requires replyTellask
 
 ### Scenario Description
 
-The current sideline is finished, and the assignment header explicitly says "when complete, call `replyTellask`".
+The current Side Dialog is finished, and the assignment header explicitly says "when complete, call `replyTellask`".
 
 ### Example
 
@@ -72,11 +72,11 @@ replyTellask({
 - Put the final deliverable body directly in `replyContent`
 - If the header says `replyTellaskSessionless`, use the same shape with that exact function name
 
-## Scenario 3: Work is not finished yet, and an upstream clarification is required
+## Scenario 3: Work is not finished yet, and tellasker clarification is required
 
 ### Scenario Description
 
-The sideline is still blocked or incomplete, so you need to ask upstream for missing information.
+The Side Dialog is still blocked or incomplete, so you need to ask the tellasker for missing information.
 
 ### Example
 
@@ -89,15 +89,15 @@ tellaskBack({
 
 ### Key Points
 
-- This example uses `tellaskBack` because upstream input is specifically required
+- 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
 
-## Scenario 4: Upstream answered the ask-back, so use replyTellaskBack to close
+## Scenario 4: Tellasker answered the ask-back, so use replyTellaskBack to close
 
 ### Scenario Description
 
-You previously sent a `tellaskBack`, upstream has now replied, and runtime exposes `replyTellaskBack`.
+You previously sent a `tellaskBack`, the tellasker has now replied, and runtime exposes `replyTellaskBack`.
 
 ### Example
 

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

@@ -23,16 +23,16 @@
 
 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                                                     |
-| ------------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
-| `replyTellask`            | `{ replyContent: string }`   | Current sideline comes from a sessioned `tellask` and is ready for final delivery                   | Delivers the final result for the current tellask session  |
-| `replyTellaskSessionless` | `{ replyContent: string }`   | Current sideline comes from a one-shot `tellaskSessionless` and is ready for final delivery         | Delivers the final result for the current one-shot tellask |
-| `replyTellaskBack`        | `{ replyContent: string }`   | Current dialog holds an unresolved `tellaskBack` reply directive                                    | Delivers the final answer to the upstream ask-back         |
-| `tellaskBack`             | `{ tellaskContent: string }` | Current sideline must ask upstream back, and existing team SOP cannot directly assign another owner | Sends a follow-up request upstream; not final delivery     |
+| Function                  | Minimal parameter contract   | When runtime exposes 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     |
+| `replyTellaskBack`        | `{ replyContent: string }`   | Current dialog holds an unresolved `tellaskBack` reply directive                                            | Delivers the final answer to the tellasker ask-back            |
+| `tellaskBack`             | `{ tellaskContent: string }` | Current Side Dialog must ask the tellasker back, and existing team SOP cannot directly assign another owner | Sends a follow-up request to the tellasker; not final delivery |
 
 ### Minimal Usage Rules
 
-- Focus on doing the current task correctly first; only move into `reply*` closure when final upstream delivery is actually ready
+- 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
 - Put only the final deliverable body in `replyContent`; do not wrap it in meta-explanations like "I am now calling replyTellask"

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

@@ -93,20 +93,20 @@
 ### 决策规则
 
 - 当前支线未完成时，先判断团队规程 / SOP / 职责卡能否明确负责人；若能明确且属于执行性处理，直接 `tellask` / `tellaskSessionless` 对应负责人
-- 只有当必须向上游补需求、澄清目标、裁决取舍、确认验收口径、提供缺失输入，或现有规程无法明确判责时：调用 `tellaskBack({ tellaskContent })`
+- 只有当必须向诉请者补需求、澄清目标、裁决取舍、确认验收口径、提供缺失输入，或现有规程无法明确判责时：调用 `tellaskBack({ tellaskContent })`
 - 需要人类亲自登录 / GUI / 验证码 / 高风险授权时：调用 `askHuman({ tellaskContent })`
 - 当前支线已经完成，且当前 assignment 明确要求 `replyTellask`：调用 `replyTellask({ replyContent })`
 - 当前支线已经完成，且当前 assignment 明确要求 `replyTellaskSessionless`：调用 `replyTellaskSessionless({ replyContent })`
-- 当前是在回复一条上游发来的 `tellaskBack` 续诉请，且 runtime 暴露了 `replyTellaskBack`：调用 `replyTellaskBack({ replyContent })`
+- 当前是在回复一条诉请者发来的 `tellaskBack` 续诉请，且 runtime 暴露了 `replyTellaskBack`：调用 `replyTellaskBack({ replyContent })`
 - 普通文本不是跨对话完成交付通道；如果你直接输出正文而没调 reply 工具，runtime 可能临时插入一条 `role=user` 的提醒要求你改用正确的 reply 函数
 
 ### 心智负担最小化规则
 
-- 先专注把当前任务做对；`reply*` 只在最终对上游交付时用于收口
+- 先专注把当前任务做对；`reply*` 只在最终对诉请者交付时用于收口
 - 不要靠记忆硬选 reply 变体；以当前 assignment 头部和 runtime 当前暴露的函数名为准
 - `reply*` 函数自身说明文案故意保持极简，只承载最小规格；情景判断看本手册的 principles / scenarios
 - 若 runtime 只暴露一个 `reply*`，那就是当前应调用的唯一完成路径
-- `tellaskBack` 是“无法按现有规程明确判责，或必须回问上游”的兜底动作，不是所有阻塞的默认第一动作
+- `tellaskBack` 只在“无法按现有规程明确判责，或必须回问诉请者”时成立，不是所有阻塞的默认第一动作
 
 ## 最佳实践
 

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

@@ -71,11 +71,11 @@ replyTellask({
 - `replyContent` 直接放最终交付正文
 - 若 assignment 头部写的是 `replyTellaskSessionless`，则同结构替换函数名
 
-## 场景 3：当前未完成，需要回问上游
+## 场景 3：当前未完成，需要回问诉请者
 
 ### 场景描述
 
-当前支线仍未完成，因此需要向上游补问缺失信息。
+当前支线仍未完成，因此需要向诉请者补问缺失信息。
 
 ### 示例
 
@@ -84,12 +84,12 @@ tellaskBack({
   tellaskContent: '还缺少生产环境端口与部署入口信息。请补充这两项后我再继续给出最终方案。',
 });
 
-// 等上游补充后，runtime 会在当前对话里继续推进
+// 等诉请者补充后，runtime 会在当前对话里继续推进
 ```
 
 ### 关键点
 
-- 这里只是“必须向上游补输入”的例子，所以用 `tellaskBack`
+- 这里只是“必须向诉请者补输入”的例子，所以用 `tellaskBack`
 - 若团队规程 / SOP / 职责卡已经能明确执行负责人，应直接 `tellask` / `tellaskSessionless` 对应负责人，而不是机械因为“未完成态”就用 `tellaskBack`
 - `tellaskBack` 只负责把问题问回去，不负责最终交付
 
@@ -97,7 +97,7 @@ tellaskBack({
 
 ### 场景描述
 
-你之前发过 `tellaskBack`，上游现在补回了所需信息，runtime 暴露了 `replyTellaskBack`。
+你之前发过 `tellaskBack`，诉请者现在补回了所需信息，runtime 暴露了 `replyTellaskBack`。
 
 ### 示例
 

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

@@ -27,12 +27,12 @@
 | ------------------------- | ---------------------------- | -------------------------------------------------------------------- | ----------------------------------- |
 | `replyTellask`            | `{ replyContent: string }`   | 当前支线承接的是 sessioned `tellask`，且已进入可交付完成态           | 把最终结果回复给当前 `tellask` 会话 |
 | `replyTellaskSessionless` | `{ replyContent: string }`   | 当前支线承接的是 one-shot `tellaskSessionless`，且已进入可交付完成态 | 把最终结果回复给当前一次性诉请      |
-| `replyTellaskBack`        | `{ replyContent: string }`   | 当前对话持有一条未完成的 `tellaskBack` 回复指令                      | 把对上一条回问的最终答复送回上游    |
-| `tellaskBack`             | `{ tellaskContent: string }` | 当前支线必须回问上游，且现有团队规程无法直接判责到其他负责人         | 向上游发起续诉请，不算最终交付      |
+| `replyTellaskBack`        | `{ replyContent: string }`   | 当前对话持有一条未完成的 `tellaskBack` 回复指令                      | 把对上一条回问的最终答复送回诉请者  |
+| `tellaskBack`             | `{ tellaskContent: string }` | 当前支线必须回问诉请者，且现有团队规程无法直接判责到其他负责人       | 向诉请者发起续诉请，不算最终交付    |
 
 ### 最小使用规则
 
-- 先专注把当前任务做对；只有真到最终对上游交付时，才进入 `reply*` 收口
+- 先专注把当前任务做对；只有真到最终对诉请者交付时，才进入 `reply*` 收口
 - 看见哪一个 `reply*` 被 runtime 暴露，就调用哪一个；不要自行改选别的 reply 变体
 - assignment 头部若已点名 reply 函数名，以那个名字为准
 - `replyContent` 只放最终交付正文，不要再包一层“我现在调用了 replyXXX”

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

@@ -68,20 +68,6 @@
 - Check lease status
 - Contact administrator
 
-### ENV_NOT_FOUND
-
-**Description:** Environment variable doesn't exist.
-
-**Cause:**
-
-- Environment variable not set
-- Environment variable name is incorrect
-
-**Solution:**
-
-- Check environment variable name
-- Set required environment variable
-
 ## Frequently Asked Questions
 
 ### Q: What is an MCP lease?

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

@@ -26,9 +26,10 @@
 
 mcp_admin is Dominds' **MCP administration toolset** for managing MCP (Model Context Protocol) connections and resources:
 
-- **MCP restart**: Restart MCP service
+- **MCP restart/enable**: Enable and restart MCP service
 - **MCP release**: Release MCP lease
-- **Environment variables**: Read environment variables
+- **MCP disable**: Disable MCP service while keeping a zero-tool toolset/manual visible
+- **Environment variables**: Read, set, and delete local environment variables
 
 ## Quick Navigation
 
@@ -43,7 +44,8 @@ mcp_admin is Dominds' **MCP administration toolset** for managing MCP (Model Con
 
 - Status: Implemented
 - Main implementation files:
-  - Tool implementation: `dominds/main/tools/mcp-admin.ts`
+  - MCP tool implementation: `dominds/main/tools/mcp.ts`
+  - Environment variable tool implementation: `dominds/main/tools/env.ts`
   - Toolset metadata: `dominds/main/tools/builtins.ts`, `dominds/main/tools/registry.ts`
 
 ## Core Concepts

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

@@ -45,17 +45,22 @@ MCP uses a lease mechanism to manage runtime resources such as HTTP connections
 - **Hold lease**: Keep using that runtime instance
 - **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`.
+
 ### 3. Environment Variables
 
 Shared with os toolset for environment variable functionality.
 
 ## Tool Overview
 
-| Tool        | Function                 |
-| ----------- | ------------------------ |
-| mcp_restart | Restart MCP service      |
-| mcp_release | Release MCP lease        |
-| env_get     | Get environment variable |
+| Tool        | Function                       |
+| ----------- | ------------------------------ |
+| mcp_restart | Enable and restart MCP service |
+| mcp_release | Release MCP lease              |
+| mcp_disable | Disable MCP service            |
+| env_get     | Get environment variable       |
+| env_set     | Set environment variable       |
+| env_unset   | Delete environment variable    |
 
 ## Best Practices
 
@@ -64,6 +69,7 @@ Shared with os toolset for environment variable functionality.
 - **Release timely**: Release lease when MCP is no longer used
 - **Monitor status**: Regularly check MCP connection status
 - **Error handling**: Handle connection failures
+- **Responsibility routing**: teammates without the `mcp_admin` toolset should use the team responsibility quick table / routing cards to ask the MCP troubleshooter or administrator for help when MCP tools stop working; they should not improvise a bypass.
 
 ### 2. Resource Management
 

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

@@ -15,7 +15,9 @@
 
 ### Scenario Description
 
-When MCP service has issues or needs to refresh the connection, restart the MCP service.
+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.
 
 ### Example
 
@@ -53,7 +55,21 @@ env_get({
 });
 ```
 
-## Scenario 4: MCP Connection Failure Handling
+## Scenario 4: Disable MCP Service
+
+### Scenario Description
+
+When an MCP server should stop providing tools, or troubleshooting needs to force it offline, disable that server and write `enabled: false`. A disabled server is still exposed as a zero-tool toolset, and its manual clearly marks it as disabled.
+
+### Example
+
+```typescript
+mcp_disable({
+  serverId: 'filesystem',
+});
+```
+
+## Scenario 5: MCP Connection Failure Handling
 
 ### Scenario Description
 
@@ -69,7 +85,7 @@ mcp_restart({
 });
 ```
 
-## Scenario 5: Resource Cleanup
+## Scenario 6: Resource Cleanup
 
 ### Scenario Description
 

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

@@ -21,7 +21,7 @@
 
 ### 1. mcp_restart
 
-Restart MCP service.
+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.
 
 **Parameters:**
 
@@ -30,9 +30,7 @@ Restart MCP service.
 **Returns:**
 
 ```yaml
-status: ok|error
-serverId: <MCP service identifier>
-restarted_at: <restart timestamp>
+ok: restarted <MCP service identifier>
 ```
 
 **Errors:**
@@ -50,9 +48,13 @@ Release the current dialog's leased MCP runtime instance for a server. This stop
 **Returns:**
 
 ```yaml
-status: ok|error
-serverId: <MCP service identifier>
-released_at: <release timestamp>
+ok: released <MCP service identifier> for dialog <dialog identifier>
+```
+
+If the current dialog has no releasable lease, returns:
+
+```yaml
+ok: no active lease for <MCP service identifier> (or server is truely-stateless)
 ```
 
 **Errors:**
@@ -60,7 +62,21 @@ released_at: <release timestamp>
 - `MCP_NOT_FOUND`: MCP service doesn't exist
 - `MCP_NOT_RUNNING`: MCP service not running
 
-### 3. env_get
+### 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.
+
+**Parameters:**
+
+- `serverId` (required): MCP service identifier
+
+**Returns:**
+
+```yaml
+ok: disabled <MCP service identifier> and set enabled=false
+```
+
+### 4. env_get
 
 Get environment variable (shared with os toolset).
 
@@ -70,16 +86,41 @@ Get environment variable (shared with os toolset).
 
 **Returns:**
 
+- Set: returns the environment variable value directly
+- Unset: returns `(unset)`
+
+### 5. env_set
+
+Set an environment variable in the Dominds server process (shared with os toolset).
+
+**Parameters:**
+
+- `key` (required): Environment variable name
+- `value` (required): Environment variable value
+
+**Returns:**
+
 ```yaml
-status: ok|error
-key: <environment variable name>
-value: <environment variable value>
-retrieved_at: <retrieval timestamp>
+ok: <environment variable name>
+prev: <previous value or (unset)>
+next: <new value>
 ```
 
-**Errors:**
+### 6. env_unset
 
-- `ENV_NOT_FOUND`: Environment variable doesn't exist
+Delete an environment variable from the Dominds server process (shared with os toolset).
+
+**Parameters:**
+
+- `key` (required): Environment variable name
+
+**Returns:**
+
+```yaml
+ok: <environment variable name>
+prev: <previous value or (unset)>
+next: (unset)
+```
 
 ## Usage Examples
 
@@ -99,6 +140,14 @@ mcp_release({
 });
 ```
 
+### Disable MCP Service
+
+```typescript
+mcp_disable({
+  serverId: 'browser',
+});
+```
+
 ### Get Environment Variable
 
 ```typescript
@@ -107,17 +156,32 @@ env_get({
 });
 ```
 
-## YAML Output Contract
+### Set Environment Variable
+
+```typescript
+env_set({
+  key: 'MCP_AUTH_TOKEN',
+  value: 'local-token',
+});
+```
+
+### Delete Environment Variable
+
+```typescript
+env_unset({
+  key: 'MCP_AUTH_TOKEN',
+});
+```
+
+## Output Contract
 
-All tool outputs use YAML format for programmatic processing:
+These tools use the short text return formats described in their own sections:
 
-- `status`: Operation status, `ok` for success, `error` for failure
-- Other fields: Additional information for specific operations
+- Success: starts with `ok:`
+- Failure: starts with `error:`
 
 On error, returns:
 
 ```yaml
-status: error
-error_code: <error code>
-message: <error message>
+error: <error message>
 ```

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

@@ -68,20 +68,6 @@
 - 检查租约状态
 - 联系管理员
 
-### ENV_NOT_FOUND
-
-**描述：** 环境变量不存在。
-
-**原因：**
-
-- 环境变量未被设置
-- 环境变量名称错误
-
-**解决方案：**
-
-- 检查环境变量名称
-- 设置所需的环境变量
-
 ## 常见问题
 
 ### Q: MCP 租约是什么？

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

@@ -26,9 +26,10 @@
 
 mcp_admin 是 Dominds 的 **MCP 管理工具集**，用于管理 MCP（Model Context Protocol）连接和资源：
 
-- **MCP 重启**：重启 MCP 服务
+- **MCP 重启/启用**：启用并重启 MCP 服务
 - **MCP 释放**：释放 MCP 租约
-- **环境变量**：读取环境变量
+- **MCP 禁用**：禁用 MCP 服务，并保留 0 工具 toolset/手册可见性
+- **环境变量**：读取、设置、删除本地环境变量
 
 ## 快速导航
 
@@ -43,7 +44,8 @@ mcp_admin 是 Dominds 的 **MCP 管理工具集**，用于管理 MCP（Model Con
 
 - 状态：已实现
 - 主要实现文件：
-  - 工具实现：`dominds/main/tools/mcp-admin.ts`
+  - MCP 工具实现：`dominds/main/tools/mcp.ts`
+  - 环境变量工具实现：`dominds/main/tools/env.ts`
   - toolset 元信息：`dominds/main/tools/builtins.ts`、`dominds/main/tools/registry.ts`
 
 ## 核心概念

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

@@ -45,17 +45,22 @@ MCP 使用租约机制管理运行时资源，例如 HTTP 连接和 stdio 进程
 - **持有租约**：继续使用该运行时实例
 - **释放租约**：停止/断开并释放资源
 
+`mcp_restart` 会把目标 server 的 `enabled: false` 改回 `enabled: true`，然后尝试启动；成功时会替换全局 MCP runtime 并清掉旧 runtime 的所有对话 lease；不需要先逐个 `mcp_release`。如果需要强制禁用某个 server，使用 `mcp_disable`。
+
 ### 3. 环境变量
 
 与 os 工具集共享环境变量功能。
 
 ## 工具概览
 
-| 工具        | 功能          |
-| ----------- | ------------- |
-| mcp_restart | 重启 MCP 服务 |
-| mcp_release | 释放 MCP 租约 |
-| env_get     | 获取环境变量  |
+| 工具        | 功能                |
+| ----------- | ------------------- |
+| mcp_restart | 启用并重启 MCP 服务 |
+| mcp_release | 释放 MCP 租约       |
+| mcp_disable | 禁用 MCP 服务       |
+| env_get     | 获取环境变量        |
+| env_set     | 设置环境变量        |
+| env_unset   | 删除环境变量        |
 
 ## 最佳实践
 
@@ -64,6 +69,7 @@ MCP 使用租约机制管理运行时资源，例如 HTTP 连接和 stdio 进程
 - **及时释放**：不再使用 MCP 时及时释放租约
 - **监控状态**：定期检查 MCP 连接状态
 - **错误处理**：处理连接失败的情况
+- **职责路由**：没有 `mcp_admin` 工具集的队友遇到 MCP 工具异常时，应按团队职责速查表/路由卡找到 MCP 排障或管理员队友协助，不要自行绕过。
 
 ### 2. 资源管理
 

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

@@ -15,7 +15,9 @@
 
 ### 场景描述
 
-当 MCP 服务出现故障或需要刷新连接时，重启 MCP 服务。
+当 MCP 服务出现故障、需要刷新连接，或当前被 `enabled: false` 禁用时，启用并重启 MCP 服务。
+
+`mcp_restart` 会把 `enabled: false` 写回 `enabled: true` 后尝试启动；成功后会清理旧 runtime 的全部对话 lease，不需要先 `mcp_release`。
 
 ### 示例
 
@@ -53,7 +55,21 @@ env_get({
 });
 ```
 
-## 场景 4：MCP 连接故障处理
+## 场景 4：禁用 MCP 服务
+
+### 场景描述
+
+当某个 MCP server 不应继续提供工具，或排障时需要强制下线它，禁用该 server 并写入 `enabled: false`。禁用后的 server 仍会作为 0 工具 toolset 暴露，手册会明确标记已禁用。
+
+### 示例
+
+```typescript
+mcp_disable({
+  serverId: 'filesystem',
+});
+```
+
+## 场景 5：MCP 连接故障处理
 
 ### 场景描述
 
@@ -69,7 +85,7 @@ mcp_restart({
 });
 ```
 
-## 场景 5：资源清理
+## 场景 6：资源清理
 
 ### 场景描述