@sema-agent/client-core 0.77.0 → 0.77.2

package/dist/engineErrorCodes.js

@@ -1,97 +1,20 @@
-/**
- * src/engineErrorCodes.ts — **引擎 wire 码词表的单一真源**(G1 去字面化,2026-08-04,
- * core 5.10.0 / sdk 6.2.0 消费半场)。
- *
- * ── 为什么要有这个文件 ────────────────────────────────────────────────────────────────────────
- * 引擎的 `errorCode` 是**机器码**(结构位),壳的四条判别链都吃它:终帧 subtype 映射
- * (`adapter/downstream/terminalToSdkResult.ts`)、409 busy 判别(`adapter/runStream.ts`)、
- * `stop.*` 五形分类(`subagent/engineTaskHandleWire.ts`)、限额面文案(`limitsWire.ts`)。
- * 收编前这些码以**裸字面量**散在五个文件、二十余处:core 每次词表迁移(5.8.0 的 `budget.*` →
- * `limits.*`、5.10.0 的 `config.*` 第四波)都要满仓 grep `===` 比较,漏一处的后果不是报错而是
- * **判别链静默走错臂** —— 这正是 [dep-bump-follow-on-checklist] 那类跟车事故的载体。
- *
- * ── 🔴 开集纪律(本文件最重要的一条)──────────────────────────────────────────────────────────
- * **wire 的 `errorCode` 是开集**:引擎完全可能比本包新一版,发一个这里没有的码。所以:
- *   · 本文件的 `ReadonlySet` / 前缀谓词一律是**识别表**(recognition table),回答的是
- *     「我认不认得这个码」,**绝不是**「合法码只有这些」;
- *   · 消费点的 `switch` 必须留 `default`、`if` 必须留 else 臂,未知码一律**原样透传**
- *     + 落诚实兜底臂,绝不塌进任何一个已知形(塌进去 = 替 server 编了一个它没说的原因);
- *   · 唯一的**闭集**是 {@link ModelFallbackReason} —— 它是 core 亲自声明的闭集单成员
- *     ([2577] 定谳),加成员 = BREAKING 清单行,所以它写成 string literal union 而不是 `string`。
- *     这条例外**只此一处**,别照抄到别的码上。
- *
- * ── 命名与来源 ────────────────────────────────────────────────────────────────────────────────
- * 每一族下方注出它的 core 版本与出处帖号;码的字面**永远以引擎为准**,本文件只是镜子。
- * 词表变动集中在一处可数(与 `terminalToSdkResult.ts` 那三个集合原本的立意同),提货批 diff 里
- * 一眼能看出「这一版引擎加了哪几个词」。
- */
-// ── 限额到限族(core 5.8.0 [2489] 词表迁移;5.7 的 `budget.*` / `limit.*` 已随退役批删净)────
-/** token 预算到限。`result` 可能带已产出正文([2489] 明记)。 */
 export const LIMITS_MAX_TOKENS_EXCEEDED = 'limits.max_tokens_exceeded';
-/** 成本预算到限(唯一一个 CC 有专门 subtype 的预算轴)。 */
 export const LIMITS_MAX_COST_EXCEEDED = 'limits.max_cost_exceeded';
-/** 轮数预算到限。 */
 export const LIMITS_MAX_TURNS_EXCEEDED = 'limits.max_turns_exceeded';
-/** 墙钟预算到限(5.8.0 起是**响亮终局** `status:'failed'`;`status:'timeout'` 该终态词整体退役)。 */
 export const LIMITS_MAX_WALLTIME_EXCEEDED = 'limits.max_walltime_exceeded';
-/** 限额族的**族前缀**(单源;上面四个常量都以它开头)。 */
 const LIMITS_ERROR_CODE_PREFIX = 'limits.';
-/**
- * 该码是否属「引擎侧治理限额到限」族。**开集前缀判**(与 {@link isConfigRefusalCode} 同款):
- * core 每加一根新的限额轴(`limits.max_*`)判别自动跟上,按成员判的消费点则要跟车。
- *
- * 🔴 用途边界:这一族回答的是「谁停的这条 run」= **本部署的治理旋钮**,不是 provider/HTTP 故障。
- * 呈现层据此避开 `API Error:` 那个身份声明(见 `adapter/runStream.ts` 的 governance 臂)——
- * 把一次「轮数用光了」说成 API 错误,用户会去查网络/密钥/额度,而真正的把手是 `--max-turns`。
- */
 export function isLimitsExceededCode(code) {
     return typeof code === 'string' && code.startsWith(LIMITS_ERROR_CODE_PREFIX);
 }
-// ── 停钟族(core 5.10.0「三时钟序」:usage_window > env_lifetime > stall)─────────────────────
-/** 部署级 token 治理窗耗尽。**唯一携带可执行等待量的停因**,与 `retryAfterMs` 配对到货。
- *  5.10.0 起:治理窗与环境寿命同一轮边界到期时,**窗赢**(此前 env-first 报告把它丢了)。 */
 export const USAGE_WINDOW_EXHAUSTED = 'usage.window_exhausted';
-/** 环境寿命到期(平台侧)。与上一条同轮到期时**让位**给它。 */
 export const ENV_LIFETIME_EXPIRED = 'env.lifetime_expired';
-// ── 配置拒绝族(core 5.10.0「不许静默折叠」第四波)────────────────────────────────────────────
-// 语义:引擎拿到一个**无法求值**的旋钮值(NaN / 负数 / 分数 / 该轴不许的 Infinity)时**响亮拒**,
-// 而不是折成 0 / 静默停用那道闸。这一族全部是「配置错了」,不是「跑失败了」—— CC 的四词 subtype
-// 里没有对位词,故一律落诚实兜底 `error_during_execution`,真实语义靠码本身透传。
-/** `TaskRequest.limits` 各门(runTeamDiscussion 累计额 / workflow 治理 TRUSTED 半 /
- *  `resourceSuspend` 四键)拒绝不可求值的值。 */
 export const CONFIG_LIMIT_INVALID = 'config.limit_invalid';
-/** `StrategyStore.find(scope, query, limit)` 的 limit 非「非负整数或 Infinity」。 */
 export const CONFIG_STRATEGY_FIND_LIMIT_INVALID = 'config.strategy_find_limit_invalid';
-/** `StrategyStore.prune` / `InMemoryStrategyStore` 构造的容量上限非非负整数(含点名拒 `Infinity`
- *  —— 容量帽可以放宽,不可以关掉)。 */
 export const CONFIG_STRATEGY_MAX_SIZE_INVALID = 'config.strategy_max_size_invalid';
-/** 未知的 limits 键(5.8.0 起:同时发新旧两代键会在这里当场失败,所以写面只发单一新形)。 */
 export const CONFIG_LIMIT_UNKNOWN_KEY = 'config.limit_unknown_key';
-/**
- * `RunnerDeps.delegationEntryCaps`(core 5.48.0 / design/323,[4743] @cli 点名件)的坏值拒。
- *
- * 两种拒绝形:成员不是正整数(NaN / 0 / 负数 / 分数 / 非数),或**解出的一对**满足
- * `maxConcurrent > maxCumulativePerSession`(一棵树不可能同时跑得比它这辈子能创建的还多 ——
- * 这是矛盾不是偏好)。缺席成员取 CC 对齐缺省(20 / 200)。
- * 🔴 与本族其余成员同律:**坏旋钮响亮拒,绝不静默折回缺省**。
- */
 export const CONFIG_DELEGATION_ENTRY_CAPS = 'config.delegation_entry_caps';
