dominds 0.7.6 → 0.8.2

package/dist/docs/fbr.zh.md

@@ -8,7 +8,7 @@
 
 **扪心自问（FBR, Fresh Boots Reasoning）** 是 Dominds 的一种工作机制：在主线对话推进过程中，智能体可以把一个边界清晰的子问题“拆出去”，以 **更干净的上下文** 重新推理一次，然后把结论回贴到主线对话中。
 
-在 Dominds 里，FBR 通过 **诉请（Tellask）语法** 触发，其中 `@self` 只是入口语法（“对当前对话自身发起诉请”）；FBR 的核心是运行时对这条支线对话施加的一组强制约束与并发语义。
+在 Dominds 里，FBR 通过专用函数工具 `freshBootsReasoning({ tellaskContent: "..." })` 触发；FBR 的核心是运行时对该支线对话施加的一组强制约束与并发语义。
 
 ## 2. 设计原则与取舍（为什么这样做）
 
@@ -23,31 +23,30 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 
 ### 2.2 不搞隐式魔法：禁用就要明确失败
 
-如果团队配置禁用了 FBR（例如 `fbr-effort: 0`），运行时必须 **对用户可见且清晰地拒绝** `!?@self`，避免“看起来发了诉请、实际上被静默忽略”的隐性失败。
+如果团队配置禁用了 FBR（例如 `fbr-effort: 0`），运行时必须 **对用户可见且清晰地拒绝** `freshBootsReasoning({ tellaskContent: "..." })`，避免“看起来发了诉请、实际上被静默忽略”的隐性失败。
 
 ### 2.3 多样本推理，而不是“多代理协作”
 
 `fbr-effort` 的并发语义并不是让多条支线相互对话或协作，而是 **并行产生多个互相独立的推理样本**，由主线对话负责综合提炼。
 
-## 3. 用户语法（`@self` 只是入口）
+## 3. 用户语法
 
 ### 3.1 触发语法
 
-以下两种语法都触发 FBR：
+触发 FBR 的语法只有一种：
 
-- **默认（瞬态）**：`!?@self`
-- **少用（可恢复）**：`!?@self !tellaskSession <tellaskSession>`
+- `freshBootsReasoning({ tellaskContent: "..." })`
 
 说明：
 
-- `@self` 表示“对当前对话自身（同一 agentId）发起诉请”。它是 **自诉请的显式语法**，用于避免把 `@teammate` 的引用/回声误判成“自己给自己诉请”。
-- FBR 的“可恢复”能力来自 `!tellaskSession`（Tellask 会话寻址），而不是来自 `@self` 本身。
+- FBR 不使用 `targetAgentId`、`sessionSlug`、`mentionList`。
+- `tellaskContent` 是 FBR 支线的权威任务上下文。
 
 ### 3.2 作用域
 
-本文档只定义 **FBR 机制**，并说明其通过 `!?@self` 触发的行为契约。一般的队友诉请（`!?@<teammate>`）仍按 [`dialog-system.zh.md`](./dialog-system.zh.md) 的 Tellask 分类与能力模型执行。
+本文档只定义 **FBR 机制**，并说明其通过 `freshBootsReasoning({ tellaskContent: "..." })` 触发的行为契约。一般的队友诉请（`tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })`）仍按 [`dialog-system.zh.md`](./dialog-system.zh.md) 的 Tellask 分类与能力模型执行。
 
-如果你需要“同人设但可用工具”的支线对话，不要用 `@self`；请使用一个明确的队友身份并授予其相应工具集（或用显式 `@<agentId>` 的一般诉请机制）。
+如果你需要“同人设但可用工具”的支线对话，请使用一般队友诉请路径，并显式指定队友身份。
 
 ## 4. 运行时契约（必须做到什么）
 
@@ -55,17 +54,16 @@ FBR 的价值来自“把推理拉回文本”：让被诉请者只围绕诉请
 
 ### 4.1 隔离与上下文
 
-当运行时驱动由 `!?@self` 创建的 FBR 支线对话时，必须强制满足：
+当运行时驱动由 `freshBootsReasoning({ tellaskContent: "..." })` 创建的 FBR 支线对话时，必须强制满足：
 
 - **不依赖诉请者对话上下文**：
   - 被诉请者不得假设能访问诉请者的主线/支线对话历史
   - 被诉请者必须把诉请正文当作主要且权威的任务上下文
-  - 若使用 `!tellaskSession`（可恢复）形式，被诉请者可以使用 **自身** 的 `tellaskSession` 历史作为显式上下文
 - **不得通过工具补上下文**：
   - 不得读文件/跑命令/浏览
   - 不得读取 Memory 或 rtws（运行时工作区）状态
 
