@sema-agent/client-core 0.77.0 → 0.77.2

package/dist/notifications.js

@@ -1,19 +1,10 @@
-/**
- * 通知投影纯函数(抽自 sema-cli engineTaskNotification/upstreamBridge 通知臂;
- * result 段纪律=cli #49 C1:帧带 result 必入 XML,core renderTaskNotificationXml 同名 tag 同段序)。
- * 0.4.0(B2 批)起本模块还含:engineTaskNotification 全文(台账/watcher/入队合成)、
- * taskNotificationErrorSupplement 全文、hookNoticeStore 的判定半场 —— 见文件下半的 B2 分节。
- */
 import { hostEnv } from './hostEnv.js';
 import { unrefTimer } from './unrefTimer.js';
 import { clearEnginePanelTaskResidentByWire, publishEngineAgentPanelEvent, } from './engineAgentPanelStore.js';
-// L-215②(0.65.0;core [6908]):「非成功终局」的**单铸谓词** —— 面板 settle 的 `isError` 位与
-// 三端自己的后台白名单必须读同一个判据;内联一个 `=== 'failed' || === 'killed'` 就是第二份会漂的台账。
 import { isTaskNotificationTerminalStatus, isTerminalNotSuccess, isTerminalStatus } from './runTerminal.js';
 function escapeXml(v) {
     return v.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;');
 }
