dominds 1.18.2 → 1.19.2

package/dist/docs/diligence-push.md

@@ -4,20 +4,20 @@ Chinese version: [中文版](./diligence-push.zh.md)
 
 ## Summary
 
-Dominds root dialogs are intended for long-run operation. A root dialog "stopping" (becoming idle)
+Dominds main dialogs are intended for long-run operation. A main dialog "stopping" (becoming idle)
 is often not what operators want: they want the agent to keep pushing forward until it either:
 
 - legitimately suspends for a human decision (Q4H), or
-- legitimately suspends waiting for subdialogs (tellask/backfill).
+- legitimately suspends waiting for Side Dialogs (tellask/backfill).
 
-This document specifies a runtime mechanism ("diligence-push") that, for **root/main dialogs only**,
+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 subdialogs).
+is legitimately suspended (Q4H or pending Side Dialogs).
 
 ## Goals
 
-- Prevent root dialogs from stopping except for legitimate suspension states (Q4H / subdialogs).
+- Prevent main dialogs from stopping except for legitimate suspension states (Q4H / Side Dialogs).
 - Keep behavior predictable and bounded (no infinite loops).
 - Make the Diligence Push text configurable per rtws (runtime workspace) and language.
 - Provide a clear, user-controlled "disable" mechanism.
@@ -25,12 +25,12 @@ is legitimately suspended (Q4H or pending subdialogs).
 ## Non-goals
 
 - Auto-completing / auto-marking a dialog as done.
-- Applying this behavior to subdialogs (subdialogs remain scoped and should report back to their caller).
+- Applying this behavior to Side Dialogs (Side Dialogs remain scoped and should report back to their tellasker).
 
 ## Definitions
 
-- **Root/main dialog**: a `RootDialog` (`dlg.id.rootId === dlg.id.selfId`), the primary conversation thread.
-- **Subdialog**: a `SubDialog`, created for tellask / scoped work.
+- **Main Dialog**: a `MainDialog` (`dlg.id.rootId === dlg.id.selfId`), the primary conversation thread.
+- **SideDialog**: a `SideDialog`, created for tellask / scoped work.
 - **Q4H**: "Questions for Human", initiated via `askHuman()`, which suspends dialog progression until the human responds.
 
 ## Expected "normal" completion path (recommended)