-直觉上：FBR 的“初心”不是“忘掉一切系统规则”，而是“相对诉请者对话不继承历史”。运行时仍可能无条件注入基础规则（安全、格式、少量只读摘要等），但 **推理依据必须以诉请正文为主**（可恢复形式除外：可使用自身历史）。
+直觉上：FBR 的“初心”不是“忘掉一切系统规则”，而是“相对诉请者对话不继承历史”。运行时仍可能无条件注入基础规则（安全、格式、少量只读摘要等），但 **推理依据必须以诉请正文为主**。
 
 ### 4.2 无工具（提示词 + 技术强制）
 
@@ -81,7 +79,7 @@ FBR 支线对话的 system prompt 必须明确包含（措辞可不同，但语
 - 这是一次 FBR 支线对话，诉请正文是主要任务上下文
 - 不要假设能访问诉请者对话历史
 - 若诉请正文缺少关键上下文，需要列出缺失信息与阻塞原因
-- 仅当必须澄清关键缺失上下文时，允许 `!?@tellasker` 回问诉请者；除此之外不要发起任何诉请
+- 仅当必须澄清关键缺失上下文时，允许 `tellaskBack({ tellaskContent: "..." })` 回问诉请者；除此之外不要发起任何诉请
 
 同时，**system prompt 本体不得包含任何工具说明**（不得出现“有哪些工具/如何用工具/例子命令/白名单”等）。
 
@@ -104,16 +102,16 @@ FBR 支线对话的 system prompt 必须明确包含（措辞可不同，但语
 
 #### 4.2.3 LLM 请求必须是“0 工具”
 
-发起 `@self` FBR 支线对话的 LLM 请求必须做到 **0 个可用工具**：
+发起 `freshBootsReasoning` FBR 支线对话的 LLM 请求必须做到 **0 个可用工具**：
 
 - 请求 payload 中不得包含任何 tool/function 定义（有效工具列表必须为空）
 - 不得启用提供方支持的任何“工具调用模式 / 工具选择 / 函数调用”开关
 
 并且：如果模型仍尝试发出 tool/function call，运行时必须视为违规并硬拒绝（见 4.5）。
 
-### 4.3 诉请限制：仅允许 `!?@tellasker`
+### 4.3 诉请限制：仅允许 `tellaskBack({ tellaskContent: "..." })`
 
-FBR 支线对话不得发起任何队友诉请（包括 `!?@human`）。唯一例外是 `!?@tellasker`：
+FBR 支线对话不得发起任何队友诉请（包括 `askHuman({ tellaskContent: "..." })`）。唯一例外是 `tellaskBack({ tellaskContent: "..." })`：
 
 - 仅支线对话可用，用于回问上游诉请者对话
 - 仅当必须澄清关键缺失上下文时才允许
@@ -124,14 +122,14 @@ FBR 支线对话不得发起任何队友诉请（包括 `!?@human`）。唯一
 FBR 支线对话应产出一份便于诉请者整合的简明推理结果。推荐结构（不强制）：
 
 1. **结论 / 建议**
-2. **推理过程**（基于诉请正文；若为可恢复形式，可结合自身 `tellaskSession` 历史）
+2. **推理过程**（仅基于诉请正文）
 3. **前提假设**（明确标注来源：诉请正文/会话历史）
 4. **未知与缺口**（如果有）
 5. **给主线的下一步**（主线可能有工具/队友，可在主线执行）
 
 ### 4.5 违规与报错（必须“响亮可调试”）
 
-- 若 FBR 支线对话尝试发起违规诉请（非 `@tellasker`）或尝试 tool/function call，运行时必须硬拒绝该次驱动。
+- 若 FBR 支线对话尝试发起违规诉请（非 `tellaskBack({ tellaskContent: "..." })`）或尝试 tool/function call，运行时必须硬拒绝该次驱动。
 - 反馈必须 **对用户可见、语义清晰**，并且日志/事件中应包含可检索的错误原因字符串，避免静默吞掉。
 
 ## 5. 并发语义：`fbr-effort`
@@ -140,25 +138,22 @@ FBR 支线对话应产出一份便于诉请者整合的简明推理结果。推
 
 - 类型：整数
 - 默认：`3`
-- `0`：禁用该成员的 `!?@self` FBR（必须明确报错拒绝）
-- `1..100`：每次 `!?@self` 并发创建 N 条 FBR 支线对话
+- `0`：禁用该成员的 `freshBootsReasoning({ tellaskContent: "..." })` FBR（必须明确报错拒绝）
+- `1..100`：每次 `freshBootsReasoning({ tellaskContent: "..." })` 并发创建 N 条 FBR 支线对话
 - `> 100` / 非整数 / 负数：配置错误（直接报错，不做 clamp）
 
 当 `fbr-effort = N`：
 
