dominds 1.23.10 → 1.24.2

package/dist/docs/diligence-push.zh.md

@@ -7,17 +7,16 @@
 Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）通常不是操作员想要的：他们希望智能体持续推进，直到：
 
 - 合法地暂停等待人类决策（Q4H），或
-- 合法地暂停等待支线对话（tellask/backfill）。
+- 没有其它本地可推进事项，只保留后台被诉请者事实（pending tellask/backfill）。
 
 本文档指定两个相关但不同的运行时控制：
 
-- **自动续推注入**：仅针对**主线对话**，当驱动程序即将停止时，运行时会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的支线对话）。
-- **支线 quirk 恢复续推**：当 provider/API quirk 明确给出一次性 `diligence_push_once` 恢复动作时，支线对话可使用运行时内置模板续推，但仅限当前存在活跃回贴义务（active reply obligation）的场景；模板必须点名运行时确认的唯一 `replyTellask*` 工具。
+- **自动续推注入**：仅针对**主线对话**，当驱动程序即将停止、且没有 Q4H 或 pending active callee dispatch 时，运行时会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成。pending tellask 是后台被诉请者事实，不是阻塞态；但在没有其它具体驱动来源时，它表示主线已经到达可 idle 的后台等待边界，不应靠鞭策语保持主线空转。
 - **强制工具调用控制**：对于普通的主线/支线对话轮次，`鞭策` 勾选项控制本轮 provider 请求是否必须通过 Dominds 工具结束。勾选时，模型应通过 `askHuman`、`tellask*`、`replyTellask*` 或其他运行时函数完成这一轮，而不是用普通文本直接收尾。FBR 中间轮是刻意例外：它们可以处于无可调用工具状态；FBR 收口阶段则必须调用两个结论工具之一。
 
 ## 目标
 
-- 防止主线对话停止，除非处于合法暂停状态（Q4H / 支线对话）。
+- 防止主线对话停止，除非处于 Q4H 等真正等待用户输入的状态，或已自然没有本地可推进事项。
 - 保持行为可预测和有界（无无限循环）。
 - 使鞭策语文本可按 rtws（运行时工作区）和语言配置。
 - 提供清晰的用户控制的"禁用"机制。
@@ -25,7 +24,7 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 ## 非目标
 
 - 自动完成/自动将对话标记为完成。
-- 将普通自动鞭策语注入应用于支线对话（支线对话保持范围，应向其诉请者报告；只有 provider quirk 恢复特例可使用支线模板）。
+- 将鞭策语注入应用于支线对话。支线对话应由普通业务事实继续推进，或向诉请者回贴；非本意的直接回复停止由 direct-reply fallback 与 caller 后续判断处理。
 
 ## 定义
 
@@ -49,20 +48,17 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 
 ### 触发条件（必须全部满足）
 
-- 对话是**主线对话**；支线对话只适用下文 provider 死锁恢复特例。
-- 对话**未暂停**：
-  - 没有待处理的 Q4H，并且
-  - 没有待处理的支线对话（等待回填）。
+- 对话是**主线对话**。
+- 对话没有会合法停止自动续推的等待事实：
+  - 没有待处理的 Q4H。
+  - 没有 pending active callee dispatch。
 - 驱动程序即将停止生成循环（即没有工具/函数输出需要另一次迭代）。
 
-### 例外：provider 死锁恢复
+### provider 死锁恢复
 
 某些 provider/API quirk 在识别到已知的 same-context deadlock，并停止沿用同一上下文自动重试后，
-会请求一次性的鞭策恢复。这不是普通的“对话即将空转停止”路径。在这个仅用于恢复的特例里，
-即使主线对话已经登记了在途诉请/支线对话，pending sideDialog 也不应否决这一次鞭策注入；因为卡死
-可能正发生在函数结果驱动的生成轮次里。
-
-支线对话也可使用这条恢复路径，但必须满足当前仍有活跃回贴义务（active reply obligation）；否则不注入鞭策语，保留 retry stopped 状态交给人类处理。支线恢复模板不读取 rtws diligence 文件，而是使用内置双语模板，包含当前时间、当前诉请目标，并点名运行时已确认的唯一 `replyTellask*` 工具（例如 `replyTellaskSessionless({ replyContent })`），禁止让 LLM 自行猜测 reply 变体。Q4H 仍然是硬阻塞条件。
+会请求一次性的鞭策恢复。这不是普通的“对话即将空转停止”路径，但仍必须遵守同一条后台等待边界：
+鞭策恢复注入仅作用于主线对话，且 pending active callee dispatch 会否决这一次鞭策注入。active callee dispatch 是后台被诉请者事实，不是 caller 的阻塞态；它允许 caller 因其它具体事实继续推进，但不能单独成为“保持主线 drive”的理由。支线对话 retry-stopped 恢复不注入鞭策语；后续由普通业务事实、direct-reply fallback 或 caller 的下一步判断决定。
 
 ### 操作
 
