@sema-agent/client-core 0.53.0 → 0.54.0

package/CHANGELOG.md

@@ -13,7 +13,7 @@
 > 不在账上,都红。**发包批的义务** = 往 `FROZEN` **追加**一行(版本号 + 发布 commit + 段 sha256),
 > **绝不改写既有行** —— 既有行是「那一版当时发了什么」的历史,不是可变配置。
 >
-> 🔴 **阶段一段头义务(0.48.0 勘误后写死,防第三例)**:发布 commit(阶段一)必须**同批**把
+> 🔴 **阶段一段头义务(0.48.0 勘误后写死;0.53.0 第三例后由 ④a0 机械执行)**:发布 commit(阶段一)必须**同批**把
 > `## <version>(未发布)` 段头转成日期形 `## <version>(YYYY-MM-DD)`(0.47.0 先例)。发布后该段
 > 字节即被 ④ 门逐字锁定,漏转**不可回改**、只能永久勘误 —— 0.36.0 与 0.48.0 两条勘误的共同根因
 > 就是这一步没做;此前头注只写了「未发的进 `(未发布)` 段」而没写「发布时转正」,歧义已由本句消除。
@@ -39,6 +39,91 @@
 > publish 后才发现。该段字节已被 ④a 逐字锁定在 `4fae01b` 上 ⇒ 标题**不回改、且永远不会被改**;
 > 门侧窄豁免同批登记(`KNOWN_HEADING_ERRATA` `version: '0.48.0', releasedAt: '4fae01b'`),
 > 与本段互钉,均为永久记录。
+>
+> 🔴 **勘误(0.53.0 发包批,2026-09-04,永久记录 —— 同案第三例,机理同上)**:`## 0.53.0` 段标题的
+> `(未发布)` 是发布批的操作失误 —— 0.53.0 **已经发布**(releasedAt=npm gitHead `2a159e3`,registry
+> 在架,dist.shasum eb59fb2c…),阶段一 commit 应当把段头转正为日期形而没转(施工车按「本批不发包」
+> 写了 `(未发布)`,主收货把「发布即钉死字节」这一格漏了)。该段字节已被 ④a 逐字锁定在 `2a159e3` 上 ⇒
+> 标题**不回改、且永远不会被改**;门侧窄豁免同批登记(`KNOWN_HEADING_ERRATA` `version: '0.53.0',
+> releasedAt: '2a159e3'`),与本段互钉,均为永久记录。**第三例之后的根治**:头注义务只是文字,三次都没
+> 挡住 ⇒ 本批把它机械化——④a0 对 `pending` 行**要求段头已是日期形**(`(未发布)` 直接红),阶段一
+> commit 漏转在发布前就红,不再靠人记。
+
+## 0.54.0(2026-09-05)
+
+### design/385 —— 三条引擎注入车道的类型化投影(`src/peerFrames.ts`;cli L-61② / L-87 5a①5a②)
+
+引擎把三类**根本不是同一种东西**的载荷塞进同一条 `task_notification` 车道,而 core 对这三类
+**不套** `<task-notification>` 壳(`renderTaskNotificationXml` 头三个分支):
+
+| 载体键 | 出处 | 模型面 |
+|---|---|---|
+| `agentMessage` | §1.4 d1,同进程子代 `SendMessage("main")` uplink | `<agent-message from="…">` |
+| `crossSessionMessage` | §4.1,另一个会话的消息从本会话信箱 drain | `<cross-session-message from="…" …>` |
+| `crossSessionNotice` | §4.4/§5.2,**本会话自己发出去**那条消息的回执 / idle 通知 | 一行纯文本 |
+
+端此前照泛化卡渲 ⇒ 用户看到「后台任务完成」卡,而模型读到的是一条同事发来的话:**两个面说的
+不是同一件事**。本批把判定与编解码整只收进包:
+
+- `classifyPeerNotification(rawPayload)` —— 三分投影,认不出返 `null`(= 泛化卡,调用方零改动)。
+  🔴 判别位是**类型化载体的在场**,永远不是 `summary` 文本:三条载体只有引擎注入腿铸得出
+  (`ExternalNotificationInput` 是 `TaskNotificationPayload` 的真子集,外部 `notify()` 一个都穿不上),
+  而 `summary`/`result` 是任何一条通知都填的字段 —— 锚文本 = 任何后台任务把
+  `<agent-message from="…">` 写进 summary 就能冒充一条同事消息。
+- **fail-closed 分两档**:必填位(`from` 空 / `body` 非串 / notice `kind` 不在闭集)⇒ 整帧退泛化卡
+  (诚实降级,用户仍看得见);可选位形不合(`fromMode` 写了闭集外的词)⇒ **只丢那一位**。
+- `_sema_provenance` **必须在场且 `kind` 与车道相符**(异源对抗复审 [high] 翻面):首版写的
+  「缺席放行」理由是「要求在场会让另两条车道在老引擎上恒死」,**该理由被证伪** —— 老引擎上那两条
+  车道连载体键都没有、判定根本走不到,而 core 契约明写 provenance「present exactly when the carrier
+  is」,在跑的 7.2.0 就是同一处同时铸两者。要求在场对真载荷零代价,对畸形 / 半截注入 / 版本漂移则
+  关上一道门(否则只凭 `from`+`body` 两个字符串就能让屏上出现一张署着任意名字的消息卡)。
+  判据是**四条等式 + 在场**(`kind` + `from`/`taskId`/`seq` 三位**必须在场**且与载体、载荷逐一相等
+  —— core 的 `SemaProvenance` 把这三位全声明为必填,三个铸点也都同址写下,所以「两侧都缺」不是
+  合法兼容形而是半截载荷;首版只写 `a === b`,`undefined === undefined` 正好把它放行了):只核 `kind` 拦得住
+  半截载荷,拦不住**同 kind 的伪造** —— 载体署一个可信名字、provenance 三位全对不上,屏上照样出现
+  一条署着那个名字的消息。后三条各有**铸点直证**(uplink 腿与跨会话 drain 腿都在同一个对象字面量里
+  同值写下 `task_id`/`seq`/`from`),铸点一改由 cli 侧 wire 锚 A-K24 的同址探针当场喊红。
+  ⚠️ 载荷那一边是 snake `task_id`、provenance 那一边是 camel `taskId` —— 同一个量两个拼法,写混了
+  等式恒不成立、整条车道静默死掉(本模块首版真写混过一次,当场被门抓住)。
+- **通知臂的分支序修正**:三车道判定挪到**完成卡台账早退之前**。`isWorkflowCompletionCardEnqueued`
+  回答的是「这个 run 的**完成卡**是不是已经入过队」,与「这一帧是不是一条同事消息」无关;而子代
+  **续跑**时复用同一个 taskId,它的合法 `agentMessage` 帧就会在那道早退上被整条丢掉(零转录输出,
+  且渲染去重账已记过 ⇒ 重放也补不回来)。peer 帧豁免该早退;泛化完成通知照旧被它吞掉(反向钉在门里)。**同因第二件**:peer 帧也不再写
+  `markEngineWorkflowNotified` 那本「完成已通知」的跨通道账 —— 一条同事**消息**不是完成事件
+  (三条 peer 铸点的 `status` 都是 `"event"`),写脏了这本账,子代自己真正的空闲期完成通知随后会被
+  补发通道整条丢掉(修前实测:同 taskId 的补发入队恒 0)。
+- **拆火编码是单射**:`escapeEnvelopeTag` 连正文里**原本就有**的反斜杠一起数(`<` 后跟任意多个
+  反斜杠再跟标签名时都插一个),`unescape(escape(x)) === x` 对一切 x 成立。core 那一份是**单向**
+  消毒(模型读完就结束、没有反向腿),照抄到这里就是一个非单射映射:合法代码文本 `<\agent-message>`
+  会在往返之后被改写成真标签,既损坏正文又是一条注入路。
+- **解析腿三条硬边界**:信封必须整串锚定;正文里出现**未拆火**的同名标签 ⇒ 整条退 `null`
+  —— 贪婪匹配会把「两封拼一起」读成一封(正文合并、两位署名全记第一位头上)、把「信封 + 尾随
+  文本」读成一封(尾随文本静默消失)。退 `null` = 落回普通文本行,一个字节都不丢。
+- 优先序**照抄 core 渲染腿**(agentMessage → crossSessionMessage → crossSessionNotice):模型那一面
+  已经按这个顺序读过了,端另立一套顺序 ⇒ 屏上的卡与模型读到的帧对不上。
+- `renderPeerFrameTranscriptText` / `parsePeerFrameText` 两半**同源在包**:端的消息面(CC 血统:
+  按标签分派)只拿得到文本,两半不同源就会有人在端里再抄一份正则 —— cli-191 A-D1/A-D12 那一族的
+  成因就是这个。通知车道**刻意不进解析腿**(锚 `[Cross-session …]` 前缀会把用户随手打的同样一行
+  认成引擎通知),它本来就该按普通文本行渲(CC 形)。
+- `peerFrameDisplayName` —— 「@谁」的优先序(跨会话 `fromName` > `from`)也在包里,端不许自己排。
+- **发包前异源扫描三修(2026-09-05,三域 opus 扫描 + opus 反证,12 条 11 实证)**:①[high] 正文**权威信封标签拆火**
+  ——渲染腿此前只拆同名信封,漏了 core `neutralizePeerBody` 那一步:子代正文里一段 `<task-notification>…<status>completed</status>…`
+  会原样进转录 block,宿主 resume 时 `parseTranscriptNotificationSeeds` 把它读成真完成通知 ⇒ 去重台账被毒化、受害 run
+  的真完成通知被跨通道臂吞掉(dist 真跑实证);现按 core 同形对 8 个权威标签 `<` 后插 ZWSP,单向不还原;通知纯行同拆并拆两个
+  消息信封标签(整体形如信封的通知不再被端认成消息)。②[high] 属性长度非对称——渲染无界、解析封顶(from 400 / from-name 200)
+  ⇒ 包自己铸的帧解析回 null、用户看到裸 XML;解析改无界(线性匹配)。③[medium] 署名规范化——`from`/`fromName` 含换行/控制符
+  折成单行单空格,折空按缺席处置。文档同批勘误:README/门契约串/§17c 中「provenance 只否决不认证、缺席放行」为首版残句,
+  实现自定稿起即为「在场 + 四等式」;§0a 版本锚与 §1c 闭包棘轮数字刷新。
+
+**老宿主零差异**:三条载体一个都不在场的载荷(= 今天的全部载荷)走的分支与本批之前**逐字节等价**;
+`taskNotificationArm` 只换了转录行那一行的文本来源,去重键 / settle / 面板 / 台账一个都没动
+(它们判的是「哪个 task 的哪个状态」,与这条通知在模型面穿哪件外衣无关)。
+
+**新增常驻门**:`scripts/run-peer-frame-projection-test.mjs`(71 checks,含**适配器级**的两条台账回归)。
+
+**已知局限(本版新增)**:`crossSessionMessage` / `crossSessionNotice` 两条载体在 **core 7.2.0
+(= ENGINE_PIN 7.57.0 内嵌那一版)上零铸点** —— 本批是消费半场先落地,上游到货前这两条车道恒
+不触发。`agentMessage` 一条今天就到得了(core 7.2.0 `agents/send-message-tool.js` 直证)。
 
 ## 0.53.0(未发布)
 