-- 运行时必须把一条 `!?@self` 扩展为 **N 条并行的无工具 FBR 支线对话**
+- 运行时必须把一条 `freshBootsReasoning({ tellaskContent: "..." })` 扩展为 **N 条并行的无工具 FBR 支线对话**
 - 每条支线接收相同的诉请正文与相同的 FBR 提示词约束
 - 主线必须接收全部 N 条回贴；**不应依赖固定顺序**（可按完成顺序回贴）
 
-对可恢复的 `!?@self !tellaskSession <tellaskSession>` 形式，若 `N > 1`，运行时必须派生出 **不同的**
-会话键，使并行支线互不共享历史（推荐：`<tellaskSession>.fbr-<i>`）。
-
 ## 6. 模型参数覆盖：`fbr_model_params`
 
 `fbr_model_params` 用于只在驱动 FBR 支线对话时覆盖模型参数：
 
 - 结构：与 `model_params` 完全一致（参考 `dominds/main/llm/defaults.yaml` 的 `model_param_options`）
-- 作用域：仅对 `!?@self` FBR 生效
+- 作用域：仅对 `freshBootsReasoning({ tellaskContent: "..." })` FBR 生效
 - 合并：建议在成员的有效 `model_params` 之上做深合并覆盖（便于只改少数字段，如 `temperature`）
 - `max_tokens` 允许写成顶层 `max_tokens`，也允许写成 `general.max_tokens`；二选一，禁止同时设置
 