@@ -138,12 +134,11 @@ members:
 
 在 kernel driver 循环中实现（`dominds/main/llm/kernel-driver/drive.ts`），作为迭代后的小检查：
 
-1. 如果对话处于暂停状态，则停止（Q4H / 支线对话待处理）；但上文所述 deadlock-recovery 特例除外，
-   即那一次恢复专用的鞭策可忽略 pending sideDialog。
+1. 如果对话正在等待 Q4H，或仍有 pending active callee dispatch，则停止。active callee dispatch 是后台被诉请者事实，不是 caller 的阻塞态；但在没有其它具体驱动来源时，它是自然 idle 边界，不能触发鞭策注入。
 2. 如果有任何工具反馈，则正常继续。
 3. 否则尝试 diligence-push 自动继续：
    - 主线对话：按 rtws diligence 文件 / 内置回退文本解析并续推。
-   - 支线对话：仅在 provider quirk 恢复且存在活跃回贴义务（active reply obligation）时，注入支线内置模板；没有活跃回贴义务时不注入。
+   - 支线对话：不注入鞭策语。
    - 如果禁用 → 正常停止。
    - 如果预算耗尽 → 发出一条仅用于提示的 UI 信息，并停止继续自动鞭策当前预算。
    - 否则 → 自动发送鞭策语并继续。
@@ -176,9 +171,9 @@ members:
 
 - 主线对话：仅工具输出 → 鞭策语注入 → 继续响应
 - 主线对话：空助手输出 → 鞭策语注入 → 继续响应
+- 主线对话：只派发 pending tellask / active callee dispatch → 无鞭策语注入，保留后台状态并自然 idle
 - 支线对话：普通 idle 无鞭策语注入
-- 支线对话：provider quirk recovery + 活跃回贴义务（active reply obligation）→ 注入支线模板，文案使用工作语言，包含当前诉请目标，并准确点名运行时确认的 `replyTellask*`
-- 支线对话：provider quirk recovery + 无活跃回贴义务 → 不注入，保留 stopped/giveup 给人类处理
+- 支线对话：provider quirk recovery 无鞭策语注入；由 direct-reply fallback 或 caller 判断后续业务动作
 - rtws 配置：
   - 当语言特定文件缺失时，`.minds/diligence.md` 被遵守
   - 空的鞭策语文件禁用 diligence-push

package/dist/docs/dominds-agent-collaboration.zh.md

@@ -119,21 +119,23 @@ Dominds 里主要有三种协作诉请：
 - 只需要一次性取证、跑一次命令、给一份审阅结果，用 **一次性诉请**
 - 支线发现关键信息缺失，不能猜，就用 **回问诉请**
 
-### 4. 协作不是“发消息就结束”，而是挂起与恢复
+### 4. 协作不是“发消息就结束”，而是后台事实与结果到达
 
-Dominds 的关键特征之一，是诉请后的运行态会显式管理：
+Dominds 的关键特征之一，是诉请后的运行态会显式管理 caller / callee 关系：
 
-- 主线可因等待支线结果而挂起
-- 支线可因等待澄清而挂起
-- 对话恢复由后端协程统一驱动
+- pending tellask 是 caller 的后台被诉请者事实，不表示 caller 被阻塞
+- callee 如需澄清，用 `tellaskBack` 回问当前 caller
+- Q4H 是正式等待用户回答的阻塞点
+- 回贴到达会成为 caller 的新事实，并可触发 caller 处理结果
 - 回贴会回到“当前诉请者”
 
 因此，从外部智能体的视角，Dominds 协作设计要考虑的不是“谁给谁发消息”，而是：
 
 - 谁拥有当前任务真相
-- 谁在等待谁
-- 谁有权继续推进
-- 谁的回复会被自动路由回哪条工作线
+- 当前诉请链路上的 caller / callee 分别是谁
+- 哪些事项只是后台进行中，哪些事项真的需要用户回答
+- 谁有权维护差遣牒并继续整体编排
+- 哪个 dispatch batch 的回贴会被路由回哪条工作线
 
 ### 5. 向人请示（Q4H）是正式阻塞点
 
@@ -200,7 +202,7 @@ Q4H 不是“顺手问一句”，而是一个正式的待答问题：
 
 - 谁作为 `default_responder`
 - 谁负责维护差遣牒
-- 谁负责汇总支线回贴并继续推进
+- 谁负责汇总 callee 回贴并继续整体推进
 
 然后再配置其他成员，例如：
 
@@ -302,7 +304,7 @@ Q4H 不是“顺手问一句”，而是一个正式的待答问题：
 - 主线职责:
   - 冻结 goals / constraints / progress
   - 决定派工
-  - 汇总支线结果
+  - 汇总 callee 结果
   - 必要时发起 Q4H
 
 ## 成员清单

package/dist/docs/dominds-terminology.md

@@ -68,6 +68,9 @@
 - EN: These are **Tellask roles**, not hierarchy; the tellasker may or may not be the structural askerDialog.
 - ZH: 这是一次诉请的**角色关系**，不是层级关系；诉请者可能是也可能不是结构上的 askerDialog。
 
+- EN: Use **Main Dialog / Side Dialog** for lifecycle, navigation, archival, Taskdoc ownership, and storage topology. Use **tellasker/tellaskee** or **caller/callee** for who asked whom, who owes a reply, result arrival, and continuation decisions.
+- ZH: **主线对话 / 支线对话**只用于生命周期、导航、归档、差遣牒职责与存储拓扑。表达“谁诉请谁、谁欠回贴、结果到达、是否继续推进”时，使用**诉请者/被诉请者**或 **caller/callee**。
+
 - EN (cross-reference): In implementation-facing docs/code, the standard class/concept names are `MainDialog` / `main dialog` for **Main Dialog**, and `SideDialog` / `sideDialog` for **Side Dialog**. `rootId` remains a structural identifier field, not the user-facing term.
 - ZH（交叉说明）: 在系统实现语境（文档/代码）中，标准类名/概念名是 **MainDialog / main dialog（主线对话）** 与 **SideDialog / sideDialog（支线对话）**。`rootId` 仍是结构标识字段，不是对外术语。
 
@@ -277,8 +280,8 @@ Example / 示例（概念）:
 
 ### Skill（技能文档）
 
-- EN: A **Skill** is a pure-Markdown capability asset under `.minds/skills/**` that is injected into prompts as guidance. Skills are best for soft guidance, checklists, heuristics, and team-specific methods.
-- ZH: **Skill（技能文档）**是 `.minds/skills/**` 下的纯 Markdown 能力资产，会作为指导性内容注入提示词。Skill 适合承载软性指导、检查清单、判断口诀与团队特定方法学。
+- EN: A **Skill** is a pure-Markdown capability asset under `.minds/skills/**`. Dominds injects a skill index into prompts, and agents read skill bodies on demand with `read_skill`. Skills are best for soft guidance, checklists, heuristics, and team-specific methods.
+- ZH: **Skill（技能文档）**是 `.minds/skills/**` 下的纯 Markdown 能力资产。Dominds 会把 skill 索引注入提示词，智能体按需通过 `read_skill` 读取正文。Skill 适合承载软性指导、检查清单、判断口诀与团队特定方法学。
 
 - EN: A Skill is **not** an installable App and is **not** the right term for a tool-coupled product capability. Frontmatter such as `allowed-tools` is compatibility metadata, not automatic authorization.
 - ZH: Skill **不是**可安装的 App，也**不是**带稳定工具契约的产品能力包的正确叫法。诸如 `allowed-tools` 的 frontmatter 只是兼容/迁移元数据，不代表自动授权。

package/dist/docs/idle-reminder-wake.md

@@ -104,7 +104,7 @@ After the aggregation window, the driver must re-read persistence and verify:
 - display state is still `idle_waiting_user`
 - execution marker is not dead and not an interrupted state requiring human resume
 - no pending Q4H exists
-- no blocking pending sideDialog exists
+- no blocking active callee dispatch exists
 - no active run exists
 
 Only then may the driver continue with the wake prompt. Otherwise the wake is dropped, while owner idempotence/state updates may still be retained.

package/dist/docs/idle-reminder-wake.zh.md

@@ -104,7 +104,7 @@ driver 不应在第一个 wake event 到达后立刻 drive。它应：
 - display state 仍是 `idle_waiting_user`
 - execution marker 不是 dead，也不是需要人工 resume 的 interrupted
 - 没有 pending Q4H
-- 没有 blocking pending sideDialog
+- 没有 blocking active callee dispatch
 - 当前没有 active run
 
 只有这些条件都满足，才允许以 wake prompt 继续驱动。否则丢弃本次 wake，并只保留 owner 的幂等/状态更新。

package/dist/docs/issues/tellask-background-continuation-live-bugs-2026-05-17.zh.md

@@ -0,0 +1,101 @@
+# Tellask 后台续推与状态推送现场 bug 记录（2026-05-17）
+
+本文记录 `tellask-background-continuation-refactor.zh.md` 重构过程中暴露的现场 bug，避免后续实现时遗失上下文。中文语义为准。
+
+## 0. 统一原则
+
+- caller/callee 是运行时业务关系，不是父子层级关系。实现命名已开始把 `parentDialog` 收敛为 `callerDialog`；剩余历史命名只应出现在明确的旧语义说明或尚未触达的内部实现细节中。
+- 任何会影响前端 badge / run-control / dialog list 的 dialog 状态变化，都必须有实时广播事件或全局状态推送，不能只依赖下一次列表刷新。
+- backend loop 不能全量扫描 root 下所有历史支线。root 长期运行并累积成千上万个支线是正常场景；需要维护 root-local 精确 watch index，只记录当前需要监护的支线子集。
+- recoverable 一致性问题优先保活：日志要 loud，带 rootId/selfId/course/genseq/callId/batchId 等结构化字段；能继续对话时不要 hard stop。
+
+## 1. 鞭策机制在 active callee 存在时误发
+
+症状：
+
+- root dialog 正在等待 active callee 时，不应注入鞭策语保持主线空转。
+- UI 把“鞭策”从未勾选改为勾选状态时，也会触发鞭策发送，即使对应 root dialog 正在等 active callee。
+
+期望：
+
+- 统一到一个判断函数：只要 dialog 有 pending active callee / background callee boundary，Diligence Push 不应成为主线续推动力。
+- “勾选鞭策”只影响可调用工具约束，不绕过 active callee gate。
+
+## 2. caller/callee badge 与状态推送不及时
+
+症状：
+
+- root 开始 tellask 后，dialog list 节点没有自动打上“电话听筒” badge。
+- 所有 callee 都已回复后，caller 节点仍未去掉 badge。
+- 对支线宣布卡死后，其 caller 应去掉 badge，但 UI 没刷新。
+- 支线等待自己的 callee 时，疑似被主线 caller 的停止状态污染，显示“已停止（可继续）”。
+
+当前修复方向：
+
+- 新增 `dlg_background_callee_summary_evt`，在 active callee 增删、resolve、declare-dead 路径广播 pending 数量。
+- 前端收到该事件后更新 running dialog list 的 `backgroundCalleeDialogCount` / `backgroundFreshBootsReasoningCalleeCount`。
+- 已覆盖 root tellask 开始、callee resolve、registered tellask 替换旧 owner、declare-dead 重试等高风险路径；后续新增 active-callee mutation 时必须同步维护 summary 广播。
+- 回归脚本：`kernel-driver:root-tellask-background-callee-badge-event`。
+
+## 3. duplicate pending replyDelivery 不应 hard stop
+
+现场样本：
+
+- rtws: `/ws/AiWorks/daowei2026/chatgpt-workstation/.dialogs`
+- error:
+  `persistTellaskCall invariant violation: duplicate pending reply delivery (rootId=cb/d9/30f2a99b, selfId=09/62/31c3bfab, existing=tool_UAU0mx13ap5tS7oheJQ5bTEN, incoming=tool_Uw5ITM0NrLfYD6Dh6s6quXoB)`
+
+已定位根因：
+
+- callee 已写 `tellask_reply_resolution_record` 和 response anchor，但 `latest.replyDelivery.status` 仍停在 `pending`。
+- 后续同一支线产生新的 `replyTellask*` 时，被误判为 duplicate pending delivery。
+
+期望：
+
+- 成功交付 reply 后同步 `markReplyDeliveryDelivered()`。
+- 如果遇到 stale pending replyDelivery，而新 reply call 对应当前有效 reply obligation，应 loud warn 并替换 pending delivery，继续对话。
+
+## 4. 支线 caller 收到 callee 回贴后没有 revive
+
+现场样本：
+
+- rtws: `/ws/AiWorks/daowei2026/chatgpt-workstation/.dialogs`
+- caller dialog: `rootId=cb/d9/30f2a99b selfId=3e/d1/31cc4b41`
+- callee dialog: `selfId=7e/c5/31decb1f`
+- UI link: `course=1&genseq=3&rootId=cb%2Fd9%2F30f2a99b&selfId=7e%2Fc5%2F31decb1f`
+
+现场事实：
+
+- callee `7e/c5/31decb1f` 在 course 1 genseq 3 调用了 `replyTellaskSessionless`。
+- caller `3e/d1/31cc4b41/course-001.jsonl` 已写入 `tellask_result_record`。
+- caller `latest.yaml` 仍有：
+  - `nextStep.triggers[0].kind = result_arrival`
+  - `batchId = dispatch:cb/d9/30f2a99b:3e/d1/31cc4b41:c1:g34`
+- caller `active-callees.json` 中对应 batch 已是 `resolved/final`，但仍未进入下一轮 generation。
+
+当前判断：
+
+- root backend loop 只照顾 root dialog，不扫描支线 `latest.nextStep`。
+- 支线 caller 的 revive 依赖 `supplyResponseToAskerDialog()` 当场直接 `scheduleDrive(callerDialog)`；一旦 fire-and-forget drive 丢失、被 gate 拦截、实例不是 live，durable `result_arrival` 没有后续兜底。
+
+目标修复：
+
+- 维护 root-local `drive-watch.json`，只记录需要 backend 监护的支线 selfId 子集。
+- 当支线写入 `nextStep` trigger、open generation 或未完成 `replyDelivery` 时加入 watch；当 trigger 消费、generation closed 且 replyDelivery 完整 recorded 后移除。
+- backend loop 仍由 root wake 唤醒，但只扫描 root 本身 + `drive-watch.json` 中的支线，不全量遍历历史支线目录。
+- 支线 `result_arrival` 写入后应 wake root backend loop，保证 durable trigger 可恢复。
+- 回归脚本：`kernel-driver:sideDialog-caller-result-arrival-backend-watch`。
+
+## 5. 文档/实现状态需更新
+
+文档位置：
+
+- `docs/tellask-background-continuation-refactor.zh.md`
+
+需要同步：
+
+- kernel-driver 已基本不再用 course JSONL 作为 active callee / reply recovery 运行源。
+- `latest.tellaskResults`、`replyDelivery`、`active-callees.json`、`nextStep.triggers`、drive watch index 是目标运行源。
+- `needsDrive` projection 已删除；`backend_queue` 旧术语仍需继续收敛为显式 next-step API。
+- malformed 边界仍未完全完成：`nextStep` 缺失仍会初始化，尚未做到所有必要状态机元信息缺失均转 malformed。
+- `sideDialog_created_evt` wire 字段已从 `parentDialog` / `parentBackground...` 收敛为 `callerDialog` / `callerBackground...`。

