@sema-agent/client-core 0.44.0 → 0.45.0

package/dist/fleet/fleetLedger.js

@@ -1,6 +1,6 @@
 import { hostLog } from '../host.js';
 import { engineWireDebugEnabled } from '../engineWireTarget.js';
-import { engineSessionParam } from '../engineSessionParam.js';
+import { engineSessionParam, engineSessionParamFor } from '../engineSessionParam.js';
 // `isHookNoticeFrame` 不在这里 re-export —— 它已由 index.ts 的 `export * from './notifications.js'`
 // 出口(重复 re-export 只会让同名绑定在包根变含糊)。端要先分诊再喂台账,从包根 import 即可。
 import { enqueueBgChildNotification, isOwnWorkflowRun } from '../notifications.js';
@@ -87,12 +87,18 @@ export function __resetFleetLedgerRegistryForTests() {
 /**
  * `client.fleet.stream(...)` 的会话过滤参数。缺席(端未装 SessionPort / 还没有会话 id)⇒ `{}`
  * = principal 级视图,**与 1.37 之前逐字同行为**(不是错误态)。
+ *
+ * 🔴 **默认槽形**(design/285 §2.1):读的是 `DEFAULT_SESSION_KEY` 槽的 `SessionPort`。单会话宿主
+ *    (cli 及今天的三端)用它**正确**;**keyed 多会话宿主别用它开流** —— 用
+ *    `createFleetLedger(hooks, { sessionKey }).issueStream()` 拿 `ingress.options`,那是本包对
+ *    keyed 开流参数的唯一承诺形(理由见文件头 design/285 段)。
  */
 export function fleetStreamOptions() {
     const s = engineSessionParam();
     return s ? { session: s } : {};
 }
-/** G19:`client.fleet.snapshot(...)` 的参数(同上;首屏/温切探针用)。 */
+/** G19:`client.fleet.snapshot(...)` 的参数(同上,同为默认槽形;首屏/温切探针用)。
+ *  keyed 宿主走 `ledger.issueSnapshot(opts)`。 */
 export function fleetSnapshotOptions(opts) {
     return {
         ...fleetStreamOptions(),
@@ -121,12 +127,49 @@ export function createFleetLedger(hooks = {}, opts = {}) {
     /** [2393] notif-F12:另两条丢弃路径的计数(未知帧型 / 隔离优先丢弃)。 */
     let droppedUnknownFrame = 0;
     let droppedForeignBgNotification = 0;
+    /** [2393] notif-F12 姊妹位(design/285 批 1):迟到 ingress(旧 epoch / 已关)上的帧丢弃计数。 */
+    let droppedStaleIngress = 0;
     let connected = false;
     let version = null;
     let scoped = null;
     let sessionScopedMeta;
     let bgNotifyFailClosedMeta = false;
     let disposed = false;
+    // ── design/285 批 1:ingress 发放与代际 ───────────────────────────────────────────────────────
+    /** ingress 发放序号(stream 与 snapshot 共用一条单调序列,值本身只用于「是不是当前那一只」)。 */
+    let epochSeq = 0;
+    /** 当前 live stream ingress 的 epoch;**0 = 从未 `issueStream()`**(宿主还在用兼容入口)。 */
+    let liveStreamEpoch = 0;
+    /** 当前 live snapshot ingress 的 epoch(与 stream 分开记 —— 快照绝不作废正在跑的流)。 */
+    let liveSnapshotEpoch = 0;
+    /** 当前 stream ingress 开流那一刻捕获的会话锚(`liveStreamEpoch === 0` 时无意义)。 */
+    let streamAnchor;
+    /**
+     * 本 ledger **有没有采用过 ingress**(对抗复审第九轮 [medium])。
+     * 用途:判「兼容入口是不是有一条活流」时,`connected` 只对**纯兼容入口宿主**有权威性 —— 采用了
+     * ingress 的宿主,流的存活由 `liveStreamEpoch` 说了算,`connected` 可能是上一条流留下的陈旧值
+     * (`close()` 只退流模式,不替宿主改它)。不分开的话,合法的降级序列「开流 → setConnected(true) →
+     * close → 取一次性快照兜底」会把那只快照**永久**判过期,SSE 断掉之后的快照恢复路径静默失效。
+     */
+    let everIssuedStream = false;
+    /**
+     * 🔴 **内容归属锚**(对抗复审第二轮 [high]):本 ledger 里现有的行/留存/连接级 meta **是哪个会话的**。
+     * 只由**经 ingress 到达**的帧写(兼容入口刻意不写:它每帧现读槽会话,再为它加一次端口读只会给
+     * cli 热路径多计一份 miss,而兼容入口按契约本来就只承诺默认槽单会话)。
+     * 用途:`issueStream()` 发现新捕获的会话与它不同 ⇒ 这是**换会话**不是重连,旧会话的账必须先清 ——
+     * 否则 `status().sessionAnchor` 报 B 而 `project()` 还在渲 A 的行,又是一本读面上看不出来的混合账。
+     */
+    let contentAnchor;
+    let contentAnchorSet = false;
+    /**
+     * 🔴 **账本写序号**(对抗复审第五轮 [high]):**任何**入口(ingress 或兼容 `ledger.applyFrame`)成功
+     * 落一帧就 +1。快照 ingress 在发放那一刻记下它,落账时变了即判过期。
+     * 为什么不能只看 `liveStreamEpoch`:兼容入口消费活流时那个值**恒为 0**,于是「兼容流写 running →
+     * 取快照 → 兼容流写 completed → 过期快照 REPLACE 回 running」这条路能整条绕过快照闸。
+     * 副产品(有意,已成文):一只快照 ingress 是**一次性**的 —— 落账一次之后序号即变,要再取一次快照
+     * 就再 `issueSnapshot()`。
+     */
+    let ledgerWrites = 0;
     const debug = (line) => {
         if (engineWireDebugEnabled())
             hostLog('debug', line);
@@ -186,7 +229,8 @@ export function createFleetLedger(hooks = {}, opts = {}) {
         }
         views.add(bgView);
     }
-    function applyFrame(frame) {
+    function applyFrame(frame, ing) {
+        ledgerWrites++; // 账本写序号:全入口通用(见 ledgerWrites 顶注 —— 只看 liveStreamEpoch 会漏掉兼容入口)
         switch (frame.type) {
             case 'meta': {
                 version = frame.version;
@@ -262,7 +306,10 @@ export function createFleetLedger(hooks = {}, opts = {}) {
                     if (parentOwned)
                         recordOwnEngineRun(childTid);
                     if (parentOwned || sessionScopedMeta === true) {
-                        recordBgParentRun(childTid, parentTid);
+                        // 🔴 design/285 批 2(D5):三值原子写 —— 会话与槽键取**本 ingress 开流那一刻的不可变
+                        //    捕获**,不是现读任何可变槽。兼容入口(`ing === null`)两个新参都是 `undefined`
+                        //    ⇒ 与 0.44.0 逐字同(它每帧现读槽会话、库里不留锚,归属不可知就不替它背书)。
+                        recordBgParentRun(childTid, parentTid, ing?.session, ing?.sessionKey);
                     }
                     else {
                         debug(`[fleet-frame] task row parent-map SKIPPED foreign/unowned(row=${row.id} parent=${parentTid})`);
@@ -322,13 +369,20 @@ export function createFleetLedger(hooks = {}, opts = {}) {
                 break;
             case 'hook_notice':
                 // hook_notice(server 1.280.0,[1790]):「本轮 Stop 守卫未能评估」纯 observe 帧。
+                // 🔴 **在册残余 P-31 的第三格**(对抗复审第九轮 [high] 登记):第二参交出去的就是那个**未经会话值
+                //    校验**的连接级信任位 `sessionScopedMeta` —— 与通知臂的 `server_fail_closed`、行帧车道的
+                //    `sessionScoped` 让位**同一个根因**(连接级零内容自校)。keyed ledger 上一条被误接的 A 流
+                //    报 sessionScoped=true 时,A 的 hook_notice 会带着「已按会话过滤」这句话进 B 的宿主面,而本
+                //    回调既不带锚也不带 evidence,端无从自裁。本批**不改签名**(additive 第三参属另一批的公开面
+                //    决定),按残余登记 + 钉现状(B3-P31/R9a);根治与另两格同一个 = 上游在 meta 帧回显本连接
+                //    session id ⇒ 一次修好三条通道。
                 // 判定本体在 notifications.classifyHookNoticeFrame(#105 F3:判别不许留在分发处,否则
                 // 离线门只能 grep);写 store 归宿主。SDK 0.0.117 起本帧**已在 FleetFrame 联合里**,
                 // 不再走 default 臂的 `type` 字面判别。
                 hooks.onHookNotice?.(frame, sessionScopedMeta === true);
                 break;
             case 'bg_notification':
-                applyBgNotification(frame.notification);
+                applyBgNotification(frame.notification, ing);
                 break;
             default:
                 // 未知未来帧 —— 开集,忽略。**但要留痕**([2393] notif-F12):忽略也是丢数据,
@@ -344,7 +398,7 @@ export function createFleetLedger(hooks = {}, opts = {}) {
      *  REF-CC-048(fleet2-10):参数类型此前写成 `FleetFrame extends never ? never : BgNotificationWire`
      *  —— 条件类型只对**裸类型参数**分发,`FleetFrame` 是具体 union,整个表达式恒等于
      *  `BgNotificationWire`,伪装成了一个从不成立的守卫。直写目标类型,不留误导性的仪式感。 */
-    function applyBgNotification(n) {
+    function applyBgNotification(n, ing) {
         if (typeof n?.taskId !== 'string' || typeof n?.status !== 'string') {
             droppedMalformed++;
             debug('[fleet-frame] MALFORMED bg_notification dropped(taskId 或 status 缺席/非串)');
@@ -383,9 +437,17 @@ export function createFleetLedger(hooks = {}, opts = {}) {
         //   硬证据。🔴 与行帧的 `rowSessionTag` 不同 —— server `streamFleet` 只从**行**上剥
         //   scope/sessionId,通知帧只剥 ownerScope/ownerSessionId,`rootSessionId` **照发**
         //   (1.291.0 dist 实读)⇒ 这条腿是活的,不在 G12 删除范围内。
+        // 🔴 design/285 批 1(P-31 正位解的判据半场):比对锚从**默认槽**换成**本 ledger 的会话锚** ——
+        //   经 ingress 到达 ⇒ 该 ingress 开流那一刻的不可变捕获(逐帧现读会让重连后旧流的迟到帧配上
+        //   新会话,那正是 owner 台账明禁的错组合);兼容入口 ⇒ `engineSessionParamFor(sessionKey)` 现读。
+        //   默认槽 + 兼容入口 ⇒ `engineSessionParamFor(DEFAULT_SESSION_KEY)` ≡ `engineSessionParam()`,
+        //   与 0.32.0 同一条取值链、逐字节等价。
+        //   ⚠️ keyed 车道这是**真行为改变**:`ownByRoot` 是下面那道丢弃门的放行腿之一,换锚会改放行/
+        //   丢弃集 —— 带**别的会话** `rootSessionId` 的通知对本键 ledger 本就该判 foreign(方向更正确)。
+        const anchor = ing !== null ? ing.session : engineSessionParamFor(sessionKey);
         const ownByRoot = typeof n.rootSessionId === 'string' &&
             n.rootSessionId.length > 0 &&
-            n.rootSessionId === engineSessionParam();
+            n.rootSessionId === anchor;
         if (!serverFailClosed &&
             !ownByRoot &&
             typeof n.parentTaskId === 'string' &&
@@ -400,23 +462,44 @@ export function createFleetLedger(hooks = {}, opts = {}) {
         //    `parentTaskId` 在不在分开(走到这里且带非空 parentTaskId ⇒ 它必然 ∈ own-run 台账,
         //    否则上面已丢弃)。多臂同时成立报第一条 —— 报的是「这一帧**实际**靠哪条过的门」,
         //    不是「最强的那条理论上也成立」。
-        // 🔴 非默认 sessionKey 封顶(0.32.0 发包前扫码采 复审 折中,P-31 的诚实半步):前两格的
-        //    会话级读法前提=「这条流是按本 ledger 的会话开的」,而开流参数只认默认槽 ⇒ keyed ledger
-        //    上该前提**无法成立也无法校验**。封顶词=`session_anchor_untrusted`(不降到 own_parent:
-        //    经 serverFailClosed/ownByRoot 放行的帧,其 parentTaskId 可能是 foreign——标进程成员是
-        //    比错标会话更糟的谎报;也不标 absent_parent:键可能在场)。语义=「这帧被会话级臂放行,
-        //    但本 ledger 无法信任那个会话锚」——消费方按非证据档自裁。单会话宿主(默认 key,今日
-        //    三端)逐字不变;P-31 正位解(per-key 会话锚全套)落地时撤此封顶。
-        const sessionEvidenceTrusted = sessionKey === DEFAULT_SESSION_KEY;
-        const evidence = serverFailClosed || ownByRoot
-            ? sessionEvidenceTrusted
-                ? serverFailClosed
-                    ? 'server_fail_closed'
-                    : 'own_root'
-                : 'session_anchor_untrusted'
-            : typeof n.parentTaskId === 'string' && n.parentTaskId.length > 0
-                ? 'own_parent'
-                : 'absent_parent';
+        // 🔴 可信谓词**按臂拆分**(design/285 §2.3.3,P-31 正位解;取代 0.32.0「非默认 key 一律封顶」
+        //    那一刀切)。两臂不同命的理由 = **自校能力不同**,不是版本先后:
+        //    · `own_root` 拿通知内容里的 `rootSessionId` 与本锚**逐值比对** —— 宿主把 A 流喂进 B 的
+        //      ingress 时,A 的通知带 `rootSessionId = sid-A ≠ sid-B`,自动拒。⇒ 锚换对了这一臂就真可信:
+        //      默认槽恒可信(0.32.0 逐字同);keyed 上**经 ingress 到达**即可信(通道证据),走兼容入口
+        //      仍封顶(没有通道证据,ledger 无从知道帧来自哪条连接)。
+        //    · `serverFailClosed` **零内容自校**:只读 meta 两个布尔位,不读任何会话、不比对任何值,
+        //      而任何一条 session-bound 流的 meta 都长这样 ⇒ 跨-key 误接时它会替别的会话作证,ingress
+        //      对此证明不了任何东西。⇒ **keyed 上恒封顶**,待上游在 meta 帧回显本连接 session id 后再议。
+        //    封顶词仍是 `session_anchor_untrusted`(不降到 own_parent:经会话级臂放行的帧其 parentTaskId
+        //    可能是 foreign,标进程成员比错标会话更糟;也不标 absent_parent:键可能在场)。
+        const defaultSlot = sessionKey === DEFAULT_SESSION_KEY;
+        const viaIngress = ing !== null;
+        /** 内容自校臂:锚对了就可信(空锚时 `ownByRoot` 结构性恒 false —— 没有锚就没法逐值比对,
+         *  所以不需要第二道 anchorOk;这也是为什么空锚只挡得住这一臂,挡不住零自校的那一臂)。 */
+        const ownRootTrusted = defaultSlot || viaIngress;
+        /** 零内容自校臂:只有「前提可成立」的默认槽那一格可信。
+         *  ⚠️ **刻意不叠 anchorOk**:这一臂的前提是「这条流是替谁开的」,与本端有没有装 `SessionPort`
+         *  无关 —— 默认槽 + 空锚 + 生产 meta 仍报本词,与 0.32.0 逐字同(钉:B3-P31/R5c)。 */
+        const serverFailClosedTrusted = defaultSlot;
+        // 🔴 臂序 = 求值序,但**只在「成立且可信」的臂之间**排序(对抗复审第一轮 [high] 采纳,红先绿后)。
+        //    旧写法「无条件先报 serverFailClosed」在**生产 meta 组合**(两位恒 true)下会让 keyed 车道
+        //    永远走不到 own_root —— 哪怕 `rootSessionId` 与本锚精确相等、内容自校已经成立。那等于把一条
+        //    **真的**会话级证明扔掉、改报一个封顶的非证据词,本批的核心净收益在生产配置下完全不可达。
+        //    新规矩:**第一条「成立 ∧ 可信」的会话级臂**胜出;一条都没有而至少有一条成立 ⇒ 封顶词。
+        //    🔴 绝不因此下探到 `own_parent`:会话级臂放行的帧根本没验过 `parentTaskId ∈ own-run 台账`
+        //    (放行门在 serverFailClosed/ownByRoot 上短路),报进程成员就是谎报。
+        const trustedSessionArm = serverFailClosed && serverFailClosedTrusted
+            ? 'server_fail_closed'
+            : ownByRoot && ownRootTrusted
+                ? 'own_root'
+                : undefined;
+        const evidence = trustedSessionArm ??
+            (serverFailClosed || ownByRoot
+                ? 'session_anchor_untrusted'
+                : typeof n.parentTaskId === 'string' && n.parentTaskId.length > 0
+                    ? 'own_parent'
+                    : 'absent_parent');
         debug(`[fleet-frame] bg_notification taskId=${n.taskId} status=${n.status} seq=${n.seq ?? '-'} accept=${evidence}`);
         // 键域(#242 批 3):`n.taskId` = registry handle = 行 id 的**尾段**。live 集按「整行 id 或
         // 尾段命中」收齐**全部**别名(server 双生行:裸 id 与 `runId childId` 复合形同时在场时两条
@@ -429,7 +512,8 @@ export function createFleetLedger(hooks = {}, opts = {}) {
         }
         if (TERMINAL_FLEET_TASK_STATUSES.has(n.status)) {
             if (typeof n.parentTaskId === 'string' && n.parentTaskId) {
-                recordBgParentRun(n.taskId, n.parentTaskId);
+                // design/285 批 2(D5,通知腿):与行帧腿同一口径 —— 三值取本 ingress 的不可变捕获。
+                recordBgParentRun(n.taskId, n.parentTaskId, ing?.session, ing?.sessionKey);
             }
             // `transcriptId`(server 1.278.0)= 委派 prompt 的取件锚。现势:通知帧是它**今天真的在场**
             // 的主要位置(行帧那条腿已同款接好,引擎一发即亮 —— 见 case 'task')。
@@ -677,11 +761,214 @@ export function createFleetLedger(hooks = {}, opts = {}) {
             workflows: projectWorkflows([...wfMap.values()].filter(ownWorkflowRow)),
         };
     }
+    /**
+     * ingress 工厂(stream/snapshot 共用)。`isLive` 让两条 ingress 各查各的代际位。
+     *
+     * 🔴 **单锚不变量**(对抗复审第一轮 [high] 采纳):一本 ledger 在**任一时刻只有一个会话锚**。
+     *    两条 ingress 的代际位分开记,但两者**不许同时 live 且锚不同** —— 否则同一个 `taskMap` /
+     *    `retained` / 连接级 meta 会被两个会话代际同写(snapshot 的 REPLACE 还会抹掉 stream 那一代的行),
+     *    而 `status().sessionAnchor` 只报 stream 那一个,混合态从读面上完全看不出来。
+     *    落地:`issueStream()` **作废在飞的 snapshot ingress**;`issueSnapshot()` 在 stream 模式下
+     *    **继承** stream 的捕获而不自己现读(见各自实现)。
+     */
+    const makeIngress = (kind, epoch, session, isLive) => {
+        let closed = false;
+        return {
+            session,
+            sessionKey,
+            epoch,
+            applyFrame(frame) {
+                if (disposed)
+                    return;
+                if (closed || !isLive()) {
+                    // 迟到帧(重连后旧 ingress / 已关的 ingress / 被流超车的快照):丢弃 + 计数。结构性堵死
+                    // 「旧流的帧配上新会话」这一错组合 —— 那正是 owner 台账「开流时一次性捕获、不逐帧现读」
+                    // 要防的形。
+                    droppedStaleIngress++;
+                    debug(`[fleet-frame] STALE ingress frame dropped(kind=${kind} epoch=${epoch} closed=${String(closed)}` +
+                        ` type=${String(frame.type)})`);
+                    return;
+                }
+                applyFrame(frame, { session, sessionKey });
+                contentAnchor = session;
+                contentAnchorSet = true;
+            },
+            close() {
+                closed = true;
+                // 🔴 收流要**真的退出流模式**(对抗复审第二轮 [medium]):只翻闭包位的话,`liveStreamEpoch`
+                //    仍非 0 ⇒ 此后每次 `issueSnapshot()` 都把一条**已关**的流当 live、继承它的陈旧锚,于是
+                //    「关流 → 换会话 → 取快照」会拿旧会话去打服务器,而 `status()` 还报旧会话。
+                //    ⚠️ 退出流模式**不等于**锚回落现读:账里还有上一会话的内容时 `status().sessionAnchor`
+                //    照实报**内容归属锚**(见 `FleetLedgerStatus.sessionAnchor` 三态)。
+                //    epoch 相等才动:关一只**过期**的 ingress 绝不许影响更新的那一只。
+                if (kind === 'stream' && liveStreamEpoch === epoch)
+                    liveStreamEpoch = 0;
+                if (kind === 'snapshot' && liveSnapshotEpoch === epoch)
+                    liveSnapshotEpoch = 0;
+            },
+        };
+    };
+    /**
+     * 🔴 **连接级 meta 复位** —— 每开一条新连接就清(对抗复审第三轮 [high])。
+     *
+     * `version`/`scoped`/`sessionScoped`/`bgNotifyFailClosed` 是「**那条连接**」的事实,不是会话内容:
+     * `sessionScoped` 决定行级 own 判别整条**让位**,`bgNotifyFailClosed` 决定通知的台账判别整条**让位**
+     * —— 两个都是 fail-**open** 方向的信任位。重连若落到老版本 / 降级节点 / 忽略 `?session=` 的节点,
+     * 或新 `meta` 缺席/迟到,沿用上一条连接的这两位 = 广播行被投影、foreign 通知绕过本地归属门去改状态
+     * 和触发钩子。**保留行与留存是对的(R7),保留连接信任位不是。**
+     * 复位后到新 `meta` 到达之间那一小段:`sessionScoped=undefined` ⇒ 行级 own 判别回到本地台账
+     * (成文的「宁藏勿串」),`bgNotifyFailClosed=false` ⇒ 通知回到 parentTaskId 判别 —— 两边都更严,方向对。
+     * ⚠️ SDK 的发帧序是 `meta` **第一帧**,所以这个窗在真实连接上就是「首帧之前」。
+     */
+    const resetConnectionMeta = (why) => {
+        version = null;
+        scoped = null;
+        sessionScopedMeta = undefined;
+        bgNotifyFailClosedMeta = false;
+        debug(`[fleet-frame] 连接级 meta 复位(${why})—— 新连接自报之前不许沿用上一条连接的让位/信任位`);
+    };
+    /**
+     * 🔴 换会话时把**上一会话的内容**整体清掉(对抗复审第二/三轮 [high])。
+     * 射程 = 行 / 留存 / 行时刻 + 内容归属锚本身。计数器是生命期量,不清;连接级 meta 由
+     * {@link resetConnectionMeta} 单独管(两件事拆开:换会话必清内容,换连接必清 meta)。
+     * ⚠️ 与「重连」严格分开:**同一会话**重开流不清内容(留存池是渲染层宽限窗,R7 反钉:重连不该
+     * 抽走已完成行)。判据是**捕获的会话变没变**,不是「有没有重开流」。
+     */
+    /** 账里有没有内容(行 / 工作流 / 留存)—— 换会话清账判据里「来路不明的存量」那一格用。 */
+    const hasLedgerContent = () => taskMap.size > 0 || wfMap.size > 0 || retained.size > 0;
+    /**
+     * 🔴 发放 ingress 前的清账判据(对抗复审第六轮 [high] 补齐兼容入口那一格):
+     * · 账里的内容**经 ingress 落的** ⇒ 有确切的归属锚,按「捕获值变没变」判(同会话重连 ⇒ 不清,R7);
+     * · 账里的内容**经兼容入口落的** ⇒ 归属**不可知**(兼容入口每帧现读槽会话,库里不留锚;为它加一次
+     *   per-frame 端口读只会给 cli 热路径白白多计一份 miss)。不可知 = 不能替它背书 ⇒ **清**。
+     *   实际影响面只有「从兼容入口迁到 ingress」那一次(清完 `hasLedgerContent()` 即假);
+     *   而 cli 这类**纯兼容入口**宿主从不调 `issue*`,这条判据对它恒不触发 ⇒ 默认槽逐字节零变化。
+     */
+    const shouldResetContentFor = (session) => contentAnchorSet ? contentAnchor !== session : hasLedgerContent();
+    const resetLedgerContentOnSessionChange = (from, to) => {
+        taskMap.clear();
+        wfMap.clear();
+        rowMeta.clear();
+        retained.clear();
+        contentAnchorSet = false;
+        contentAnchor = undefined;
+        debug(`[fleet-frame] 会话锚变更(${from ?? '-'} → ${to ?? '-'})⇒ 清上一会话的行/留存` +
+            '(换会话不是重连:再渲上一会话的行就是跨会话残影)');
+    };
     return {
         applyFrame(frame) {
             if (disposed)
                 return;
-            applyFrame(frame);
+            // 兼容入口:没有通道证据 ⇒ 会话锚现读本键槽(默认槽逐字节等价于 0.32.0)。
+            applyFrame(frame, null);
+        },
+        issueStream() {
+            const session = engineSessionParamFor(sessionKey);
+            // 🔴 换会话 ≠ 重连:新捕获的会话与**账里现有内容所属**的会话不同 ⇒ 先清旧账再发新 ingress,
+            //    否则 status() 报新会话而 project()/在飞读面还在渲旧会话的行(混合账,读面上看不出来)。
+            //    同会话重开流(真正的重连)走不到这里,留存池原样保留(R7)。
+            if (shouldResetContentFor(session)) {
+                resetLedgerContentOnSessionChange(contentAnchorSet ? contentAnchor : '<兼容入口,归属不可知>', session);
+            }
+            // 🔴 连接级 meta **每开一条新连接就清**(与内容保留策略拆开):那两位是 fail-open 方向的信任位,
+            //    沿用上一条连接的会让「重连落到降级/老版本/忽略 ?session= 的节点」直接绕过本地归属门。
+            resetConnectionMeta('新 stream ingress');
+            const epoch = ++epochSeq;
+            liveStreamEpoch = epoch;
+            streamAnchor = session;
+            everIssuedStream = true;
+            // 🔴 单锚不变量:开真流即作废在飞的一次性快照 ingress —— 快照是时点探针,流一开它就被取代了;
+            //    留着它 = 允许「快照那一代的会话」与「本流的会话」并发写同一本账。
+            liveSnapshotEpoch = 0;
+            debug(`[fleet-frame] ingress issued(kind=stream key=${sessionKey} epoch=${epoch} session=${session ?? '-'})`);
+            return {
+                ...makeIngress('stream', epoch, session, () => liveStreamEpoch === epoch),
+                options: session !== undefined ? { session } : {},
+            };
+        },
+        issueSnapshot(snapOpts) {
+            // 🔴 单锚不变量:stream 模式下**继承** stream 的不可变捕获,绝不自己现读。现读的形在「槽内会话
+            //    已轮换、宿主还没重开流」时会铸出第二个锚,于是两条 live ingress 各按各的会话给同一本账
+            //    背书。继承同时满足 design/285「snapshot 绝不改写 stream 锚」——它只读不写。
+            //    真换了会话的正确姿势是先 `issueStream()`(= 重连),那一步会把锚整体推进。
+            const inStreamMode = liveStreamEpoch !== 0;
+            // 🔴 **兼容入口消费的活流也是活流**(对抗复审第八轮 [high]):那条车道不设 `liveStreamEpoch`,
+            //    只有宿主的 `setConnected(true)` 说得出「现在有一条流连着」。漏判它 = 把一条**正活着**的
+            //    连接当 snapshot-only 处理,当场清掉它的连接级 meta —— 而那条流的 `meta` 只在连接首帧出现过,
+            //    于是 `sessionScoped`/`bgNotifyFailClosed` 会在**剩余整个连接生命期**保持关闭(行投影退回本地
+            //    own-run 判别而静默藏行)。⇒ 活流期间签发的快照:**不清内容、不清 meta、永久判过期**。
+            //    🔴 但 `connected` 只对**纯兼容入口宿主**有权威性(第九轮 [medium]):采用了 ingress 的宿主,
+            //    流的存活由 `liveStreamEpoch` 说了算 —— `close()` 只退流模式、不替宿主改 `connected`,拿一个
+            //    陈旧的 true 当「活流」会把合法降级序列「开流 → close → 取一次性快照兜底」的快照永久判废。
+            const compatStreamLive = !inStreamMode && connected && !everIssuedStream;
+            const duringLiveStream = inStreamMode || compatStreamLive;
+            // 🔴 **活流分支绝不现读端口**(对抗复审第十轮 [medium]):无条件先 `engineSessionParamFor()` 的写法
+            //    与本批「stream 模式下继承捕获、不自己现读」那句承诺自相矛盾 —— 端口热重载期间它会铸出**虚假的
+            //    session miss**(实测:开流后撤端口再签发快照,`hostPortMissesFor(key).session` 0→1),端口实现
+            //    抛错时还会让 `issueSnapshot()` 整条失败。取值只在 snapshot-only 分支发生。
+            const session = inStreamMode ? streamAnchor : engineSessionParamFor(sessionKey);
+            // 🔴 **snapshot-only 车道的换会话也要清账**(对抗复审第三轮 [high]):没有 live stream 时快照
+            //    自己现读,而「A 流写完终态留存 + meta 后 close → 槽切到 B → 只取快照」这条真实时序里,
+            //    snapshot 的 REPLACE **刻意不清留存**(R7)、也带不来新 meta ⇒ B 的活跃行会与 A 的留存行同账,
+            //    且 A 那条连接的 `sessionScoped=true` 还在替整本账放行。走与 issueStream 同一套清账。
+            //    ⚠️ 只在**真的没有活流**时做:活流期间签发的快照本来就永久判过期,清账/清 meta 只会破坏
+            //    那条还活着的连接(第八轮 [high])。
+            if (!duringLiveStream) {
+                if (shouldResetContentFor(session)) {
+                    resetLedgerContentOnSessionChange(contentAnchorSet ? contentAnchor : '<兼容入口,归属不可知>', session);
+                }
+                // 🔴 **快照连接自带不了 meta**(对抗复审第四轮 [high]):SDK 的 `fleet.snapshot()` 内部开流→取
+                //    snapshot 帧→关流,`meta` 在封装里被吞 ⇒ 这条连接的行**没有任何 scoping 断言**。若沿用上一条
+                //    (已关的)stream 连接的 `sessionScoped=true`,快照落在降级/不按 `?session=` 过滤的节点上时,
+                //    它带回的外来行会被一条**不相干连接**的信任位无条件放行投影,而且此后**没有任何 meta 帧**能
+                //    纠正它。⇒ 快照车道一律复位连接级 meta,行回到本地台账判别(fail-closed 方向)。
+                resetConnectionMeta('快照连接:SDK 封装吞掉了它自己的 meta,不许沿用别条连接的信任位');
+            }
+            if (inStreamMode) {
+                debug(`[fleet-frame] snapshot ingress 继承 stream 锚(${streamAnchor ?? '-'};活流期间不现读槽会话 ——` +
+                    ' 要切会话请先 issueStream())');
+            }
+            const epoch = ++epochSeq;
+            liveSnapshotEpoch = epoch; // 🔴 不碰 liveStreamEpoch / streamAnchor
+            debug(`[fleet-frame] ingress issued(kind=snapshot key=${sessionKey} epoch=${epoch} session=${session ?? '-'})`);
+            // 🔴 **有 live stream 时快照一律不落账**(对抗复审第二/四轮 [high] 的合流解):
+            //    ①两条连接两个写者,而 `applySnapshot` 是无条件 REPLACE —— 「服务端取样之后、落账之前」流
+            //      又推了一帧时,照落会把**更新的**行覆盖回旧值,而 fleet 是 latest-state 总线,没有任何
+            //      后续帧保证修回来(只能等那一行下次 transition);
+            //    ②快照连接的 `meta` 被 SDK 封装吞掉 ⇒ 它的行**自带零 scoping 断言**,落进一本正持着别的
+            //      连接 `sessionScoped=true` 的账里,就会被那条**不相干连接**的信任位无条件放行投影。
+            //    而 live stream 本身就是「snapshot 先行的 latest-state 总线」—— 它一开就带全量快照并持续
+            //    刷新,此时再落一份一次性快照**零收益**。⇒ 丢弃 + 计 `droppedStaleIngress`。
+            //    一次性快照的正当场景(首屏/温切探针)本来就发生在**没有 live stream**的时候。
+            // 写序号闸(对抗复审第五轮 [high]):「有 live stream 时不落账」挡不住**兼容入口**消费的活流
+            //    (那条路上 `liveStreamEpoch` 恒为 0)⇒ 再叠一道全入口通用的账本写序号。
+            const writesAtIssue = ledgerWrites;
+            // 🔴 「有没有 live stream」必须**固化在发放那一刻**(对抗复审第七轮 [high] 的 close-before-result
+            //    竞态):落账时才现查 `liveStreamEpoch === 0` 的话,「流活着时签发快照 → 快照还在路上、流先
+            //    `close()` → 快照返回落账」会因为 close 把 epoch 清零而**反而通过闸**;而这只快照当初正是在
+            //    stream 模式下签发的 —— 它跳过了 `resetConnectionMeta()`,于是会沿用一条**已关连接**的
+            //    `sessionScoped=true` 去给自己带回来的行背书。⇒ 流存活期间签发的快照**永久判过期**。
+            //    (发放时无流的那只不必再查 `liveStreamEpoch`:此后一旦 `issueStream()`,它会把
+            //     `liveSnapshotEpoch` 置 0,epoch 那一条已经把它挡下了;兼容车道则由 `ledgerWrites` 挡。)
+            const issuedDuringStream = duringLiveStream;
+            const base = makeIngress('snapshot', epoch, session, () => liveSnapshotEpoch === epoch && !issuedDuringStream && ledgerWrites === writesAtIssue);
+            return {
+                ...base,
+                // SDK 的 `fleet.snapshot()` 回的是 `{tasks, workflows}`(不是帧)—— 帧形在库内合成一处,
+                // 端不再手抄。`ts` 走本地钟只是占位:台账对 snapshot 帧的时刻恒用 `nowFn()`,不读 `frame.ts`。
+                applySnapshot(snapshot) {
+                    base.applyFrame({
+                        type: 'snapshot',
+                        tasks: snapshot.tasks,
+                        workflows: snapshot.workflows,
+                        ts: nowFn(),
+                    });
+                },
+                options: {
+                    ...(session !== undefined ? { session } : {}),
+                    ...(snapOpts?.timeoutMs !== undefined ? { timeoutMs: snapOpts.timeoutMs } : {}),
+                },
+            };
         },
         setConnected(v) {
             connected = v;
@@ -698,6 +985,14 @@ export function createFleetLedger(hooks = {}, opts = {}) {
             droppedMalformed,
             droppedUnknownFrame,
             droppedForeignBgNotification,
+            // 「此刻的判据/内容所属锚」三态(对抗复审第五轮 [high] 收紧):
+            //   ①有 live stream ⇒ 它开流那一刻的捕获(它的帧就按这个判);
+            //   ②没有 live stream 但**账里有内容** ⇒ 内容归属锚 —— 绝不改报一个还没被用过的现读值,
+            //     否则「close 之后槽会话轮换」这一刻 status 就会报新会话而账里装的还是旧会话的行;
+            //   ③空账无流 ⇒ 兼容入口下一帧会现读的那个值。
+            sessionAnchor: liveStreamEpoch !== 0 ? streamAnchor : contentAnchorSet ? contentAnchor : engineSessionParamFor(sessionKey),
+            sessionAnchorEpoch: liveStreamEpoch,
+            droppedStaleIngress,
         }),
         dispose() {
             disposed = true;

package/dist/hitl/planReviewWire.d.ts

@@ -80,7 +80,7 @@ export declare function _resetArmedPlanReviewsForTest(): void;
  * REF-CC-027 above); false = caller renders the terminal as usual. Fail-soft: any error inside must
  * never break the stream drain.
  */
-export declare function armPlanReviewApproval(result: unknown): boolean;
+export declare function armPlanReviewApproval(result: unknown, sessionKey?: string): boolean;
 /** POST the decision; on settle enqueue an isMeta turn so the model reports the resume outcome.
  *  SDK 宪法迁移批:SDK 0.0.52 assistant.planReview verb(同 wire `POST /v1/assistant/tasks/:id/
  *  plan_review` 同 body {decision})——raw fetch 退役。错误模型:非 2xx 抛 APIError(message =

package/dist/hitl/planReviewWire.js

@@ -148,11 +148,39 @@ function publishPlanReviewCard(taskId) {
  * REF-CC-027 above); false = caller renders the terminal as usual. Fail-soft: any error inside must
  * never break the stream drain.
  */
-export function armPlanReviewApproval(result) {
+export function armPlanReviewApproval(result, sessionKey) {
     let armedTaskId;
     try {
         if (!isPlanReviewPark(result))
             return false;
+        // 🔴 **非默认槽 ⇒ 运行时 fail-closed**(异源对抗复审第六轮 [high] 采纳:「文档登记不能代替运行时
+        //    隔离」)。additive 第二参让 keyed 宿主**说得出**这条 park 属于哪个槽;库这边诚实回答
+        //    「这条链今天服务不了它」,而不是**默默按默认槽立卡、再按默认槽把决断发出去** ——
+        //    后者在「默认槽 + keyed 槽同时装配」的宿主上会把 B 会话的 approve/reject 带着**默认槽**的
+        //    baseUrl/token/principal 发出去(对端有同名任务就改错会话的状态,没有就 404 而原 run 继续
+        //    停在审批门)。整条链(卡注册 / 退役 / responder 台账 / decide)同批转 keyed 是 additive
+        //    公开面改动,归后续工单;在那之前**明确拒绝**比静默回落默认槽诚实。
+        //    ⚠️ 不传 / 传默认槽 ⇒ 与 0.44.0 逐字同(单会话宿主零受迫)。
+        if (sessionKey !== undefined && sessionKey !== DEFAULT_SESSION_KEY) {
+            hostLog('error', `planReviewWire: plan_review 卡未 arm —— 本链今天只服务默认会话槽,收到 sessionKey=${JSON.stringify(sessionKey)}。` +
+                '多会话宿主的 plan-mode 归后续工单(卡台账/responder/decide 需同批转 keyed);' +
+                '此处拒绝而不是回落默认槽 —— 回落会把这条会话的决断带着别的槽的 baseUrl/token/principal 发出去。');
+            return false;
+        }
+        // 🔴 design/285 批 3 的**显式裁定:plan 决策链两处 `engineWireTarget()` 本批豁免**(D7b 全量
+        //    清单里唯二不换的两处;设计稿 §1 明令「施工时显式裁入射程或豁免 + 理由」,不许静默漏)。
+        //
+        //    豁免的理由**不是**「它没有这个病」——它有:keyed 宿主上 plan 决断会走默认槽的 baseUrl /
+        //    token / principal。理由是**只换这一跳会造出一个新的自相矛盾**:整条 plan_review HITL 链
+        //    今天是默认槽单会话形 —— 卡的注册与退役按 `DEFAULT_SESSION_KEY`(下一行 `retireActiveReopen`
+        //    与 `liveQuestionStore` 的 responder 台账同键),`decidePlanReview` 又是从那张卡的 responder
+        //    里回调的。把 wire target 单独换成 keyed = 「按默认槽立卡、按 keyed 槽发决断」,比现状更坏
+        //    (现状至少两头一致地错在同一个槽上,一眼可见;半 keyed 形是两头不一致,只在多会话下现形)。
+        //    ⇒ 正确的做法是整条链(卡台账 + responder + wire)**同批**转 keyed,那是 additive 公开面
+        //    改动(`armPlanReviewApproval` 要收 sessionKey 并把它捎进 responder 闭包),归后续工单;
+        //    与本行下方那条「多会话宿主的 arm 路径归后续工单」是同一条欠账,不是两笔。
+        //    现状由常驻钉 `B3-P31/G18b` 钉住(装了 keyed 槽而默认槽为空 ⇒ 本腿仍判 offline),
+        //    防「悄悄换成 keyed」与「悄悄以为已经 keyed 了」两向。
         if (!engineWireTarget())
             return false;
         const { taskId } = result;
@@ -234,6 +262,8 @@ export async function decidePlanReview(taskId, decision) {
     // 请求都没发出去,而模型/用户没有任何回程信号。两条早退现在都汇进同一条 outcome 管道(下方
     // 唯一的 enqueue 调用点),不再是两条独立的静默 return。
     let outcome;
+    // 🔴 design/285 批 3 显式裁定:本处与 `armPlanReviewApproval` 同一笔豁免(理由逐字见那边)——
+    //    决断是从 arm 立的那张卡的 responder 回调进来的,槽键必须与立卡时同源,单换这一跳即两头不一致。
     const cfg = engineWireTarget();
     if (!cfg) {
         hostLog('error', `planReviewWire: ${decision} NOT sent — engineWireTarget() unavailable`);
@@ -374,6 +404,19 @@ export function reopenPlanReviewCard(taskId, opts) {
         if (!hasQuestionOverlayFor(sessionKey)) {
             return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
         }
+        // 🔴 **非默认槽 + 没有自带投递口 ⇒ 拒绝重开**(异源对抗复审第七轮 [high] 采纳)。本函数按传入的
+        //    `sessionKey` 在 B 槽发卡与记账,但**缺省 responder 投递走 `decidePlanReview`,而那一处固定读
+        //    默认槽的 `engineWireTarget()`** ⇒ 用户在 B 看到并点下去的 approve/reject 会带着 **A 的**
+        //    baseUrl/token/principal 出站(对端有同名任务就改错会话的状态,没有就 404 而 B 的任务继续锁死)。
+        //    arm 臂那道 fail-closed 覆盖不到这条 409/自愈重开入口 —— 两个入口必须同命。
+        //    ⚠️ 宿主自带 `deliverDecision`(它自己按槽投递)⇒ 放行,那时投递口不再是库内的默认槽管道。
+        if (sessionKey !== DEFAULT_SESSION_KEY && opts?.deliverDecision === undefined) {
+            hostLog('error', `planReviewWire: plan_review 卡未重开 —— sessionKey=${JSON.stringify(sessionKey)} 是非默认槽,` +
+                '而缺省决断投递口(decidePlanReview)今天固定打默认槽的 baseUrl/token/principal。' +
+                '整条链转 keyed 之前,非默认槽要重开请自带 deliverDecision(按本槽投递);' +
+                '此处拒绝而不是照发 —— 照发会把这条会话的决断发到另一个槽上。');
+            return receiptMs === undefined ? { reopened: false } : Promise.resolve({ reopened: false });
+        }
         const canonicalId = planReviewQuestionId(taskId);
         // 先查(firstSight)后记 —— 顺序决定判决正确性;台账按 sessionKey 分账,键 = **当代** plan 键
         // (A-024.4 分代:0 代与 canonical 字节同形,决断消费后落新代 —— 恒定键会对同 run 的下一只

package/dist/seam.d.ts

@@ -389,7 +389,47 @@ export type ChromeEvent = {
  * `actor.hostAsserted` 是消费端唯一能判「这个署名可信吗」的位:渲署名而不渲这个位 = 把一个
  * 未经验证的名字渲成可信的(core 自己的 `[from …]` 渲染就是靠它决定加不加 `(unverified)`)。
  */
- | HumanInputChromeEvent | EngineNoticeChromeEvent;
+ | HumanInputChromeEvent | EngineNoticeChromeEvent | TextSegmentEndChromeEvent;
+/**
+ * {@link ChromeEvent} 的 `text_segment_end` 臂(#323 / core #447,core ≥5.63 / server ≥7.50)——
+ * 「**assistant 的这一段散文写完了**」,由引擎明说,不是由本包猜。
+ *
+ * ── 它替代的是什么 ──────────────────────────────────────────────────────────────────────────
+ * 本包的 `adapt/textStream.ts` 至今用**启发式**猜段边界:静默 ≥1.5s + 段尾是句末/段末字符 +
+ * 每段至多一刀(`takeAnswerSegmentOnIdle`,#323 症状① 的止血件)。那是猜 —— 慢模型的一次卡顿会
+ * 被当成段结束,一轮回复被切成 N 条 assistant 消息。本臂是**引擎报的真边界**:模型关掉了那个
+ * text content block。CC 对位:CC 在 provider 的 `content_block_stop` 上把每个写完的块当作一条
+ * 独立 assistant 消息 —— 块结束**就是**分段信号,本臂把同一个边界搬到了 wire 上。
+ *
+ * 🔴 **宿主消费义务**(全部可选、fail-soft;本臂存在的第一价值 = 边界信号不再落 `unknown_arm`):
+ *  ① **它是信号,不是内容**。`content` = 那一段的**权威全文**,而这些字节**已经**以 `stream_delta`
+ *     活体增量流过、并且会由 transcript 平面的 assistant 消息给出 committed 形。
+ *     🔴 拿 `content` 再渲一行 = **同一段文字上屏两遍**。它的正当用途是**对账**(用引擎的权威全文
+ *     校/换掉自己缝合出来的那一段)与**定界**(现在可以提交这一段了)。
+ *  ② **诚实缺席,不可反推**(core 臂注逐字):只有会报块结束的 Brain 才发它 —— 三个一方 brain 都发,
+ *     自定义 brain 可能整条流一帧都没有。⇒ 缺席 = 「**没报**」,**永远不等于**「这一段没结束」。
+ *     消费方按**每条流**判「这条流带不带边界帧」,只在整条流一帧都没有时才回落自己的启发式;
+ *     按**单帧**缺席就回落 = 把「这一拍还没到边界」误当「引擎不支持」。
+ *  ③ **空段无帧**:引擎只为**有字节**的段发帧(空 text block 静默关闭)—— 所以宿主永远不会收到
+ *     空 `content`,收到了也不该提交一个幻影段(本包投影层已按 `empty_payload` 拦下)。
+ *  ④ 🔴 **子流让位**:带 `parentToolCallId` 的段边界属于子代/编排流,拿它去提交 leader 的段就是
+ *     跨 lane 状态破坏(与 `stream_delta` 的 thinking 半场、`retry_status` 同一条纪律)。所以本臂
+ *     在库内**已经断闸** —— 子流的段边界**根本不产出本 chrome 事件**,本臂因此没有
+ *     `parentToolCallId` 位(有位才是可疑的:那意味着 leader 面上会出现别人的边界)。
+ *     要消费子流边界的宿主读 SDKMessage 平面的 `text_end` 内部臂,那一层原样带 `parentToolCallId`。
+ *
+ * ⚠️ **UNTRUSTED、仅展示**:`content` 是模型输出,契约与活体增量同 —— 渲染,绝不回喂模型。
+ * 📋 如实留白:本包的 `takeAnswerSegmentOnIdle` 启发式**本批不撤**(撤它要按 ② 做一条 per-stream
+ *    的状态化策略,属行为面改动,按宪法三问单独走)。本批只把边界送到宿主手上。
+ */
+export interface TextSegmentEndChromeEvent {
+    kind: 'text_segment_end';
+    laneProof: LaneProof;
+    /** 该段的**权威全文**(与那一段活体增量的拼接逐字节相等)。🔴 对账/定界用,别拿它再渲一行。 */
+    content: string;
+    /** core 铸的事件身份(uuidv7 形);wire 未必带 ⇒ 缺席时本键不在场。 */
+    eventId?: string;
+}
 /**
  * {@link ChromeEvent} 的 `engine_notice` 臂(#310 / #318 件①,server ≥7.36;契约 = server
  * `ASSISTANT-WIRE-CONTRACT` 附录 D)——「**引擎想让这条会话的人知道一件事**」。

package/dist/seam.js

@@ -48,6 +48,10 @@ const CHROME_ARM_TABLE = {
         required: false,
         duty: '可选:渲引擎通告(按 code+detail,message 仅 fallback;未知 code 也必须渲不许丢;durable 重放按 eventId 幂等;harvest 的 moved/escalated 并列呈现绝不相减)',
     },
+    text_segment_end: {
+        required: false,
+        duty: '可选:引擎明报的 assistant 散文段边界(#323/core #447)。🔴 content 是对账/定界用的权威全文,拿它再渲一行 = 同一段上屏两遍;缺席只表示「没报」,绝不等于「段没结束」——要退回自家启发式必须按整条流判、不按单帧判',
+    },
 };
 /**
  * chrome 臂**覆盖率断言出口**(§8-1 裁决的一半:client-core 定接口不定实现)。