@@ -169,38 +164,25 @@ FBR 支线对话应产出一份便于诉请者整合的简明推理结果。推
 坏例（依赖外部上下文与工具）：
 
 ```text
-!?@self
-把 bug 找出来并修掉。
+freshBootsReasoning({ tellaskContent: "把 bug 找出来并修掉。" })
 ```
 
 好例（把关键上下文写进正文）：
 
 ```text
-!?@self
-你正在做无工具的 FBR。请只使用下方文本推理。
-
-目标：判断最可能的根因，并给出 2–3 个可行修复方向。
-
-现象：
-- 点击 “Run” 偶发卡死 ~10 秒。
-
-约束：
-- 不能改后端协议。
-
-线索（日志/片段）：
-<粘贴相关日志或代码片段>
+freshBootsReasoning({ tellaskContent: "你正在做无工具的 FBR。请只使用下方文本推理。\n\n目标：判断最可能的根因，并给出 2–3 个可行修复方向。\n\n现象：\n- 点击 \"Run\" 偶发卡死 ~10 秒。\n\n约束：\n- 不能改后端协议。\n\n线索（日志/片段）：\n<粘贴相关日志或代码片段>" })
 ```
 
 ### 7.2 `.minds/team.yaml`
 
 ```yaml
 member_defaults:
-  # 默认每次 `!?@self` 并发创建 3 条无工具 FBR 支线对话。
+  # 默认每次 `freshBootsReasoning({ tellaskContent: "..." })` 并发创建 3 条无工具 FBR 支线对话。
   fbr-effort: 3
 
 members:
   ux:
-    # 每次 `!?@self` 并发创建 5 条独立推理样本。
+    # 每次 `freshBootsReasoning({ tellaskContent: "..." })` 并发创建 5 条独立推理样本。
     fbr-effort: 5
 
     # 让 FBR 更“发散”，但不影响主线风格。
@@ -214,14 +196,14 @@ members:
 
 ## 8. 与一般支线对话的关系（避免混用）
 
-- `!?@self` 的 FBR 支线对话是 **特例**：无工具、正文优先、诉请受限、可并发扩展。
-- 一般的 `!?@<teammate>` 支线对话仍是“完整能力”的（可按配置拥有工具与工具集）。
-- 若你需要“同人设 + 可用工具”的支线，不要用 `@self`；请显式配置一个队友身份来承载这类工作线程。
+- `freshBootsReasoning({ tellaskContent: "..." })` 的 FBR 支线对话是 **特例**：无工具、正文优先、诉请受限、可并发扩展。
+- 一般的 `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })` 支线对话仍是“完整能力”的（可按配置拥有工具与工具集）。
+- 若你需要“同人设 + 可用工具”的支线，请使用显式队友身份（`tellask` / `tellaskSessionless`）。
 
 ## 9. 验收清单（实现检查点）
 
-- `!?@self` 触发 FBR：支线对话必须无工具，并且在 API 层确认为“0 工具”请求。
+- `freshBootsReasoning({ tellaskContent: "..." })` 触发 FBR：支线对话必须无工具，并且在 API 层确认为“0 工具”请求。
 - system prompt 本体不含工具说明；工具相关文本只能来自独立、固定的“无工具提示”。
-- FBR 支线对话不得发起队友诉请；仅允许必要时 `!?@tellasker` 回问。
+- FBR 支线对话不得发起队友诉请；仅允许必要时 `tellaskBack({ tellaskContent: "..." })` 回问。
 - `fbr-effort` 默认 `3`，接受 `0..100`，禁用时明确报错拒绝。
 - `fbr_model_params` 仅对 FBR 生效，且与 `model_params` 同结构、按深合并覆盖。

package/dist/docs/mottos.md

@@ -161,9 +161,8 @@ Taskdoc Structure:
 **In dominds (recommended syntax)**
 
 - Fresh Boots Reasoning (FBR) is **common**, and should usually be done via **transient self-subdialogs**.
-- Use `@self` (no `!tellaskSession`) for the default “fresh boots” session: isolate one sub-problem, answer, and return.
-- Use `@self !tellaskSession <tellaskSession>` **rarely**, only when you explicitly want a **resumable** long-lived fresh-boots session
-  for a multi-step sub-problem.
+- Use `freshBootsReasoning({ tellaskContent: "..." })` for the default “fresh boots” session: isolate one sub-problem, answer, and return.
+- Use `freshBootsReasoning({ tellaskContent: "..." })` whenever you need tool-less, clean-slate reasoning on a bounded sub-problem.
 
 **Traditional vs. Fresh Boots Approach**
 

package/dist/docs/mottos.zh.md

@@ -161,8 +161,8 @@
 **在 dominds 中（推荐语法）**
 
 - 扪心自问（FBR）是**常见的**，通常应该通过**瞬态子对话**完成。
-- 使用 `@self`（不带 `!tellaskSession`）进行默认的"初心"会话：隔离一个子问题，回答，然后返回。
-- **很少**使用 `@self !tellaskSession <tellaskSession>`，仅当你明确想要一个**可恢复的**长期初心会话用于多步骤子问题时。
+- 使用 `freshBootsReasoning({ tellaskContent: "..." })` 进行默认的“初心”会话：隔离一个子问题，回答，然后返回。
+- 需要对边界清晰的子问题做“无工具、清洁上下文”推理时，直接使用 `freshBootsReasoning({ tellaskContent: "..." })`。
 
 **传统 vs. 初心方法**
 

package/dist/docs/q4h.md

@@ -5,12 +5,12 @@ Chinese version: [中文版](./q4h.zh.md)
 ## Summary
 
 Q4H is Dominds’s mechanism for raising a human decision/clarification request from any dialog by issuing a Tellask to
-`@human` (`!?@human ...`). When a dialog enters Q4H, progression is suspended until the human responds.
+`askHuman()` (`!?askHuman() ...`). When a dialog enters Q4H, progression is suspended until the human responds.
 
 This document specifies a WebUI enhancement:
 
 1. **External deep links** that jump directly to a Q4H question’s call site (the place in the conversation where
-   `!?@human` was issued), and optionally **pre-select** the pending question so the input enters “answer mode”.
+   `!?askHuman()` was issued), and optionally **pre-select** the pending question so the input enters “answer mode”.
 2. A consistent **call site action UI**: internal navigation (same tab) vs external navigation (new tab/window).
 
 ## Goals
@@ -33,7 +33,7 @@ This document specifies a WebUI enhancement:
 ## Definitions (user-facing terms)
 
 - **Mainline dialog / sideline dialog**: user-facing terms for the primary thread and temporary work threads.
-- **Call site**: the location in the conversation where a Tellask was issued (for Q4H: where `!?@human` appears).
+- **Call site**: the location in the conversation where a Tellask was issued (for Q4H: where `!?askHuman()` appears).
 - **Answer mode**: the input is bound to a specific pending Q4H question so `Send` becomes “answer this question”.
 
 ## UX / Product Requirements
@@ -86,7 +86,7 @@ Recommended (optional but improves resilience / reduces dependency on global Q4H
 - `selfId`: originating dialog id (root or sideline)
 - `course`: course number (1-based)
 - `msg`: message index (best-effort fallback locator)
-- `callId`: tellask callId when the Q4H was created from an `!?@human` tellask block
+- `callId`: tellask callId when the Q4H was created from an `!?askHuman()` tellask block
 
 Behavior:
 
@@ -142,12 +142,12 @@ Notes:
 
 Existing persisted question shape includes:
 
-- `id`, `tellaskHead`, `bodyContent`, `askedAt`
+- `id`, `mentionList`, `tellaskContent`, `askedAt`
 - `callSiteRef: { course, messageIndex }`
 
 Enhancement:
 
-- Add optional `callId?: string` to Q4H questions created from an `!?@human` tellask block.
+- Add optional `callId?: string` to Q4H questions created from an `!?askHuman()` tellask block.
   - This enables precise call-site scrolling via `data-call-id` in the rendered DOM.
   - Questions created by system mechanisms that are not emitted from a tellask block MAY have no `callId`.
 

package/dist/docs/q4h.zh.md

@@ -4,11 +4,11 @@
 
 ## 摘要
 
-Q4H 是 Dominds 的运行时机制：在任何对话中通过向 `@human` 发起诉请（`!?@human ...`），把一个“必须由人类决策/澄清/确认”的问题抛给人类，并**合法暂停**对话推进，直到人类回应。
+Q4H 是 Dominds 的运行时机制：在任何对话中通过向 `askHuman()` 发起诉请（`!?askHuman() ...`），把一个“必须由人类决策/澄清/确认”的问题抛给人类，并**合法暂停**对话推进，直到人类回应。
 
 本文档指定一次 WebUI 增强：
 
-1. 支持 **外链 deep link（URL）**：打开后可直达某个 Q4H 的“提问点”（call site，即对话中出现 `!?@human` 的位置），并在条件允许时让输入框进入“回答模式”。
+1. 支持 **外链 deep link（URL）**：打开后可直达某个 Q4H 的“提问点”（call site，即对话中出现 `!?askHuman()` 的位置），并在条件允许时让输入框进入“回答模式”。
 2. 统一并增强 **call site 行为** 的 UI：同一处功能提供
    - **内链**（同一 tab 内导航）与
    - **外链**（新 tab/窗口打开）
@@ -36,7 +36,7 @@ Q4H 是 Dominds 的运行时机制：在任何对话中通过向 `@human` 发起
 ## 定义（使用者语境）
 
 - **主线对话 / 支线对话**：对外术语，用于描述主要推进线程与临时工作线程。
-- **提问点（call site）**：对话中发起诉请的具体位置；对 Q4H 即 `!?@human` 出现的位置。
+- **提问点（call site）**：对话中发起诉请的具体位置；对 Q4H 即 `!?askHuman()` 出现的位置。
 - **回答模式（answer mode）**：输入框绑定到某个待处理 Q4H 问题，`Send` 的语义变为“回答该问题”。
 
 ## UX / 产品需求
@@ -89,7 +89,7 @@ WebUI 通过 `window.location.search` 识别 deep link 参数。
 - `selfId`：来源对话 id（主线或支线）
 - `course`：course 编号（1-based）
 - `msg`：messageIndex（仅用于 best-effort 回退定位）
-- `callId`：当该 Q4H 来源于 `!?@human` 诉请块时，对应的 tellask `callId`（更精确的定位方式）
+- `callId`：当该 Q4H 来源于 `!?askHuman()` 诉请块时，对应的 tellask `callId`（更精确的定位方式）
 
 行为：
 
@@ -144,12 +144,12 @@ WebUI 通过 `window.location.search` 识别 deep link 参数。
 
 既有 Q4H 持久化字段：
 
-- `id`, `tellaskHead`, `bodyContent`, `askedAt`
+- `id`, `mentionList`, `tellaskContent`, `askedAt`
 - `callSiteRef: { course, messageIndex }`
 
 增强：
 
-- 为由 `!?@human` 诉请块产生的 Q4H 问题增加可选字段 `callId?: string`。
+- 为由 `!?askHuman()` 诉请块产生的 Q4H 问题增加可选字段 `callId?: string`。
   - 使前端可通过 `data-call-id` 精确滚动定位。
   - 对于非诉请块产生的系统型 Q4H，允许没有 `callId`。
 

package/dist/docs/tellask-collab.md

@@ -28,13 +28,13 @@ These points reflect current behavior in `dialog-system.md`, `fbr.md`, `dominds-
 
 ### 2.1 Three Tellask modes
 
