dominds 1.23.10 → 1.24.2

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

@@ -62,11 +62,11 @@ askerDialog 可以在执行期间接收来自当前需向它回复的支线对
 
 ### 支线对话索引 (subdlg.yaml)
 
-**subdlg.yaml** 文件索引诉请者正在等待的待处理支线对话。与 `q4h.yaml` 类似，它是一个索引文件，不是真理之源：
+**subdlg.yaml** 文件索引诉请者名下仍未回贴的后台被诉请者对话。与 `q4h.yaml` 类似，它是一个索引文件，不是真理之源：
 
-- 索引跟踪诉请者正在等待哪些支线对话 ID
+- 索引跟踪哪些支线对话 ID 仍欠 caller 回贴
 - 实际的支线对话状态从磁盘 (done/ 目录) 验证
-- 用于后端协程的崩溃恢复和自动重启
+- 用于后端协程的崩溃恢复、可观测状态和结果到达处理
 
 ### 支线对话注册表
 
@@ -112,13 +112,13 @@ askerDialog 可以在执行期间接收来自当前需向它回复的支线对
 后端协程使用以下模式驱动对话：
 
 1. 扫描全局注册表以识别需要驱动的主线对话
-2. 对于每个候选者，检查恢复条件（Q4H 已回答，支线对话完成已接收）
+2. 对于每个候选者，检查具体驱动来源（Q4H 已回答、queued prompt、结果到达、open generation 恢复等）
 3. 在驱动之前获取对话的互斥锁
-4. 执行生成循环直到挂起点或完成
+4. 执行生成循环直到自然 idle、进入 Q4H 或完成
 5. 释放互斥锁
 6. 将所有状态变更持久化到存储
 
-驱动循环持续进行，直到对话挂起（等待 Q4H 或支线对话）或完成。当条件变化时（用户回答 Q4H，支线对话完成），后端通过存储检查检测这些变化并自动恢复驱动。
+驱动循环持续进行，直到对话自然 idle、进入 Q4H 或完成。active callee dispatch 是后台被诉请者事实，不会单独挂起 caller；但只有 pending active callee dispatch、没有其它具体驱动来源时，caller 应自然 idle，不靠鞭策语维持主线空转。当用户回答 Q4H 或 callee 结果到达时，后端记录该具体事实，并仅从该事实驱动受影响对话。
 
 ### 前端集成
 
@@ -149,7 +149,7 @@ askerDialog 可以在执行期间接收来自当前需向它回复的支线对
 
 - 每次消息生成后
 - 挂起时（Q4H 提出，支线对话创建）
-- 恢复时（Q4H 已回答，支线对话完成）
+- 恢复时（Q4H 已回答，callee 结果到达）
 - 完成时
 
 这确保了崩溃恢复，并使后端能够从任何持久化状态恢复，而不依赖于前端状态。
@@ -174,23 +174,23 @@ askerDialog 可以在执行期间接收来自当前需向它回复的支线对
 点击 `Continue` 后，后端必须重新从 persistence 真源判定当前对话属于哪一种情况，而不能只根据表面的 `displayState` 做静态推断：
 
 - **情况 1：当前对话没有回复义务**
-  这时若也没有其他 blocker，就应直接继续 drive；若已回到普通待用户输入态，则 `resume_dialog` 不应再被视为可继续。
-- **情况 2：当前对话仍有回复义务，但处于 suspend 状态**
-  常见于仍在等待 Q4H / pending sideDialogs。此时 `Continue` 应退出插话 paused projection，并恢复成真实的 `blocked`。
+  这时若也没有 Q4H 等用户等待事实，就应直接继续 drive；若已回到普通待用户输入态，则 `resume_dialog` 不应再被视为可继续。
+- **情况 2：当前对话仍有回复义务，但正在等待用户输入**
+  典型例子是 pending Q4H。此时 `Continue` 应退出插话 paused projection，并恢复成真实的 `blocked`。
 - **情况 3：当前对话仍有回复义务，但已不再 suspend，具备继续推进条件**
-  例如 blocker 已消失，或存在允许继续的 queued prompt。此时 `Continue` 不应先落一个中间 `blocked/idle` 占位态，而应直接继续 drive。
+  例如 Q4H/用户等待事实已消失，或存在允许继续的 queued prompt。此时 `Continue` 不应先落一个中间 `blocked/idle` 占位态，而应直接继续 drive。
 
 **因此有两个实现约束**：
 
 - `refreshRunControlProjectionFromPersistenceFacts()` 在用户尚未点击 `Continue` 前，必须保留这层“插话已处理；原任务已暂停”的 `stopped` 投影；否则 UI 会过早塌回普通 `blocked`，破坏多轮插话体验。反过来，如果当前其实没有待恢复原任务，则根本不应建立这层 paused projection。
 - 真正决定 `Continue` 结果的逻辑，必须在恢复驱动路径中重新读取 fresh persistence facts；不能把“可点 Continue”误解为“必然立即 proceeding”。
 - 若 `Continue` 后真源仍是 `blocked`，回复责任重申文案应当立即作为 runtime guide 同时进入 `dlg.msgs` 与持久化课程历史，并同步发前端气泡；这样后面真正恢复 drive 时只需正常读取上下文，不应再额外补发一条重复的 runtime prompt。
-- run-control 工具栏中的 `resumable` 计数，应与“是否允许手动 Continue 尝试”保持一致。因此，处于 interjection-paused `stopped` 的对话即便底层仍有 blocker，也应计入 `resumable`；因为 `Continue` 的业务语义正是“退出这层临时 paused projection，并从真源重判下一步”。
+- run-control 工具栏中的 `resumable` 计数，应与“是否允许手动 Continue 尝试”保持一致。因此，处于 interjection-paused `stopped` 的对话即便底层仍有用户等待事实，也应计入 `resumable`；因为 `Continue` 的业务语义正是“退出这层临时 paused projection，并从真源重判下一步”。
 
 **心智模型提醒**：
 
 - 不能只看 `displayState.kind === 'stopped'` 就理解这条链路。
-- 不能只看 blocker facts 就理解为什么 UI 仍显示 `stopped`。
+- 不能只看用户等待事实就理解为什么 UI 仍显示 `stopped`。
 - 也不能只看 `resume_dialog` eligibility 就推断恢复后一定马上运行。
 - 更不能把所有 `origin === 'user'` 的输入都笼统视作“用户插话”；`q4hAnswerCallId` 非空的 prompt 是 askHuman answer continuation，必须按另一条语义链处理。
 
@@ -224,7 +224,7 @@ flowchart TD
 
 **行为**：
 
-1. 当前支线对话**挂起**
+1. 当前 callee 记录回问诉请并等待诉请者答复
 2. 驱动程序切换到驱动**诉请者**（TYPE A 中为直接 askerDialog；使用 `sideDialog.askerDialog` 引用）
 3. 诉请者的响应流回支线对话
 4. 支线对话**恢复**，诉请者的响应在上下文中
@@ -239,9 +239,9 @@ flowchart TD
 **支线交付规则（规范）**：
 
 - 只有当所有目标完成时，支线对话才可直接正常回复诉请者。
-- 支线对话没有独立的活性维持状态。支线继续推进，是因为正常业务状态仍未完成：工具结果需要处理、Q4H 待答、下游支线待回贴，或已有显式 runtime/user prompt 排队。不要新增只为维持活跃而存在的旁路。
+- 支线对话没有独立的活性维持状态。支线继续推进，是因为正常业务状态仍未完成：工具结果需要处理、Q4H 待答、下游 callee 待回贴，或已有显式 runtime/user prompt 排队。不要新增只为维持活跃而存在的旁路。
 - 回复义务的尾部处理是一条很小的状态机：运行时到达未挂起的尾部后，只检查本次 drive 产出的最新非空 assistant generation 候选；同一 generation 同时存在 saying/thinking 时优先取公开 saying。若支线仍欠 `replyTellask*`，并且已经产出候选内容但没有调用精确 reply 工具，运行时只排队一次 reply-tool reminder；如果模型在 reminder 后仍只产出 thinking/saying，运行时会有意通过 direct-reply fallback 投递该内容，并显式标注 fallback。
-- 运行时不得通过回扫历史消息文本来推断这个尾部状态。历史上下文属于模型和 UI；调度状态必须由当前 drive result、active reply obligation、pending blocker 索引或 queued prompt 等显式状态携带。
+- 运行时不得通过回扫历史消息文本来推断这个尾部状态。历史上下文属于模型和 UI；调度状态必须由当前 drive result、active reply obligation、pending Q4H 索引或 queued prompt 等显式状态携带。
 - 若目标尚未完成，不要默认直接 `tellaskBack`；应先按团队规程 / SOP / 职责卡判断能否明确负责人，若能明确且属于执行性处理，直接 `tellask` / `tellaskSessionless` 对应负责人。
 - 只有当必须由诉请者补充需求、澄清目标、做业务裁决、确认验收口径、提供缺失输入，或现有规程无法明确判责时，才使用 `tellaskBack({ tellaskContent: "..." })` 回问诉请者再继续。
 - **FBR 例外**：FBR 支线对话禁止一切 tellask（包括 `tellaskBack` / `tellask` / `tellaskSessionless` / `askHuman`），只能列出缺口与阻塞原因并直接回复。
