@sema-agent/client-core 0.53.0 → 0.55.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,173 @@
 > 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.55.0(2026-09-05)
+
+### `waiting_first_token` —— 等第一个 token 是一种**状态**,不是一次错误(core 7.3.0 / #530;cli B-003 / L-108①)
+
+用户报案(sema-bug4「模型调用失败对用户不可见」)的两个面,同一个根因:
+
+| 引擎 | 用户看到 |
+|---|---|
+| 7.57.0(内嵌 core 7.2.0) | **什么都没有** —— 相不存在,壳无从渲 |
+| 7.58.0(内嵌 core 7.3.1) | 一条**错误色**的 `API error` 行 —— 方向反了:一次尝试都没失败过 |
+
+core 7.3.0 在 `BrainStatusPhase` 上加了第七相 `waiting_first_token`:首 token 看门狗已武装
+(`firstTokenTimeoutMs > 30_000`)而第一个字还没到,等满 30s 起每 30s 发一帧,携 `elapsedMs` /
+`timeoutMs`(`core/dist/brain/stream-engine.js` 的 `emitWaitFrame` 铸点)。本包 0.54.0 及以前
+`mapBrainStatusToRetry` 的 `switch` 只认六相 ⇒ **第七相落 `default:` 被投成 `{kind:'error'}`**,
+壳照 `kind` 渲成重试行。病形 = 「上游闭集加员落 default 臂 ⇒ 新状态被渲成最像的旧状态」,
+与 #3004 修的 `recovered`(重试**成功**被渲成 `API error`)逐字同族。
+
+- **新 `kind: 'waiting'` 臂**(`src/retryStatus.ts`):携 `elapsedMs` / `timeoutMs`,不打 `terminal`
+  位(首 token 到了 core 补 `recovered`,彻底失败补 `gave_up` —— 等待本身从来不是终态)。
+  `deadline` 恒 = 映射时刻的 `nowMs`(本相不带 `retryIn*`)⇒ 渲染面按「剩余量 ≤ 0」自然不渲倒计时。
+- 🔴 **老宿主分两形(不许含混说「零差异」)**:`waiting` 臂刻意是 `error` 臂的**结构超集** ——
+  **结构形**消费者(`if (kind==='stalled') … else …`)逐字节零差异;而**穷尽形**消费者
+  (`switch (kind)` + `default: assertNever`)**加员即破**(重新编译报「waiting 不可赋给 never」,
+  已编译老产物在 default 臂**抛**)—— 破的是判别值本身,补结构位救不了。⇒ 对这一类消费方
+  0.55.0 是 **BREAKING**,三端必须审一遍自己的 `RetryStatus` switch。两形的事实分别钉在
+  `run-client-core-pure-test.mjs` G6-e ①②③。结构形的细节:还没跟车的端
+  (desktop / web-client)其 `if (kind==='stalled') … else …` 的 else 臂照旧读到 `error` /
+  `deadline` / `terminal`,渲出与 0.54.0 **逐字节相同**的那一行。少了 `error` 这一位,
+  `status.error.rateLimits` 就是一次 TypeError —— 渲染路径裸抛 = 整屏崩,把「一行渲错」升级成
+  「一屏全没」。判据不是一句承诺,是门:`run-client-core-pure-test.mjs` G6-d 与
+  `run-additive-key-passthrough-test.mjs` G5d 拿**本函数自己的 `default:` 臂**当活对照
+  (一个未知相走的正是加员前第七相走的那条臂),两边逐位相等才绿。
+- **两位跟车过两层白名单**:`BrainStatus` 加 `elapsedMs` / `timeoutMs`(九键 → **十一键**)。
+  🔴 族扫落点是**两处**,不是派工单点名的那一处:`adapter/downstream/eventToSdkMessage.ts`
+  的 `case 'status'`(wire → 内部臂)与 `adapt/arms.ts` 的 `retryStatusArm`(内部臂 → chrome 事件)。
+  漏任一层,新相到壳只剩空壳:kind 对了、秒数永远缺席。两位缺席一律**键不 stamp**,绝不折 0。
+- **相位运行期镜像**六相 → **七相**;devDep `@sema-agent/core` `^7.1.0` → `~7.3.0`
+  (对账物不抬,`engine-vocab` G2-b 对新相**没有判别力** —— 这正是该门头注记过五次的恒绿病根)。
+
+### 抬对账物同批捞出的三件存量(族扫,不是点名件)
+
+抬 devDep core 到 7.3.1 后 `engine-vocab` 门当场翻红三处,逐条如实修:
+
+1. **`CC_DETAIL_TYPES` 漏 `list-agents`**(42 / core 43)—— ListAgents 的结构化卡
+   (`core/dist/agents/list-agents-tool.js` 铸点)。漏词的实际后果是那一类卡**永远退回正则解
+   模型面文本**,而任何一层都不会响。与 5.20 / 5.43 两次逐字同族。
+2. **`EditedRuleTextPrecheck` ok 臂漏 `warnings`**(core 7.3.0 / design/382 §3.3-5 的**宽度提示**)。
+   这条腿是端口注入(值原样穿过),所以漏的不是运行期的值,是**消费端的类型面可见性** ——
+   端读不到就不会渲,「宽度在点头之前被说出来」就只剩引擎那半边。同批转出
+   `EditedRuleBreadthWarning`(`code` 按本包一贯纪律取**开集串**,不镜像 core 的闭集枚举)。
+3. **门自身的抽取口径病**:`extractStringUnion` 的 `([^;]+);` 在**第一个分号**处截断,而 core 7.3.0
+   的 `BrainStatusPhase` 成员之间夹着一段**正文带分号**的 JSDoc ⇒ 第七相被静默漏抽,门报出
+   「core 6 相 / 本包 7 相;多:waiting_first_token」这种**方向反了的**红 —— 一个抽取口径的病
+   足以把跟车做对的人判成做错。修 = 先剥注释再匹配(同族的 `extractInterfaceKeys` 早就这么做),
+   并补两条自证腿(带分号 JSDoc 夹层 / 剥注释后不把注释里的串当成员)。
+
+### 已知局限(本版新增)
+
+- 壳半场的文案是 sema 超集:CC 2.1.250 语料**无同形提示行**(`cli250.js` 里 `first token` /
+  `firstToken` / `first_token` 的全部命中都是账号首 token 日期与流式计时**遥测**,无渲染面;
+  同族里唯一的用户可见行是 `Waiting for API response`,那是 `reconnecting` 相的既有行)。
+  ⇒ 措辞按 [6386] / L-79② 既定形,登记 divergence。
+- 未跟车的**结构形**端(desktop / web-client)在 7.58.0 引擎上仍会渲 0.54.0 那一行。这是加员的
+  **设计选择**而不是遗漏:零崩渲、零行为漂移,跟车与否由各端自己排期。**穷尽形**端不在此列 ——
+  见上一条,那是 BREAKING,必须加 case。
+- 🔴 **本版发出去也还不能让用户看见这一行**(异源对抗复审 [high] 如实记):cli 侧 deps 仍是
+  `@sema-agent/client-core ^0.53.0` / `@sema-agent/core ^7.2.0`,ENGINE_PIN 仍是 server 7.57.0
+  (内嵌 core 7.2.0,**没有**这个相)。⇒ 端到端可见需要三件同批:0.55.0 发布 → cli deps 抬到
+  ^0.55.0(含 lockfile)→ ENGINE_PIN 抬到 ≥7.58.0,并在**那一对真版本**上重跑 live 腿、
+  摘掉它在 `skip-baseline.json` 里的必 SKIP 登记。
+
+- **发包前异源扫描四修(2026-09-05,三域 opus 扫描 + opus 反证,17 条 7 实证)**:①[medium] **waiting 相的覆盖层拆除生命周期无门**——
+  把 `retryStatusArm` 尾行 `noteRetryOverlay()` 对 waiting 摘掉,pure 3455 + additive 81 照样全绿 ⇒ 补 R1w 三判据(waiting 后首个主 lane
+  内容帧即 `status:null`、先于 `response_metrics start`、子流帧不清);②[low] `elapsedMs`/`timeoutMs` 负数/NaN 直穿 ⇒ `saneMs` 只认有限非负
+  数(缺席不渲 0);③[medium] cli 侧 waiting 相曾走 RetryStatusRow 的 all-or-nothing 槽,整块顶掉动画 glyph 与每秒计时,30s 一帧之间屏上零变化
+  (像卡死)⇒ 壳改为只替换 byline、glyph 照常动(cli 半场);④文档/门勘误:`retryStatus.ts` 键集注释 9→11 键、server 7.54.0→7.58.0;typeshape
+  棘轮 b4 21→20 的推导理由改按实测(此前只有一处内联);engine-vocab `CORE_FLOOR` 7.1→7.3 与对账物同步;INTEGRATION-CLIENTS §0a 已发版本的
+  「未发」告示按「发出即退场」约定退场。**老宿主三形**(§18c 更正):结构形(读 `kind` 走 default)零差异;穷尽形(`switch`+`assertNever`)
+  BREAKING;**不读 kind 的宿主**(web-client 现状)在 waiting 相上仍渲既有错误行「Request failed · retrying」——不是回归(0.54.0 同形),
+  但接 §18b 才有真进度行。
+
+## 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.55.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());
@@ -737,7 +765,7 @@ const retryStatusArm = function* (m, { ctx, flags }) {
     // #47 矩阵 #5:子代 lane 帧绝不骑主 spinner(无判别守卫的无条件 store 写=默认可疑)。
     if (typeof m.parentToolCallId === 'string')
         return;
-    // 🔴 六键全转(#3004 跟修批 2026-08-08):此前这里只挑 phase/detail/retryInSec 三键,attempt /
+    // 🔴 十一键全转(0.55.0;首建 #3004 跟修批 2026-08-08):此前这里只挑 phase/detail/retryInSec 三键,attempt /
     //    maxRetries / retryInMs 被剥在本层 —— 而 server 两腿的 brainStatusEventData 是全发的,
     //    `RetryStatus` 上也早就留好了 attempt/maxRetries 两位。键集真源 =
     //    `BRAIN_STATUS_PAYLOAD_KEYS`(engine-vocab G2-c 对实装 core 对账)。
@@ -761,6 +789,14 @@ const retryStatusArm = function* (m, { ctx, flags }) {
         //                  剥掉它 = 用户看得到「在重试」却看不到「谁失败了/该不该等」)。
         ...(typeof m.retryAtMs === 'number' ? { retryAtMs: m.retryAtMs } : {}),
         ...(typeof m.errorStatus === 'number' ? { errorStatus: m.errorStatus } : {}),
+        // ── 十一键(0.55.0;core 7.3.0 #530,server ≥7.58 `brainStatusEventData` 放行)──────────
+        // 🔴 **同一个病形的第五、第六例**,而且这一次剥掉的是**新相的全部内容**:
+        //    `waiting_first_token` 帧上除了 phase 就只有这两位携带信息(它不带 retryIn*/attempt/
+        //    errClass/errorStatus —— core 明说本相不宣告等待)。这层白名单不跟车,`mapBrainStatusToRetry`
+        //    的新 `waiting` 臂就只能收到一个空壳:kind 对了、秒数永远缺席,屏上那行渲不出「等了多久」。
+        //    ⇒ 加相**必同批加键**;键集真源仍是实装 core 的 `BrainStatus` 整个键集(G2-c 逐键等值门)。
+        ...(typeof m.elapsedMs === 'number' ? { elapsedMs: m.elapsedMs } : {}),
+        ...(typeof m.timeoutMs === 'number' ? { timeoutMs: m.timeoutMs } : {}),
     }, ctx.now());
     // `status === null` = 引擎直报 `recovered`(重试成功)。这一拍是**清除腿之一** —— 但间接腿
     // (TurnFlags 的「主 lane 内容帧到达即清」)可能已经清过了:已安装 core 在内容流跑完的 finally