-- `TellaskBack`: `!?@tellasker`
-- `Tellask Session`: `!?@<teammate> !tellaskSession <slug>`
-- `Fresh Tellask`: `!?@<teammate>`
+- `TellaskBack`: `tellaskBack({ tellaskContent: "..." })`
+- `Tellask Session`: `tellask({ targetAgentId: "<teammate>", sessionSlug: "<slug>", tellaskContent: "..." })`
+- `Fresh Tellask`: `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })`
 
 ### 2.2 What `Tellask Session` really means
 
-- `!tellaskSession <slug>` gives resumable addressing and reusable context.
+- `sessionSlug` gives resumable addressing and reusable context.
 - It does not create an always-running worker.
 - Progress still happens one Tellask call at a time.
 
@@ -93,7 +93,7 @@ That is a workflow break. The model should send the Tellask directly.
 
 ### 4.1 Four-step teammate Tellask loop
 
-For teammate Tellasks (non-`!?@self`), always run this loop:
+For teammate Tellasks (non-`freshBootsReasoning({ tellaskContent: "..." })`), always run this loop:
 
 1. `Initiate`: send a Tellask with scope, constraints, and acceptance evidence.
 2. `Wait`: wait for that specific response.
@@ -109,7 +109,7 @@ Hard rule:
 Recommended pattern:
 
 ```text
-!?@shell_specialist !tellaskSession typecheck-loop
+tellask({ targetAgentId: "shell_specialist", sessionSlug: "typecheck-loop", tellaskContent: "..." })
 !?Run `pnpm lint:types` and return raw output only.
 !?If it fails, include the first 3 errors with file + line.
 !?Acceptance: include exit code and the first actionable anchor.
@@ -132,7 +132,7 @@ I cannot run shell here; please ask @shell_specialist to execute `pnpm lint:type
 Good:
 
 ```text
-!?@shell_specialist !tellaskSession typecheck-loop
+tellask({ targetAgentId: "shell_specialist", sessionSlug: "typecheck-loop", tellaskContent: "..." })
 !?Please execute `pnpm lint:types` now and paste raw output.
 !?If command is unavailable, paste the error and one safe alternative.
 ```
