dominds 1.7.0 → 1.7.2

package/README.md

@@ -4,7 +4,7 @@
 
 > Agents should be sustaining the continuous development of your products, one-shot product creation is hallucination.
 
-- 中文版：[README.zh.md](./README.zh.md)
+- Chinese version: [中文版](./README.zh.md)
 
 ## CAVEATS
 

package/README.zh.md

@@ -185,7 +185,7 @@ Dominds 面向“长期开发运作（DevOps）”场景设计，基于社会化
 - **[CLI Usage Guide](docs/cli-usage.zh.md)** — 命令行工具及使用方法
 - **[Q4H](docs/q4h.zh.md)** — 向人类提问（`askHuman`）机制与 WebUI 支持
 - **[MCP Support](docs/mcp-support.zh.md)** — MCP 工具集成指南
-- **[Encapsulated Taskdocs](docs/encapsulated-taskdoc.zh.md)** — 差遣牒（Taskdoc）封装
+- **[封装式差遣牒](docs/encapsulated-taskdoc.zh.md)** — `*.tsk/` 任务包与访问约束
 - **[FBR](docs/fbr.zh.md)** — 扪心自问（`freshBootsReasoning`）机制设计与增强
 - **[Context Health](docs/context-health.zh.md)** — 上下文健康维护
 - **[Diligence Push](docs/diligence-push.zh.md)** — 鞭策机制

package/dist/dialog.js