package/dist/adapter/downstream/eventToSdkMessage.js

@@ -344,6 +344,11 @@ export function eventToSdkMessage(ev, ctx) {
             //    不等 SDK**,类型面缺席不等于 wire 上缺席。
             //    📋 **退役条件**:sdk 把这两位补进 `status` 臂声明的那一批,把它们并进上面的类型面直读、
             //    删掉本段的 `st2` 结构视图(与本批刚兑现的四键退役逐字同一条路)。
+            // 🔴 **0.55.0 又添两位,同一条退役路**(core 7.3.0 #530 / server ≥7.58 `brainStatusEventData`
+            //    放行):`elapsedMs`(第一个 token 已被等了多久)与 `timeoutMs`(这次等待的天花板)。
+            //    它们只在新相 `waiting_first_token` 上在场,而那一相**除了 phase 就只有这两位带信息** ——
+            //    本层剥掉 = 新相到了下游只剩一个空壳,屏上渲不出「等了多久」。sdk 的 `status` 臂同样尚未
+            //    声明这两位 ⇒ 与上面两位同款结构视图读,退役条件同(sdk 补声明的那一批一起并进类型面直读)。
             const st2 = ev;
             const num = (v) => typeof v === 'number' && Number.isFinite(v) ? v : undefined;
             const attempt = num(ev.attempt);
@@ -351,6 +356,8 @@ export function eventToSdkMessage(ev, ctx) {
             const retryInMs = num(ev.retryInMs);
             const retryAtMs = num(st2.retryAtMs);
             const errorStatus = num(st2.errorStatus);
+            const elapsedMs = num(st2.elapsedMs);
+            const timeoutMs = num(st2.timeoutMs);
             // 非空串才透传(空串既不是桶也不是「不知道」,只会在下游被渲成一个空的原因)。
             const errClass = typeof ev.errClass === 'string' && ev.errClass.length > 0 ? ev.errClass : undefined;
             return projected(stamp(ctx, armBody({
@@ -370,6 +377,11 @@ export function eventToSdkMessage(ev, ctx) {
                 //    **全链**(adapt 入口 → chrome 事件),所以漏任一层它都红。
                 ...(retryAtMs !== undefined ? { retryAtMs } : {}),
                 ...(errorStatus !== undefined ? { errorStatus } : {}),
+                // ── 0.55.0 跟车两位(core 7.3.0 #530 / server ≥7.58 放行)──────────────────────────
+                // 族扫同址:本条腿的**两层白名单**(本层 + `adapt/arms.ts` 的 `retryStatusArm`)本批同改,
+                // 与上面 0.48.0 那两位逐字同一个理由;漏任一层,新相 `waiting_first_token` 的秒数就到不了壳。
+                ...(elapsedMs !== undefined ? { elapsedMs } : {}),
+                ...(timeoutMs !== undefined ? { timeoutMs } : {}),
                 // 🔴 §E2 lane 身份必须透传(2026-08-08 对抗复审二轮复审命中的**跨 lane 状态破坏**)。
                 //    `status` 臂本来就是 `& EventIdentity`(SDK events.d.ts),server 两腿共用的
                 //    `brainStatusEventData` 也经 `identityFields` 发 eventId/parentToolCallId —— 而本层此前

package/dist/hitl/editedRuleTextPrecheck.d.ts

@@ -57,10 +57,35 @@
  * 🔴 `code` 是**开集串**:core 的 `RuleRejectCode` 词表属主是引擎,本包**刻意不镜像那张枚举**
  *    (镜像 = 引擎加员当天把一个合法值判没,#157 词表纪律的反面)。要分支就按串比,未知值原样呈现。
  */
+/**
+ * core 7.3.0(design/382 §3.3-5)—— 关于一条**已被接受**的规则的**宽度提示**。
+ * 🔴 **提示不是拒绝**:拒绝集一字未动,这一位说的是「这条规则比这张卡宽,持有人该知道」
+ *    (`Bash(adb:*)` admits every argument form of `adb`)。渲不渲、怎么渲是端的事;引擎保证的是
+ *    另一半 —— 走 edit 臂确认时命中码会写进记录(`edited.warnings`),「宽度在点头之前被说出来过」
+ *    因此是可审计的事实。
+ * 🔴 `code` 在本包是**开集串**,与本文件 `code?: string` 那一位同一条纪律:core 的
+ *    `EditedRuleBreadthWarning['code']` 今天是 `'broad_prefix' | 'compound_prefix'` 两员,
+ *    镜像那张枚举 = 引擎加员当天把一个合法值判没(#157 词表纪律的反面)。
+ */
+export interface EditedRuleBreadthWarning {
+    /** 开集串(见类型注)。未知码原样呈现,绝不因为不认得就丢掉这条提示。 */
+    readonly code: string;
+    /** 基线措辞(端可改写,**绝不可反转**;与 §3.5 的 reason 基线同契约)。 */
+    readonly message: string;
+}
 export type EditedRuleTextPrecheck = {
     ok: true;
     /** 真正会落库的那一形(可能与输入字节不同 —— 拼写归一)。内联反馈显示**这一形**。 */
     canonicalRule: string;
+    /**
+     * core 7.3.0 跟车一位(B-003 批抬 devDep core ^7.1.0 → ~7.3.0 时由 engine-vocab G4 形对账
+     * 抓出:「ok 臂键集恰 {ok, canonicalRule}」当场翻红,core 真返回三键)。**ADDITIVE,缺席 =
+     * 没什么可说的**(不是「没有提示 = 规则很窄」的反推位)。
+     * 🔴 本包只做**类型面转出**:这条腿是端口注入(值从 core 原样穿过,本层零加工),所以镜像
+     *    漏这一位不会剥掉运行期的值,漏掉的是**消费端的类型面可见性** —— 端读不到就不会渲,
+     *    「宽度在点头之前被说出来」这件事就只剩引擎那半边。
+     */
+    warnings?: readonly EditedRuleBreadthWarning[];
 } | {
     ok: false;
     /** 验证器自己拒时在场;coverage 闸拒时缺席(开集串,见类型注)。 */

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;