@@ -152,8 +152,8 @@ Add or strengthen these coordination constraints:
 
 1. `Response-closes-call`: teammate response closes the current call; continuation requires a new Tellask.
 2. `Wait-state guard`: only claim waiting when a concrete pending Tellask exists.
-3. `Autonomy guard`: do not use @human as a relay for executable teammate work.
-4. `Action-over-narration`: if you write “next ask @X to do Y”, emit `!?@X ...` in the same turn.
+3. `Autonomy guard`: do not use askHuman() as a relay for executable teammate work.
+4. `Action-over-narration`: if you write “next ask @X to do Y”, emit `tellaskSessionless({ targetAgentId: "X", tellaskContent: "..." })` in the same turn.
 
 ### 5.2 Collaboration priming (P1)
 
@@ -161,13 +161,13 @@ Split the collaboration drill into two short segments, both grounded in verifiab
 
 1. One-shot Tellask: `uname -a` as the runtime baseline.
 2. Long-session Tellask: `tellaskSession: rtws-vcs-inventory` for a two-round repo inventory.
-3. Run `!?@self` FBR and distillation only after both evidence segments are available.
+3. Run `freshBootsReasoning({ tellaskContent: "..." })` FBR and distillation only after both evidence segments are available.
 
 Operating rules:
 
 1. If no `shell_specialist` is available, Dominds runtime gathers the same facts (`uname -a` + git inventory). This is a standard mode, not a degraded path.
 2. A response closes the current round; continuation requires a new explicit Tellask.
-3. “Ask teammate to do X” must materialize as `!?@...`, not as a relay request to @human.
+3. “Ask teammate to do X” must materialize as `tellask* function call`, not as a relay request to askHuman().
 
 ### 5.3 P1 design baseline (implemented)
 
@@ -192,7 +192,7 @@ Operating rules:
    - remotes (fetch/push)
    - branch / upstream
    - dirty state
-5. Merge `uname + VCS` into one evidence block for `!?@self` FBR.
+5. Merge `uname + VCS` into one evidence block for `freshBootsReasoning({ tellaskContent: "..." })` FBR.
 6. Distill after FBR feedback is complete, and produce the priming note.
 
 #### Tellask template constraints
@@ -234,7 +234,7 @@ Before and after each collaboration step:
 1. Did I send a concrete Tellask with acceptance evidence?
 2. If I say “waiting”, which pending Tellask am I waiting on?
 3. After receiving feedback, did I either close the task or send the next Tellask?
-4. Did I turn “ask teammate to do X” into an actual `!?@...` block?
+4. Did I turn “ask teammate to do X” into an actual `tellask* function call` block?
 5. Did I write key decisions back to Taskdoc instead of leaving them in chat only?
 
 ---

package/dist/docs/tellask-collab.zh.md

@@ -28,15 +28,15 @@
 
 ### 2.1 Tellask 三形态
 
-- `TellaskBack`（回问诉请）：`!?@tellasker`，用于向诉请者回问澄清。
-- `Tellask Session`（长线诉请）：`!?@<teammate> !tellaskSession <slug>`，可恢复上下文的多轮协作。
-- `Fresh Tellask`（一次性诉请）：`!?@<teammate>`，一次性、不可恢复。
+- `TellaskBack`（回问诉请）：`tellaskBack({ tellaskContent: "..." })`，用于向诉请者回问澄清。
+- `Tellask Session`（长线诉请）：`tellask({ targetAgentId: "<teammate>", sessionSlug: "<slug>", tellaskContent: "..." })`，可恢复上下文的多轮协作。
+- `Fresh Tellask`（一次性诉请）：`tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." })`，一次性、不可恢复。
 
 ### 2.2 `Tellask Session` 的真实语义
 
