dominds 1.18.2 → 1.19.2

package/dist/docs/tellask-collab.md

@@ -36,7 +36,7 @@ These points reflect current behavior in `dialog-system.md`, `fbr.md`, and `dili
 Important addition:
 
 - Only `Tellask Session` has an assignment-update channel.
-- `Fresh Tellask` has no such channel; another `tellaskSessionless` only creates another transient sideline and does not affect or tell the earlier owner to stop.
+- `Fresh Tellask` has no such channel; another `tellaskSessionless` only creates another transient Side Dialog and does not affect or tell the earlier owner to stop.
 - If later correction, earlier wrap-up, or scope change may be needed, do not choose `Fresh Tellask`; use `tellask` with `sessionSlug` from the start.
 
 ### 2.2 What `Tellask Session` really means
@@ -52,9 +52,9 @@ Short version: a Tellask Session is a resumable thread, not autonomous backgroun
 For teammate Tellasks, the runtime lifecycle is:
 
 1. Tellask is emitted.
-2. Caller waits while sideline runs.
+2. Tellasker waits while Side Dialog runs.
 3. A response is supplied back.
-4. Caller resumes.
+4. Tellasker resumes.
 
 Critical operational fact:
 
@@ -65,7 +65,7 @@ So if more work is needed, the tellasker must issue the next Tellask explicitly.
 
 ### 2.4 Diligence Push boundary
 
-- Diligence Push helps the tellasker dialog avoid going idle.
+- Diligence Push helps the tellasker avoid going idle.
 - It does not send teammate Tellasks on the agent’s behalf.
 - It is a pressure mechanism, not an execution orchestrator.
 
@@ -77,8 +77,8 @@ So if more work is needed, the tellasker must issue the next Tellask explicitly.
 
 Observed behavior:
 
-- Tellasker dialog receives “phase 1 done”.
-- Tellasker dialog then says “waiting for them to continue”.
+- Tellasker receives “phase 1 done”.
+- Tellasker then says “waiting for them to continue”.
 - No new Tellask is sent, so progress stops.
 
 Root cause:
@@ -98,7 +98,7 @@ That is a workflow break. The model should send the Tellask directly.
 
 ## 4. Best-practice execution protocol
 
-### 4.0 Inter-dialog transfer and sideline rule (mandatory)
+### 4.0 Inter-dialog transfer and Side Dialog rule (mandatory)
 
 **Transfer and markers (required)**:
 
@@ -106,24 +106,24 @@ That is a workflow break. The model should send the Tellask directly.
 - First-line markers are runtime-injected into that payload by semantics; agents must not hand-write them:
   - English work language:
     - Ask-back reply: `【TellaskBack】`
-    - Regular completed sideline reply: `【Completed】`
+    - Regular completed Side Dialog reply: `【Completed】`
     - FBR reply: `【FBR-Direct Reply】` or `【FBR-Reasoning Only】`
   - Chinese work language:
     - Ask-back reply: `【回问诉请】`
-    - Regular completed sideline reply: `【最终完成】`
+    - Regular completed Side Dialog reply: `【最终完成】`
     - FBR reply: `【FBR-直接回复】` or `【FBR-仅推理】`
-- If the requester defines a “reply/delivery format” in tellask body, keep it to the business delivery structure; do not require responder-side hand-written markers, because Dominds runtime injects those markers automatically.
+- If the tellasker defines a “reply/delivery format” in tellask body, keep it to the business delivery structure; do not require tellaskee-side hand-written markers, because Dominds runtime injects those markers automatically.
 - 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: model output from one dialog can be embedded into a runtime template and sent as another dialog body.
 
-**Sideline delivery rule**:
+**Side Dialog delivery rule**:
 
-- If a sideline dialog has completed all 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 the work-language marker automatically (`【Completed】` in English work language, `【最终完成】` in Chinese work language).
+- If a Side Dialog has completed all 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 and injects the work-language marker automatically (`【Completed】` in English work language, `【最终完成】` in Chinese work language).
 - If the work is unfinished, do not default to `tellaskBack`: first use team SOP / role ownership to judge whether a responsible owner is already clear; if yes and the issue is execution work, directly use `tellask` / `tellaskSessionless` for that owner.
-- Use `tellaskBack({ tellaskContent: "..." })` only when the upstream requester must clarify the request, decide a tradeoff, confirm acceptance criteria, provide missing input, or current SOP cannot determine ownership; do not post plain-text intermediate status updates while unfinished.
+- Use `tellaskBack({ tellaskContent: "..." })` only when the tellasker must clarify the request, decide a tradeoff, confirm acceptance criteria, provide missing input, or current SOP cannot determine ownership; do not post plain-text intermediate status updates while unfinished.
 - **FBR exception**: FBR forbids all tellask calls (including `tellaskBack` / `tellask` / `tellaskSessionless` / `askHuman`); list missing context + reasoning and return.
-- If a human user inserts a message or asks a follow-up in the sideline: just reply normally; no need to report back to the upstream requester.
+- If a human user inserts a message or asks a follow-up in the Side Dialog: just reply normally; no need to report back to the tellasker.
 
 Note: no extra "Status: ..." line is required; the first-line marker is the stage reminder.
 
@@ -228,7 +228,7 @@ Operating rules:
 
 1. `Prelude Intro`: declare shell policy (`specialist_only` / `self_is_specialist` / `no_specialist`).
 2. `uname` baseline:
-   - `specialist_only`: tellasker dialog sends one-shot Tellask to `@<shell_specialist>` and receives response.
+   - `specialist_only`: tellasker sends one-shot Tellask to `@<shell_specialist>` and receives response.
    - other policies: runtime collects and displays `uname -a`.
 3. `VCS Round-1` (same `tellaskSession`): topology inventory
    - whether rtws root is a git repo
@@ -273,7 +273,7 @@ Operating rules:
 
 ---
 
-## 6. Tellasker dialog operator checklist
+## 6. Tellasker operator checklist
 
 Before and after each collaboration step:
 
@@ -281,7 +281,7 @@ Before and after each collaboration step:
 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 `tellask* function call` block?
-5. Did I write key decisions back to Taskdoc (root dialog only) instead of leaving them in chat only?
+5. Did I write key decisions back to Taskdoc (main dialog only) instead of leaving them in chat only?
 
 ---
 

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

@@ -52,7 +52,7 @@
 对诉请者来说，一次队友诉请的运行时节奏是：
 
 1. 发出 `tellaskSessionless({ targetAgentId: "<teammate>", tellaskContent: "..." }) ...`。
-2. 当前对话进入挂起/等待（pending subdialogs）。
+2. 当前对话进入挂起/等待（pending sideDialogs）。
 3. 被诉请者完成本轮驱动并回贴结果。
 4. 诉请者恢复继续。
 
@@ -63,7 +63,7 @@
 
 ### 2.4 Diligence Push 的边界
 
-- Diligence Push 会鞭策诉请者对话继续思考和推进。
+- Diligence Push 会鞭策诉请者继续思考和推进。
 - 它不负责自动补发队友诉请，也不改变 tellask 的调用生命周期。
 - 所以它能缓解“发呆”，但不能根治“口头安排不落地”的协作停滞。
 
@@ -75,7 +75,7 @@
 
 表象：
 
-- 诉请者对话收到“阶段 1 完成”的反馈后，写下“等待对方继续执行”，但没有再次诉请。
+- 诉请者收到“阶段 1 完成”的反馈后，写下“等待对方继续执行”，但没有再次诉请。
 - 实际上队友对应支线已结束，系统也没有自动继续执行原诉请。
 
 根因：
@@ -115,9 +115,9 @@
 
 **支线交付规则**：
 
-- 只有当所有目标完成时，支线对话才可直接正常回复诉请者对话（直接发正文即可，不需要调用 tellaskBack；运行时自动注入完成标记）。
+- 只有当所有目标完成时，支线对话才可直接正常回复诉请者（直接发正文即可，不需要调用 tellaskBack；运行时自动注入完成标记）。
 - 若目标尚未完成，不要默认直接 `tellaskBack`：应先按团队规程 / SOP / 职责卡判断能否明确负责人；若能明确且属于执行性处理，直接 `tellask` / `tellaskSessionless` 对应负责人。
-- 只有当必须由上游诉请者补充需求、澄清目标、做业务裁决、确认验收口径、提供缺失输入，或现有规程无法明确判责时，才使用 `tellaskBack({ tellaskContent: "..." })` 回问诉请者对话；不得发送普通文本中间汇报。
+- 只有当必须由诉请者补充需求、澄清目标、做业务裁决、确认验收口径、提供缺失输入，或现有规程无法明确判责时，才使用 `tellaskBack({ tellaskContent: "..." })` 回问诉请者；不得发送普通文本中间汇报。
 - **FBR 例外**：FBR 禁止一切 tellask（包括 `tellaskBack` / `tellask` / `tellaskSessionless` / `askHuman`）；只列缺口 + 推理与摘要并直接回复。
 - 若人类用户在支线对话中插入消息或补问：直接正常回复，不需要向诉请者汇报。
 
@@ -229,7 +229,7 @@ tellask({
 
 1. `Prelude Intro`：声明 shell 策略（`specialist_only` / `self_is_specialist` / `no_specialist`）。
 2. `uname` 基线：
-   - `specialist_only`：诉请者对话 `tellaskSessionless({ targetAgentId: "<shell_specialist>", tellaskContent: "..." })` 发一次性诉请并接收回贴。
+   - `specialist_only`：诉请者 `tellaskSessionless({ targetAgentId: "<shell_specialist>", tellaskContent: "..." })` 发一次性诉请并接收回贴。
    - 其他两种策略：运行时采集并显示 `uname -a`。
 3. `VCS Round-1`（同一 `tellaskSession`）：确认 rtws 拓扑
    - 根路径是否 git repo
@@ -274,7 +274,7 @@ tellask({
 
 ---
 
-## 6. 面向诉请者对话主理人的协作清单
+## 6. 面向诉请者主理人的协作清单
 
 每次协作循环前后，快速自检：
 
@@ -282,7 +282,7 @@ tellask({
 2. 我现在说“等待”时，是否真有 pending tellask 对应？
 3. 回贴到达后，我是否做了“判定 + 下一轮诉请/本地动作”？
 4. 我是否把“让队友做”落成了真实 `tellask* function call`，而不是口头转派给 askHuman()？
-5. 关键决策是否已写回差遣牒（仅根对话）而不是只留在聊天里？
+5. 关键决策是否已写回差遣牒（仅主线对话）而不是只留在聊天里？
 
 ---