-// ── 记忆面的两个**构造期**拒码(CC-96;`agents[].memory` / 请求记忆面的同族第二波)────────────
-//
-// 两码与本族其余成员同律(「配置错了」不是「跑失败了」),但**多一条**:它们拒在**受理之前** ——
-// 这一次运行什么都没跑,所以出路一律是「改请求再发」,不是等、也不是去查运行结果。
-// 🔴 **分诊归引擎,本包不预铸第二判官**:拼写合不合法 / 范围算不算不匹配,判据都在引擎侧;本端照码渲一句话
-//    (单铸口 = `src/memorySpecWire.ts` 的 `memoryConfigRefusalNoteOf`),绝不自己先算一遍再「帮」它判。
-// ⚠️ 两码的 HTTP 状态**不同**(本族此前清一色 400):拼写 400 / 不匹配 409。状态不是判据(判据是码),
-//    但它是**处置差**的来源 —— 一条是打字错,一条是与已生效的那一份冲突,渲成同一句会把两种出路混掉。
-/** 记忆面 project key 的拼写不合法(**400**;构造期拒,什么都没跑)。 */
 export const CONFIG_MEMORY_PROJECT_KEY_SPELLING = 'config.memory_project_key_spelling';
-/** 这次请求的记忆写入范围与已生效的那一份不一致(**409**;构造期拒,什么都没跑 —— 冲突,不是拼写错)。 */
 export const CONFIG_MEMORY_WRITE_SCOPE_MISMATCH = 'config.memory_write_scope_mismatch';