-- `!tellaskSession <slug>` 的作用是“会话寻址 + 历史复用”。
+- `sessionSlug` 的作用是“会话寻址 + 历史复用”。
 - 它**不是**“后台持续执行开关”。
-- 同一个 `<slug>` 下，每一次新任务推进，仍然需要新的 `!?@...` 诉请触发。
+- 同一个 `<slug>` 下，每一次新任务推进，仍然需要新的 `tellask* function call` 诉请触发。
 
 一句话：`Session` 是“可续接的对话容器”，不是“会自动前进的后台 worker”。
 
@@ -44,7 +44,7 @@
 
 对诉请者来说，一次队友诉请的运行时节奏是：
 
-1. 发出 `!?@<teammate> ...`。
+1. 发出 `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." }) ...`。
 2. 当前对话进入挂起/等待（pending subdialogs）。
 3. 被诉请者完成本轮驱动并回贴结果。
 4. 诉请者恢复继续。
@@ -90,12 +90,12 @@
 
 ### 4.1 协作阶段协议（Teammate Tellask 版）
 
-对**队友诉请（非 `!?@self`）**，统一执行四段协议：
+对**队友诉请（非 `freshBootsReasoning({ tellaskContent: "..." })`）**，统一执行四段协议：
 
-1. `发起`：明确目标、约束、验收口径，发出 `!?@...`。
+1. `发起`：明确目标、约束、验收口径，发出 `tellask* function call`。
 2. `等待`：等待本轮回贴，不预设对方会自动继续。
 3. `判定`：回贴到达后判断“已达成 / 未达成 / 需澄清”。
-4. `续推`：若未达成，立即发下一轮诉请（通常沿用同一 `!tellaskSession <slug>`）。
+4. `续推`：若未达成，立即发下一轮诉请（通常沿用同一 `sessionSlug`）。
 
 强约束：
 
@@ -107,7 +107,7 @@
 推荐写法：
 
 ```text
-!?@shell_specialist !tellaskSession typecheck-loop
+tellask({ targetAgentId: "shell_specialist", sessionSlug: "typecheck-loop", tellaskContent: "..." })
 !?执行 `pnpm lint:types`，仅回贴原始输出。
 !?若失败：只列前 3 个错误（含文件路径与行号），并给出你建议先处理的 1 个错误。
 !?验收：我需要看到命令退出码与首个错误锚点。
@@ -130,7 +130,7 @@
 正例（自主闭环）：
 
 ```text
