dominds 1.21.1 → 1.22.1

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,
@@ -85,10 +85,9 @@ async function getOrRestoreMainDialog(rootId, status) {
         ? latest.diligencePushRemainingBudget
         : undefined;
     const normalizedRemainingBudget = clampNonNegativeFiniteInt(persistedRemainingBudget, diligencePushMax > 0 ? diligencePushMax : 0);
-    mainDialog.diligencePushRemainingBudget =
-        diligencePushMax > 0
-            ? Math.min(normalizedRemainingBudget, diligencePushMax)
-            : normalizedRemainingBudget;
+    // `diligence-push-max` only seeds defaults. Persisted per-dialog budget is the runtime source of
+    // truth, including operator-added budget above (or despite) the current team default.
+    mainDialog.diligencePushRemainingBudget = normalizedRemainingBudget;
     mainDialog.setPersistenceStatus(status);
     dialog_global_registry_1.globalDialogRegistry.register(mainDialog);
     // Keep the in-memory main dialog fully hydrated regardless of persistence status
@@ -154,7 +153,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/dialog.d.ts

@@ -438,7 +438,7 @@ export declare abstract class Dialog {
     }): Promise<void>;
     persistAgentMessage(content: string, genseq: number, type: 'thinking_msg' | 'saying_msg', provider_data?: ProviderData, reasoning?: ReasoningPayload): Promise<void>;
     persistUiOnlyMarkdown(content: string, genseq: number): Promise<void>;
-    persistFunctionCall(id: string, name: string, rawArgumentsText: string, genseq: number): Promise<void>;
+    persistFunctionCall(id: string, name: string, rawArgumentsText: string, genseq: number, rawId?: string): Promise<void>;
     persistTellaskCall(id: string, name: TellaskCallRecordName, rawArgumentsText: string, genseq: number, options?: {
         deliveryMode?: 'tellask_call_start' | 'func_call_requested';
     }): Promise<void>;