-/**
- * 已知的配置拒绝码(**识别表,非白名单**)。判「这是不是一条配置拒绝」请用
- * {@link isConfigRefusalCode} —— 它按 `config.` 前缀判,未来新成员自动落进来。
- */
 export const CONFIG_REFUSAL_CODES = new Set([
     CONFIG_LIMIT_INVALID,
     CONFIG_STRATEGY_FIND_LIMIT_INVALID,
@@ -101,51 +24,15 @@ export const CONFIG_REFUSAL_CODES = new Set([
     CONFIG_MEMORY_PROJECT_KEY_SPELLING,
     CONFIG_MEMORY_WRITE_SCOPE_MISMATCH,
 ]);
-// ── 委派席位到限族(core 5.48.0 design/323,[4743] @cli 点名的「两新 coded 拒绝」)──────────────
-//
-// 语义:一次**新开委派**(Task 铸新席位)因为**席位帽**被拒 —— 不是配置坏了(那是上面的
-// `config.delegation_entry_caps`),也不是失败了,而是「现在不行」。SendMessage **复活**走
-// revive 短路:core 只对它查并发帽、**跳过**累计帽(dist/agents/subagent.js:累计检查包在
-// `reviveRow === undefined` 里)—— 这正是累计帽处置指向「复用」的机器面依据。两码**处置不同,
-// 禁合并**:
-//   · 并发帽 ⇒ **等**:活着的兄弟结束就有位,同一条命令过一会儿照样成;
-//   · 累计帽 ⇒ **复用而不是新开**:计数是 **retained-window 帐**(core 计数前先把不在
-//     stored/active 里的 handle 从 ledger 剪掉 —— 行被 retention 回收后配额**会回来**),core
-//     文案原话即 "in its retained window … Continue an existing agent (SendMessage) instead of
-//     launching new ones"。渲成「这条会话这辈子的配额用完了」是**错的**(0.38.0 段曾这么写,
-//     0.39.0 勘误;异源对抗复审命中):会把一个「换 SendMessage 姿势就能继续」的用户赶去换会话。
-// 把两者渲成同一句「委派失败」会让第一种情形的用户去改配置,第二种情形的用户去白等新槽。
-//
-// 🔴 **载体现势(2026-08-21 二次亲验,core 5.50.0 dist node 直读)**:0.38.0 曾如实登记「这两码
-//    只铸进 Task 工具结果体的 `details.error`,而 core 的 `errorCode` 抬升腿只读 `details.code` →
-//    `details.errorKind` 两个拼法 ⇒ wire 上拿不到」,故先立词、消费分支候载体(上游诉求随
-//    0.38.0 发布登记)。core 5.50.0 已兑现:`capRefusal` 铸 `{ error: code, code }` **孪生拼法**
-//    (`dist/agents/subagent.js`),抬升腿(`dist/core/runner/runtask.js` `toolEndBodyFrom`)读
-//    `details.code` 后 stamp 帧顶层 ⇒ **两码自 core ≥5.50.0 起真出现在 `tool_end.errorCode`**。
-//    消费分支 0.39.0 同批接上:**判定归本包**({@link delegationCapDispositionOf}),文案归端。
-//    载体门 = `run-engine-vocab-floor-test.mjs` G3 腿(锚 dist 铸点与抬升腿口径,孪生消失当场红,
-//    不许安静绿回去)。旧引擎(5.48/5.49)上两码仍只在模型面文案里 —— 消费点拿不到码就什么都
-//    别渲,**绝不按文案反解**([cross-repo-fix-at-source-constitution] 依旧适用)。
-/** 并发帽:这棵树此刻活着的委派席位已达 `delegationEntryCaps.maxConcurrent`(CC 对齐缺省 20)。
- *  🔴 处置 = **可等**(兄弟结束即有位),别渲成「配置要改」。 */
 export const DELEGATION_CONCURRENCY_CAP = 'delegation.concurrency_cap';
-/** 累计帽:这棵树在 **retained window** 内创建的委派席位已达 `maxCumulativePerSession`
- *  (CC 对齐缺省 200)。🔴 处置 = **复用既有 agent(SendMessage)或候 retention 回收**(行被
- *  reap 后配额恢复 —— core 计数前先剪 ledger,见族注),别渲成「换会话」或「改配置」。 */
 export const DELEGATION_SESSION_CAP = 'delegation.session_cap';
-/** 委派席位到限码识别表(**开集**:core 可能再加第三根轴)。两员处置不对称,消费点禁合并分支。 */
 export const DELEGATION_CAP_CODES = new Set([
     DELEGATION_CONCURRENCY_CAP,
     DELEGATION_SESSION_CAP,
 ]);
-/** `delegation.` 前缀谓词 —— **开集**判别(与 {@link isConfigRefusalCode} 同款)。缺席/空串 ⇒ false。
- *  🔴 它只回答「这是不是一条委派席位拒绝」;**该等新槽还是该复用既有 agent**必须按成员分
- *  ({@link delegationCapDispositionOf}),见两码各自的注释。 */
 export function isDelegationCapCode(code) {
     return typeof code === 'string' && code.startsWith('delegation.');
 }
-/** 两成员各归各格;未知 `delegation.*` 码(core 的第三根轴)⇒ `undefined` —— 开集纪律:不认得
- *  就不给处置,消费点必须留「只报码不指路」的 default 臂,绝不塌进任何一格替引擎指路。 */
 export function delegationCapDispositionOf(code) {
     if (code === DELEGATION_CONCURRENCY_CAP)
         return 'wait-for-slot';
@@ -153,98 +40,27 @@ export function delegationCapDispositionOf(code) {
         return 'reuse-existing-or-await-reap';
     return undefined;
 }
-// ── MCP 吊销族(core 5.50.0;操作员 mid-session 吊销 server 后的工具面拒绝)────────────────────
-/**
- * 已吊销 MCP server 上的调用被拒。core `dist/core/mcp.js` **三个铸点同码**(远端工具调用 /
- * 资源读取 / 目录列举)。载体与 `delegation.*` 两码同批:`{ error, code }` 双键同值 ⇒
- * `tool_end.errorCode`(core ≥5.50.0;载体门 = engine-vocab G3 腿)。
- * 🔴 **哪个 server 被吊销,今天 wire 上拿不到**(异源对抗复审命中,如实登记):core 的
- * detail 确有 `server` 键,但它是**进程内** result 体 —— 抬升腿只 lift `code`,且该 detail 无
- * `type` 进不了 `structured` ⇒ 端只有码没有名。**别按 output 文案抠 server 名当机器判据**
- * (文案是模型面散文,不是契约);归因渲染候上游补 typed detail / tool_end 字段(诉求已
- * 随 0.39.0 发布帖点名 core,表态制)。
- * 🔴 语义三条,一条都别渲错:
- *   · **请求没发出去**(core 文案原话 "The request was NOT sent")—— 是本地闸,不是远端失败;
- *   · 这不是故障也不是配置坏了,是**操作员的治理动作** —— 别渲成「服务器错误,稍后重试」;
- *   · 同 server 重试**无意义**,直到它被重新批准;工具表在下一 turn 更新(core 文案原话)。
- */
 export const MCP_SERVER_REVOKED = 'mcp.server_revoked';
-/** `config.` 前缀谓词 —— **开集**判别:5.10.0 之后每一波「不许静默折叠」都会往这一族加词,
- *  按前缀判的消费点不必跟车,按成员判的必须跟车。缺席/空串 ⇒ false。 */
 export function isConfigRefusalCode(code) {
     return typeof code === 'string' && code.startsWith('config.');
 }
-// ── 中断族(core 5.10.0:被中断的 tool call 的合成 `tool_end` 终于带正文)──────────────────────
-// 5.10.0 之前两条 reconcile 腿只把 `[INTERRUPTED]` 解释写进 transcript,事件流上只有
-// `isError:true` 而无正文 ⇒ 从帧渲染工具输出的消费者看到的是**空结果**,一次调用的两个面互相矛盾。
-// 现在帧上带 `output`(与所有 live 工具结果同一投影)+ `errorCode`(下面两员,来自持久化的
-// `details.errorKind`)+ `label`,消费者**按码判别**而不是去正则匹配散文。
-/** 该 call 从未真正开始执行(可安全重发)。 */
 export const TOOL_END_INTERRUPTED_NEVER_STARTED = 'interrupted_never_started';
-/** 该 call 的结局未知(持有它的进程死了 —— 副作用可能已经发生,**不可**当作没跑过)。 */
 export const TOOL_END_INTERRUPTED_OUTCOME_UNKNOWN = 'interrupted_outcome_unknown';
-/**
- * 中断码识别表(**开集**:`tool_end.errorCode` 整体是开集,未来可能有第三种中断成因)。
- * 🔴 两员**语义不对称**,别合并处置:`never_started` 可以重发,`outcome_unknown` 不可以。
- */
 const TOOL_END_INTERRUPTED_CODES = new Set([
     TOOL_END_INTERRUPTED_NEVER_STARTED,
     TOOL_END_INTERRUPTED_OUTCOME_UNKNOWN,
 ]);
-/** 这条 `tool_end` 是不是「中断留下的合成收口帧」。未知码 ⇒ false(开集:不认得就不认得,
- *  绝不猜)。 */
 export function isInterruptedToolEndCode(code) {
     return typeof code === 'string' && TOOL_END_INTERRUPTED_CODES.has(code);
 }
-// ── 能力准入族(server 7.57.0 S-81;`capability.*` 是**开集前缀**,本行只登记其中一个成员)────
-/**
- * 提交面的 selfOrchestration 准入拒绝(`POST /v1/tasks` 与同闸的 stream 提交,**501**)。
- *
- * 语义:引擎侧的 workflow 开关是开着的(`SELF_ORCHESTRATION_ENABLED=true`),但这台部署处在
- * **半配置的多租户形态** —— 要求 principal、却没有中心侧的准入解析器,于是它无法判「这一位
- * 调用者能不能用 workflow」,fail-closed 拒。请求带 `selfOrchestration:true` **或**
- * `settings.ultracode:true`(后者由 server 展开成前者)就撞这一条;把这两个键去掉,**同一条
- * 请求照常受理**。
- *
- * 🔴 **这是复用码**:它与其它 `capability.*` 501 共用体形,而处置**不同** —— 别的能力位
- * 缺席时去掉这两个键也不会变成可受理。⇒ 消费点必须按**恰等**判,绝不放宽成 `capability.`
- * 前缀判(那是 `sessionMemoryStatus` 那条读面上的另一件事,两者刻意不合流)。
- * 判型与「去键重发一次」的判定归 `src/selfOrchestrationDenial.ts`(文案归端)。
- * 🔴 非布尔的 `selfOrchestration` 走的是 **400**,不是本码 —— 那是「值不对」不是「不给用」。
- */
 export const CAPABILITY_SELF_ORCHESTRATION_REQUIRED = 'capability.self_orchestration_required';
-// ── 门语义族 ──────────────────────────────────────────────────────────────────────────────────
-/**
- * 「**门把这次调用 park 了**」的机读码(core 5.52.0 `prepare-task` 的
- * `abortResultDetails: () => ({ code: "gate.parked" })`;[4973] 契约:双短路点同席恒铸)。
- *
- * 🔴 **它是「这次调用没有在这里结算」的第二形**(engine 7.64.0 真机黑盒直证):审批窗走完 300s
- *    未决而走 park 路径时,`tool_end` 帧上**没有 `gate` 字段** —— 只有这个码。门记录缺席在那一形上
- *    **不是**「记录坏了」,是「这次调用根本没结算过什么,它被 park 了」。⇒ 任何要回答「这次调用
- *    settle 了没有」的消费点必须**两形都认**:`gate.settlement` 在场那一形,与本码这一形。
- * 🔴 单源:`hitl/frameRouter.ts` 的连坐/中断判据与 `gateOutcome.ts` 的停驻谓词读的是同一个常量 ——
- *    两处各写一份字面量必漂(而漂的那一天两边对同一帧给出相反的判决)。
- */
 export const GATE_PARKED_ERROR_CODE = 'gate.parked';
-// ── 会话冲突族 ────────────────────────────────────────────────────────────────────────────────
-/** 409 session-busy 的 canonical 码([2377]C-1,server main `049ff2c`,随 5.0.0 发)。 */
 export const ACTIVE_RUN_BUSY_ERROR_CODE = 'conflict.session_active_run';
-// ── `runs.taskStop` 409 冲突族([1833] G13;SDK `TaskStopConflictError.errorCode` 判别)────────
-/** 仲裁店不可达 ⇒ **真相未知**(core 1.397 三分的第三形;塌进 `not_landed` 是诚实缺陷)。 */
 export const STOP_PARK_ARBITER_UNREACHABLE = 'stop.park_arbiter_unreachable';
-/** park 的 resume 赢了这场竞争。 */
 export const STOP_PARK_RESUME_WON = 'stop.park_resume_won';
-/** kill 没落地。 */
 export const STOP_NOT_LANDED = 'stop.not_landed';
-/** 该任务不在本副本。 */
 export const STOP_NOT_LOCAL = 'stop.not_local';
-/** 该任务已 park。 */
 export const STOP_PARKED = 'stop.parked';
-/**
- * 兜底**字面认码**用的已知集(typed 错误缺席时才走这条回落腿)。
- * 🔴 **顺序即语义**:长码优先 —— `stop.parked` 是 `stop.park_resume_won` 的前缀,顺序反了
- * `detail.includes()` 会让短码抢走长码的命中。数组(有序)不是 Set(无序),这是判据的一部分。
- */
 export const STOP_CONFLICT_CODES = [
     STOP_PARK_ARBITER_UNREACHABLE,
     STOP_PARK_RESUME_WON,
@@ -252,131 +68,20 @@ export const STOP_CONFLICT_CODES = [
     STOP_NOT_LOCAL,
     STOP_PARKED,
 ];
-// ── 结构化输出族 ──────────────────────────────────────────────────────────────────────────────
-/** `outputSchema` 任务在重试上限内没能产出合法结构化输出(语义字面就是 CC 那个 subtype 的话)。 */
 export const OUTPUT_INVALID = 'output.invalid';
-// ── rewind / resume 族(core 1.292 [833])────────────────────────────────────────────────────
-/**
- * `resume_at.*` 单族前缀(A-028.11 单源化,#244 族E):壳 `isResumeAtRejection`(Esc 杀锚后的
- * 一次性去锚自动重发判型)此前持裸字面 `'resume_at.'` —— 收编到本表。🔴 它**刻意窄于**
- * {@link REWIND_ERROR_CODE_PREFIXES}(不含 `rewind_snapshot.`):自动重发的安全性论证只对
- * resume_at 族做过(pre-stream 零副作用),扩到全 rewind 族属行为变更,须另立项。
- */
 export const RESUME_AT_ERROR_CODE_PREFIX = 'resume_at.';
-/**
- * 用户**可自解**的操作性错误的码前缀(选错回退目标 / 回退过根 / 快照缺失)。
- * 消费点把 code 附在 message 后便于对账 —— 这一族是「你的操作有问题」,不是「引擎坏了」。
- * 前缀形(不是成员形)= 开集:这一族里每加一个新码,判别自动跟上。
- */
 export const REWIND_ERROR_CODE_PREFIXES = [RESUME_AT_ERROR_CODE_PREFIX, 'rewind_snapshot.'];
-/** 该码是否属 rewind/resume 可自解族。缺席 ⇒ false。 */
 export function isRewindFamilyCode(code) {
     return typeof code === 'string' && REWIND_ERROR_CODE_PREFIXES.some((p) => code.startsWith(p));
 }
-// ── resume 族的**时间性拒绝**二码(L-102;server ≥7.47.0 / ≥7.51.0,SDK 8.1.0 `ResumeRetryLaterError`)──
-//
-// ⚠️ 与上面的 `resume_at.`(**下划线**,rewind 取址族)是**两族** —— 这里是 `resume.`(**点**,
-// design/122 D2 的 409 合同拒绝族)。同一个词在两个族里,判别靠分隔符,别按 `resume` 子串猜。
-//
-// 语义:下面两码是这一族里**唯一携带可执行等待量**(`retryAfterSec`)的两码 —— 这就是它们成为
-// 一个闭集的**全部理由**。
-// 🔴 **本闭集回答的不是「哪些码可以等」**(异源对抗复审 [medium] 真病修:上一版这段写成「只有下面
-//    两码可能是『现在不行、过一会儿行』」,是**排他性错断**)。族内**明确的反例**就在本文件视野内:
-//    `resume.row_recycling` 的 core 铸文逐字「this clears on its own; send again in a moment」——
-//    它可等,只是 server 给不出秒数,所以它**不在**本闭集里、也**不该**在。
-//    ⇒ 「本读口返回 `null`」只意味着**没命中这两码**,绝不意味着「等也没用」;闭集外的码照旧走
-//    `classifySubagentResumeFailure` 的既有各格(`row-contended` 就是可等的那一格)。
-// 🔴 命中之后**也不等于一定可等**:后一码另有一条 `terminal` 臂(见该码顶注)⇒ 处置由
-//    `wireErrorTriage` 的 `waitable` 按**正向证据**判,不由「命中本族」判。此前它们双双落进 `classifySubagentResumeFailure`
-// 的开集兜底 `error` ⇒ server 明明给了「等多久」,到客户端只剩一句泛泛失败(与 0.38.0 收
-// `row_recycling`/`row_gone` 那次同形)。
-/**
- * `resume.usage_window_exhausted`(#449 G1,core 5.60.1;server ≥7.47.0)—— 这一行的账本键上,
- * 本部署的**治理窗**满了。core 铸文的两句不变量:**什么都没消费、什么都没解钉** ⇒ 同一个 token
- * 带同一个决议在窗放开后可**直兑**(所以处置是「等」,不是「重开」也不是「改配置」)。
- * ⚠️ 与 429 的 {@link USAGE_WINDOW_EXHAUSTED}(`usage.window_exhausted`,提交面 pre-admission)
- * **同一本账、不同门、不同码**:本码是 resume/decide 腿的 pre-CAS 拒。别把两者合并判。
- */
 export const RESUME_USAGE_WINDOW_EXHAUSTED = 'resume.usage_window_exhausted';
-/**
- * `resume.preflight_rejected`(#376,core 5.65 retry-later 形;server ≥7.51.0)—— 部署自己的
- * `RunnerDeps.resumePreflight` 拒了这次 resume(显式拒 / 抛 / 超时 / 答案读不动,四臂一律
- * fail-closed)。它是 CAS 前的**最后一档**,所以什么都没被消费。
- * 🔴 **core 侧另有一条 `terminal` 臂**(行已被这次拒绝的单发 expire CAS 结清、token 不可再赎),
- *    而两臂的**判别位在 message 散文里**。本包**不按文案分臂** —— 按文案分支正是上游改一个词就
- *    静默空转的形。⇒ 消费端能诚实说的只有两臂都成立的那句:「这一拒发生在提交之前,你的决定
- *    没被消费」;「还能不能再赎」交给引擎那行原文去说,别替它下结论。
- */
 export const RESUME_PREFLIGHT_REJECTED = 'resume.preflight_rejected';
-/**
- * `resume.placement_mismatch`(#376 / core 5.65,design/380 O1③;server ≥7.51.0)—— 这次 resume
- * 显式带的 `internals.placementRoot` 与 suspend 铸点记下的 `CheckpointState.placementRootSessionId`
- * **不同**。目标绑定的 env factory 按那个固定点查 placement,静默换根会把这条腿(以及它往下传的
- * 每一个子代)重新落在**另一台目标**上,而 park 的工作区在原来那台 ⇒ **拒在 CAS 之前**,行仍 `pending`。
- *
- * 🔴 **它不在 {@link RESUME_RETRY_LATER_CODES} 里,而且不该在**:server 只在
- * `resume.usage_window_exhausted` / `resume.preflight_rejected` 两码上铸 `retryAfterSec`
- * (server 7.51.0 `dist/http/server.js` 的 `CheckpointError` 出口逐字),本码恒无窗;更要紧的是
- * **等一会儿对它毫无用处** —— 出路是「用记录里的那个 root 重来,或干脆不传 `internals.placementRoot`
- * 继承记录值」,是**换参数**不是**等时间**。把它放进时间性闭集会让人白等一个永远不会自己好的拒绝。
- * ⇒ 它与 `resume.preflight_rejected` 一起构成**另一个**闭集:{@link import('./resumeRefusalCopy.js').RESUME_REFUSAL_CODES}
- * (「有人话可补」的拒绝),两个闭集刻意分家 —— 一个回答「能不能等」,一个回答「该对人说什么」。
- */
 export const RESUME_PLACEMENT_MISMATCH = 'resume.placement_mismatch';
-/**
- * 409 `conflict.resume_context_unavailable`(server ≥7.80.1 S-376 起体带结构位;码本身更早就有):**这个批准无处投递** ——
- * 发起这条 run 的会话当前没有可用的上下文来继续它。常见原因是部署按 `REAP_RUN_STALE_SEC` 回收了无活动会话,但 server 在
- * **上下文读取失败**(如存储故障)时也发同一个码,wire 上没有判别位 ⇒ 本包只报事实不推断原因。什么都没被决定,卡仍 pending。
- * 🔴 它不在 `resume.*` 族(前缀是 `conflict.`),也不进 {@link RESUME_RETRY_LATER_CODES} / `RESUME_REFUSAL_CODES`:
- *    能不能等 wire 上没有判别位(回收了就等不回来,读取失败则可能恢复)⇒ 不进「可等」集;出路是「用体上的 `runId` 自己恢复这条 run」,
- *    调大保留时长只能避免以后再发生。
- * 🔴 体上的 `staleAfterSec`(整数秒 = 该部署当下的 `REAP_RUN_STALE_SEC` 真值)是 7.80.1 的 additive 键;sdk 9.6.0 的
- *    `ConflictError` **还没把它带上来**(只带 activeTaskId 三件)⇒ 经 sdk 到端今天恒缺席,sdk 出键之日本包读口自动填满
- *    (读口按结构读 `errorCode` + `staleAfterSec` + `runId`,见 `resumeRefusalCopy.resumeContextUnavailableFromError`)。
- */
 export const RESUME_CONTEXT_UNAVAILABLE = 'conflict.resume_context_unavailable';
-/**
- * 时间性拒绝族的**闭集**。
- *
- * 🔴 这是本文件的第二个闭集,但闭的**不是**「`resume.*` 一共有几个码」(那仍是开集,新码照旧
- * 落 {@link isRewindFamilyCode} 之外的开集兜底),闭的是「**server 在哪些码上铸 `retryAfterSec`**」:
- * server 的铸键判据逐字 =「本码 ∧ 有限正数」,两码之外恒缺席;SDK 8.1.0 `classifyApiError` 同样
- * 按这**两个具名码**铸 `ResumeRetryLaterError`(具名分支排在 `resume.` 前缀兜底**之前**)。
- * 🔴 **绝不放宽成 `resume.` 前缀判**:那会把 `retain_off` / `evicted` / `row_gone` 这些**等也没用**
- * 的码一起说成「过会儿再试」—— 一半用户白等,另一半白重开(与 `row_recycling`/`row_gone` 禁合并
- * 同一条纪律)。加成员 = 上游真在新码上铸了 `retryAfterSec`,必须同批带判据。
- *
- * 🔴 **为什么是 `Object.freeze` 的数组而不是 `ReadonlySet`**(异源对抗复审 [medium] 采纳,真病;
- * 与 `interactiveHalt.RUN_LEVEL_STOP_ERROR_CODES`(#363 二轮)**同一条已定谳的病形**):
- * `ReadonlySet<string>` 只在**类型面**只读 —— 运行期它就是一只普通 `Set`,而判定查的是**同一个
- * 实例**。任何 JS 消费者(公面上它是导出的)`.add('resume.row_gone')` 之后,一条「等也没用」的
- * 拒绝就会当场变成带窗的 `retry-later`(实测:`row_gone` + `retryAfterSec:30` 从 `row-gone` 翻成
- * `retry-later`)—— 闭集与「只认正向证据」两道约束一起被绕过。冻结数组在**运行期**真的改不动
- * (ESM 恒 strict:`push`/下标赋值直接抛),于是「公开面」与「判定源」可以安全地是同一个物。
- * ⚠️ 判据形随之从 `.has()` 改成 `.includes()`(与 `parkResolver.GATE_FAILURE_CODES` 同姿势;
- *    闭集只有两员,查找成本不是这里的量)。
- * ⚠️ **同形存量登记**(只登记不顺手改):同文件的 `CONFIG_REFUSAL_CODES` / `DELEGATION_CAP_CODES` /
- *    `TOOL_END_INTERRUPTED_CODES` 三张表今天仍是 `ReadonlySet`,同病。它们**已经在公面上**且消费点
- *    用 `.has()` ⇒ 换形是下游 BREAKING(签名从 `ReadonlySet<string>` 变 `readonly string[]`),
- *    不属内容批射程;本条按现状登记,换形另立一批。本位是**新铸**的,所以在出生那天就用对形。
- */
 export const RESUME_RETRY_LATER_CODES = Object.freeze([
     RESUME_USAGE_WINDOW_EXHAUSTED,
     RESUME_PREFLIGHT_REJECTED,
 ]);
-// ── resume **reopen 族**(CC-06 / B-081,0.71.3;server `http/resume-legs.ts` isCheckpointReopenedFailure 同表)──
-/**
- * core runtask 在返回这三码的 failed 之前已经 `store.reopen` 了那张 checkpoint ⇒ **卡仍 pending、行重新 park、
- * `/decide` 报 retriable:true**:它们是「再 park」不是终局。下游处置三码逐字同款(重取待批列表、在原工具在场的
- * 部署上重决);族的判别力只在 `errorCode`,server 刻意不给它们各自的 HTTP 状态。
- *  · `resume.env_failed` —— 执行环境没起来;
- *  · `resume.tool_unavailable` —— 批过的那只工具在这条腿上**不在**;
- *  · `resume.tool_contract_mismatch`(core 7.8.0 F2)—— 工具还在,但 contractId / shapeDigest / implementationRevision
- *    任一不同 = 顶着同名的替身。
- * 🔴 sdk d.ts 未建模这三码(只在 core `checkpoint-store.d.ts` / `tool-roster.d.ts` 注释里点名),字面以 server
- *    resume-legs.ts 实装为锚;与 {@link RESUME_RETRY_LATER_CODES}(能不能等)/ `RESUME_REFUSAL_CODES`(该对人说什么)
- *    **两两不交** —— 三种处置三张表。`checkpoint.reopen_failed`(reopen 本身失败 = 终局)刻意不在本族。
- */
 export const RESUME_ENV_FAILED = 'resume.env_failed';
 export const RESUME_TOOL_UNAVAILABLE = 'resume.tool_unavailable';
 export const RESUME_TOOL_CONTRACT_MISMATCH = 'resume.tool_contract_mismatch';
@@ -385,80 +90,16 @@ export const RESUME_REOPEN_CODES = Object.freeze([
     RESUME_TOOL_UNAVAILABLE,
     RESUME_TOOL_CONTRACT_MISMATCH,
 ]);
-// ── `/decide` workflow 车道拒绝族(B-070 / L-200;sdk README §9.0.0,server ≥7.69.0)──────────
-//
-// 背景一句话:`/decide` 7.69.0 起长出**第三条车道** —— 停在耐久审批门上的那一只 checkpoint 属于一个
-// **workflow 子代**时,决断要投给它的**宿主会话**去 wake。这条车道的 200 与另外两条**不是同一句话**
-// (见 `src/decideReceipt.ts` 顶注),而它的三个拒绝码也各有各的出路,合并判就会把「重发没用」
-// 与「等一会儿重发」说成同一件事。
-/**
- * `decide.workflow_host_unknown`(409;sdk README §9.0.0 逐字:「run 上没有发起会话锚 ⇒ 无处投递,
- * **无重试价值**」)。
- * 🔴 出路**不是等**:这条 run 上根本没有可投递的宿主锚,重发一百次也一样。人能做的是据拒体的
- *    `runId` 自己去看那条 run(或换一条路 resume 它)。
- */
 export const DECIDE_WORKFLOW_HOST_UNKNOWN = 'decide.workflow_host_unknown';
-// 0.71.0(CC-20):`decide.workflow_host_not_parked` 常量与出路句**整只退役**(server 7.72.0 退役无别名,sdk errors.d.ts ⚰️ 顶注:
-//   ≥7.72.0 永不再发 —— 那条车道有了第二条腿,宿主没停在 park 上时改铸新 run,不再拒);退役词由 census 门钉零命中。
-/**
- * `decide.workflow_remember_unsupported`(400;同上:「本车道 fail-closed 拒 `remember:"session"`」)。
- * 🔴 出路是**去掉 `remember` 重发**,而且 sdk 顶注逐字保证「零副作用」——这一格与另外两个 409
- *    的分法不是严重程度,是**改什么才能过**(改参数 / 等时序 / 没救)。
- */
 export const DECIDE_WORKFLOW_REMEMBER_UNSUPPORTED = 'decide.workflow_remember_unsupported';
-/**
- * `/decide` workflow 车道的拒绝码**闭集**(两员;0.71.0 CC-20 退役 `host_not_parked` 后从三员收成两员)。
- *
- * 🔴 闭的不是「`decide.*` 一共有几个码」(那仍是开集:`approval_binding_mismatch` /
- *    `approval_stale` / `gate_not_tool_approval` 等都不在本表,它们各有既有处置),闭的是
- *    「**这两个码是 workflow 那条新车道独有的、而且各自有一句人话**」。
- * 🔴 **形制**:`Object.freeze` 的数组,不是 `ReadonlySet`(同 {@link RESUME_RETRY_LATER_CODES} 的
- *    已定谳病形 —— `ReadonlySet` 只在类型面只读,而判定查的就是公面上这同一个实例)。
- * 🔴 加成员必须**同批**补那一句人话 + 判据,不许靠 `decide.` 前缀放宽(前缀下住着三种处置)。
- * 🔴 **删成员义务**(0.71.0 CC-20 补):上游退役某码(sdk errors.d.ts 顶注 ⚰️ RETIRED 无别名)⇒ 同批删常量、出路句、
- *    `resendable` 行,退役词进 census 门登记;decide-receipt 门 E0 对每一员钉「上游仍活着」,上游退役当天先红。
- * 📋 **刻意不镜像**:`decide.workflow_park_identity_lost`(server 7.71.0 引入、7.75.0 退役,sdk 从未建模,继任 `decide.workflow_resume_not_admitted`
- *    家族由 sdk 类承载);端收到未知 `decide.*` 码一律走开集通用行(机器行原样上屏),本表不为已退役码留位。
- */
 export const DECIDE_WORKFLOW_LANE_CODES = Object.freeze([
     DECIDE_WORKFLOW_HOST_UNKNOWN,
     DECIDE_WORKFLOW_REMEMBER_UNSUPPORTED,
 ]);
-// ══ 0.68.0 提货批(core 7.17.0 #652;server [7084] D 段)—— workflow **park 真相**四拒码 ══════
-//
-// 背景一句话:workflow run 记录从 7.17.0 起带 `parks[]`(准入输入),而「一条 run 的 park 到底是
-// 什么状态」是 **resume 的前提**。读不出 / 对不上 / 不在 pending / 压根没有 run 店 —— 四种情形此前
-// 混在 `workflow.journal_incompatible` 的「journal entry missing」那一臂里,一个码说四件事,于是
-// 消费端只能渲一句「日志不兼容」,而四条出路完全不同。core 7.17.0 把它们拆成四个码(那条旧臂同批
-// 退役),`workflow.ts:602` 是码集的铸点。
-//
-// 🔴 **它们不是 `SCRIPT_ERROR_CODES` 的成员**(core 顶注逐字:host runtime 类)—— 别拿脚本错误那
-//    张表去判它们,也别把它们塞进那张表。
-// 🔴 **本包不抄 core 的句子**(单铸律,同 `engineNoticeCodes.ts` 顶注):只给码、闭集与每个码的
-//    `detail` 键位读法,人话用引擎给的那一句。
-/** 这条 workflow 的 park 真相**读不出来**(店抛了 / 超时 / 记录不在 / 记录还在跑)。
- *  `detail.reason` 开集(`checkpoint_store_threw` / `store_threw` / `record_missing` /
- *  `record_not_terminal`…;词表属主在 core)⇒ 读得出即原样带,读不懂**不折**已知词。 */
 const WORKFLOW_PARK_TRUTH_UNREADABLE = 'workflow.park_truth_unreadable';
-/** 记录说这一序号 park 着,而 checkpoint 店说那只审批**已决 / 已过期 / 被回收**。
- *  `detail.status` 三词(`absent` / `expired` / `resolved`)+ `detail.ordinal`;
- *  `detail.checkpointId` **可缺席**(店里没 id)—— 缺席 ≠ 「没有 checkpoint」。 */
 const WORKFLOW_PARK_NOT_PENDING = 'workflow.park_not_pending';
-/** 记录里的 park **绑不回**它的 checkpoint(记录自相矛盾)。`detail.ordinal` 在场。 */
 const WORKFLOW_PARK_BINDING_BROKEN = 'workflow.park_binding_broken';
-/** 这条 workflow 的子代会 park,而部署**没有 run 店**(或没有 checkpoint 店)⇒ 没有耐久行可供
- *  宿主按它路由那只停着的审批。`detail` 恒空对象(这是**配置**问题,不是某一条 run 的事实)。 */
 const WORKFLOW_PARK_REQUIRES_RUN_STORE = 'workflow.park_requires_run_store';
-/**
- * workflow **park 真相**拒绝码的闭集(四员;core 7.17.0 `workflow.ts:602` 码集)。
- *
- * 🔴 闭的是「**这四个码是 park 真相这一族独有的**」,不是「`workflow.*` 一共有几个码」——
- *    后者仍是开集(`workflow.governance_key_stripped` / `workflow.agent_option_ignored` 是通告码,
- *    `workflow.journal_incompatible` 是另一族拒绝码,各有各的既有处置)。
- * 🔴 **绝不靠 `workflow.park_` 前缀放宽**:前缀是个命名巧合,不是契约;上游哪天加第五个码,
- *    该在这里显形并被人处置,而不是被一条前缀判据无声吞进来。
- * 🔴 形制:`Object.freeze` 的数组(同 {@link DECIDE_WORKFLOW_LANE_CODES})。
- */
 export const WORKFLOW_PARK_REFUSAL_CODES = Object.freeze([
     WORKFLOW_PARK_TRUTH_UNREADABLE,
     WORKFLOW_PARK_NOT_PENDING,
@@ -466,63 +107,16 @@ export const WORKFLOW_PARK_REFUSAL_CODES = Object.freeze([
     WORKFLOW_PARK_REQUIRES_RUN_STORE,
 ]);
 const WORKFLOW_PARK_REFUSAL_CODE_SET = new Set(WORKFLOW_PARK_REFUSAL_CODES);
-/**
- * 这个码是不是 workflow park 真相族的拒绝码({@link WORKFLOW_PARK_REFUSAL_CODES} 的成员)。
- *
- * 🔴 表外码 ⇒ `false` = 「本端认不出它属于这一族」,**不是**「这次 resume 没问题」。
- * 🔴 非串 / 空串 ⇒ `false`;认**原始值**(消毒只进文案,不进判据)。
- */
 export function isWorkflowParkRefusalCode(code) {
     return typeof code === 'string' && WORKFLOW_PARK_REFUSAL_CODE_SET.has(code);
 }
-// ── drain / 场景执法族(A-028.11/.13 单源化,#244 族E,2026-08-15)────────────────────────────
-/**
- * server 温切 drain 门的 pre-stream 拒收码(503 + `errorCode:"draining"`;server 侧
- * `error:"draining"` 是冻结契约,SDK toApiError 盖成 `errorCode`)。此前壳/包注释各持裸字面。
- */
 export const DRAINING_ERROR_CODE = 'draining';
-/**
- * 场景执法拒绝码(service gateScenarioRequest 的 400;SDK `ScenarioNotAllowedError`)。
- * 判型半场见 wireErrorTriage.scenarioDenyFromError;allowlist 渲染归各端。
- */
 export const SCENARIO_NOT_ALLOWED_ERROR_CODE = 'scenario_not_allowed';
-// ── 流控族(SDK 6.2.0 CB-1/TR-6 的 `error` 臂)───────────────────────────────────────────────
-/**
- * 15 分钟流帽(server `src/http/sse-log.ts`)。
- * 🔴 **到达 ≠ run 死了** —— 帧自己就说「run 仍然活着」。正确处置 = 按 `Last-Event-ID` 重连续读
- * (`runs.events` 车道由 SDK 内部自动做)。把它当终态渲染会把一条还在跑的任务在 UI 上判死。
- * `errorCode` 整体开集:未知码按「可重连的流控信号」通用降级,不要按成员判死。
- */
 export const STREAM_MAX_DURATION = 'STREAM_MAX_DURATION';
-/** {@link ModelFallbackReason} 的唯一成员(今天)。 */
 export const MODEL_FALLBACK_INHERIT_NO_TIER_BINDING = 'inherit_no_tier_binding';
-/** wire 上的 `modelFallback` 窄化:是闭集成员才认,别的一律当缺席(不认得的原因 ≠ 编一个)。 */
 export function asModelFallbackReason(v) {
     return v === MODEL_FALLBACK_INHERIT_NO_TIER_BINDING ? MODEL_FALLBACK_INHERIT_NO_TIER_BINDING : undefined;
 }
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-// 0.68.0(L-246 A13)—— 引擎的 **turn 停止原词** → CC `stop_reason`(**唯一映射铸点**)
-// ══════════════════════════════════════════════════════════════════════════════════════════════
-//
-// ── 为什么它下沉到包里 ────────────────────────────────────────────────────────────────────────
-// 这张表此前住在壳里(cli `printStreamJsonContract.ts` 的 `ENGINE_STOP_REASON_TO_CC`),而它是一张
-// **CC 皮肤词汇表** —— 本包的立意逐字是「Every CC-skin shape is collected here so the wire itself
-// stays neutral」。住在壳里的后果是三端各铸一份:web / desktop 要渲同一个 `stop_reason` 时只能
-// 自己再抄一遍五个词,而下一次 core 归一化词表变动时,漏掉的那一份会把**这一轮为什么停**渲错 ——
-// 而那恰恰是出错/被截断那一刻最需要读对的一格。
-//
-// ── 左右两列的出处 ────────────────────────────────────────────────────────────────────────────
-// 左列 = `turn_end.stopReason`(core `StopReason` 归一化后的五词;core `task-event.d.ts` 逐字:
-//   「Typed `string` (not the internal `StopReason`) to keep the engine's union private, but the
-//   value set is exactly those five tokens」)—— 本包的 `turn_usage._sema_stop_reason` 原词透传它。
-// 右列 = CC stdout 契约上的 `stop_reason`。
-/**
- * 引擎 turn 停止原词的**识别表**(五词;core `StopReason` 归一化后的值集)。
- *
- * 🔴 **它是识别表不是闭集判据**:`turn_end.stopReason` 在 sdk 型面上是开放 `string`(上游刻意让
- *    引擎的 union 保持私有)⇒ 引擎比这一端新时真的会送一个第六个词过来。本表回答的是
- *    「我认不认得这个词」,**绝不是**「合法的词只有这五个」。
- */
 export const ENGINE_STOP_REASONS = Object.freeze([
     'stop',
     'length',
@@ -530,15 +124,6 @@ export const ENGINE_STOP_REASONS = Object.freeze([
     'error',
     'aborted',
 ]);
-/**
- * 五词 → CC `stop_reason`。`null` **不是**「没映射」,是**映射到诚实缺席**。
- *
- * 🔴 两条纪律(逐字自壳侧原表搬入,一个字节没改语义):
- *   · `error` / `aborted` 在 CC 的词表里**没有对应词**,而既有结算规则对出错的一轮本来就留 `null`
- *     (schema 可空)⇒ 这里同样**不编一个词出来**;
- *   · **表外词一律不映射**(见 {@link engineStopReasonToCc}):引擎长出第六个词时既不猜也不改既有
- *     结算,让它按修前那条路走完 —— 猜一个 CC 词会让消费者据此判错这一轮的结局。
- */
 const ENGINE_STOP_REASON_TO_CC = Object.freeze({
     stop: 'end_turn',
     length: 'max_tokens',
@@ -546,18 +131,6 @@ const ENGINE_STOP_REASON_TO_CC = Object.freeze({
     error: null,
     aborted: null,
 });
-/**
- * 引擎停止原词 → CC `stop_reason` 的**唯一映射口**。**三态**,刻意不合并:
- *  · `string`      —— 映到了一个 CC 词;
- *  · `null`        —— 映到了**诚实缺席**(`error` / `aborted`:CC 没有对应词,不编一个);
- *  · `undefined`   —— **这个词本端不认识**(表外词 / 非串 / 空串)⇒ 调用方按「不映射」走原路。
- *
- * 🔴 `null` 与 `undefined` 必须分开:前者是「我认得这个词,而它的正确渲法就是没有词」,后者是
- *    「我不认得这个词」。合成一个值 ⇒ 引擎加第六个词那天,它会被渲成一次「这一轮没有 stop_reason」
- *    的**肯定事实**,而真相是这一端读不懂 —— 本仓反复在修的那条「把不知道渲成事实」的病。
- * 🔴 **按自有属性查表**(`Object.freeze` 不移除原型):一个来自 wire 的 `constructor` / `toString`
- *    会命中 `Object.prototype` 上的**函数**并被当成一个 CC 词交出去。
- */
 export function engineStopReasonToCc(stopReason) {
     if (typeof stopReason !== 'string' || stopReason.length === 0)
         return undefined;

package/dist/engineHttpTools.d.ts

@@ -1,31 +1,2 @@
-/**
- * src/engineHttpTools.ts — SDK **纯工具面**的转口口(L-61 / L-318 件④,0.68.2)。
- *
- * ── 病形(为什么要有这一只)──────────────────────────────────────────────────────────────────
- * 端对引擎 wire 的一切消费必须经本包(sdk-isolation 门公约),而 SDK 里有两件**纯工具**至今没有
- * 经本包的路:
- *   · `engineUrl(baseUrl, path)` —— 「URL 去尾斜杠 + 拼路径」的语义单真源(端自己拼字符串就会
- *     在 `//v1/...` 这类形上各错各的);
- *   · `probeHealth(baseUrl, timeoutMs?, fetchImpl?)` —— 引擎存活探针的单真源。
- * 于是 cli 有 5 个产品文件**直连** `@sema-agent/sdk` 只为取这两件(sdk-isolation 存量册
- * `sdk-value` 桶里那几条,`_retirement` 段逐字:「多数只取 engineUrl builder 一件」),web /
- * desktop 接同一条腿时会再各直连一次。
- *
- * ── 为什么这一只可以做**值级**转口(与 core 判官那一只的分界)──────────────────────────────
- * 可移植门(`run-client-core-portability-test.mjs`)对包总入口做两件事:外部包**等值集**
- * `EXPECTED_PACKAGES_INDEX` + esbuild `--platform=browser` 真打一次包。
- *   · `@sema-agent/sdk` **本来就在**那个等值集里(本包已有 5 处值级 SDK import)⇒ 加这一只
- *     不改集合,只让闭包文件数 +1(棘轮按既有姿势逐件记账,见该门 `MAX_CLOSURE_FILES_INDEX` 头注);
- *   · SDK 的 `dist/health.js` **零 import**(实测:整文件一条 `import`/`require` 都没有,传输走
- *     全局 `fetch` = web 标准,不是 Node 内建)⇒ 浏览器打包面零风险。
- * 🔴 对照:`@sema-agent/core` 的同类件**不能**这么做(`hitl/editedRuleTextPrecheck.ts` 头注逐字:
- *    core 的 barrel 值级拉 `node:crypto`/`node:fs`/`node:path`,一条这样的边会把整台引擎焊进
- *    web/desktop 的产物)—— 那一族走**端口注入**形。两者的分界线是「这个外部包在不在等值集里」,
- *    不是「它是不是纯函数」。
- *
- * 🔴 **原样转口,一个字节都不加工**:本模块不包装、不改签名、不补默认值 —— 包一层就是把「同一
- *    函数体」这条唯一的抗漂移保证亲手拆掉(与 `editedRuleTextPrecheck` 的装口纪律同一条)。
- *    要在这两件之上加判定的那天,新开一个具名模块,别往转口口里塞。
- */
 export { engineUrl, probeHealth } from '@sema-agent/sdk';
 export type { ProbeHealthResult } from '@sema-agent/sdk';

package/dist/engineHttpTools.js

@@ -1,30 +1 @@
-/**
- * src/engineHttpTools.ts — SDK **纯工具面**的转口口(L-61 / L-318 件④,0.68.2)。
- *
- * ── 病形(为什么要有这一只)──────────────────────────────────────────────────────────────────
- * 端对引擎 wire 的一切消费必须经本包(sdk-isolation 门公约),而 SDK 里有两件**纯工具**至今没有
- * 经本包的路:
- *   · `engineUrl(baseUrl, path)` —— 「URL 去尾斜杠 + 拼路径」的语义单真源(端自己拼字符串就会
- *     在 `//v1/...` 这类形上各错各的);
- *   · `probeHealth(baseUrl, timeoutMs?, fetchImpl?)` —— 引擎存活探针的单真源。
- * 于是 cli 有 5 个产品文件**直连** `@sema-agent/sdk` 只为取这两件(sdk-isolation 存量册
- * `sdk-value` 桶里那几条,`_retirement` 段逐字:「多数只取 engineUrl builder 一件」),web /
- * desktop 接同一条腿时会再各直连一次。
- *
- * ── 为什么这一只可以做**值级**转口(与 core 判官那一只的分界)──────────────────────────────
- * 可移植门(`run-client-core-portability-test.mjs`)对包总入口做两件事:外部包**等值集**
- * `EXPECTED_PACKAGES_INDEX` + esbuild `--platform=browser` 真打一次包。
- *   · `@sema-agent/sdk` **本来就在**那个等值集里(本包已有 5 处值级 SDK import)⇒ 加这一只
- *     不改集合,只让闭包文件数 +1(棘轮按既有姿势逐件记账,见该门 `MAX_CLOSURE_FILES_INDEX` 头注);
- *   · SDK 的 `dist/health.js` **零 import**(实测:整文件一条 `import`/`require` 都没有,传输走
- *     全局 `fetch` = web 标准,不是 Node 内建)⇒ 浏览器打包面零风险。
- * 🔴 对照:`@sema-agent/core` 的同类件**不能**这么做(`hitl/editedRuleTextPrecheck.ts` 头注逐字:
- *    core 的 barrel 值级拉 `node:crypto`/`node:fs`/`node:path`,一条这样的边会把整台引擎焊进
- *    web/desktop 的产物)—— 那一族走**端口注入**形。两者的分界线是「这个外部包在不在等值集里」,
- *    不是「它是不是纯函数」。
- *
- * 🔴 **原样转口,一个字节都不加工**:本模块不包装、不改签名、不补默认值 —— 包一层就是把「同一
- *    函数体」这条唯一的抗漂移保证亲手拆掉(与 `editedRuleTextPrecheck` 的装口纪律同一条)。
- *    要在这两件之上加判定的那天,新开一个具名模块,别往转口口里塞。
- */
 export { engineUrl, probeHealth } from '@sema-agent/sdk';