dominds 1.21.0 → 1.22.0

package/dist/access-control.js

@@ -58,6 +58,15 @@ function hasFileExtAccess(fileExtName, whitelist, blacklist) {
     }
     return false;
 }
+function resolveRtwsRelativePath(targetPath) {
+    const cwd = path_1.default.resolve(process.cwd());
+    const resolvedPath = path_1.default.resolve(cwd, targetPath);
+    const relativePath = path_1.default.relative(cwd, resolvedPath);
+    if (relativePath === '' || (!relativePath.startsWith('..') && !path_1.default.isAbsolute(relativePath))) {
+        return relativePath;
+    }
+    return null;
+}
 /**
  * Directory-specific pattern matching for access control.
  * This function determines if a target path (file or directory) should be controlled
@@ -175,15 +184,10 @@ function matchesPattern(targetPath, dirPattern) {
  * 6. If whitelist patterns exist but none match, deny access
  */
 function hasReadAccess(member, targetPath) {
-    // Get resolved relative path from rtws root
-    const cwd = path_1.default.resolve(process.cwd());
-    const resolvedPath = path_1.default.resolve(cwd, targetPath);
     // Ensure path is within rtws
-    if (!resolvedPath.startsWith(cwd)) {
+    const relativePath = resolveRtwsRelativePath(targetPath);
+    if (relativePath === null)
         return false;
-    }
-    // Get relative path from rtws root
-    const relativePath = path_1.default.relative(cwd, resolvedPath);
     // Taskdocs (`*.tsk/`) are encapsulated and hard-denied for all general file tools.
     if (isEncapsulatedTaskPath(relativePath)) {
         return false;
@@ -238,15 +242,10 @@ function hasReadAccess(member, targetPath) {
  * 6. If whitelist patterns exist but none match, deny access
  */
 function hasWriteAccess(member, targetPath) {
-    // Get resolved relative path from rtws root
-    const cwd = path_1.default.resolve(process.cwd());
-    const resolvedPath = path_1.default.resolve(cwd, targetPath);
     // Ensure path is within rtws
-    if (!resolvedPath.startsWith(cwd)) {
+    const relativePath = resolveRtwsRelativePath(targetPath);
+    if (relativePath === null)
         return false;
-    }
-    // Get relative path from rtws root
-    const relativePath = path_1.default.relative(cwd, resolvedPath);
     // Taskdocs (`*.tsk/`) are encapsulated and hard-denied for all general file tools.
     if (isEncapsulatedTaskPath(relativePath)) {
         return false;

package/dist/dialog-instance-registry.js

@@ -68,7 +68,7 @@ async function getOrRestoreMainDialog(rootId, status) {
     catch (_err) {
         diligencePushMax = diligence_1.DEFAULT_DILIGENCE_PUSH_MAX;
     }
-    const defaultDisableDiligencePush = diligencePushMax <= 0;
+    const defaultDisableDiligencePush = false;
     const rootStore = new persistence_1.DiskFileDialogStore(mainDialogId);
     const mainDialog = new dialog_1.MainDialog(rootStore, rootMetadata.taskDocPath, mainDialogId, rootMetadata.agentId, {
         messages: rootState.messages,
@@ -154,7 +154,10 @@ async function ensureDialogLoaded(mainDialog, targetId, status, visitedSelfIds =
         contextHealth: state.contextHealth,
         pendingCourseStartPrompt,
     });
-    sideDialog.disableDiligencePush = latest?.disableDiligencePush ?? false;
+    sideDialog.disableDiligencePush =
+        latest && typeof latest.disableDiligencePush === 'boolean'
+            ? latest.disableDiligencePush
+            : false;
     if (sideDialog.sessionSlug) {
         mainDialog.registerSideDialog(sideDialog);
     }

package/dist/docs/diligence-push.md

@@ -10,10 +10,17 @@ is often not what operators want: they want the agent to keep pushing forward un
 - legitimately suspends for a human decision (Q4H), or
 - legitimately suspends waiting for Side Dialogs (tellask/backfill).
 
-This document specifies a runtime mechanism ("diligence-push") that, for **main dialogs only**,
-prevents the dialog from stopping: whenever the driver would otherwise stop, it auto-sends a short
-diligence prompt (rendered as a normal user bubble) and continues generation, except when the dialog
-is legitimately suspended (Q4H or pending Side Dialogs).
+This document specifies two related runtime controls:
+
+- **Auto-continue injection**: for **main dialogs only**, whenever the driver would otherwise stop,
+  runtime auto-sends a short diligence prompt (rendered as a normal user bubble) and continues
+  generation, except when the dialog is legitimately suspended (Q4H or pending Side Dialogs).
+- **Required tool-use control**: for ordinary main and side dialog rounds, the Diligence Push
+  checkbox controls whether the provider request must end through a Dominds tool call. When checked,
+  the model is expected to call a tool such as `askHuman`, `tellask*`, `replyTellask*`, or another
+  runtime-provided function instead of stopping with a plain-text question/final answer. FBR middle
+  rounds are the intentional exception: they may run with no callable tools; FBR closure requires one
+  of the conclusion tools.
 
 ## Goals
 
@@ -25,7 +32,8 @@ is legitimately suspended (Q4H or pending Side Dialogs).
 ## Non-goals
 
 - Auto-completing / auto-marking a dialog as done.
-- Applying this behavior to Side Dialogs (Side Dialogs remain scoped and should report back to their tellasker).
+- Auto-injecting Diligence Push prompts into Side Dialogs (Side Dialogs remain scoped and should
+  report back to their tellasker).
 
 ## Definitions
 

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

@@ -9,7 +9,10 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 - 合法地暂停等待人类决策（Q4H），或
 - 合法地暂停等待支线对话（tellask/backfill）。
 
-本文档指定了一个运行时机制（"diligence-push"），仅针对**主线对话**，防止对话停止：每当驱动程序即将停止时，它会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的支线对话）。
+本文档指定两个相关但不同的运行时控制：
+
+- **自动续推注入**：仅针对**主线对话**，当驱动程序即将停止时，运行时会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的支线对话）。
+- **强制工具调用控制**：对于普通的主线/支线对话轮次，`鞭策` 勾选项控制本轮 provider 请求是否必须通过 Dominds 工具结束。勾选时，模型应通过 `askHuman`、`tellask*`、`replyTellask*` 或其他运行时函数完成这一轮，而不是用普通文本直接收尾。FBR 中间轮是刻意例外：它们可以处于无可调用工具状态；FBR 收口阶段则必须调用两个结论工具之一。
 
 ## 目标
 
@@ -21,7 +24,7 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 ## 非目标
 
 - 自动完成/自动将对话标记为完成。
-- 将此行为应用于支线对话（支线对话保持范围，应向其诉请者报告）。
+- 将自动鞭策语注入应用于支线对话（支线对话保持范围，应向其诉请者报告）。
 
 ## 定义
 

package/dist/docs/fbr.md

@@ -14,12 +14,12 @@ The mechanism is the runtime-enforced contract applied to the spawned Side Dialo
 
 ## 2. Design principles and tradeoffs
 
-### 2.1 Predictability first: FBR is tool-less until final closure
+### 2.1 Predictability first: FBR cannot use ordinary tools until final closure
 
 FBR is meant to be “reasoning over text”, not “an agent run that explores the environment”. To keep it safe and
 predictable, FBR Side Dialogs must be:
 
-- **tool-less by construction during divergence/convergence** (technically enforced; not “please don’t use tools”), and
+- **isolated from ordinary tools during divergence/convergence** (no tellask / file / shell / browser / rtws access; provider requests may use `tool_choice: "none"` or equivalent), and
 - **closure-only in the final stage** (exactly two conclusion functions, no other tools), and
 - **body-first** (the tellask body is the authoritative task context).
 
@@ -75,12 +75,12 @@ When driving an FBR Side Dialog created by `freshBootsReasoning({ tellaskContent
 Intuition: “fresh boots” means “fresh relative to the tellasker-side thread”, not “ignores baseline system rules”. Runtime may
 still inject baseline policy/safety/formatting context, but the tellask body remains the authority.
 
-### 4.2 Tool-less (prompt + technical enforcement)
+### 4.2 Tool isolation (prompt + technical enforcement)
 
 Tool-less FBR has two layers, both required:
 
 1. **Prompt contract**: the runtime must communicate the current phase constraints unambiguously.
-2. **API/transport contract**: divergence/convergence must be technically tool-less; final closure may expose exactly two conclusion functions and nothing else.
+2. **API/transport contract**: divergence/convergence must expose no callable Dominds tools; final closure may expose exactly two conclusion functions and nothing else.
 
 #### 4.2.1 System prompt requirements (no tool instructions)
 
@@ -110,12 +110,12 @@ If a provider integration normally injects a tool prompt or schema, then for FBR
 
 Under no circumstances should the FBR Side Dialog see any tool definitions.
 
-#### 4.2.3 The LLM request MUST be “zero tools”
+#### 4.2.3 Divergence/convergence requests expose no callable tools
 
-For divergence/convergence, the LLM request for an FBR Side Dialog (`freshBootsReasoning`) MUST have **zero tools available**:
+For divergence/convergence, the LLM request for an FBR Side Dialog (`freshBootsReasoning`) MUST have no callable Dominds tools available:
 
 - the request payload must not include tool/function definitions (effective tool list must be empty)
-- provider tool-calling / function-calling modes must not be enabled
+- provider tool-calling / function-calling modes should use `none` or the closest provider-equivalent disabled mode
 
 In the final closure phase, runtime MAY expose exactly these two functions and no others:
 
@@ -217,7 +217,7 @@ members:
 
 ## 9. Acceptance checklist
 
-- `freshBootsReasoning({ tellaskContent: "..." })` triggers tool-less FBR; the LLM request is technically “zero tools”.
+- `freshBootsReasoning({ tellaskContent: "..." })` triggers FBR; divergence/convergence expose no callable tools, and final closure requires one of the two conclusion tools.
 - The system prompt body contains no tool instructions; tool-related wording comes only from the separate fixed notice.
 - FBR Side Dialogs cannot issue teammate Tellasks (including `tellaskBack`).
 - `fbr-effort` defaults to `3`, accepts `0..100`, rejects invalid values, and fails loudly when disabled.

package/dist/docs/fbr.zh.md

@@ -12,11 +12,11 @@
 
 ## 2. 设计原则与取舍（为什么这样做）
 
-### 2.1 可预期优先：FBR 在最终收口前必须“无工具”
+### 2.1 可预期优先：FBR 在最终收口前不得使用普通工具
 
 FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请正文进行独立推理，而不是在工具、环境、副作用里游走。为此，FBR 支线对话必须满足：
 
-- **发散/收敛阶段技术上 0 工具**（不是“提示词里说别用工具”）
+- **发散/收敛阶段与普通工具隔离**（不能 tellask、读文件、跑 shell、浏览、访问 rtws；provider 请求可使用 `tool_choice: "none"` 或等价禁用模式）
 - **最终收口阶段只开放两个结论函数**
 - **上下文以诉请正文为权威**（不是“默认继承诉请者一侧历史”）
 
@@ -76,7 +76,7 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 FBR 的阶段性约束必须同时满足两类要求：
 
 1. **提示词契约**：运行时必须把当前阶段的能力边界表达得明确无歧义。
-2. **API/传输层契约**：发散/收敛阶段必须技术上“0 工具”；最终收口阶段只允许两个结论函数。
+2. **API/传输层契约**：发散/收敛阶段不得暴露任何可调用的 Dominds 工具；最终收口阶段只允许两个结论函数。
 
 #### 4.2.1 system prompt 的要求（不得包含工具说明）
 
@@ -106,12 +106,12 @@ FBR 支线对话的 system prompt 必须明确包含（措辞可不同，但语
 
 无论如何，FBR 支线对话都不应看到任何工具定义。
 
-#### 4.2.3 发散/收敛阶段的 LLM 请求必须是“0 工具”
+#### 4.2.3 发散/收敛阶段的 LLM 请求不得暴露可调用工具
 
-发起 `freshBootsReasoning` FBR 支线对话的 LLM 请求必须做到 **0 个可用工具**：
+发起 `freshBootsReasoning` FBR 支线对话的发散/收敛请求必须做到没有可调用的 Dominds 工具：
 
 - 请求 payload 中不得包含任何 tool/function 定义（有效工具列表必须为空）
-- 不得启用提供方支持的任何“工具调用模式 / 工具选择 / 函数调用”开关
+- provider 工具调用/函数调用模式应使用 `none` 或最接近的禁用模式
 
 最终收口阶段，运行时只可开放以下两个函数：
 
@@ -212,7 +212,7 @@ members:
 
 ## 9. 验收清单（实现检查点）
 
-- `freshBootsReasoning({ tellaskContent: "..." })` 触发 FBR：支线对话必须无工具，并且在 API 层确认为“0 工具”请求。
+- `freshBootsReasoning({ tellaskContent: "..." })` 触发 FBR：发散/收敛阶段不得暴露可调用工具；最终收口阶段必须调用两个结论工具之一。
 - system prompt 本体不含工具说明；工具相关文本只能来自独立、固定的“无工具提示”。
 - FBR 支线对话不得发起队友诉请（包括 `tellaskBack`）。
 - `fbr-effort` 默认 `3`，接受 `0..100`，禁用时明确报错拒绝。

package/dist/docs/llm-provider-isolation.md

@@ -12,6 +12,8 @@ This means:
 - `apiType: anthropic` owns official Anthropic Messages semantics, including object-shaped `model_params.anthropic.thinking`.
 - `apiType: anthropic-compatible` owns Anthropic-compatible gateway semantics, including boolean `model_params.anthropic-compatible.thinking` mapped to provider `enabled` / `disabled` request objects.
 
+Some providers expose OpenAI-compatible or Anthropic-compatible endpoints while still requiring an explicit provider quirk profile. Volcano Engine Ark Coding Plan is the canonical example: its OpenAI-compatible integration reuses the Chat Completions transport shape, but `thinking`, `reasoning_content`, tool-call/thinking alternation, `<think>` compatibility, and model capability metadata must stay inside the `volcengine-coding-plan` quirk instead of becoming generic `openai-compatible` semantics. See [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md) for the design record.
+
 Similar field names across wrappers do not imply compatibility. For example, `reasoning_effort`, `verbosity`, `parallel_tool_calls`, and web search controls may look similar but can still differ in accepted values, payload shape, lifecycle events, validation rules, and runtime meaning.
 
 ## Hard Rules

package/dist/docs/llm-provider-isolation.zh.md

@@ -12,6 +12,8 @@ Dominds 把每个 LLM provider wrapper 视为独立的协议适配器，而不
 - `apiType: anthropic` 只负责 Anthropic 官方 Messages 语义，包括 object 形态的 `model_params.anthropic.thinking`。
 - `apiType: anthropic-compatible` 负责 Anthropic 兼容网关语义，包括 boolean 形态的 `model_params.anthropic-compatible.thinking`，并映射为 provider 请求里的 `enabled` / `disabled` object。
 
+某些 provider 虽然暴露 OpenAI-compatible 或 Anthropic-compatible endpoint，但仍可能需要明确的 provider quirk profile。典型例子是火山方舟 Coding Plan：OpenAI-compatible 接入应复用 Chat Completions 的基础传输形态，但它的 `thinking`、`reasoning_content`、工具调用交替、`<think>` 兼容与模型能力表必须留在 `volcengine-coding-plan` 专项 quirk 中，不能进入通用 `openai-compatible` 语义。设计记录见 [`volcengine-coding-plan-openai-compatible.zh.md`](./volcengine-coding-plan-openai-compatible.zh.md)。
+
 不同 wrapper 下看起来同名的字段，不代表它们可以互相兼容。比如 `reasoning_effort`、`verbosity`、`parallel_tool_calls`、web search 相关开关，名字可能相似，但可接受值、请求载荷形状、流事件生命周期、校验规则和运行时含义都可能不同。
 
 ## 强约束

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

@@ -0,0 +1,120 @@
+# MCP Prompts and Resources
+
+This document defines how Dominds maps MCP prompts and resources into the runtime.
+It extends the tool-focused MCP support described in [mcp-support.md](./mcp-support.md).
+
+## Design Position
+
+MCP primitives have different control semantics:
+
+- **Tools** are model-controlled actions. Dominds exposes them as function tools.
+- **Prompts** are user-controlled templates. Dominds exposes them as read-only snippets.
+- **Resources** are application-controlled context objects. Dominds exposes them through a
+  resource registry and explicit read tools.
+
+Dominds should not flatten all MCP primitives into ordinary model tools. Doing so loses the
+control boundary that makes MCP debuggable and safe.
+
+## Prompts -> Read-Only Snippets
+
+MCP prompts are surfaced in the Snippets panel as read-only templates.
+
+Expected behavior:
+
+- `prompts/list` contributes dynamic snippet entries grouped by MCP server.
+- `prompts/get` renders a selected prompt before insertion.
+- 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.
+
+This keeps prompts user-selected while reusing the existing Dominds snippet workflow.
+
+## Resources -> Resource Registry
+
+MCP resources and resource templates are surfaced through a Dominds resource registry.
+
+Resource entries:
+
+- Static resources come from `resources/list`.
+- Resource templates come from `resources/templates/list`.
+- 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.
+
+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
+context surface.
+
+## Resource Tools
+
+Dominds provides explicit read-only tools:
+
+- `list_resources`: list available resources and resource templates.
+- `fetch_resource`: fetch a static resource or a rendered resource template.
+
+Template fetching requires `arguments`. Passing arguments to a static resource is an error.
+Missing template variables are errors. Oversized results and unsupported MIME types are errors,
+not silent fallbacks.
+
+## Resource Skills
+
+Markdown resources with valid Agent Skill frontmatter may be exposed as read-only virtual skills.
+
+Rules:
+
+- Resource skills are opt-in through `.minds/mcp.yaml`.
+- Only textual markdown resources are eligible.
+- 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.
+
+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.
+
+## Config Shape
+
+Example:
+
+```yaml
+version: 1
+servers:
+  workstation:
+    transport: streamable_http
+    url: http://127.0.0.1:43178/mcp
+    headers:
+      Authorization: Bearer dw
+
+    prompts:
+      whitelist:
+        - 'workstation.*'
+      transform:
+        - prefix: 'workstation_'
+
+    resources:
+      whitelist:
+        - 'workstation-handbook://*'
+        - 'workstation-skill://*'
+      blacklist:
+        - '*secret*'
+      transform:
+        - prefix: 'workstation_'
+      mimeTypes:
+        - text/markdown
+        - text/plain
+      maxBytes: 50000
+      skills:
+        enabled: true
+        whitelist:
+          - 'workstation-skill://*'
+        transform:
+          - prefix: 'workstation_skill_'
+```
+
+Filtering matches original MCP names/URIs/templates. Transforms only produce Dominds-local IDs.
+
+## Non-Goals
+
+- No write-back to MCP prompts or resources.
+- No automatic conversion of every markdown resource into a skill.
+- No implicit prompt/resource access for servers filtered out by `.minds/mcp.yaml`.
+- No compatibility fallback that silently calls MCP tools when resources or prompts fail.

package/dist/docs/mcp-support.md

@@ -15,6 +15,8 @@ MCP TypeScript SDK):
 
 - `.minds/mcp.yaml` loader with mandatory hot-reload.
 - MCP-derived tools/toolsets registered into the existing global tool(set) registry.
+- MCP prompts and resources are mapped separately from tools; see
+  [mcp-prompts-resources.md](./mcp-prompts-resources.md).
 - Supported transports: `stdio` and `streamable_http` (SSE transport is not supported as a separate
   config option).
 - rtws Problems surfaced to the WebUI (Problems pill + panel) for MCP and LLM provider

package/dist/docs/team_mgmt-toolset.md

@@ -326,8 +326,8 @@ used in `.minds/team.yaml` member configurations.
 
 - `openai`: uses the OpenAI **Responses API** (best for OpenAI official endpoints; requires a `/v1`-style `responses` endpoint)
 - `anthropic`: uses the official Anthropic **Messages API**. `model_params.anthropic.thinking` uses the official Anthropic object shape.
-- `anthropic-compatible`: uses Anthropic-compatible **Messages API** / coding-plan endpoints, e.g. Volcano Engine Coding Plan `.../api/coding`. `model_params.anthropic-compatible.thinking` uses the Dominds boolean switch: `true` sends `thinking.type=enabled`; `false` sends `thinking.type=disabled`.
-- `openai-compatible`: uses the OpenAI **Chat Completions API** (best for most “OpenAI-compatible” third-party/proxy endpoints; e.g. a manually configured Ark `.../api/v3` endpoint)
+- `anthropic-compatible`: uses Anthropic-compatible **Messages API**. `model_params.anthropic-compatible.thinking` uses the Dominds boolean switch: `true` sends `thinking.type=enabled`; `false` sends `thinking.type=disabled`.
+- `openai-compatible`: uses the OpenAI **Chat Completions API** (best for most “OpenAI-compatible” third-party/proxy endpoints; e.g. a manually configured Ark `.../api/v3` endpoint; Volcano Engine Ark Coding Plan must use its dedicated `.../api/coding/v3` endpoint and declare the matching quirk)
   - **Vision support**: if the provider/model supports multimodal Chat Completions, Dominds will pass tool-output images (`func_result_msg.contentItems[].type=input_image`, e.g. from MCP tools) to the model as `image_url` inputs after reading the persisted artifact; unsupported mime types are downgraded to text.
 
 ```yaml
@@ -394,11 +394,16 @@ Notes:
   - `content` / `sections`: inline team-management guidance shown in the `team_mgmt` MCP chapter (`sections` supports `[{ title, content }]` or `{ "<title>": "<content>" }`)
 - Missing manual does **not** mean the toolset is unavailable. Standard tool metadata comes from MCP
   `tools/list`; agents should continue by reading each tool’s own description/arguments. Dominds
-  still reports a warning so the team can add at least a short overall positioning note.
+  still reports a warning so the team can add at least a short overall positioning note and list
+  tool names to clarify attribution.
 - Team-manager recommendation: after MCP config validation passes, rely on MCP-provided tool
-  descriptions/arguments first, and still write a short positioning note for each MCP server. Use
-  `manual.contentFile` or inline `content + sections` for richer handwritten guidance such as
-  examples, pitfalls, safety boundaries, failure handling, and coordination norms.
+  descriptions/arguments first, and still write a short positioning note for each MCP server and
+  list tool names to make clear which tools belong to this toolset. Use `manual.contentFile` or
+  inline `content + sections` for richer handwritten guidance such as examples, pitfalls, safety
+  boundaries, failure handling, and coordination norms.
+- Tool-list writing rule: list tool names, with a short purpose group when useful; do not copy
+  parameter schemas or long tool descriptions, because those contracts are provided by
+  function-tool definitions in the system prompt.
 - Use a semi-structured chapter shape for optional enhancements: high-value sections often include
   `When To Use`, `Guardrails`, and `Business Handling When Unavailable`, but do not force every
   toolset into one fixed template.

package/dist/docs/team_mgmt-toolset.zh.md

@@ -267,8 +267,8 @@
 
 - `openai`：使用 OpenAI **Responses API**（适用于 OpenAI 官方；需要 `/v1` 语义的 `responses` 端点）
 - `anthropic`：使用 Anthropic 官方 **Messages API**。`model_params.anthropic.thinking` 使用 Anthropic 官方 object 形态。
-- `anthropic-compatible`：使用 Anthropic 兼容的 **Messages API** / Coding Plan 端点（例如 Volcano Engine Coding Plan `.../api/coding`）。`model_params.anthropic-compatible.thinking` 使用 Dominds boolean 开关：`true` 发送 `thinking.type=enabled`，`false` 发送 `thinking.type=disabled`。
-- `openai-compatible`：使用 OpenAI **Chat Completions API**（适用于多数“OpenAI 兼容”第三方/代理；例如手动配置的 Ark `.../api/v3` 端点）
+- `anthropic-compatible`：使用 Anthropic 兼容的 **Messages API**。`model_params.anthropic-compatible.thinking` 使用 Dominds boolean 开关：`true` 发送 `thinking.type=enabled`，`false` 发送 `thinking.type=disabled`。
+- `openai-compatible`：使用 OpenAI **Chat Completions API**（适用于多数“OpenAI 兼容”第三方/代理；例如手动配置的 Ark `.../api/v3` 端点；火山方舟 Coding Plan 必须使用专属 `.../api/coding/v3` 端点并声明对应 quirk）
   - **识图支持**：如果该 provider/model 支持 Chat Completions 的多模态输入，Dominds 会把工具输出里的图片（`func_result_msg.contentItems[].type=input_image`，来自 MCP 等工具）读取 artifact 后作为 `image_url` 形式喂给模型；不支持的 mimeType 会降级成文本提示。
 
 ```yaml
@@ -328,8 +328,9 @@ members:
 - 可选手册：可在 `.minds/mcp.yaml` 的 `servers.<serverId>.manual` 提供手册相关信息：
   - `contentFile`：正式 runtime 手册的 topic 文件目录前缀；`man({ "toolsetId": "<serverId>" })` 最终给 LLM 看的正文从这里加载，包括 `scenarios`、`errors` 等手写章节
   - `content` / `sections`：补充给 `team_mgmt` MCP 章节看的 inline 团队管理说明（`sections` 支持 `[{ title, content }]` 或 `{ "<title>": "<content>" }`）
-- 没有手册 **不代表** 该 toolset 不可用；标准工具元数据来自 MCP `tools/list`。智能体应继续依据每个工具自身的 description/参数来使用。Dominds 仍会发出 warning，提醒团队至少补充简短整体定位说明。
-- 建议团队管理者在 MCP 配置验证通过后，优先依赖 MCP server 暴露的工具 description/参数；同时给每个 MCP server 写一段简短定位。若需要更完整的综合示例、避坑指南、安全边界、故障处置或协作规范，再写 `manual.contentFile` 或 inline `content + sections`。
+- 没有手册 **不代表** 该 toolset 不可用；标准工具元数据来自 MCP `tools/list`。智能体应继续依据每个工具自身的 description/参数来使用。Dominds 仍会发出 warning，提醒团队至少补充简短整体定位说明，并列出工具名清单以澄清归属关系。
+- 建议团队管理者在 MCP 配置验证通过后，优先依赖 MCP server 暴露的工具 description/参数；同时给每个 MCP server 写一段简短定位，并列出工具名清单，明确“哪些工具属于这个 toolset”。若需要更完整的综合示例、避坑指南、安全边界、故障处置或协作规范，再写 `manual.contentFile` 或 inline `content + sections`。
+- 工具列表只列工具名即可，必要时补一句用途归类；不要复制参数 schema 或长篇工具 description，因为这些契约由系统提示里的函数工具定义提供。
 - 可选增强的章节组织建议采用“半结构化”：可优先考虑 `何时使用`、`安全边界`、`不可用时业务处置` 这类高价值章节，但不要求所有 toolset 都照抄同一模板。
 - 对高风险 MCP toolset，建议明确“不可用时业务处置规约”，至少回答：
   - 当前 toolset 暂不可达时，是否必须找协调者/专员接手

package/dist/docs/tool-availability-protocol.md

@@ -227,7 +227,10 @@ layer.
 
 - WebUI tools widget no longer caches authority snapshots per dialog.
 - The widget fetches a fresh `/api/tool-availability` snapshot and renders the composed visible
-  toolsets/direct tools for the current context.
+  toolsets/standalone tools for the current context.
+- Composition includes runtime-injected standalone tools such as `man` and `read_skill`, plus the
+  intrinsic `control` toolset with main-dialog vs side-dialog filtering, so the widget follows the
+  effective tools of a fresh drive/load rather than only static `.minds/team.yaml` bindings.
 - In-flight prompts are still not rewritten retroactively. A fresh drive/load uses the latest
   composed availability snapshot, which remains the intended contract.
 - App-controlled dynamic availability is still intentionally narrow in surface area: