dominds 1.24.1 → 1.24.3

package/dist/dialog-drive-work.d.ts

@@ -1,3 +1,4 @@
 import type { DialogLatestFile } from '@longrun-ai/kernel/types/storage';
 export type DialogLatestSnapshot = DialogLatestFile | null;
+export declare function hasRecoverableGenerationBeyondFinalResponse(latest: DialogLatestFile): boolean;
 export declare function hasDurableDriveWork(latest: DialogLatestSnapshot): boolean;

package/dist/dialog-drive-work.js

@@ -1,10 +1,23 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.hasRecoverableGenerationBeyondFinalResponse = hasRecoverableGenerationBeyondFinalResponse;
 exports.hasDurableDriveWork = hasDurableDriveWork;
 const dialog_generation_run_1 = require("./dialog-generation-run");
 function hasResultArrivalTrigger(latest) {
     return latest.nextStep.triggers.some((trigger) => trigger.kind === 'result_arrival');
 }
+function hasRecoverableGenerationBeyondFinalResponse(latest) {
+    if ((0, dialog_generation_run_1.getRecoverableGenerationRunState)(latest) === undefined) {
+        return false;
+    }
+    const finalResponse = latest.sideDialogFinalResponse;
+    if (finalResponse === undefined) {
+        return true;
+    }
+    return (latest.pendingRuntimePrompt !== undefined ||
+        (latest.latestAssignmentAnchor !== undefined &&
+            latest.latestAssignmentAnchor.callId !== finalResponse.callId));
+}
 function hasDurableDriveWork(latest) {
     if (!latest) {
         return false;
@@ -14,8 +27,14 @@ function hasDurableDriveWork(latest) {
         (replyDelivery.status === 'pending' || replyDelivery.toolResultStatus === 'pending')) {
         return true;
     }
+    if (latest.pendingRuntimePrompt !== undefined) {
+        return true;
+    }
+    if (hasRecoverableGenerationBeyondFinalResponse(latest)) {
+        return true;
+    }
     if (latest.sideDialogFinalResponse !== undefined) {
         return hasResultArrivalTrigger(latest);
     }
-    return (latest.nextStep.triggers.length > 0 || (0, dialog_generation_run_1.getRecoverableGenerationRunState)(latest) !== undefined);
+    return latest.nextStep.triggers.length > 0;
 }

package/dist/docs/tellask-background-continuation-refactor.zh.md

@@ -97,12 +97,62 @@ Diligence Push 是例外：它只作用于主线对话，因为它是编排保
 
 因此 `blocker` 只应作为旧代码命名或旧 displayState 的迁移对象被提及，不应成为新设计里的业务概念。
 
+### 业务 continuation：只记录意图，轮到时重新 claim
+
+这次重构的核心抽象不是“无 prompt 驱动是否有资格继续”，而是“当前有一个什么业务 continuation 需要尝试处理”。
+
+原则：
+
+- continuation 只记录“想继续什么业务”，不记录“创建当时判断过，所以未来一定可以继续”。
+- continuation 轮到执行时，必须基于最新持久事实重新 claim / decide。
+- 事实仍成立：消费 continuation 并继续。
+- 事实已变化：作为 stale continuation 静默丢弃，最多写 `debug` 日志。
+- 事实冲突：说明状态不自洽，按 loud error policy 失败。
+- 事实暂时被先决等待阻塞：保留 continuation 或投影成对应阻塞态，不在调度循环里拼接跨场景规则。
+
+这条原则的价值在于把跨时间线判断局部化封装起来。调度循环只负责按顺序取出 continuation，并把它交给对应业务 handler；handler 自己读取最新状态并决定是否仍然成立。这样可以避免现在的 `source + reason + noPromptSideDialogResumeEntitlement + executionMarker + sideDialogFinalResponse + nextStep` 在一个大 gate 里互相缠绕。
+
+目标形态：
+
+```ts
+type DialogContinuation =
+  | { kind: 'user_message'; msgId: string }
+  | { kind: 'user_answered_human_request'; questionId: string; callId: string }
+  | { kind: 'assignment_arrived'; promptId: string; callId: string }
+  | { kind: 'assignment_updated'; promptId: string; callId: string; sessionSlug: string }
+  | { kind: 'requested_work_replied'; batchId: string }
+  | {
+      kind: 'deliver_tellask_reply';
+      targetDialogId: string;
+      targetCallId: string;
+      expectedReplyCallName: 'replyTellask' | 'replyTellaskSessionless' | 'replyTellaskBack';
+    }
+  | { kind: 'operator_continue_original_task'; dialogId: string }
+  | { kind: 'recover_open_generation'; course: number; genseq: number }
+  | { kind: 'mainline_diligence'; diligenceId: string };
+```
+
+这个 union 是业务语义草图，不要求一次性落地成对外协议；目标是约束内部命名和控制流：任何新 continuation 都必须能回答“哪个业务事实到了、轮到时如何按最新事实重新判断”。
+
+典型 claim 规则：
+
+- `requested_work_replied(batchId)`：读取 `active-callees.json` / batch 状态。batch 仍 complete 且未消费，则把 batch 结果注入上下文并消费；batch 已删除或已消费，则 stale `debug` 丢弃；batch 状态冲突则 loud fail。
+- `deliver_tellask_reply(targetCallId)`：读取 active reply obligation 和 `sideDialogFinalResponse`。同一 `targetCallId` 的回复义务仍存在且未 final，则注入 reply reminder / reassertion；义务消失、callId 已变化或 final anchor 已覆盖该 callId，则 stale `debug` 丢弃；callId 相同但 expected reply tool / target dialog 不一致，则 loud fail。
+- `operator_continue_original_task`：读取 deferred reply reassertion、active callee、user wait、execution marker 等最新事实。原任务仍被下游阻塞，则恢复真实阻塞态；原任务已不阻塞，则把 deferred reassertion 转成 runtime prompt 并继续；没有 parked original task，则 stale `debug` 丢弃。
+- `recover_open_generation(course,genseq)`：只读取 `generationRunState.open`。同一 open generation 仍存在则恢复；已 closed 则 stale `debug` 丢弃；状态缺失/冲突则 malformed / loud fail。
+
+日志原则：
+
+- stale continuation 是正常竞速结果，使用 `debug`。
+- 因状态冲突导致无法判断的 continuation 是一致性问题，使用 loud error / stream error / structured diagnostic。
+- 不把 stale continuation 打成 ERROR；ERROR 应只表示协议/状态机不自洽或 unsafe path。
+
 ### 同类概念也要降级
 
 类似 `blocker`，下面几个词也容易把技术症状误升级成业务机制：
 
 - `needsDrive`：业务上不是“这个 dialog 需要被驱动”的抽象状态，而是有一个具体下一步动作来源：用户输入、queued prompt、主线 Diligence Push、回贴结果到达、open generation 续跑等。目标实现不再保留 boolean 投影；只保留具体 `nextStep.triggers` 和 registry wake signal。
-- `entitlement` / `revive`：业务上不是某个 dialog 获得“恢复权”，而是“有新事实到达，caller 应处理”。目标实现以 `result_arrival` trigger 表达这件事；若底层仍临时保留 entitlement token，只能作为防重入/防误续推的内部令牌，并必须携带同一个 `batchId`。
+- `entitlement` / `revive`：业务上不是某个 dialog 获得“恢复权”，而是“有新事实到达，caller 应处理”。目标实现以业务 continuation 表达这件事，例如 `requested_work_replied(batchId)` 或 `deliver_tellask_reply(targetCallId)`；若底层仍临时保留 entitlement token，只能作为迁移期防重入/防误续推的内部令牌，并必须携带同一个业务 identity。
 - `wait-group`：业务上不是 caller 正在等待一组 callee，而是“同一次派发批次的回贴结果要成组收口”。因此设计用 dispatch batch / 派发批次描述，不再新增 `waitGroupId` 这类等待语义字段名。
 - `proceeding recovery`：业务上不是恢复 proceeding 状态，而是“上一次 generation 确认未闭合，所以继续同一轮”。已闭合 generation 只能从状态快照重新投影状态。
 - `latest` / `displayState`：业务事实的来源应是状态机转移时维护的结构化元信息；`displayState`、run-control counts 都只是投影，不能反向决定业务事实。
@@ -532,6 +582,60 @@ pending tellask observability 使用 `PendingBackgroundWork`。四者不可混
 - completion obligations 决定“这个 dialog 是否还欠上游交付”。
 - background work 决定“有哪些后台诉请仍在进行中”。
 
+### 1.5. 把 reply obligation follow-up 改成业务 continuation
+
+`reply_obligation_follow_up` 是第一批适合下手的迁移点。它现在通过 `noPromptSideDialogResumeEntitlement.reason='reply_obligation_follow_up'` 表示“这次无 prompt sideDialog drive 可以继续”，这会把调度资格和业务事实绑在一起。目标态应改为一个局部自洽的 continuation：
+
+```ts
+type DeliverTellaskReplyContinuation = {
+  kind: 'deliver_tellask_reply';
+  targetDialogId: string;
+  targetCallId: string;
+  expectedReplyCallName: 'replyTellask' | 'replyTellaskSessionless' | 'replyTellaskBack';
+};
+```
+
+创建点：
+
+- sideDialog 或 ask-back dialog 生成了可疑似最终回复的普通自然语言内容；
+- 当前 prompt 不是 reply tool reminder；
+- active reply obligation 仍存在；
+- 系统需要排一条 runtime reminder，让模型用正确的 `replyTellask*` 完成交付。
+
+创建时只记录目标业务 identity，不把“未来一定可继续”的判断固化进去。轮到执行时重新读取最新事实：
+
+```ts
+async function claimDeliverTellaskReplyContinuation(
+  dialogId: DialogID,
+  continuation: DeliverTellaskReplyContinuation,
+): Promise<'claimed' | 'stale'> {
+  const latest = await DialogPersistence.loadDialogLatest(dialogId, 'running');
+  const active = await DialogPersistence.loadActiveTellaskReplyObligation(dialogId, 'running');
+  const finalResponse = latest?.sideDialogFinalResponse;
+
+  if (finalResponse?.callId === continuation.targetCallId) return 'stale';
+  if (active === undefined) return 'stale';
+  if (active.targetCallId !== continuation.targetCallId) return 'stale';
+  if (active.targetDialogId !== continuation.targetDialogId) {
+    throw new Error('reply obligation continuation invariant violation: target dialog changed');
+  }
+  if (active.expectedReplyCallName !== continuation.expectedReplyCallName) {
+    throw new Error('reply obligation continuation invariant violation: reply tool changed');
+  }
+  return 'claimed';
+}
+```
+
+业务含义：
+
+- 当前仍有同一个 `targetCallId` 的回复义务：继续注入/消费 reply reminder。
+- 回复义务已经消失：说明已交付或状态变化，stale `debug` 丢弃。
+- 当前回复义务换成别的 callId：说明这条 continuation 是旧任务的迟到唤醒，stale `debug` 丢弃。
+- final response anchor 已覆盖该 callId：说明该 callId 已完成，stale `debug` 丢弃。
+- callId 相同但 target dialog / expected reply tool 改变：这是状态不自洽，loud fail。
+
+这能替代当前 `reply_obligation_follow_up` 和 `final response anchor` 的大 gate 组合：不再问“这个 no-prompt drive 有没有 entitlement”，而是问“这条 deliver-tellask-reply continuation 对应的回复义务此刻是否仍成立”。
+
 ### 2. 调整 dialog display projection
 
 `computeIdleDisplayState()` 对任意 dialog：
@@ -717,7 +821,7 @@ closed-generation projection 清掉 stale `generating` 后，要同步处理 `ne
 
 - 更新 `active-callees.json` 中对应 batch member 的 resolved/final 状态。
 - 若同 batch 已全部完成，则把 batch 标记为 `resolved`，写入 `result_arrival` trigger，并由 backend/直接调度路径启动 caller 处理新事实。
-- schedule 等待方 drive，带当前实现所需的 `noPromptSideDialogResumeEntitlement`。
+- schedule 等待方 drive 只负责叫醒；真正是否继续，由 `requested_work_replied(batchId)` continuation 在轮到时重新读取 batch / trigger / user wait 等最新事实后 claim。
 
 保留原则：
 
@@ -727,7 +831,7 @@ closed-generation projection 清掉 stale `generating` 后，要同步处理 `ne
 - 多路同组 reply 中间态不得触发 caller LLM generation，但要更新 observability、pending reminder 和对应 call bubble。
 - 自动继续 prompt/drive 应明确携带“有新回贴事实可处理”的原因。
 - 若等待方正在 Q4H / askHuman user wait 中，batch complete 仍写入 `result_arrival` trigger，但 driver 停在 user wait；用户回答清除 user wait 后再消费该 trigger。
-- 当前实现里的 revive entitlement 应携带 `batchId` / batch completion facts，并对应生成 `result_arrival` trigger；目标态移除“全局 pending sideDialogs 是否为空”这类猜测。
+- 当前实现里的 revive entitlement 应先收敛为携带 `batchId` / batch completion facts 的迁移期令牌，并对应生成 `result_arrival` trigger；目标态移除 entitlement，保留 `requested_work_replied(batchId)` 业务 continuation。
 - 若等待方 dialog 已经 idle，收到回贴可以自动 drive 处理结果；这不违反 background_continue。
 
 ## 模块级改造清单
@@ -890,6 +994,22 @@ UI 业务状态投影结论：
     - 输入：模拟 event 写入成功但状态快照元信息未更新的异常路径。
     - 期望：runtime 发 warning / structured diagnostic，把该 dialog 转移到 `malformed/`，停止 unsafe drive；不回扫历史补猜。
 
+22. reply obligation follow-up stale 丢弃。
+    - 输入：排入 `deliver_tellask_reply(targetCallId=A)` continuation 后，A 对应 active reply obligation 已被 reply tool / direct-fallback 完成，或 `sideDialogFinalResponse.callId=A` 已存在。
+    - 期望：continuation 执行时重新 claim 最新事实，发现已完成后 `debug` 丢弃；不新增 gen_start，不写 ERROR/WARN。
+
+23. reply obligation follow-up callId 换绑。
+    - 输入：排入 `deliver_tellask_reply(targetCallId=A)` 后，当前 active reply obligation 已变为 `targetCallId=B`。
+    - 期望：A 的 continuation 作为旧任务迟到唤醒 `debug` 丢弃；B 的回复义务不被 A 的 continuation 消费。
+
+24. reply obligation follow-up 同 callId 但 target/tool 冲突。
+    - 输入：排入 `deliver_tellask_reply(targetCallId=A, expectedReplyCallName=replyTellaskSessionless)`，执行时 active reply obligation 仍是 A，但 target dialog 或 expected reply tool 与 continuation 不一致。
+    - 期望：按 loud error policy 失败，记录稳定关联字段；不能静默按任一方继续。
+
+25. 用户插话期间下游回贴到达。
+    - 输入：sideDialog 因用户插话进入 `user_interjection_pause_resume_original_task`，随后下游 active callee batch complete，产生 `requested_work_replied(batchId)` continuation。
+    - 期望：continuation 基于最新事实 claim；若原任务已不再被其它事实阻塞，则自动结束插话暂停并交付 deferred reply reassertion；若仍被其它先决事实阻塞，则恢复真实阻塞态，不在调度循环里用特殊组合规则硬拼。
+
 ### 重启恢复测试
 
 1. closed single pending tellask generation + stale `generating=true`。
@@ -956,6 +1076,7 @@ UI 业务状态投影结论：
 - `nextStep` 已成为必要字段，`latest` 缺失它或 trigger 结构不合法就直接进入 `malformed/`，不再自动补猜。
 - `latest.tellaskCalls` 和 `latest.tellaskResults` 都已落地，tellask call/result duplicate 判定读取 latest 索引，不再扫描当前 course JSONL。
 - `replyDelivery`、`latest.userWait`、`latestAssignmentAnchor`、`sideDialogFinalResponse` 等状态字段都已补齐，恢复/尾部判定优先读状态快照。
+- reply obligation follow-up 已经不再依赖创建时绑定的 `noPromptSideDialogResumeEntitlement`；尾部会按最新事实重新认领，并在 `driveDialogStreamCore` 已经先消费更新 bubble 的场景下，按最后一个 assistant output 对应的 reply target 重新回绑到当前业务义务，避免更新诉请竞速把后续回贴继续机会锁死。
 
 调度和唤醒也已收敛：
 
@@ -963,6 +1084,8 @@ UI 业务状态投影结论：
 - `globalDialogRegistry` 只承载 live registry 与 wake signal，`wakeDrive` / `clearDriveWake` / `isDriveWakeQueued` 是唯一公开语义。
 - backend loop 只扫描 live root dialog 本身 + root-local `drive-watch.json` 中的支线子集；支线只在 `latest.nextStep.triggers`、open `generationRunState`、pending/delivered-but-tool-result-pending `replyDelivery` 等 durable work 存在时进入 watch。
 - `root_drive_wake` 若在 generation start 被 accepted 后遇到 core/tail failure，会重新写回 durable wake，避免失败收尾误清队列。
+- `reply_obligation_follow_up` 第一刀已落地：runtime reply reminder 不再通过 `noPromptSideDialogResumeEntitlement.reason='reply_obligation_follow_up'` 获得无 prompt drive 资格，而是在轮到消费 queued prompt 时读取最新 `sideDialogFinalResponse`、target dialog `tellaskResults`、当前 sideDialog assignment / active reply obligation 后重新 claim。若这次 assistant output 已经在 core 内部消费了更新 bubble，则 tail 会按最后一个 assistant output 的 reply target 重新认领当前义务，再决定是否继续。旧 callId 已完成、回复义务已消失、或当前回复义务换成其它 callId 时，queued reminder 以 `debug` 丢弃；callId 相同但 target/tool/content 不一致时 loud fail。
+- stale reply reminder 被丢弃后，如果最新状态没有其它 durable drive work，driver 直接停止，不进入 core 开空 generation；caller result-arrival 在 final response anchor 后也不再绕一圈旧的 invalid reply-tool detour。
 
 UI 和投影语义也已对齐：
 
@@ -980,18 +1103,21 @@ UI 和投影语义也已对齐：
 
 ## 迁移步骤
 
-1. 新增 generationRunState、DialogUserWaitState、NextStepTriggerState、dispatch batch、reply delivery status 等状态机元信息，并在每次状态转移时同步维护。
-2. 移除 runtime 历史回扫补猜路径；旧 dialog 缺必要元信息时进入 `malformed/`。如确有业务价值，由人类手工分析 `malformed/` 记录并修正后续跑。
-3. 新增 fact helpers：user wait、next-step facts、completion obligations、background pending work，全部读取状态快照。
-4. 调整 dialog `getSuspensionStatus()` 或新增 next-step facts API，先让 drive 使用新 API；API 必须按角色区分 caller background work 与 callee completion obligation。
-5. 调整 display projection，移除 pending tellask -> `waiting_for_sideDialogs`，覆盖 caller/callee 角色组合。
-6. 调整 post-tool continuation，把 pending tellask ack 从 immediate followup 中排除并加测试。
-7. 新增 `active-callees.json`，以 `batchId` 保证多路同组回复齐后才触发 result-arrival handling；消费后删除 batch，不累积历史。
-8. 调整 Diligence Push，显式读取状态快照里的 pending tellask context 并改文案。
-9. 调整 restart recovery，仅读取状态快照判断 open/closed generation；缺元信息或冲突时转移到 `malformed/`。
-10. 调整 proceeding recovery，只恢复真正 open generation。
-11. 调整 backend loop，避免 `resumeInProgressGeneration` 绕过已 closed background boundary。
-12. 更新 tests / docs / UI run-control copy。
+1. 已完成：建立业务 continuation 抽象和 claim 原则。调度层只负责叫醒/取下一条 continuation；业务 handler 轮到时重新读取最新持久事实决定 claimed / stale / conflict。
+2. 已完成第一刀：迁移 `reply_obligation_follow_up`。queued runtime reply reminder 携带 `targetCallId`、`targetDialogId`、`expectedReplyCallName` 和诉请内容，执行时重新读取 active reply obligation、sideDialog assignment、target tellask result 和 final response anchor；若 core 已先消费更新 bubble，则 tail 会按最后一个 assistant output 的 reply target 重新认领当前义务。stale 用 `debug` 丢弃，状态冲突 loud fail。
+3. 下一刀：迁移 `result_arrival` / caller revive，用 `requested_work_replied(batchId)` continuation 替换 revive entitlement；direct schedule 和 backend watch 都只叫醒，claim 时读取 batch/trigger 最新事实。
+4. 新增 generationRunState、DialogUserWaitState、NextStepTriggerState、dispatch batch、reply delivery status 等状态机元信息，并在每次状态转移时同步维护。
+5. 移除 runtime 历史回扫补猜路径；旧 dialog 缺必要元信息时进入 `malformed/`。如确有业务价值，由人类手工分析 `malformed/` 记录并修正后续跑。
+6. 新增 fact helpers：user wait、next-step facts、completion obligations、background pending work，全部读取状态快照。
+7. 调整 dialog `getSuspensionStatus()` 或新增 next-step facts API，先让 drive 使用新 API；API 必须按角色区分 caller background work 与 callee completion obligation。
+8. 调整 display projection，移除 pending tellask -> `waiting_for_sideDialogs`，覆盖 caller/callee 角色组合。
+9. 调整 post-tool continuation，把 pending tellask ack 从 immediate followup 中排除并加测试。
+10. 新增 `active-callees.json`，以 `batchId` 保证多路同组回复齐后才触发 result-arrival handling；消费后删除 batch，不累积历史。
+11. 调整 Diligence Push，显式读取状态快照里的 pending tellask context 并改文案。
+12. 调整 restart recovery，仅读取状态快照判断 open/closed generation；缺元信息或冲突时转移到 `malformed/`。
+13. 调整 proceeding recovery，只恢复真正 open generation。
+14. 调整 backend loop，避免 `resumeInProgressGeneration` 绕过已 closed background boundary。
+15. 更新 tests / docs / UI run-control copy。
 
 ## 风险与判定
 
@@ -1007,9 +1133,12 @@ UI 和投影语义也已对齐：
 
 ### 判定原则
 
+- 业务 continuation 创建时只记录业务 identity 和意图；轮到执行时必须重新读取最新持久事实 claim，不能复用创建时的判断结论。
+- stale continuation 是正常竞速结果，使用 `debug` 丢弃；只有事实冲突、元信息缺失或 unsafe path 才 loud fail。
 - pending tellask 存在时，caller dialog 可被驱动，但不是因为 pending tellask 必须驱动。
 - pending tellask 存在时，caller dialog 可 idle，但 idle 不代表后台完成。
 - active reply obligation 存在时，当前 dialog 是 callee；它需要最终通过对应 reply path 收口，但它自己的下游 pending tellask 不决定它是否继续推进。
+- reply obligation follow-up 必须绑定具体 `targetCallId`；当前 active reply obligation 已消失、已换 callId、或 final response anchor 已覆盖该 callId 时，该 follow-up stale 丢弃。
 - caller 处理 callee 回复时，触发粒度是 dispatch batch complete；单个 `tellask` 是 size = 1 的特例。
 - 只有不存在 `awaiting_user_answer` 等先决等待事实，且存在未消费 `NextStepTriggerState` trigger 或当前工具轮产生 immediate tool result，才能启动新一轮。
 - 已有 `gen_finish_record` 的 generation 不应被 proceeding recovery 重放。

package/dist/llm/kernel-driver/drive.js

@@ -1197,7 +1197,7 @@ function reserveKnownFunctionCallId(reservation, callId) {
         reservation.knownCallIds.add(normalized);
     }
 }
-function collectKnownFunctionCallIdsForCurrentCourse(dialog) {
+async function collectKnownFunctionCallIdsForCurrentCourse(dialog) {
     const known = new Set();
     const addKnown = (callId) => {
         const normalized = trimOptionalCallId(callId);
@@ -1218,6 +1218,29 @@ function collectKnownFunctionCallIdsForCurrentCourse(dialog) {
         addKnown(msg.rawId);
         addKnown(msg.effectiveId);
     }
+    const persistedEvents = await persistence_1.DialogPersistence.loadCourseEvents(dialog.id, course, dialog.status);
+    for (const event of persistedEvents) {
+        switch (event.type) {
+            case 'func_call_record': {
+                addKnown(event.id);
+                addKnown(event.rawId);
+                addKnown(event.effectiveId);
+                break;
+            }
+            case 'func_result_record': {
+                addKnown(event.id);
+                addKnown(event.rawId);
+                addKnown(event.effectiveId);
+                break;
+            }
+            case 'tellask_call_record': {
+                addKnown(event.id);
+                break;
+            }
+            default:
+                break;
+        }
+    }
     return known;
 }
 function allocateDuplicateEffectiveCallId(args) {
@@ -1265,7 +1288,7 @@ function allocateEffectiveFunctionCallId(args) {
 }
 async function normalizeGeneratedFunctionCallIds(args) {
     const reservation = {
-        knownCallIds: new Set(collectKnownFunctionCallIdsForCurrentCourse(args.dialog)),
+        knownCallIds: new Set(await collectKnownFunctionCallIdsForCurrentCourse(args.dialog)),
         seenRawIdsThisRound: new Set(),
         nextDuplicateSuffixByRawId: new Map(),
     };
@@ -1426,6 +1449,7 @@ async function executeFunctionRound(args) {
             immediateFollowupCallIds: [],
             immediateTellaskOutputCallIds: [],
             shouldStopAfterReplyTool: false,
+            shouldStopAfterPendingTellaskWait: false,
             pairedMessages: [],
             tellaskToolOutputs: [],
         };
@@ -1535,6 +1559,7 @@ async function executeFunctionRound(args) {
         immediateFollowupCallIds,
         immediateTellaskOutputCallIds: tellaskRound.immediateTellaskOutputCallIds,
         shouldStopAfterReplyTool: tellaskRound.shouldStopAfterReplyTool,
+        shouldStopAfterPendingTellaskWait: tellaskRound.shouldStopAfterPendingTellaskWait,
         pairedMessages,
         tellaskToolOutputs: [...tellaskRound.toolOutputs],
     };
@@ -2809,6 +2834,14 @@ async function driveDialogStreamCore(dlg, callbacks, humanPrompt, driveOptions)
                         routed.hasImmediateTellaskOutputs ||
                         invalidFuncCallCount > 0;
                     if (!shouldStartImmediatePostToolGeneration) {
+                        if (routed.shouldStopAfterPendingTellaskWait) {
+                            log_1.log.debug('kernel-driver stop round after pending tellask wait boundary', undefined, {
+                                dialogId: dlg.id.valueOf(),
+                                rootId: dlg.id.rootId,
+                                selfId: dlg.id.selfId,
+                            });
+                            break;
+                        }
                         const healthFirst = await maybeContinueWithHealthPromptBeforeDiligence({
                             dlg,
                             providerCfg,