-/** 通知 user-turn XML 渲染(core task-notification 同形;external 帧开标签带 from= 属性)。 */
 export function renderTaskNotificationXml(n) {
     const openTag = n.taskType === 'external' && n.externalSource
         ? `<task-notification type="external" from="${escapeXml(n.externalSource.replace(/\s+/g, ' ').slice(0, 120)).replace(/"/g, '&quot;')}">`
@@ -27,13 +18,6 @@ export function renderTaskNotificationXml(n) {
 <summary>${escapeXml(n.summary)}</summary>${seg('result', n.result)}${linesBlock}${stepsBlock}${typeof n.resumable === 'boolean' ? `\n<resumable>${n.resumable}</resumable>` : ''}
 </task-notification>`;
 }
-/**
- * core 1.262.0 残局包([558]A/D)— 从 task_notification 帧派生残局显示行,与 core 进程内
- * renderResidual(core/task-notification.ts:75-86)**逐字节对齐**:先 `- tool target → outcome`
- * 步骤行,再 ONE `edited: path (×N), …` 行(editedFiles 折进 recent-steps,core 不铸独立
- * <edited-files> tag——别自创)。字段是 additive 的,老引擎没有 ⇒ []。返回裸串,转义由调用方按
- * 自己的面做(XML/Ink 行)。cli deriveNotificationResidualLines 的等价搬运。
- */
 export function deriveNotificationResidualLines(n) {
     const out = [];
     if (Array.isArray(n.recentSteps)) {
@@ -56,17 +40,10 @@ export function deriveNotificationResidualLines(n) {
     }
     return out;
 }
-/**
- * 引擎 task_notification 原始 payload → renderTaskNotificationXml 的入参(**含上面注释里那两条
- * 回填**:summary 缺省 ⇒ `Background task "<id>" <status>`;status 非串 ⇒ 'unknown',summary 改说 outcome unknown)。
- * task_id 空串/缺失 ⇒ null(RB-75 同族:空 id 会塌成 ':status' 共享桶互吞,无 id 的通知本就无意义)。
- * 字段名映射按 wire 真形:task_id/output_file/task_type/source 是 snake/wire 名,其余同名。
- */
 export function normalizeTaskNotification(n) {
     const taskId = typeof n.task_id === 'string' && n.task_id.length > 0 ? n.task_id : undefined;
     if (taskId === undefined)
         return null;
-    // 0.72.12 CC-50(#59 A-08):status 非串 ⇒ 'unknown'(此前 'completed',并用它编 summary 与去重键)。
     const status = typeof n.status === 'string' ? n.status : 'unknown';
     const lines = Array.isArray(n.lines)
         ? n.lines.filter((l) => typeof l === 'string')
@@ -98,33 +75,14 @@ export function normalizeTaskNotification(n) {
         ...(typeof n.source === 'string' && n.source.length > 0 ? { externalSource: n.source } : {}),
     };
 }
-/** 通知去重键——cli engineTaskNotificationDedupKey **逐字等价**(对抗复审抓的
- *  等价性破坏,0.1.1 修):无 seq 不追加段(与 seq:1 是不同键);仅 external 用
- *  `external:` 前缀;seq 收 number|string。格式:`[external:]taskId:status[:seq]`。 */
 export function taskNotificationDedupKey(n) {
     const seq = typeof n.seq === 'number' || typeof n.seq === 'string' ? String(n.seq) : '';
     const lane = n.taskType === 'external' ? 'external:' : '';
     return `${lane}${n.taskId}:${n.status}${seq ? `:${seq}` : ''}`;
 }
-/**
- * ⇄ B7(T2):同一把键的 **裸 wire 载荷** 入口 —— cli `upstreamBridge.engineTaskNotificationDedupKey`
- * 的等价物(入参是引擎 `task_notification` 帧的原始 payload:snake_case `task_id` / `task_type`)。
- *
- * 🔴 **不是第二份算法**:字段归一之后直接委托给上面那一个 `taskNotificationDedupKey`。
- * 两份手写算法正是这条键在 0.1.1 被 对抗复审抓到过的形(无 seq 追不追段的差异会让
- * 「重放去重」整条失效而两边代码看着都对);pure 门 B7 段对两个入口做**同键对拍**。
- *
- * 键形:`[external:]taskId:status[:seq]`。缺 `task_id` ⇒ 空 taskId 段(与 cli 逐字一致 ——
- * 空 id 的通知本就在 `normalizeTaskNotification` 那一层被丢弃,这里不额外加语义)。
- *
- * ⚠️ **P1-3(完成事件单一权威)未到货 ⇒ 只搬不删**:引擎给出 `completionId` 之后,这把
- * 「客户端按 taskId:status[:seq] 自己重算」的键才能换成「读引擎发的 id」。退役条件见
- * `compensations.ts` 的 T2 行。
- */
 export function taskNotificationDedupKeyFromWire(n) {
     return taskNotificationDedupKey({
         taskId: typeof n.task_id === 'string' ? n.task_id : '',
-        // CC-50:与 normalizeTaskNotification 同判,缺席不与真 completed 同桶。
         status: typeof n.status === 'string' ? n.status : 'unknown',
         ...(typeof n.seq === 'number' || typeof n.seq === 'string' ? { seq: n.seq } : {}),
         ...(typeof n.task_type === 'string' ? { taskType: n.task_type } : {}),
@@ -172,11 +130,6 @@ export function parseTranscriptNotificationSeeds(messages) {
                     continue;
                 const external = /\btype="external"/.test(attrs);
                 renderedKeys.push(`${external ? 'external:' : ''}${taskId}:${status}`);
-                // L-215② 族扫(0.65.0):终局判据走单铸谓词 —— 修前这里手抄三词,core [6908] 的 `blocked`
-                //    漏在外面 ⇒ 一条已经渲过的 `blocked` 通知不进 `notifiedKeys`,重开会话后**再投一次**。
-                // 0.73.3(CC-60 A-D11):这条 XML 有**两个生产者**、两张终局词表 —— core task-notification(带 cancelled)与本包
-                //    enqueueBgChildNotification(status 来自 run 行状态面,带 blocked)⇒ 按**并集**判终局;`event` 是唯一非终局。
-                //    两张冻结元组各自不动(动任一张 = 把另一个生产者的词丢掉)。
                 if (!external && (isTerminalStatus(status) || isTaskNotificationTerminalStatus(status))) {
                     notifiedKeys.push(taskId);
                 }
@@ -186,21 +139,6 @@ export function parseTranscriptNotificationSeeds(messages) {
     }
     return { renderedKeys, notifiedKeys, seeded };
 }
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2「通知族合并」):cli 三个文件并入本模块
-//   ① src/sema/engineTaskNotification.ts(347 行,台账 + watcher + 入队合成)
-//   ② src/sema/taskNotificationErrorSupplement.ts(58 行,纯函数)
-//   ③ src/sema/hookNoticeStore.ts(177 行)的**判定半场**(store 写入半场留宿主)
-// 🔴 单实例纪律(B1 血泪同款):①带 11 个模块级台账(notifiedRunIds / cardEnqueuedRunIds /
-//   outstandingRuns / outstandingBgTasks / ownWorkflowRuns / bgNotifiedKeys / 两个 probe 槽 /
-//   listener 集 / watchTimer / tickInFlight)—— 写口(bridge 登记、probe 安装)与读口
-//   (footer outstanding 计数、fleet own 判别、去重)必须解析到**同一个包实例**。
-// 🔴 队列口(messageQueueManager)是宿主件:本包不 import 壳的队列,改成**注入 port**
-//   (设计稿原文「messageQueueManager 调用 ⇒ chrome 事件」的等价实现:先给最小注入口,
-//   chrome 事件化留给 B3 的 AdapterContext 扩容)。**未注入 = 通知投递静默丢失**,所以
-//   miss 有计数 + 一次性告警,绝不让它悄悄消失(a0110e88 零渲染案的教训:配对机制必须共享前提)。
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// cli src/constants/xml.ts 的四个 tag 常量(值逐字对齐;本包不引壳的 constants 桶)。
 const TASK_NOTIFICATION_TAG = 'task-notification';
 const TASK_ID_TAG = 'task-id';
 const STATUS_TAG = 'status';
@@ -208,23 +146,15 @@ const SUMMARY_TAG = 'summary';
 let queuePort = null;
 let queuePortMisses = 0;
 let queuePortWarned = false;
-/** 宿主装配:壳侧 shim / web 宿主在**模块加载期**装(装之前的调用会计入 miss)。 */
 export function installNotificationQueuePort(port) {
     queuePort = port;
 }
-/** 🔴 未注入队列口而发生的投递次数 —— 恒应为 0;>0 = 宿主装配漏了,通知已静默丢失。 */
 export function notificationQueuePortMisses() {
     return queuePortMisses;
 }
-/**
- * 本模块唯一的 SEMA_DEBUG 留痕出口(前缀逐字保持 `[sema][notif] `,与既有 drop 那行同形)。
- * 🔴 为什么要单口:C5「静默丢数据零容忍」的执行方式是**每条丢弃/放弃路径都能在同一个前缀下
- * grep 到**;散写 console.error 时新增的丢弃路径很容易漏掉留痕(notif-02/-03 就是这么漏的)。
- */
 function traceNotif(line) {
     if (!hostEnv().SEMA_DEBUG)
         return;
-    // eslint-disable-next-line no-console
     console.error(`[sema][notif] ${line}`);
 }
 function port() {
@@ -233,44 +163,20 @@ function port() {
     queuePortMisses++;
     if (!queuePortWarned) {
         queuePortWarned = true;
-        // eslint-disable-next-line no-console
         console.error('[client-core] notification queue port NOT installed — task-notification delivery is being dropped. ' +
             'Host must call installNotificationQueuePort() at startup (see notifications.ts B2 section).');
     }
     return null;
 }
-/** 测试钩:清 port + miss 计数(不动台账,台账各有自己的 reset)。 */
 export function _resetNotificationQueuePortForTest() {
     queuePort = null;
     queuePortMisses = 0;
     queuePortWarned = false;
 }
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// ① engineTaskNotification — engine-side background-run completion → CC `<task-notification>` injection.
-//
-// The service pushes a `workflow_complete` named SSE frame (service 1.75, `{runId, status, summary}` —
-// an explicit whitelist) onto the session's NEXT `/v1/tasks/stream` connection when a background
-// workflow it launched earlier finishes out-of-band. The shell turns that frame into CC's OWN
-// remote-task completion mechanism (the RemoteAgentTask `enqueueRemoteNotification` precedent,
-// CC 187 `Nco`): build the `<task-notification>` XML, enqueue it as a `task-notification` queued
-// command, and let CC's native drain / queue processor (idle → auto-submit) deliver it to the model.
-// No explicit priority — CC's RemoteAgentTask enqueues WITHOUT one, so the queue default ('later',
-// messageQueueManager: "so user input is never starved") applies; 'next' is the LocalShellTask/
-// MONITOR_TOOL precedent, not the remote-completion one (adversarial review w0zwpa251 §5).
-//
-// Dedup: CC marks the task registry entry `notified` — an engine workflow has no registry entry, so a
-// PROCESS-LIFETIME Set on runId does the same job (the service inbox is at-least-once; its enqueue is
-// runId-idempotent across restarts, this Set covers redelivery within one shell process).
-//
-// No `<output-file>` line: CC's output-file points at a LOCAL task output file (getTaskOutputPath);
-// an engine run has none — the SDK-exit regex reads tags independently, an absent tag is undefined
-// (the `<tool-use-id>` line is optional in CC's own template the same way).
-// ══════════════════════════════════════════════════════════════════════════════════════════════
 const notifiedRunIds = new Set();
 const notifiedBgCycleHigh = new Map();
 let ledgerOrder = 0;
 const nextLedgerOrder = () => ++ledgerOrder;
-/** 「已送达」两账的**唯一**写口(裸 id 维 + 周期维必须同时前进,否则收摊臂又回到没有周期证据)。 */
 function markRunNotified(runId, cycle = BG_FIRST_SEQ) {
     notifiedRunIds.add(runId);
     const prev = notifiedBgCycleHigh.get(runId);
@@ -278,31 +184,10 @@ function markRunNotified(runId, cycle = BG_FIRST_SEQ) {
         notifiedBgCycleHigh.set(runId, { cycle, order: nextLedgerOrder() });
     }
 }
-/** 「**这一个周期**已经送达过」——收摊臂唯一可用的删除证据。 */
 function notifiedBgCycleAtLeast(taskId, cycle) {
     const high = notifiedBgCycleHigh.get(taskId);
     return high !== undefined && high.cycle >= cycle ? high : undefined;
 }
-/**
- * B1(frame-lane-matrix 三节定谳)— Path A 回声到达时丢弃同 run 的 pending 队列条目。
- * 双投机理:活跃 turn 内 Path B(workflow_complete/bg_notification/probe feeder →
- * enqueuePendingNotification)先入队,Path A(引擎 server-side steer-inject 的
- * task_notification 回声帧)随流到达——引擎侧模型已收到一遍;turn 收口 idle 排水若再
- * auto-submit 队列条目 = 模型二收同一份 XML。壳撤不回引擎侧注入(跨进程),但能在
- * drain 前把已被回声证实送达的同 run 队列条目丢掉。键空间 = 裸 taskId/runId(与
- * notifiedRunIds/cardEnqueuedRunIds 同域);条目匹配按队列 XML 的 <task-id> 标签
- * (enqueue 两族与 bridge 渲染同用 escapeXml,键形字节对齐)。仅主线程 task-notification
- * 条目(agentId undefined);用户输入/其他模式绝不触碰。
- */
-/**
- * B7:plan_review 结局回植(`hitl/planReviewWire.ts` 的唯一调用点)。走队列口的
- * `enqueueMetaPrompt` 可选动词 —— 口或动词缺席 ⇒ 计 miss(与 `port()` 同一个计数器,宿主
- * 只看 `hostPortMisses()` 一个数)并**返回 false**,调用方 fail-soft。
- *
- * 🔴 为什么不复用 `enqueuePendingNotification`:那条走的是 `<task-notification>` 通道(队列
- * 的 `task-notification` 模式,drain 时按通知语义处理);plan_review 结局是一个 **isMeta 的
- * prompt turn**。混用 = 结局被当成后台任务完成通知渲染,是「看起来送到了」的假绑定。
- */
 export function enqueuePlanReviewOutcome(value) {
     const p = port();
     if (!p)
@@ -323,89 +208,35 @@ export function dropQueuedNotificationsForRun(taskId) {
         cmd.agentId === undefined &&
         typeof cmd.value === 'string' &&
         cmd.value.includes(needle));
-    // 🔴 a0110e88 零渲染案(clay 1.0.55 真机):删掉的条目正是 cardEnqueuedRunIds
-    // 记号所指的「会渲卡的队列条目」——条目死了记号还在,推送帧的渲染臂会按记号 break,两条渲染路
-    // 互相踢皮球 = UI 永远没有这条通知。删除成功必须同时交还卡所有权(清记号),让帧臂渲染。
-    // 模型面不受影响:core 文档化设计(task-notification.ts design/116 §7)保证 turn 边界 steer
-    // 注入,引擎侧单投成立;这里只救 UI 半场。
     if (dropped.length > 0) {
         cardEnqueuedRunIds.delete(taskId);
         traceNotif(`dropped ${dropped.length} queued task-notification(s) for ${taskId} — engine echo already delivered (B1); card ownership returned to the frame lane`);
     }
     return dropped.length;
 }
-/**
- * Pre-seed the runId dedup WITHOUT enqueueing — the completion already reached the model in-band
- * (clay 2026-07-04 复审:模型用 TaskOutput 轮询拿到 workflow 终态并当轮总结完;引擎 completion inbox
- * 不知道"轮询已送达",下一次开流仍补发 workflow_complete —— 对模型是纯重复,还触发一轮"这是补发通知,
- * 无需重复"的空转)。终态在 turn 内经过壳的投影(TaskOutput workflow 终态卡 / 引擎 server-side 已
- * steer-inject 的 task_notification 帧)即预标记,Channel A 对同 runId 的补发直接丢弃。
- */
 export function markEngineWorkflowNotified(runId) {
-    // [2393] F-1:外部 mark 只证「首周期已送达」(它没有周期号可带),周期维按首周期记 —— 与本函数
-    // 既有的跨通道语义逐字一致(enqueueBgChildNotification 的跨通道臂同样只对首周期成立)。
     markRunNotified(runId);
     if (outstandingRuns.delete(runId))
         notifyOutstanding();
 }
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// B5 ①(0.7.0)—— **配对台账折回**([1857];记忆 paired-mechanisms-must-share-premise)。
-// 0.6.0 把 `notifiedRuns` / `cardEnqueuedRuns` 放在**适配器实例**上,而与它们配对的另一半全在
-// 本模块的 module 台账上:清账的 `dropQueuedNotificationsForRun`、记账的
-// `enqueueBgChildNotification` / `enqueueEngineWorkflowNotification`、以及 idle watcher 那条
-// (壳根本拦不到的调用点)。两半前提不共享 = 四个方向同时错:
-//   ① module 记过账 ⇒ 实例不知道 ⇒ 推送帧渲第二张卡(双卡)
-//   ② 宿主回钩写实例、drop 清 module ⇒ 实例只增不减 ⇒ 那一行永不上屏(a0110e88 复发)
-//   ③④ 跨通道去重两向失效 ⇒ 同一完成二次喂模型
-// 修法 = 台账**整体**回到 module(与 cli 的 module 级 Set 逐字同域),适配器只经下面这四个口读写;
-// 实例上只留 `renderedNotifications`(渲染去重,天然 per-session)与 `firedSubagentStartHookTaskIds`
-// (DIVERGENCE-6 有意的实例级)。
-// 🔴 多 session 宿主(web 一个页面两个会话)上本对台账是**进程级共享**的 —— 这与 cli 一致,
-//   且必须如此:队列 port、idle watcher、outstanding 药丸也都是进程级的,台账单独 per-session
-//   就又造出一对「前提不共享」的机制。
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-/** 跨通道去重的**读**口(适配器 workflow_complete 臂的发射门;cli 同域)。 */
 export function isEngineWorkflowNotified(runId) {
     return notifiedRunIds.has(runId);
 }
-/** 「这个 run 的完成卡已入队」的**写**口(cli 侧等价物 = 两个 enqueue 函数内的 `cardEnqueuedRunIds.add`)。 */
 export function noteWorkflowCompletionCardEnqueued(runId) {
     if (runId.length > 0)
         cardEnqueuedRunIds.add(runId);
 }
-/** 台账序列化面(`exportLedger`)—— 只读快照,顺序 = 插入序。 */
 export function listNotifiedRuns() {
     return [...notifiedRunIds];
 }
 export function listWorkflowCompletionCardsEnqueued() {
     return [...cardEnqueuedRunIds];
 }
-/** 双通道「完成卡」去重(clay dogfood 2026-07-19 双通知案):与 notifiedRunIds(模型通知去重,
- *  external mark 也写它)**分键**——本集只由 probe 合成 enqueue 写入(workflow+bg agent 两族,
- *  对抗复审§1:bg 合成不写此集时 probe 先到→后到推送帧仍渲第二张卡)、只由推送帧渲染前读,
- *  故 external 先到的 mark 不会误吞后到的内部帧(dedup-lane 单测双向钉)。 */
 const cardEnqueuedRunIds = new Set();
 export function isWorkflowCompletionCardEnqueued(runId) {
     return cardEnqueuedRunIds.has(runId);
 }
-const outstandingRuns = new Map(); // runId → registeredAt(ms)
-// ── D4(212 对拍):outstanding 计数订阅面——REPL 空闲态渲「✻ Waiting for N dynamic
-// workflow(s) to finish」(CC 2.1.212 同形,wf-ui-cc2 ground truth)。仅通知计数变化 ——
-// notif-03 起「计数」含 `outstandingAbandonedCount()`,故 bg 半场的 TTL 放弃也发一次通知
-// (那一格变了,消费方要重渲「N 个后台任务已停止等待」)。
-//
-// 🔴 [2393] notif-F9(2026-08-03 全窗复审)**判据纠偏 + 契约写清**(裁定:机制不改,把口径写死)。
-// 复审的观察是「bg 半场信号不对称:放弃发通知、登记不发,而订阅面两个计数口都不含 bg ⇒ 一次 bg
-// 放弃叫醒全部订阅者却什么都没变(空转重渲)」。逐口核过之后这条**不成立**,但它指出的真缺口
-// (契约没写清)是真的,所以写在这里:
-//   · 订阅契约 = 「**任一可读计数**发生变化」,可读计数恰好三个:`outstandingWorkflowCount()` /
-//     `outstandingDeliverableWorkflowCount()` / `outstandingAbandonedCount()`;
-//   · bg **放弃**必须发:它改变第三个(`abandonedCount++`)—— 不是空转;
-//   · bg **登记**必须不发:bg 在飞数**没有**可读口(刻意:headless 退出门只认 workflow 半场,
-//     见 `outstandingDeliverableWorkflowCount` 的头注),不改变任何可读量的事件不许叫醒订阅者
-//     (叫醒 = 每次 async_launched 回执触发一次全树重渲,而消费方一个字都读不到新东西)。
-//   ⇒ 「不对称」是这条契约的**正确后果**,不是漏。谁想给 bg 在飞数开一个可读口,必须同批让
-//     `registerOutstandingBgTask` 发通知(两半共享前提,[paired-mechanisms-must-share-premise])。
+const outstandingRuns = new Map();
 const outstandingListeners = new Set();
 function notifyOutstanding() {
     for (const l of [...outstandingListeners]) {
@@ -413,16 +244,12 @@ function notifyOutstanding() {
             l();
         }
         catch {
-            /* 订阅方异常不拖累通知链 */
         }
     }
 }
 export function outstandingWorkflowCount() {
     return outstandingRuns.size;
 }
-/** headless(-p)退出门用([1340] BGB 分化案):**可送达**的 outstanding 数——probe 未装
- *  (mock/离线)恒 0,print 驱动器不为永远等不到的通知悬置;probe 在装则 watcher 5s 节拍
- *  必然送达或 TTL 放弃(2h 上界=run 蒸发极端形,与 CC 等本地 bg 任务的无界形同族)。 */
 export function outstandingDeliverableWorkflowCount() {
     return statusProbe ? outstandingRuns.size : 0;
 }
@@ -433,10 +260,6 @@ export function subscribeOutstandingWorkflows(listener) {
     };
 }
 let abandonedCount = 0;
-/**
- * 🔴 放弃观察的**唯一出口**。`id` 是各自台账的键(bg 侧 = `taskId:seq` 复合键,留痕里可直读)。
- * 未命中(键已不在台账)⇒ 不计数、不留痕:放弃必须是**真发生过**的事,别把「本来就没有」算成放弃。
- */
 function abandonOutstanding(kind, id, reason) {
     const removed = kind === 'bg-task' ? outstandingBgTasks.delete(id) : outstandingRuns.delete(id);
     if (!removed)
@@ -445,24 +268,8 @@ function abandonOutstanding(kind, id, reason) {
     const line = `abandoned ${kind} ${id} — reason=${reason}, waited > WATCH_TTL_MS(${WATCH_TTL_MS}ms); ` +
         'no completion notification will ever be delivered for it';
     traceNotif(line);
-    // 🔴 [2393] notif-F2(2026-08-03 全窗复审)**边界定谳**:本条修复到库边界为止,用户可见那一端
-    // 由宿主闭合,已挂提货单(`docs/refactor/README.md`「提货单 / 破坏性变更清单」节的**宿主侧待办**表,
-    // 背景与「库侧为什么停在这里」见 `docs/refactor/WAVE2-RESIDUALS.md` [2393] 那一节第 2 条)。
-    // 为什么不在库内补偿:
-    //   · `traceNotif` 受 SEMA_DEBUG 门控是**刻意**的 —— 那是诊断面;把放弃行为默认打进用户 stderr
-    //     等于库替宿主决定 UI(headless `-p` 的 stdout 是协议面,污染它是真回归);
-    //   · 走 `hostLog` 口需要 `notifications.ts` import `host.ts`,实测会把 **A 层闭包 22→24 文件**
-    //     (`run-client-core-portability-test.mjs` 的 `MAX_ADAPT_CLOSURE_FILES` 只许降)—— 为一条诊断
-    //     线把 A 层拽进宿主口体系,代价大于收益([no-hasty-compensation-final-fix-first] 三问);
-    //   · 用户可见那一端的**量**已经在场且可读:`outstandingAbandonedCount()`(+ `notificationDropCounters()`
-    //     六格)。缺的是三端的渲染,那是宿主工单,不是库内补偿位。
     notifyOutstanding();
 }
-/**
- * 🔴 已**停止等待**的 outstanding 条目数(workflow + bg 合计,process-lifetime 只增)。
- * 消费方(footer / headless 退出前的收尾行)据此把「N 个后台任务已停止等待」与「都送达了」
- * 分开渲——H1:排队与放弃对消费方必须可分辨。additive:既有计数口的语义一字节不变。
- */
 export function outstandingAbandonedCount() {
     return abandonedCount;
 }
@@ -485,74 +292,33 @@ export function notificationDropCounters() {
 let statusProbe = null;
 let watchTimer = null;
 const WATCH_INTERVAL_MS = 5000;
-const WATCH_TTL_MS = 2 * 60 * 60 * 1000; // 2h 兜底放弃(run 蒸发/owner 不可读时不永轮)
-/** liveClient 在构造会话 client 时注册(带正确 baseUrl/token/principal 的 workflows.get)。 */
+const WATCH_TTL_MS = 2 * 60 * 60 * 1000;
 export function installWorkflowStatusProbe(probe) {
     statusProbe = probe;
 }
-/** bg 子代生命周期号的首周期值(SendMessage 复活即 +1;wire 缺 seq ⇒ 按首周期解释)。 */
 const BG_FIRST_SEQ = 1;
-/**
- * 🔴 [2393] notif-F8(2026-08-03 全窗复审):seq 归一的**唯一铸点**。
- * 修前有两处各写各的:登记口 `Number.isFinite && >= BG_FIRST_SEQ` 才收(否则钳到首周期,再 floor),
- * enqueue 口只有 `n.seq ?? BG_FIRST_SEQ`(零校验),而帧臂(`fleet/fleetLedger.ts` 的
- * `applyBgNotification`)是**原样透传**。后果不是「多写一遍」而是两条通道的去重键会**错开**:
- * server 哪天发 0 基 seq(或小数)⇒ watcher 合成走已钳成 1 的键 `id:1:status`,帧通道走原值键
- * `id:0:status`,两键不撞 ⇒ 跨通道去重整体失效,同一次完成被喂给模型两遍。
- * notif-02 立的是「键必须含 seq」,归一没收成单口就等于键的**语义**没收口。
- */
 function normalizeBgSeq(seq) {
     return typeof seq === 'number' && Number.isFinite(seq) && seq >= BG_FIRST_SEQ ? Math.floor(seq) : BG_FIRST_SEQ;
 }
-/**
- * 🔴 notif-02:观察台账的键是 **(taskId, seq) 复合键**,不是裸 taskId。
- * 裸 taskId 时 seq≥2 的复活周期与首周期同键 ⇒ 复活周期结构性进不了台账,而 watcher 存在的
- * 全部理由就是「bg 完成通知 idle 期没有到达通道」—— 复活周期因此退回那条已判定不可靠的推送通道。
- */
 function bgOutstandingKey(taskId, seq) {
     return `${taskId}:${seq}`;
 }
 const outstandingBgTasks = new Map();
 let bgStatusProbe = null;
-/**
- * R4(clay 五报 07-31)委派 prompt 台账:`async_launched` 回执带全 {task_id, description, prompt}
- * 三件,但此前 prompt 只进消息 payload(ctrl+o expand 那条腿),任务行/详情页(↓ manage)取不到,
- * 只能绕道等引擎 running 期不发的 transcriptId 去转录读面捞 ⇒ Prompt 节恒空。
- * 这里按行 id 记一份(与 fleet 行 rowIdTail 同 keyspace),行消费端建行时取用。
- * 与 outstandingBgTasks 分开存:后者随通知摘除,prompt 在行的整个生命周期都要可取。
- * process-lifetime 有界:bg 子代数量 = 人手派发量级,不设逐出。
- */
 const bgTaskPrompts = new Map();
-/** 委派 prompt 取件口(行消费端建行/详情页兜底用)。未登记 ⇒ undefined(诚实缺席)。 */
 export function outstandingBgTaskPrompt(taskId) {
     return bgTaskPrompts.get(taskId);
 }
 export function installBgTaskStatusProbe(probe) {
     bgStatusProbe = probe;
 }
-/**
- * bridge 在 Agent async_launched 回执(structured type:'agent')经过时登记。按 (taskId,seq) 幂等。
- *
- * 🔴 notif-02(两账分离):登记闸**不再查 `notifiedRunIds`**。那个集合是「模型通知去重」账
- * (哪次完成已经喂给模型了),不是「是否还要观察」账;两账混用的后果是 seq≥2 的复活周期
- * 永远登记不进来(`notifiedRunIds` 全文无 delete 站点,首周期一通知就是终身黑名单)。
- * 首周期若确已送达,由 watcher 的收摊臂在下一拍摘除(见 `tickWatchInner` bg 半场),
- * 代价是一次 no-op 遍历,而不是一整个完成周期的结构性缺席。
- *
- * 🔴 [2393] F-1:`seq` 缺席时这里仍然**按首周期解释,不在登记口猜周期号** —— 猜出来的周期号会
- * 把「已终局任务的回执重放」也升成新周期,方向相反地造出重复通知。周期号只在 watcher 那侧、
- * 拿到 probe 的「它又在跑」这个证据之后才前进(见 `tickWatchInner` 的收摊臂三档)。
- *
- * @param seq bg 子代生命周期号;wire 未带 ⇒ 按首周期(BG_FIRST_SEQ)解释,复活周期由 watcher 补。
- */
 export function registerOutstandingBgTask(taskId, description, prompt, seq) {
     if (!taskId)
         return;
-    // prompt 台账先记(与 watcher 登记的幂等早退解耦:重复回执/已通知任务的 prompt 仍要可取)。
     if (typeof prompt === 'string' && prompt.length > 0 && !bgTaskPrompts.has(taskId)) {
         bgTaskPrompts.set(taskId, prompt);
     }
-    const cycle = normalizeBgSeq(seq); // notif-F8:唯一铸点
+    const cycle = normalizeBgSeq(seq);
     const key = bgOutstandingKey(taskId, cycle);
     if (outstandingBgTasks.has(key))
         return;
@@ -565,36 +331,22 @@ export function registerOutstandingBgTask(taskId, description, prompt, seq) {
     });
     ensureWatchTimer();
 }
-/** 本壳亲手启动过的 workflow run(process-lifetime,只增不摘——outstandingRuns 会随完成摘除,
- *  这个集合是 fleet 行渲染的 own 判别台账;clay 2026-07-23 双 session 串扰案:旧代际引擎对
- *  fleet 行帧广播,workflow 行必须有壳侧行级判别兜底,与 bg_notification 的 isOwnEngineRun
- *  台账对称)。诚实边界同款:壳重启/resume 后旧 workflow 行在老引擎下会被藏(1.244+ server
- *  已按会话过滤=sessionScoped 让位,不受此限)。 */
 const ownWorkflowRuns = new Set();
 export function isOwnWorkflowRun(runId) {
     return ownWorkflowRuns.has(runId);
 }
-/** 本壳亲手启动过的 workflow run 列表(Set 插入序 = 启动序;/workflows 命令的目标 run 选择用,
- *  cmd-workflows.tsx——fleet source 无行可选时的兜底 id 源)。 */
 export function listOwnWorkflowRuns() {
     return [...ownWorkflowRuns];
 }
-/**
- * CC-37(0.72.2,cli [7468] ②):只登 own 台账、不动 outstanding —— 给 adapter 的 workflow lane 门用:带 `workflowRunId`
- * 的 `task_progress` 帧**且**其父指向本会话见过的 Workflow 工具卡(own-run 正向证明)时,在为其铸行的那一拍就登记,
- * 不再等 run_workflow 回执;此前 fleet 行已渲 13 s 而 `listOwnWorkflowRuns()` 仍空。幂等;别的会话的 workflow 帧
- * (无本会话卡为父)**不登**。
- */
 export function noteOwnWorkflowRun(runId) {
     if (!runId)
         return;
     ownWorkflowRuns.add(runId);
 }
-/** bridge 在 run_workflow 回执(structured type:'workflow-run')经过时登记。幂等;已通知的不再登记。 */
 export function registerOutstandingWorkflowRun(runId) {
     if (!runId)
         return;
-    ownWorkflowRuns.add(runId); // own 台账先记(与 outstanding 摘除解耦)
+    ownWorkflowRuns.add(runId);
     if (notifiedRunIds.has(runId) || outstandingRuns.has(runId))
         return;
     outstandingRuns.set(runId, Date.now());
@@ -605,46 +357,18 @@ function ensureWatchTimer() {
     if (watchTimer !== null)
         return;
     watchTimer = setInterval(() => {
-        // 定时器回调不能 await:tick 的失败必须在这里落地,否则变成 unhandledRejection 打死宿主进程。
         tickWatch().catch(err => {
             traceNotif(`watcher tick threw: ${err instanceof Error ? err.message : String(err)}`);
         });
     }, WATCH_INTERVAL_MS);
-    // 不阻止进程退出(域词表-14:unrefTimer 单一实现)
     unrefTimer(watchTimer);
 }
-// ── notif-01(D4 必有 settle 路径 + A5 界不得来自第三方默认值)────────────────────────────────
-// 病形:重入护栏是**不带超时的单飞**,而 tickWatchInner 里两个 `await probe(...)` 没有任何
-// deadline —— probe 由宿主注入,今天两处实装都只是 `await client.runs/workflows.get(...)`,
-// 界完全外包给了宿主的 HTTP 栈。probe 的 promise 若不 settle:护栏永久为真 ⇒ 此后每拍早退 ⇒
-// **住在 tick 里的 TTL 清扫也一并失效** ⇒ outstanding 永不清空 ⇒ watchTimer 永不停 ⇒
-// `outstandingDeliverableWorkflowCount()` 恒 >0 ⇒ headless(-p)的退出门恒真、进程永不退出。
-// 修法三件(缺一条链就还在):①每个 probe await 包 deadline;②护栏改时间戳 + 强制复位;
-// ③TTL 清扫提到护栏**之前**,让「探测卡死」不连坐「超时放弃」。
-/**
- * 单次探测的截止。取值理由:节拍是 WATCH_INTERVAL_MS(5s),本值 = **2 个节拍**——
- *   · 下界:比一个节拍大,慢但活着的 probe(一次往返略超 5s)不会被切成「必失败」;
- *   · 上界:小整数倍,单个条目最坏只压住 2 拍,而不是把整条链交给宿主 HTTP 栈的默认值。
- */
 const PROBE_TIMEOUT_MS = 2 * WATCH_INTERVAL_MS;
-/**
- * 在飞 tick 的强制复位门。取值理由:一拍最坏耗时 ≈ 条目数 × PROBE_TIMEOUT_MS,故门必须显著
- * 大于单条截止,否则条目一多就会误判卡死。6 倍截止 = 一拍里有 3 个条目全部吃满超时仍不算卡死。
- * ⚠️ 复位**不能**中止那个已在飞的 tick(probe promise 不在我们手里),只是允许下一拍照常起 ——
- * 代价是短时间内可能有两拍并发探测同一条目;相对「进程永不退出」这是明确划算的取舍,
- * 且 `stuckTickResets` 恒应为 0,>0 说明有 probe 连 deadline 都截不住,是要查的账。
- */
 const STUCK_TICK_RESET_MS = 6 * PROBE_TIMEOUT_MS;
-/** 测试可覆写的时序(仅测试钩写;生产恒 null ⇒ 用上面两个常量)。 */
 let probeTimeoutOverrideMs = null;
 let stuckTickResetOverrideMs = null;
 const probeTimeoutMs = () => probeTimeoutOverrideMs ?? PROBE_TIMEOUT_MS;
 const stuckTickResetMs = () => stuckTickResetOverrideMs ?? STUCK_TICK_RESET_MS;
-/**
- * probe 超时的**类型化**错误(错误判别一律 instanceof,禁按文案前缀判)。
- * 不导出:它只在本模块的 catch 臂之间流动,宿主注入的 probe 永远看不到它 —— 公面每多一个名字
- * 就是多一条对外承诺,没有消费者的错误类别不该上公面(要用时再导出并同批更新导出基线)。
- */
 class ProbeDeadlineError extends Error {
     timeoutMs;
     constructor(timeoutMs) {
@@ -653,24 +377,11 @@ class ProbeDeadlineError extends Error {
         this.timeoutMs = timeoutMs;
     }
 }
-/**
- * 给一个不受我们控制的 promise 加一道**本仓自己声明**的界(A5)。超时 ⇒ reject
- * `ProbeDeadlineError`,落进调用方既有的「单次探测失败」catch 臂,TTL 继续兜底。
- * 计时器 unref(存在则),绝不因为一次探测把宿主进程钉住。
- */
 function withProbeDeadline(p, timeoutMs) {
     return new Promise((resolve, reject) => {
         const timer = setTimeout(() => {
             reject(new ProbeDeadlineError(timeoutMs));
         }, timeoutMs);
-        // 🔴 [2393] notif-F7(2026-08-03 全窗复审)**不 unref**:这正是 `unrefTimer.ts:6-9` 逐字写死的
-        // 域词表-13 定谳所指的那一类 —— 「被 await 的 race/budget 臂上的定时器绝不能 unref(会让进程
-        // 在它 settle 前提前退出,RB-447 同形)」。本 deadline 定时器是 `await withProbeDeadline(...)`
-        // **唯一的 settle 来源**(probe 永不 settle 时):unref 之后若宿主此刻没有别的活句柄
-        // (watchTimer 自己也是 unref 的),事件循环判定可退出,回调不再执行,那一拍 tick 永不 settle
-        // —— notif-01① 「必有 settle 路径」的保证就不是自持的,而是押在「宿主别处总有活句柄」上。
-        // 两条成对臂已经保证它不会拖住进程:①probe settle 时下面两个 `clearTimeout(timer)` 必执行;
-        // ②它自己到点就 reject 并被 clear,寿命上界 = timeoutMs(默认 PROBE_TIMEOUT_MS)。
         p.then(v => {
             clearTimeout(timer);
             resolve(v);
@@ -680,34 +391,10 @@ function withProbeDeadline(p, timeoutMs) {
         });
     });
 }
-// 重入护栏(对抗复审§5):慢 probe(>5s)时多个 tick 并发走同一 outstanding 快照=同任务
-// 重复探测×N。单飞:在飞即跳过本 tick,下个节拍自然补上。
-// 🔴 布尔改**起始时间戳**(notif-01②):布尔形没有任何复位路径能对付「await 永不返回」。
 let tickStartedAtMs = null;
-/** 在飞 tick 的世代号:强制复位后旧 tick 收口时不许清掉**新** tick 的时间戳。 */
 let tickGeneration = 0;
-/**
- * TTL 清扫(notif-03 的单口收敛 + notif-01③ 的位置修正)。
- * 🔴 必须在重入护栏**之前**跑:清扫住在 tickWatchInner 里时,一个卡死的 probe 会连坐 TTL,
- * 于是「2h 上界」这个 `outstandingDeliverableWorkflowCount()` 正当性的另一半也一起失效。
- */
-/**
- * 🔴 [2393] notif-F10(2026-08-03 全窗复审):**正被在飞 probe 臂持有**的键集(bg 侧存复合键,
- * workflow 侧存 runId)。`abandonOutstanding` 自己的前提是「放弃必须是**真发生过**的事」,但它
- * 上一版只挡住了「键不在台账」,没挡住「键正被在飞臂持有」:上一拍 probe 还在飞(它手里握着这
- * 条目的快照),这一拍 sweep 判它超 TTL ⇒ 计数 +1 并打出「no completion notification will ever
- * be delivered for it」,几十毫秒后那个 probe 返回 terminal ⇒ 照常合成并投递通知。
- * 留痕是假话,`outstandingAbandonedCount()`(消费方据以渲「N 个后台任务已停止等待」的诚实计数)
- * 被灌一格假数 —— 正是 notif-03 立案要根治的那一类观测面撒谎。
- * 🔴 让位必须**自己有界**,否则它就变成 notif-01③ 刚修掉的那个形(「清扫住在 tick 体内 ⇒ 一个卡死的
- * probe 连坐 TTL ⇒ headless 退出门恒真、进程永不退出」)。所以记的是**在飞臂的起始时刻**,
- * 让位只在「这条臂还没超过它自己的 deadline」时成立:臂一旦活过 `probeTimeoutMs()`(= 它本该被
- * 截断的时刻),它就不再是「马上会给出答案的那条臂」,TTL 照常执行。
- * ⇒ 正常路径:多等一拍(5s),换来放弃计数不被灌假数;病理路径:与修前逐字同形,liveness 不变。
- */
 const bgProbeInFlight = new Map();
 const runProbeInFlight = new Map();
-/** 在飞臂是否仍在它自己的 deadline 之内(超了就不再让位 —— 见上方 notif-F10 头注)。 */
 function probeArmStillWithinDeadline(startedAt, now) {
     return startedAt !== undefined && now - startedAt <= probeTimeoutMs();
 }
@@ -716,8 +403,6 @@ function sweepExpiredOutstanding(now) {
         if (now - meta.registeredAt <= WATCH_TTL_MS)
             continue;
         if (probeArmStillWithinDeadline(bgProbeInFlight.get(key), now)) {
-            // notif-F10:在飞臂正握着它、且还没超它自己的 deadline —— 这一拍不判放弃
-            // (判了就可能马上被那条臂证伪:计数与留痕当场成假话)。
             traceNotif(`ttl sweep deferred for bg-task ${key}: a probe arm is still in flight within its deadline`);
             continue;
         }
@@ -733,7 +418,6 @@ function sweepExpiredOutstanding(now) {
         abandonOutstanding('workflow-run', runId, 'ttl');
     }
 }
-/** @param nowMs 时钟注入(仅测试钩用;生产走 Date.now())。 */
 async function tickWatch(nowMs) {
     const now = nowMs ?? Date.now();
     sweepExpiredOutstanding(now);
@@ -757,36 +441,17 @@ async function tickWatch(nowMs) {
         await tickWatchInner(now);
     }
     finally {
-        // 被强制复位过就别清:那面时间戳已经属于后来的那一拍了。
         if (tickGeneration === myGeneration)
             tickStartedAtMs = null;
     }
 }
-/** @param now 本拍的时钟(与 `sweepExpiredOutstanding` **同一个来源** —— notif-F10 的让位判据比的是
- *  「在飞臂活了多久 vs 它自己的 deadline」,两边取不同的钟就会得出 3 小时前起飞的荒谬结论)。 */
 async function tickWatchInner(now) {
-    // bg agent 半场(与 workflow 半场同节拍;TTL 已提到 tickWatch 的护栏之前统一清扫。
-    // probe 未装=mock/离线,只等推送补发)
     const bgProbe = bgStatusProbe;
     for (const [key, meta] of [...outstandingBgTasks]) {
-        // 🔴 [2393] F-1:收摊臂的删除必须**挣得**。此前的判据是裸 taskId 黑名单
-        // (`meta.seq <= BG_FIRST_SEQ && notifiedRunIds.has(meta.taskId)`),它只证明「这个 id 曾经
-        // 送达过某次完成」;而 `structured.seq` 缺席时复活周期的 cycle 塌回首周期,于是这条臂拿
-        // **首周期的送达记录**把**第二周期**的观察条目在下一拍秒删,probe 一次不跑 —— 与 notif-02
-        // 修前的静默丢通知逐字相同,且删在 enqueue 之前 ⇒ 三个既有计数器一格都摸不到。
-        // 新判据分三档,每一档都拿得出理由:
-        //   ① 这一周期确已送达(周期键台账)⇒ 才谈得上收摊;
-        //   ①a 条目**登记在那次送达之前** ⇒ 它就是那次送达自己的观察条目,无歧义,零成本收摊
-        //       (= 旧行为的正当那一半,常态路径,不多花一次探测);
-        //   ①b 条目**登记在送达之后** ⇒ 有歧义:复活周期?还是已终局任务的回执重放?靠 probe 定夺:
-        //   ② probe 说它**真终局** ⇒ 就是那个已送达的周期,收摊(重放回执落这里,不会二次喂模型);
-        //   ③ probe 说它**又在跑** ⇒ 这按构造是一个**新的完成周期**(裸 id 黑名单对它零判别力),
-        //      把条目升到下一个周期号继续观察,并留痕。probe 未装 ⇒ 没有可挣得的证据,沿用旧的盲摘
-        //      但记账;probe 失败/答不上来 ⇒ 不删也不升(TTL 兜底),绝不拿探测失败当终局证据。
         const delivered = notifiedBgCycleAtLeast(meta.taskId, meta.seq);
         if (delivered !== undefined) {
             if (meta.registeredOrder < delivered.order) {
-                outstandingBgTasks.delete(key); // ①a 推送/别的通道已送达本条目观察的那个周期 — 收摊
+                outstandingBgTasks.delete(key);
                 continue;
             }
             if (!bgProbe) {
@@ -795,21 +460,21 @@ async function tickWatchInner(now) {
                 continue;
             }
             let alive;
-            bgProbeInFlight.set(key, now); // notif-F10:在飞期间(且未超 deadline)sweep 不许把它判成「放弃」
+            bgProbeInFlight.set(key, now);
             try {
                 const res = await withProbeDeadline(bgProbe(meta.taskId), probeTimeoutMs());
                 if (res === null || res === undefined)
-                    continue; // 答不上来 ≠ 终局,留给下一拍/TTL
+                    continue;
                 alive = !res.terminal;
             }
             catch {
-                continue; // 探测失败(含 ProbeDeadlineError)不构成删除证据
+                continue;
             }
             finally {
                 bgProbeInFlight.delete(key);
             }
             if (!alive) {
-                outstandingBgTasks.delete(key); // 真终局 = 已送达的那个周期,收摊
+                outstandingBgTasks.delete(key);
                 continue;
             }
             const promoted = Math.max(meta.seq, delivered.cycle) + 1;
@@ -826,15 +491,13 @@ async function tickWatchInner(now) {
         }
         if (!bgProbe)
             continue;
-        bgProbeInFlight.set(key, now); // notif-F10:同上 —— 在飞臂持有期间(未超 deadline)TTL 让位
+        bgProbeInFlight.set(key, now);
         try {
             const res = await withProbeDeadline(bgProbe(meta.taskId), probeTimeoutMs());
             if (res?.terminal) {
                 outstandingBgTasks.delete(key);
                 enqueueBgChildNotification({
                     taskId: meta.taskId,
-                    // 🔴 seq 必须透传:不带 seq 时键退化成 `taskId:1:status`,与首周期键碰撞 ⇒ 被去重臂
-                    // 静默吞掉,而台账条目已经先删了 ⇒ 该完成**永久丢失**(clay 图2 案在 watcher 车道的复刻)。
                     seq: meta.seq,
                     status: res.status,
                     summary: `Background agent "${meta.description}" ${res.status}`,
@@ -842,7 +505,6 @@ async function tickWatchInner(now) {
             }
         }
         catch {
-            // 单次探测失败(含 ProbeDeadlineError 截断)不放弃:网络抖动照旧,TTL 兜底
         }
         finally {
             bgProbeInFlight.delete(key);
@@ -852,12 +514,12 @@ async function tickWatchInner(now) {
     for (const runId of [...outstandingRuns.keys()]) {
         if (notifiedRunIds.has(runId)) {
             if (outstandingRuns.delete(runId))
-                notifyOutstanding(); // 推送/终态轮询卡已送达 —— 收摊
+                notifyOutstanding();
             continue;
         }
         if (!probe)
-            continue; // live client 未装(mock/离线)→ 只等推送
-        runProbeInFlight.set(runId, now); // notif-F10:在飞期间(且未超 deadline)sweep 不许把它判成「放弃」
+            continue;
+        runProbeInFlight.set(runId, now);
         try {
             const res = await withProbeDeadline(probe(runId), probeTimeoutMs());
             if (res?.terminal) {
@@ -871,74 +533,43 @@ async function tickWatchInner(now) {
             }
         }
         catch {
-            // 单次探测失败(含 ProbeDeadlineError 截断)不放弃:网络抖动照旧,TTL 兜底
         }
         finally {
             runProbeInFlight.delete(runId);
         }
     }
 }
-/**
- * bg_notification 帧桥([446] 帧契约,service 1.119 上线):session 级后台子代的
- * 完成/终态通知走常开 fleet lane → 这里转入 #21 的 pending-notification 注入链
- * (idle 自动注入,彻底关掉「bg 完成通知等下次输入才 drain」的死窗)。
- * (taskId,status) 去重=外圈皮带(durable park 腿重放/at-least-once 双投自免)。
- */
 const bgNotifiedKeys = new Set();
 export function enqueueBgChildNotification(n) {
-    const cycle = normalizeBgSeq(n.seq); // notif-F8:与登记口同一个铸点(零校验的 `?? 1` 会让两条通道的键错开)
+    const cycle = normalizeBgSeq(n.seq);
     const key = `${n.taskId}:${cycle}:${n.status}`;
-    // 🔴 notif-03 同族(C5):两条静默 return 都记账 + 留痕 —— 不记账时「按设计去重」与
-    // 「seq 丢了导致完成被吞」在观测上完全等价,而后者是用户永远收不到通知的那一类。
     if (bgNotifiedKeys.has(key)) {
         bgDedupDropped++;
         traceNotif(`bg notification suppressed (same key already delivered) key=${key}`);
         return;
     }
-    // cross-channel 去重(clay 2026-07-06 截图疑似双唤醒定谳):同一完成可能同时走
-    // workflow_complete/probe 链(notifiedRunIds 键空间)与 bg_notification 帧——两空间互认,
-    // 任一链注入过即跳过,并反向 seed。仅首周期查(revive 周期是新完成,probe 链只报首周期
-    // 终态,不构成双投)。
     if (cycle <= BG_FIRST_SEQ && notifiedRunIds.has(n.taskId)) {
         bgCrossChannelDropped++;
         traceNotif(`bg notification suppressed (cross-channel: run already notified) taskId=${n.taskId} seq=${cycle} status=${n.status}`);
         return;
     }
     bgNotifiedKeys.add(key);
-    // 🔴 完成三本账(完成去重 / 周期 / 完成卡)与面板 settle **只认通知自己的终态词**(completed / failed / killed / cancelled)。
-    //    非终态(running / queued / event / unknown / 未来词)只过上面那本**逐条**去重账:它若占了完成账,同一任务随后的
-    //    真终态会被跨通道去重吞掉 ⇒ 零 end、常驻标永不摘(异源对抗复审)。
     const terminal = isTaskNotificationTerminalStatus(n.status);
     if (terminal) {
-        // [2393] F-1:周期维必须跟着前进 —— 收摊臂删条目的唯一证据就是这一格。
         markRunNotified(n.taskId, cycle);
         cardEnqueuedRunIds.add(n.taskId);
     }
-    // #6 通知-settle 边(合成半场):bg 子代行不再被 turn sweep 假结(session 常驻台账),真终态
-    // 唯二来源 = 推送帧(bridge task_notification 臂)与本合成链(probe/fleet bg_notification 收敛点)。
-    // 消费端 settle 幂等(running 才动),推送帧先到时此发布为 no-op。
     if (terminal) {
         try {
-            // 0.72.13(test 0.72.12 验收 ①;DS-06 同形存量):只对**通知自己的终态词**(completed / failed / killed / cancelled)settle 面板行。
-            // 此前对任何 status 都铸 `end`,而 `isError: isTerminalNotSuccess(status)` 对 running / queued / event / 未来词答 false ⇒
-            // 面板把一条还在跑 / 认不出状态的行结成 **completed** —— 该谓词的 JSDoc 明禁拿它的 false 当成功。非终态 ⇒ 不 settle、常驻标不摘。
-            // 0.74.4 CC-83:按 wire 词清 —— 尾段若归先发布的 UUID 所有,那把键下的常驻标一起清(主通道与常驻账同一把键)
             clearEnginePanelTaskResidentByWire(n.taskId, typeof n.seq === 'number' && Number.isInteger(n.seq) && n.seq >= BG_FIRST_SEQ ? { cycleSeq: n.seq } : undefined);
             publishEngineAgentPanelEvent({
                 kind: 'end',
                 taskId: n.taskId,
-                // L-215②(0.65.0):读**单铸谓词**而不是内联两词 —— 修前这里只认 `failed`/`killed`,
-                //    而 core [6908] 的 `blocked` 是 **agent 自报的终态**(不是等人)⇒ 一条自报走不下去的
-                //    后台 run 在面板上被 settle 成**成功**。🔴 `suspended`/`needs_review` 仍不在表里
-                //    (那两词是「等一次人的决定」,判成终局会把一条正等着你的 run 在面板上判死)。
                 isError: isTerminalNotSuccess(n.status),
-                // 0.74.0:周期身份 —— **wire 真给了 seq 才带**。上面的 `cycle` 是去重键用的归一值(缺席归一成首周期),
-                // 那是键不是事实;把它上屏等于对一条没报代际的通知声称「这是第一代」。
                 ...(typeof n.seq === 'number' && Number.isInteger(n.seq) && n.seq >= BG_FIRST_SEQ ? { cycleSeq: n.seq } : {}),
             });
         }
         catch {
-            /* fail-soft — 面板 settle 失败绝不挡模型通知注入 */
         }
     }
     const message = `<${TASK_NOTIFICATION_TAG}>
@@ -952,18 +583,11 @@ export function enqueueBgChildNotification(n) {
     });
 }
 export function enqueueEngineWorkflowNotification(c) {
-    // 🔴 [2393] notif-F1(2026-08-03 全窗复审):这条静默 return 是 C5 收口的**第三处漏网拼法**。
-    // 同批把 bg 侧两条静默 return 都补了计数+留痕(上面 bgDedupDropped / bgCrossChannelDropped),
-    // 而它的孪生体 workflow 侧一条都没有 —— 而 `traceNotif` 的头注把执行标准写成「每条丢弃/放弃
-    // 路径都能在同一个前缀下 grep 到」。失败场景:`markEngineWorkflowNotified()`(外部通道 seed)
-    // 或 probe 链先记账后,推送帧再送同一 runId 的完成 ⇒ 这里静默吞掉,而「按设计去重」与
-    // 「一条真完成被误吞(runId 铸法变了 / 两条链 id 不同域)」在观测面上完全等价。
     if (notifiedRunIds.has(c.runId)) {
         workflowDedupDropped++;
         traceNotif(`workflow notification suppressed (run already notified) runId=${c.runId} status=${c.status}`);
         return;
     }
-    // [2393] F-1:workflow 侧没有周期概念,周期维按首周期记(与 markEngineWorkflowNotified 同理)。
     markRunNotified(c.runId);
     cardEnqueuedRunIds.add(c.runId);
     const message = `<${TASK_NOTIFICATION_TAG}>
@@ -976,8 +600,6 @@ export function enqueueEngineWorkflowNotification(c) {
         mode: 'task-notification',
     });
 }
-/** 测试钩(B2 新增,壳侧原文件没有):清空全部通知台账 + probe 槽 + watcher。
- *  🔴 生产绝不调用 —— 台账是 process-lifetime 去重的唯一凭据,清了就会双投。 */
 export function _resetEngineTaskNotificationForTest() {
     notifiedRunIds.clear();
     notifiedBgCycleHigh.clear();
@@ -987,15 +609,6 @@ export function _resetEngineTaskNotificationForTest() {
     ownWorkflowRuns.clear();
     bgNotifiedKeys.clear();
     outstandingListeners.clear();
-    // 🔴 [2393] notif-F11(2026-08-03 全窗复审):这三件此前漏清 —— 头注自称「清空**全部**通知台账」。
-    //   · `bgTaskPrompts`:首值粘性(已登记的 taskId 不覆写),门里两个用例复用同一 taskId 时
-    //     `outstandingBgTaskPrompt()` 会跨用例返回上一用例的 prompt,reset 拿不掉(既有钉侥幸没撞上,
-    //     不是被挡住了)。它的 process-lifetime 无逐出是**生产**决定(bg 子代 = 人手派发量级),
-    //     与测试钩要不要清是两件事。
-    //   · `tickGeneration`:世代号不复位,跨用例累加(今天只做相等比较,不是现症;但「清空全部」
-    //     这句话要么成立要么改掉,不留半真)。
-    //   · `bgProbeInFlight` / `runProbeInFlight`(notif-F10 新增):上一个用例的 probe 若被用例
-    //     提前收尾抛下,残留的键会让下一个用例的 TTL sweep 永远让位 = 静默失效的 TTL。
     bgTaskPrompts.clear();
     bgProbeInFlight.clear();
     runProbeInFlight.clear();
@@ -1017,52 +630,18 @@ export function _resetEngineTaskNotificationForTest() {
         watchTimer = null;
     }
 }
-/**
- * 测试钩:**驱动一拍** watcher(生产由 setInterval 驱动,外部无入口 ⇒ 护栏/TTL/deadline
- * 三条链在门里全不可达,notif-01/-02/-03 才会一路活到今天)。
- * @param nowMs TTL 判据的时钟注入(WATCH_TTL_MS 是 2h,不注入时钟就只能真等两小时)。
- * 🔴 生产绝不调用。
- */
 export async function _tickWatchOnceForTest(nowMs) {
     await tickWatch(nowMs);
 }
-/**
- * 测试钩:覆写 watcher 时序常量(默认是 10s/60s 量级,门里等不起)。传 null 恢复生产值。
- * 🔴 生产绝不调用;覆写只影响 deadline 与强制复位门,不动 WATCH_INTERVAL_MS/WATCH_TTL_MS。
- */
 export function _setWatcherTimingForTest(o) {
     probeTimeoutOverrideMs = o?.probeTimeoutMs ?? null;
     stuckTickResetOverrideMs = o?.stuckTickResetMs ?? null;
 }
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// ② taskNotificationErrorSupplement — S4-P3(clay 专项;取证 workflow-card-forensics,
-// 2026-07-24「workflow completed 卡下挂 API Error: 503 · draining」案):task-notification
-// 自动提交 turn 的 API-error 行 supplement。
-//
-// 场景:后台 workflow/bg agent 完成 → 完成通知入队自动提交新 turn(enqueueEngineWorkflowNotification/
-// enqueueBgChildNotification → queueProcessor idle 排水)→ 该 turn 的引擎提交失败(典型:撞温切排水的
-// 503 draining,S4-P0 有界重试打光)→ CC 转录形制里 assistant error 行恒以 ⎿ 臂贴在其 user 消息
-// (= 通知卡)正下方,用户误读为「后台任务本身失败」。这里生成一句 supplement 澄清:任务本身已终态,
-// 失败的只是「把结果通知投递给模型」这一轮;/tasks 可查结果。supplement, never mask
-// (detachWire/sandboxDegradeHint 同款姿势):原始 error 行原样保留,只追加一行。
-//
-// 判别:通知 turn 的 objective 就是合成的 `<task-notification>` XML 整体(queueProcessor 自动提交,
-// user 消息 origin kind 'task-notification')——以 trimStart() 后 startsWith 判型,用户手打正文里
-// 【提到】该 tag 不误伤。
-// 渲染:AssistantTextMessage 的 API-error 臂经 splitApiErrorSupplement 把本行拆出来渲 dim。
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-/** 所有 supplement 变体共享的行首 —— 渲染侧拆行锚(splitApiErrorSupplement),两侧必须同步改。 */
 const SUPPLEMENT_LINE_PREFIX = 'The background task itself ';
-/** 该 objective 是否为 task-notification 自动提交 turn 的注入 XML(整体即通知,非提及)。 */
 export function isTaskNotificationObjective(objective) {
     return (typeof objective === 'string' &&
         objective.trimStart().startsWith(`<${TASK_NOTIFICATION_TAG}>`));
 }
-/**
- * 通知 turn → supplement 文案(非通知 turn → undefined,判别不扩散)。措辞英文、CC 报错语气
- * (事实 + 出路,不惊悚)。status 从 XML `<status>` 读:completed 用定稿句;其余终态如实带
- * status(通知可能报 failed/killed —— 谎称 completed 比不加更糟)。
- */
 export function taskNotificationDeliverySupplement(objective) {
     if (!isTaskNotificationObjective(objective))
         return undefined;
@@ -1072,20 +651,11 @@ export function taskNotificationDeliverySupplement(objective) {
         return `${SUPPLEMENT_LINE_PREFIX}completed — only this notification delivery failed. Check /tasks for the result.`;
     }
     const statusNote = status && status.length > 0 ? ` (status: ${status})` : '';
-    // 0.72.12 CC-50(异源对抗复审 R2 [medium]):只对**明确终态**说 already finished。此前这个尾模板对任何词都断言「已结束」,
-    // 而同批 normalizeTaskNotification 开始对缺 status 的通知铸 `unknown` ⇒ 补充行重新造出终局确定性(DS-06:兜底位置落正向词,
-    // 且模板表达式逃过 AST 五形)。缺席 / unknown / 未来词 / 活跃词 ⇒ 只陈述投递失败,不推断任务结局。
-    // 终态词表对账**通知**自己的词(单源 `runTerminal.TASK_NOTIFICATION_TERMINAL_STATUSES`),不借 run 级 `isTerminalStatus`
-    // (那张表没有 cancelled、多一个 blocked,语义不同)。
     if (isTaskNotificationTerminalStatus(status)) {
         return `${SUPPLEMENT_LINE_PREFIX}already finished${statusNote} — only this notification delivery failed. Check /tasks for the result.`;
     }
     return `${SUPPLEMENT_LINE_PREFIX}is in a state this client cannot confirm${statusNote} — this notification delivery failed and the task's outcome is unknown here. Check /tasks for its current state.`;
 }