package/README.md

@@ -35,7 +35,7 @@ Renamed from **`@sema-agent/wire-cc-adapter`** (0.1.x, deprecated — see *Migra
 
 ## Scope
 
-**Version:** 0.53.0
+**Version:** 0.54.0
 
 - **Today** — the adapter seam, the whole `adapt()` pipeline (all 14 A-layer arms plus the
   B/D/E tool-card layers), the notification/caps/model families, the adapter kernel (stream driver
@@ -263,6 +263,7 @@ public-surface guard checks that last one).
 | `scripts/run-terminal-identity-copy-test.mjs` | Terminal-state **identity**, in both lanes where a stop gets a name. A run stopped by this deployment's own governance knobs — the open-set `limits.*` family, `output.invalid`, and the `blocked` contract terminal a ReportBlocked agent produces — is not a provider failure, and labelling it `API Error:` sends the reader to check the network, the key and the quota when the handle is the `--max-turns` they passed themselves. Those terminals now render a neutral row; the reverse direction is guarded just as hard, because asserting "this is *not* an API error" on a code the package does not recognise is the same misfiling pointed the other way — a real `gateway HTTP 502`, a `conflict.session_active_run` and any unknown code all keep the `API Error:` prefix, and the row keeps its `isApiErrorMessage` class flag so brief-mode visibility filtering does not silently drop it. The second half is who the rejected submission belonged to: the self-heal copy told every caller "Your message was NOT sent … send it again", which is three separate untruths for a system injection (a plan-review outcome, a cron wake-up, a task notification) — not the user's message, and not re-sendable, since a host queue marks those non-editable and non-recallable. The injected form says so instead, and the one sentence that promises re-delivery is pinned to the single disposition that earns it: `selfHealSubmissionDisposition` is the same function the host consults before putting the item back on its queue, so the promise and the behaviour cannot drift apart, and the arms where no card could be surfaced state plainly that nothing was delivered and nothing will retry |
 | `scripts/run-additive-key-passthrough-test.mjs` | The one disease shape behind two legs: a **closed whitelist / flattening arm** dropping a fact that is already on the wire, while both sides of the seam look correct. (1) The `task_progress` projection carries a registered **key ledger** — a frame populated with every key the service really projects is pushed through the shipped `eventToSdkMessage`, and the set of wire keys that survive must equal the registered pass-through list **name for name in both directions**, so quietly forwarding one more key is as red as quietly dropping one. `model` (the child run's model id, minted by core as `prepared.model.id` and projected by the server since 7.52.1) is the key this batch adds, with the same conditional the server itself applies: a non-empty string or no key at all — an empty string is neither a model id nor "unknown". The ledger is also checked against the fenced list in `docs/INTEGRATION-CLIENTS.md` §3d, so a doc that still says seven keys while the code forwards eight is red rather than merely stale. (2) The decide-failure arms carry the server's S-02 `currentPending` pointer key from a 409 `approval_stale` refusal onto the outcome the host reads. The reader is structural rather than `instanceof`, because the client is host-injected and the class identity is not this package's to assume; a half triple never mints (half a pointer cannot relocate anything), an empty string is not presence, and `checkpointToken` never transits. Both the allow and the deny leg are driven end to end through the real durable approval path — as is the accept-session leg, where a refusal carrying the pointer key must now re-raise instead of silently re-sending the human's answer for the **old** card as a plain approve (one decide call, pointer preserved), while a legacy 400 still falls back exactly as before — and all three flattening points must call the one shared reader — the same-shape residue check that makes "fixed one arm and left the twin" red instead of invisible |
 | `scripts/run-esc-halt-plan-test.mjs` | The Esc stop decision every client shares: fire the **turn-level** halt first, and escalate to a **run-level** cancel in exactly two cases — the engine itself answered with a 409 from the closed code set (it is saying "there is no in-flight turn here; use cancel for a run-level stop"), or that shot came back with no verdict at all *and* the shell can independently prove a permission card was on screen. Everything else does not escalate. The asymmetry is the whole point and every negative control guards the same direction — deciding *not* to escalate costs the user one more choice on a busy-session card (recoverable), deciding to escalate wrongly tears down a run that was alive and takes every in-flight tool with it (not). So: the closed code set is a **frozen** value, not a `ReadonlySet` — type-level immutability does not stop a consumer's `.add()`, and the guard proves it by really trying to mutate the exported value and then checking the verdict did not drift; the escalation gate is the **conjunction** of that closed set and the 409 status, since honouring the code alone lets a 500 that merely quotes it drive a destructive call; `interrupt.not_held` and `steering.not_running` are deliberately outside the set (the first means *this replica* has no live face — the run may be perfectly alive on another); an unreadable code falls to the no-escalation side; a `parked` flag never overrides a verdict the engine did give, and only strict `true` counts when it did not. The first shot is unconditional by construction — it does not consult `parked`, because the 409 it earns is exactly the verdict the gate wants — and the verdict itself is a closed machine-readable reason word, not display copy |
+| `scripts/run-peer-frame-projection-test.mjs` | The three engine-injected lanes design/385 puts on the **one** `task_notification` carrier, which are not the same kind of thing at all: a delegated child's uplink (`agentMessage`), another session's message drained from this session's own box (`crossSessionMessage`), and a receipt about one of *this* session's own outbound messages (`crossSessionNotice`). The engine renders none of them inside a `<task-notification>` shell, so a client that projects them as the generic completion card shows "background task finished" while the model read a colleague's sentence — two faces describing different events. The discriminator is pinned to the **typed carrier being present**, never to the `summary` text: those carriers can only be minted by the engine's injection legs (the external `notify()` input is a strict subset of the payload and can wear none of them), while `summary` is filled by every notification there is — so anchoring on text would let any background task impersonate a colleague's message by writing `<agent-message from="…">` into its own summary, and a positive control asserts exactly that payload still projects as the generic card. Fail-closed has two tiers rather than one: a broken **required** field (empty `from`, a non-string `body`, a notice `kind` outside the closed set) returns absence so the caller falls back to the generic card — an honest downgrade where the user still sees the notification — while a broken **optional** field drops only itself, because losing an attribution note and losing a colleague's whole message are not the same magnitude. The provenance side record is **required and must agree on four points** (`kind` matches the lane; `from`/`taskId`/`seq` are present and equal the carrier/payload — each equality is anchored on a core mint site and pinned by the cli wire-anchor A-K24), so a carrier signed with a trusted name but a disagreeing provenance falls back to the generic card; peer bodies pass the same authority-envelope neutralization core applies (`<task-notification>` etc. are defused) so a colleague's text can never seed the resume dedup ledger. Lane precedence copies the engine renderer's own order, because the model already read the frame in that order and a client ordering of its own would put a card on screen that disagrees with the frame the model saw. Rendering and parsing of the transcript line live in the same module and are round-tripped in both directions, including a body carrying a forged closing tag (a parser fooled there hands half a message to the next row) and a quote inside the sender label (which must not forge a second attribute); the notice lane is deliberately kept **out** of the parser, since recognising it would mean anchoring the `[Cross-session …]` prefix and a user typing that same line would be rendered as engine speech. Hostile carriers are read as own **data** descriptors only and accessors are never invoked at all — `catch` catches throwing, not never returning — proven by a counting getter that must stay at zero calls, alongside a revoked proxy and a prototype-only carrier; and four legacy payload shapes assert the no-carrier path is byte-identical to before, which is the executable form of "zero difference for an older host" |
 
 Each suite carries a floor that only moves up — a refactor that stops executing a group of
 assertions is a failure, not a quieter pass. Guards anchor on the **installed artefact's content**

package/dist/adapt/arms.js

@@ -1,3 +1,4 @@
+import { classifyPeerNotification, renderPeerFrameTranscriptText } from '../peerFrames.js';
 import { dropQueuedNotificationsForRun, isEngineWorkflowNotified, isWorkflowCompletionCardEnqueued, markEngineWorkflowNotified, normalizeTaskNotification, noteWorkflowCompletionCardEnqueued, renderTaskNotificationXml, taskNotificationDedupKey } from '../notifications.js';
 import { mapBrainStatusToRetry } from '../retryStatus.js';
 import { steeringInjectedToAttachments } from '../steering.js';
@@ -676,19 +677,46 @@ const taskNotificationArm = function* (m, { ctx, idOf, panel, inst }) {
             yield* panel.settleFromNotification(taskId, rawStatus !== 'completed');
         }
     }
+    // ── design/385:三条引擎注入车道的判定**必须在下面那道完成卡早退之前**做 ────────────────
+    // 🔴 异源对抗复审 r2 [high] 实测的吞消息形:`isWorkflowCompletionCardEnqueued(taskId)` 回答的是
+    //    「这个 run 的**完成卡**是不是已经入过队」,与「这一帧是不是一条同事消息」毫无关系。而一个
+    //    子代**续跑**时复用同一个 taskId(`_sema_provenance.taskId === task_id === senderId`,core
+    //    7.2.0 uplink 铸点直证),它的合法 `agentMessage` 帧就会在这道早退上被整条丢掉:零转录输出,
+    //    且渲染去重账已经记过 ⇒ 重放也补不回来。复现序:先 `noteWorkflowCompletionCardEnqueued(id)`,
+    //    再送同 id 的 uplink 帧 ⇒ 修前只剩 chrome 收尾事件、消息正文完全缺席。
+    //    ⇒ peer 帧**豁免**这道早退(它不是完成卡,不参与完成卡的双通道去重)。
+    const peerFrame = classifyPeerNotification(n);
     // 双通道反向去重:probe 合成的完成卡已入队 ⇒ 后到的推送帧只做上面的记账,不渲第二条。
     // 🔴 B5 ①:读的是 **module 台账**(cli `isWorkflowCompletionCardEnqueued` 逐字)——
     //   记账方(两个 enqueue + idle watcher)与清账方(上面的 drop)都在那儿。
-    if (n.task_type !== 'external' && isWorkflowCompletionCardEnqueued(taskId))
+    if (peerFrame === null && n.task_type !== 'external' && isWorkflowCompletionCardEnqueued(taskId))
         return;
     // 跨通道记账(cli markEngineWorkflowNotified 同位、同条件:非 external,不看终态):
     // 这帧到达 = 引擎已 server-side steer-inject 过,补发通道(workflow_complete)不得再注入。
     // external 豁免([769] 对抗复审收紧:external 从不经补发通道,mark 只会缴械 probe 兜底)。
-    if (n.task_type !== 'external')
+    // 🔴 **peer 帧同样豁免**(异源对抗复审 r3 [high],实测:投一条合法 uplink 之后再给同 taskId 入队
+    //    `{status:'completed'}`,队列恒 0、`bgCrossChannelDropped` +1)。这本账问的是「这个 run 的
+    //    **完成**是不是已经被引擎注入过」——而一条同事**消息**不是完成事件(三条 peer 铸点的
+    //    `status` 都是 `"event"`,core 直证)。子代跑到一半发了句话就把这本账写脏,它自己真正的
+    //    空闲期完成通知随后被补发通道整条丢掉,用户只能等下一次开流才可能看见。
+    if (peerFrame === null && n.task_type !== 'external')
         markEngineWorkflowNotified(taskId);
+    // 判定单源 = `classifyPeerNotification`(载体在场判别,绝不锚 summary 文本);认不出 ⇒ `null`
+    // ⇒ 这一行与本臂此前**逐字节等价**(三条载体一个都不在场的载荷 = 今天的全部载荷,老宿主零差异)。
+    // 🔴 除上面那道完成卡早退之外,其余账**全不动**:去重键 / settle / 面板 / 跨通道 mark 判的是
+    //    「哪个 task 的哪个状态」,与这条通知在模型面穿哪件外衣无关,跟着换会把几条独立的账搅成一本。
+    //    (uplink 帧的 `status` 是 `"event"` —— core 7.2.0 铸点直证 ⇒ 终态那几条腿本来就不会对它开火。)
     yield transcript({
         type: 'user',
-        message: { role: 'user', content: [{ type: 'text', text: renderTaskNotificationXml(fields) }] },
+        message: {
+            role: 'user',
+            content: [
+                {
+                    type: 'text',
+                    text: peerFrame !== null ? renderPeerFrameTranscriptText(peerFrame) : renderTaskNotificationXml(fields),
+                },
+            ],
+        },
         uuid: idOf(m),
         session_id: ctx.sessionId,
     }, ctx.now());

package/dist/index.d.ts

@@ -135,6 +135,7 @@
 export * from './seam.js';
 export * from './workflow.js';
 export * from './notifications.js';
+export * from './peerFrames.js';
 export * from './steering.js';
 export * from './diagnostics.js';
 export * from './retryStatus.js';

package/dist/index.js

@@ -135,6 +135,13 @@
 export * from './seam.js';
 export * from './workflow.js';
 export * from './notifications.js';
+// ── design/385(0.54.0):三条引擎注入车道的类型化投影 + 转录行文本编解码 ────────────────────
+// 收在库里的理由:① 判别位是**类型化载体的在场**(agentMessage / crossSessionMessage /
+// crossSessionNotice),端若各自判就会有人拿 `summary` 文本判 —— 那条路上任何后台任务都能把
+// `<agent-message from="…">` 写进 summary 冒充一条同事消息;② 端的消息面只拿得到**文本**,
+// 所以「帧→文本」与「文本→帧」两半必须同源在包里,端才做得到零字符串判定(cli-191 A-D1/A-D12
+// 那一族的成因正是消费端各自抄一份判据)。
+export * from './peerFrames.js';
 export * from './steering.js';
 export * from './diagnostics.js';
 export * from './retryStatus.js';

package/dist/peerFrames.d.ts

@@ -0,0 +1,117 @@
+/**
+ * peerFrames.ts — design/385 的三条**引擎注入帧**在客户端的类型化投影(判定单源在包,端只装配)。
+ *
+ * ── 这一件守的是什么 ────────────────────────────────────────────────────────────────
+ * 引擎把三类东西塞进 **同一条** `task_notification` 车道,而它们在模型面根本不是同一种东西
+ * (core `renderTaskNotificationXml` 对这三类**不套** `<task-notification>` 壳):
+ *   · `agentMessage`         同进程子代 → 父会话的 uplink(`SendMessage("main")`,§1.4 d1);
+ *   · `crossSessionMessage`  另一个会话的消息,从本会话自己的信箱里 drain 出来(§4.1);
+ *   · `crossSessionNotice`   关于**本会话自己发出去的**那条消息的回执 / idle 通知(§4.4 / §5.2)。
+ * 端如果照 `task_notification` 泛化卡去渲,用户看到的是一张「后台任务完成」卡,而模型读到的是
+ * 一条同事发来的话 —— 两个面说的不是同一件事。
+ *
+ * 🔴 **判别位是类型化载体的在场,永远不是 `summary` 文本**。这三条载体只有引擎的注入腿铸得出
+ *    (`ExternalNotificationInput` 是 `TaskNotificationPayload` 的**真子集**,外部 `notify()` 一个
+ *    都穿不上);而 `summary`/`result` 是任何一条通知都填的字段,拿它做判据 = 任何一个后台任务
+ *    只要把 `<agent-message from="…">` 写进 summary 就能冒充一条同事消息。
+ *
+ * 🔴 **身份三条等式**:`_sema_provenance` 必须在场、`kind` 与车道相符,且 `from`/`taskId`/`seq`
+ *    与载体和载荷逐一相等(三条都由 core 铸点直证,见 `provenanceAgrees`)。只核 `kind` 拦得住
+ *    半截载荷,拦不住**同 kind 的伪造**——载体署一个可信名字、provenance 三位全不对,屏上照样
+ *    出现一条署着那个名字的消息。
+ *
+ * 🔴 **fail-closed**:载体在场但形不合(`from` 空、`body` 非串、notice 的 `kind` 不在闭集里)⇒
+ *    返回 `null` = 退回泛化卡。退回泛化卡是**诚实降级**(用户仍看得见这条通知,只是没有专用形);
+ *    而放一个半截形出去,端就会拿 `undefined` 去渲一张署名为空的「来自 @undefined 的消息」卡。
+ *
+ * 🔴 **优先序照抄 core 的渲染腿**(`agentMessage` → `crossSessionMessage` → `crossSessionNotice`)。
+ *    多载体同时在场是矛盾载荷,但**模型那一面已经按 core 的顺序读过了** —— 端按同一个顺序判,
+ *    两个面才说同一件事;这里另立一套「矛盾就退泛化」会让屏上那张卡与模型读到的帧对不上。
+ *
+ * ── 为什么渲染/解析两半都在包里 ─────────────────────────────────────────────────────
+ * 端的消息面(CC 血统:`UserTextMessage` 按标签分派)拿到的只有**文本**,没有帧。所以包必须同时
+ * 给出「帧 → 文本」与「文本 → 帧」两半,且**同源**(同一组标签常量、同一套属性序),端才可能
+ * 做到零字符串判定。两半的往返在常驻门里逐形对拍。
+ *
+ * ── 与上游的锚 ──────────────────────────────────────────────────────────────────────
+ * 两个标签字面量是 core 的铸点镜像(`core/task-notification.js::AGENT_MESSAGE_TAG` /
+ * `agents/cross-session-envelope.js::CROSS_SESSION_MESSAGE_TAG`),登记在壳的 wire 锚契约表里
+ * (cli `scripts/wire-anchor-registry.mjs`)—— core 改词当天那道门就红,而不是等到用户发现
+ * 「同事消息又变回一张后台任务卡了」。
+ */
+/** core `core/task-notification.ts::AGENT_MESSAGE_TAG` 的镜像(同进程 uplink 的模型面标签)。 */
+export declare const AGENT_MESSAGE_TAG = "agent-message";
+/** core `agents/cross-session-envelope.ts::CROSS_SESSION_MESSAGE_TAG` 的镜像(跨会话信封标签)。 */
+export declare const CROSS_SESSION_MESSAGE_TAG = "cross-session-message";
+/** core `_sema_provenance.kind` 的闭集(7.4.0 三员;7.2.0 只有第一员 —— 缺员按「上游还没发」处理,
+ *  不是「上游改词」:本模块从不要求 provenance 在场,只要求**在场时不自相矛盾**)。 */
+export declare const PEER_FRAME_LANES: readonly ["agent_message", "cross_session_message", "cross_session_notice"];
+export type PeerFrameLane = (typeof PEER_FRAME_LANES)[number];
+/** core `crossSessionNotice.kind` 的闭集(§4.4:投递回执 / idle 回执两形)。 */
+export declare const CROSS_SESSION_NOTICE_KINDS: readonly ["delivery_notice", "idle_notice"];
+export type CrossSessionNoticeKind = (typeof CROSS_SESSION_NOTICE_KINDS)[number];
+/** core `PermissionModeClass`(发送方**自述**的权限模式类,不是被证实的事实)。 */
+export declare const PEER_MODE_CLASSES: readonly ["bypass", "prompting"];
+export type PeerModeClass = (typeof PEER_MODE_CLASSES)[number];
+export type AgentMessageFrame = {
+    lane: 'agent_message';
+    /** 帧的 `from="…"` 属性所拼的那个署名(子代的名字 / 标签)。 */
+    from: string;
+    body: string;
+    agentType?: string;
+    /** 生产者的 per-frame 计数器(= 本 payload 的 `seq`);缺席不补 0。 */
+    seq?: number;
+};
+export type CrossSessionMessageFrame = {
+    lane: 'cross_session_message';
+    /** 发送方的**地址**(可回信的那一个;§4.1 provenance 的 `from` 同值)。 */
+    from: string;
+    body: string;
+    fromSession?: string;
+    fromName?: string;
+    fromMode?: PeerModeClass;
+    fromScope?: string;
+    seq?: number;
+};
+export type CrossSessionNoticeFrame = {
+    lane: 'cross_session_notice';
+    kind: CrossSessionNoticeKind;
+    /** 引擎自铸的整行文本(`[Cross-session delivery notice] …` / `[Cross-session idle notice] …`)。
+     *  🔴 端**原样渲一行**:这行是引擎按类型化 `peerMeta.notice` 铸的,端再解析一遍就是拿散文当数据。 */
+    text: string;
+};
+export type PeerFrameProjection = AgentMessageFrame | CrossSessionMessageFrame | CrossSessionNoticeFrame;
+/**
+ * `task_notification` 原始 wire 载荷 → 三条引擎注入车道之一;认不出 ⇒ `null`(= 泛化通知,
+ * 调用方照旧走 `normalizeTaskNotification` / `renderTaskNotificationXml`)。
+ *
+ * 入参是**原始**载荷(snake_case `task_id` 那一份),不是 `normalizeTaskNotification` 的产物 ——
+ * 后者是一张 15 键白名单,这三条载体一个都不在里面。
+ */
+export declare function classifyPeerNotification(n: Record<string, unknown>): PeerFrameProjection | null;
+/**
+ * core `ENGINE_AUTHORITY_ENVELOPE_TAGS` 的镜像(`core/untrusted-text.ts::ENGINE_ENVELOPES` 里 kind="authority" 的标签):
+ * 这些信封在模型面/转录面代表**引擎权威**,一段同事正文里出现它们就是伪造。core 的 `neutralizePeerBody`
+ * (= `sanitizeUntrustedText(body, PEER_BODY_ENVELOPE_TAGS)`)在渲染信封**之前**先把它们拆火(`<` 后插 ZWSP),
+ * 本模块首版只抄了后一步(同名信封拆火)——异源发包扫描 [high] 实证:子代正文里一段
+ * `<task-notification><task-id>victim</task-id><status>completed</status>…` 会原样进转录 block,
+ * 宿主 resume 时 `parseTranscriptNotificationSeeds` 把它读成真完成通知 ⇒ 去重台账被毒化,受害 run 的
+ * 真完成通知随后被跨通道臂整条吞掉。这里补上那一步,并与 core 同形(`<\s*\/?\s*(tag)(\s[^>]*)?>` 全大小写)。
+ * 🔴 单向(与 core 一致):端的解析腿**不**还原 ZWSP —— 拆掉的权威标签就该永远是拆掉的。
+ */
+export declare const AUTHORITY_ENVELOPE_TAGS: readonly ["system-reminder", "task-notification", "new-diagnostics", "user_memory", "scope", "skills", "total_tokens", "instruction-files"];
+/**
+ * 投影 → 转录行文本(端的消息面按标签分派的那一份)。
+ *
+ * 🔴 这**不是** core 模型面信封的逐字副本,也不该是:core 那一份是给**模型**读的(带纪律块、
+ *    带 CC 逐字属性语法、带 round-trip 拒收);这一份是**端的转录回显**,只需要与本模块的解析腿
+ *    往返一致。刻意不复刻 core 的语法契约 —— 复刻一份对不上的副本比不复刻更坏
+ *    (它会让人以为端这一行是模型读到的那一行)。属性序仍照 core 的规范序排,便于人肉比对。
+ */
+export declare function renderPeerFrameTranscriptText(p: PeerFrameProjection): string;
+export declare function parsePeerFrameText(text: string): AgentMessageFrame | CrossSessionMessageFrame | null;
+/**
+ * 端渲「@谁」时该用的那个名字 —— 判定在包,端不许自己排优先序。
+ * 跨会话:`fromName`(人取的名)优先于 `from`(地址);同进程:只有 `from`。
+ */
+export declare function peerFrameDisplayName(p: AgentMessageFrame | CrossSessionMessageFrame): string;

package/dist/peerFrames.js

@@ -0,0 +1,369 @@
+/**
+ * peerFrames.ts — design/385 的三条**引擎注入帧**在客户端的类型化投影(判定单源在包,端只装配)。
+ *
+ * ── 这一件守的是什么 ────────────────────────────────────────────────────────────────
+ * 引擎把三类东西塞进 **同一条** `task_notification` 车道,而它们在模型面根本不是同一种东西
+ * (core `renderTaskNotificationXml` 对这三类**不套** `<task-notification>` 壳):
+ *   · `agentMessage`         同进程子代 → 父会话的 uplink(`SendMessage("main")`,§1.4 d1);
+ *   · `crossSessionMessage`  另一个会话的消息,从本会话自己的信箱里 drain 出来(§4.1);
+ *   · `crossSessionNotice`   关于**本会话自己发出去的**那条消息的回执 / idle 通知(§4.4 / §5.2)。
+ * 端如果照 `task_notification` 泛化卡去渲,用户看到的是一张「后台任务完成」卡,而模型读到的是
+ * 一条同事发来的话 —— 两个面说的不是同一件事。
+ *
+ * 🔴 **判别位是类型化载体的在场,永远不是 `summary` 文本**。这三条载体只有引擎的注入腿铸得出
+ *    (`ExternalNotificationInput` 是 `TaskNotificationPayload` 的**真子集**,外部 `notify()` 一个
+ *    都穿不上);而 `summary`/`result` 是任何一条通知都填的字段,拿它做判据 = 任何一个后台任务
+ *    只要把 `<agent-message from="…">` 写进 summary 就能冒充一条同事消息。
+ *
+ * 🔴 **身份三条等式**:`_sema_provenance` 必须在场、`kind` 与车道相符,且 `from`/`taskId`/`seq`
+ *    与载体和载荷逐一相等(三条都由 core 铸点直证,见 `provenanceAgrees`)。只核 `kind` 拦得住
+ *    半截载荷,拦不住**同 kind 的伪造**——载体署一个可信名字、provenance 三位全不对,屏上照样
+ *    出现一条署着那个名字的消息。
+ *
+ * 🔴 **fail-closed**:载体在场但形不合(`from` 空、`body` 非串、notice 的 `kind` 不在闭集里)⇒
+ *    返回 `null` = 退回泛化卡。退回泛化卡是**诚实降级**(用户仍看得见这条通知,只是没有专用形);
+ *    而放一个半截形出去,端就会拿 `undefined` 去渲一张署名为空的「来自 @undefined 的消息」卡。
+ *
+ * 🔴 **优先序照抄 core 的渲染腿**(`agentMessage` → `crossSessionMessage` → `crossSessionNotice`)。
+ *    多载体同时在场是矛盾载荷,但**模型那一面已经按 core 的顺序读过了** —— 端按同一个顺序判,
+ *    两个面才说同一件事;这里另立一套「矛盾就退泛化」会让屏上那张卡与模型读到的帧对不上。
+ *
+ * ── 为什么渲染/解析两半都在包里 ─────────────────────────────────────────────────────
+ * 端的消息面(CC 血统:`UserTextMessage` 按标签分派)拿到的只有**文本**,没有帧。所以包必须同时
+ * 给出「帧 → 文本」与「文本 → 帧」两半,且**同源**(同一组标签常量、同一套属性序),端才可能
+ * 做到零字符串判定。两半的往返在常驻门里逐形对拍。
+ *
+ * ── 与上游的锚 ──────────────────────────────────────────────────────────────────────
+ * 两个标签字面量是 core 的铸点镜像(`core/task-notification.js::AGENT_MESSAGE_TAG` /
+ * `agents/cross-session-envelope.js::CROSS_SESSION_MESSAGE_TAG`),登记在壳的 wire 锚契约表里
+ * (cli `scripts/wire-anchor-registry.mjs`)—— core 改词当天那道门就红,而不是等到用户发现
+ * 「同事消息又变回一张后台任务卡了」。
+ */
+// ── wire 键名 / 属性名的单源(**刻意放在本文件第一个 `export` 之前**)────────────────────────
+// 两个作用,第二个是被逼出来的:
+//   ① 键名单源 —— 读口与渲染口用同一个字节,不给手抄留缝;
+//   ② 绕开 client-core 闭包扫描器的一处误匹配:`run-client-core-portability-test.mjs` 的
+//      `import/export … from '…'` 边扫描按 `from` + 引号这个**字节序列**认依赖,于是源码里任何
+//      一个 `'from'` 字面量(本模块读的正是 wire 上那个 `from` 键)都会被当成一条外部包依赖,
+//      把「A 层闭包外部包 === {diff}」判红。扫描器的锚起点是**行首的 `export`**,所以键名收在
+//      首个 export 之前就落在它的射程外。⚠️ 这是绕过一处**扫描器误报**,不是绕过判据本身 ——
+//      本模块真实的外部依赖是零(纯叶,零 import)。
+const WIRE_KEY_FROM = 'from';
+const WIRE_KEY_BODY = 'body';
+const WIRE_KEY_KIND = 'kind';
+const WIRE_KEY_TEXT = 'text';
+const WIRE_KEY_SEQ = 'seq';
+const WIRE_KEY_TASK_ID = 'task_id';
+/** 🔴 载荷那一边是 **snake** `task_id`,provenance 那一边是 **camel** `taskId` —— 同一个量、两个拼法,
+ *  写混了等式恒不成立、整条车道静默死掉(本模块首版就写混过一次,当场被门抓住)。 */
+const WIRE_KEY_PROV_TASK_ID = 'taskId';
+const WIRE_KEY_AGENT_TYPE = 'agentType';
+const WIRE_KEY_AGENT_MESSAGE = 'agentMessage';
+const WIRE_KEY_CROSS_SESSION_MESSAGE = 'crossSessionMessage';
+const WIRE_KEY_CROSS_SESSION_NOTICE = 'crossSessionNotice';
+const WIRE_KEY_PROVENANCE = '_sema_provenance';
+const WIRE_KEY_FROM_SESSION = 'fromSession';
+const WIRE_KEY_FROM_NAME = 'fromName';
+const WIRE_KEY_FROM_MODE = 'fromMode';
+const WIRE_KEY_FROM_SCOPE = 'fromScope';
+/** 信封上的 `from` 属性名(与上面的 wire 键同字节,渲染/解析两腿共用)。 */
+const FROM_ATTR = WIRE_KEY_FROM;
+/** core `core/task-notification.ts::AGENT_MESSAGE_TAG` 的镜像(同进程 uplink 的模型面标签)。 */
+export const AGENT_MESSAGE_TAG = 'agent-message';
+/** core `agents/cross-session-envelope.ts::CROSS_SESSION_MESSAGE_TAG` 的镜像(跨会话信封标签)。 */
+export const CROSS_SESSION_MESSAGE_TAG = 'cross-session-message';
+/** core `_sema_provenance.kind` 的闭集(7.4.0 三员;7.2.0 只有第一员 —— 缺员按「上游还没发」处理,
+ *  不是「上游改词」:本模块从不要求 provenance 在场,只要求**在场时不自相矛盾**)。 */
+export const PEER_FRAME_LANES = Object.freeze(['agent_message', 'cross_session_message', 'cross_session_notice']);
+/** core `crossSessionNotice.kind` 的闭集(§4.4:投递回执 / idle 回执两形)。 */
+export const CROSS_SESSION_NOTICE_KINDS = Object.freeze(['delivery_notice', 'idle_notice']);
+/** core `PermissionModeClass`(发送方**自述**的权限模式类,不是被证实的事实)。 */
+export const PEER_MODE_CLASSES = Object.freeze(['bypass', 'prompting']);
+// ── 防御式读口 ────────────────────────────────────────────────────────────────────────
+// 载荷是 wire JSON,正常路径上全是数据属性;但读一个 getter = 同步跑别人的代码,而
+// `try/catch` 接得住抛错、接不住「永不返回」。⇒ 只认自有**数据**描述符,访问器一律当缺席。
+function dataProp(o, key) {
+    if (o === null || typeof o !== 'object')
+        return undefined;
+    let d;
+    try {
+        d = Object.getOwnPropertyDescriptor(o, key);
+    }
+    catch {
+        // 已撤销的 Proxy / 敌意 trap:当缺席(读不出来 ≠ 有值)
+        return undefined;
+    }
+    if (d === undefined || !('value' in d))
+        return undefined;
+    return d.value;
+}
+function nonEmptyString(v) {
+    return typeof v === 'string' && v.length > 0 ? v : undefined;
+}
+function finiteNumber(v) {
+    return typeof v === 'number' && Number.isFinite(v) ? v : undefined;
+}
+/**
+ * `_sema_provenance` 的一致性判据 —— **必须在场、且 `kind` 与载体所属车道相符**。
+ *
+ * 🔴 首版写的是「只否决不认证、缺席放行」,理由是「core 7.2.0 的闭集只有一员,要求在场会让另外
+ *    两条车道在老引擎上恒死」。**那条理由是错的**(异源对抗复审 r1 [high] 证伪,当场采纳):
+ *    老引擎上另外两条车道**连载体键都不存在**,本函数根本走不到;而 core 契约明写 provenance
+ *    「present exactly when the carrier is」——今天在跑的那一版(7.2.0 `agents/send-message-tool.js`
+ *    的 uplink 腿)就是**同一处**同时铸载体与 provenance 的。所以要求它在场:
+ *      · 对**真**载荷零代价(真载荷从来都带着它);
+ *      · 对畸形/半截注入/版本漂移的载荷则关上了一道门 —— 否则只凭 `from`/`body` 两个字符串就能
+ *        让屏上出现一张署着任意名字的「来自某人的消息」卡,而那正是本模块存在的理由的反面。
+ *
+ * 判据 = **在场 + 四等式**(`kind` 与车道相符;`from`/`taskId`/`seq` 三位必须在场且与载体、载荷逐一相等,
+ * 见函数体内三条铸点直证)。首版曾写「判据只到 kind、刻意不比三位」——那一版的顾虑(上游编码差一格
+ * ⇒ 车道静默死)由 cli 侧 wire 锚 A-K24 的同址探针接管:铸点一改门先红,不会变成静默死。
+ */
+function provenanceAgrees(n, lane, carrierFrom) {
+    const prov = dataProp(n, WIRE_KEY_PROVENANCE);
+    if (prov === null || typeof prov !== 'object')
+        return false;
+    if (dataProp(prov, WIRE_KEY_KIND) !== lane)
+        return false;
+    // 🔴 三条等式**每一条都有铸点直证**(不是从散文里推的):
+    //    · uplink 腿(core 7.2.0 `dist/agents/send-message-tool.js`)一个对象字面量里同时写下
+    //      `task_id: senderId` / `seq: uplinkSeq` / `agentMessage:{from: senderLabel}` 与
+    //      `_sema_provenance:{from: senderLabel, taskId: senderId, seq: uplinkSeq}`;
+    //    · 跨会话 drain 腿(core 7.4.0 `agents/peer-session-drain.ts` 的两个 build*Payload)同形:
+    //      `task_id: boxHandle` / `seq: m.seq` 与 provenance 的 `taskId`/`seq` 同值,
+    //      消息臂的 `crossSessionMessage.from` 与 provenance 的 `from` 同为 `fields.from`。
+    //    ⇒ 三位不一致 = 这不是引擎那条腿铸出来的载荷。只核 `kind` 只拦得住半截载荷,拦不住
+    //      **同 kind 的伪造**:载体署一个可信的名字、provenance 三位全对不上,屏上照样出现一条
+    //      署着那个名字的消息(异源对抗复审 r2 [medium] 实测)。
+    //    🔴 铸点一改这三条就该跟着改 —— 由壳的 wire 锚 A-K24 同址探针钉住那一行字面量,
+    //      上游改词当天门就红,不会变成一条静默死掉的车道。
+    // 🔴 **在场也是判据的一半**(异源对抗复审 r3 [medium] 采纳):`SemaProvenance` 的 `from`/`taskId`/
+    //    `seq` 在 core 的类型面上**全是必填**,三个铸点也都同址写下它们 —— 所以「两侧都缺」不是一种
+    //    合法的兼容形,而是一个半截载荷。首版只写 `a === b`,于是 `undefined === undefined` 把它放行了
+    //    (实测:去掉两侧 seq、或去掉载荷的 task_id,半截载荷照样投影成一条 agent_message)。
+    //    ⇒ 先各自核在场与类型,再比值。
+    const provFrom = cleanName(dataProp(prov, WIRE_KEY_FROM));
+    if (provFrom === undefined || (carrierFrom !== undefined && provFrom !== carrierFrom))
+        return false;
+    const taskId = nonEmptyString(dataProp(n, WIRE_KEY_TASK_ID));
+    if (taskId === undefined || nonEmptyString(dataProp(prov, WIRE_KEY_PROV_TASK_ID)) !== taskId)
+        return false;
+    const seq = finiteNumber(dataProp(n, WIRE_KEY_SEQ));
+    return seq !== undefined && finiteNumber(dataProp(prov, WIRE_KEY_SEQ)) === seq;
+}
+/**
+ * `task_notification` 原始 wire 载荷 → 三条引擎注入车道之一;认不出 ⇒ `null`(= 泛化通知,
+ * 调用方照旧走 `normalizeTaskNotification` / `renderTaskNotificationXml`)。
+ *
+ * 入参是**原始**载荷(snake_case `task_id` 那一份),不是 `normalizeTaskNotification` 的产物 ——
+ * 后者是一张 15 键白名单,这三条载体一个都不在里面。
+ */
+export function classifyPeerNotification(n) {
+    const seq = finiteNumber(dataProp(n, WIRE_KEY_SEQ));
+    // ① 同进程 uplink(§1.4 d1)
+    const agentMessage = dataProp(n, WIRE_KEY_AGENT_MESSAGE);
+    if (agentMessage !== undefined) {
+        const from = cleanName(dataProp(agentMessage, WIRE_KEY_FROM));
+        const body = dataProp(agentMessage, WIRE_KEY_BODY);
+        if (from !== undefined && typeof body === 'string' && provenanceAgrees(n, 'agent_message', from)) {
+            const agentType = nonEmptyString(dataProp(dataProp(n, WIRE_KEY_PROVENANCE), WIRE_KEY_AGENT_TYPE));
+            return {
+                lane: 'agent_message',
+                from,
+                body,
+                ...(agentType !== undefined ? { agentType } : {}),
+                ...(seq !== undefined ? { seq } : {}),
+            };
+        }
+        return null;
+    }
+    // ② 跨会话信封(§4.1)
+    const crossSessionMessage = dataProp(n, WIRE_KEY_CROSS_SESSION_MESSAGE);
+    if (crossSessionMessage !== undefined) {
+        const from = cleanName(dataProp(crossSessionMessage, WIRE_KEY_FROM));
+        const body = dataProp(crossSessionMessage, WIRE_KEY_BODY);
+        if (from === undefined || typeof body !== 'string' || !provenanceAgrees(n, 'cross_session_message', from))
+            return null;
+        const fromSession = nonEmptyString(dataProp(crossSessionMessage, WIRE_KEY_FROM_SESSION));
+        const fromName = cleanName(dataProp(crossSessionMessage, WIRE_KEY_FROM_NAME));
+        const fromModeRaw = dataProp(crossSessionMessage, WIRE_KEY_FROM_MODE);
+        const fromMode = PEER_MODE_CLASSES.find(m => m === fromModeRaw);
+        const fromScope = nonEmptyString(dataProp(crossSessionMessage, WIRE_KEY_FROM_SCOPE));
+        // 🔴 可选位形不合 ⇒ **只丢那一位**,不丢整帧:少一个 `from-mode` 是少一句注,
+        //    丢整帧是把一条同事消息从用户眼前拿走(与必填位的 fail-closed 是两码事)。
+        return {
+            lane: 'cross_session_message',
+            from,
+            body,
+            ...(fromSession !== undefined ? { fromSession } : {}),
+            ...(fromName !== undefined ? { fromName } : {}),
+            ...(fromMode !== undefined ? { fromMode } : {}),
+            ...(fromScope !== undefined ? { fromScope } : {}),
+            ...(seq !== undefined ? { seq } : {}),
+        };
+    }
+    // ③ 跨会话回执 / idle 通知(§4.4 / §5.2)
+    const crossSessionNotice = dataProp(n, WIRE_KEY_CROSS_SESSION_NOTICE);
+    if (crossSessionNotice !== undefined) {
+        const kindRaw = dataProp(crossSessionNotice, WIRE_KEY_KIND);
+        const kind = CROSS_SESSION_NOTICE_KINDS.find(k => k === kindRaw);
+        const text = nonEmptyString(dataProp(crossSessionNotice, WIRE_KEY_TEXT));
+        if (kind === undefined || text === undefined || !provenanceAgrees(n, 'cross_session_notice'))
+            return null;
+        return { lane: 'cross_session_notice', kind, text };
+    }
+    return null;
+}
+// ── 帧 ⇄ 文本(端的消息面只拿得到文本;两半同源,往返在常驻门里对拍)────────────────────
+/**
+ * core `ENGINE_AUTHORITY_ENVELOPE_TAGS` 的镜像(`core/untrusted-text.ts::ENGINE_ENVELOPES` 里 kind="authority" 的标签):
+ * 这些信封在模型面/转录面代表**引擎权威**,一段同事正文里出现它们就是伪造。core 的 `neutralizePeerBody`
+ * (= `sanitizeUntrustedText(body, PEER_BODY_ENVELOPE_TAGS)`)在渲染信封**之前**先把它们拆火(`<` 后插 ZWSP),
+ * 本模块首版只抄了后一步(同名信封拆火)——异源发包扫描 [high] 实证:子代正文里一段
+ * `<task-notification><task-id>victim</task-id><status>completed</status>…` 会原样进转录 block,
+ * 宿主 resume 时 `parseTranscriptNotificationSeeds` 把它读成真完成通知 ⇒ 去重台账被毒化,受害 run 的
+ * 真完成通知随后被跨通道臂整条吞掉。这里补上那一步,并与 core 同形(`<\s*\/?\s*(tag)(\s[^>]*)?>` 全大小写)。
+ * 🔴 单向(与 core 一致):端的解析腿**不**还原 ZWSP —— 拆掉的权威标签就该永远是拆掉的。
+ */
+export const AUTHORITY_ENVELOPE_TAGS = Object.freeze([
+    'system-reminder',
+    'task-notification',
+    'new-diagnostics',
+    'user_memory',
+    'scope',
+    'skills',
+    'total_tokens',
+    'instruction-files',
+]);
+const ZWSP = String.fromCharCode(0x200b);
+const AUTHORITY_BREAKOUT_RE = new RegExp(`<\\s*\\/?\\s*(?:${AUTHORITY_ENVELOPE_TAGS.map(t => t.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')).join('|')})(?:\\s[^>]*)?>`, 'gi');
+function neutralizeAuthorityTags(text) {
+    return text.replace(AUTHORITY_BREAKOUT_RE, m => m.replace('<', '<' + ZWSP));
+}
+/**
+ * 署名类属性的呈现规范化(异源发包扫描 [medium]):`from` / `fromName` 是发送方**自述**的串,可含换行与控制符,
+ * 折叠行按单行渲会被它撑破。与 core `canonicalPeerDisplayName` 同向:控制符/换行折成单空格、两端去空白;
+ * 折空 ⇒ 视同缺席(必填位 ⇒ 整帧退泛化卡;可选位 ⇒ 只丢那一位)。
+ */
+function cleanName(v) {
+    if (typeof v !== 'string')
+        return undefined;
+    const t = v.replace(/[\u0000-\u001f\u007f\u2028\u2029]+/g, ' ').replace(/\s+/g, ' ').trim();
+    return t.length > 0 ? t : undefined;
+}
+/**
+ * 正文里的同名标签拆火:开括号后插一个反斜杠,于是它不再是一个标签。
+ *
+ * 🔴 与 core 的 `escapeEnvelopeTag` **有意不同一格**(异源对抗复审 r1 [medium] 采纳):core 那一份是
+ *    **单向**消毒(模型读到就完了,没有反向腿),所以它不处理正文里**原本就有**的 `<\agent-message>`;
+ *    而本模块有反向腿(端的消息面要把正文还原出来),单向消毒在这里就是一个**非单射**映射 ——
+ *    一段合法的代码文本 `<\agent-message>` 会在 render→parse 往返之后被改写成 `<agent-message>`,
+ *    既损坏正文,又等于给正文一条**注入真标签**的路。
+ *    ⇒ 这里连**已有的反斜杠**一起数:`<` 后面跟任意多个反斜杠再跟标签名时都插一个。
+ *    每次编码恰好加一个、每次解码恰好去一个 ⇒ `unescape(escape(x)) === x` 对一切 x 成立。
+ */
+function escapeEnvelopeTag(tag, text) {
+    return text.replace(new RegExp(`<(?=\\\\*/?${tag}(?:[>\\s/]|$))`, 'gi'), '<\\');
+}
+function unescapeEnvelopeTag(tag, text) {
+    return text.replace(new RegExp(`<\\\\(?=\\\\*/?${tag}(?:[>\\s/]|$))`, 'gi'), '<');
+}
+/** 属性值转义 —— 属性用双引号包,值里的 `"` 与尖括号一律实体化,不给伪造闭合属性留缝。 */
+function attr(v) {
+    return v.replace(/&/g, '&amp;').replace(/"/g, '&quot;').replace(/</g, '&lt;').replace(/>/g, '&gt;');
+}
+function unattr(v) {
+    return v.replace(/&quot;/g, '"').replace(/&lt;/g, '<').replace(/&gt;/g, '>').replace(/&amp;/g, '&');
+}
+/**
+ * 投影 → 转录行文本(端的消息面按标签分派的那一份)。
+ *
+ * 🔴 这**不是** core 模型面信封的逐字副本,也不该是:core 那一份是给**模型**读的(带纪律块、
+ *    带 CC 逐字属性语法、带 round-trip 拒收);这一份是**端的转录回显**,只需要与本模块的解析腿
+ *    往返一致。刻意不复刻 core 的语法契约 —— 复刻一份对不上的副本比不复刻更坏
+ *    (它会让人以为端这一行是模型读到的那一行)。属性序仍照 core 的规范序排,便于人肉比对。
+ */
+export function renderPeerFrameTranscriptText(p) {
+    // 🔴 通知纯行也是引擎按 peerMeta 铸的散文,但它承载的仍是**关于别人消息**的文本:同样过权威标签拆火,
+    //    并把两个消息信封标签拆火 —— 否则一条整体形如 `<agent-message …>…</agent-message>` 的通知会被端判成
+    //    一条署名消息(异源发包扫描同形存量③)。
+    if (p.lane === 'cross_session_notice')
+        return escapeEnvelopeTag(CROSS_SESSION_MESSAGE_TAG, escapeEnvelopeTag(AGENT_MESSAGE_TAG, neutralizeAuthorityTags(p.text)));
+    if (p.lane === 'agent_message') {
+        const body = escapeEnvelopeTag(AGENT_MESSAGE_TAG, neutralizeAuthorityTags(p.body));
+        return `<${AGENT_MESSAGE_TAG} ${FROM_ATTR}="${attr(p.from)}">\n${body}\n</${AGENT_MESSAGE_TAG}>`;
+    }
+    const attrs = [`${FROM_ATTR}="${attr(p.from)}"`];
+    if (p.fromSession !== undefined)
+        attrs.push(`from-session="${attr(p.fromSession)}"`);
+    if (p.fromName !== undefined)
+        attrs.push(`from-name="${attr(p.fromName)}"`);
+    if (p.fromMode !== undefined)
+        attrs.push(`from-mode="${attr(p.fromMode)}"`);
+    if (p.fromScope !== undefined)
+        attrs.push(`from-scope="${attr(p.fromScope)}"`);
+    const body = escapeEnvelopeTag(CROSS_SESSION_MESSAGE_TAG, neutralizeAuthorityTags(p.body));
+    return `<${CROSS_SESSION_MESSAGE_TAG} ${attrs.join(' ')}>\n${body}\n</${CROSS_SESSION_MESSAGE_TAG}>`;
+}
+// 🔴 属性值不设长度上界:渲染腿无界,解析腿封顶就会让包自己铸出的帧解析回 null(异源发包扫描 [high]);
+//    `[^"]*` 是线性匹配,无回溯风险。
+const AGENT_MESSAGE_RE = new RegExp(`^<${AGENT_MESSAGE_TAG} ${FROM_ATTR}="([^"]*)">\\n([\\s\\S]*)\\n</${AGENT_MESSAGE_TAG}>$`);
+const CROSS_SESSION_RE = new RegExp(`^<${CROSS_SESSION_MESSAGE_TAG} ${FROM_ATTR}="([^"]*)"` +
+    `(?: from-session="([^"]*)")?` +
+    `(?: from-name="([^"]*)")?` +
+    `(?: from-mode="(bypass|prompting)")?` +
+    `(?: from-scope="([^"]*)")?` +
+    `>\\n([\\s\\S]*)\\n</${CROSS_SESSION_MESSAGE_TAG}>$`);
+/**
+ * 转录行文本 → 投影(`renderPeerFrameTranscriptText` 的逆)。认不出 ⇒ `null`。
+ *
+ * 端唯一该调的字符串判定口:**端自己一条正则都不许写**(cli-191 A-D1/A-D12 那一族的成因就是
+ * 消费端各自抄一份判据,上游改词后集体空转而没有一道门响)。
+ *
+ * 🔴 `ok` 只等于「形是规范的」,**不等于**「这条消息真是引擎注入的」——文本面的身份权威不存在
+ *    (core §4.2 三层规则同一句话)。端拿它做**呈现**分派,不许拿它做任何授权判断。
+ * 🔴 通知车道(`cross_session_notice`)刻意**不进这条腿**:它的转录行是一行没有标签的散文,
+ *    要认它只能去锚 `[Cross-session …]` 前缀 —— 那正是本仓禁的那一形(用户随手打一行同样的字
+ *    就会被认成引擎通知)。通知按普通文本行渲,本来就是 CC 形。
+ */
+function hasRawTag(tag, body) {
+    return new RegExp(`<(?=/?${tag}(?:[>\\s/]|$))`, 'i').test(body);
+}
+export function parsePeerFrameText(text) {
+    const a = AGENT_MESSAGE_RE.exec(text);
+    if (a !== null) {
+        const from = unattr(a[1] ?? '');
+        // 🔴 正文里出现**未拆火**的同名标签 ⇒ 这不是本渲染腿产出的字节(它拆火过了),而**贪婪**的
+        //    `[\s\S]*` 会把「两封拼在一起」读成一封、把两封的正文合并、把两位署名合并成第一位 ——
+        //    异源对抗复审 r1 [high] 的第三形。整条退 null:落回普通文本行,一个字节都不丢。
+        if (from.length === 0 || hasRawTag(AGENT_MESSAGE_TAG, a[2] ?? ''))
+            return null;
+        return { lane: 'agent_message', from, body: unescapeEnvelopeTag(AGENT_MESSAGE_TAG, a[2] ?? '') };
+    }
+    const c = CROSS_SESSION_RE.exec(text);
+    if (c === null)
+        return null;
+    const from = unattr(c[1] ?? '');
+    if (from.length === 0 || hasRawTag(CROSS_SESSION_MESSAGE_TAG, c[6] ?? ''))
+        return null;
+    const fromSession = c[2] !== undefined ? unattr(c[2]) : undefined;
+    const fromName = c[3] !== undefined ? unattr(c[3]) : undefined;
+    const fromMode = PEER_MODE_CLASSES.find(m => m === c[4]);
+    const fromScope = c[5] !== undefined ? unattr(c[5]) : undefined;
+    return {
+        lane: 'cross_session_message',
+        from,
+        body: unescapeEnvelopeTag(CROSS_SESSION_MESSAGE_TAG, c[6] ?? ''),
+        ...(fromSession !== undefined ? { fromSession } : {}),
+        ...(fromName !== undefined ? { fromName } : {}),
+        ...(fromMode !== undefined ? { fromMode } : {}),
+        ...(fromScope !== undefined ? { fromScope } : {}),
+    };
+}
+/**
+ * 端渲「@谁」时该用的那个名字 —— 判定在包,端不许自己排优先序。
+ * 跨会话:`fromName`(人取的名)优先于 `from`(地址);同进程:只有 `from`。
+ */
+export function peerFrameDisplayName(p) {
+    return p.lane === 'cross_session_message' && p.fromName !== undefined ? p.fromName : p.from;
+}

package/docs/INTEGRATION-CLIENTS.md

@@ -15,15 +15,15 @@
 
 ## §0 版本锚与重扫纪律
 
-### 0a. 版本锚(2026-09-04)
+### 0a. 版本锚(2026-09-05)
 
 | 项 | 值 | 真源 |
 |---|---|---|
-| 本包 | `@sema-agent/client-core` **0.53.0**(工作树**未发**;npm 最新 = **0.52.0**。L-93 那一批进 `CHANGELOG.md` 的 `## 0.53.0(未发布)` 段,冻结账已按两阶段协议插 `pending` 行) | `package.json` `version` |
+| 本包 | `@sema-agent/client-core` **0.54.0**(工作树**未发**;npm 最新 = **0.53.0**。design/385 那一批进 `CHANGELOG.md` 的 `## 0.54.0(2026-09-05)` 段,冻结账已按两阶段协议插 `pending` 行) | `package.json` `version` |
 | peer:wire 契约 | `@sema-agent/sdk` **>=7.4.0**(value-level,非 type-only;0.48.0 抬版,四条硬理由见 `CHANGELOG.md` 0.48.0 段末的地板影响面账) | `package.json` `peerDependencies` |
 | peer:会话词汇表 | `@sema-agent/agent-types` **>=0.2.0**(type-only,零运行时) | 同上 |
 | runtime dep | `diff` ^9.0.0(**唯一**一条;portability 门按**等值**钉死) | `package.json` `dependencies` |
-| 公开导出面 | **805** 个运行期符号(+ 41 个测试钩;= 工作树当下的值 —— 已发的 `0.51.0` 是 **803**,再加 L-69⑨ 两件未发 additive 导出;`0.49.0` 是 **795**,再加 S-81 五件未发 additive 导出;`0.48.0` 是 **794**,npm `0.47.0` 是 **790**,`0.46.0` 是 **787**,`0.44.0` 是 **783**,`0.43.1`/`0.43.0` 是 **776**,`0.42.0` 是 **771**,`0.41.0` 是 **767**,`0.39.0` 是 **766**,`0.38.0` 是 **764**;`0.37.0` 是 **753**,见 `CHANGELOG.md`) | `scripts/public-export-baseline.json` 的 `count` / `testHookCount` —— **别手抄进别处,以该文件为准** |
+| 公开导出面 | **815** 个运行期符号(+ 41 个测试钩;= 工作树当下的值 —— 再加 design/385 十件未发 additive 导出(0.54.0 段,含发包扫描补的 `AUTHORITY_ENVELOPE_TAGS`);已发的 `0.51.0` 是 **803**,再加 L-69⑨ 两件未发 additive 导出;`0.49.0` 是 **795**,再加 S-81 五件未发 additive 导出;`0.48.0` 是 **794**,npm `0.47.0` 是 **790**,`0.46.0` 是 **787**,`0.44.0` 是 **783**,`0.43.1`/`0.43.0` 是 **776**,`0.42.0` 是 **771**,`0.41.0` 是 **767**,`0.39.0` 是 **766**,`0.38.0` 是 **764**;`0.37.0` 是 **753**,见 `CHANGELOG.md`) | `scripts/public-export-baseline.json` 的 `count` / `testHookCount` —— **别手抄进别处,以该文件为准** |
 | 常驻门 | 以 `scripts/gates-manifest.json` 的 `suites` 长度为准(**本档不抄这个数**) | `scripts/gates-manifest.json`;`npm test` 的名单等值门与它逐名对账 |
 | 沿革档 | 0.29.0 起建 `CHANGELOG.md`;更早批次记账在 `src/index.ts` 文件头 + `docs/REFACTOR-LEDGER.md` | — |
 
@@ -106,14 +106,14 @@ SDK 核对「本包 import 的每个值级符号仍然导出」「`TaskStats.cos
   `--platform=browser` **真打包**看守,不是靠约定。
 - 宿主能力一律**经端口注入**(`installHost({...})`,见 §5),库自己**绝不** `require('fs')`、
   绝不 `process.env` 直读(env 走 `hostEnv()`)、绝不全局 `fetch`(目录线上腿走注入的 `CatalogFetchJson`)。
-- 闭包棘轮(零松量,逐块记账在各上限常量头注):内核 7 文件 / A 层 23 / index 119。
+- 闭包棘轮(零松量,逐块记账在各上限常量头注):内核 7 文件 / A 层 24 / index 142(0.54.0 `peerFrames.ts` 入 A 层与 index 各 +1)。
 - **实现锚**:`scripts/run-client-core-portability-test.mjs`、`src/hostEnv.ts`、`src/host.ts`。
 
 ---
 
 ## §2 公共导出面地图(按域)
 
-> 全集真源 = `scripts/public-export-baseline.json` 的 `names`(**805** 项)。
+> 全集真源 = `scripts/public-export-baseline.json` 的 `names`(**815** 项)。
 > 本节**不逐名抄**,只给「域 → 承重导出 → 用途 → 实现锚」。承重导出 = 一个端为了让这个域干活
 > **必须**直接调到的那几个符号;其余是它们的类型、变体与辅助位。
 > 单一入口:`import { … } from '@sema-agent/client-core'`(`exports` 只有 `.` 一个;
@@ -123,7 +123,7 @@ SDK 核对「本包 import 的每个值级符号仍然导出」「`TaskStats.cos
 
 `public-export-baseline.json` 由 **`dist/index.js` 的运行期导出**生成(生成口径自述见
 `scripts/run-client-core-typeshape-test.mjs`,双向精确集合门在 `scripts/run-public-surface-test.mjs`)。
-实测:805 项 **100% 是运行期导出,零 type-only**。
+实测:815 项 **100% 是运行期导出,零 type-only**。
 
 **推论(端必须知道)**:
 - barrel 导出的**类型**面比 707 大得多,且**不被这道门看守** —— `AdapterContext` / `SeamEvent` /
@@ -137,12 +137,12 @@ SDK 核对「本包 import 的每个值级符号仍然导出」「`TaskStats.cos
   `WorkflowsGateUnknownDenial` 四形**不在**基线里,`src/selfOrchestrationDenial.ts` 对基线贡献
   **4** 项运行期导出(三个函数 + `SELF_ORCHESTRATION_RETRY_WITHOUT`)。
 
-805 项的内部构成(帮助端估读表大小):**238** 项是 `SCREAMING_SNAKE` 常量数据表/词汇表
+815 项的内部构成(帮助端估读表大小):**244** 项是 `SCREAMING_SNAKE` 常量数据表/词汇表
 (矩阵、键集、env 名、锚串)而非可调用物;**5** 项是 PascalCase 运行期值
 (`ControlRouter` / `ControlSafetyError` / `HitlBridge` / `HitlSafetyError` / `DecideTransportRetryExhaustedError`);
 **41** 项是 `*For(sessionKey, …)` 的 per-session 变体(§6;其中 `engineNamespaceKeyFor` 是命名巧合 —— 参数是 baseUrl 不是 sessionKey,见域 14)。
 
-### 2b. 域图(16 域,逐域计数之和 = 805)
+### 2b. 域图(16 域,逐域计数之和 = 815)
 
 | # | 域 | 名数 | 承重导出 | 用途 | 实现锚 |
 |---|---|---|---|---|---|
@@ -152,7 +152,7 @@ SDK 核对「本包 import 的每个值级符号仍然导出」「`TaskStats.cos
 | 4 | **子代 wire + 面板侧信道台账** | 84 | `tailEngineSubagent` · `installSubagentActivitySink` · `installSubagentTailMetaSink`(#280 件2:tail meta 帧发布口,`contentFrames` 判别位载体)· `stopEngineTask` + `classifyTaskStopConflict` · `fetchEngineSubagentReport` · `steerEngineSubagent`(0.32.0 未发布 #280 件A:additive 第三参 `childTaskId` —— 端有行上下文时**应当**传,传了就走「台账优先 / 缺席即诚实缺席 + `noteBgOwnerAbsence` 留痕」的 Q3 口径,与 tail·taskOutput·subagentOutput 三腿同姿势、与孪生 resume 腿共用同一个 `resolveOwnerRunId` 判据;**不传**则逐字维持旧行为=回落在飞 run)· `resumeSettledSubagent` + `resolveSubagentResumeContext` + `resolveOwnerRunId` + `classifySubagentResumeFailure` + `subagentResumeAvailable`(#242 批 2 A-028.7:resume 判定半场上收,与 steer 孪生同居;取址三态 = 台账有行用行值 / 指名了行但台账缺席则**诚实缺席绝不回落在飞 run** / 没指名行才回落。出路文案归端)· `recordSubagentOwnerFromProgress` + `getBgParentRunOwner`(A-028.6:「子代 → 宿主 run」**单表**,宿主 run 必须由持 stream-local 值的调用方显式传入,包内绝不从 `activeEngineRunId()` 推断)· `noteBgOwnerAbsence`(#242 批 3 [4000] Q3=B:tail/taskOutput·taskStop/subagentOutput 三腿台账缺席即诚实缺席**绝不回落在飞 run**,缺席 warn 留痕每 (腿,taskId) 一条)· `clearBgTerminalFacts`(#242 批 3 扫码修:复活=新周期,旧周期终态事实作废——fleetLedger 复活两腿按尾段清账,factsAccepted 方向核不再拿上周期终态当先例)· `auditRetainWithoutWake`([4000] Q5:引擎宣示 `subagentResume` + 本端在付 `retainSubagentSessions` + 端未实现 `wakeSubagent` ⇒ 响亮一条;`CLIENT_VERBS.wakeSubagent` 维持 fail-soft)· `subscribeSubagentContent` · `subscribeEngineAgentPanel` · `publishQuestionFrame` / `respondToQuestion` | 驱动与观测委派子代;经 module 级台账喂活体 agent/task 面板。全部**能力位 gate**(§5b) | `src/subagent/*.ts`、`src/subagentContentStore.ts`、`src/engineAgentPanelStore.ts`、`src/engineInlineTaskStats.ts`、`src/engineToolLabelStore.ts`、`src/liveQuestionStore.ts` |
 | 5 | **fleet 投影** | 46 | `createFleetLedger` · `projectTasks` · `projectWorkflows` · `projectFleetAgentRows` · `readEngineActiveBgTasks` · `FLEET_TASK_VIEW_KEYS` · `escapeDisplayControlChars`(不可见字符可见化,行标签/描述消毒的共享底座)· `wireCycleSeq` / `wireRetiredBy`(0.38.0 提货补投的 #261 §2 两位:代际号 = SendMessage 复活即 +1,**缺席 ≠ 第一代**;`retiredBy` 在场 = 这条终态是对账腿从 durable run 行投影出来的、**不是**发布方亲报 —— 幽灵行与正常收尾唯一的 wire 判据。两位都只在场才落键) | 老 `fleetClient` 那一刀的成品:**帧体归库、连接归端** —— 端持 SSE 连接,库做行投影 + 保留台账 | `src/fleet/fleetProjection.ts`、`src/fleet/fleetLedger.ts`、`src/fleetAgentPanelProjection.ts`、`src/fleetTaskDesc.ts` |
 | 6 | **请求装配(上行唯一构造口)** | 8 | `buildTaskRequest` · `REQUEST_FIELD_MATRIX` · `unregisteredRequestKeys` · `applyLiveRequestDefaults` · `taskNotificationToPrintFrame` | 两条车道(`interactive`/`print`)出站请求的**唯一**构造器;`unregisteredRequestKeys` 是可执行门 —— 端偷带一个未登记键上 wire 就红 | `src/request/taskRequest.ts`、`src/request/printNotification.ts` |
-| 7 | **通知与 outstanding 台账** | 41 | `installNotificationQueuePort` · `normalizeTaskNotification` · `taskNotificationDedupKeyFromWire` · `registerOutstandingBgTask` / `registerOutstandingWorkflowRun` · `notificationQueuePortMisses` · `subscribeOutstandingWorkflows` · `outstandingDeliverableWorkflowCount` | `task_notification` 归一 + 去重 + 投递进宿主命令队列的**一把闸**;`outstandingDeliverableWorkflowCount()` 是 headless `-p` 的**退出门** | `src/notifications.ts`(11 个 module 台账) |
+| 7 | **通知与 outstanding 台账** | 51 | `installNotificationQueuePort` · `normalizeTaskNotification` · `taskNotificationDedupKeyFromWire` · `registerOutstandingBgTask` / `registerOutstandingWorkflowRun` · `notificationQueuePortMisses` · `subscribeOutstandingWorkflows` · `outstandingDeliverableWorkflowCount` | `task_notification` 归一 + 去重 + 投递进宿主命令队列的**一把闸**;`outstandingDeliverableWorkflowCount()` 是 headless `-p` 的**退出门** · `classifyPeerNotification` / `renderPeerFrameTranscriptText` / `parsePeerFrameText` / `peerFrameDisplayName` + 三张闭集表(design/385,0.54.0:同一条 `task_notification` 车道上三条**引擎注入帧**的类型化投影 —— 判别位=载体在场而非 summary 文本,详见 §17) | `src/notifications.ts`(11 个 module 台账) |
 | 8 | **工具结果卡** | 25 | `structuredToToolUseResult` · `readAsyncLaunchedAgentReceipt` · `wireOutputToBody` · `parseModelFacingBash` · `getPatchFromContents` · `toolEndResultToUserFrame` · `flattenToolOutput` | 铸端要渲的 `tool_result` 卡体,含客户端 diff hunk(唯一 runtime dep 的用处) | `src/toolResult.ts`、`src/printToolResultFrame.ts`、`src/diff/patch.ts` |
 | 9 | **能力/旋钮 wire 门族** | 91 | `projectAgentsForWire` / `awaitTaskAgentsWire` · `hooksForWire` · `mcpConfigsToSpecs` · `ultracodeForRequest` · `resolveWebSearch` + `buildWebSearchEnv` · `attachmentsForRequest` · `projectEffectiveBody` · `classifySelfOrchestrationRefusal` / `stripSelfOrchestrationIntent` / `projectWorkflowsGate` / `SELF_ORCHESTRATION_RETRY_WITHOUT`(S-81,server 7.57.0:上面两条 stamp 腿的**背面** —— 半配置多租户形态下 server 把带 `selfOrchestration` / `settings.ultracode` 的提交 501 拒掉,判型/去键/caps 闸三处都是判定不是文案,详见 §13) | 逐功能的「引擎有没有这个能力 + 这个字段怎么上 wire」投影器,由 `buildTaskRequest` 组装。🔴 `hooksForWire()` 是 **fail-closed**:无 `SettingsPort` ⇒ 返回 `undefined`(信任门,不是取值) | 17 个 `src/*WireCaps.ts` + `src/scratchpadWireCaps.ts`、`src/hooksWireCaps.ts`、`src/goalStopHook.ts`、`src/websearch/searchProviderPresets.ts`、`src/selfOrchestrationDenial.ts`(S-81 拒绝判定层) |
 | 10 | **headless / 部署旋钮 wire** | 61 | `parseSandboxArgv` / `sandboxRequestFields` · `parseLimitsArgv` / `limitsForPrint` · `resolveHeadlessFinalVerify` · `resolveHeadlessPermissionMode` · `resolveHeadlessInteractiveTools` · `armDetachCancel` + `detachCancelArm` + `isDetachArmed` · `withHeadlessR1Reconnect` | `-p`/headless 车道的 env+argv 旋钮。🔴 `detachWire` 是**拆**的补偿:判定与 cancel-arm 台账在库,信号路径的裸 fetch 留宿主(`detachCancelArm()` 是取件口) | `src/sandboxWire.ts`、`scenarioWire.ts`、`finalVerifyWire.ts`、`limitsWire.ts`、`interactiveToolsWire.ts`、`headlessPermissionModeWire.ts`、`headlessReconnectWire.ts`、`detachWire.ts` |
@@ -2592,3 +2592,105 @@ interface ActiveRunSelfHealDeps {
 `offerStaleParkChoice` / `staleParkArm` / `cancelAndConfirmRelease` / 五个新 kind 的文案臂)。
 **常驻门**:`scripts/run-selfheal-reopen-test.mjs`(G11 段,含「该位缺席 ⇒ 逐字旧结局且零 cancel」负控)、
 `scripts/run-terminal-identity-copy-test.mjs`(G2 段:新 kind 的注入形与处置分类)。
+
+
+## §17 🆕 design/385 三条引擎注入车道的类型化投影(0.54.0;cli L-61② / L-87 5a①5a②)
+
+### 17a. 修的是哪一形
+
+引擎把三类**根本不是同一种东西**的载荷塞进同一条 `task_notification` 车道,而 core 对这三类
+**不套** `<task-notification>` 壳(`core/task-notification.ts::renderTaskNotificationXml` 头三个分支
+按这个顺序判):
+
+| 载体键(`TaskNotificationPayload` 上) | 出处 | 模型面 |
+|---|---|---|
+| `agentMessage: {from, body}` | §1.4 d1 —— 同进程子代 `SendMessage("main")` 的 uplink | `<agent-message from="…">` + peer 纪律块 |
+| `crossSessionMessage: CrossSessionEnvelopeFields & {body}` | §4.1 —— 另一个会话的消息,从本会话自己的信箱 drain 出来 | `<cross-session-message from="…" from-session="…" from-name="…" from-mode="…">` + 跨会话纪律块 |
+| `crossSessionNotice: {kind, text}` | §4.4/§5.2 —— **本会话自己发出去**那条消息的回执 / `notify_when_idle` 的 idle 通知 | 一行纯文本(`[Cross-session delivery notice] …` / `[Cross-session idle notice] …`) |
+
+端此前照 `task_notification` 泛化卡渲 ⇒ 屏上是「后台任务完成」,而模型读到的是一条同事发来的话。
+
+### 17b. 端该怎么用(三步,端零字符串判定)
+
+```ts
+import { classifyPeerNotification, parsePeerFrameText, peerFrameDisplayName } from '@sema-agent/client-core'
+
+// ① 帧面(适配器内部已接;宿主自建管线才需要):原始 wire 载荷 → 投影 | null
+const frame = classifyPeerNotification(rawTaskNotificationPayload)
+
+// ② 文本面(端的消息组件只拿得到文本):转录行 → 投影 | null
+const projected = parsePeerFrameText(messageText)
+if (projected?.lane === 'agent_message') renderAgentMessageCard(peerFrameDisplayName(projected), projected.body)
+if (projected?.lane === 'cross_session_message') renderCollapsedPeerRow(peerFrameDisplayName(projected), projected.body)
+// ③ 通知车道没有标签,按普通文本行渲 —— 这就是 CC 形(无卡、无折叠、一行)
+```
+
+### 17c. 五条判定纪律(端不许自己重判)
+
+- 🔴 **判别位 = 类型化载体的在场,永远不是 `summary` 文本**。三条载体只有引擎的注入腿铸得出
+  (`ExternalNotificationInput` 是 `TaskNotificationPayload` 的**真子集** —— 外部 `notify()` 一个都
+  穿不上);而 `summary`/`result` 是任何一条通知都填的字段。判据落到文本上 ⇒ 任何一个后台任务
+  只要把 `<agent-message from="…">` 写进自己的 summary 就能在用户屏上冒充一条同事消息。
+- 🔴 **fail-closed 分两档**。必填位坏(`from` 空 / `body` 非串 / notice `kind` 不在闭集)⇒ 整帧返
+  `null` = 退泛化卡(诚实降级:用户仍看得见这条通知,只是没有专用形)。可选位坏(`fromMode` 写了
+  闭集外的词)⇒ **只丢那一位**:少一句注 vs 把一条同事消息从用户眼前拿走,不是同一个量级。
+- 🔴 **`_sema_provenance` 必须在场,且 `kind` 与载体车道相符**。缺席 / 读不出(非对象、访问器)/
+  矛盾,三形一律退泛化卡。**这一条 0.54.0 定稿时翻过一次面**:首版是「只否决不认证、缺席放行」,
+  理由「要求在场会让另两条车道在老引擎上恒死」被对抗复审证伪 —— 老引擎上那两条车道**连载体键都
+  没有**,判定根本走不到;而 core 契约明写 provenance「present exactly when the carrier is」,在跑的
+  7.2.0 就是同一处同时铸两者。要求在场对真载荷零代价,对畸形 / 半截注入 / 版本漂移则关上一道门。
+  🔴 判据是**四条等式 + 在场**:`kind` 与车道相符,且 `from`/`taskId`/`seq` 三位**必须在场**并分别
+  等于载体的 `from`、载荷的 `task_id`、载荷的 `seq`(core 的 `SemaProvenance` 把这三位全声明为必填,
+  三个铸点也都同址写下 ⇒「两侧都缺」不是合法兼容形,而是半截载荷)。只核 `kind` 拦得住半截载荷,拦不住**同 kind 的伪造** —— 载体署一个可信名字、
+  provenance 三位全对不上,屏上照样出现一条署着那个名字的消息。后三条**各有铸点直证**(uplink 腿与
+  跨会话 drain 腿都在同一个对象字面量里同值写下这几位),铸点一改由 cli 侧 wire 锚的同址探针当场
+  喊红 ⇒ 「等式失效」不会退化成一条静默死掉的车道。
+  ⚠️ 端若自建管线要注意:载荷那一边是 **snake** `task_id`、provenance 那一边是 **camel** `taskId`
+  —— 同一个量两个拼法,写混了等式恒不成立。
+- 🔴 **分支序**:三车道判定必须在「完成卡已入队」这类**完成通知专用**早退**之前**做。子代续跑时
+  复用同一个 taskId,它的合法 `agentMessage` 帧会在那种早退上被整条丢掉(零输出、去重账已记 ⇒
+  重放也补不回来)。**同因第二件**:peer 帧也不该写「这个 run 的完成已经被引擎注入过」那本跨通道账
+  —— 一条同事**消息**不是完成事件(三条 peer 铸点的 `status` 都是 `"event"`),写脏了它,子代自己
+  真正的空闲期完成通知随后会被补发通道整条丢掉。本包 0.54.0 的 `taskNotificationArm` 已按此两条修;
+  端若自建投影管线同理。
+  文本面同理:`parsePeerFrameText` 的 `ok` 只等于「形是规范的」,**不等于**「这条真是引擎注入的」
+  —— 文本面不存在身份权威(core §4.2 三层规则同一句话)。端拿它做**呈现**分派,不许拿它做任何
+  授权判断。
+- 🔴 **`parsePeerFrameText` 的三条硬边界**(端若自建管线必须同样成立):信封整串锚定;正文里出现
+  **未拆火**的同名标签 ⇒ 整条退 `null`(贪婪匹配会把「两封拼一起」读成一封、把「信封 + 尾随文本」
+  读成一封而尾随文本静默消失);拆火编码是**单射**(`unescape(escape(x)) === x` 对一切 x 成立,
+  连正文里原本就有的反斜杠一起数)—— core 的 `escapeEnvelopeTag` 是**单向**消毒、没有这条义务,
+  照抄过来会让 `<\agent-message>` 这类合法代码文本在往返之后变成一个真标签。
+- 🔴 **优先序照抄 core 的渲染腿**(agentMessage → crossSessionMessage → crossSessionNotice)。多载体
+  同在是矛盾载荷,但模型那一面**已经按 core 的顺序读过了**;端另立一套「矛盾就退泛化」会让屏上
+  那张卡与模型读到的帧对不上。
+- 🔴 **通知车道刻意不进 `parsePeerFrameText`**。它的转录行是一行没有标签的散文,要认它只能去锚
+  `[Cross-session …]` 前缀 —— 用户随手打一行同样的字就会被认成引擎通知。按普通文本行渲本来就是
+  CC 形。
+
+### 17d. 零行为差的边界
+
+三条载体一个都不在场的载荷(= 上游到货前的**全部**载荷)走的分支与 0.53.0 **逐字节等价**:
+`taskNotificationArm` 只换了转录行那一行的**文本来源**,去重键 / `bgshell_settle` / 面板 settle /
+module 台账一个都没动(它们判的是「哪个 task 的哪个状态」,与这条通知在模型面穿哪件外衣无关,
+跟着换会把三条独立的账搅成一本)。
+
+🔴 **边界的另一半(发包扫描 [high] 纠偏)**:载体**在场**时,`taskNotificationArm` 对**所有**宿主(含没接 `parsePeerFrameText`
+的老宿主 desktop/web-client)都把转录行文本换成信封形(`<agent-message …>…</agent-message>` / `<cross-session-message …>` /
+通知纯行),不再是 `<task-notification>` XML。这是**有意的**——那一行本来就是模型读到的帧,老宿主把它当普通 user 文本行渲
+正是 CC 形(CC 的 `<agent-message>` 就是一条 user 文本)。所以「零行为差」只对**载体缺席**的载荷成立;载体在场的老宿主差异=
+「泛化完成卡 → 一行原文」,不是回退。
+
+### 17e. 上游供给的诚实边界(本版新增的已知局限)
+
+`crossSessionMessage` / `crossSessionNotice` 两条载体在 **core 7.2.0** —— 即 cli `ENGINE_PIN 7.57.0`
+内嵌的那一版 —— 上**零铸点**(直证:`node_modules/@sema-agent/core/dist/**` 两词零命中)。本批是
+**消费半场先落地**,上游到货前这两条车道恒不触发。`agentMessage` 一条今天就到得了
+(core 7.2.0 `dist/agents/send-message-tool.js` 的 uplink 腿直证 `_sema_provenance: { kind: "agent_message" …`)。
+两个标签字面量已由 cli 侧的 wire 锚契约门(登记表里的 A-K24 条)对 core 真字节看着。
+
+**cli / web / desktop 认领**:cli 侧接点(消息组件三形)在本批同车;web / desktop **无需动作**
+(不调新导出 ⇒ 逐字节零行为差,只是这三条车道在它们那儿仍渲泛化卡)。
+**实现锚**:`src/peerFrames.ts`(`classifyPeerNotification` / `renderPeerFrameTranscriptText` /
+`parsePeerFrameText` / `peerFrameDisplayName` / 三张闭集表)、`src/adapt/arms.ts` 的通知臂。
+**常驻门**:`scripts/run-peer-frame-projection-test.mjs`(71 checks,含适配器级的两条台账回归)。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sema-agent/client-core",
-  "version": "0.53.0",
+  "version": "0.54.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. Renamed from @sema-agent/wire-cc-adapter (0.1.x).",
   "license": "MIT",
   "type": "module",