@sema-agent/client-core 0.77.1 → 0.77.2

package/dist/retryStatus.d.ts

@@ -1,156 +1,39 @@
-/**
- * retryStatus.ts — BrainStatus liveness(§E3/§E10 `status` 臂)→ spinner retry 行状态(PURE)。
- * cli src/sema/retryStatusStore.ts 的 mapBrainStatusToRetry 逐字搬运,唯一改动 = **时钟注入**
- * (原版读 Date.now(),库里由调用方给 nowMs,跨端确定性 + 可测)。187 语义对位:
- *   reconnecting → stalled  → '✻ Waiting for API response · will retry in Ns · check your network'
- *   retrying     → error    → '✻ API error · Retrying in Ns'(非终态;187 硬编码 'API error')
- *   rate_limited → error    → '✻ Usage limit reached · Retrying in Ns'(rateLimits 真 ⇒ 终态)
- *   circuit_open → error    → '✻ <detail|Service temporarily unavailable> · Retrying in Ns'
- *   recovered    → null     → 覆盖层摘掉(重试**成功**,不是错误 —— 见下)
- *   gave_up      → error+terminal → '✻ <detail>'(重试用尽的终态;与 recovered 反向。**打 terminal 位**,
- *                                    渲染面据此不得再接「· Retrying in Ns」——已经没有下一次了)
- *   waiting_first_token → waiting → '✻ Waiting for the model's first token · Ns [/ Ns]'(core 7.3.0 /
- *                                    #530;0.55.0 接。**非错误、非重连**:模型已连上,正在生成前的静默。
- *                                    携 elapsedMs/timeoutMs;本臂是 error 臂的结构超集 —— 老宿主的
- *                                    else 臂照旧渲 0.54.0 那一行,零行为差异零崩渲,见该臂顶注)
- * 绝不捏造 attempt 计数——只用引擎真给的 phase / detail / retryInSec / retryInMs / attempt /
- * maxRetries / errClass / retryAtMs / errorStatus(core 7.0.x 起**九键**、7.3.0 起 +`elapsedMs`/`timeoutMs` 成**十一键**;0.48.0 补齐后两位,
- * 族扫账见 {@link BRAIN_STATUS_PAYLOAD_KEYS} 末段)。
- *
- * 🔴 员数与字段补全(2026-08-08,#3004 跟修批)。此前本文件只列 4 相 + 3 字段,而引擎侧
- * (core `BrainStatusPhase` / `BrainStatus`,dist/core/types.d.ts)是 **6 相 + 6 字段**,server 两腿的
- * `brainStatusEventData`(dist/trace/project.js)把 attempt/maxRetries/retryInMs 全发。两处后果:
- *   · `recovered`(引擎重试**成功**的终态)落 `default:` 臂 ⇒ 被渲成 `kind:'error'`,即
- *     「刚刚恢复」被渲成「API error · Retrying」—— 方向完全相反的谎报;
- *   · attempt/maxRetries/retryInMs 在本层被剥掉 ⇒ `RetryStatus` 上早就留好的 attempt/maxRetries
- *     两位恒缺席。这不是「不许编造」(那条纪律没错),是**供给方给了却没接**。
- * 反漂移腿:`scripts/run-engine-vocab-floor-test.mjs` G2-b/G2-c 拿下面两张运行期镜像对**实装
- * @sema-agent/core** 的 `BrainStatusPhase` / `BrainStatus` 逐词逐键对账 —— 引擎再加相/加键,那边先红。
- */
-export type RetryStatus = 
-/** 等 API 响应(`reconnecting`)。**计数两位在场**:实装 core 的 reconnecting 帧与 retrying/
- *  rate_limited 同形,六字段全发(`stream-engine.js` 三处 `sleepAnnouncingRetry` 逐处实测)——
- *  丢掉它们正好是在「用户最需要看重连进度」的那一刻把进度藏起来(2026-08-08 对抗复审命中)。 */
-{
+export type RetryStatus = {
     kind: 'stalled';
     deadline: number;
     attempt?: number;
     maxRetries?: number;
-    /** 见 {@link BrainStatusPayload.errClass}(引擎给了才在场;本层只透传,措辞是壳半场)。 */
     errClass?: BrainRetryErrClass | (string & {});
-    /** 见 {@link BrainStatusPayload.retryAtMs}。🔴 **产生者铸的墙钟截止点**;在场时端应当拿它
-     *  渲倒计时,而不是拿 {@link deadline} —— 后者是**本层**按 `nowMs + 剩余量` 现算的,跨进程跳
-     *  的传输耗时已经把它推后了(core 顶注点名的正是这个病)。缺席 ⇒ 退回 `deadline`。 */
     retryAtMs?: number;
-    /** 见 {@link BrainStatusPayload.errorStatus}(引擎给了才在场;缺席禁渲成 0/未知码)。 */
     errorStatus?: number;
-    /** 见 {@link BrainStatusPayload.elapsedMs}(引擎给了才在场;本层零重算)。 */
     elapsedMs?: number;
-    /** 见 {@link BrainStatusPayload.timeoutMs}(引擎给了才在场;缺席禁渲成 0)。 */
     timeoutMs?: number;
-    /**
-     * 🔴 0.68.0(L-246)—— 引擎给的**中性人话提示**(`BrainStatus.detail`;server 已脱敏 + 限 300 字)。
-     *
-     * 修前这一位只在两条 `error` 臂上被读(`circuit_open` / `gave_up` 各拿它当 `error.formatted`),
-     * `stalled` 臂**整只丢掉**它 —— 于是「为什么还在等」这句唯一由引擎产出的解释,恰恰在**最长的
-     * 那一段等待**上看不见,端只好自己按 `errClass` 拼一句泛泛的话(而那正是措辞该由产生者单铸的
-     * 反例)。⇒ 原样透传,**一个字不改写、不截断**(显示封顶归端,它才知道自己的行宽)。
-     * 🔴 缺席 ⇒ 键不铸(空串同理):一格空白的解释比没有解释更坏。
-     */
     detail?: string;
 } | {
     kind: 'error';
     deadline: number;
     attempt?: number;
     maxRetries?: number;
-    /** 见 {@link BrainStatusPayload.errClass}(引擎给了才在场;本层只透传,措辞是壳半场)。 */
     errClass?: BrainRetryErrClass | (string & {});
-    /** 见 {@link BrainStatusPayload.retryAtMs}(与 `stalled` 臂同义同纪律:在场优先于 `deadline`)。 */
     retryAtMs?: number;
-    /** 见 {@link BrainStatusPayload.errorStatus}。CC parity:`system/api_retry.error_status`
-     *  就是这个数,端可据它渲「API error 529」这类**点名失败方**的行(CC 语料直证该行是小写 `API error`
-     *  且不渲码;状态码是端的超集追加 —— 档 §3g 取证订正 2026-09-01)。 */
     errorStatus?: number;
-    /**
-     * 🔴 **终态位**(2026-08-08 对抗复审命中):`true` ⇔ 引擎**不会再重试了**(`gave_up` 相)。
-     * 缺席 = 仍在重试循环里(retrying / rate_limited / circuit_open)。
-     *
-     * 为什么必须有这一位:`deadline` 的语义是「距下次重试」,而 gave_up 根本没有下次 —— 实装 core
-     * 的 finally 只发 `{phase:'gave_up', detail:'retries exhausted'}`(**不带** attempt/maxRetries,
-     * 所以消费方也无法靠「3/3」推出耗尽)。没有这一位,187 那套「<detail> · Retrying in Ns」句式
-     * 会把一次**已经放弃**渲成「正在重试,还剩 0 秒」——终帧稍有延迟,这句谎就一直挂着。
-     * 渲染措辞是壳半场(本包不渲染),本位只保证那个事实到得了壳。
-     */
     terminal?: true;
     error: RetryStatusErrorPayload;
-    /** 见 {@link BrainStatusPayload.elapsedMs}(引擎给了才在场;本层零重算)。 */
     elapsedMs?: number;
-    /** 见 {@link BrainStatusPayload.timeoutMs}(引擎给了才在场;缺席禁渲成 0)。 */
     timeoutMs?: number;
-}
-/**
- * **等第一个 token**(core 7.3.0 / #530 的 `waiting_first_token` 相,0.55.0 接):请求已经发出、
- * 模型已经连上,只是**还没吐出第一个字**。它既不是错误,也不是重连 —— 没有任何一次尝试失败过,
- * 引擎也不是在**宣告**一次等待,而是在**观测**一次等待(core 顶注逐字:"no wait is being
- * announced, a wait is being OBSERVED")。
- *
- * 🔴 **为什么必须单开一个 kind**(病形:上游闭集加员落 default 臂 ⇒ 新状态被渲成**最像的旧状态**):
- *    0.54.0 及以前本相落 `mapBrainStatusToRetry` 的 `default:` 臂 ⇒ 投成 `{kind:'error'}`,壳把
- *    「在等第一个字」渲成一条**错误色**的 `API error` 行(无 eta、无 attempt)。方向相反的谎报,
- *    与 #3004 修的 `recovered`(重试**成功**被渲成 `API error`)逐字同族。用户报案形正是这一条。
- *
- * 🔴 **本臂刻意是 `error` 臂的结构超集 —— 这是加员的兼容形,不是冗余**:一个还不认得
- *    `'waiting'` 的宿主(desktop / web-client 尚未跟车)其 `if (kind==='stalled') … else …` 的
- *    else 臂会照旧读到 `error` / `deadline` / `terminal`,渲出与 **0.54.0 逐字节相同**的那一行。
- *    少了 `error` 这一位,老宿主的 `status.error.rateLimits` 就是一次 TypeError —— 渲染路径裸抛
- *    = 整屏崩([render-path-must-not-throw]),把「一行渲错」升级成「一屏全没」。
- *    判据写进门:`run-client-core-pure-test.mjs` G6-d「老宿主归约视图对本相的输出 ≡ 0.54.0 对
- *    同一 payload 的输出」。认得本 kind 的宿主拿 {@link elapsedMs} / {@link timeoutMs} 渲真话。
- */
- | {
+} | {
     kind: 'waiting';
-    /**
-     * 🔴 **兼容位,不是一个真等待的截止点**:core 明说本相**绝不带** `retryInMs`/`retryAtMs`
-     * (它不宣告等待),故本位恒 = 映射时刻的 `nowMs` ⇒ 渲染面按「剩余量 ≤ 0」自然不渲倒计时。
-     * 它在场只为让**老宿主**的 else 臂算得出数而不是 NaN;**认得本 kind 的宿主不得拿它渲倒计时**
-     * ——「距下次重试」在本相根本没有所指。要渲进度,读 {@link elapsedMs} / {@link timeoutMs}。
-     */
     deadline: number;
     attempt?: number;
     maxRetries?: number;
-    /** 见 {@link BrainStatusPayload.errClass}(core 不变式:本相恒缺席;本层不写特判,给了就透)。 */
     errClass?: BrainRetryErrClass | (string & {});
-    /** 见 {@link BrainStatusPayload.retryAtMs}(core 不变式:本相恒缺席;本层不写特判,给了就透)。 */
     retryAtMs?: number;
-    /** 见 {@link BrainStatusPayload.errorStatus}(core 不变式:本相恒缺席;本层不写特判,给了就透)。 */
     errorStatus?: number;
-    /** 已经等了多久(ms)。见 {@link BrainStatusPayload.elapsedMs};缺席 = 引擎没给,禁渲 0。 */
     elapsedMs?: number;
-    /** 这次等待的天花板(ms)。见 {@link BrainStatusPayload.timeoutMs};缺席 = 不渲「/ Ns」。 */
     timeoutMs?: number;
-    /**
-     * 🔴 **恒缺席**(`?: never`):等第一个 token **不是**终态 —— 引擎还在等,首 token 到了会补
-     * `recovered`、彻底失败会补 `gave_up`。这一位写在型上只为让**老宿主**那句 `status.terminal`
-     * 在加员后仍然编译得过(union 各员都得有这个键才允许直接读),值上永不 stamp。
-     */
     terminal?: never;
-    /**
-     * 🔴 **兼容位**:`formatted` 恒为空串 —— 与 0.54.0 的 `default:` 臂逐字节相同(那一臂也是
-     * `{ formatted: '' }`)。本相**没有错误**,所以这里也不许编一句错误文案出来;它存在的唯一
-     * 理由是老宿主的 else 臂要读得到这个对象(见上文 G6-d)。新宿主**不得**读本位当错误证据 ——
-     * 判「有没有错」的量是 `kind`,不是这个恒空的壳([anchor-on-the-deciding-quantity])。
-     */
     error: RetryStatusErrorPayload;
 };
-/**
- * `error` 载荷的**具名形**。
- * 🔴 具名不是风格偏好,是 typeshape 门 B4 的硬要求:导出签名里的**内联匿名形(≥3 成员)**受棘轮
- * 管(只降不升)—— 0.55.0 的 `waiting` 臂复用同一个形,再内联抄一份就是把同一个结构写第三遍、
- * 并把棘轮顶高一格。具名后结构与此前**逐字节相同**(TS 结构化类型 ⇒ 对消费端零差异,不是收窄),
- * 而且这一形从此只有**一处**定义 —— 三个臂再也不可能各自漂。
- * 🔴 **刻意不导出**:它是 `RetryStatus` 的内部构件,公面契约仍是 `RetryStatus` 本身
- * (公面导出表是登记制,加一个名字要走那张表;这一位没有独立的消费理由)。
- */
 interface RetryStatusErrorPayload {
     formatted: string;
     isNetworkDown?: boolean;
@@ -162,124 +45,22 @@ interface RetryStatusErrorPayload {
         rateLimitType?: string;
     } | null;
 }
-/**
- * core `BrainStatusPhase` 的**运行期值拷贝**(engine-vocab 门 G2-b 拿它对实装 core 对账)。
- * 引擎侧是闭集,**读时按开集处理** —— 一个部署可以在自己的通道上冒出别的相,认得的分支照走,
- * 认不得的落 `default:` 兜底(见 {@link mapBrainStatusToRetry} 末臂)。
- */
 export declare const BRAIN_STATUS_PHASES: readonly ["rate_limited", "retrying", "reconnecting", "circuit_open", "recovered", "gave_up", "waiting_first_token"];
 export type BrainStatusPhase = (typeof BRAIN_STATUS_PHASES)[number];
-/**
- * core `BrainRetryErrClass`(5.43.0)的**类型面镜像** —— 一次重试等待的**原因分桶**,
- * provider 中立(绝不是 HTTP 状态码 / syscall code / provider 分类法;那些不许过这条通道):
- *   · `connect_refused` 目标本身给了确定否定(该地址没人 accept / 名字无地址)—— 短梯队服务的那一类;
- *   · `transport`       其余传输层失败(connect 超时 / reset / 流中断)—— 全梯队;
- *   · `stall`           连上了、也没断,但**不出字节**(流停滞)—— 与 `transport` 分家的理由见下;
- *   · `rate_limit`      provider 要求放慢;
- *   · `server`          provider 自报自己这边出错;
- *   · `http`            状态谓词判终态、但 provider 自己的显式重试裁定说重试;
- *   · `output_cap`      根本不是连接失败:provider 报上下文超限后按更低 output cap 重发(无退避)。
- *
- * 🔴 **刻意没有运行期值镜像**(与 {@link BRAIN_STATUS_PHASES} 不同):本包对 errClass **零分支**
- * (纯透传),少一个成员没有任何行为后果 —— 开集读会把不认得的桶原样带过去。而 phase 是有 switch
- * 分支的,少一相会落 default 臂被渲成错话,所以那张表才需要运行期镜像 + engine-vocab 等值门。
- * 判据锚在「真正决定结果的量」上:决定结果的是有没有分支,不是有没有一张表。
- */
 export type BrainRetryErrClass = 'connect_refused' | 'transport' | 'stall' | 'rate_limit' | 'server' | 'http' | 'output_cap';
-/** wire 上 `status` 臂的载荷(= core `BrainStatus`;server 两腿白名单原样转发这 **11** 键(7.3.0 起含 `elapsedMs`/`timeoutMs`)——
- *  真源 = server 7.58.0 `dist/trace/project.js` 的 `brainStatusEventData`,逐条条件拷贝)。 */
 export interface BrainStatusPayload {
-    /** 闭集 + `(string & {})`:未知相仍可携带(开集读),不必先改类型再解析。 */
     phase: BrainStatusPhase | (string & {});
-    /** 中性人话提示(无 provider/HTTP 细节;server 已脱敏 + 限 300 字)。 */
     detail?: string;
-    /** 距下次重试的秒数(= `ceil(retryInMs/1000)`,core circuit-breaker 与 ms 位同发)。 */
     retryInSec?: number;
-    /** 距下次重试的毫秒数 —— **更精的同一个量**,在场时优先于 `retryInSec`。 */
     retryInMs?: number;
-    /** 引擎真实的第几次尝试(1-based)。缺席 = 引擎没给,绝不折成 0。 */
     attempt?: number;
-    /** 引擎这一轮的重试上限。与 `attempt` 一起才能渲「2/5」。 */
     maxRetries?: number;
-    /**
-     * core 7.0.x(#506 ㋑;server ≥7.53 `brainStatusEventData` 真发;ADDITIVE,0.48.0 补)——
-     * 本次退避**预计结束的墙钟时刻**(epoch ms)= 发帧那一刻的 `Date.now() + retryInMs`,
-     * **由产生者铸**。不变式(core 顶注逐字):`retryInMs` 在场时它必在场,不宣告等待的帧
-     * (`recovered` / `gave_up` / output-cap 立即重发)上必缺席。
-     *
-     * 🔴 **为什么这一位必须由上游给、消费端不许自己算**(core 顶注的原话,也是本包接它的理由):
-     * `Date.now() + retryInMs` 只对**瞬时收到帧**的读者成立。中间隔了若干进程跳(core → server →
-     * 本包 → 端)之后再自己加,得到的截止点已经被传输耗时推后了;而 core 对 >30s 的等待会每 30s
-     * **重播一帧并递减**,于是「自己算」的倒计时在每个重播片上**重新起跳**而不是收敛。
-     * 🔴 **时钟域,明说以消除歧义**:墙钟(`Date.now()`),**不是**单调钟。端不得拿它与自己的
-     * 单调计时器比;跨机器/跨授时校正时它是**近似值** —— 权威的**相对**量始终是 `retryInMs`,
-     * 本位是由它派生的绝对便利位。
-     */
     retryAtMs?: number;
-    /**
-     * core 7.0.x(#506 ㋑;server ≥7.53 `brainStatusEventData` 真发;ADDITIVE,0.48.0 补)——
-     * **刚刚失败的那次尝试**的 HTTP 状态码。这条通道上**唯一**一个 provider 自报的数字
-     * (其余一切仍走引擎自己的中性分桶 `phase` / `errClass`)。
-     *
-     * 🔴 **为什么这条一贯拒绝 HTTP 细节的通道要收它**(core 顶注的原话):要让操作者判断
-     * 「该等,还是该去修点什么」,两个中性桶**供不出**这个信息 —— `rate_limit` 同时盖住
-     * 「provider 自己会清掉的 429」与「账号配额耗尽的 429」,`server` 同时盖住 500 与
-     * 负载均衡器后面的 503。CC 在**同一场合**报同一个数(`system/api_retry.error_status`,
-     * 读自 `APIError.status`)⇒ 接它同时满足 CC parity 与本通道的中立契约。
-     * 🔴 **在场面是封闭的,缺席不许反推**:只在「这次尝试拿到了一个**点名了失败**的应答」时在场
-     * (连接梯的 retry 等待 + output-cap 的 400)。**恒缺席**于:传输层失败(压根没有应答)、
-     * 流中断(那条应答自己的状态是**成功**,一个什么都没失败的状态不许被当成重试的原因)、
-     * `circuit_open`(本地快失败,没发出去)、`recovered`/`gave_up`(不宣告任何尝试)。
-     * ⇒ 端**禁**把缺席渲成 0 或「未知错误码」;那两类的因由由 `errClass` 按构造点名。
-     * 🔴 **与 CC 的可空必填不同**:CC 有一整条 `system/api_retry` 消息专供重试场合,能把键设成
-     * 必填可空;本形是**所有 phase 共用的一个形**,所以是可选位(core 顶注同款理由)。
-     */
     errorStatus?: number;
-    /**
-     * core 5.43.0(#307 双扫 S44,2026-08-19;ADDITIVE)——**这次等待的原因分桶**
-     * (core `BrainRetryErrClass`,provider 中立闭集)。与 `phase`(引擎正在**做什么**)互补:
-     * 本键说的是**为什么**。只在**重试等待帧**上在场且引擎分得出类;`recovered`/`gave_up` 两个终态帧
-     * 与 `circuit_open`(本地快失败,不是观测到的失败)上刻意缺席。
-     *
-     * 🔴 **闭集 + `(string & {})`,读时按开集处理**,与 `phase` 同款纪律:一个部署可以在自己的通道上
-     * 冒出别的桶,认得的照走、认不得的原样带过去 —— 绝不因为「不认得」就把这次等待的原因抹成缺席
-     * (那是把引擎真给的量在本层剥掉,#3004 那批修的正是这一类)。
-     * 缺席 = 引擎没分类,**不得**被渲成某个默认桶。
-     *
-     * 分工:本包只负责让这个事实到得了壳(投影/透传保真),措辞与是否上屏是壳半场。
-     */
     errClass?: BrainRetryErrClass | (string & {});
-    /**
-     * core 7.3.0(#530;server ≥7.58 `brainStatusEventData` 真发;ADDITIVE,0.55.0 补)——
-     * 在一帧 `waiting_first_token` 上:**第一个 token 已经被等了多久**(ms,发帧那一刻,发帧进程
-     * 自己的钟;跨进程跳是近似值)。core 顶注:`Absent on every other phase`。
-     *
-     * 🔴 缺席禁折 0:「不知道等了多久」与「等了 0 毫秒」是两件事,后者会让屏上那行秒数恒 0
-     *    ([honest-absence-not-fabricated-zero])。
-     */
     elapsedMs?: number;
-    /**
-     * core 7.3.0(#530;server ≥7.58 `brainStatusEventData` 真发;ADDITIVE,0.55.0 补)——
-     * 在一帧 `waiting_first_token` 上:**已武装的首 token 看门狗**(ms)= 这次等待的天花板,
-     * 消费方据它渲「45s of 120s」。core 顶注:`Absent on every other phase`。
-     *
-     * 🔴 与 `retryInMs` 不是同一个量,**绝不可互换**:那一位是「还要等多久才重试」(引擎在宣告一次
-     *    等待),本位是「这次等待最多容忍多久」(引擎在观测一次等待)。把本位当倒计时渲,渲出来的是
-     *    一个从不递减的数。
-     */
     timeoutMs?: number;
 }
-/**
- * 上面那个 interface 的**运行期键镜像**(照 `TOOL_APPROVAL_FRAME_KEYS_MIRROR` 先例):
- * engine-vocab 门 G2-c 拿它与 core `BrainStatus` 的键集逐元素比 ⇒ 引擎 additive 增键当天红。
- * 下面两个类型钉保证镜像与 interface 之间不可能漂移(少键/多键都是编译错)。
- */
 export declare const BRAIN_STATUS_PAYLOAD_KEYS: readonly ["phase", "detail", "retryInSec", "retryInMs", "attempt", "maxRetries", "errClass", "retryAtMs", "errorStatus", "elapsedMs", "timeoutMs"];
-/**
- * BrainStatus 载荷 → spinner 行状态。
- *
- * 返回 **`null` = 没有覆盖层**(不是「不知道」):今天只有 `recovered` 走这条 —— 引擎明说这次重试
- * 已经成功,行就该摘掉。此前本函数返回型钉死非空,于是 `recovered` 只能被塞进 error 臂。
- */
 export declare function mapBrainStatusToRetry(p: BrainStatusPayload, nowMs: number): RetryStatus | null;
 export {};

package/dist/retryStatus.js

@@ -1,37 +1,3 @@
-/**
- * retryStatus.ts — BrainStatus liveness(§E3/§E10 `status` 臂)→ spinner retry 行状态(PURE)。
- * cli src/sema/retryStatusStore.ts 的 mapBrainStatusToRetry 逐字搬运,唯一改动 = **时钟注入**
- * (原版读 Date.now(),库里由调用方给 nowMs,跨端确定性 + 可测)。187 语义对位:
- *   reconnecting → stalled  → '✻ Waiting for API response · will retry in Ns · check your network'
- *   retrying     → error    → '✻ API error · Retrying in Ns'(非终态;187 硬编码 'API error')
- *   rate_limited → error    → '✻ Usage limit reached · Retrying in Ns'(rateLimits 真 ⇒ 终态)
- *   circuit_open → error    → '✻ <detail|Service temporarily unavailable> · Retrying in Ns'
- *   recovered    → null     → 覆盖层摘掉(重试**成功**,不是错误 —— 见下)
- *   gave_up      → error+terminal → '✻ <detail>'(重试用尽的终态;与 recovered 反向。**打 terminal 位**,
- *                                    渲染面据此不得再接「· Retrying in Ns」——已经没有下一次了)
- *   waiting_first_token → waiting → '✻ Waiting for the model's first token · Ns [/ Ns]'(core 7.3.0 /
- *                                    #530;0.55.0 接。**非错误、非重连**:模型已连上,正在生成前的静默。
- *                                    携 elapsedMs/timeoutMs;本臂是 error 臂的结构超集 —— 老宿主的
- *                                    else 臂照旧渲 0.54.0 那一行,零行为差异零崩渲,见该臂顶注)
- * 绝不捏造 attempt 计数——只用引擎真给的 phase / detail / retryInSec / retryInMs / attempt /
- * maxRetries / errClass / retryAtMs / errorStatus(core 7.0.x 起**九键**、7.3.0 起 +`elapsedMs`/`timeoutMs` 成**十一键**;0.48.0 补齐后两位,
- * 族扫账见 {@link BRAIN_STATUS_PAYLOAD_KEYS} 末段)。
- *
- * 🔴 员数与字段补全(2026-08-08,#3004 跟修批)。此前本文件只列 4 相 + 3 字段,而引擎侧
- * (core `BrainStatusPhase` / `BrainStatus`,dist/core/types.d.ts)是 **6 相 + 6 字段**,server 两腿的
- * `brainStatusEventData`(dist/trace/project.js)把 attempt/maxRetries/retryInMs 全发。两处后果:
- *   · `recovered`(引擎重试**成功**的终态)落 `default:` 臂 ⇒ 被渲成 `kind:'error'`,即
- *     「刚刚恢复」被渲成「API error · Retrying」—— 方向完全相反的谎报;
- *   · attempt/maxRetries/retryInMs 在本层被剥掉 ⇒ `RetryStatus` 上早就留好的 attempt/maxRetries
- *     两位恒缺席。这不是「不许编造」(那条纪律没错),是**供给方给了却没接**。
- * 反漂移腿:`scripts/run-engine-vocab-floor-test.mjs` G2-b/G2-c 拿下面两张运行期镜像对**实装
- * @sema-agent/core** 的 `BrainStatusPhase` / `BrainStatus` 逐词逐键对账 —— 引擎再加相/加键,那边先红。
- */
-/**
- * core `BrainStatusPhase` 的**运行期值拷贝**(engine-vocab 门 G2-b 拿它对实装 core 对账)。
- * 引擎侧是闭集,**读时按开集处理** —— 一个部署可以在自己的通道上冒出别的相,认得的分支照走,
- * 认不得的落 `default:` 兜底(见 {@link mapBrainStatusToRetry} 末臂)。
- */
 export const BRAIN_STATUS_PHASES = [
     'rate_limited',
     'retrying',
@@ -39,17 +5,8 @@ export const BRAIN_STATUS_PHASES = [
     'circuit_open',
     'recovered',
     'gave_up',
-    // core 7.3.0 跟车一相(#530;0.55.0)——「等第一个 token」。加员的**理由**与 recovered 那一相
-    // 逐字同族:少一相 ⇒ 它落 `mapBrainStatusToRetry` 的 default 臂被渲成错误行。engine-vocab G2-b
-    // 对**实装 core** 逐词对账(本批 devDep ^7.1.0 → ^7.4.0 后那道门先红后绿,红文逐字:
-    // 「漏:waiting_first_token」)。
     'waiting_first_token',
 ];
-/**
- * 上面那个 interface 的**运行期键镜像**(照 `TOOL_APPROVAL_FRAME_KEYS_MIRROR` 先例):
- * engine-vocab 门 G2-c 拿它与 core `BrainStatus` 的键集逐元素比 ⇒ 引擎 additive 增键当天红。
- * 下面两个类型钉保证镜像与 interface 之间不可能漂移(少键/多键都是编译错)。
- */
 export const BRAIN_STATUS_PAYLOAD_KEYS = [
     'phase',
     'detail',
@@ -57,70 +14,24 @@ export const BRAIN_STATUS_PAYLOAD_KEYS = [
     'retryInMs',
     'attempt',
     'maxRetries',
-    // core 5.43.0 跟车一键(#307 双扫 S44,2026-08-19):engine-vocab G2-c 对实装 core 逐键对账。
     'errClass',
-    // ── core 7.0.x 跟车**两键**(0.48.0;#506 ㋑)────────────────────────────────────────────
-    // 🔴 **族扫的产物,不是只补触发本批的那一个**([same-shape-residue-constitution]):本批的
-    //    派工单只点名了 `errorStatus`。族扫 = 把实装 core 的 `BrainStatus` **整个键集**与本镜像逐一
-    //    对表(而不是只补被点名的那一位),当场捞出**存量**漏键 `retryAtMs` —— 它与 errorStatus 同批
-    //    进 core、同在 server `brainStatusEventData` 的白名单里真发,只是没人提。
-    //    病形与 0.47.0 的 `task_progress.model` 逐字同族:上游真发、本层闭形镜像剥掉、两边代码看着都对。
-    //    engine-vocab G2-c 的等值门本批**先红后绿**,红文逐字:「漏:retryAtMs,errorStatus」。
     'retryAtMs',
     'errorStatus',
-    // ── core 7.3.0 跟车**两键**(0.55.0;#530)────────────────────────────────────────────────
-    // 与 4) 的相位加员同一批上游变更:core 在 `BrainStatus` 上加了 elapsedMs/timeoutMs 两位,
-    // server 7.58.0 的 `brainStatusEventData` 白名单同批放行。镜像不跟 ⇒ G2-c 等值门红。
     'elapsedMs',
     'timeoutMs',
 ];
 const _brainStatusKeyPin = [true, true];
 void _brainStatusKeyPin;
-/**
- * BrainStatus 载荷 → spinner 行状态。
- *
- * 返回 **`null` = 没有覆盖层**(不是「不知道」):今天只有 `recovered` 走这条 —— 引擎明说这次重试
- * 已经成功,行就该摘掉。此前本函数返回型钉死非空,于是 `recovered` 只能被塞进 error 臂。
- */
 export function mapBrainStatusToRetry(p, nowMs) {
-    // 退避剩余量:ms 位在场就用 ms(1200ms 用 sec 位会被 ceil 成 2s,行上少一秒多一秒都是谎)。
     const remainingMs = typeof p.retryInMs === 'number' ? p.retryInMs : (p.retryInSec ?? 0) * 1000;
     const deadline = nowMs + Math.max(0, remainingMs);
-    /** 引擎真给的计数才落位;缺席 ⇒ 键不 stamp(诚实缺席,不造 0)。 */
     const counts = {
         ...(typeof p.attempt === 'number' ? { attempt: p.attempt } : {}),
         ...(typeof p.maxRetries === 'number' ? { maxRetries: p.maxRetries } : {}),
     };
-    /**
-     * 原因桶(#307 S44):引擎真给的**非空串**才落位。缺席 / 空串 / 非串 ⇒ 键不 stamp
-     * ——「不知道为什么等」渲成缺席,绝不折成某个默认桶。开集:不认得的桶原样带过去
-     * (本层零分支,认不得也没有可落错的臂)。
-     */
     const cause = typeof p.errClass === 'string' && p.errClass.length > 0 ? { errClass: p.errClass } : {};
-    /**
-     * core 7.0.x 跟车两位(0.48.0),**原样透传、零重算**:
-     *  · `retryAtMs` —— 产生者铸的墙钟截止点。本层**刻意不拿它去改写** `deadline`:那一位是已发布的
-     *    行为面(0.29.0 起端就在读),换算法 = 一次静默的行为改动。两位并存、端自己选(在场优先),
-     *    是 additive 的唯一诚实形。
-     *  · `errorStatus` —— 刚失败那次尝试的 HTTP 状态。
-     * 🔴 **两位在终态帧(`recovered`/`gave_up`)与 `circuit_open` 上按 core 的不变式本就缺席**,
-     *    所以这里不写「终态就不透」的特判:该由 `terminal` 位管的事(渲染面不得再接倒计时)已经
-     *    有位管了,再加一道按键在场性的特判,等于让本层替上游重述一遍它自己的不变式 —— 上游哪天
-     *    改了不变式,特判就成了**本层单方面剥键**。判据锚在真正决定渲染的量(`terminal`)上,
-     *    不锚一个恰好同时成立的第二事实([anchor-on-the-deciding-quantity])。
-     */
     const producerTiming = typeof p.retryAtMs === 'number' ? { retryAtMs: p.retryAtMs } : {};
     const failureStatus = typeof p.errorStatus === 'number' ? { errorStatus: p.errorStatus } : {};
-    /**
-     * core 7.3.0 跟车两位(0.55.0),**原样透传、零重算**,并且**与其它键一样进 `extra`**
-     * (= 每个臂都透,不按相位写特判)。理由与上面 `producerTiming`/`failureStatus` 那段逐字同源:
-     * core 的不变式说这两位只在 `waiting_first_token` 上在场 —— 但**由 core 说,不由本层复述**。
-     * 本层若写「只有 waiting 臂才透 elapsedMs」,上游哪天把它铺到别的相,本层就成了单方面剥键
-     * (`task_progress.model` / `retryAtMs` 两次同形存量的病根)。判据锚在真正决定渲染的量
-     * (`kind`),不锚一个恰好同时成立的第二事实([anchor-on-the-deciding-quantity])。
-     */
-    // 两个进度位是引擎快照(ms):负数 / NaN / Infinity 不是「等了负久」,一律当缺席(0.55.0 发包扫描 [low] 采;
-    // 同一包的 eventToSdkMessage 腿对数值位同样只认有限非负数,两条腿同律)。
     const saneMs = (v) => typeof v === 'number' && Number.isFinite(v) && v >= 0 ? v : undefined;
     const elapsedMs = saneMs(p.elapsedMs);
     const timeoutMs = saneMs(p.timeoutMs);
@@ -128,12 +39,9 @@ export function mapBrainStatusToRetry(p, nowMs) {
         ...(elapsedMs !== undefined ? { elapsedMs } : {}),
         ...(timeoutMs !== undefined ? { timeoutMs } : {}),
     };
-    // 🔴 0.68.0(L-246):引擎那句中性提示。**只进 `stalled` 臂** —— 两条 error 臂上它已经是
-    //    `error.formatted` 的来源,同一句话在同一只读数上出现两次会让端不知道该渲哪一份。
     const stalledDetail = typeof p.detail === 'string' && p.detail.length > 0 ? { detail: p.detail } : {};
     const extra = { ...counts, ...cause, ...producerTiming, ...failureStatus, ...waitProgress };
     switch (p.phase) {
-        // 🔴 引擎直报「恢复」:摘行。绝不落 error 臂 —— 那是把成功渲成失败。
         case 'recovered':
             return null;
         case 'reconnecting':
@@ -147,23 +55,8 @@ export function mapBrainStatusToRetry(p, nowMs) {
                 ...extra,
                 error: { formatted: p.detail ?? 'Service temporarily unavailable', isNetworkDown: true },
             };
-        // 重试用尽:仍是错误行(与 recovered 反向,绝不许一起归成「结束了 ⇒ 清行」),但**打终态位** ——
-        // 实装 core 的 finally 只发 `{phase, detail}`(detail = 'retries exhausted' / 'cancelled while
-        // retrying'),既没有计数也没有 retryIn*,所以「不会再重试了」这件事**只能**由本位表达;
-        // 靠 attempt===maxRetries 去推是错的(供给方根本不发那两位)。
         case 'gave_up':
             return { kind: 'error', deadline, terminal: true, ...extra, error: { formatted: p.detail ?? '' } };
-        /**
-         * 🔴 core 7.3.0 / #530 加的第七相 —— 等第一个 token。**必须在 default 臂之前落自己的 kind**:
-         * 这一相走到 `default:` 就是本 bug 的根因(B-003 / L-108①)——「模型正在生成前的静默」被投成
-         * `{kind:'error'}`,壳照 `kind` 渲成错误色的 `API error` 行,用户看到的是「在重试」,而事实是
-         * 「在等第一个字」。这不是措辞问题:方向是反的(没有任何一次尝试失败过)。
-         *
-         * `error: { formatted: '' }` 与 `deadline` 是**兼容位**(见 `RetryStatus` 的 `waiting` 臂顶注):
-         * 老宿主的 else 臂据它们渲出与 0.54.0 **逐字节相同**的那一行 ⇒ 加员对未跟车的端零行为差异、
-         * 零崩渲。`terminal` 永不 stamp —— 首 token 到了 core 补 `recovered`(壳摘行),彻底失败补
-         * `gave_up`(壳翻终态错误行),等待本身从来不是终态。
-         */
         case 'waiting_first_token':
             return { kind: 'waiting', deadline, ...extra, error: { formatted: '' } };
         case 'retrying':

package/dist/rewindWireCaps.d.ts

@@ -1,36 +1,9 @@
-/**
- * ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2):cli src/sema/rewindWireCaps.ts 逐字搬入(零依赖)。
- */
-/**
- * src/sema/rewindWireCaps.ts — PURE CC Rewind (E18) field projection (no deps, testable). seamQuery imports it.
- *
- * Maps the CC /rewind MessageSelector modes → the engine's rewind fields (SDK TaskRequest, core 1.166.0;
- * resumeAtMode: core 1.292 [833]):
- *   both         = { resumeAt, resumeAtMode:"before", rewindFiles:true }   fork BEFORE the user message + tree
- *   conversation = { resumeAt, resumeAtMode:"before" }                     fork BEFORE the user message only
- *   code         = { rewindFilesTo }                restore the tree only, NO conversation fork (no setLeafId)
- * The target is a USER-MESSAGE SessionTreeEntry.id (server anchors user-message boundaries). Plus the per-turn
- * CAPTURE stamp (rewindFiles:true on a normal turn) so the engine snapshots the tree (else nothing to restore).
- *
- * resumeAtMode "before"(排他截,core 1.292):CC /rewind 的语义是「回到发这条消息之前」——被选中的
- * user message 回填输入框、从对话里移除;engine 侧对应 setLeafId(entry.parentId)。旧的含目标(inclusive
- * "at")形状会把该 user message 留在引擎历史里 → 模型仍记得(暗号复现 bug)。老 server 未透传该字段时
- * 行为退回含目标(version-safe,无回归——等 server 透传)。
- */
-/** A one-shot rewind RESTORE instruction (or the per-turn capture stamp) projected onto a request. */
 export interface SeamRewindSpec {
     resumeAt?: string;
-    /** core 1.292([833]):"before" = 排他截(setLeafId(entry.parentId));缺省 "at" = 含目标。 */
     resumeAtMode?: 'at' | 'before';
     rewindFiles?: boolean;
     rewindFilesTo?: string;
 }
-/** The CC /rewind restore modes that hit the engine (summarize = compact, handled elsewhere). */
 export type RewindMode = 'both' | 'conversation' | 'code';
-/** Build the engine rewind fields for a chosen mode + target user-message entryId. */
 export declare function rewindSpecForMode(mode: RewindMode, targetEntryId: string): SeamRewindSpec;
-/**
- * PURE projection (no state): an armed one-shot RESTORE wins; else the per-turn CAPTURE stamp (when enabled);
- * else nothing. The caller consumes (clears) the arm after a restore.
- */
 export declare function projectRewind(pending: SeamRewindSpec | undefined, captureEnabled: boolean): SeamRewindSpec;

package/dist/rewindWireCaps.js

@@ -1,23 +1,3 @@
-/**
- * ⇄ B2 批搬迁(2026-07-27,多端改造设计稿 §3 B2):cli src/sema/rewindWireCaps.ts 逐字搬入(零依赖)。
- */
-/**
- * src/sema/rewindWireCaps.ts — PURE CC Rewind (E18) field projection (no deps, testable). seamQuery imports it.
- *
- * Maps the CC /rewind MessageSelector modes → the engine's rewind fields (SDK TaskRequest, core 1.166.0;
- * resumeAtMode: core 1.292 [833]):
- *   both         = { resumeAt, resumeAtMode:"before", rewindFiles:true }   fork BEFORE the user message + tree
- *   conversation = { resumeAt, resumeAtMode:"before" }                     fork BEFORE the user message only
- *   code         = { rewindFilesTo }                restore the tree only, NO conversation fork (no setLeafId)
- * The target is a USER-MESSAGE SessionTreeEntry.id (server anchors user-message boundaries). Plus the per-turn
- * CAPTURE stamp (rewindFiles:true on a normal turn) so the engine snapshots the tree (else nothing to restore).
- *
- * resumeAtMode "before"(排他截,core 1.292):CC /rewind 的语义是「回到发这条消息之前」——被选中的
- * user message 回填输入框、从对话里移除;engine 侧对应 setLeafId(entry.parentId)。旧的含目标(inclusive
- * "at")形状会把该 user message 留在引擎历史里 → 模型仍记得(暗号复现 bug)。老 server 未透传该字段时
- * 行为退回含目标(version-safe,无回归——等 server 透传)。
- */
-/** Build the engine rewind fields for a chosen mode + target user-message entryId. */
 export function rewindSpecForMode(mode, targetEntryId) {
     switch (mode) {
         case 'both':
@@ -28,10 +8,6 @@ export function rewindSpecForMode(mode, targetEntryId) {
             return { rewindFilesTo: targetEntryId };
     }
 }
-/**
- * PURE projection (no state): an armed one-shot RESTORE wins; else the per-turn CAPTURE stamp (when enabled);
- * else nothing. The caller consumes (clears) the arm after a restore.
- */
 export function projectRewind(pending, captureEnabled) {
     if (pending)
         return { ...pending };

package/dist/runCancelContext.d.ts

@@ -1,17 +1,3 @@
-/**
- * runCancelContext — run 记录上 server 自铸的**取消现场**侧记键 `cancelContext`(server ≥7.87.3 `PersistedTaskResult =
- * TaskResult & { cancelContext? }`,`dist/plugins/store-contracts.d.ts` `RunCancelContext` 四座)的三端共用读面,与
- * `turn_aborted{reason:'engine_error'}` 之后「到底是谁把这条 run 结掉的」的**成因判定**(0.74.3 CC-71;cli L-212 (a) 消费半场归包)。
- * sdk 9.7.1 对该键无型 ⇒ 按契约结构读。
- *
- * ── 🔴 读法 ─────────────────────────────────────────────────────────────────────────────────
- *  ① `cancelContext` 缺席 = 老 server / 这条 run 不是被取消的 / 记录形不带 —— **不折成「未取消」**,读数是 `not_reported`。
- *  ② 四座各自可缺席、各自防御读:`lastEventKind`(串)/ `lastEventAgeMs`(≥0 有限数)/ `elapsedMs`(≥0 有限数;绝不折 0)/
- *     `lastBrainStatus`(对象,原样带出不窄读)。「有 age 无 kind」是合法读数。
- *  ③ 成因判定 {@link classifyRunAbortCause}:只由 run 记录上的**机读证据**得出 —— `errorCode` ∈ 取消码 ⇒ `cancelled_by_user`;
- *     `cancelContext` 在场而码不是取消码 ⇒ 仍按码判(现场只是附注);码缺席 / 认不出 ⇒ `unknown`。**缺席不猜**。
- */
-/** 四座读数(在场才带)。 */
 export interface RunCancelContextView {
     readonly lastEventKind?: string;
     readonly lastEventAgeMs?: number;
@@ -24,7 +10,6 @@ export type RunCancelContextReading = {
     kind: 'present';
     context: RunCancelContextView;
 };
-/** run 记录(`runs.get` 回体 / `done.result`)→ 取消现场读数;记录非对象 ⇒ `undefined`(判不出,与 not_reported 分开)。 */
 export declare function readRunCancelContext(record: unknown): RunCancelContextReading | undefined;
 import { type RunTerminalRead } from './runTerminal.js';
 export type RunAbortCause = {
@@ -34,16 +19,12 @@ export type RunAbortCause = {
     kind: 'engine_error';
     code?: string;
     message?: string;
-}
-/** run 记录仍非终态:流断了而 run 还在(壳这一端的事实,不是 run 的成因)。`status` 原词。 */
- | {
+} | {
     kind: 'run_still_live';
     status?: string;
 } | {
     kind: 'unknown';
     terminal?: RunTerminalRead['kind'];
 };
-/** 取消码常量(server `CANCELLED_CODE` / sdk runs.d.ts 逐字)。 */
 export declare const RUN_CANCELLED_CODE: "cancelled";
-/** 壳带 `engineTaskId` 去 `runs.get` 拿回的记录 ⇒ 成因。只由机读证据得出;缺席不猜。 */
 export declare function classifyRunAbortCause(record: unknown): RunAbortCause;

package/dist/runCancelContext.js

@@ -1,23 +1,6 @@
-/**
- * runCancelContext — run 记录上 server 自铸的**取消现场**侧记键 `cancelContext`(server ≥7.87.3 `PersistedTaskResult =
- * TaskResult & { cancelContext? }`,`dist/plugins/store-contracts.d.ts` `RunCancelContext` 四座)的三端共用读面,与
- * `turn_aborted{reason:'engine_error'}` 之后「到底是谁把这条 run 结掉的」的**成因判定**(0.74.3 CC-71;cli L-212 (a) 消费半场归包)。
- * sdk 9.7.1 对该键无型 ⇒ 按契约结构读。
- *
- * ── 🔴 读法 ─────────────────────────────────────────────────────────────────────────────────
- *  ① `cancelContext` 缺席 = 老 server / 这条 run 不是被取消的 / 记录形不带 —— **不折成「未取消」**,读数是 `not_reported`。
- *  ② 四座各自可缺席、各自防御读:`lastEventKind`(串)/ `lastEventAgeMs`(≥0 有限数)/ `elapsedMs`(≥0 有限数;绝不折 0)/
- *     `lastBrainStatus`(对象,原样带出不窄读)。「有 age 无 kind」是合法读数。
- *  ③ 成因判定 {@link classifyRunAbortCause}:只由 run 记录上的**机读证据**得出 —— `errorCode` ∈ 取消码 ⇒ `cancelled_by_user`;
- *     `cancelContext` 在场而码不是取消码 ⇒ 仍按码判(现场只是附注);码缺席 / 认不出 ⇒ `unknown`。**缺席不猜**。
- */
 function nonNegFinite(v) {
     return typeof v === 'number' && Number.isFinite(v) && v >= 0 ? v : undefined;
 }
-/**
- * 记录形两种:顶层 `result`(PersistedTaskResult)或已经是 result 本身。只有 `result` 长得像一份 run 结果(带 terminal / status /
- * cancelContext 任一键)才下钻 —— `TaskResult` 自己也有个 `result` 键(今天是串),哪天成了对象也不该被当成结果记录(test [7702] §七 ④)。
- */
 function runResultHolder(r) {
     const inner = r.result;
     if (inner === null || typeof inner !== 'object' || Array.isArray(inner))
@@ -25,12 +8,10 @@ function runResultHolder(r) {
     const o = inner;
     return Object.hasOwn(o, 'terminal') || Object.hasOwn(o, 'status') || Object.hasOwn(o, 'cancelContext') ? o : r;
 }
-/** run 记录(`runs.get` 回体 / `done.result`)→ 取消现场读数;记录非对象 ⇒ `undefined`(判不出,与 not_reported 分开)。 */
 export function readRunCancelContext(record) {
     if (record === null || typeof record !== 'object')
         return undefined;
     const r = record;
-    // 记录形两种:顶层 `result.cancelContext`(PersistedTaskResult)或已经是 result 本身。
     const holder = runResultHolder(r);
     if (!Object.hasOwn(holder, 'cancelContext') || holder.cancelContext === undefined)
         return { kind: 'not_reported' };
@@ -52,20 +33,9 @@ export function readRunCancelContext(record) {
         },
     };
 }
-// ── 成因判定(闭集四词;cli L-212 (a) 对齐)────────────────────────────────────────────────
-//
-// 字节出处(cli 亲 grep server 7.87.3 dist):
-//   · 被取消 = 唯一铸点 `run-cancel-context.js` `mintCancelledResult` ⇒ `terminal:{kind:"failed", code:"cancelled"}`,
-//     且**只有这条路**挂 `cancelContext`;
-//   · 引擎错 = `terminal.kind === "failed"` 且 code !== "cancelled";code 是 core 的**开集**(network / brain.* / limits.* …)⇒ 只渲原码,不枚举;
-//   · 客户端断连**没有独立字节**:server 走的是 detach / park(durable run 继续跑、在等的 ask 停驻),run 记录不会因此失败 ⇒
-//     它不是 run 的成因,是壳这一端的事实 —— 判法 = run 记录仍非终态(running / queued / suspended / needs_review)⇒ `run_still_live`。
-//   · 别的(完成 / 挡住 / 读不出终态词)⇒ `unknown`,不猜。
 import { readRunTerminal } from './runTerminal.js';
-/** 取消码常量(server `CANCELLED_CODE` / sdk runs.d.ts 逐字)。 */
 export const RUN_CANCELLED_CODE = 'cancelled';
 const LIVE_STATUSES = new Set(['running', 'queued', 'suspended', 'needs_review']);
-/** 壳带 `engineTaskId` 去 `runs.get` 拿回的记录 ⇒ 成因。只由机读证据得出;缺席不猜。 */
 export function classifyRunAbortCause(record) {
     if (record === null || typeof record !== 'object')
         return { kind: 'unknown' };
@@ -79,12 +49,8 @@ export function classifyRunAbortCause(record) {
         }
         return { kind: 'engine_error', ...(read.code !== undefined ? { code: read.code } : {}), ...(read.message !== undefined ? { message: read.message } : {}) };
     }
-    // 非终态 = run 还活着:嵌套 paused 臂 / 平面 paused 词 / 行上 status 仍是在飞词(平面读器对 running / queued 答 unknown{word},
-    // 那不是「读不出」,是「还没结」—— 所以先看 status 再落 unknown)。
     if (read !== null && read.kind === 'paused')
         return { kind: 'run_still_live', ...(status !== undefined ? { status } : {}) };
-    // 异源复审 R2 [medium]:result 已是终态(completed / blocked)而行上 status 还是在飞词 = 两处证据矛盾 ⇒ unknown(带观测到的终态词),
-    // 不按外层 status 说「还活着」——result 是终局记录,行状态可能滞后;矛盾不是 liveness 的证据。
     if ((read === null || read.kind === 'unknown') && status !== undefined && LIVE_STATUSES.has(status))
         return { kind: 'run_still_live', status };
     return { kind: 'unknown', ...(read !== null ? { terminal: read.kind } : {}) };