@@ -275,10 +275,10 @@ flowchart TD
 LLM 发出：tellaskSessionless({ targetAgentId: "orchestrator", tellaskContent: "..." }) 我应该如何处理数据库迁移？
 
 结果：
-- sub-001 挂起
+- sub-001 记录回问诉请并等待诉请者答复
 - 驱动程序使用问题驱动 orchestrator
 - orchestrator 用指导响应
-- sub-001 恢复，Orchestrator 的响应在上下文中
+- sub-001 带着 orchestrator 的响应继续
 ```
 
 ### TYPE B：已注册支线对话诉请（长线诉请）
@@ -300,9 +300,9 @@ LLM 发出：tellaskSessionless({ targetAgentId: "orchestrator", tellaskContent:
 1. 检查注册表中是否存在键为 `agentId!sessionSlug` 的现有支线对话
 2. **如果存在**：恢复已注册的支线对话
 3. **如果不存在**：创建新的支线对话并使用键 `agentId!sessionSlug` 注册它
-4. 诉请者在支线对话运行时**挂起**
-5. 支线对话的响应流回诉请者
-6. 诉请者**恢复**，支线对话的响应在上下文中
+4. 诉请者记录后台被诉请者事实；不会仅因 active callee dispatch 被阻塞
+5. 支线对话的响应流回诉请者，形成结果到达事实
+6. 诉请者可因结果到达、queued prompt、用户输入、无 pending active callee 时的 Diligence Push 或其它显式驱动源继续
 
 **当前诉请者跟踪（对复用很重要）：**
 
@@ -339,20 +339,18 @@ LLM 发出：tellask({ targetAgentId: "researcher", sessionSlug: "market-analysi
 - 注册表查找：不存在 "researcher!market-analysis"
 - 创建新的支线对话 "researcher!market-analysis"
 - 在主线的注册表中注册它
-- orchestrator 挂起
+- orchestrator 记录后台被诉请者事实
 - 驱动 researcher 支线对话
-- 响应流回 orchestrator
-- orchestrator 恢复
+- 响应作为结果到达事实流回 orchestrator
 
 LLM 再次发出：tellask({ targetAgentId: "researcher", sessionSlug: "market-analysis", tellaskContent: "..." })
 
 结果（第二次调用）：
 - 注册表查找："researcher!market-analysis" 存在
 - 恢复现有的支线对话
-- orchestrator 挂起
+- orchestrator 记录后台被诉请者事实
 - 从离开的地方继续驱动现有的 researcher 支线对话
-- 响应流回 orchestrator
-- orchestrator 恢复
+- 响应作为结果到达事实流回 orchestrator
 ```
 
 ### TYPE C：瞬态支线对话诉请（一次性诉请）
@@ -367,13 +365,13 @@ LLM 再次发出：tellask({ targetAgentId: "researcher", sessionSlug: "market-a
 
 **行为**：
 
-1. 当前对话**挂起**
+1. 当前对话记录后台被诉请者事实；不会仅因 active callee dispatch 被阻塞
 2. 使用指定的 agentId 创建**新的支线对话**
 3. 驱动新的支线对话：
    - 一般 TYPE C 支线对话是“完整能力”的（可回问诉请者、队友诉请、按配置使用工具）。
    - `freshBootsReasoning({ tellaskContent: "..." })` 属于 FBR 特例：无工具、禁止任何诉请（见 `fbr.zh.md`）。
-4. 支线对话的响应流回诉请者
-5. 诉请者**恢复**，支线对话的响应在上下文中
+4. 支线对话的响应作为结果到达事实流回诉请者
+5. 诉请者可因结果到达、queued prompt、用户输入、无 pending active callee 时的 Diligence Push 或其它显式驱动源继续
 
 **关键特征**：
 
@@ -394,19 +392,18 @@ LLM 再次发出：tellask({ targetAgentId: "researcher", sessionSlug: "market-a
 LLM 发出：@code-reviewer 请审查这个 PR
 
 结果：
-- orchestrator 挂起
+- orchestrator 记录后台被诉请者事实
 - 使用 agentId "code-reviewer" 创建新的支线对话
 - 驱动 code-reviewer 支线对话（它可以进行自己的诉请、工具等）
-- code-reviewer 完成并返回审查结果
-- orchestrator 恢复，审查结果在上下文中
+- code-reviewer 完成，审查结果作为结果到达事实流回 orchestrator
 
 LLM 再次发出：@code-reviewer 审查这个其他 PR
 
 结果：
-- orchestrator 挂起
+- orchestrator 记录后台被诉请者事实
 - 创建另一个新的支线对话（与之前的不同！）
 - 驱动新的 code-reviewer 支线对话
-- orchestrator 恢复，新的审查结果在上下文中
+- 新的审查结果作为结果到达事实流回 orchestrator
 ```
 
 ### 对比总结
@@ -418,7 +415,7 @@ LLM 再次发出：@code-reviewer 审查这个其他 PR
 | **注册表查找**   | 否（使用 `sideDialog.askerDialog`）      | 是（`agentId!sessionSlug`）                                                              | 否（永不注册）                                                                            |
 | **恢复**         | 否（诉请者不是支线对话）                 | 是（查找找到现有的）                                                                     | 否（总是新的）                                                                            |
 | **注册**         | 不适用                                   | 创建并注册                                                                               | 永不注册                                                                                  |
-| **诉请者行为**   | 支线对话挂起                             | 诉请者挂起                                                                               | 诉请者挂起                                                                                |
+| **诉请者行为**   | callee 等待诉请者回问回复                | 诉请者记录后台被诉请者事实                                                               | 诉请者记录后台被诉请者事实                                                                |
 | **支线对话能力** | 完整（回问诉请者、队友、工具）           | 完整（回问诉请者、队友、工具）                                                           | 完整（回问诉请者、队友、工具）                                                            |
 | **用例**         | 从诉请者澄清                             | 恢复持久支线任务                                                                         | 一次性独立任务                                                                            |
 
@@ -453,15 +450,15 @@ flowchart TD
 
 4. **UI 将 Q4H 呈现为队友诉请**：UI 类似于其他队友诉请处理 Q4H，具有导航链接到对话中的诉请站点。用户使用与常规消息相同的输入文本区域内联回答。
 
-5. **支线对话响应供应**：支线对话通过持久化将响应写入*当前诉请者*的上下文（不是回调）。对于 TYPE B，每次诉请都会用最新的诉请者 + tellaskInfo 更新支线对话的 `assignmentFromAsker`，因此响应被路由到最近的诉请者（主线或支线对话）。这支持分离操作、复用和崩溃恢复。
+5. **callee 响应供应**：callee 通过持久化将响应写入*当前诉请者*的上下文（不是回调）。对于 TYPE B，每次诉请都会用最新的诉请者 + tellaskInfo 更新支线对话的 `assignmentFromAsker`，因此响应被路由到最近的诉请者（主线或支线对话）。这支持分离操作、复用和崩溃恢复。
 
-   TYPE B 长线诉请更新的确认边界必须谨慎区分：pending 状态与 `asker-stack.jsonl` 更新，只表示运行时已接受/登记新要求；只有支线 driver 实际消费 `registered_assignment_update` up-next、写入可见更新气泡和 assignment anchor 后，才表示目标支线已收到并开始处理更新。`registered_assignment_update` up-next 是运行态调度状态，不是持久化 redo log；不要为了“更新气泡”即时可重放而新增严格持久队列。后端进程重启后的业务自愈依赖 loud facts 与足够上下文（pending reminder、asker stack 最新 assignment、旧 call 是否缺少终态、目标支线是否缺少 assignment anchor），让 LLM 自主决定重发、修正或等待，而不是追求技术层面绝不丢内存队列。
+   TYPE B 长线诉请更新的确认边界必须谨慎区分：pending 状态与 `asker-stack.jsonl` 更新，只表示运行时已接受/登记新要求；只有 callee driver 实际消费 `registered_assignment_update` up-next、写入可见更新气泡和 assignment anchor 后，才表示目标 callee 已收到并开始处理更新。`registered_assignment_update` up-next 是运行态调度状态，不是持久化 redo log；不要为了“更新气泡”即时可重放而新增严格持久队列。后端进程重启后的业务自愈依赖 loud facts 与足够上下文（pending reminder、asker stack 最新 assignment、旧 call 是否缺少终态、目标 callee 是否缺少 assignment anchor），让 LLM 自主决定重发、修正或继续观察后台事实，而不是追求技术层面绝不丢内存队列。
 
 6. **支线对话注册表**：已注册的支线对话（TYPE B 长线诉请）在主线对话作用域的注册表中跟踪。注册表在 `clear_mind` 操作中持续存在，并在主线加载时重建。
 
 7. **状态保留契约**：
    - `clear_mind`：清除消息，清除 Q4H 索引，保留提醒，保留注册表
-   - 支线对话完成：向当前诉请者写入响应，从待处理列表中删除（注册表不变）
+   - callee 完成：向当前诉请者写入响应，从待处理列表中删除（注册表不变）
    - 支线对话宣布卡死：将 runState 标记为 dead，并移除对应 TYPE B 注册表条目；同一 slug 可作为全新支线重新发起
    - Q4H 回答：从索引中清除已回答的问题，继续对话
 
@@ -648,7 +645,7 @@ sequenceDiagram
   participant Driver as driveDialogStream
 
   Asker->>Side: 创建支线对话（TYPE B 或 C）
-  Note over Asker: 诉请者因待处理支线对话而阻塞
+  Note over Asker: 诉请者记录后台被诉请者事实
 
   Side->>WS: 发出 askHuman({ tellaskContent: "..." }) 问题
   WS-->>UI: questions_count_update
@@ -657,7 +654,7 @@ sequenceDiagram
   UI->>WS: drive_dialog_by_user_answer(dialog=sideDialogId, questionId, content)
   WS->>Driver: driveDialogStream(sideDialog, human answer)
   Driver-->>Side: 支线对话恢复
-  Side-->>Asker: 响应供应（清除待处理支线对话）
+  Side-->>Asker: 供应结果到达事实（清除该 pending callee）
 ```
 
 ### Q4H 与思维清晰操作
@@ -701,7 +698,7 @@ flowchart TD
 - `.dialogs/run/<root-id>/sideDialogs/<sub-id>/q4h.yaml`
 - `.dialogs/run/<root-id>/registry.yaml`（仅主线；TYPE B 注册表）
 
-### 支线对话响应供应机制
+### callee 响应供应机制
 
 **核心原则**：支线对话通过持久化向**当前诉请者**的上下文供应响应，而不是通过回调（TYPE A 时诉请者为直接 askerDialog）。
 
@@ -715,37 +712,36 @@ sequenceDiagram
   Asker->>Driver: 创建支线对话（添加到待处理列表）
   Driver->>Side: 驱动支线对话（分离执行）
   Side-->>Store: 持久化最终响应
-  Driver-->>Asker: 供应响应 + 清除待处理支线对话
-  opt 诉请者是主线且现在已解除阻塞
-    Driver-->>Asker: 设置 needsDrive=true（自动重启）
+  Driver-->>Asker: 供应结果到达事实 + 清除 pending callee
+  opt 结果到达形成显式驱动源
+    Driver-->>Asker: 设置 needsDrive=true
   end
 ```
 
-### 支线对话 Q4H 和诉请者恢复
+### 支线对话 Q4H 和诉请者结果到达
 
-当支线对话提出 Q4H 并等待人工输入时，诉请者的自动重启逻辑必须处理这种情况：
+当 callee 提出 Q4H 并等待人工输入时，caller 的 result-arrival 处理必须尊重“还没有 callee 结果”这个事实：
 
 ```typescript
-// 诉请者检查支线对话完成状态
-async function checkSideDialogRevival(askerDialog: Dialog): Promise<void> {
-  const pending = await loadPendingSideDialogs(askerDialog.id);
+// caller 检查 callee 完成状态
+async function checkCalleeResultArrival(caller: Dialog): Promise<void> {
+  const pending = await loadActiveCalleeDispatches(caller.id);
 
   for (const p of pending) {
-    // 检查支线对话是否有未解决的 Q4H
+    // 检查 callee 是否有未解决的 Q4H
     const sideDialogQ4H = await DialogPersistence.loadQuestions4HumanState(p.sideDialogId);
 
     if (sideDialogQ4H.length > 0) {
-      // 支线对话正在等待人工输入
-      // 不要自动重启 - 等待人工回答 Q4H
-      log.debug(`支线对话 ${p.sideDialogId} 有 ${sideDialogQ4H.length} 个 Q4H，跳过自动重启`);
+      // callee 正在等待人工输入；此时还不存在结果到达事实
+      log.debug(`callee ${p.sideDialogId} 有 ${sideDialogQ4H.length} 个 Q4H，跳过结果到达处理`);
       continue;
     }
 
-    // 支线对话没有 Q4H，检查是否完成
+    // callee 没有 Q4H，检查是否完成
     const isDone = await isSideDialogCompleted(p.sideDialogId);
     if (isDone) {
-      // 合并响应并自动重启
-      await incorporateSideDialogResponse(askerDialog, p.sideDialogId);
+      // 合并响应，并从这个具体事实触发后续调度
+      await incorporateSideDialogResponse(caller, p.sideDialogId);
     }
   }
 }
@@ -896,7 +892,7 @@ flowchart TD
   Key --> Lookup{注册表命中？}
   Lookup -- 是 --> Resume[恢复 + 驱动现有支线对话]
   Lookup -- 否 --> Create[创建 + 注册 + 驱动新的支线对话]
-  Resume --> Supply[向诉请者供应响应]
+  Resume --> Supply[向诉请者供应结果到达事实]
   Create --> Supply
 ```
 
@@ -1060,8 +1056,8 @@ interface RegistryMethods {
 **fork 后动作**（由后端返回给 UI）：
 
 - `draft_user_text`：若目标 generation 是一条用户输入，则把该文本回填到新对话输入框中，等待用户决定是否发送
-- `restore_pending`：若切点之前存在待处理 Q4H 或待处理支线对话，则恢复这些阻塞态，让新主线继续处于阻塞状态
-- `auto_continue`：若切点之前没有待处理阻塞，则新主线以 `interrupted(system_stop: fork_dialog_continue)` 初始化，UI 随后立即发送 `resume_dialog`
+- `restore_pending`：若切点之前存在待处理 Q4H，则恢复该用户等待状态；active callee dispatches 复制为后台被诉请者事实，不投影为阻塞态
+- `auto_continue`：若切点之前没有待处理 Q4H 等用户等待事实，则新主线以 `interrupted(system_stop: fork_dialog_continue)` 初始化，UI 随后立即发送 `resume_dialog`
 
 **一致性要求**：
 
@@ -1219,7 +1215,7 @@ Dominds 的运行时**不**持久化单一的类似枚举的 "awaiting …" 状
 
 - 持久化状态（API/索引）：`running | completed | archived`
 - 持久化 `latest.yaml`：`status`、`needsDrive`、`generating`
-- 派生的门控：`hasPendingQ4H()` 和 `hasPendingSideDialogs()`
+- 派生的门控：`hasPendingQ4H()`；active callee dispatches 是后台被诉请者事实，不是驱动门控
 
 **持久化状态生命周期**：
 
@@ -1235,9 +1231,10 @@ stateDiagram-v2
 
 ```mermaid
 flowchart TD
-  A[status=running] --> B{可以驱动？\\n（没有待处理的 Q4H\\n且没有待处理的支线对话）}
-  B -- 否 --> S[已暂停\\n（等待 Q4H 和/或支线对话）]
-  S -->|Q4H 回答\\n或支线对话响应供应| C{需要驱动？}
+  A[status=running] --> B{可以驱动？\\n（没有待处理的 Q4H）}
+  B -- 否 --> S[已暂停\\n（等待 Q4H）]
+  S -->|Q4H 回答| C{需要驱动？}
+  R[结果到达] --> C
   B -- 是 --> C{需要驱动？}
   C -- 否 --> I[空闲\\n（等待触发器）]
   C -- 是 --> D[驱动循环\\n（流式传输时 generating=true）]
@@ -1261,7 +1258,7 @@ sequenceDiagram
   Side->>Driver: 发出 `tellaskBack({ tellaskContent: "..." })` + 问题
   Driver->>Asker: 驱动诉请者以回答
   Asker-->>Driver: 响应文本
-  Driver-->>Side: 恢复支线对话，响应在上下文中
+  Driver-->>Side: 驱动 callee，诉请者响应在上下文中
 ```
 
 #### TYPE B：已注册支线对话诉请（长线诉请）（`tellask({ targetAgentId: "agentId", sessionSlug: "tellaskSession", tellaskContent: "..." })`）
@@ -1287,17 +1284,17 @@ sequenceDiagram
     Driver->>Side: 创建 + 注册 + 驱动
   end
   Side-->>Driver: 最终响应
-  Driver-->>Tellasker: 供应响应 + 清除待处理支线对话
-  opt 诉请者是主线且现在已解除阻塞
-    Driver-->>Tellasker: 设置 needsDrive=true（自动重启调度）
+  Driver-->>Tellasker: 供应结果到达事实 + 清除 pending callee
+  opt 结果到达形成显式驱动源
+    Driver-->>Tellasker: 设置 needsDrive=true（结果到达处理）
   end
 ```
 
 call-site 呼应不变量：每个 `tellask` 发起点的 `callId`，后续都必须在诉请者对话历史里留下同
-`callId` 的呼应点。正常支线回复、跨程 carryover、已注册会话被更新后的替代通知都可以结束这次
-call；不能静默删除或覆盖 pending 轮次。已注册会话被更新时，替代通知的文案不能在目标支线实际消费
-更新前宣称“更新已送达/目标支线正在按新要求处理”；在此之前只能表达“旧轮已被新要求登记替换，等待
-目标支线在安全边界消费更新”。
+`callId` 的呼应点。正常 callee 回复、跨程 carryover、已注册会话被更新后的替代通知都可以结束这次
+call；不能静默删除或覆盖 pending 轮次。已注册会话被更新时，替代通知的文案不能在目标 callee 实际消费
+更新前宣称“更新已送达/目标 callee 正在按新要求处理”；在此之前只能表达“旧轮已被新要求登记替换，目标
+callee 尚未在安全边界消费更新”。
 
 WebUI 外链不变量：生成 `/dl/*` URL 时必须在业务现场显式写出目标语义，避免复用泛化 deep-link
 helper。`/dl/callsite` 只表示诉请者对话里的发起气泡：`selfId/course` 是诉请者对话坐标，`callId`
@@ -1318,7 +1315,7 @@ sequenceDiagram
   Driver->>Side: 创建（不注册）
   Driver->>Side: 驱动
   Side-->>Driver: 最终响应
-  Driver-->>Tellasker: 供应响应（无注册表更新）
+  Driver-->>Tellasker: 供应结果到达事实（无注册表更新）
 ```
 
 ### Q4H 生命周期状态
@@ -1348,7 +1345,7 @@ sequenceDiagram
   participant Driver as driveDialogStream
 
   Asker->>Side: 创建支线对话（TYPE B 或 C）
-  Note over Asker,Side: 诉请者因待处理支线对话而阻塞
+  Note over Asker,Side: 诉请者记录后台被诉请者事实
   Side->>WS: 发出 askHuman({ tellaskContent: "..." }) 问题（Q4H）
   WS-->>UI: questions_count_update（全局）
 
@@ -1358,10 +1355,10 @@ sequenceDiagram
   WS->>Side: 清除 q4h.yaml 条目
   WS->>Driver: driveDialogStream(sideDialog, user answer)
   Driver-->>Side: 支线对话恢复并继续
-  Side-->>Asker: 支线对话响应供应给诉请者（清除待处理支线对话）
+  Side-->>Asker: callee 响应供应给诉请者（结果到达事实；清除该 pending callee）
 
-  opt 诉请者是主线且现在已解除阻塞
-    Asker-->>Asker: 设置 needsDrive=true（自动重启）
+  opt 诉请者有 result-arrival 驱动事实
+    Asker-->>Asker: 设置 needsDrive=true（结果到达处理）
   end
 ```
 
@@ -1417,7 +1414,7 @@ sequenceDiagram
   Asker->>Side: createSideDialog()
   Side->>Store: recordQuestionForHuman()
   Side-->>UI: questions_count_update（支线对话）
-  Asker-->>Asker: suspended（等待 Q4H/支线对话）
+  Asker-->>Asker: 记录后台被诉请者事实；只有 Q4H 是用户等待阻塞点
 
   User->>UI: 选择支线对话 Q4H
   User->>Asker: drive_dialog_by_user_answer(targetSideDialogId)
@@ -1426,7 +1423,7 @@ sequenceDiagram
   Side->>Store: clearQuestions4HumanState()
   Side-->>Side: driveDialogStream(answer)
   Side->>Store: write response.yaml
-  Side-->>Asker: supply response（恢复主线对话）
+  Side-->>Asker: supply result-arrival fact
 ```
 
 ### 3. 已注册支线对话诉请（TYPE B / 长线诉请）
@@ -1440,14 +1437,14 @@ sequenceDiagram
   Main->>Store: lookup registry key "researcher!market"
   alt not found
     Main->>Store: create sideDialog + save registry.yaml
-    Main->>Side: drive（主线暂停）
+    Main->>Side: drive（后台被诉请者工作）
   else found
     Main->>Store: load sideDialog + update lastAccessed
-    Main->>Side: drive（主线暂停）
+    Main->>Side: drive（后台被诉请者工作）
   end
 
   Side->>Store: write response.yaml
-  Side-->>Main: supply response（主线恢复）
+  Side-->>Main: supply result-arrival fact
 ```
 
 ### 4. 清晰度操作保留注册表

package/dist/docs/diligence-push.md

@@ -8,17 +8,16 @@ Dominds main dialogs are intended for long-run operation. A main dialog "stoppin
 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 Side Dialogs (tellask/backfill).
+- has no local work to do while retaining background callee facts (pending tellask/backfill).
 
 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).
-- **Side Dialog quirk recovery push**: when a provider/API quirk explicitly requests a one-time
-  `diligence_push_once` recovery, a Side Dialog may receive a built-in runtime template, but only
-  when it currently has an active reply obligation; the template must name the one `replyTellask*`
-  tool confirmed by runtime.
+- **Auto-continue injection**: for **main dialogs only**, whenever the driver would otherwise stop
+  and there is no Q4H or pending active callee dispatch, runtime auto-sends a short diligence prompt
+  (rendered as a normal user bubble) and continues generation. Pending tellask is a background
+  callee fact, not a blocking state; but when no other concrete drive source exists, it means the
+  main dialog has reached an idleable background-wait boundary and must not be kept spinning by a
+  Diligence Push prompt.
 - **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
@@ -28,7 +27,7 @@ This document specifies two related runtime controls:
 
 ## Goals
 
-- Prevent main dialogs from stopping except for legitimate suspension states (Q4H / Side Dialogs).
+- Prevent main dialogs from stopping except for Q4H or a natural boundary with no local work.
 - 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.
@@ -36,9 +35,9 @@ This document specifies two related runtime controls:
 ## Non-goals
 
 - Auto-completing / auto-marking a dialog as done.
-- Auto-injecting ordinary Diligence Push prompts into Side Dialogs (Side Dialogs remain scoped and
-  should report back to their tellasker; only the provider-quirk recovery exception may use the Side
-  Dialog template).
+- Auto-injecting Diligence Push prompts into Side Dialogs. Side Dialogs remain scoped and should
+  either continue from ordinary business facts or report back to their tellasker; direct-reply
+  fallback and caller-side judgment handle unintended plain-text stops.
 
 ## Definitions
 
@@ -62,30 +61,22 @@ This is the "controlled convergence" path. The diligence-push mechanism should *
 
 ### Trigger conditions (must all hold)
 
-- Dialog is the **Main Dialog**; Side Dialogs only use the provider deadlock recovery exception
-  below.
-- Dialog is **not suspended**:
-  - no pending Q4H, and
-  - no pending Side Dialogs (waiting for backfill).
+- Dialog is the **Main Dialog**.
+- Dialog has no wait fact that should legitimately stop auto-continuation:
+  - no pending Q4H.
+- no pending active callee dispatch.
 - The driver would otherwise stop the generation loop (i.e., no tool/function outputs require another iteration).
 
-### Exception: provider deadlock recovery
+### 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 sideDialogs do not veto the single Diligence Push
-injection, because the deadlock may happen in a function-result-driven generation round right after
-the main dialog has already registered an in-flight tellask/sideDialog.
-
-Side Dialogs may also use this recovery path, but only for provider/API retry-stopped deadlock
-recovery while an active reply obligation still exists. This is not a general mechanism for keeping
-Side Dialogs active. Normal Side Dialog continuation must come from ordinary business state: tool
-results, Q4H, downstream Side Dialog blockers, or queued runtime/user prompts. If no active reply
-obligation exists, runtime does not inject a push and leaves the retry-stopped state for a human to
-handle. The Side Dialog recovery template does not read rtws diligence files; it uses a built-in
-bilingual template containing the current time, the current Tellask goal, and the single
-runtime-confirmed `replyTellask*` tool (for example `replyTellaskSessionless({ replyContent })`).
-The LLM must not guess the reply variant. Q4H remains a hard blocker.
+idle" path, but it still follows the same background-wait boundary. Diligence recovery injection is
+main-dialog-only, and a pending active callee dispatch vetoes the one-time Diligence Push injection.
+Active callee dispatch is a background callee fact, not a caller blocking state: the caller may keep
+working from other concrete facts, but active callee dispatch alone is not a reason to keep driving
+the mainline. Side Dialog retry-stopped recovery does not inject a Diligence prompt; ordinary
+business facts, direct-reply fallback, or the caller's next judgment decide how work proceeds.
 
 ### Action
 
@@ -176,14 +167,13 @@ 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 / sideDialog pending), except for the deadlock-recovery
-   special case described above where one recovery-only Diligence Push may ignore pending
-   sideDialogs.
+1. If the dialog is waiting for Q4H or still has a pending active callee dispatch, stop. Active
+   callee dispatch is a background callee fact, not a caller blocking state; but without another
+   concrete drive source it is a natural idle boundary and must not trigger Diligence injection.
 2. If there is any tool feedback, continue normally.
 3. Otherwise, attempt diligence-push auto-continue:
    - Main Dialog: resolve the rtws diligence file or built-in fallback text.
-   - Side Dialog: only for provider-quirk recovery with an active reply obligation; otherwise do
-     not inject.
+   - Side Dialog: do not inject Diligence Push.
    - If disabled → stop normally.
    - If budget exhausted → emit an informational UI notice and stop further automatic Diligence
      Pushes for the current budget.
@@ -217,11 +207,11 @@ Regression tests should cover:
 
 - Main dialog: tool-only output → diligence injection → continued response
 - Main dialog: empty assistant output → diligence injection → continued response
+- Main dialog: only pending tellask / active callee dispatch → no Diligence injection; retain the
+  background state and naturally idle
 - SideDialog: ordinary idle path has no diligence injection
-- SideDialog: provider quirk recovery + active reply obligation → inject the Side Dialog template in
-  the work language, include the current Tellask goal, and name the exact active `replyTellask*`
-- SideDialog: provider quirk recovery + no active reply obligation → no injection; leave the
-  stopped/give-up state for human handling
+- SideDialog: provider quirk recovery has no Diligence injection; direct-reply fallback or caller
+  judgment handles the next business move
 - rtws config:
   - `.minds/diligence.md` is honored when lang-specific file is absent
   - empty diligence file disables diligence-push