@@ -670,7 +670,7 @@ export declare abstract class DialogStore {
     /**
      * Persist a function call to storage
      */
-    persistFunctionCall(_dialog: Dialog, _id: string, _name: string, _rawArgumentsText: string, _genseq: number): Promise<void>;
+    persistFunctionCall(_dialog: Dialog, _id: string, _name: string, _rawArgumentsText: string, _genseq: number, _rawId?: string): Promise<void>;
     persistTellaskCall(_dialog: Dialog, _id: string, _name: TellaskCallRecordName, _rawArgumentsText: string, _genseq: number, _options?: {
         deliveryMode?: 'tellask_call_start' | 'func_call_requested';
     }): Promise<void>;

package/dist/dialog.js

@@ -1452,8 +1452,8 @@ class Dialog {
     async persistUiOnlyMarkdown(content, genseq) {
         return await this.dlgStore.persistUiOnlyMarkdown(this, content, genseq);
     }
-    async persistFunctionCall(id, name, rawArgumentsText, genseq) {
-        return await this.dlgStore.persistFunctionCall(this, id, name, rawArgumentsText, genseq);
+    async persistFunctionCall(id, name, rawArgumentsText, genseq, rawId) {
+        return await this.dlgStore.persistFunctionCall(this, id, name, rawArgumentsText, genseq, rawId);
     }
     async persistTellaskCall(id, name, rawArgumentsText, genseq, options) {
         return await this.dlgStore.persistTellaskCall(this, id, name, rawArgumentsText, genseq, options);
@@ -1895,7 +1895,7 @@ class DialogStore {
     /**
      * Persist a function call to storage
      */
-    async persistFunctionCall(_dialog, _id, _name, _rawArgumentsText, _genseq) { }
+    async persistFunctionCall(_dialog, _id, _name, _rawArgumentsText, _genseq, _rawId) { }
     async persistTellaskCall(_dialog, _id, _name, _rawArgumentsText, _genseq, _options) { }
     /**
      * Start a new course in storage

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
 
@@ -74,15 +82,20 @@ To avoid infinite loops, diligence-push has a per-dialog budget (per-member `dil
 how many auto-continued diligence prompts can be injected for a given dialog before the runtime stops
 issuing further automatic Diligence Pushes for that budget.
 
-- Default: **3**
-- If `< 1`, diligence-push is effectively disabled for that member
+- Default: **99**
+- If `< 1`, new dialogs start with no automatic Diligence Push budget
 - Configurable per-member via `diligence-push-max` in `.minds/team.yaml`
 
-### Reset on Q4H
+Important: `diligence-push-max` is only the default budget used when a dialog instance is created
+or reset. Runtime decisions must use the concrete dialog's remaining budget
+(`diligencePushRemainingBudget`), so a manually refilled dialog can keep auto-continuing even when
+the team default is `0`.
 
-When a dialog becomes suspended due to a pending Q4H (Questions for Human), the diligence-push injection
-counter is reset. This ensures that after the human answers the Q4H and the dialog is resumed, the
-dialog gets a fresh diligence-push budget again.
+### Q4H suspension
+
+When a dialog becomes suspended due to a pending Q4H (Questions for Human), Diligence Push stops
+while that suspension is active. Q4H does not reapply the member default budget; the dialog keeps its
+own remaining budget so operator adjustments survive the suspension boundary.
 
 ### Budget exhausted → stop auto-pushing for that budget
 
@@ -95,9 +108,8 @@ Diligence-push can be disabled per-rtws in either of these ways:
 
 - If the selected diligence file exists but its content is empty/whitespace, diligence-push is disabled (no injection).
 
-Diligence-push can be disabled per-member in either of these ways:
-
-- If `diligence-push-max < 1`, diligence-push is disabled for that member (no injection).
+To stop auto-continue for a specific dialog, set that dialog's remaining budget to `0` or use the
+per-dialog Diligence Push disable switch.
 
 ## Diligence prompt resolution
 
@@ -114,9 +126,10 @@ If the first existing file in the above order has empty/whitespace content, **di
 Note: YAML frontmatter in diligence files is **ignored** by the runtime. If present, it is treated as
 non-content metadata and stripped from the prompt body.
 
-### Team member cap: `diligence-push-max`
+### Team member default budget: `diligence-push-max`
 
-Each team member can optionally cap diligence-push via `.minds/team.yaml`:
+Each team member can optionally set the starting Diligence Push budget for new or reset dialogs via
+`.minds/team.yaml`:
 
 ```yaml
 members:
@@ -127,7 +140,9 @@ members:
 Rules:
 
 - If missing, `diligence-push-max` defaults to **99** for that member.
-- If `diligence-push-max < 1`, diligence-push is disabled for that member (no injection), even if the diligence file exists.
+- If `diligence-push-max < 1`, newly created dialogs start with remaining budget `0`.
+- After creation or reset, runtime business logic follows the dialog's own remaining budget rather
+  than treating `diligence-push-max` as runtime authority.
 - Built-in shadow members `fuxi` and `pangu` default to `diligence-push-max: 0` unless explicitly overridden in team.yaml.
 
 ## UX notes

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 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 ## 非目标
 
 - 自动完成/自动将对话标记为完成。
-- 将此行为应用于支线对话（支线对话保持范围，应向其诉请者报告）。
+- 将自动鞭策语注入应用于支线对话（支线对话保持范围，应向其诉请者报告）。
 
 ## 定义
 
@@ -67,12 +70,15 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 为避免无限循环，diligence-push 有一个按对话的预算（每个成员的 `diligence-push-max`），控制对于给定对话在当前预算内还能注入多少个自动继续的鞭策语；预算耗尽后，运行时会停止继续自动鞭策。
 
 - 默认值：**99**
-- 如果 `< 1`，则该成员的 diligence-push 有效禁用
+- 如果 `< 1`，则新建对话从 0 个自动鞭策预算开始
 - 可通过 `.minds/team.yaml` 中的 `diligence-push-max` 按成员配置
 
-### Q4H 时重置
+重要：`diligence-push-max` 只是在创建或重置对话实例时使用的默认预算。运行时业务判断必须以具体对话自己的剩余预算
+（`diligencePushRemainingBudget`）为准；因此即使团队默认值是 `0`，手工补充过预算的对话也应继续自动鞭策。
+
+### Q4H 暂停
 
-当对话因待处理的 Q4H（Questions for Human）而暂停时，diligence-push 注入计数器会被重置。这确保在人类回答 Q4H 并恢复对话后，对话会获得新的 diligence-push 预算。
+当对话因待处理的 Q4H（Questions for Human）而暂停时，鞭策会在该暂停期间停止。Q4H 不会重新套用成员默认预算；对话会保留自己的剩余预算，因此操作员调整过的预算能跨过暂停边界继续生效。
 
 ### 预算耗尽 → 停止继续自动鞭策当前预算
 
@@ -84,9 +90,7 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 
 - 如果选中的鞭策语文件存在但其内容为空/仅空白，则禁用 diligence-push（不注入）。
 
-可以通过以下任一方式按成员禁用 diligence-push：
-
-- 如果 `diligence-push-max < 1`，则该成员的 diligence-push 被禁用（不注入）。
+若要停止某个具体对话的自动续推，应将该对话的剩余预算设为 `0`，或使用该对话自己的鞭策禁用开关。
 
 ## 鞭策语解析
 
@@ -102,9 +106,9 @@ Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）
 
 注意：鞭策语文件中的 YAML frontmatter 会被运行时忽略。如果存在，它被视为非内容元数据并从提示正文中剥离。
 
-### 团队成员上限：`diligence-push-max`
+### 团队成员默认预算：`diligence-push-max`
 
-每个团队成员可以选择通过 `.minds/team.yaml` 限制 diligence-push：
+每个团队成员可以选择通过 `.minds/team.yaml` 设置新建或重置对话的鞭策起始预算：
 
 ```yaml
 members:
@@ -115,7 +119,8 @@ members:
 规则：
 
 - 如果缺失，`diligence-push-max` 对于该成员默认为 **99**。
-- 如果 `diligence-push-max < 1`，则该成员的 diligence-push 被禁用（不注入），即使鞭策语文件存在。
+- 如果 `diligence-push-max < 1`，则新建对话的剩余预算从 `0` 开始。
+- 创建或重置之后，运行时业务逻辑以对话自己的剩余预算为准，而不是再次把 `diligence-push-max` 当作启停闸门。
 - 内置影子成员 `fuxi` 和 `pangu` 默认为 `diligence-push-max: 0`，除非在 team.yaml 中显式覆盖。
 
 ## UX 备注

package/dist/docs/dominds-terminology.md

@@ -425,11 +425,11 @@ Example / 示例（概念）:
 
 ### Diligence Push（鞭策）
 
-- EN: A proactive continuation mechanism that nudges an agent forward when it's idle or blocked (a "Diligence Push"), using configurable prompts and budget limits. **Always use "Diligence Push"; never use "keep-going", "勤奋", "proactive-push", or "auto-continue".**
-- ZH: 一种主动继续机制，在智能体空闲或阻塞时通过可配置的提示词和预算上限进行"鞭策"。**统一使用"鞭策"；禁止使用"保持运行"、"勤奋"、"自动继续"、"催促"等变体。**
+- EN: A proactive continuation mechanism that nudges an agent forward when it's idle or blocked (a "Diligence Push"), using configurable prompts and per-dialog remaining budgets. **Always use "Diligence Push"; never use "keep-going", "勤奋", "proactive-push", or "auto-continue".**
+- ZH: 一种主动继续机制，在智能体空闲或阻塞时通过可配置的提示词和每个对话自己的剩余预算进行"鞭策"。**统一使用"鞭策"；禁止使用"保持运行"、"勤奋"、"自动继续"、"催促"等变体。**
 
 - EN: Related terms: "Diligence Push prompt" (prompt file), "Diligence Push-max" config, "Diligence Push injection" (prompt injection).
-- ZH: 相关术语："鞭策提示词"（提示词文件）、"鞭策上限"（配置项）、"鞭策注入"（注入机制）。
+- ZH: 相关术语："鞭策提示词"（提示词文件）、"鞭策默认预算"（配置项）、"鞭策注入"（注入机制）。
 
 ### 用词原则：者 / 器 与 -or / -er
 

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 explicit provider quirks. Volcano Engine Ark Coding Plan now uses the OpenAI-compatible Chat Completions shape with its dedicated `/api/coding/v3` endpoint; the historical Anthropic-compatible Volcano tool-call quirks have been removed. 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 形态，并使用专属 `/api/coding/v3` endpoint；历史 Anthropic-compatible 火山工具调用 quirk 已取消。设计记录见 [`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)
   - **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

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` 端点）
   - **识图支持**：如果该 provider/model 支持 Chat Completions 的多模态输入，Dominds 会把工具输出里的图片（`func_result_msg.contentItems[].type=input_image`，来自 MCP 等工具）读取 artifact 后作为 `image_url` 形式喂给模型；不支持的 mimeType 会降级成文本提示。
 
 ```yaml

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: