@sema-agent/client-core 0.8.0 → 0.9.0

package/dist/notifications.d.ts

@@ -49,6 +49,46 @@ export declare function taskNotificationDedupKey(n: {
     seq?: number | string;
     taskType?: string;
 }): string;
+/**
+ * ⇄ B7(T2):同一把键的 **裸 wire 载荷** 入口 —— cli `upstreamBridge.engineTaskNotificationDedupKey`
+ * 的等价物(入参是引擎 `task_notification` 帧的原始 payload:snake_case `task_id` / `task_type`)。
+ *
+ * 🔴 **不是第二份算法**:字段归一之后直接委托给上面那一个 `taskNotificationDedupKey`。
+ * 两份手写算法正是这条键在 0.1.1 被 codex 对抗复审抓到过的形(无 seq 追不追段的差异会让
+ * 「重放去重」整条失效而两边代码看着都对);pure 门 B7 段对两个入口做**同键对拍**。
+ *
+ * 键形:`[external:]taskId:status[:seq]`。缺 `task_id` ⇒ 空 taskId 段(与 cli 逐字一致 ——
+ * 空 id 的通知本就在 `normalizeTaskNotification` 那一层被丢弃,这里不额外加语义)。
+ *
+ * ⚠️ **P1-3(完成事件单一权威)未到货 ⇒ 只搬不删**:引擎给出 `completionId` 之后,这把
+ * 「客户端按 taskId:status[:seq] 自己重算」的键才能换成「读引擎发的 id」。退役条件见
+ * `compensations.ts` 的 T2 行。
+ */
+export declare function taskNotificationDedupKeyFromWire(n: Record<string, unknown>): string;
+/**
+ * ⇄ B7(T3):从**落盘转录**里的 `<task-notification>` 块反解去重键 —— #63 resume 回植的
+ * **纯解析半场**(适配器实例的 `importLedgerFromTranscript` 与宿主的 resume 装载腿共用这一份)。
+ *
+ * 为什么要单独导出:cli 里这段解析有**两份**(`upstreamBridge.seedEngineTaskNotificationDedupFromTranscript`
+ * 与包内 `WireToCcAdapterImpl.importLedgerFromTranscript`),两份的差异会让 resume 回植在某一侧
+ * 静默失效。B7 把解析收成一份纯函数,两个消费口都调它;壳侧那份 shim 化后直接调
+ * `bridgeAdapter().importLedgerFromTranscript(...)`。
+ *
+ * 🔴 键形必须是**无 seq** 的:落盘 XML 不带 seq,Monitor 的 `:seq` 批键形与之不同 —— 这正是
+ * 「绝不误伤 Monitor 多批流」的判据(cli `taskNotificationResumeSeed` 单测双向钉的就是它)。
+ *
+ * ⚠️ **P1-3 到货后**:仍需回植(crash 窗口是客观存在的),但不必再解 XML —— 转录里会直接带
+ * `completionId`。退役条件见 `compensations.ts` 的 T3 行。
+ */
+export interface TranscriptNotificationSeeds {
+    /** 渲染去重键(`[external:]taskId:status`,**无 seq 段**)。 */
+    renderedKeys: string[];
+    /** 跨通道记账键(裸 taskId;仅**非 external** 的终态 completed/failed/killed)。 */
+    notifiedKeys: string[];
+    /** 解出的块数(= cli `seeded` 返回值)。 */
+    seeded: number;
+}
+export declare function parseTranscriptNotificationSeeds(messages: ReadonlyArray<unknown>): TranscriptNotificationSeeds;
 /** 宿主队列条目的最小结构形(壳 QueuedCommand 的子集;本包只读这三个键)。 */
 export interface QueuedCommandLike {
     mode?: unknown;
@@ -63,6 +103,23 @@ export interface NotificationQueuePort {
     }): void;
     /** 壳 = messageQueueManager.removeByFilter;返回被摘掉的条目(数量是判据)。 */
     removeByFilter(predicate: (cmd: QueuedCommandLike) => boolean): QueuedCommandLike[];
+    /**
+     * B7:`mode:'prompt'` 的 **isMeta** 回植(今天唯一的消费者 = plan_review 结局,
+     * `hitl/planReviewWire.ts`)。与上面那条是**不同的队列语义**(task-notification 走
+     * `<task-notification>` 通道;这条是一个 isMeta 的 prompt turn),所以是第二个动词而不是
+     * 给第一个加参数。
+     *
+     * 🔴 **可选**(`?`):既有宿主(壳 B2 起装的那份)不实现它照样满足接口 —— 加必填方法会让所有
+     * 已装配的宿主在类型层一起红,而这条动词只有一个消费者。缺席 ⇒ 计 miss + 该结局不回植
+     * (模型在 approve 之后原地不动),**不是**静默可接受的面,所以计 miss 而不是静默。
+     */
+    enqueueMetaPrompt?(command: {
+        value: string;
+        mode: 'prompt';
+        priority: 'later';
+        isMeta: true;
+        workload: string;
+    }): void;
 }
 /** 宿主装配:壳侧 shim / web 宿主在**模块加载期**装(装之前的调用会计入 miss)。 */
 export declare function installNotificationQueuePort(port: NotificationQueuePort | null): void;
@@ -81,6 +138,16 @@ export declare function _resetNotificationQueuePortForTest(): void;
  * (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 declare function enqueuePlanReviewOutcome(value: string): boolean;
 export declare function dropQueuedNotificationsForRun(taskId: string): number;
 /**
  * Pre-seed the runId dedup WITHOUT enqueueing — the completion already reached the model in-band

package/dist/notifications.js

@@ -99,6 +99,80 @@ export function taskNotificationDedupKey(n) {
     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 被 codex 对抗复审抓到过的形(无 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 : '',
+        status: typeof n.status === 'string' ? n.status : 'completed',
+        ...(typeof n.seq === 'number' || typeof n.seq === 'string' ? { seq: n.seq } : {}),
+        ...(typeof n.task_type === 'string' ? { taskType: n.task_type } : {}),
+    });
+}
+export function parseTranscriptNotificationSeeds(messages) {
+    const unescape = (s) => s
+        .replace(/&lt;/g, '<')
+        .replace(/&gt;/g, '>')
+        .replace(/&quot;/g, '"')
+        .replace(/&#39;/g, "'")
+        .replace(/&amp;/g, '&');
+    const renderedKeys = [];
+    const notifiedKeys = [];
+    let seeded = 0;
+    for (const m of messages) {
+        const rec = m;
+        if (rec?.type !== 'user')
+            continue;
+        const content = rec.message?.content;
+        const texts = [];
+        if (typeof content === 'string')
+            texts.push(content);
+        else if (Array.isArray(content)) {
+            for (const b of content) {
+                const bb = b;
+                if (bb?.type === 'text' && typeof bb.text === 'string')
+                    texts.push(bb.text);
+            }
+        }
+        for (const text of texts) {
+            if (!text.includes(`<${TASK_NOTIFICATION_TAG}`))
+                continue;
+            const blockRe = new RegExp(`<${TASK_NOTIFICATION_TAG}(\\s[^>]*)?>([\\s\\S]*?)</${TASK_NOTIFICATION_TAG}>`, 'g');
+            for (const bm of text.matchAll(blockRe)) {
+                const attrs = bm[1] ?? '';
+                const body = bm[2] ?? '';
+                const idM = body.match(new RegExp(`<${TASK_ID_TAG}>([\\s\\S]*?)</${TASK_ID_TAG}>`));
+                const stM = body.match(new RegExp(`<${STATUS_TAG}>([\\s\\S]*?)</${STATUS_TAG}>`));
+                if (!idM || !stM)
+                    continue;
+                const taskId = unescape(idM[1] ?? '');
+                const status = unescape(stM[1] ?? '');
+                if (taskId.length === 0 || status.length === 0)
+                    continue;
+                const external = /\btype="external"/.test(attrs);
+                renderedKeys.push(`${external ? 'external:' : ''}${taskId}:${status}`);
+                if (!external && (status === 'completed' || status === 'failed' || status === 'killed')) {
+                    notifiedKeys.push(taskId);
+                }
+                seeded++;
+            }
+        }
+    }
+    return { renderedKeys, notifiedKeys, seeded };
+}
 // ══════════════════════════════════════════════════════════════════════════════════════════════
 // ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2「通知族合并」):cli 三个文件并入本模块
 //   ① src/sema/engineTaskNotification.ts(347 行,台账 + watcher + 入队合成)
@@ -180,6 +254,26 @@ const notifiedRunIds = new Set();
  * (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)
+        return false;
+    if (typeof p.enqueueMetaPrompt !== 'function') {
+        queuePortMisses++;
+        return false;
+    }
+    p.enqueueMetaPrompt({ value, mode: 'prompt', priority: 'later', isMeta: true, workload: 'plan-review' });
+    return true;
+}
 export function dropQueuedNotificationsForRun(taskId) {
     const needle = `<${TASK_ID_TAG}>${escapeXml(taskId)}</${TASK_ID_TAG}>`;
     const p = port();

package/dist/subagent/engineTaskHandleWire.d.ts

@@ -1,4 +1,3 @@
-export { engineTaskHandlesCapable } from './engineRowStopGate.js';
 export interface EngineTaskOutputResult {
     /** 累积后的输出正文(游标两形兼容,见头注)。 */
     content: string;

package/dist/subagent/engineTaskHandleWire.js

@@ -44,9 +44,10 @@ import { engineWireDebugEnabled, engineWireTarget } from '../engineWireTarget.js
 import { activeEngineRunId, engineSessionParamSpread } from '../engineSessionParam.js';
 import { getBgParentRun } from '../subagentContentStore.js';
 import { engineTaskHandlesCapable } from './engineRowStopGate.js';
-// 能力门同步读口:#98 起真源在零依赖叶 `engineRowStopGate`(批量停要同步分类,不能拉本模块的
-// SDK 图),这里原样 re-export,消费方不动。
-export { engineTaskHandlesCapable } from './engineRowStopGate.js';
+// 能力门同步读口:真源在零依赖叶 `engineRowStopGate`(batch-stop 同步分类不拉本模块 SDK 图)。
+// ⚠️ 此处**不再 re-export**——它与原定义同进 index.ts 的 `export *` barrel 会构成双出口,
+// esbuild 对 star-export 歧义直接 build 失败(tsc 同源 symbol 不报=假绿;0.8.0 壳收批实撞,
+// idle-terminal-settle 套逮住)。包内消费者直接 import 原叶。
 /** 宿主 run 解析:fleet 行/通知帧喂的 parent 映射优先(行 id=`${runId} ${handle}` 的 parentId
  *  投影),缺席退当前交互 run(register 时刻的活跃 run 即宿主——engineSide bash 行的出生形)。 */
 function resolveHostRun(handle) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sema-agent/client-core",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "Client-side session runtime shared by every sema human client (TUI / web / desktop): sema wire frames (AgentEvent) -> CC session vocabulary (SDKMessage) with dual-plane output (transcript/chrome), deterministic transcript ids, lane discipline as a type, and the notification/dedup ledgers. Every CC-skin shape is collected here so the wire itself stays neutral. Blackboard [1832] design axioms; [1651]/[1652]/[1653] signed seam design. Renamed from @sema-agent/wire-cc-adapter (0.1.x).",
   "license": "MIT",
   "type": "module",
@@ -25,7 +25,7 @@
   },
   "devDependencies": {
     "@sema-agent/agent-types": "^0.2.0",
-    "@sema-agent/sdk": "^0.0.118",
+    "@sema-agent/sdk": "^0.0.125",
     "esbuild": "^0.27.4",
     "typescript": "^6.0.2"
   }