@sema-agent/server 7.146.0 → 7.147.0

package/dist/observability/fail-open.d.ts

@@ -217,7 +217,7 @@ export declare const FAIL_OPEN_TAGS: {
     };
     readonly "server.session-id-tombstone.evicted": {
         readonly cls: "P-DEBT";
-        readonly note: "`deleted-session-ids.ts` 的 `retireSessionId`(本进程删过的会话 id → 删前属主那张表的唯一铸点;执行上下文解析器 `resolveExecutionContext` 读它,拒本进程上这只 id 的执行服务删前属主之外的住客 —— 409 `conflict.session_id_retired`):表满(`DELETED_SESSION_ID_CAP` 条)⇒ 驱逐最旧的一条,那个 id 回到「本进程没删过」。保护面、方向明知是放行 ⇒ 记债:表独自守着一个窄 P 面 —— 本服务按裸会话 id 键的通告分流器(`EngineNoticeRouter`)收委派腿的用户面通告,引擎 7.64.0 的地址是树根会话 id、不带住客 ⇒ 被驱逐的那个 id 上,另一位属主在本进程重登之后,前任住客子代的被拒通告可按 id 落进新住客的流(暂存那一形不在其内:引擎 7.64.0 起按住客存取,弃掉、运维席一条 delegation.delivery_discarded)。不放行的形是表无界增长。收口条件 = core #3479(委派腿通告地址带根住客)到货 ∧ 服务侧按裸会话 id 键的座普查为零 —— 届时表、本 tag 与 409 `conflict.session_id_retired` 一并退。";
+        readonly note: "`deleted-session-ids.ts` 的 `retireSessionId`(本进程删过的会话 id → 删前属主那张表的唯一铸点;执行上下文解析器 `resolveExecutionContext` 读它,拒本进程上这只 id 的执行服务删前属主之外的住客 —— 409 `conflict.session_id_retired`):表满(`DELETED_SESSION_ID_CAP` 条)⇒ 驱逐最旧的一条,那个 id 回到「本进程没删过」。保护面、方向明知是放行 ⇒ 记债:表独自守着一个窄 P 面 —— 本服务按裸会话 id 键的通告分流器(`EngineNoticeRouter`)收委派腿的用户面通告;引擎 7.65.0 起这些通告按根会话 id + 树出生时的根住客投递(本进程接纳过叶的根被重建 ⇒ 前任树的通告弃掉、运维席一条 path notice 的 delegation.delivery_discarded),余下的是引擎写下的已知限度 —— 根重建了而本进程还没接纳它的叶(或叶在别的进程跑)时前任树的通告仍按 id 投递 ⇒ 被驱逐的那个 id 上,另一位属主在本进程重登之后,前任住客子代的被拒通告在这一形上仍可按 id 落进新住客的流(暂存那一形不在其内:引擎 7.64.0 起按住客存取,弃掉、运维席一条 delegation.delivery_discarded)。不放行的形是表无界增长。收口条件 = 那一已知限度收口 ∧ 服务侧按裸会话 id 键的座普查为零 —— 届时表、本 tag 与 409 `conflict.session_id_retired` 一并退。";
     };
     readonly "server.approvals.queue-row-gate-kind-missing": {
         readonly cls: "F";
@@ -225,7 +225,7 @@ export declare const FAIL_OPEN_TAGS: {
     };
     readonly "server.sql-json.checkpoint.pending-steer-queue-lossy": {
         readonly cls: "F";
-        readonly note: "S-550(`stores-sql/checkpoint-store-sql.ts` 的 `get()`,core 5.14.0 #147 的耐久转向队列):一条挂起 run 的 `checkpoint.pending_steer_queue` 这一格**没能完整读出来**(不是合法 JSON 文本 / 不是数组 / 某一条目的四个必备键不合形)⇒ 读不出的那部分**丢掉**,run 照常 resume。放行的最坏后果 = 一条已经 park 的操作员转向指令**没有**在这次 resume 上注入(人以为说过的话没送到);不放行的代价是这条挂起的 run **永远不可 resume** —— resume 是它唯一的出路,为一格读不出的转向把整条 run 变成砖是错误的失败方向(写侧刻意相反:`setPendingSteer` 往一份读不全的队列上追加会把读不出的条目永久抹掉,那里 fail-loud)。故 F 类。留痕从一条 `logger.info` 升成登记 tag 的理由:日志行在**遥测轴**上是零信号,「这台机器的转向队列一直读不出来」与「这台机器本来就没人 steer」在指标上完全同形。计数非零 = 去按日志里的 token 指纹查那一行。";
+        readonly note: "S-550(`stores-sql/checkpoint-store-sql.ts` 的 `get()`,core 5.14.0 #147 的耐久转向队列):一条挂起 run 的 `checkpoint.pending_steer_queue` 这一格**没能完整读出来**(不是合法 JSON 文本 / 不是数组 / 某一条目缺店铸键 `seq` / `inputId`,或过不了 core 的 `validatePendingSteer`——含领先一版的写者留下的、带冻结表外键的条目:判官拒,不再静默丢掉那一键后照常注入)⇒ 读不出的那部分**丢掉**,run 照常 resume。放行的最坏后果 = 一条已经 park 的操作员转向指令**没有**在这次 resume 上注入(人以为说过的话没送到);不放行的代价是这条挂起的 run **永远不可 resume** —— resume 是它唯一的出路,为一格读不出的转向把整条 run 变成砖是错误的失败方向(写侧刻意相反:`setPendingSteer` 往一份读不全的队列上追加会把读不出的条目永久抹掉,那里 fail-loud)。故 F 类。留痕从一条 `logger.info` 升成登记 tag 的理由:日志行在**遥测轴**上是零信号,「这台机器的转向队列一直读不出来」与「这台机器本来就没人 steer」在指标上完全同形。计数非零 = 去按日志里的 token 指纹查那一行。";
     };
     readonly "server.sql-json.checkpoint.outcome-unreadable": {
         readonly cls: "F";
@@ -295,6 +295,10 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "#310(codex 对抗复审 R1-[medium],验真后修):三条 run 腿把一条白名单通告写进 durable 账本时,那次 `appendEvent` **异步 reject**(store 抖动 / 连接断 / 行冲突)。结构上不能 await —— `onNotice` 是 core 的同步回调,拿一次账本写去阻塞引擎是更坏的交易 —— 所以写口只能 fire-and-forget,`route` 的同步 try 结构性观察不到这次失败 —— 「投出去了」与「真落盘了」不是同一件事。放行的最坏后果按腿分档,如实登记:**sync stream 腿**还有 live SSE 那一份(在线的人看得见,丢的是断连补看;写失败时 live 可以多于账本 —— 用户看见了、回放里没有,本 tag 计一次);**bg / resume 两腿账本是唯一的用户可见终点** ⇒ 那条通告对用户永久消失。仍判 F 而不是 P:通告是**披露**面不是执法面(不参与任何门/裁决),且运维面那一份(结构化日志 `engine_notice`)在分流之前就已经落定、一条不丢。此前是裸 `.catch(() => undefined)` —— 同文件 resume 腿的子代 forward 写口早在 C2/C5 批2 就因为「裸吞 = 事件从 durable log 永久消失且零信号」补过 `warnAppend`,本 tag 是同一条纪律在通告口的落实(warn 留细节 + 计数让「系统性在漏」显形)。不做重试队列是刻意的:账本里没有任何一族行做有界重试,单给通告开一条会造出第二套持久化语义。";
     };
+    readonly "server.memory.store-form-refused-step-skipped": {
+        readonly cls: "F";
+        readonly note: "`memory-incident-sink.ts` 的 `createMemoryEngineIncidentSink`(两只宿主 `onError` 的 `memory` 相共用的落点):记忆相上到达店形拒族(`STORE_FORM_REFUSAL_CODES`,按族读;引擎 7.65.0 起含控制面所在文件系统不能建硬链接的 `memory.control_plane_links_unsupported`)的码 ⇒ 引擎的一步记忆活被店拒、会话照跑:mount 时开店被拒 ⇒ 这一跑记忆面读作 `memoryless`(`mount-failed`);mount 之后的整理 / 收割撞上 ⇒ 那一步没做(席只认码与相,不分哪一步 —— 是哪一步看同一行 `memory_engine_incident` 的句子)。放行的最坏后果 = 这一跑没有记忆或少做一步记忆活(不召回、不采集、不收割、不整理)—— 少做,不是错做:不开门、不放宽任何判据,模型读不到的是记忆不是别的;不放行的代价是记忆盘一个挂载面的形不对就让每一跑都失败。留痕是因为「这台部署的记忆从来没挂上」与「会话里本来没东西可记」在外部同形:逐次计数 + 探针 + 每进程一次 warn,detail `code=<店形拒码>`(运维行 `memory_engine_incident` 另带码与经出口座的句子);出路 = 把记忆控制面放到支持硬链接的卷上(或按码修挂载形)后重启。";
+    };
     readonly "server.memory.locked-layer-probe-partial": {
         readonly cls: "F";
         readonly note: "O2(7.101.0 合并复审,`memory-layer-legacy-lock.ts announceLockedLegacyMemoryLayers`,boot 期锁住记忆层探测;detail 只报 `unreadable=<条数>`):挂载面或某个层里的目录**读不出**(EACCES 之类 —— 不是 ≤7.30.x 引擎的锁形,那种 0555 目录可读)⇒ 那棵子树看不全,照常起服。放行的最坏后果 = 一个锁住的层在 boot 日志里没被点名 —— 探测是**披露**面,不参与任何门 / 裁决;core 在真正失败的那一次删除上仍给出自己的 `chmod -R u+w` 补救句。不放行的代价严重不对称:为一条 warn 打死起服(混跑窗里能服务的副本)。计数让「这台部署的记忆树有读不出的目录」显形。";
@@ -305,7 +309,7 @@ export declare const FAIL_OPEN_TAGS: {
     };
     readonly "server.session-workspace.record-degraded": {
         readonly cls: "F";
-        readonly note: "会话行的位置与项目那一格(`session_meta.workspace` / local `session-workspaces.json`;唯一写者 `session-workspace.ts` 的腿记录座,唯一列属主 `plugins/session-workspace-cell.ts`;detail 的 `op` 点名哪一步):`op=write` 一次写失败(库抖 / 盘满 / 锁等待超时)⇒ 行停在上一帧,下一帧照写;`op=read` 一格读不出(被带外改坏)⇒ 读作没有记录,下一帧整格重写;`op=frame` 一帧投不成存储形(引擎不会铸出这种帧)⇒ 这一帧不记。这一格是宿主对**引擎判过的答案**的记录,不是判据 —— 引擎每条腿都重判项目(有记号就判记号,声明不等响亮拒)。放行的最坏后果 = 这只会话的下一条不带 `projectId` 的提交续声明的是旧的项目或不声明(没有记号的检出里这只会话少一次续声明);不放行的代价是把一条在跑的腿、或这只会话往后的每一次提交,为一份记录摔掉。计数非零 = 这台部署的会话店写不动 / 有人改过库。";
+        readonly note: "会话行的位置与项目那一格(`session_ext.workspace` / local `session-workspaces.json`;唯一写者 `session-workspace.ts` 的腿记录座,唯一列属主 `plugins/session-workspace-cell.ts`;detail 的 `op` 点名哪一步):`op=write` 一次写失败(库抖 / 盘满 / 锁等待超时)⇒ 行停在上一帧,下一帧照写;`op=read` 一格读不出(被带外改坏)⇒ 读作没有记录,下一帧整格重写;`op=frame` 一帧投不成存储形(引擎不会铸出这种帧)⇒ 这一帧不记。这一格是宿主对**引擎判过的答案**的记录,不是判据 —— 引擎每条腿都重判项目(有记号就判记号,声明不等响亮拒)。放行的最坏后果 = 这只会话的下一条不带 `projectId` 的提交续声明的是旧的项目或不声明(没有记号的检出里这只会话少一次续声明);不放行的代价是把一条在跑的腿、或这只会话往后的每一次提交,为一份记录摔掉。计数非零 = 这台部署的会话店写不动 / 有人改过库。";
     };
     readonly "server.local-session-row.created-at-absent": {
         readonly cls: "F";
@@ -323,10 +327,6 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "S-995(`hooks/hook-runner.ts` 的 `hooksMatcherIssue`,fresh 受理面「工具事件 matcher 选中别名而选不中正名 ⇒ 400」判据的**未判**臂;detail = `event=… reason=… matcherChars=…`,不带 matcher 原字节):一只 matcher 没能被判 ⇒ 照旧受理。判据一条顺序、两档共用(7.114.0 修复轮):长度上限 → 形只问契约包的 `hookMatcherForm`(literal 形〔名字表 / 空 / `*`〕两档都直接问 `hookMatcherSelects`、不占预算;regex 形 regex 档把同一只契约函数交进 vm 带每次求值各一份的固定预算〔超时 = 灾难回溯 ⇒ 确定的 400 拒,不是未判、不登记;一次受理里所有已完成求值的耗时之和超过受理总额度同样是确定的 400 拒〕、literal 档不适用;invalid 形 regex 档 = 确定的 400 拒〔S-1455 收尾:不是未判、不登记;运行期另记 `hook_matcher_invalid`;形判对所有契约事件同一判,不止工具事件〕、literal 档不适用)。现在只有一种 reason —— `oversize`(两档:超 8 192 字符不读;多租户车道上 hooks 不装配,这一笔只为让超长输入显形)。`invalid_regex` 臂自 S-1455 收尾(7.126.0)起退役:它是确定性的坏配置、不是「判不了」,与超预算同类 ⇒ 受理当场 400。**不记**的:literal 档(多租户车道)遇正则形 = 不适用 —— 该车道 hooks 整只不装配,没有被守的对象,不是未判。放行的最坏后果 = **那一只 matcher 没被这条判据守住**:它若真写了别名,照旧永不命中(7.112.0 对正则形一律不判,同一后果);**不是安全闸**(受理面的有效性判 = S-924 的「响亮」,决定不了任何放行 / 拒绝 / 权限;hook 的 deny 语义在运行期 hook-runner)。拒放集合相对 7.113.0 的一处放宽:超过上限的字面别名 matcher 7.113.0 拒、7.114.0 两档未判受理(已披露)。计数让「受理面一直判不了」(超长 matcher)显形。";
     };
-    readonly "server.hooks.resume-reader-refused": {
-        readonly cls: "P-DEBT";
-        readonly note: "续跑重放(`task-settings.ts` 的 `parseTaskSettings`,经 `boot/resolve-spec.ts` 装配)读存下的请求体里的 `settings.hooks`,而 hooks 配置的唯一读者(契约包分类器,`hooks/hook-runner.ts` 的 `parseHooksConfig`)判不过、也没被一次性迁移 M20 接住(窗已关,或拒因不属 M20 的两形 —— 藏着守卫迹象的未知字段 / JSON `__proto__` 事件键)⇒ 这份 hooks **整只不采纳**(`task_settings_deferred` 记账),任务照常续跑 —— 其中若有真在拦的 `PreToolUse` 钩子,续跑后不再拦。M20 窗开着时那两形不进这一臂(剥键重读、守卫照跑,一行 `hooks_read_as_before_upgrade`)。只在 hooks 会被采纳的单用户车道计数(多租户整只忽略 hooks,无物可丢);fresh 提交不进这一臂(受理面 400)。放行的最坏后果:升级前停驻、体里 hooks 带那两形之一的任务,在窗关之后才续跑的(发布后才升级的部署、调长了 `APPROVAL_TERMINAL_BACKSTOP_MS` 的部署、滚动升级里旧副本在窗内新写的行),或体里 hooks 带别的坏形的,失去这份 hooks 里原本真在拦的钩子。方向已裁:持久数据面走 M20 窗内迁移,窗关后整份不采纳 + 本计数(存量停驻行此时已被收割,计数应趋零)。detail = `leg=`。计数非零 = 有任务带着被读者拒掉的存量 hooks 在续跑。";
-    };
     readonly "server.hooks.notice-sink-threw": {
         readonly cls: "F";
         readonly note: "#281:hook 观测回调(`onHookNotice`,部署把它接到 fleet 流)自己抛了。放行的最坏后果 = **这一条观测帧**缺席;补偿是结构性的:①日志终点在投递之前就已逐字落定(`hook_command_failed` / `hook_command_timeout` / `hook_command_spawn_failed` 一族),运维面零回退;②观测帧不参与任何门/裁决(纯 observe,#281 全族判据里「裁决面一个字节不动」是承重条款),故 F 类。不放行的代价严重不对称:异常会掀回 core 的 hook 回调栈,把一次**观察动作**变成一次**工具调用失败** —— 「观察一件事的动作反过来改变了那件事」正是本 tag 要根除的形,而它伤的恰恰是 hook 已经坏掉、用户最需要任务照跑的那一刻。留痕承重:静默吞掉之后「这台机器为什么一条 hook 通知都没有」在遥测里与「hook 从来没坏过」同形。";
@@ -467,6 +467,10 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "S-322(`approval-ask-audit-store.ts` `rotateOlderThan`,审批账本留存律的审计账半场):轮转把留下的行原字节写进暂存文件(core `writeThenLink`:数据已 fsync)并 `rename` 盖上之后,目录 fsync 失败。换文件**已经落定且可见**、内存索引与 `crashConverged` 读面已经跟上,所以不回滚(也回滚不了)、读数照交。放行的最坏后果:掉电后目录项可能还指旧账本 ⇒ 删掉的行回来(下一拍再删,无害),轮转之后追加、在下一次目录落盘之前掉电的行可能丢(与 `append-failed` 同类后果:痕迹缺几条,审批结算不受影响)。与 core 原子写对目录 fsync 的尽力而为同一姿态(core 吞掉),这里改为留痕。审计店不开门、不改任何审批结算 ⇒ F。";
     };
+    readonly "server.atomic-write.dir-fsync-failed": {
+        readonly cls: "F";
+        readonly note: "`plugins/owner-only-file-mode.ts` 本仓原子写的两个出口,**只在调用方声明 `durability: \"best-effort\"` 时**(同步 `atomicWriteFileSync`:完成收件箱账本的压实 `orchestration/workflow-completion-inbox.ts`、续租被拒的粘性位 `fleet/serving-lease.ts`;异步 `atomicWriteFileAsync`:附件店、会话边档、记忆同步游标、LKG、技能正文盘缓存;声明 `required` 的调用方 —— local 数据根的引擎版本高水位 marker —— 目录 fsync 失败即抛,不走本 tag):tmp 已 fsync、`rename` 已盖上之后,目录 fsync 失败(打不开目录 / 文件系统不支持对目录 fsync / EIO)。换文件**已经落定且可见**,不回滚(也回滚不了)、不抛(抛 = 把一次已生效的写报成失败:压实在起服构造里跑 ⇒ 拒启;异步写口的调用方会把已落下的附件 / 游标报成写失败)。放行的最坏后果:掉电后目录项可能还指旧文件或缺席 —— 收件箱账本回到压实前那一本(内容是压实前的超集,重放结果相同),压实之后追加到新账本、在下一次目录落盘之前掉电的行可能丢(已投进箱的通告少几条,不放行任何东西);粘性位回到上一份或缺席(重启后到第一次续租答复之前接单 —— 与 `server.fleet.denied-marker-unpersisted` 同一窗);附件 / 边档 / 游标 / LKG / 盘缓存回到上一份或缺席(与这些写口修前不 fsync 的常态同一后果:游标重同步、盘缓存重取、LKG 缺席走冷启动)。与 core `atomicWriteFile` 对目录 fsync 的尽力而为同一姿态(core 吞掉),这里改为留痕;core 的原子写改成独占新建 tmp 之后,同步的两处调用方改回 core(同步出口退役),本座留给异步出口。不开门、不改任何判据 ⇒ F。";
+    };
     readonly "server.approval-ask-audit.corrupt-record-skipped": {
         readonly cls: "F";
         readonly note: "S-967(`approval-ask-audit-store.ts`,local 车道 File ask 审计店的 boot 重放;登记名 `approval-ask-audit`):账本**中间**一行读不出形(`42` / 数组 / 缺键 / 词表外 `kind`·`outcome`·`orphanState` / 半截 JSON;撕尾不走本 tag)⇒ 跳过它继续。最坏后果按行种:丢 `ask` ⇒ 那只孤儿在崩溃收敛读面缺席(无身份可列);丢 `settle` ⇒ 该组按 pending 臂收(审批门在执行之前 ⇒ 若这条 settle 其实是 `allowed` 且工具已执行,`resumeSafe:true` 是错的 —— 与头注「双故障窗」同族);丢 `leg_closed` ⇒ decided 臂多收一行(保守方向);丢 `crash_converged` ⇒ 下一次 boot 重收(幂等);丢 `interrupted_by_shutdown` / `late_settle` ⇒ 成因注退回 `crashed_before_park` / 少一行取证。审计店不开门、不改任何审批结算 ⇒ F。修前:重放坏行只计入 `convergeCrashedAsks().corruptLines`(boot 日志一个数),**无逐条披露、无 tag**。";
@@ -483,6 +487,10 @@ export declare const FAIL_OPEN_TAGS: {
         readonly cls: "F";
         readonly note: "S-978(`orchestration/workflow-completion-inbox.ts`,local 车道 File 完成信箱的 boot 重放;登记名 `workflow-completion-inbox`):账本**中间**一行读不出形(`42` / `null` / 数组 / 缺 `op` 或 `op` 词表外 / `enqueue` 缺 `entry.sessionId`·`entry.runId` / `ack` 缺 `sessionId`·`runId` / `drain` 缺 `sessionId` / 半截 JSON;撕尾不走本 tag)⇒ 跳过它继续。最坏后果按行种:丢 `enqueue` ⇒ 那条完成推送不进信箱(`WorkflowStatus` 轮询地板照旧兜住);丢 `ack` ⇒ 一条已送达的完成在重启后再投一次(壳按 runId 去重,至少一次的既有语义);丢 `drain`(会话清除墓碑)⇒ 被删会话里尚未送达的条目复活 —— 出帧前仍过 owner 二道闸(`emitPendingWorkflowCompletions`:条目盖的 owner 与本次调用方不符 ⇒ ack 丢弃、不出帧),同属主重领同一 sessionId 只会多收一条按 runId 去重的推送。信箱不开门、不改任何 run 的执行或授权 ⇒ F。修前:解析失败 `continue`(静默),而解析成功的 `null` 行在读 `rec.op` 时抛 TypeError ⇒ `new FileWorkflowCompletionInbox` 抛(构造点无 catch ⇒ 这一面起不来),其余非对象 / 缺键形静默忽略。boot 压实随后从内存活集重写账本 ⇒ 坏行的字节压实后不留盘,披露是它唯一的记录。";
     };
+    readonly "server.workflow-completion-inbox.payload-over-budget": {
+        readonly cls: "F";
+        readonly note: "停驻收件条目编码座(`orchestration/workflow-completion-inbox.ts` 的 `encodeInboxBody`,两个家族的写口都只经它):条目 `payload` 的最终 JSON 按 UTF-8 字节超出预算(= 最窄后端的 `payload` 列容量,`plugins/inbox-payload-column.ts`;MySQL 协议 `TEXT` 65,535 字节)⇒ 入店的是**最小形**:帧的流侧去重键字段(`task_type` / `task_id` / `status` / `seq` / `attempt` 里全形带着的那几位)+ 归因侧记 `_sema_provenance`(在场且装得下即留)+ `payloadTruncated { droppedKeys, bytes }`,其余成员整只丢并在带内点名;连侧记也装不下(病态 `task_id` / 侧记成员)⇒ 侧记也丢,此时全形若带归因成员,`summary` 列换成本服务铸的受信句、`droppedKeys` 末尾记 `summary`(对端写的摘要不脱离归因单独出帧)。**不是放宽**:这条臂保的是投递 —— 修前越列宽的条目在 MySQL 协议后端上 INSERT 整条失败(通知丢,只剩一行日志),PG / File 照存,两副结局;现在三店收同一份判过的字节。丢的是一只照样送达的展示帧里的内容成员(`result` / `lines` / `editedFiles` / 侧记 / 载体 …),不开门、不改任何判据或授权;整类丢而不是按大小挑着丢,归因随文本走:摘要只在归因还在时原样出帧。最坏后果 = 收件人这一帧看到的细节少了(`status` 在列里照到,`payloadTruncated` 点名丢了什么;最坏连摘要原句也换成受信句)⇒ F。detail = `sessionId=… key=<收件键> bytes=<全形字节> budget=<预算> dropped=<键名>`。计数持续非零 = 有停驻通知的扩展成员常年越过列宽(看是哪类成员,考虑在产生方收紧逐成员界)。";
+    };
     readonly "server.user-input-ledger.append-failed": {
         readonly cls: "F";
         readonly note: "S-928(`src/user-input-ledger.ts`):200 承诺**之后**的一次账本写失败 —— detail 的 `op=` 点名是哪一种:`settle`(腿在本进程收场)/ `withdraw`(引擎没收下这次 steer)/ `converge`(收敛器判孤儿)/ `announce`(通告已投出,记「告知过」)。放行的最坏后果逐个说清:settle / withdraw 漏写 ⇒ 这次受理在账上仍是 open —— 本进程下一次收敛扫描补结清(本进程写的、已不在活腿上 ⇒ leg_over);进程在那之前就崩了 ⇒ 下一次 boot 的收敛读 run 店判(S-969 L8 起两车道同一只判词:承载它的 run 正常翻面 / 已 park ⇒ leg_over 补结清、不告知;落款死亡判决或写者已死仍 running ⇒ crashed)—— 仍会多说一句的只剩两形:withdraw 漏写后那条腿崩了(一次没变成 200 的受理被告知一次);settle 漏写后本进程续跑了同一条 run、续跑腿崩了(run 行说的是同一 taskId 上**最新**那条腿)。方向都是多说,不漏;converge 漏写 ⇒ 留在 open,下一次扫描再判(延迟,不丢);announce 漏写 ⇒ 下一条 run 再说一遍(至多一次退化成至少一次)。都是**告知面**的偏差,不开任何门、不改任何 run 的执行 ⇒ F。计数非零 = 这台机器的账本写不动了(local:数据根盘满 / 只读;SQL:库不可达),steer 此刻多半也在回 503。";
@@ -603,7 +611,7 @@ export declare const FAIL_OPEN_TAGS: {
     };
     readonly "server.remote-write.staging-dir-left": {
         readonly cls: "F";
-        readonly note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备 / 提交脚本删一只私有暂存目录(`.<名>.stage-<十六进制>/`,生来 0700;只删这次写放进去的 `data` 与这只空目录,从不递归删)没删掉、在 stdout 写一条记录点名 —— 五处:`mv` 已把暂存件换到目标上之后删当前那只;跟一跳到别的目录重新暂存成功之后删原来那只;重新暂存却没用上(收紧不成 / 拷不成)的那一只;就地拷入 / 追加时删暂存名失败、或写完关掉 fd 后删私有目录失败(有的文件系统为仍打开着的文件留隐藏项:NFS / libfuse / SMB);准备时收不成私有 / 里面已有 `data` 的那一只。目录里多出了不是这次写放进去的东西(同一身份或 root 的别的进程往里写过 / 收紧之前别人放进来的)、目录被换成了符号链接、或文件系统拒删。写照它自己的结局答(提交已成 ⇒ 成功:答失败会让调用方以为目标没变),残留只在这里留痕。放行的最坏后果 = 目标(或链接所指)目录里多一只隐藏目录(空的,或装着别人放进去的东西;重新暂存没用上的那只可能装着这次写的半份新内容),只有写入方进得去;不是门、不是凭据、不碰目标内容。计数非零 = 那台目标机上有东西在往别人的暂存目录里写,或删不动,去看那只目录。detail = 残留目录的路径(一次写最多两只,逐只计)。";
+        readonly note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备 / 提交脚本删一只私有暂存目录(`.<名>.stage-<十六进制>/`,生来 0700;只删这次写放进去的 `data` 与这只空目录,从不递归删)没删掉、在 stdout 写一条记录点名 —— 五处:`mv` 已把暂存件换到目标上之后删当前那只;跟一跳到别的目录重新暂存成功之后删原来那只;重新暂存却没用上(收紧不成 / 拷不成)的那一只;就地拷入 / 追加时删暂存名失败、或写完关掉 fd 后删私有目录失败(有的文件系统为仍打开着的文件留隐藏项:NFS / libfuse / SMB);准备时收不成私有 / 里面已有 `data` 的那一只。目录里多出了不是这次写放进去的东西(同一身份或 root 的别的进程往里写过 / 收紧之前别人放进来的)、目录被换成了符号链接、或文件系统拒删。编排对脚本点名的每一只(按路径去重)再补清一次 —— 只 `rmdir`、不删里面的东西,且只对名字是本次暂存名、路径经 UTF-8 解码仍可信(无 U+FFFD)的动手,别的原样不碰、照样算残留;原私有目录在写没成时另补清它的 `data` 与目录 —— **补清之后仍在的才计数**(异步释放的文件系统上隐藏项此时多半已删净),失败的写同时把它们点进错误句。写照它自己的结局答(提交已成 ⇒ 成功:答失败会让调用方以为目标没变),残留只在这里留痕。放行的最坏后果 = 目标(或链接所指)目录里多一只隐藏目录(空的,或装着别人放进去的东西;重新暂存没用上的那只可能装着这次写的半份新内容),只有写入方进得去;不是门、不是凭据、不碰目标内容。计数非零 = 那台目标机上有东西在往别人的暂存目录里写,或删不动,去看那只目录。detail = 残留目录的路径(一次写最多两只,逐只计一次)。";
     };
     readonly "server.resume-anchor.capture-failed": {
         readonly cls: "F";
@@ -611,7 +619,7 @@ export declare const FAIL_OPEN_TAGS: {
     };
     readonly "server.remote-write.stage-seal-fallback": {
         readonly cls: "F";
-        readonly note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备脚本把刚建的私有暂存目录收成 0700 并读回核实(`chmod 700` 退出 0 ∧ `stat` 读回的模式低三位恰是 700 ∧ 属主 = 本身份),任一步不成 —— `chmod` 被文件系统 / 内核拒;退出 0 却没生效(不认权限位的文件系统);父目录带缺省 ACL 而掩码收不下来;目录上有继承来的 ACL 条目(macOS 原生 ACL / FreeBSD · illumos ZFS 的 NFSv4 ACL)去不掉或读不出,或目标机平台不在读 ACL 的适配器闭集里(`uname -s` 不是 Linux / Darwin / FreeBSD / SunOS);目标机上没有 `stat` —— 准备退出 4、这次写**不暂存**,两只文件面、五条腿一律改为直接写目标(与「目标目录不收新名字」同一条回落;能追加写的腿直接追加,e2b / adb 的追加 = 读旧 + 拼 + 整份写目标 —— adb 的这一形就是 7.138.x 的追加,push 没有追加写)。修前这一步是 `chmod 700 … || :`:加固失败照样放行上传,字节落在一只别的身份可能读得到的目录里(P 轴 fail-open),那一臂已删,字节从不进一只没核成私有的目录。放行的最坏后果 = 这一次写失去「整旧或整新」(非原子:中途断 / 取消 ⇒ 目标可能只写了一半,整份写目标的 e2b / adb 上可能没了或只剩半份;写目标那一步因取消中断答 `unknown`,那一步开始之前取消答 `aborted`、目标未碰,那一步不收取消(ssh 的 sftp)照样写完);ssh / local-docker / k8s 写进原 inode、权限位不变,e2b 的 `files.write` 与 adb 的 push 整份写目标、inode / 权限位由对端定(adbd 不保,与 7.138.x 同形);不是门、不是凭据。Android 共享存储(`/sdcard` 一类:权限位由挂载派生、不认 chmod)上 adb 的写按 sdcardfs / MediaProvider FUSE 的权限语义**推断**每一次都走这里(未上真机,真机读数候 test;结构性,运维修不掉;工作区放在 `/data/local/tmp` 一类认权限位的目录就不走)。计数非零 = 这台目标机的这个目录上私有目录收不成私有(文件系统不认权限位 / 缺省 ACL 掩码收不下来 / 继承来的 ACL 条目去不掉 / 平台不可知 / 缺 `stat`),写在走非原子的退路,去看那个目录。detail = `<目标路径>: <准备脚本写的原因句>`。";
+        readonly note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备脚本把刚建的私有暂存目录收成 0700 并读回核实(`chmod 700` 退出 0 ∧ `ls -ldn` 读回的模式串低三位恰是 700 ∧ 属主 = 本身份),任一步不成 —— `chmod` 被文件系统 / 内核拒;退出 0 却没生效(不认权限位的文件系统);父目录带缺省 ACL 而掩码收不下来;目录上有继承来的 ACL 条目(macOS 原生 ACL / FreeBSD · illumos ZFS 的 NFSv4 ACL)去不掉或读不出,或目标机平台不在读 ACL 的适配器闭集里(`uname -s` 不是 Linux / Darwin / FreeBSD / SunOS);目标机上读不出模式串(`ls` 不可用 / 输出读不懂)—— 准备退出 4(提交脚本里跟一跳链接到别的目录重新暂存的那只目录同判、同一个码:放弃它、目标未碰、编排清掉原暂存件)、这次写**不暂存**,两只文件面、五条腿一律改为直接写目标(与「目标目录不收新名字」同一条回落;能追加写的腿直接追加,e2b / adb 的追加 = 读旧 + 拼 + 整份写目标 —— adb 的这一形就是 7.138.x 的追加,push 没有追加写)。修前这一步是 `chmod 700 … || :`:加固失败照样放行上传,字节落在一只别的身份可能读得到的目录里(P 轴 fail-open),那一臂已删,字节从不进一只没核成私有的目录。放行的最坏后果 = 这一次写失去「整旧或整新」(非原子:中途断 / 取消 ⇒ 目标可能只写了一半,整份写目标的 e2b / adb 上可能没了或只剩半份;取消只看落在哪一段:备件阶段〔第一个字节发往目标机之前:adb 在本机落临时件、ssh 开 sftp 通道含懒重连、k8s 建连、追加退路的读旧 + 拼〕答 `aborted`、目标未碰;传输那一步因取消中断答 `unknown`;那一步不收取消(ssh 的 sftp)照样写完);ssh / local-docker / k8s 写进原 inode、权限位不变,e2b 的 `files.write` 与 adb 的 push 整份写目标、inode / 权限位由对端定(adbd 不保,与 7.138.x 同形);不是门、不是凭据。Android 共享存储(`/sdcard` 一类:权限位由挂载派生、不认 chmod)上 adb 的写按 sdcardfs / MediaProvider FUSE 的权限语义**推断**每一次都走这里(未上真机,真机读数候 test;结构性,运维修不掉;工作区放在 `/data/local/tmp` 一类认权限位的目录就不走)。计数非零 = 这台目标机的这个目录上私有目录收不成私有(文件系统不认权限位 / 缺省 ACL 掩码收不下来 / 继承来的 ACL 条目去不掉 / 平台不可知 / 缺 `stat`),写在走非原子的退路,去看那个目录。detail = `<目标路径>: <准备脚本(或提交脚本重新暂存那一臂)写的原因句>`。";
     };
     readonly "server.park.held-card-void-failed": {
         readonly cls: "F";

package/dist/observability/fail-open.js

@@ -199,7 +199,7 @@ export const FAIL_OPEN_TAGS = {
     },
     "server.session-id-tombstone.evicted": {
         cls: "P-DEBT",
-        note: "`deleted-session-ids.ts` 的 `retireSessionId`(本进程删过的会话 id → 删前属主那张表的唯一铸点;执行上下文解析器 `resolveExecutionContext` 读它,拒本进程上这只 id 的执行服务删前属主之外的住客 —— 409 `conflict.session_id_retired`):表满(`DELETED_SESSION_ID_CAP` 条)⇒ 驱逐最旧的一条,那个 id 回到「本进程没删过」。保护面、方向明知是放行 ⇒ 记债:表独自守着一个窄 P 面 —— 本服务按裸会话 id 键的通告分流器(`EngineNoticeRouter`)收委派腿的用户面通告,引擎 7.64.0 的地址是树根会话 id、不带住客 ⇒ 被驱逐的那个 id 上,另一位属主在本进程重登之后,前任住客子代的被拒通告可按 id 落进新住客的流(暂存那一形不在其内:引擎 7.64.0 起按住客存取,弃掉、运维席一条 delegation.delivery_discarded)。不放行的形是表无界增长。收口条件 = core #3479(委派腿通告地址带根住客)到货 ∧ 服务侧按裸会话 id 键的座普查为零 —— 届时表、本 tag 与 409 `conflict.session_id_retired` 一并退。",
+        note: "`deleted-session-ids.ts` 的 `retireSessionId`(本进程删过的会话 id → 删前属主那张表的唯一铸点;执行上下文解析器 `resolveExecutionContext` 读它,拒本进程上这只 id 的执行服务删前属主之外的住客 —— 409 `conflict.session_id_retired`):表满(`DELETED_SESSION_ID_CAP` 条)⇒ 驱逐最旧的一条,那个 id 回到「本进程没删过」。保护面、方向明知是放行 ⇒ 记债:表独自守着一个窄 P 面 —— 本服务按裸会话 id 键的通告分流器(`EngineNoticeRouter`)收委派腿的用户面通告;引擎 7.65.0 起这些通告按根会话 id + 树出生时的根住客投递(本进程接纳过叶的根被重建 ⇒ 前任树的通告弃掉、运维席一条 path notice 的 delegation.delivery_discarded),余下的是引擎写下的已知限度 —— 根重建了而本进程还没接纳它的叶(或叶在别的进程跑)时前任树的通告仍按 id 投递 ⇒ 被驱逐的那个 id 上,另一位属主在本进程重登之后,前任住客子代的被拒通告在这一形上仍可按 id 落进新住客的流(暂存那一形不在其内:引擎 7.64.0 起按住客存取,弃掉、运维席一条 delegation.delivery_discarded)。不放行的形是表无界增长。收口条件 = 那一已知限度收口 ∧ 服务侧按裸会话 id 键的座普查为零 —— 届时表、本 tag 与 409 `conflict.session_id_retired` 一并退。",
     },
     "server.approvals.queue-row-gate-kind-missing": {
         cls: "F",
@@ -207,7 +207,7 @@ export const FAIL_OPEN_TAGS = {
     },
     "server.sql-json.checkpoint.pending-steer-queue-lossy": {
         cls: "F",
-        note: "S-550(`stores-sql/checkpoint-store-sql.ts` 的 `get()`,core 5.14.0 #147 的耐久转向队列):一条挂起 run 的 `checkpoint.pending_steer_queue` 这一格**没能完整读出来**(不是合法 JSON 文本 / 不是数组 / 某一条目的四个必备键不合形)⇒ 读不出的那部分**丢掉**,run 照常 resume。放行的最坏后果 = 一条已经 park 的操作员转向指令**没有**在这次 resume 上注入(人以为说过的话没送到);不放行的代价是这条挂起的 run **永远不可 resume** —— resume 是它唯一的出路,为一格读不出的转向把整条 run 变成砖是错误的失败方向(写侧刻意相反:`setPendingSteer` 往一份读不全的队列上追加会把读不出的条目永久抹掉,那里 fail-loud)。故 F 类。留痕从一条 `logger.info` 升成登记 tag 的理由:日志行在**遥测轴**上是零信号,「这台机器的转向队列一直读不出来」与「这台机器本来就没人 steer」在指标上完全同形。计数非零 = 去按日志里的 token 指纹查那一行。",
+        note: "S-550(`stores-sql/checkpoint-store-sql.ts` 的 `get()`,core 5.14.0 #147 的耐久转向队列):一条挂起 run 的 `checkpoint.pending_steer_queue` 这一格**没能完整读出来**(不是合法 JSON 文本 / 不是数组 / 某一条目缺店铸键 `seq` / `inputId`,或过不了 core 的 `validatePendingSteer`——含领先一版的写者留下的、带冻结表外键的条目:判官拒,不再静默丢掉那一键后照常注入)⇒ 读不出的那部分**丢掉**,run 照常 resume。放行的最坏后果 = 一条已经 park 的操作员转向指令**没有**在这次 resume 上注入(人以为说过的话没送到);不放行的代价是这条挂起的 run **永远不可 resume** —— resume 是它唯一的出路,为一格读不出的转向把整条 run 变成砖是错误的失败方向(写侧刻意相反:`setPendingSteer` 往一份读不全的队列上追加会把读不出的条目永久抹掉,那里 fail-loud)。故 F 类。留痕从一条 `logger.info` 升成登记 tag 的理由:日志行在**遥测轴**上是零信号,「这台机器的转向队列一直读不出来」与「这台机器本来就没人 steer」在指标上完全同形。计数非零 = 去按日志里的 token 指纹查那一行。",
     },
     "server.sql-json.checkpoint.outcome-unreadable": {
         cls: "F",
@@ -277,6 +277,10 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "#310(codex 对抗复审 R1-[medium],验真后修):三条 run 腿把一条白名单通告写进 durable 账本时,那次 `appendEvent` **异步 reject**(store 抖动 / 连接断 / 行冲突)。结构上不能 await —— `onNotice` 是 core 的同步回调,拿一次账本写去阻塞引擎是更坏的交易 —— 所以写口只能 fire-and-forget,`route` 的同步 try 结构性观察不到这次失败 —— 「投出去了」与「真落盘了」不是同一件事。放行的最坏后果按腿分档,如实登记:**sync stream 腿**还有 live SSE 那一份(在线的人看得见,丢的是断连补看;写失败时 live 可以多于账本 —— 用户看见了、回放里没有,本 tag 计一次);**bg / resume 两腿账本是唯一的用户可见终点** ⇒ 那条通告对用户永久消失。仍判 F 而不是 P:通告是**披露**面不是执法面(不参与任何门/裁决),且运维面那一份(结构化日志 `engine_notice`)在分流之前就已经落定、一条不丢。此前是裸 `.catch(() => undefined)` —— 同文件 resume 腿的子代 forward 写口早在 C2/C5 批2 就因为「裸吞 = 事件从 durable log 永久消失且零信号」补过 `warnAppend`,本 tag 是同一条纪律在通告口的落实(warn 留细节 + 计数让「系统性在漏」显形)。不做重试队列是刻意的:账本里没有任何一族行做有界重试,单给通告开一条会造出第二套持久化语义。",
     },
+    "server.memory.store-form-refused-step-skipped": {
+        cls: "F",
+        note: "`memory-incident-sink.ts` 的 `createMemoryEngineIncidentSink`(两只宿主 `onError` 的 `memory` 相共用的落点):记忆相上到达店形拒族(`STORE_FORM_REFUSAL_CODES`,按族读;引擎 7.65.0 起含控制面所在文件系统不能建硬链接的 `memory.control_plane_links_unsupported`)的码 ⇒ 引擎的一步记忆活被店拒、会话照跑:mount 时开店被拒 ⇒ 这一跑记忆面读作 `memoryless`(`mount-failed`);mount 之后的整理 / 收割撞上 ⇒ 那一步没做(席只认码与相,不分哪一步 —— 是哪一步看同一行 `memory_engine_incident` 的句子)。放行的最坏后果 = 这一跑没有记忆或少做一步记忆活(不召回、不采集、不收割、不整理)—— 少做,不是错做:不开门、不放宽任何判据,模型读不到的是记忆不是别的;不放行的代价是记忆盘一个挂载面的形不对就让每一跑都失败。留痕是因为「这台部署的记忆从来没挂上」与「会话里本来没东西可记」在外部同形:逐次计数 + 探针 + 每进程一次 warn,detail `code=<店形拒码>`(运维行 `memory_engine_incident` 另带码与经出口座的句子);出路 = 把记忆控制面放到支持硬链接的卷上(或按码修挂载形)后重启。",
+    },
     "server.memory.locked-layer-probe-partial": {
         cls: "F",
         note: "O2(7.101.0 合并复审,`memory-layer-legacy-lock.ts announceLockedLegacyMemoryLayers`,boot 期锁住记忆层探测;detail 只报 `unreadable=<条数>`):挂载面或某个层里的目录**读不出**(EACCES 之类 —— 不是 ≤7.30.x 引擎的锁形,那种 0555 目录可读)⇒ 那棵子树看不全,照常起服。放行的最坏后果 = 一个锁住的层在 boot 日志里没被点名 —— 探测是**披露**面,不参与任何门 / 裁决;core 在真正失败的那一次删除上仍给出自己的 `chmod -R u+w` 补救句。不放行的代价严重不对称:为一条 warn 打死起服(混跑窗里能服务的副本)。计数让「这台部署的记忆树有读不出的目录」显形。",
@@ -287,7 +291,7 @@ export const FAIL_OPEN_TAGS = {
     },
     "server.session-workspace.record-degraded": {
         cls: "F",
-        note: "会话行的位置与项目那一格(`session_meta.workspace` / local `session-workspaces.json`;唯一写者 `session-workspace.ts` 的腿记录座,唯一列属主 `plugins/session-workspace-cell.ts`;detail 的 `op` 点名哪一步):`op=write` 一次写失败(库抖 / 盘满 / 锁等待超时)⇒ 行停在上一帧,下一帧照写;`op=read` 一格读不出(被带外改坏)⇒ 读作没有记录,下一帧整格重写;`op=frame` 一帧投不成存储形(引擎不会铸出这种帧)⇒ 这一帧不记。这一格是宿主对**引擎判过的答案**的记录,不是判据 —— 引擎每条腿都重判项目(有记号就判记号,声明不等响亮拒)。放行的最坏后果 = 这只会话的下一条不带 `projectId` 的提交续声明的是旧的项目或不声明(没有记号的检出里这只会话少一次续声明);不放行的代价是把一条在跑的腿、或这只会话往后的每一次提交,为一份记录摔掉。计数非零 = 这台部署的会话店写不动 / 有人改过库。",
+        note: "会话行的位置与项目那一格(`session_ext.workspace` / local `session-workspaces.json`;唯一写者 `session-workspace.ts` 的腿记录座,唯一列属主 `plugins/session-workspace-cell.ts`;detail 的 `op` 点名哪一步):`op=write` 一次写失败(库抖 / 盘满 / 锁等待超时)⇒ 行停在上一帧,下一帧照写;`op=read` 一格读不出(被带外改坏)⇒ 读作没有记录,下一帧整格重写;`op=frame` 一帧投不成存储形(引擎不会铸出这种帧)⇒ 这一帧不记。这一格是宿主对**引擎判过的答案**的记录,不是判据 —— 引擎每条腿都重判项目(有记号就判记号,声明不等响亮拒)。放行的最坏后果 = 这只会话的下一条不带 `projectId` 的提交续声明的是旧的项目或不声明(没有记号的检出里这只会话少一次续声明);不放行的代价是把一条在跑的腿、或这只会话往后的每一次提交,为一份记录摔掉。计数非零 = 这台部署的会话店写不动 / 有人改过库。",
     },
     "server.local-session-row.created-at-absent": {
         cls: "F",
@@ -305,10 +309,6 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "S-995(`hooks/hook-runner.ts` 的 `hooksMatcherIssue`,fresh 受理面「工具事件 matcher 选中别名而选不中正名 ⇒ 400」判据的**未判**臂;detail = `event=… reason=… matcherChars=…`,不带 matcher 原字节):一只 matcher 没能被判 ⇒ 照旧受理。判据一条顺序、两档共用(7.114.0 修复轮):长度上限 → 形只问契约包的 `hookMatcherForm`(literal 形〔名字表 / 空 / `*`〕两档都直接问 `hookMatcherSelects`、不占预算;regex 形 regex 档把同一只契约函数交进 vm 带每次求值各一份的固定预算〔超时 = 灾难回溯 ⇒ 确定的 400 拒,不是未判、不登记;一次受理里所有已完成求值的耗时之和超过受理总额度同样是确定的 400 拒〕、literal 档不适用;invalid 形 regex 档 = 确定的 400 拒〔S-1455 收尾:不是未判、不登记;运行期另记 `hook_matcher_invalid`;形判对所有契约事件同一判,不止工具事件〕、literal 档不适用)。现在只有一种 reason —— `oversize`(两档:超 8 192 字符不读;多租户车道上 hooks 不装配,这一笔只为让超长输入显形)。`invalid_regex` 臂自 S-1455 收尾(7.126.0)起退役:它是确定性的坏配置、不是「判不了」,与超预算同类 ⇒ 受理当场 400。**不记**的:literal 档(多租户车道)遇正则形 = 不适用 —— 该车道 hooks 整只不装配,没有被守的对象,不是未判。放行的最坏后果 = **那一只 matcher 没被这条判据守住**:它若真写了别名,照旧永不命中(7.112.0 对正则形一律不判,同一后果);**不是安全闸**(受理面的有效性判 = S-924 的「响亮」,决定不了任何放行 / 拒绝 / 权限;hook 的 deny 语义在运行期 hook-runner)。拒放集合相对 7.113.0 的一处放宽:超过上限的字面别名 matcher 7.113.0 拒、7.114.0 两档未判受理(已披露)。计数让「受理面一直判不了」(超长 matcher)显形。",
     },
-    "server.hooks.resume-reader-refused": {
-        cls: "P-DEBT",
-        note: "续跑重放(`task-settings.ts` 的 `parseTaskSettings`,经 `boot/resolve-spec.ts` 装配)读存下的请求体里的 `settings.hooks`,而 hooks 配置的唯一读者(契约包分类器,`hooks/hook-runner.ts` 的 `parseHooksConfig`)判不过、也没被一次性迁移 M20 接住(窗已关,或拒因不属 M20 的两形 —— 藏着守卫迹象的未知字段 / JSON `__proto__` 事件键)⇒ 这份 hooks **整只不采纳**(`task_settings_deferred` 记账),任务照常续跑 —— 其中若有真在拦的 `PreToolUse` 钩子,续跑后不再拦。M20 窗开着时那两形不进这一臂(剥键重读、守卫照跑,一行 `hooks_read_as_before_upgrade`)。只在 hooks 会被采纳的单用户车道计数(多租户整只忽略 hooks,无物可丢);fresh 提交不进这一臂(受理面 400)。放行的最坏后果:升级前停驻、体里 hooks 带那两形之一的任务,在窗关之后才续跑的(发布后才升级的部署、调长了 `APPROVAL_TERMINAL_BACKSTOP_MS` 的部署、滚动升级里旧副本在窗内新写的行),或体里 hooks 带别的坏形的,失去这份 hooks 里原本真在拦的钩子。方向已裁:持久数据面走 M20 窗内迁移,窗关后整份不采纳 + 本计数(存量停驻行此时已被收割,计数应趋零)。detail = `leg=`。计数非零 = 有任务带着被读者拒掉的存量 hooks 在续跑。",
-    },
     "server.hooks.notice-sink-threw": {
         cls: "F",
         note: "#281:hook 观测回调(`onHookNotice`,部署把它接到 fleet 流)自己抛了。放行的最坏后果 = **这一条观测帧**缺席;补偿是结构性的:①日志终点在投递之前就已逐字落定(`hook_command_failed` / `hook_command_timeout` / `hook_command_spawn_failed` 一族),运维面零回退;②观测帧不参与任何门/裁决(纯 observe,#281 全族判据里「裁决面一个字节不动」是承重条款),故 F 类。不放行的代价严重不对称:异常会掀回 core 的 hook 回调栈,把一次**观察动作**变成一次**工具调用失败** —— 「观察一件事的动作反过来改变了那件事」正是本 tag 要根除的形,而它伤的恰恰是 hook 已经坏掉、用户最需要任务照跑的那一刻。留痕承重:静默吞掉之后「这台机器为什么一条 hook 通知都没有」在遥测里与「hook 从来没坏过」同形。",
@@ -425,6 +425,10 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "S-322(`approval-ask-audit-store.ts` `rotateOlderThan`,审批账本留存律的审计账半场):轮转把留下的行原字节写进暂存文件(core `writeThenLink`:数据已 fsync)并 `rename` 盖上之后,目录 fsync 失败。换文件**已经落定且可见**、内存索引与 `crashConverged` 读面已经跟上,所以不回滚(也回滚不了)、读数照交。放行的最坏后果:掉电后目录项可能还指旧账本 ⇒ 删掉的行回来(下一拍再删,无害),轮转之后追加、在下一次目录落盘之前掉电的行可能丢(与 `append-failed` 同类后果:痕迹缺几条,审批结算不受影响)。与 core 原子写对目录 fsync 的尽力而为同一姿态(core 吞掉),这里改为留痕。审计店不开门、不改任何审批结算 ⇒ F。",
     },
+    "server.atomic-write.dir-fsync-failed": {
+        cls: "F",
+        note: "`plugins/owner-only-file-mode.ts` 本仓原子写的两个出口,**只在调用方声明 `durability: \"best-effort\"` 时**(同步 `atomicWriteFileSync`:完成收件箱账本的压实 `orchestration/workflow-completion-inbox.ts`、续租被拒的粘性位 `fleet/serving-lease.ts`;异步 `atomicWriteFileAsync`:附件店、会话边档、记忆同步游标、LKG、技能正文盘缓存;声明 `required` 的调用方 —— local 数据根的引擎版本高水位 marker —— 目录 fsync 失败即抛,不走本 tag):tmp 已 fsync、`rename` 已盖上之后,目录 fsync 失败(打不开目录 / 文件系统不支持对目录 fsync / EIO)。换文件**已经落定且可见**,不回滚(也回滚不了)、不抛(抛 = 把一次已生效的写报成失败:压实在起服构造里跑 ⇒ 拒启;异步写口的调用方会把已落下的附件 / 游标报成写失败)。放行的最坏后果:掉电后目录项可能还指旧文件或缺席 —— 收件箱账本回到压实前那一本(内容是压实前的超集,重放结果相同),压实之后追加到新账本、在下一次目录落盘之前掉电的行可能丢(已投进箱的通告少几条,不放行任何东西);粘性位回到上一份或缺席(重启后到第一次续租答复之前接单 —— 与 `server.fleet.denied-marker-unpersisted` 同一窗);附件 / 边档 / 游标 / LKG / 盘缓存回到上一份或缺席(与这些写口修前不 fsync 的常态同一后果:游标重同步、盘缓存重取、LKG 缺席走冷启动)。与 core `atomicWriteFile` 对目录 fsync 的尽力而为同一姿态(core 吞掉),这里改为留痕;core 的原子写改成独占新建 tmp 之后,同步的两处调用方改回 core(同步出口退役),本座留给异步出口。不开门、不改任何判据 ⇒ F。",
+    },
     "server.approval-ask-audit.corrupt-record-skipped": {
         cls: "F",
         note: "S-967(`approval-ask-audit-store.ts`,local 车道 File ask 审计店的 boot 重放;登记名 `approval-ask-audit`):账本**中间**一行读不出形(`42` / 数组 / 缺键 / 词表外 `kind`·`outcome`·`orphanState` / 半截 JSON;撕尾不走本 tag)⇒ 跳过它继续。最坏后果按行种:丢 `ask` ⇒ 那只孤儿在崩溃收敛读面缺席(无身份可列);丢 `settle` ⇒ 该组按 pending 臂收(审批门在执行之前 ⇒ 若这条 settle 其实是 `allowed` 且工具已执行,`resumeSafe:true` 是错的 —— 与头注「双故障窗」同族);丢 `leg_closed` ⇒ decided 臂多收一行(保守方向);丢 `crash_converged` ⇒ 下一次 boot 重收(幂等);丢 `interrupted_by_shutdown` / `late_settle` ⇒ 成因注退回 `crashed_before_park` / 少一行取证。审计店不开门、不改任何审批结算 ⇒ F。修前:重放坏行只计入 `convergeCrashedAsks().corruptLines`(boot 日志一个数),**无逐条披露、无 tag**。",
@@ -441,6 +445,10 @@ export const FAIL_OPEN_TAGS = {
         cls: "F",
         note: "S-978(`orchestration/workflow-completion-inbox.ts`,local 车道 File 完成信箱的 boot 重放;登记名 `workflow-completion-inbox`):账本**中间**一行读不出形(`42` / `null` / 数组 / 缺 `op` 或 `op` 词表外 / `enqueue` 缺 `entry.sessionId`·`entry.runId` / `ack` 缺 `sessionId`·`runId` / `drain` 缺 `sessionId` / 半截 JSON;撕尾不走本 tag)⇒ 跳过它继续。最坏后果按行种:丢 `enqueue` ⇒ 那条完成推送不进信箱(`WorkflowStatus` 轮询地板照旧兜住);丢 `ack` ⇒ 一条已送达的完成在重启后再投一次(壳按 runId 去重,至少一次的既有语义);丢 `drain`(会话清除墓碑)⇒ 被删会话里尚未送达的条目复活 —— 出帧前仍过 owner 二道闸(`emitPendingWorkflowCompletions`:条目盖的 owner 与本次调用方不符 ⇒ ack 丢弃、不出帧),同属主重领同一 sessionId 只会多收一条按 runId 去重的推送。信箱不开门、不改任何 run 的执行或授权 ⇒ F。修前:解析失败 `continue`(静默),而解析成功的 `null` 行在读 `rec.op` 时抛 TypeError ⇒ `new FileWorkflowCompletionInbox` 抛(构造点无 catch ⇒ 这一面起不来),其余非对象 / 缺键形静默忽略。boot 压实随后从内存活集重写账本 ⇒ 坏行的字节压实后不留盘,披露是它唯一的记录。",
     },
+    "server.workflow-completion-inbox.payload-over-budget": {
+        cls: "F",
+        note: "停驻收件条目编码座(`orchestration/workflow-completion-inbox.ts` 的 `encodeInboxBody`,两个家族的写口都只经它):条目 `payload` 的最终 JSON 按 UTF-8 字节超出预算(= 最窄后端的 `payload` 列容量,`plugins/inbox-payload-column.ts`;MySQL 协议 `TEXT` 65,535 字节)⇒ 入店的是**最小形**:帧的流侧去重键字段(`task_type` / `task_id` / `status` / `seq` / `attempt` 里全形带着的那几位)+ 归因侧记 `_sema_provenance`(在场且装得下即留)+ `payloadTruncated { droppedKeys, bytes }`,其余成员整只丢并在带内点名;连侧记也装不下(病态 `task_id` / 侧记成员)⇒ 侧记也丢,此时全形若带归因成员,`summary` 列换成本服务铸的受信句、`droppedKeys` 末尾记 `summary`(对端写的摘要不脱离归因单独出帧)。**不是放宽**:这条臂保的是投递 —— 修前越列宽的条目在 MySQL 协议后端上 INSERT 整条失败(通知丢,只剩一行日志),PG / File 照存,两副结局;现在三店收同一份判过的字节。丢的是一只照样送达的展示帧里的内容成员(`result` / `lines` / `editedFiles` / 侧记 / 载体 …),不开门、不改任何判据或授权;整类丢而不是按大小挑着丢,归因随文本走:摘要只在归因还在时原样出帧。最坏后果 = 收件人这一帧看到的细节少了(`status` 在列里照到,`payloadTruncated` 点名丢了什么;最坏连摘要原句也换成受信句)⇒ F。detail = `sessionId=… key=<收件键> bytes=<全形字节> budget=<预算> dropped=<键名>`。计数持续非零 = 有停驻通知的扩展成员常年越过列宽(看是哪类成员,考虑在产生方收紧逐成员界)。",
+    },
     "server.user-input-ledger.append-failed": {
         cls: "F",
         note: "S-928(`src/user-input-ledger.ts`):200 承诺**之后**的一次账本写失败 —— detail 的 `op=` 点名是哪一种:`settle`(腿在本进程收场)/ `withdraw`(引擎没收下这次 steer)/ `converge`(收敛器判孤儿)/ `announce`(通告已投出,记「告知过」)。放行的最坏后果逐个说清:settle / withdraw 漏写 ⇒ 这次受理在账上仍是 open —— 本进程下一次收敛扫描补结清(本进程写的、已不在活腿上 ⇒ leg_over);进程在那之前就崩了 ⇒ 下一次 boot 的收敛读 run 店判(S-969 L8 起两车道同一只判词:承载它的 run 正常翻面 / 已 park ⇒ leg_over 补结清、不告知;落款死亡判决或写者已死仍 running ⇒ crashed)—— 仍会多说一句的只剩两形:withdraw 漏写后那条腿崩了(一次没变成 200 的受理被告知一次);settle 漏写后本进程续跑了同一条 run、续跑腿崩了(run 行说的是同一 taskId 上**最新**那条腿)。方向都是多说,不漏;converge 漏写 ⇒ 留在 open,下一次扫描再判(延迟,不丢);announce 漏写 ⇒ 下一条 run 再说一遍(至多一次退化成至少一次)。都是**告知面**的偏差,不开任何门、不改任何 run 的执行 ⇒ F。计数非零 = 这台机器的账本写不动了(local:数据根盘满 / 只读;SQL:库不可达),steer 此刻多半也在回 503。",
@@ -561,7 +569,7 @@ export const FAIL_OPEN_TAGS = {
     },
     "server.remote-write.staging-dir-left": {
         cls: "F",
-        note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备 / 提交脚本删一只私有暂存目录(`.<名>.stage-<十六进制>/`,生来 0700;只删这次写放进去的 `data` 与这只空目录,从不递归删)没删掉、在 stdout 写一条记录点名 —— 五处:`mv` 已把暂存件换到目标上之后删当前那只;跟一跳到别的目录重新暂存成功之后删原来那只;重新暂存却没用上(收紧不成 / 拷不成)的那一只;就地拷入 / 追加时删暂存名失败、或写完关掉 fd 后删私有目录失败(有的文件系统为仍打开着的文件留隐藏项:NFS / libfuse / SMB);准备时收不成私有 / 里面已有 `data` 的那一只。目录里多出了不是这次写放进去的东西(同一身份或 root 的别的进程往里写过 / 收紧之前别人放进来的)、目录被换成了符号链接、或文件系统拒删。写照它自己的结局答(提交已成 ⇒ 成功:答失败会让调用方以为目标没变),残留只在这里留痕。放行的最坏后果 = 目标(或链接所指)目录里多一只隐藏目录(空的,或装着别人放进去的东西;重新暂存没用上的那只可能装着这次写的半份新内容),只有写入方进得去;不是门、不是凭据、不碰目标内容。计数非零 = 那台目标机上有东西在往别人的暂存目录里写,或删不动,去看那只目录。detail = 残留目录的路径(一次写最多两只,逐只计)。",
+        note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备 / 提交脚本删一只私有暂存目录(`.<名>.stage-<十六进制>/`,生来 0700;只删这次写放进去的 `data` 与这只空目录,从不递归删)没删掉、在 stdout 写一条记录点名 —— 五处:`mv` 已把暂存件换到目标上之后删当前那只;跟一跳到别的目录重新暂存成功之后删原来那只;重新暂存却没用上(收紧不成 / 拷不成)的那一只;就地拷入 / 追加时删暂存名失败、或写完关掉 fd 后删私有目录失败(有的文件系统为仍打开着的文件留隐藏项:NFS / libfuse / SMB);准备时收不成私有 / 里面已有 `data` 的那一只。目录里多出了不是这次写放进去的东西(同一身份或 root 的别的进程往里写过 / 收紧之前别人放进来的)、目录被换成了符号链接、或文件系统拒删。编排对脚本点名的每一只(按路径去重)再补清一次 —— 只 `rmdir`、不删里面的东西,且只对名字是本次暂存名、路径经 UTF-8 解码仍可信(无 U+FFFD)的动手,别的原样不碰、照样算残留;原私有目录在写没成时另补清它的 `data` 与目录 —— **补清之后仍在的才计数**(异步释放的文件系统上隐藏项此时多半已删净),失败的写同时把它们点进错误句。写照它自己的结局答(提交已成 ⇒ 成功:答失败会让调用方以为目标没变),残留只在这里留痕。放行的最坏后果 = 目标(或链接所指)目录里多一只隐藏目录(空的,或装着别人放进去的东西;重新暂存没用上的那只可能装着这次写的半份新内容),只有写入方进得去;不是门、不是凭据、不碰目标内容。计数非零 = 那台目标机上有东西在往别人的暂存目录里写,或删不动,去看那只目录。detail = 残留目录的路径(一次写最多两只,逐只计一次)。",
     },
     "server.resume-anchor.capture-failed": {
         cls: "F",
@@ -569,7 +577,7 @@ export const FAIL_OPEN_TAGS = {
     },
     "server.remote-write.stage-seal-fallback": {
         cls: "F",
-        note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备脚本把刚建的私有暂存目录收成 0700 并读回核实(`chmod 700` 退出 0 ∧ `stat` 读回的模式低三位恰是 700 ∧ 属主 = 本身份),任一步不成 —— `chmod` 被文件系统 / 内核拒;退出 0 却没生效(不认权限位的文件系统);父目录带缺省 ACL 而掩码收不下来;目录上有继承来的 ACL 条目(macOS 原生 ACL / FreeBSD · illumos ZFS 的 NFSv4 ACL)去不掉或读不出,或目标机平台不在读 ACL 的适配器闭集里(`uname -s` 不是 Linux / Darwin / FreeBSD / SunOS);目标机上没有 `stat` —— 准备退出 4、这次写**不暂存**,两只文件面、五条腿一律改为直接写目标(与「目标目录不收新名字」同一条回落;能追加写的腿直接追加,e2b / adb 的追加 = 读旧 + 拼 + 整份写目标 —— adb 的这一形就是 7.138.x 的追加,push 没有追加写)。修前这一步是 `chmod 700 … || :`:加固失败照样放行上传,字节落在一只别的身份可能读得到的目录里(P 轴 fail-open),那一臂已删,字节从不进一只没核成私有的目录。放行的最坏后果 = 这一次写失去「整旧或整新」(非原子:中途断 / 取消 ⇒ 目标可能只写了一半,整份写目标的 e2b / adb 上可能没了或只剩半份;写目标那一步因取消中断答 `unknown`,那一步开始之前取消答 `aborted`、目标未碰,那一步不收取消(ssh 的 sftp)照样写完);ssh / local-docker / k8s 写进原 inode、权限位不变,e2b 的 `files.write` 与 adb 的 push 整份写目标、inode / 权限位由对端定(adbd 不保,与 7.138.x 同形);不是门、不是凭据。Android 共享存储(`/sdcard` 一类:权限位由挂载派生、不认 chmod)上 adb 的写按 sdcardfs / MediaProvider FUSE 的权限语义**推断**每一次都走这里(未上真机,真机读数候 test;结构性,运维修不掉;工作区放在 `/data/local/tmp` 一类认权限位的目录就不走)。计数非零 = 这台目标机的这个目录上私有目录收不成私有(文件系统不认权限位 / 缺省 ACL 掩码收不下来 / 继承来的 ACL 条目去不掉 / 平台不可知 / 缺 `stat`),写在走非原子的退路,去看那个目录。detail = `<目标路径>: <准备脚本写的原因句>`。",
+        note: "远端五条车道的写(`plugins/remote-shell.ts` 的暂存编排):准备脚本把刚建的私有暂存目录收成 0700 并读回核实(`chmod 700` 退出 0 ∧ `ls -ldn` 读回的模式串低三位恰是 700 ∧ 属主 = 本身份),任一步不成 —— `chmod` 被文件系统 / 内核拒;退出 0 却没生效(不认权限位的文件系统);父目录带缺省 ACL 而掩码收不下来;目录上有继承来的 ACL 条目(macOS 原生 ACL / FreeBSD · illumos ZFS 的 NFSv4 ACL)去不掉或读不出,或目标机平台不在读 ACL 的适配器闭集里(`uname -s` 不是 Linux / Darwin / FreeBSD / SunOS);目标机上读不出模式串(`ls` 不可用 / 输出读不懂)—— 准备退出 4(提交脚本里跟一跳链接到别的目录重新暂存的那只目录同判、同一个码:放弃它、目标未碰、编排清掉原暂存件)、这次写**不暂存**,两只文件面、五条腿一律改为直接写目标(与「目标目录不收新名字」同一条回落;能追加写的腿直接追加,e2b / adb 的追加 = 读旧 + 拼 + 整份写目标 —— adb 的这一形就是 7.138.x 的追加,push 没有追加写)。修前这一步是 `chmod 700 … || :`:加固失败照样放行上传,字节落在一只别的身份可能读得到的目录里(P 轴 fail-open),那一臂已删,字节从不进一只没核成私有的目录。放行的最坏后果 = 这一次写失去「整旧或整新」(非原子:中途断 / 取消 ⇒ 目标可能只写了一半,整份写目标的 e2b / adb 上可能没了或只剩半份;取消只看落在哪一段:备件阶段〔第一个字节发往目标机之前:adb 在本机落临时件、ssh 开 sftp 通道含懒重连、k8s 建连、追加退路的读旧 + 拼〕答 `aborted`、目标未碰;传输那一步因取消中断答 `unknown`;那一步不收取消(ssh 的 sftp)照样写完);ssh / local-docker / k8s 写进原 inode、权限位不变,e2b 的 `files.write` 与 adb 的 push 整份写目标、inode / 权限位由对端定(adbd 不保,与 7.138.x 同形);不是门、不是凭据。Android 共享存储(`/sdcard` 一类:权限位由挂载派生、不认 chmod)上 adb 的写按 sdcardfs / MediaProvider FUSE 的权限语义**推断**每一次都走这里(未上真机,真机读数候 test;结构性,运维修不掉;工作区放在 `/data/local/tmp` 一类认权限位的目录就不走)。计数非零 = 这台目标机的这个目录上私有目录收不成私有(文件系统不认权限位 / 缺省 ACL 掩码收不下来 / 继承来的 ACL 条目去不掉 / 平台不可知 / 缺 `stat`),写在走非原子的退路,去看那个目录。detail = `<目标路径>: <准备脚本(或提交脚本重新暂存那一臂)写的原因句>`。",
     },
     "server.park.held-card-void-failed": {
         cls: "F",

package/dist/observability/metrics.d.ts

@@ -1,4 +1,6 @@
 export type Labels = Record<string, string>;
+/** 认领时延直方图的名字(注册在 {@link createMetrics};计时口径与 `step` 闭集的属主是 `http/claim-latency.ts`,它引这个常量 —— 名字只此一处)。 */
+export declare const EXECUTION_CLAIM_METRIC = "execution_claim_duration_seconds";
 export declare class Metrics {
     private counters;
     private gauges;

package/dist/observability/metrics.js

@@ -2,6 +2,7 @@ import { DENIED_BY_VALUES } from "@sema-agent/core";
 import { buildPermissionRuleEventsHelp } from "./permission-rule-events.js";
 import { MCP_PROBE_OUTCOMES } from "../capabilities/mcp-probe.js";
 const DEFAULT_BUCKETS = [0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10, 30, 60];
+export const EXECUTION_CLAIM_METRIC = "execution_claim_duration_seconds";
 function labelKey(labels) {
     return Object.keys(labels)
         .sort()
@@ -304,6 +305,7 @@ export function createMetrics() {
     m.counter("sandbox_pods_reaped_total", "Sandbox pods deleted by the k8s lane's pod reaper, by reason (containers_ended: every container finished; run_ended_past_hold: the pod's run ended longer ago than the hold)");
     m.counter("task_outcomes_total", "Task outcome-ledger rows recorded, by status and oracle green flag");
     m.counter("workflow_runs_total", "Self-orchestration workflow runs, by status");
+    m.histogram(EXECUTION_CLAIM_METRIC, "Execution-claim round-trip latency by step (run_claim: RunStore.createRun incl. the SQL root-session row lock; placement_commit: the one post-claim execution-placement write)", [0.001, 0.005, 0.02, 0.1, 0.5, 2, 10]);
     m.histogram("auth_bridge_verify_seconds", "Registry SSO JWT verify latency (hot path sub-ms; cold path includes a JWKS fetch)", [0.001, 0.005, 0.02, 0.1, 0.5, 2, 10]);
     return m;
 }

package/dist/observability/secret-env-scrub.d.ts

@@ -17,6 +17,12 @@
  *     有部署级出路的现场([ref]:`server.lsp.spawn-env`;7.103.0 起 + `server.bake-runner.spawn-env`)升 `warn`,并带当前放行名单与出路句
  *     —— 规则见 `SecretEnvScrubSiteSpec`。
  *     不是「每 site 一次」:一个**新**的密钥形 key 后来才出现(部署加了一个凭证)时,那才是最该看见的一行。
+ *     🔴 **名字只有一个读者**:披露行回答「这条腿扣了哪些名字」。引擎自己读执行环境的那条腿(模型可驱动的 host shell:引擎每个会话读执行环境的必填答
+ *     `ExecutionEnv.withheldEnv`、铸 `inherit_env.names_withheld`,本仓的通告转发体把它落成结构化 `engine_notice` 行并上会话流)已经在说同一批名字 ⇒ 那一格登记
+ *     `told:"engine-notice"`:本座只记计数(`secret_env_scrubbed_total`,不带名字 —— 每条规则扣了几次是另一个事实),不写披露行。引擎没有读者的腿
+ *     (git / 语言服务器 / bake-runner / hooks / docker / adb,以及 host 适配器类里本服务自己的 git worktree 基环境 —— 它从不交给引擎)本服务是唯一的读者,登记
+ *     `told:"log"`,披露行照旧。哪一格是哪一种不手抄:车道适配器里 `get withheldEnv()` 有真读者的那几只 = `told:"engine-notice"` 的那几格
+ *     (`test/withheld-names-one-reading.test.ts` 闭集互推);同一个类里不交给引擎的那条腿另立现场(按腿命名,不按类)。
  *  findings 全部是 core 的 `SecretEnvFinding`(7.129.0 / core 7.51.1 起只有引擎一只写手,经 `server-secret-env.ts` 的唯一组合):形状臂的五词
  *  `exact-name` / `prefix-rule`(`OTEL_*`)/ `namespace-rule`(`SEMA_` 命名空间)/ `name-rule`(名字形状)/ `value-rule`(值里带凭据),加
  *  `own-credential`(本进程起服声明的自有凭据名 —— 配置目录 secret 名 ∪ 名单型旋钮名 —— 被形状臂漏下、由声明臂扣的;`all` 词下也扣)。
@@ -46,49 +52,69 @@ import type { Metrics } from "./metrics.js";
  * 一个剥除现场的登记:`note` = 这条腿上泄漏意味着什么;`remedy` = 部署方能不能自己把某个被剥的键放回来。
  *
  * 🔴 [ref]:`remedy` 在场与否决定披露行的**级别**,规则一句 —— **有出路的现场用 warn,并把出路句与当前放行名单写进同一行**;
- * 没有出路的现场是纯保护留痕,照旧 info。理由:没有出路的剥除(模型可驱动的 shell、git 钩子)是本服务替部署方做的决定,
+ * 没有出路的现场是纯保护留痕,照旧 info。理由:没有出路的剥除(git 钩子、CLI 腿)是本服务替部署方做的决定,
  * 读者只需要知道它生效了;有出路的剥除(语言服务器)可能让一件功能静默变差(补全 / 诊断缺了私有 registry 的依赖),
  * 那是部署方要自己决定的事 —— 看不见 = 无从归因。出路句不带任何值。
+ *
+ * `told` 说**谁把这条腿扣下的名字告诉人**(一个事实一个读者,见文件头):`"log"` = 本座的披露行(有 `note`);`"engine-notice"` = 引擎读这条腿的执行环境并铸
+ * `inherit_env.names_withheld`,本座不再写第二遍名字(无披露行 ⇒ 无 `note`、无出路句;计数照记)。
  */
-export interface SecretEnvScrubSiteSpec {
+export type SecretEnvScrubSiteSpec = {
+    readonly told: "log";
     readonly note: string;
     readonly remedy: string | null;
-}
+} | {
+    readonly told: "engine-notice";
+    readonly remedy: null;
+};
 /** 登记过的剥除现场。闭集:未登记的 site 传不进 {@link recordSecretEnvScrub}(编译期拒,同 FAIL_OPEN_TAGS 纪律)。 */
 export declare const SECRET_ENV_SCRUB_SITES: {
     readonly "server.remote-env-host.spawn-env": {
-        readonly note: "模型可驱动的 host shell 继承 env(`inheritEnv` 三词任一,缺省 `\"scrub\"`;`\"all\"` 词下扣的只有本服务自己的凭据名)——这条腿上的一次泄漏等于把编排器的脑钥/仓库令牌交给模型选的命令";
+        readonly told: "engine-notice";
+        readonly remedy: null;
+    };
+    readonly "server.remote-env-host.git-base": {
+        readonly told: "log";
+        readonly note: "本服务自己的 git worktree 基环境(host 车道 worktree 隔离:`git worktree add / remove / prune`)交给 git 与它拉起的 hook / credential helper 的 env —— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据交给仓里的 hook";
         readonly remedy: null;
     };
     readonly "server.remote-env-local-docker.spawn-env": {
+        readonly told: "log";
         readonly note: "local-docker 车道交给宿主 `docker` CLI 的 env(它拉起的凭据助手 / CLI 插件同读)—— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据交给宿主上的第三方助手";
         readonly remedy: null;
     };
     readonly "server.remote-env-adb.spawn-env": {
+        readonly told: "log";
         readonly note: "adb 车道交给宿主 `adb` CLI 的 env(首次调用起的常驻 adb server 继承同一份并一直活着)—— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据留在一只常驻进程的环境里";
         readonly remedy: null;
     };
     readonly "server.hooks.spawn-env": {
+        readonly told: "log";
         readonly note: "settings hooks 的命令腿(请求带来的命令跑在宿主上)的 env —— 严格名单(`PATH` / `HOME` / 终端 / locale 等十二名)经引擎的 `hostChildEnv` 组合:名单外一律不交,本服务自有凭据任何情况都不交;请求的有效环境层(`settings.env`)作授予叠在上面;请求给工具 shell 的继承词对它不作用";
         readonly remedy: null;
     };
     readonly "server.project-memory.git-subprocess": {
+        readonly told: "log";
         readonly note: "project-memory 读仓叙事时的 git 子进程 env —— 仓内的钩子/凭证助手会以本进程身份运行";
         readonly remedy: null;
     };
     readonly "server.lsp.spawn-env": {
+        readonly told: "log";
         readonly note: "宿主车道本地语言服务器子进程 env(core 7.30.1 #1073 的 `NodeLspManagerOptions.env`)—— 语言服务器会执行仓里的代码(构建脚本/插件/工作区配置),一次泄漏等于把本进程的凭据交给仓";
         readonly remedy: `LSP_ENV_ALLOW=NAME,NAME \u70B9\u540D\u653E\u884C(\u539F\u6837\u4EA4\u7ED9\u8BED\u8A00\u670D\u52A1\u5668,\u90E8\u7F72\u65B9\u663E\u5F0F\u627F\u62C5;${string});\u503C\u4E0D\u8FDB\u65E5\u5FD7`;
     };
     readonly "server.center-plugins.git-clone": {
+        readonly told: "log";
         readonly note: "center 下发插件的 git clone / fetch 子进程 env —— 克隆的是 center 声明里的第三方仓,git 与它拉起的 transport / askpass 以本进程身份运行";
         readonly remedy: null;
     };
     readonly "server.leader.git-push": {
+        readonly told: "log";
         readonly note: "leader 控制面把集成结果推回 durable remote 的 git 子进程 env —— 这条腿保留宿主 git 配置(写凭据可能走宿主 credential helper),helper / hook 以本进程身份运行";
         readonly remedy: null;
     };
     readonly "server.bake-runner.spawn-env": {
+        readonly told: "log";
         readonly note: "bake-runner(构建宿主守护进程)交给 build.sh 与主机命令(git fetch / docker push / docker image inspect / df)的 env —— 配方脚本在构建宿主上以 runner 身份运行,一次泄漏等于把 runner 的 BAKE_RUNNER_TOKEN 交给配方";
         readonly remedy: "BAKE_ENV_ALLOW=NAME,NAME 点名放行(原样交给 build.sh 与主机命令,部署方显式承担;bake-runner 进程的旋钮,没有多租户姿态);值不进日志";
     };

package/dist/observability/secret-env-scrub.js

@@ -2,39 +2,49 @@ import { summarizeRedactions } from "@sema-agent/core";
 import { describeAllowlistPostures } from "../env-name-allowlist-knobs.js";
 import { createLogger } from "./logger.js";
 export const SECRET_ENV_SCRUB_SITES = {
-    "server.remote-env-host.spawn-env": {
-        note: "模型可驱动的 host shell 继承 env(`inheritEnv` 三词任一,缺省 `\"scrub\"`;`\"all\"` 词下扣的只有本服务自己的凭据名)——这条腿上的一次泄漏等于把编排器的脑钥/仓库令牌交给模型选的命令",
+    "server.remote-env-host.spawn-env": { told: "engine-notice", remedy: null },
+    "server.remote-env-host.git-base": {
+        told: "log",
+        note: "本服务自己的 git worktree 基环境(host 车道 worktree 隔离:`git worktree add / remove / prune`)交给 git 与它拉起的 hook / credential helper 的 env —— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据交给仓里的 hook",
         remedy: null,
     },
     "server.remote-env-local-docker.spawn-env": {
+        told: "log",
         note: "local-docker 车道交给宿主 `docker` CLI 的 env(它拉起的凭据助手 / CLI 插件同读)—— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据交给宿主上的第三方助手",
         remedy: null,
     },
     "server.remote-env-adb.spawn-env": {
+        told: "log",
         note: "adb 车道交给宿主 `adb` CLI 的 env(首次调用起的常驻 adb server 继承同一份并一直活着)—— 继承词 `\"all\"`,扣的只有本服务自己的凭据;一次泄漏等于把本服务凭据留在一只常驻进程的环境里",
         remedy: null,
     },
     "server.hooks.spawn-env": {
+        told: "log",
         note: "settings hooks 的命令腿(请求带来的命令跑在宿主上)的 env —— 严格名单(`PATH` / `HOME` / 终端 / locale 等十二名)经引擎的 `hostChildEnv` 组合:名单外一律不交,本服务自有凭据任何情况都不交;请求的有效环境层(`settings.env`)作授予叠在上面;请求给工具 shell 的继承词对它不作用",
         remedy: null,
     },
     "server.project-memory.git-subprocess": {
+        told: "log",
         note: "project-memory 读仓叙事时的 git 子进程 env —— 仓内的钩子/凭证助手会以本进程身份运行",
         remedy: null,
     },
     "server.lsp.spawn-env": {
+        told: "log",
         note: "宿主车道本地语言服务器子进程 env(core 7.30.1 #1073 的 `NodeLspManagerOptions.env`)—— 语言服务器会执行仓里的代码(构建脚本/插件/工作区配置),一次泄漏等于把本进程的凭据交给仓",
         remedy: `LSP_ENV_ALLOW=NAME,NAME 点名放行(原样交给语言服务器,部署方显式承担;${describeAllowlistPostures()});值不进日志`,
     },
     "server.center-plugins.git-clone": {
+        told: "log",
         note: "center 下发插件的 git clone / fetch 子进程 env —— 克隆的是 center 声明里的第三方仓,git 与它拉起的 transport / askpass 以本进程身份运行",
         remedy: null,
     },
     "server.leader.git-push": {
+        told: "log",
         note: "leader 控制面把集成结果推回 durable remote 的 git 子进程 env —— 这条腿保留宿主 git 配置(写凭据可能走宿主 credential helper),helper / hook 以本进程身份运行",
         remedy: null,
     },
     "server.bake-runner.spawn-env": {
+        told: "log",
         note: "bake-runner(构建宿主守护进程)交给 build.sh 与主机命令(git fetch / docker push / docker image inspect / df)的 env —— 配方脚本在构建宿主上以 runner 身份运行,一次泄漏等于把 runner 的 BAKE_RUNNER_TOKEN 交给配方",
         remedy: "BAKE_ENV_ALLOW=NAME,NAME 点名放行(原样交给 build.sh 与主机命令,部署方显式承担;bake-runner 进程的旋钮,没有多租户姿态);值不进日志",
     },
@@ -77,6 +87,9 @@ export function recordSecretEnvScrub(site, findings, allowed) {
             counts.set(k, (counts.get(k) ?? 0) + 1);
         }
         drainToMetrics();
+        const spec = SECRET_ENV_SCRUB_SITES[site];
+        if (spec.told === "engine-notice")
+            return;
         const logger = sink.logger;
         if (logger === undefined)
             return;
@@ -86,7 +99,6 @@ export function recordSecretEnvScrub(site, findings, allowed) {
         const fresh = findings.filter((f) => !disclosed.has(`${site}${SEP}${f.key}`)).slice(0, room);
         if (fresh.length === 0)
             return;
-        const spec = SECRET_ENV_SCRUB_SITES[site];
         const fields = {
             site,
             note: spec.note,

package/dist/orchestration/workflow-agent-session-index.d.ts

@@ -39,14 +39,14 @@ export type WorkflowRunParkKey = NonNullable<WorkflowRun["parks"]>[number];
  *  · 这一位**在场却不是数组** ⇒ 读不出(`undefined`):记录说了话、说的不是一份列表;
  *  · 每条四个身份位必须是非空串;`originUnconfirmed` 只认字面 `true`(core 从不写 `false`);
  *  · **持有者两成员同进同出**(core 7.44.0 逐字:both or neither):`parkedBy` 非空串、`generation` 非负安全整数;只有其一、或任一形坏
- *    ⇒ 坏条目。两者皆无 = 旧引擎写的条目(证不了持有者),照读;
+ *    ⇒ 坏条目。两者皆无 = 引擎 7.43 及以前写的条目(不持有任何东西),照读;
  *  · **任一条目形坏 ⇒ 整只读不出来**(整档成败制):core 对同一形整条拒 resume(`park_binding_broken`);「丢掉坏的、留下好的」会静默
  *    铸出一份**比真相少几条 park** 的集合,而这只读者的消费面正是 park 的路由与赎回。
  */
 export declare function readRunParks(run: unknown): WorkflowRunParkKey[] | undefined;
 /**
  * 🔴 **「这条记录的 run 持有这条停驻」的唯一读法**(core 7.44.0 [ref] 逐字):`entry.parkedBy === record.id`。
- * 继承来、本跑还没走到的条目带上一跑的 id;旧引擎写的条目两成员皆无 —— 两者都不是本记录持有的。
+ * 继承来、本跑还没走到的条目带上一跑的 id;引擎 7.43 及以前写的条目两成员皆无 —— 两者都不是本记录持有的。
  */
 export declare function heldParksOf(recordId: string, parks: readonly WorkflowRunParkKey[]): WorkflowRunParkKey[];
 /**
@@ -62,12 +62,11 @@ export declare function buildParkSessionRows(runId: string, run: {
  * 一次路由的判决(闭集):
  *  · `held`   —— 持有这个子会话的记录里最高代次**恰一条**:`park` = 它持有的那一条条目(赎回键在条目上);
  *  · `forked` —— 最高代次上不止一条记录(同一条 run 先后被续跑两次,两支都走到了这里):`runIds` 升序;
- *  · `unproven` —— 没有任何记录持有它,而这件事证不了:`unreadable` = 某一条候选记录的 `parks[]` 读不出(它可能就是持有者);
- *    `older_engine` = 点名它的条目没有持有者位(写于不带这两位的旧引擎);`runId` = 去续跑的那一条(`unreadable` 时是读不出的那条里 id 最小的);
- *    `readableHolderRunId` 只在 `unreadable` 上可能在场 —— **其余可读候选里**持有它的最高代次**恰一条**记录(规则 ②,与 `held` 同一只判);没有 / 并列 ⇒ 缺席。
+ *  · `unproven` —— 没有任何记录持有它,而这件事证不了:某一条候选记录的 `parks[]` 读不出(它可能就是持有者);`runId` = 读不出的那几条里 id 最小的;
+ *    `readableHolderRunId` —— **其余可读候选里**持有它的最高代次**恰一条**记录(规则 ②,与 `held` 同一只判);没有 / 并列 ⇒ 缺席。
  *    它不改判决(任一读不出 ⇒ 整卡拒不变),只让拒体多给一条线索:读不出的那条引擎往往恰拒续跑,而健康的持有者就在旁边(工作可从它续上;
  *    读不出的那条的指针仍在候选里,续跑它之后这张卡照旧整卡拒,直到那条记录被修好);
- *  · `none`   —— 没有任何记录持有它,且候选全部读得出、条目都带持有者位 ⇒ 诚实 miss。
+ *  · `none`   —— 候选全部读得出、没有任何记录持有它(含点名它的条目没有持有者位的存量记录 —— 引擎 7.43 及以前写下)⇒ 诚实 miss。
  */
 export type WorkflowParkRoute = {
     readonly kind: "held";
@@ -79,7 +78,6 @@ export type WorkflowParkRoute = {
     readonly runIds: readonly string[];
 } | {
     readonly kind: "unproven";
-    readonly cause: "unreadable" | "older_engine";
     readonly runId: string;
     readonly run: WorkflowRun;
     readonly readableHolderRunId?: string;
@@ -90,14 +88,11 @@ export type WorkflowParkRoute = {
  * 🔴 **路由与赎回的唯一判决**(纯函数;输入 = 点名这个子会话的每一条记录,读不到的记录 —— 已被收割 —— 由调用方先剔掉)。
  *
  * 一条规则,按序:
- *  ① 任一候选的 `parks[]` 读不出 ⇒ `unproven/unreadable`(它可能正是最高代次的持有者;宁可不投,绝不投错 —— 引擎对条目形坏的记录整条拒续跑);
+ *  ① 任一候选的 `parks[]` 读不出 ⇒ `unproven`(它可能正是最高代次的持有者;宁可不投,绝不投错 —— 引擎对条目形坏的记录整条拒续跑);
  *    其余可读候选按下一条判出的持有者(恰一条)带进 `readableHolderRunId`(只给出路,不改判决);
  *  ② 其余候选里,持有这个子会话({@link heldParksOf})的条目取最高 `generation`:恰一条记录 ⇒ `held`;多于一条 ⇒ `forked`;
- *  ③ 没有持有者:有条目两成员皆无(旧引擎写的)⇒ `unproven/older_engine`,`runId` = 这类记录里最晚建的那条(续跑它,新引擎走到这张停驻时
- *    写下自己的代次 0 行);否则 `none`。
+ *  ③ 没有持有者 ⇒ `none`(点名它的条目没有持有者位的存量记录同判:那种条目不持有任何东西)。
  * 判决不看写序、不看 `agents[]`、不看 `originRunId`(core:那一位说的是「材料在哪条 run 的 journal 里」,不是「谁站在上面」)。
- *
- * 🔴 **窗与删码**:规则 ③ 的 `older_engine` 读臂是一次性迁移 M9 的读侧半场(升级那一刻还停驻着的存量记录)。窗口与删码清单见 `plugins/one-time-migrations.ts` 登记表 M9 一行,随 M9 一起删;这里不写第二份窗。
  */
 export declare function routeWorkflowPark(sessionId: string, candidates: readonly WorkflowRun[]): WorkflowParkRoute;
 /** 账本一行的**内域形**:一条 run 当时的整份指针快照(`{runId, rows}`;同一条 run 后写的一行整份覆盖先写的 —— 本仓只增不删,所以后一行恒是前一行的超集)。 */

package/dist/orchestration/workflow-agent-session-index.js

@@ -57,17 +57,12 @@ export function routeWorkflowPark(sessionId, candidates) {
     const top = highestHolders(sessionId, readable);
     if (firstUnreadable !== undefined) {
         const holder = top.length === 1 ? top[0].run.id : undefined;
-        return { kind: "unproven", cause: "unreadable", runId: firstUnreadable.id, run: firstUnreadable, ...(holder !== undefined ? { readableHolderRunId: holder } : {}) };
+        return { kind: "unproven", runId: firstUnreadable.id, run: firstUnreadable, ...(holder !== undefined ? { readableHolderRunId: holder } : {}) };
     }
     if (top.length === 1)
         return { kind: "held", runId: top[0].run.id, run: top[0].run, park: top[0].park };
     if (top.length > 1)
         return { kind: "forked", runIds: top.map((t) => t.run.id) };
-    const older = readable.filter(({ parks }) => parks.some((p) => p.sessionId === sessionId && p.parkedBy === undefined));
-    if (older.length > 0) {
-        const latest = older.reduce((a, b) => (b.run.createdAt > a.run.createdAt || (b.run.createdAt === a.run.createdAt && b.run.id > a.run.id) ? b : a));
-        return { kind: "unproven", cause: "older_engine", runId: latest.run.id, run: latest.run };
-    }
     return { kind: "none" };
 }
 function highestHolders(sessionId, readable) {