package/dist/docs/mcp-prompts-resources.md

@@ -26,6 +26,7 @@ Expected behavior:
 - Prompt arguments are collected by the UI before insertion when the prompt declares arguments.
 - MCP prompt snippets cannot be edited or saved back through Dominds.
 - Prompt IDs are Dominds-local stable IDs derived from server ID plus transformed MCP prompt name.
+- Prompt IDs use the server-level transform unless `prompts.transform` overrides it.
 
 This keeps prompts user-selected while reusing the existing Dominds snippet workflow.
 
@@ -40,6 +41,7 @@ Resource entries:
 - Static resource IDs are derived from the resource URI after configured transforms.
 - Template resource IDs are derived from the URI template after configured transforms.
 - The original URI or URI template remains the source of truth used for MCP requests.
+- Resource IDs use the server-level transform unless `resources.transform` overrides it.
 
 The resource registry is intentionally separate from Dominds files, docs, and memory. Those
 domains keep their existing dedicated concepts. The resource registry is the generic MCP-shaped
@@ -67,6 +69,8 @@ Rules:
 - The frontmatter must pass the same validation as local Dominds skills.
 - Resource skills are read-only and keep MCP provenance.
 - Invalid or duplicate resource skills are reported loudly through Problems/logs.
+- Resource skill IDs use the nearest enclosing transform: `resources.skills.transform` overrides
+  `resources.transform`, which overrides the server-level default.
 
 Dominds skills are loaded as an index in the system prompt. Skill bodies are read on demand with
 `read_skill`, so resource skills do not inflate every generation by default.
@@ -84,11 +88,14 @@ servers:
     headers:
       Authorization: Bearer dw
 
+    transform:
+      - prefix: 'workstation_'
+
     prompts:
       whitelist:
         - 'workstation.*'
-      transform:
-        - prefix: 'workstation_'
+      # transform:
+      #   - prefix: 'prompt_'
 
     resources:
       whitelist:
@@ -96,8 +103,8 @@ servers:
         - 'workstation-skill://*'
       blacklist:
         - '*secret*'
-      transform:
-        - prefix: 'workstation_'
+      # transform:
+      #   - prefix: 'resource_'
       mimeTypes:
         - text/markdown
         - text/plain
@@ -106,8 +113,8 @@ servers:
         enabled: true
         whitelist:
           - 'workstation-skill://*'