@@ -40,7 +40,7 @@ When the agent needs a human decision to conclude (e.g., confirm a choice or dec
 1. The agent issues a Q4H (`askHuman()`) with the necessary context and explicit decision request.
 2. The WebUI surfaces the Q4H clearly.
 3. The human decides and either:
-   - marks the root dialog "done" manually, or
+   - marks the main dialog "done" manually, or
    - provides the requested info so the dialog can proceed.
 
 This is the "controlled convergence" path. The diligence-push mechanism should **not** override legitimate suspension states.
@@ -49,19 +49,19 @@ This is the "controlled convergence" path. The diligence-push mechanism should *
 
 ### Trigger conditions (must all hold)
 
-- Dialog is the **root/main dialog** (never for subdialogs).
+- Dialog is the **Main Dialog** (never for Side Dialogs).
 - Dialog is **not suspended**:
   - no pending Q4H, and
-  - no pending subdialogs (waiting for backfill).
+  - no pending Side Dialogs (waiting for backfill).
 - The driver would otherwise stop the generation loop (i.e., no tool/function outputs require another iteration).
 
 ### Exception: provider deadlock recovery
 
 Some provider/API quirk handlers may request a one-time Diligence Push recovery after Dominds stops
 same-context retries for a known deadlock pattern. This is not the ordinary "dialog is about to go
-idle" path. In that recovery-only case, pending subdialogs do not veto the single Diligence Push
+idle" path. In that recovery-only case, pending sideDialogs do not veto the single Diligence Push
 injection, because the deadlock may happen in a function-result-driven generation round right after
-the root dialog has already registered an in-flight tellask/subdialog. Q4H remains a hard blocker.
+the main dialog has already registered an in-flight tellask/sideDialog. Q4H remains a hard blocker.
 
 ### Action
 
@@ -145,9 +145,9 @@ Rules:
 Implemented in the kernel driver loop (`dominds/main/llm/kernel-driver/drive.ts`) as a small
 post-iteration check:
 
-1. If the dialog is suspended, stop (Q4H / subdialog pending), except for the deadlock-recovery
+1. If the dialog is suspended, stop (Q4H / sideDialog pending), except for the deadlock-recovery
    special case described above where one recovery-only Diligence Push may ignore pending
-   subdialogs.
+   sideDialogs.
 2. If there is any tool feedback, continue normally.
 3. Otherwise (root only), attempt diligence-push auto-continue:
    - If disabled → stop normally.
@@ -181,9 +181,9 @@ Recommended follow-ups (not required for initial implementation):
 
 Regression tests should cover:
 
-- Root dialog: tool-only output → diligence injection → continued response
-- Root dialog: empty assistant output → diligence injection → continued response
-- Subdialog: no diligence injection
+- Main dialog: tool-only output → diligence injection → continued response
+- Main dialog: empty assistant output → diligence injection → continued response
+- SideDialog: no diligence injection
 - rtws config:
   - `.minds/diligence.md` is honored when lang-specific file is absent
   - empty diligence file disables diligence-push

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

@@ -4,16 +4,16 @@
 
 ## 概述
 
-Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常不是操作员想要的：他们希望智能体持续推进，直到：
+Dominds 主线对话旨在长期运行。主线对话"停止"（变为空闲）通常不是操作员想要的：他们希望智能体持续推进，直到：
 
 - 合法地暂停等待人类决策（Q4H），或
-- 合法地暂停等待子对话（tellask/backfill）。
+- 合法地暂停等待支线对话（tellask/backfill）。
 
-本文档指定了一个运行时机制（"diligence-push"），仅针对**根/主对话**，防止对话停止：每当驱动程序即将停止时，它会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的子对话）。
+本文档指定了一个运行时机制（"diligence-push"），仅针对**主线对话**，防止对话停止：每当驱动程序即将停止时，它会自动发送一个简短的鞭策语（渲染为正常的用户气泡）并继续生成，除非对话处于合法暂停状态（Q4H 或待处理的支线对话）。
 
 ## 目标
 
-- 防止根对话停止，除非处于合法暂停状态（Q4H / 子对话）。
+- 防止主线对话停止，除非处于合法暂停状态（Q4H / 支线对话）。
 - 保持行为可预测和有界（无无限循环）。
 - 使鞭策语文本可按 rtws（运行时工作区）和语言配置。
 - 提供清晰的用户控制的"禁用"机制。
@@ -21,12 +21,12 @@ Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常
 ## 非目标
 
 - 自动完成/自动将对话标记为完成。
-- 将此行为应用于子对话（子对话保持范围，应向其调用者报告）。
+- 将此行为应用于支线对话（支线对话保持范围，应向其诉请者报告）。
 
 ## 定义
 
-- **根/主对话**：`RootDialog`（`dlg.id.rootId === dlg.id.selfId`），主要对话线程。
-- **子对话**：`SubDialog`，为 tellask / 作用域工作创建。
+- **主线对话**：`MainDialog`（`dlg.id.rootId === dlg.id.selfId`），主要对话线程。
+- **支线对话**：`SideDialog`，为 tellask / 作用域工作创建。
 - **Q4H**："Questions for Human"，通过 `askHuman()` 发起，暂停对话进度直到人类响应。
 
 ## 预期的"正常"完成路径（推荐）
@@ -36,7 +36,7 @@ Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常
 1. 智能体发出 Q4H（`askHuman()`）并提供必要的上下文和明确的决策请求。
 2. WebUI 清楚地呈现 Q4H。
 3. 人类决定并：
-   - 手动将根对话标记为"完成"，或
+   - 手动将主线对话标记为"完成"，或
    - 提供请求的信息以便对话继续。
 
 这是"受控收敛"路径。diligence-push 机制不应覆盖合法的暂停状态。
@@ -45,17 +45,17 @@ Dominds 根对话旨在长期运行。根对话"停止"（变为空闲）通常
 
 ### 触发条件（必须全部满足）
 
-- 对话是**根/主对话**（绝不会是子对话）。
+- 对话是**主线对话**（绝不会是支线对话）。
 - 对话**未暂停**：
   - 没有待处理的 Q4H，并且
-  - 没有待处理的子对话（等待回填）。
+  - 没有待处理的支线对话（等待回填）。
 - 驱动程序即将停止生成循环（即没有工具/函数输出需要另一次迭代）。
 
 ### 例外：provider deadlock recovery
 
 某些 provider/API quirk 在识别到已知的 same-context deadlock，并停止沿用同一上下文自动重试后，
 会请求一次性的鞭策恢复。这不是普通的“对话即将空转停止”路径。在这个仅用于恢复的特例里，
-即使根对话已经登记了在途诉请/支线对话，pending subdialog 也不应否决这一次鞭策注入；因为卡死
+即使主线对话已经登记了在途诉请/支线对话，pending sideDialog 也不应否决这一次鞭策注入；因为卡死
 可能正发生在函数结果驱动的生成轮次里。Q4H 仍然是硬阻塞条件。
 
 ### 操作
@@ -130,10 +130,10 @@ members:
 
 在 kernel driver 循环中实现（`dominds/main/llm/kernel-driver/drive.ts`），作为迭代后的小检查：
 
-1. 如果对话处于暂停状态，则停止（Q4H / 子对话待处理）；但上文所述 deadlock-recovery 特例除外，
-   即那一次恢复专用的鞭策可忽略 pending subdialog。
+1. 如果对话处于暂停状态，则停止（Q4H / 支线对话待处理）；但上文所述 deadlock-recovery 特例除外，
+   即那一次恢复专用的鞭策可忽略 pending sideDialog。
 2. 如果有任何工具反馈，则正常继续。
-3. 否则（仅限根），尝试 diligence-push 自动继续：
+3. 否则（仅限主线对话），尝试 diligence-push 自动继续：
    - 如果禁用 → 正常停止。
    - 如果预算耗尽 → 发出一条仅用于提示的 UI 信息，并停止继续自动鞭策当前预算。
    - 否则 → 自动发送鞭策语并继续。
@@ -164,9 +164,9 @@ members:
 
 回归测试应覆盖：
 
-- 根对话：仅工具输出 → 鞭策语注入 → 继续响应
-- 根对话：空助手输出 → 鞭策语注入 → 继续响应
-- 子对话：无鞭策语注入
+- 主线对话：仅工具输出 → 鞭策语注入 → 继续响应
+- 主线对话：空助手输出 → 鞭策语注入 → 继续响应
+- 支线对话：无鞭策语注入
 - rtws 配置：
   - 当语言特定文件缺失时，`.minds/diligence.md` 被遵守
   - 空的鞭策语文件禁用 diligence-push

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

@@ -41,7 +41,7 @@ Dominds 团队成员通常由以下几类信息组成：
 
 - **主线对话**：承载当前任务的共享差遣牒，负责整体推进。
 - **支线对话**：围绕某个分项任务临时展开的工作对话。
-- **诉请者对话 / 被诉请者对话**：一次协作调用中的 caller / callee 角色，不等于上下级。
+- **诉请者 / 被诉请者**：一次 Tellask 协作中的 tellasker / tellaskee 角色，不等于上下级。
 
 这意味着：同一个成员可以在不同时间参与多条对话；团队结构与运行中的对话流是两层东西。
 
@@ -109,7 +109,7 @@ Dominds 团队成员通常由以下几类信息组成：
 
 Dominds 里主要有三种协作诉请：
 
-- **TellaskBack（回问诉请）**：支线需要澄清时，回问当前诉请者对话。
+- **TellaskBack（回问诉请）**：支线需要澄清时，回问当前诉请者。
 - **Tellask Session（长线诉请）**：适合多轮迭代、上下文可续用的协作。
 - **Fresh Tellask（一次性诉请）**：一次性的、无需保留后续续话语义的协作。
 
@@ -126,7 +126,7 @@ Dominds 的关键特征之一，是诉请后的运行态会显式管理：
 - 主线可因等待支线结果而挂起
 - 支线可因等待澄清而挂起
 - 对话恢复由后端协程统一驱动
-- 回贴会回到“当前诉请者对话”
+- 回贴会回到“当前诉请者”
 
 因此，从外部智能体的视角，Dominds 协作设计要考虑的不是“谁给谁发消息”，而是：
 

package/dist/docs/dominds-terminology.md

@@ -35,13 +35,12 @@
 - EN: `Tellask body` | ZH: `诉请正文`
 - EN: `tellasker` | ZH: `诉请者`
 - EN: `tellaskee` | ZH: `被诉请者`
-- EN: `tellasker dialog` | ZH: `诉请者对话`
-- EN: `tellaskee dialog` | ZH: `被诉请者对话`
+- EN: `Dialog Responder` | ZH: `对话主理人`
 - EN: `TellaskBack` | ZH: `回问诉请`
 - EN: `Tellask Session` | ZH: `长线诉请`
 - EN: `Fresh Tellask` | ZH: `一次性诉请`
-- EN: `Mainline dialog` | ZH: `主线对话`
-- EN: `Sideline dialog` | ZH: `支线对话`
+- EN: `Main Dialog` | ZH: `主线对话`
+- EN: `Side Dialog` | ZH: `支线对话`
 - EN: `Taskdoc` | ZH: `差遣牒`
 - EN: `Taskdoc package (*.tsk/)` | ZH: `任务包`
 - EN: `sessionSlug` | ZH: 会话 Slug（只写在 headline）
@@ -49,28 +48,28 @@
 - EN: `TUI (interactive UI)` | ZH: `TUI（交互前端）`
 - EN: `WebUI (interactive UI)` | ZH: `WebUI（交互前端）`
 
-### Dialog Terms（主线对话 / 支线对话）
+### Dialog Terms（Main Dialog / Side Dialog，主线对话 / 支线对话）
 
-- EN: **Mainline dialog** is the dialog that carries the canonical shared Taskdoc and is responsible for overall progress.
+- EN: **Main Dialog** is the dialog that carries the canonical shared Taskdoc and is responsible for overall progress.
 - ZH: **主线对话**是承载共享差遣牒（Taskdoc）并负责整体推进的那条对话。
 
-- EN: **Only the mainline dialog responder** can call `change_mind`.
+- EN: **Only the Main Dialog Responder** can call `change_mind`.
 - ZH: **只有主线对话主理人**拥有 `change_mind` 权限；支线对话主理人没有。
 
-- EN: A **sideline dialog** is a temporary work dialog for a subtask. Between dialogs/agents, there is no hierarchy — only **tellasker/tellaskee** roles.
+- EN: A **Side Dialog** is a temporary work dialog for a subtask. Between dialogs/agents, there is no hierarchy — only **tellasker/tellaskee** roles.
 - ZH: **支线对话**是为推进某个分项任务临时创建的工作对话。对话/智能体之间没有上下级关系，只有 **诉请者/被诉请者**。
 
-- EN: A **tellasker dialog** is the dialog that issued the current Tellask; it can be the mainline dialog or any sideline dialog.
-- ZH: **诉请者对话**是当前诉请的发起对话；它可以是主线对话，也可以是任意支线对话。
+- EN: A **tellasker** is the dialog that issued the current Tellask; it can be the Main Dialog or any Side Dialog.
+- ZH: **诉请者**是当前诉请的发起对话；它可以是主线对话，也可以是任意支线对话。
 
-- EN: A **tellaskee dialog** is the dialog handling the current Tellask (this dialog).
-- ZH: **被诉请者对话**是处理当前诉请的对话（也就是此对话）。
+- EN: A **tellaskee** is the dialog handling the current Tellask (this dialog).
+- ZH: **被诉请者**是处理当前诉请的对话（也就是此对话）。
 
-- EN: These are **call roles**, not hierarchy; a tellasker dialog may or may not be the structural supdialog.
-- ZH: 这是一次诉请的**角色关系**，不是层级关系；诉请者对话可能是也可能不是结构上的上位对话。
+- EN: These are **Tellask roles**, not hierarchy; the tellasker may or may not be the structural askerDialog.
+- ZH: 这是一次诉请的**角色关系**，不是层级关系；诉请者可能是也可能不是结构上的 askerDialog。
 
-- EN (cross-reference): In implementation-facing docs/code you may see `root dialog` / `main dialog` for “mainline dialog”, and `subdialog` for “sideline dialog”.
-- ZH（交叉说明）: 在系统实现语境（文档/代码）中，你可能会看到 **根对话 / 主对话（root dialog / main dialog）** 来指代“主线对话”，以及 **subdialog（子对话）** 来指代“支线对话”。这些实现术语不应出现在使用者语境的提示词/示例中。
+- 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` 仍是结构标识字段，不是对外术语。
 
 ### UI Surfaces（入口界面与交互前端）
 
@@ -99,8 +98,8 @@
 - EN: The LLM reads only the latest/current course during normal restore/drive. Carryover exists specifically so the latest course can still see the old request context plus its resolved result without reloading the older course transcript.
 - ZH: 正常的 restore/drive 中，LLM 只读取最新/当前 course。carryover 的存在，就是为了让最新 course 在**不重新加载旧 course transcript** 的前提下，仍能看到旧提问的必要上下文及其完成结果。
 
-- EN: `originCourse` is provenance only: it tells you where the original Tellask was issued.
-- ZH: `originCourse` 只表示来源（provenance）：原始诉请是在哪个 course 发起的。
+- EN: `callSiteCourse` is provenance only: it tells you where the original Tellask was issued.
+- ZH: `callSiteCourse` 只表示来源（provenance）：原始诉请是在哪个 course 发起的。
 
 - EN: `carryoverCourse` and event `course` are owner-course fields: they tell you which current/latest course now contains the usable context.
 - ZH: `carryoverCourse` 和事件里的 `course` 表示归属 course：当前哪一个最新 course 持有这段可直接使用的上下文。
@@ -139,13 +138,13 @@
 - EN (term): `TellaskBack`
 - ZH（术语）: `回问诉请`
 
-- EN (meaning): Ask the **tellasker dialog** (the dialog that issued the current Tellask) for clarification instead of guessing.
-- ZH（含义）: 当被诉请方需要补充信息时，应**回问诉请者对话**澄清，而不是自行猜测。
+- EN (meaning): Ask the **tellasker** (the dialog that issued the current Tellask) for clarification instead of guessing.
+- ZH（含义）: 当被诉请方需要补充信息时，应**回问诉请者**澄清，而不是自行猜测。
 
-- EN (what “Back” means): “Back” refers to routing back to the tellasker dialog; it does **not** imply hierarchy/seniority.
-- ZH（Back 的含义）: “Back” 指回到诉请者对话，**不暗示上下级**。
+- EN (what “Back” means): “Back” refers to routing back to the tellasker; it does **not** imply hierarchy/seniority.
+- ZH（Back 的含义）: “Back” 指回到诉请者，**不暗示上下级**。
 
-- EN (typical carrier): `tellaskBack({ tellaskContent: "..." }) ...` (only available inside a sideline dialog)
+- EN (typical carrier): `tellaskBack({ tellaskContent: "..." }) ...` (only available inside a Side Dialog)
 - ZH（典型载体）: `tellaskBack({ tellaskContent: "..." }) ...`（只在你处于支线对话语境时可用）
 
 Example / 示例（概念）:
@@ -213,7 +212,7 @@ tellask({
 - EN (key property): “Fresh/one-shot” is not only “new context”; it also means **no continuation semantics** — later Tellasks are not expected to resume the same session context.
 - ZH（关键性质）: “Fresh/一次性”不仅表示“新开上下文”，更表示：**没有后续续话语义** —— 后续诉请不应被期待能自动续接本次一次性诉请的上下文。
 
-- EN (operational consequence): A Fresh Tellask has **no assignment-update channel**. Another `tellaskSessionless` creates a new transient sideline; it does not update or tell the earlier one to stop.
+- EN (operational consequence): A Fresh Tellask has **no assignment-update channel**. Another `tellaskSessionless` creates a new transient Side Dialog; it does not update or tell the earlier one to stop.
 - ZH（操作后果）: 一次性诉请**没有任务安排更新通道**。再次发起 `tellaskSessionless` 只会新建另一条瞬态支线，不会更新、更不会要求先前那条支线停止。
 
 - EN (practical guidance): If you need a follow-up after a Fresh Tellask, treat it as a new request and restate necessary context; if you need iterative follow-ups, use `Tellask Session` with `sessionSlug`.
@@ -226,7 +225,7 @@ Example / 示例（概念）:
 
 ### 系统提示可复用的一句话（One-Sentence Summary for System Prompts）
 
-- EN: `TellaskBack` asks the tellasker dialog for clarification; `Tellask Session` uses `sessionSlug` for resumable multi-turn work; `Fresh Tellask` is one-shot and non-resumable.
+- EN: `TellaskBack` asks the tellasker for clarification; `Tellask Session` uses `sessionSlug` for resumable multi-turn work; `Fresh Tellask` is one-shot and non-resumable.
 - ZH: `TellaskBack` 回问诉请者澄清；`Tellask Session` 用 `sessionSlug` 进行可续用多轮协作；`Fresh Tellask` 是一次性且不可恢复。
 
 ### 为何保留 `!` 前缀？（Why keep the `!` prefix?）
@@ -343,7 +342,7 @@ Example / 示例（概念）:
 - ZH: **对话主理人（Dialog Responder）**是一个智能体在某个**具体对话**中承担的角色：负责在该对话中**回应并推进**。
 
 - EN: Practical mapping:
-  - The dialog responder is identified by the dialog's `agentId` in `dialog.yaml` (implementation field name stays `agentId`).
+  - The Dialog Responder is identified by the dialog's `agentId` in `dialog.yaml` (implementation field name stays `agentId`).
   - Do NOT call it “dialog agent” in docs/prompts; that phrase is ambiguous.
 - ZH: 落地映射：
   - 对话主理人在实现上由 `dialog.yaml` 中的 `agentId` 指定（实现字段名仍为 `agentId`）。
@@ -396,8 +395,8 @@ Example / 示例（概念）:
 - ZH: **多程对话（multi-course dialog）**指同一个对话可以拥有**多段过程**；每一程都像一次“重新开工”的对话工作区。
 
 - EN: Course creation (how a new course starts):
-  - The **first course** exists naturally when a mainline dialog or sideline dialog is created.
-  - After that, a **new course** is started when the dialog responder calls `clear_mind`.
+  - The **first course** exists naturally when a Main Dialog or Side Dialog is created.
+  - After that, a **new course** is started when the Dialog Responder calls `clear_mind`.
   - Exception: the system may auto-start a new course for remediation (e.g., context health becomes critical).
 - ZH: “一程”如何产生（新一程如何开始）：
   - **第一程**：随着主线对话/支线对话的创建自然产生。
@@ -470,39 +469,39 @@ Example / 示例（概念）:
 - EN: A **dialog** is a persisted, driveable conversation state machine.
 - ZH: **对话（dialog）**是一个可持久化、可被后端驱动的对话状态机。
 
-### Supdialog / 上位对话
+### AskerDialog / 诉请者
 
-- EN: A **supdialog** ("super dialog") is the orchestrating dialog in a hierarchical dialog relationship. It spawns subdialogs, provides context/objectives, and receives results/questions/escalations from its subdialogs.
-- ZH: **supdialog（上位对话）**是在层级对话关系中负责编排的对话：它创建 subdialog，提供上下文/目标，并接收 subdialog 的结果/问题/升级请求。
+- EN: **askerDialog** is the implementation-facing dialog that currently owns an assignment or reply obligation for a sideDialog. It may be the main dialog or another sideDialog; it is a tellask/reply relationship, not inherently a hierarchy label.
+- ZH: **askerDialog（诉请者）**是在实现语境中当前拥有某个支线 assignment 或 reply obligation 的对话。它可以是 main dialog，也可以是另一个 sideDialog；这是诉请/回复关系，不天然表示层级上位。
 
-- EN: A supdialog may receive **TellaskBack calls** from its subdialogs during execution.
-- ZH: supdialog 在执行过程中可能接收来自 subdialog 的 **TellaskBack call（回问诉请）**。
+- EN: An askerDialog may receive **TellaskBack calls** from the sideDialogs that currently owe it a reply.
+- ZH: askerDialog 在执行过程中可能接收来自当前需向它回复的 sideDialog 的 **TellaskBack call（回问诉请）**。
 
-### Subdialog / 子对话
+### SideDialog / 支线对话
 
-- EN: A **subdialog** is a specialized dialog spawned by a supdialog to handle a subtask with fresh (or session-resumed) context.
-- ZH: **subdialog（子对话）**是由 supdialog 派生出来用于处理子任务的专用对话，具备相对独立的上下文（可能是新开或按会话 key 恢复）。
+- EN: A **sideDialog** is a specialized dialog spawned by an askerDialog to handle a subtask with fresh (or session-resumed) context.
+- ZH: **sideDialog（支线对话）**是由 askerDialog 派生出来用于处理子任务的专用对话，具备相对独立的上下文（可能是新开或按会话 key 恢复）。
 
-### Root Dialog / 根对话
+### MainDialog / 主线对话
 
-- EN: A **root dialog** (aka **main dialog**) is the top-level dialog with no supdialog.
-- ZH: **根对话（root dialog / main dialog）**是层级最顶层的对话，不存在 supdialog。
+- EN: A **main dialog** is the top-level dialog with no askerDialog. Prefer **Main Dialog** in general/user-facing context and `MainDialog` / `main dialog` in implementation-facing context.
+- ZH: **main dialog（主线对话）**是没有 askerDialog 的顶层主线对话。通用/对外语境优先使用 **Main Dialog / 主线对话**；实现语境使用 `MainDialog` / `main dialog`。
 
 ### Type A/B/C (internal taxonomy) / 内部分类
 
 - EN: The implementation may still use the internal labels **Type A/B/C** to classify teammate-tellask patterns.
 - ZH: 实现层仍可能使用 **Type A/B/C** 作为队友诉请形态的内部分类。
 
-- EN: Type A: TellaskBack call (a subdialog asking back to its tellasker dialog); primary syntax `tellaskBack({ tellaskContent: "..." })` (NO `sessionSlug`).
-- ZH: Type A：回问诉请（子对话回问其诉请者对话）；主语法 `tellaskBack({ tellaskContent: "..." })`（不带 `sessionSlug`）。
+- EN: Type A: TellaskBack call (a sideDialog asking back to its tellasker); primary syntax `tellaskBack({ tellaskContent: "..." })` (NO `sessionSlug`).
+- ZH: Type A：回问诉请（支线对话回问其诉请者）；主语法 `tellaskBack({ tellaskContent: "..." })`（不带 `sessionSlug`）。
 
-- EN: Type B: registered subdialog call (resumable) keyed by `agentId!sessionSlug`.
-- ZH: Type B：registered subdialog call（可恢复），用 `agentId!sessionSlug` 作为 registry key。
+- EN: Type B: registered sideDialog call (resumable) keyed by `agentId!sessionSlug`.
+- ZH: Type B：registered sideDialog call（可恢复），用 `agentId!sessionSlug` 作为 registry key。
 
-- EN: Type C: transient subdialog call (one-shot), not registered.
-- ZH: Type C：transient subdialog call（一次性），不注册到 registry。
+- EN: Type C: transient sideDialog call (one-shot), not registered.
+- ZH: Type C：transient sideDialog call（一次性），不注册到 registry。
 
 ### `sessionSlug` / 会话 Slug 指令
 
-- EN: Resumable registered subdialogs use `sessionSlug` in the Tellask headline.
-- ZH: 可恢复的注册子对话使用 Tellask headline 内的 `sessionSlug`。
+- EN: Resumable registered sideDialogs use `sessionSlug` in the Tellask headline.
+- ZH: 可恢复的注册支线对话使用 Tellask headline 内的 `sessionSlug`。

package/dist/docs/encapsulated-taskdoc.md

@@ -10,11 +10,11 @@ with a stable schema and a strict access policy.
 ## Goals
 
 - **Clarity**: separate “what we want” (goals) from “what we must obey” (constraints) and “where we are” (progress).
-- **Coordination**: make the Taskdoc the task’s **live coordination bulletin board** across mainlines/agents (keep `progress.md`/`constraints.md` current; don’t bury key decisions in chat).
+- **Coordination**: make the Taskdoc the task’s **live coordination bulletin board** across Main Dialogs/agents (keep `progress.md`/`constraints.md` current; don’t bury key decisions in chat).
 - **Durability**: make task state persist across long-running work and across dialog course resets.
 - **Auditability**: make task changes explicit and attributable to a single, intentional action.
 - **Safety**: prevent accidental or tool-driven reads/writes that bypass intended UX and control points.
-- **Shareability**: ensure the Taskdoc is visible/consistent across the entire dialog tree (root + subdialogs).
+- **Shareability**: ensure the Taskdoc is visible/consistent across the entire dialog tree (main dialog + sideDialogs).
 
 ## Non-goals
 
@@ -24,7 +24,7 @@ with a stable schema and a strict access policy.
 
 ## Terminology
 
-- **Dialog tree**: a root dialog plus any subdialogs/teammates spawned under it.
+- **Dialog tree**: a main dialog plus any sideDialogs/teammates spawned under it.
 - **Taskdoc package**: a directory ending in `.tsk/` that stores the Taskdoc as multiple files.
 - **Taskdoc (effective)**: the logical Taskdoc content presented to the agent, derived from the Taskdoc package.
 - **Encapsulation**: treating `.tsk/` as protected internal state, not general rtws (runtime workspace) files.
@@ -253,7 +253,7 @@ Call the function tool `change_mind` with:
 - The body is treated as opaque markdown text; no partial patching/diff semantics are implied.
 - A successful `change_mind` updates the Taskdoc package immediately and becomes visible to:
   - the current dialog
-  - all subdialogs/teammates in the dialog tree
+  - all sideDialogs/teammates in the dialog tree
   - any observing WebUI clients
 
 ### Failure cases (non-exhaustive)

package/dist/docs/encapsulated-taskdoc.zh.md

@@ -13,7 +13,7 @@
 - **持久性**：使任务状态在长期工作和多程对话重置之间保持持久。
 - **可审计性**：使任务变更明确且可归因于单一、有意的操作。
 - **安全性**：防止绕过预期用户体验和控制点的意外或工具驱动的读/写。
-- **可共享性**：确保差遣牒在整个对话树（根 + 子对话）中可见/一致。
+- **可共享性**：确保差遣牒在整个对话树（主线对话 + 支线对话）中可见/一致。
 
 ## 非目标
 
@@ -23,7 +23,7 @@
 
 ## 术语
 
-- **对话树**：根对话加上在其下产生的任何子对话/队友。
+- **对话树**：主线对话加上在其下产生的任何支线对话/队友。
 - **差遣牒**：一份任务契约（目标/约束/进度），同时也是跨主线/跨智能体的任务实时协调公告板。
 - **任务包**：以 `.tsk/` 后缀结尾的目录，将差遣牒存储为多个文件。
 - **有效差遣牒**：呈现给智能体的逻辑差遣牒内容，从任务包派生而来。
@@ -264,7 +264,7 @@ recall_taskdoc({ category, selector })
 - 正文被视为不透明的 markdown 文本；不暗示部分修补/差异语义。
 - 成功的 `change_mind` 会立即更新任务包，并对以下内容可见：
   - 当前对话
-  - 对话树中的所有子对话/队友
+  - 对话树中的所有支线对话/队友
   - 任何观察的 WebUI 客户端
 
 ### 失败情况（非穷尽）