-!?@shell_specialist !tellaskSession typecheck-loop
+tellask({ targetAgentId: "shell_specialist", sessionSlug: "typecheck-loop", tellaskContent: "..." })
 !?请立即执行 `pnpm lint:types` 并原样回贴结果。
 !?若命令不存在，回贴错误并给出本仓可行替代命令。
 ```
@@ -153,9 +153,9 @@
 2. `等待声明约束`  
    只有当存在明确 pending tellask 时，才可声明“等待中”；否则必须执行下一动作。
 3. `自主执行约束`  
-   能通过队友 tellask 完成的执行动作，不得转交给 @human 当“转发员”。
+   能通过队友 tellask 完成的执行动作，不得转交给 askHuman() 当“转发员”。
 4. `动作优先约束`  
-   当你写“下一步让 @X 做 Y”时，应在同一回复内直接给出 `!?@X ...`。
+   当你写“下一步让 @X 做 Y”时，应在同一回复内直接给出 `tellaskSessionless({ targetAgentId: "X", tellaskContent: "..." })`。
 
 ### 5.2 协作 Priming 改进（P1）
 
@@ -163,13 +163,13 @@
 
 1. 一次性诉请：`uname -a`（环境基线）。
 2. 长线诉请：`tellaskSession: rtws-vcs-inventory` 两轮盘点仓库现状。
-3. 在两段证据都到位后，再进入 `!?@self` FBR 和综合提炼。
+3. 在两段证据都到位后，再进入 `freshBootsReasoning({ tellaskContent: "..." })` FBR 和综合提炼。
 
 关键原则：
 
 1. 无可用 `shell_specialist` 时，由 Dominds 运行时采集同样事实（`uname -a` + git 盘点），这是标准模式，不是降级。
 2. 回贴即本轮结束；要继续必须显式发起下一轮诉请。
-3. “让队友做”必须直接落成 `!?@...`，不能转交 @human 当转发员。
+3. “让队友做”必须直接落成 `tellask* function call`，不能转交 askHuman() 当转发员。
 
 ### 5.3 P1 设计基线（当前实现）
 
@@ -184,7 +184,7 @@
 
 1. `Prelude Intro`：声明 shell 策略（`specialist_only` / `self_is_specialist` / `no_specialist`）。
 2. `uname` 基线：
-   - `specialist_only`：主线 `!?@<shell_specialist>` 发一次性诉请并接收回贴。
+   - `specialist_only`：主线 `tellaskSessionless({ targetAgentId: "<shell_specialist>", tellaskContent: "..." })` 发一次性诉请并接收回贴。
    - 其他两种策略：运行时采集并显示 `uname -a`。
 3. `VCS Round-1`（同一 `tellaskSession`）：确认 rtws 拓扑
    - 根路径是否 git repo
@@ -194,7 +194,7 @@
    - remote（fetch/push）
    - branch / upstream
    - dirty 状态
-5. 汇总 `uname + VCS` 作为同一份环境证据，发起 `!?@self` FBR。
+5. 汇总 `uname + VCS` 作为同一份环境证据，发起 `freshBootsReasoning({ tellaskContent: "..." })` FBR。
 6. 收齐 FBR 回贴后做 distillation，产出 priming note。
 
 #### 诉请模板约束
@@ -236,7 +236,7 @@
 1. 我这轮是否已经发出明确 tellask（有目标、约束、验收）？
 2. 我现在说“等待”时，是否真有 pending tellask 对应？
 3. 回贴到达后，我是否做了“判定 + 下一轮诉请/本地动作”？
-4. 我是否把“让队友做”落成了真实 `!?@...`，而不是口头转派给 @human？
+4. 我是否把“让队友做”落成了真实 `tellask* function call`，而不是口头转派给 askHuman()？
 5. 关键决策是否已写回 Taskdoc（主线）而不是只留在聊天里？
 
 ---

package/dist/llm/driver-entry.js

@@ -4,49 +4,25 @@ exports.getActiveDriverEngine = getActiveDriverEngine;
 exports.driveDialogStream = driveDialogStream;
 exports.emitSayingEvents = emitSayingEvents;
 exports.supplyResponseToSupdialog = supplyResponseToSupdialog;
+exports.restoreDialogHierarchy = restoreDialogHierarchy;
 exports.runBackendDriver = runBackendDriver;
-const driver_1 = require("./driver");
 const driver_v2_1 = require("./driver-v2");
-function resolveActiveDriverEngine() {
-    const raw = process.env.DOMINDS_DRIVER_ENGINE;
-    if (raw === undefined) {
-        return 'v2';
-    }
-    const normalized = raw.trim().toLowerCase();
-    if (normalized === '' || normalized === 'v2') {
-        return 'v2';
-    }
-    if (normalized === 'v1') {
-        return 'v1';
-    }
-    throw new Error(`Invalid DOMINDS_DRIVER_ENGINE=${JSON.stringify(raw)} (expected "v1" or "v2")`);
-}
-// Single switch point for rollout/tests.
-const ACTIVE_DRIVER_ENGINE = resolveActiveDriverEngine();
+const ACTIVE_DRIVER_ENGINE = 'v2';
 function getActiveDriverEngine() {
     return ACTIVE_DRIVER_ENGINE;
 }
 async function driveDialogStream(...args) {
-    if (ACTIVE_DRIVER_ENGINE === 'v2') {
-        return await (0, driver_v2_1.driveDialogStream)(...args);
-    }
-    return await (0, driver_1.driveDialogStream)(...args);
+    return await (0, driver_v2_1.driveDialogStream)(...args);
 }
 async function emitSayingEvents(...args) {
-    if (ACTIVE_DRIVER_ENGINE === 'v2') {
-        return await (0, driver_v2_1.emitSayingEvents)(...args);
-    }
-    return await (0, driver_1.emitSayingEvents)(...args);
+    return await (0, driver_v2_1.emitSayingEvents)(...args);
 }
 async function supplyResponseToSupdialog(...args) {
-    if (ACTIVE_DRIVER_ENGINE === 'v2') {
-        return await (0, driver_v2_1.supplyResponseToSupdialog)(...args);
-    }
-    return await (0, driver_1.supplyResponseToSupdialog)(...args);
+    return await (0, driver_v2_1.supplyResponseToSupdialog)(...args);
+}
+async function restoreDialogHierarchy(...args) {
+    return await (0, driver_v2_1.restoreDialogHierarchy)(...args);
 }
 function runBackendDriver() {
-    if (ACTIVE_DRIVER_ENGINE === 'v2') {
-        return (0, driver_v2_1.runBackendDriver)();
-    }
-    return (0, driver_1.runBackendDriver)();
+    return (0, driver_v2_1.runBackendDriver)();
 }