-/**
- * API-error 行文拆分(渲染层消费):尾部的 supplement 行(若在)分离出来渲 dim,main 保留原始
- * error 字面渲红。无 supplement 的行原样返回 —— 既有 API-error 渲染路径零改变。
- */
 export function splitApiErrorSupplement(text) {
     const idx = text.lastIndexOf(`\n${SUPPLEMENT_LINE_PREFIX}`);
     if (idx === -1)
@@ -1093,28 +663,19 @@ export function splitApiErrorSupplement(text) {
     return { main: text.slice(0, idx), supplement: text.slice(idx + 1) };
 }
 const KNOWN_REASONS = new Set(['no_content', 'unparsed', 'skipped']);
-/**
- * hook_notice 帧的判定本体(壳 ingestHookNoticeFrame 的判定半场逐字等价)。
- * 🔴 归属镜像在**这里**做而不是在 fleetClient 里做 —— #105 变异普查(F3)定谳过:分发条件留在
- * fleetClient 时,离线门只能 grep 源码,而 grep 对「把 'hook_notice' 改成 'hook_noticeZZZ'」
- * 这类变异因注释碰撞+子串命中恒绿。提到这里后离线门直接**行为测本函数**。
- */
 export function classifyHookNoticeFrame(frame, opts) {
     const f = frame;
     if (f?.type !== 'hook_notice')
         return { ok: false, drop: 'not-hook-notice' };
     if (f.kind !== 'hook_decision_unavailable') {
-        // 未来新 kind:纯 observe 道,未知即忽略(不猜语义)。
         return { ok: false, drop: 'unknown-kind', kind: String(f.kind) };
     }
-    // 🔴 归属镜像:server 只对 scoped 连接 fail-closed;未 scoped 连接上这帧可能是任何会话的。
     if (!opts.sessionScoped)
         return { ok: false, drop: 'not-session-scoped' };
     const reason = typeof f.reason === 'string' && KNOWN_REASONS.has(f.reason)
         ? f.reason
         : 'skipped';
     const event = typeof f.event === 'string' ? f.event : '';
-    // 非 Stop 事件今天没有承载面(PreToolUse 等等有承载面再接)。
     if (event !== 'Stop')
         return { ok: false, drop: 'non-stop-event', event, reason };
     return {
@@ -1127,52 +688,25 @@ export function classifyHookNoticeFrame(frame, opts) {
         },
     };
 }
-/** 判别口:是不是 hook_notice 帧(宿主 fleet applyFrame 的分发条件;不是则继续走别的臂)。 */
 export function isHookNoticeFrame(frame) {
     return frame?.type === 'hook_notice';
 }
-/**
- * 「Last check」行的诚实文案([1790] 措辞纪律:「本轮未能评估,已放行」方向;detail 是 server
- * 结构化日志同源的机器话,dim 展示原文比意译更可追责)。
- */
 export function hookNoticeLastCheckText(n) {
     return `couldn't evaluate this turn — proceeded (${n.reason}${n.detail ? `: ${n.detail}` : ''})`;
 }
-/** footer 通知条文案前缀(测试锁字面;宿主拼 ` (${reason})`)。 */
 export const HOOK_NOTICE_WARN_PREFIX = 'Goal check: couldn\'t evaluate this turn — proceeded';
 const KNOWN_FAILURE_REASONS = new Set(['exit_nonzero', 'timeout', 'spawn_failed', 'bad_json']);
 const KNOWN_ENTRY_TYPES = new Set(['command', 'http', 'prompt', 'agent']);
-/**
- * 观测帧自由文本上限 —— 与 server `MAX_HOOK_NOTICE_TEXT_CHARS`(`fleet/fleet-bus.d.ts`)同值。
- * 🔴 server 已截过一遍(那一遍拿得到原文,是**承重**的);本包这一遍是**边界兜底**,挡住忘了截断的
- *    未来生产者把一条无界流灌进单行横幅。幂等:输出恒 ≤ 上限。
- */
 export const MAX_HOOK_NOTICE_TEXT_CHARS = 512;
 function boundedNoticeText(s) {
     return s.length <= MAX_HOOK_NOTICE_TEXT_CHARS ? s : s.slice(0, MAX_HOOK_NOTICE_TEXT_CHARS);
 }
-/**
- * `hook_non_blocking_failure` 帧的判定本体(#281 的客户端半场)。
- *
- * 🔴 **与 {@link classifyHookNoticeFrame} 是两个口,不是一个口的两条臂**:两族的载荷形不同
- * (那族出 {@link GoalHookNotice},本族出 {@link HookFailureNotice}),把它们塞进同一个返回联合会
- * **破坏既有消费端**(现在 `v.ok` 之后直接读 `v.notice` 的写法要全部改窄化)。分口 ⇒ 姊妹口的行为
- * **逐字节不变**(它对本族仍报 `unknown-kind`,常驻套对这一格有钉),宿主按 `kind` 分派一次即可。
- *
- * 🔴 **闭集位一律「不认就丢」,绝不折成某一档**:与姊妹族「表外 reason 归一到 `skipped`」刻意不同 ——
- * 那一族的 `skipped` 有真兜底语义(「跳过了」),本族**没有**「兜底故障形」这种东西,把一个没见过的
- * 词折成 `exit_nonzero` 就是替引擎编一个它没说过的故障。
- *
- * 🔴 `hookName` 缺席即丢:一条「某个 hook 坏了、但不知道是哪个」的横幅,用户拿它什么都做不了,
- * 只会制造焦虑 —— 而 server 侧这一位是**必填**,缺席意味着这不是一帧合规的本族帧。
- */
 export function classifyHookFailureFrame(frame, opts) {
     const f = frame;
     if (f?.type !== 'hook_notice')
         return { ok: false, drop: 'not-hook-notice' };
     if (f.kind !== 'hook_non_blocking_failure')
         return { ok: false, drop: 'unknown-kind', kind: String(f.kind) };
-    // 🔴 归属镜像(与姊妹族同一条 fail-CLOSED):server 只对 scoped 连接过滤。
     if (!opts.sessionScoped)
         return { ok: false, drop: 'not-session-scoped' };
     if (typeof f.reason !== 'string' || !KNOWN_FAILURE_REASONS.has(f.reason))
@@ -1188,7 +722,6 @@ export function classifyHookFailureFrame(frame, opts) {
             reason: f.reason,
             hookName: boundedNoticeText(f.hookName),
             entryType: f.entryType,
-            // 🔴 非整数/非数一律降缺席 —— 退出码是给人照着查的,一个 1.5 或 'x' 比没有更坏。
             ...(typeof f.exitCode === 'number' && Number.isSafeInteger(f.exitCode) ? { exitCode: f.exitCode } : {}),
             ...(typeof f.toolName === 'string' && f.toolName ? { toolName: boundedNoticeText(f.toolName) } : {}),
             ...(typeof f.stderr === 'string' && f.stderr ? { stderr: boundedNoticeText(f.stderr) } : {}),
@@ -1197,14 +730,3 @@ export function classifyHookFailureFrame(frame, opts) {
         },
     };
 }
-// 🔴 本族的**横幅文案口** `hookFailureNoticeText` / `HOOK_FAILURE_WARN_PREFIX` 与能力位读口一样,
-//    刻意**不在本文件**,而在 `hooksWireCaps.ts` —— 理由同 `fleetHookFailureNoticeCapable`:本文件在
-//    **A 层闭包**内(portability 门 ①b,只降棘轮),而文案口必须过展示消毒单源 `collapseLabel`
-//    (在 `fleetTaskDesc.ts`),把那个文件拉进闭包会让棘轮当场涨一格;在本文件手抄第二份字符集
-//    则正是 `fleetTaskDesc` 顶注点名禁止的形(「改一处必须改另一处」)。
-//    ⇒ **判定留本文件、展示归那一层**,与包内既有分工一致(本文件只交出**原文** `hookName`/`stderr`,
-//    UNTRUSTED-for-display 的消毒责任在渲染侧)。
-// 🔴 本族的**能力位读口** `fleetHookFailureNoticeCapable` 刻意**不放在本文件**,而在
-//    `hooksWireCaps.ts` —— 本文件在 **A 层闭包**内(portability 门 ①b,只降棘轮),而能力位要读
-//    `engineCapsCache`,把那个文件拉进闭包会让棘轮当场涨一格。能力位本就属 `*WireCaps` 那一层
-//    (与 `hooksForWire` 同域),放那里是归位不是绕道。