@@ -142,10 +142,10 @@ class Dialog {
         // Diligence Push disable switch (persisted via latest.yaml; default = false).
         this.disableDiligencePush = false;
         // Current callId for tellask call correlation
-        // - Set during teammate_call_finish_evt (from tellask-special function calls)
+        // - Set when tellask-special call results are finalized
         // - Retrieved during inline call-result emission (for receiveTellaskCallResult callId parameter)
         // - Enables frontend to attach result INLINE to the calling section
-        // - NOT used for teammate tellasks (which use calleeDialogId instead)
+        // - NOT used for sideline-response bubbles (which use calleeDialogId instead)
         this._currentCallId = null;
         // Validate required parameters
         if (!taskDocPath || taskDocPath.trim() === '') {
@@ -207,7 +207,7 @@ class Dialog {
      * Get the current callId for tellask call correlation
      *
      * Call Types:
-     * - tellask-special function call: callId is set during teammate_call_finish_evt and used for inline result correlation
+     * - tellask-special function call: callId is set when call results are finalized and used for inline result correlation
      * - Subdialog response bubbles: use calleeDialogId instead of callId
      *
      * @returns The current callId for call correlation, or null if no active call
@@ -216,7 +216,7 @@ class Dialog {
         return this._currentCallId;
     }
     /**
-     * Set the current callId (called during teammate_call_finish_evt for tellask-special calls)
+     * Set the current callId for tellask-special inline result correlation
      *
      * @param callId - The function-call correlation ID
      */
@@ -796,7 +796,7 @@ class Dialog {
         return await this.dlgStore.receiveTellaskCallResult(this, responderId, callName, mentionList, tellaskContent, result, status, callId);
     }
     /**
-     * Receive teammate response (separate bubble for @teammate tellasks)
+     * Receive tellask response (separate bubble for tellask sideline replies)
      */
     async receiveTellaskResponse(responderId, callName, mentionList, tellaskContent, status, subdialogId, options) {
         return await this.dlgStore.receiveTellaskResponse(this, responderId, callName, mentionList, tellaskContent, status, subdialogId, options);
@@ -939,7 +939,7 @@ class Dialog {
 }
 exports.Dialog = Dialog;
 /**
- * SubDialog - A subdialog created by a RootDialog for autonomous teammate tellasks.
+ * SubDialog - A subdialog created by a RootDialog for autonomous tellask sideline work.
  * Stores the root dialog for registry and lookup, and resolves its effective supdialog dynamically.
  */
 class SubDialog extends Dialog {
@@ -1064,7 +1064,7 @@ class RootDialog extends Dialog {
         return Array.from(this._subdialogRegistry.values());
     }
     /**
-     * Create a new subdialog for autonomous teammate tellasks.
+     * Create a new subdialog for autonomous tellask sideline work.
      */
     async createSubDialog(targetAgentId, mentionList, tellaskContent, options) {
         return await this.dlgStore.createSubDialog(this, targetAgentId, mentionList, tellaskContent, options);
@@ -1146,7 +1146,7 @@ class DialogStore {
      */
     async receiveTellaskCallResult(_dialog, _responderId, _callName, _mentionList, _tellaskContent, _result, _status, _callId) { }
     /**
-     * Receive teammate response (separate bubble for @teammate tellasks)
+     * Receive tellask response (separate bubble for tellask sideline replies)
      */
     async receiveTellaskResponse(_dialog, _responderId, _callName, _mentionList, _tellaskContent, _status, _subdialogId, _options) { }
     async updateQuestions4Human(_dialog, _questions) { }

package/dist/docs/OEC-philosophy.md

@@ -4,27 +4,27 @@ Chinese version: [中文版](./OEC-philosophy.zh.md)
 
 > Haier: Overall Every(thing/one/day) Control/Clear
 
-The OEC Management Method is a comprehensive enterprise management framework created by Haier Group in 1989, also known as "全方位优化管理法" (Comprehensive Optimization Management Method). This philosophy has generated tremendous economic and social benefits for Haier, earning them the National Enterprise Management Innovation "Golden Horse Award" and the Enterprise Reform "Sail Cup", with Premier Zhu Rongji批示 recommending nationwide promotion of this management experience.
+The OEC Management Method is a comprehensive enterprise management framework created by Haier Group in 1989, also known as the Comprehensive Optimization Management Method. This philosophy generated major economic and social benefits for Haier, earning the company the National Enterprise Management Innovation "Golden Horse Award" and the Enterprise Reform "Sail Cup", along with a recommendation from Premier Zhu Rongji to promote the management experience nationwide.
 
 ## Core Philosophy
 
-OEC represents a systematic approach to daily management that emphasizes **"Daily work completion, daily clearance, daily improvement"** (日事日毕、日清日高). The fundamental principle is that every employee must accomplish targeted work every day, with the overall goal being to achieve a 1% improvement over the previous day's performance.
+OEC represents a systematic approach to daily management that emphasizes **"Daily work completion, daily clearance, daily improvement."** The fundamental principle is that every employee must accomplish targeted work every day, with the overall goal being to achieve a 1% improvement over the previous day's performance.
 
 ## The OEC Components
 
-### **O - Overall (全方位)**
+### **O - Overall**
 
 - **Global Integration**: All activities, processes, and systems are interconnected
 - **Holistic Thinking**: Every element contributes to the overall organizational success
 - **Strategic Alignment**: Daily activities support long-term strategic objectives
 
-### **E - Everyone, Everything, Everyday (每人、每事、每日)**
+### **E - Everyone, Everything, Everyday**
 
 - **Everyone**: Every employee has clear responsibilities and accountability
 - **Everything**: Every task, process, and outcome is managed and controlled
 - **Everyday**: Daily operations, reviews, and improvements are non-negotiable
 
-### **C - Control and Clear (控制和清晰)**
+### **C - Control and Clear**
 
 - **Clear Standards**: Defined expectations, processes, and quality benchmarks
 - **Controlled Processes**: Systematic monitoring and adjustment mechanisms
@@ -32,27 +32,27 @@ OEC represents a systematic approach to daily management that emphasizes **"Dail
 
 ## Three Fundamental Principles
 
-### 1. **Closed-Loop Management (闭环原则)**
+### 1. **Closed-Loop Management**
 
 - **PDCA Cycle**: Plan-Do-Check-Act continuous improvement
 - **Complete Accountability**: Every task has clear ownership and follow-through
 - **Systematic Follow-up**: No loose ends or unaddressed issues
 
-### 2. **Comparative Analysis (比较分析原则)**
+### 2. **Comparative Analysis**
 
 - **Internal Benchmarking**: Compare current performance with past achievements
 - **External Benchmarking**: Measure against industry best practices and international standards
 - **Competitive Intelligence**: Use comparison as a driver for improvement
 
-### 3. **Continuous Optimization (不断优化原则)**
+### 3. **Continuous Optimization**
 
-- **Weakest Link Theory**: Identify and strengthen薄弱环节 (weak areas)
+- **Weakest Link Theory**: Identify and strengthen weak areas
 - **Incremental Progress**: 1% daily improvement compounds significantly over time
 - **Systematic Enhancement**: Continuous refinement of all processes
 
 ## Implementation Framework
 
-### Daily Work Completion (日事日毕)
+### Daily Work Completion
 
 **Core Mechanisms:**
 
@@ -66,7 +66,7 @@ OEC represents a systematic approach to daily management that emphasizes **"Dail
 - Mid-day check-ins ensure progress tracking
 - Evening reviews confirm completion and identify issues
 
-### Daily Clearance (日清日高)
+### Daily Clearance
 
 **The "Three Management Principles":**
 

package/dist/docs/OEC-philosophy.zh.md

@@ -169,7 +169,7 @@ OEC 代表了一种系统化的日常管理方法，强调**"日事日毕、日
 
 ### **多程对话**
 
-- **每日重置**：使用已写回关键进展的差遣牒（Taskdoc，任务实时协调公告板）与空对话历史（主要是大篇幅、过时的工具调用结果）开启新一程对话
+- **每日重置**：使用已写回关键进展的差遣牒（任务实时协调公告板）与空对话历史（主要是大篇幅、过时的工具调用结果）开启新一程对话
 - **清除上下文**：确保所有智能体在最佳清晰度和更新信息下工作
 - **即时解决**：在同一操作周期内解决问题和异常
 

package/dist/docs/context-health.md

@@ -113,12 +113,14 @@ Levels are derived from the two thresholds:
 
 ## v3 Remediation Semantics (Driver-enforced)
 
-### Continuation package (“接续包”)
+### Continuation package
 
 The remediation workflow centers around a _continuation package_ (a scannable, actionable bundle of
-context that survives a new course). When the agent is still clear-headed, this should preferably be
-kept as **one structured reminder**. But when the agent is already muddled in caution/critical,
-multiple rough reminders are acceptable as a bridge.
+context that survives a new course). The agent must not self-assess whether it is “still
+clear-headed” or “already muddled” because that judgment is not reliable or auditable. The only
+mechanical branch is whether the system has put the current course into `caution` / `critical`
+remediation. Outside remediation, prefer **one structured reminder**. During remediation, rough
+multi-reminder carry-over is acceptable as a bridge.
 
 Recommended structure (multi-line but compact; focus on details not covered in Taskdoc):
 
@@ -130,10 +132,13 @@ Recommended structure (multi-line but compact; focus on details not covered in T
 Rules:
 
 - Keep normal reminders concise and few.
-- When preparing a new course, prefer compressing into one continuation-package reminder if the
-  agent is still clear-headed.
-- If the agent is already muddled, prioritize preserving volatile information even via multiple rough
-  reminders; in the next course, the first action should be to review, merge, and delete redundancy.
+- Do not let the agent branch on subjective self-assessment such as “clear-headed” vs “muddled”.
+- When the current course is not under `caution` / `critical` remediation, prefer compressing into
+  one structured continuation-package reminder.
+- When the system has put the current course into `caution` / `critical` remediation, prioritize
+  preserving volatile information even via multiple rough reminders; in the current course, only
+  preserve info and `clear_mind`. Once the system actually starts the next course, the first step
+  is to review, merge, and delete redundancy.
 - Do not duplicate Taskdoc content except for a short bridge when strictly needed.
 - Do not paste long raw logs/tool outputs into the continuation package.
 
@@ -150,7 +155,7 @@ Current behavior:
   generations; configurable per model).
 - Each inserted prompt requires the agent to **curate reminders** (at least one call):
   - `update_reminder` (preferred) / `add_reminder`
-  - Prefer a structured continuation-package reminder; if already muddled, rough multi-reminder carry-over is acceptable
+  - Default to one structured continuation-package reminder; if the current course is already under remediation and one structured reminder cannot be produced directly from already observed facts, rough multi-reminder carry-over is acceptable
   - Then `clear_mind` when it becomes scannable/actionable
 
 ### Critical (red)
@@ -159,7 +164,7 @@ When `level === 'critical'`, the driver enters a **countdown remediation** (max
 
 - On each turn, the driver records a **role=user prompt** (persisted as a user message) that is
   visible in the UI as a user prompt. This prompt tells the agent to:
-  - curate reminders via `update_reminder` / `add_reminder`, preferably into a continuation-package reminder but allowing rough multi-reminder carry-over when already muddled, and
+  - curate reminders via `update_reminder` / `add_reminder`, preferably into a continuation-package reminder but allowing rough multi-reminder carry-over when the current course is already under remediation and a single structured reminder cannot be produced directly from already observed facts, and
   - then call `clear_mind` to start a new course.
 - The prompt includes a countdown: after **N** turns the system will automatically clear.
 - When the countdown reaches 0, the driver **automatically calls** `clear_mind` (with empty args; no
@@ -186,10 +191,26 @@ Suggested visual states:
 - **Critical** (red)
 - **Unknown** (gray)
 
-Note (zh UI copy):
+### Canonical bilingual status mapping
 
-- `caution` → “吃紧”
-- `critical` → “告急”
+To avoid ad hoc translations in docs, prompts, and UI copy, this status set uses the following
+canonical mapping:
+
+| Internal state | Canonical English | Canonical Chinese UI copy | Notes                                                                                                                            |
+| -------------- | ----------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `healthy`      | `Healthy`         | `充裕`                    | Means the prompt is still comfortably below the soft threshold; the Chinese UI label is not `健康`.                              |
+| `caution`      | `Caution`         | `吃紧`                    | Means the prompt is past the soft threshold and reminder curation should start; the Chinese UI label is not `警告`.              |
+| `critical`     | `Critical`        | `告急`                    | Means the dialog is in the high-risk zone and driver-enforced countdown remediation applies; the Chinese UI label is not `严重`. |
+| `unknown`      | `Unknown`         | `未知`                    | Means usage stats for the turn are unavailable, so context health cannot be determined.                                          |
+
+Additional constraints:
+
+- English docs and prompts should use `Healthy / Caution / Critical / Unknown` as the canonical
+  English labels.
+- When an English doc needs to mention the Chinese counterpart, it should use the exact Chinese UI
+  labels above (`充裕 / 吃紧 / 告急 / 未知`) rather than improvised near-synonyms.
+- Chinese explanatory prose may still describe the semantics in other words, but those alternate
+  words should not replace the canonical status labels in UI/spec text.
 
 ## Implementation Outline
 
@@ -210,7 +231,7 @@ Note (zh UI copy):
   - `caution`: driver inserts a persisted role=user prompt (UI-visible user instruction).
     On entering `caution` it inserts once; while still `caution` it reinserts on a cadence (default: every
     10 generations; configurable per model). Each time, the agent must call at least one of
-    `update_reminder` / `add_reminder` and preserve a continuation package. A single structured reminder is preferred, but multiple rough reminders are acceptable when already muddled; in the new course the agent should reconcile them first, then `clear_mind` when ready.
+    `update_reminder` / `add_reminder` and preserve a continuation package. A single structured reminder is preferred when the current course is not under remediation pressure; during remediation, multiple rough reminders are acceptable if they can be written directly from already observed facts without further reading/analysis. In the new course the agent should reconcile them first, then `clear_mind` when ready.
   - `critical`: driver runs a countdown remediation (max 5 turns) using **recorded role=user prompts**.
     Each prompt includes a countdown and instructs reminder curation + `clear_mind`. When the countdown
     reaches 0, the driver auto-executes `clear_mind` and starts a new course (no Q4H, no suspension).

package/dist/docs/context-health.zh.md

@@ -100,13 +100,22 @@ Dominds 计算比率：
 
 恢复工作流围绕一个**接续包**（一个可扫描的、可操作的上下文束）展开，该束在新一程对话中存活。
 
-推荐结构（多行；按任务规模缩放；聚焦于差遣牒（Taskdoc）中未涵盖的细节）：
+推荐结构（多行；按任务规模缩放；聚焦于差遣牒中未涵盖的细节）：
 
 - 第一个可操作步骤
 - 关键指针（文件/符号/搜索词）
 - 运行/验证（命令、端口、环境变量）
 - 容易丢失的临时细节（路径/ID/URL/示例输入）
 
+规则：
+
+- 普通提醒项保持简短且少量。
+- 不允许智能体靠主观感觉判断自己“头脑清楚”还是“已经发乱”；这两种说法没有可靠、可审计的客观判据。
+- 机制性分流规则只有一个：看**系统是否已将当前程置于上下文健康处置态**。若当前没有 `caution/critical` 处置指令，则默认优先压缩成一个结构化接续包提醒项。
+- 一旦系统已将当前程置于 `caution/critical` 处置态，当前程的目标就切换为“保住易丢信息并尽快 `clear_mind`”，此时允许多条粗略提醒项过桥；系统真正开启新一程后，第一步再复核、合并并删除冗余。
+- 除非确有必要，不要重复差遣牒已覆盖的内容。
+- 不要把长原始日志/大段 tool output 直接塞进接续包。
+
 ### 警告（黄色）
 
 当 `level === 'caution'` 时，驱动程序在**下一个** LLM 生成轮次自动插入一条 **role=user** 指导提示，并**将其持久化为普通用户消息**，以便 UI 将其渲染为正常的用户指令。
@@ -145,15 +154,27 @@ Dominds 计算比率：
 
 建议的视觉状态：
 
-- **健康**（绿色）
-- **警告**（黄色）
-- **严重**（红色）
+- **充裕**（绿色）
+- **吃紧**（黄色）
+- **告急**（红色）
 - **未知**（灰色）
 
-注意（中文 UI 文案）：
+### 状态术语对照（规范）
+
+为避免在文档、提示词、UI 文案里出现“看似正确但并非正规对应”的翻译，这组状态词统一按下表使用：
+
+| 内部状态值 | 英文规范文案 | 中文 UI 文案 | 说明                                                                             |
+| ---------- | ------------ | ------------ | -------------------------------------------------------------------------------- |
+| `healthy`  | `Healthy`    | `充裕`       | 表示上下文距离软线仍有明显余量；中文 UI 不使用“健康”作为正式标签。               |
+| `caution`  | `Caution`    | `吃紧`       | 表示已越过软线、需要开始整理与收敛；中文 UI 不使用“警告”作为正式标签。           |
+| `critical` | `Critical`   | `告急`       | 表示已进入高风险区，驱动程序会执行倒计时恢复；中文 UI 不使用“严重”作为正式标签。 |
+| `unknown`  | `Unknown`    | `未知`       | 表示本轮缺少可用 usage 统计，无法判断上下文健康度。                              |
+
+补充约束：
 
-- `caution` → "吃紧"
-- `critical` → "告急"
+- 在中文文档/提示词/UI 中，涉及这组**正式状态名称**时，应优先使用 `充裕 / 吃紧 / 告急 / 未知`。
+- `健康 / 警告 / 严重` 这类词只可作为解释性描述，不应再作为正式按钮文案、状态标签或规范对照译名。
+- 英文文档在提到中文对应词时，应明确引用上述正式中文 UI 文案，避免自行译成其他近义词。
 
 ## 实现大纲
 

package/dist/docs/design.zh.md

@@ -136,13 +136,13 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 
 **2. 以任务为中心的专注架构**
 
-- **中央差遣牒（Taskdoc）**：任务实时协调的公告板；目标/约束/进度的单一真实来源（关键决策与下一步必须写回 `progress`）
+- **中央差遣牒**：任务实时协调的公告板；目标/约束/进度的单一真实来源（关键决策与下一步必须写回 `progress`）
 - **动态上下文窗口**：时间限制的上下文保留
 - **基于优先级的信息过滤**：自动排名上下文相关性
 
-术语：本文统一使用“差遣牒（Taskdoc）”指代任务契约与实时协调公告板；它不是个人草稿本。
+术语：本文统一使用“差遣牒”指代任务契约与实时协调公告板；它不是个人草稿本。
 
-### 差遣牒（Taskdoc）结构
+### 差遣牒结构
 
 ```
 差遣牒结构：
@@ -187,7 +187,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 ```
 触发：需要复杂的技术决策
 新鲜会话：
-- 加载差遣牒（Taskdoc）+ 技术要求
+- 加载差遣牒 + 技术要求
 - 专注："分析可行性并推荐方法"
 - 输出：带有推理的清晰技术建议
 ```
@@ -197,7 +197,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 ```
 触发：需要新想法或解决方案
 新鲜会话：
-- 仅加载差遣牒（Taskdoc）+ 问题陈述
+- 仅加载差遣牒 + 问题陈述
 - 专注："在不受约束偏见影响的情况下产生创新方法"
 - 输出：带有理由的创意解决方案列表
 ```
@@ -207,7 +207,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 ```
 触发：需要验证当前方法
 新鲜会话：
-- 加载差遣牒（Taskdoc）+ 当前解决方案尝试
+- 加载差遣牒 + 当前解决方案尝试
 - 专注："识别薄弱环节和改进机会"
 - 输出：批判性分析和建议
 ```
@@ -304,7 +304,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 **新鲜度级别：**
 
 1. **级别 0**：当前智能体状态
-2. **级别 1**：干净智能体 + 差遣牒（Taskdoc）（标准初心）
+2. **级别 1**：干净智能体 + 差遣牒（标准初心）
 3. **级别 2**：完全重置的智能体，只有问题陈述
 4. **级别 3**：具有不同训练重点的新智能体实例
 
@@ -318,7 +318,7 @@ Dominds 为 AI 智能体实现了**社会分工**——一种通过战略性心
 
 **以任务为中心的新鲜会话：**
 
-- 所有新鲜推理会话引用相同的中央差遣牒（Taskdoc）
+- 所有新鲜推理会话引用相同的中央差遣牒
 - 确保多个专注推理尝试的一致性
 - 允许认知重置的同时保持连续性线索
 

package/dist/docs/dialog-persistence.zh.md

@@ -395,9 +395,9 @@ subdialogs_created: 1
 status: 'completed'
 ```
 
-### 差遣牒（Taskdoc）存储
+### 差遣牒存储
 
-差遣牒（Taskdoc）是独立存在的 rtws 工件，对话通过路径引用它们。实践上，差遣牒也是跨主线/跨智能体的**任务实时协调公告板**。差遣牒必须是封装的 `*.tsk/` 任务包。
+差遣牒是独立存在的 rtws 工件，对话通过路径引用它们。实践上，差遣牒也是跨主线/跨智能体的**任务实时协调公告板**。差遣牒必须是封装的 `*.tsk/` 任务包。
 
 ```yaml
 # 在 dialog.yaml 中
@@ -456,7 +456,7 @@ taskdocChecksum: 'sha256:abc123...'
 4. 使用序列化的 DialogID 写入初始 `dialog.yaml` 元数据
 5. 将 `latest.yaml` 初始化为 `currentCourse: 1`
 6. 创建空的 `reminders.json`
-7. 设置差遣牒（Taskdoc）路径引用
+7. 设置差遣牒路径引用
 
 ### 消息持久化
 
@@ -472,7 +472,7 @@ taskdocChecksum: 'sha256:abc123...'
    - `selfDlgId`：新生成的子对话 ID
    - `rootDlgId`：从 supdialog 的 `rootDlgId` 继承
 3. 在父级的 `subdialogs/` 下创建子对话目录（仅使用 `selfDlgId` 作为目录名）
-4. 从父级设置差遣牒（Taskdoc）路径引用
+4. 从父级设置差遣牒路径引用
 5. 在元数据中设置父调用上下文
 6. 初始化子对话状态，元数据中仅存储 `selfDlgId`
 7. 加载时基于目录结构重建完整的 `DialogID` 和 `rootDlgId`

package/dist/docs/dialog-system.md

@@ -36,7 +36,7 @@ A **supdialog** (short for "super dialog") is the supdialog in a hierarchical di
 
 Note: **supdialog** is a structural parent in the dialog hierarchy. It is not the same as the **tellasker dialog** (the caller for the current Tellask). For TYPE A (`tellaskBack`), the tellasker dialog is the direct supdialog; for TYPE B/C, the tellasker dialog may be a different dialog.
 
-A supdialog may receive **TellaskBack** from its subdialogs during their task execution. When a subdialog needs guidance or additional context, it can Tellask back via `tellaskBack({ tellaskContent: "..." })` (TYPE A / `TellaskBack` / 回问诉请), which provides responses that feed back into the subdialog's context.
+A supdialog may receive **TellaskBack** from its subdialogs during their task execution. When a subdialog needs guidance or additional context, it can Tellask back via `tellaskBack({ tellaskContent: "..." })` (TYPE A / `TellaskBack`), which provides responses that feed back into the subdialog's context.
 
 ### Subdialog
 
@@ -152,13 +152,13 @@ This section documents the three distinct types of teammate Tellasks in the Domi
 ```mermaid
 flowchart TD
   M[LLM emits tellaskSessionless({ targetAgentId: "mention", tellaskContent: "..." })] --> Q{Is this a subdialog Tellasking its direct supdialog (tellasker dialog for TYPE A)?}
-  Q -- yes --> A[TYPE A: TellaskBack<br/>(`TellaskBack` / 回问诉请)<br/>Primary: tellaskBack({ tellaskContent: "..." }) (NO sessionSlug)]
+  Q -- yes --> A[TYPE A: TellaskBack<br/>(`TellaskBack`)<br/>Primary: tellaskBack({ tellaskContent: "..." }) (NO sessionSlug)]
   Q -- no --> T{Is sessionSlug present?}
-  T -- yes --> B[TYPE B: Registered subdialog Tellask<br/>(`Tellask Session` / 长线诉请)<br/>tellask({ targetAgentId: "agentId", sessionSlug: "tellaskSession", tellaskContent: "..." })]
-  T -- no --> C[TYPE C: Transient subdialog Tellask<br/>(`Fresh Tellask` / 一次性诉请)<br/>tellaskSessionless({ targetAgentId: "agentId", tellaskContent: "..." })]
+  T -- yes --> B[TYPE B: Registered subdialog Tellask<br/>(`Tellask Session` / Registered Session Tellask)<br/>tellask({ targetAgentId: "agentId", sessionSlug: "tellaskSession", tellaskContent: "..." })]
+  T -- no --> C[TYPE C: Transient subdialog Tellask<br/>(`Fresh Tellask` / One-shot Tellask)<br/>tellaskSessionless({ targetAgentId: "agentId", tellaskContent: "..." })]
 ```
 
-### TYPE A: TellaskBack (Type A / `TellaskBack` / 回问诉请)
+### TYPE A: TellaskBack (Type A / `TellaskBack`)
 
 **Primary syntax**: `tellaskBack({ tellaskContent: "..." })` (NO `sessionSlug`) — `tellaskBack({ tellaskContent: "..." }) sessionSlug ...` is a **syntax error**
 
@@ -185,7 +185,7 @@ flowchart TD
 **Sideline delivery rule (normative)**:
 
 - If a sideline dialog has completed all assigned goals and can deliver the final result, it MUST reply directly with the response body; do not use `tellaskBack` to send final delivery.
-- Runtime treats that direct reply as the completion delivery to the tellasker dialog and injects `【最终完成】` into the transfer payload automatically.
+- Runtime treats that direct reply as the completion delivery to the tellasker dialog and injects the work-language marker automatically (`【Completed】` in English work language, and the localized Chinese completion marker in Chinese work language).
 - If any goal is incomplete, the dialog is blocked, or critical context is missing, it MUST issue `tellaskBack({ tellaskContent: "..." })` to request clarification or next-step confirmation before proceeding.
 - **FBR exception**: FBR sideline dialogs are tellask-free (no `tellaskBack`); they must list missing context and return.
 
@@ -193,9 +193,14 @@ flowchart TD
 
 - Runtime builds a canonical inter-dialog transfer payload for teammate replies; this payload is delivered to target-agent context, and UI must show the same payload verbatim.
 - First-line markers are runtime-injected into that transfer payload by semantics; agents must not hand-write them:
-  - Ask-back reply: `【tellaskBack】`
-  - Regular completed sideline reply: `【最终完成】`
-  - FBR sideline reply: `【FBR-直接回复】` or `【FBR-仅推理】`
+  - English work language:
+    - Ask-back reply: `【TellaskBack】`
+    - Regular completed sideline reply: `【Completed】`
+    - FBR sideline reply: `【FBR-Direct Reply】` or `【FBR-Reasoning Only】`
+  - Chinese work language:
+    - Ask-back reply: `【TellaskBack】`
+    - Regular completed sideline reply: `【Completed】`
+    - FBR sideline reply: `【FBR-Direct Reply】` or `【FBR-Reasoning Only】`
 - Source-dialog model raw is naturally preserved in source-dialog persistence; inter-dialog transfer must not rewrite or overwrite that source raw.
 - Template-wrapped transfer is allowed: a model output from one dialog may be embedded into a runtime template and sent as the body to another dialog.
 
@@ -221,7 +226,7 @@ Result:
 - sub-001 resumes with orchestrator's response
 ```
 
-### TYPE B: Registered Subdialog Tellask (Type B / `Tellask Session` / 长线诉请)
+### TYPE B: Registered Subdialog Tellask (Type B / `Tellask Session` / Registered Session Tellask)
 
 **Syntax**: `tellask({ targetAgentId: "<anyAgentId>", sessionSlug: "<tellaskSession>", tellaskContent: "..." })` (note the space before `sessionSlug`)
 
@@ -297,7 +302,7 @@ Result (second call):
 - orchestrator resumes
 ```
 
-### TYPE C: Transient Subdialog Tellask (Type C / `Fresh Tellask` / 一次性诉请)
+### TYPE C: Transient Subdialog Tellask (Type C / `Fresh Tellask` / One-shot Tellask)
 
 **Syntax**: `tellaskSessionless({ targetAgentId: "<nonSupdialogAgentId>", tellaskContent: "..." })` (NO `sessionSlug`)
 
@@ -965,12 +970,12 @@ interface RegistryMethods {
 At the start of every subdialog course, the runtime must prepend a role header to the assignment prompt:
 
 - EN: `You are the responder (tellaskee dialog) for this dialog; the tellasker dialog is @xxx (the current caller).`
-- ZH: `你是当前被诉请者对话（tellaskee dialog）的主理人；诉请者对话（tellasker dialog）为 @xxx（当前发起本次诉请）。`
+- Chinese variant: see [the Chinese doc](./dialog-system.zh.md) for the corresponding work-language header.
 
 **FBR special handling**: FBR is a self-subdialog and must keep a dedicated header to avoid confusion:
 
 - EN (example): `This is an FBR sideline dialog; the tellasker dialog is @xxx (may be the same agent).`
-- ZH（示例）: `这是一次 FBR 支线对话；诉请者对话为 @xxx（可能与当前对话同一 agent）。`
+- Chinese variant example: see [the Chinese doc](./dialog-system.zh.md) for the corresponding FBR header example.
 
 **Insertion point**: prefer a single insertion point by updating `formatAssignmentFromSupdialog()` (covers `dialog.ts`, `tellask-bridge`).
 Frontend twin must stay in sync: `dominds/webapp/src/shared/utils/inter-dialog-format.ts`.
@@ -1325,7 +1330,7 @@ sequenceDiagram
   Sub-->>Sup: supply response (resume root)
 ```
 
-### 3. Registered Subdialog Tellask (TYPE B / `Tellask Session` / 长线诉请)
+### 3. Registered Subdialog Tellask (TYPE B / `Tellask Session` / Registered Session Tellask)
 
 ```mermaid
 sequenceDiagram