-        transform:
-          - prefix: 'workstation_skill_'
+        # transform:
+        #   - prefix: 'skill_'
 ```
 
 Filtering matches original MCP names/URIs/templates. Transforms only produce Dominds-local IDs.

package/dist/docs/mcp-support.md

@@ -208,7 +208,7 @@ into Dominds’ tool system, and therefore can never be presented to agents for
 
 - Patterns use simple wildcard matching with `*` (match any substring).
 - Matching is evaluated against the **original MCP tool name** (before rename transforms). This
-  keeps filters stable even if naming transforms change.
+  keeps filters stable even if ID transforms change.
 
 ### Semantics
 
@@ -224,15 +224,16 @@ into Dominds’ tool system, and therefore can never be presented to agents for
   - Tools that match neither `whitelist` nor `blacklist` are registered (i.e. whitelist does not
     restrict the universe when a blacklist is present).
 
-## Tool Name Transforms
+## ID Transforms
 
-Transforms are applied to the MCP tool name to produce a Dominds tool name.
+Transforms are applied to MCP-derived IDs to produce Dominds-local IDs.
 
 ### Why transforms exist
 
-- MCP servers frequently expose short/common tool names (`open`, `search`, `list`, …) that can
-  collide across servers and with built-ins.
-- Dominds tool names are global, so names must be made unique and recognizable.
+- MCP servers frequently expose short/common IDs (`open`, `search`, `list`, handbook URIs, prompt
+  names, …) that can collide across servers and with built-ins.
+- Dominds tool names, prompt IDs, resource IDs, and virtual skill IDs are global within their
+  registries, so IDs must be made unique and recognizable.
 
 ### Supported transforms
 
@@ -257,6 +258,11 @@ Notes:
 - `prefix: "x_"` always adds `x_` in front of the current name.
 - `prefix: { remove, add }` removes the specified leading substring if present, then adds `add`.
 - `suffix: "_x"` always appends `"_x"` to the current name.
+- `servers.<serverId>.transform` is the default transform for every MCP-derived Dominds ID from
+  that server: tools, prompts, resources/resource templates, and resource skills.
+- Nested `tools.transform`, `prompts.transform`, `resources.transform`, and
+  `resources.skills.transform` override the enclosing transform for that surface. They do not stack
+  with it. An explicit `transform: []` means “no transform for this surface”.
 
 ## Tool Name Validity (Reject Invalid Names)
 
@@ -441,13 +447,16 @@ servers:
     # headers: {} # optional (supports literal, { env: NAME }, or { prefix, env } values)
     # sessionId: '' # optional
 
+    # Default ID transforms for all MCP-derived Dominds IDs from this server (optional).
+    # Nested transforms under tools/prompts/resources/resources.skills override this default.
+    transform: []
+
     # Tool exposure controls
     tools:
       whitelist: [] # optional
       blacklist: [] # optional
-
-    # Tool name transforms (optional)
-    transform: []
+      # Optional tool-only override; explicit [] disables the top-level transform for tools.
+      # transform: []
 
     # Optional enhanced manual information; omitting it is allowed but emits a Problems warning.
     # - contentFile: formal runtime manual for man({ "toolsetId": "<serverId>" });

package/dist/docs/mcp-support.zh.md

@@ -164,7 +164,7 @@ Dominds 已经通过提供者支持结构化的"函数调用"，包括参数验
 ### 模式规则
 
 - 模式使用简单的通配符匹配，使用 `*`（匹配任何子字符串）。
-- 匹配针对**原始 MCP 工具名称**评估（在重命名转换之前）。这使过滤器保持稳定，即使命名转换发生变化。
+- 匹配针对**原始 MCP 工具名称**评估（在 ID 转换之前）。这使过滤器保持稳定，即使 ID 转换发生变化。
 
 ### 语义
 
@@ -177,14 +177,14 @@ Dominds 已经通过提供者支持结构化的"函数调用"，包括参数验
   - 匹配任何 `blacklist` 模式的工具永远不会被注册，**除非**它们也匹配 `whitelist`（白名单覆盖黑名单用于精选）。
   - 既不匹配 `whitelist` 也不匹配 `blacklist` 的工具会被注册（即当黑名单存在时，白名单不限制范围）。
 
-## 工具名称转换
+## ID 转换
 
-转换应用于 MCP 工具名称以生成 Dominds 工具名称。
+转换应用于 MCP 派生 ID，用于生成 Dominds 本地 ID。
 
 ### 为什么存在转换
 
-- MCP 服务器经常暴露短/常见的工具名称（`open`、`search`、`list` ……），这些名称可能在服务器之间冲突并与内置工具冲突。
-- Dominds 工具名称是全局的，因此名称必须唯一且可识别。
+- MCP 服务器经常暴露短/常见的 ID（`open`、`search`、`list`、手册 URI、prompt 名称……），这些 ID 可能在服务器之间冲突并与内置能力冲突。
+- Dominds 的工具名称、prompt ID、resource ID、虚拟 skill ID 在各自 registry 内是全局的，因此 ID 必须唯一且可识别。
 
 ### 支持的转换
 
@@ -209,6 +209,8 @@ transform:
 - `prefix: "x_"` 始终在当前名称前面添加 `x_`。
 - `prefix: { remove, add }` 删除指定的前导子字符串（如果存在），然后添加 `add`。
 - `suffix: "_x"` 始终将 `"_x"` 附加到当前名称。
+- `servers.<serverId>.transform` 是该 server 派生出的所有 Dominds ID 的默认转换：tools、prompts、resources/resource templates、resource skills 都默认使用它。
+- 内层 `tools.transform`、`prompts.transform`、`resources.transform`、`resources.skills.transform` 会覆盖外层转换，不会与外层叠加。显式 `transform: []` 表示该 surface 不做转换。
 
 ## 工具名称有效性（拒绝无效名称）
 
@@ -359,13 +361,16 @@ servers:
     # headers: {} # 可选（支持字面量、{ env: NAME } 或 { prefix, env } 值）
     # sessionId: '' # 可选
 
+    # 该 server 派生出的所有 Dominds ID 的默认转换（可选）。
+    # tools/prompts/resources/resources.skills 下的内层 transform 会覆盖这个默认值。
+    transform: []
+
     # 工具暴露控制
     tools:
       whitelist: [] # 可选
       blacklist: [] # 可选
-
-    # 工具名称转换（可选）
-    transform: []
+      # 可选：仅 tools 的覆盖转换；显式 [] 表示 tools 不使用顶层 transform。
+      # transform: []
 
     # 可选增强手册；省略时仍可接入，但会产生 Problems warning。
     # - contentFile: 给 man({ "toolsetId": "<serverId>" }) 的正式运行时手册；

package/dist/docs/memory-system.md

@@ -2,12 +2,13 @@
 
 Chinese version: [中文版](./memory-system.zh.md)
 
-Dominds’ “memory system” is really **context engineering**: put information into the right container based on stability and sharing scope, so long‑running work stays fast, correct, and transparent to humans.
+Dominds’ “memory system” is really **context engineering**: put information into the right container based on stability, sharing scope, and execution semantics, so long‑running work stays fast, correct, and transparent to humans.
 
 TL;DR:
 
 - Make dialog history disposable (noise is cheap to drop).
 - Make key artifacts survivable (you can `clear_mind` and still keep moving).
+- Treat skills as first-class context assets: memory stores facts/indexes/consensus, while skills capture reusable “when to do it, how to do it, and where the boundary is” operating guidance.
 - Publicly declare and openly discuss progress in real time (and keep it auditable) to enforce timely coordination: that’s where the real leverage comes from when multiple agents and multiple Main Dialogs work in parallel (Taskdoc / team memory / env notes).
 
 Key rule: **the Taskdoc is the task’s live coordination bulletin board**. Put key decisions/status/next steps in `progress`, hard rules in `constraints`, and don’t leave them only in chat or reminders.
@@ -23,6 +24,8 @@ Related terminology: [dominds-terminology.md](./dominds-terminology.md)
   - [B) Task-term memory: Taskdoc is the single source of truth](#b-task-term-memory-taskdoc-is-the-single-source-of-truth)
   - [C) Short-term memory: dialog history is a buffer, reminders are a working set](#c-short-term-memory-dialog-history-is-a-buffer-reminders-are-a-working-set)
 - [Day-to-day workflow (operational health)](#day-to-day-workflow-operational-health)
+  - [Where to write what (quick rules)](#where-to-write-what-quick-rules)
+  - [Memory vs skills: selection rules](#memory-vs-skills-selection-rules)
 
 ---
 
@@ -33,13 +36,17 @@ The same information can be categorized by “who needs to see it / who maintain
 - **Individual-scope (per-agent / per-dialog)**:
   - `persona` / `knowhow` / `pitfalls` (role definitions assigned per member)
   - individual memory (`personal_memory`)
+  - individual skills (`.minds/skills/individual/<member-id>/...`)
   - dialog history (including tool calls and outputs)
   - reminders (working set / worklog)
 - **Collective-scope (shared by team/task)**:
   - rtws-level “env notes” (`.minds/env*.md`): the workspace’s baseline facts, runtime constraints, and gotchas
   - team memory (`team_memory`)
+  - team-shared skills (`.minds/skills/team_shared/...`; the `linkable` pool is a reusable source maintained by team management)
   - Taskdoc: in a healthy workflow, the same Taskdoc is expected to be progressed by multiple Main Dialogs (different Dialog Responders), so treat it as the collective single source of truth
 
+Skills and memory are both long-lived context assets, but they are not the same thing: **memory is the storage layer for facts, indexes, and consensus; skills are the execution-guidance layer for reusable prompt skills and operating procedures**. At startup, the runtime lists summaries of visible skills and the model can call `read_skill` for the body when needed. Upstream metadata such as `allowed-tools` is advisory for migration only; it does not grant Dominds tool permissions. Team collaboration SOPs should usually be skills: they should describe collaboration roles, inputs/outputs, escalation rules, synchronization cadence, and acceptance policy instead of making current-workspace paths part of the body.
+
 ### Permissions and division of labor
 
 “Collective memory” does not mean “everyone can edit everything”. A core Dominds principle is social division of labor:
@@ -59,6 +66,7 @@ This doc uses three time horizons: long-term / task-term / short-term (dialog).
   - **Org structure (static definitions)**: `persona` / `knowhow` / `pitfalls`
   - **Team governance (shared)**: team memory
   - **Agent-owned**: individual memory
+  - **Reusable skill assets**: individual / team-shared skills (prompt guidance), plus MCP resource skills
 - **B) Task-term memory (survives dialog courses)**
   - **Auto-injected Taskdoc core**: `goals` / `constraints` / `progress`
   - **Extra Taskdoc sections (on-demand recall)**: the fixed `bearinmind/` set (`contracts` / `acceptance` / `grants` / `runbook` / `decisions` / `risks`), plus any task-specific sections (see [encapsulated-taskdoc.md](./encapsulated-taskdoc.md))
@@ -114,6 +122,31 @@ Key notes:
 - Personal memory is automatically isolated on disk under `.minds/memory/individual/<member-id>/...`, so your `path` must NOT include your member id (do not write `<member-id>/...`).
 - If you have zero personal memory entries, just call `add_personal_memory` — the directory will be created automatically.
 
+#### 4) Skills: reusable operating capability (prompt skill assets)
+
+Skills are for **procedural thinking**, **reusable operating paths**, and **trigger/boundary guidance**. A skill answers “when this class of task appears, how should I handle it?”, not “what facts are currently true in this workspace?”.
+
+Common forms:
+
+- Individual skill: `.minds/skills/individual/<member-id>/<skill-id>/`
+- Team-shared skill: `.minds/skills/team_shared/<skill-id>/`
+- MCP resource skill: a virtual skill exposed by MCP resources
+
+Good skill content:
+
+- portable debugging/review/design/acceptance routines
+- team collaboration SOPs, responsibility splits, handoff/escalation/synchronization flows, acceptance and rollback policy
+- task-class procedures, checklists, and failure-recovery strategies
+- applicability, non-applicability, and required permissions/tools/inputs
+
+Poor skill content:
+
+- current rtws paths, file indexes, architecture facts, or temporary state: use `personal_memory` / `team_memory` / `.minds/env*.md` / Taskdoc instead
+- quasi-real-time task state, next steps, or blockers: use Taskdoc `progress`
+- content that really needs scripts, privileged tools, MCP, external binaries, or reusable execution capability: elevate it into a Dominds app / toolset / teammate contract instead of leaving it as a Markdown skill
+
+A useful split: **workspace-coupled facts go to memory; workspace-independent operating methods go to skills**. If an experience contains both, split it: put the portable method in a skill, put this repo’s paths, command entrypoints, and local contracts in memory or env notes, and have the skill say to consult those assets first. If an SOP looks path-heavy, first try to abstract it into generic collaboration concepts; keep paths as binding data, not as the SOP body.
+
 ### B) Task-term memory: Taskdoc is the single source of truth
 
 Taskdocs are the canonical task contract shared by the team. They answer: what we want, what we must not violate, and where we are.
@@ -219,9 +252,26 @@ The goal for agents’ day-to-day work is not “write more docs”. It’s a lo
 - **Team memory `team_memory`**: stable team conventions and invariants (worth reusing)
 - **Env notes `.minds/env*.md`**: rtws baseline facts, runtime constraints, gotchas (align humans + all agents to the same environment)
 - **Individual memory `personal_memory`**: personal preferences + responsibility-area rtws index (keep accurate)
+- **Skills**: reusable operating guidance, checklists, triggers, and boundaries (portable procedure, not a fact warehouse)
 - **Reminders**: short-term, high-frequency details (working set / worklog; delete freely)
 - **Dialog history / tool output**: disposable by default; only keep distilled excerpts, not raw dumps
 
+### Memory vs skills: selection rules
+
+Ask four questions first:
+
+1. **Is it strongly tied to the current workspace?** Exact paths, symbols, interface facts, repo conventions, and rtws runtime constraints belong in memory/env; cross-workspace methods belong in skills.
+2. **Is it a fact or a method?** “File X owns Y” is memory. “When reviewing X-class changes, check A/B/C” is a skill.
+3. **Who needs it?** Stable facts everyone must share go to `team_memory`; team collaboration SOPs and team-wide procedures usually go to team-shared skills. A member’s entry map goes to `personal_memory`; that member’s operating preference goes to an individual skill.
+4. **Does it need real execution capability?** If it needs scripts, permissions, MCP, external binaries, or a stable UI/API, do not leave it as a skill only. Design an app/toolset/teammate contract and keep the skill as the usage/judgment guidance.
+
+Additional design considerations:
+
+- **Context budget**: memory should be short, exact, and frequently maintained; skills may be longer, but their summaries must help the model decide whether to call `read_skill`.
+- **Staleness cost**: facts that change with the repo should not be hidden inside skills, or skills become a stale knowledge source.
+- **Auditability**: team-shared skills and team memory are team assets and should be maintained by governance roles; personal assets must still be updated when they go stale.
+- **Language and semantics**: when user-facing semantics are involved, follow the project i18n rules; Chinese remains the semantic baseline.
+
 ### Caution/critical: stop the bleeding first
 
 When context health enters **caution/critical** (see [context-health.md](./context-health.md)), don’t keep piling on new inputs: