@sema-agent/server 7.2.0 → 7.4.0

package/dist/tool-approval.js

@@ -43,6 +43,13 @@
 import { AsyncLocalStorage } from "node:async_hooks";
 import { uuidv7 } from "@sema-agent/core";
 import { redactDeep, redactSecrets } from "./trace/redact.js";
+import { createLogger } from "./observability/logger.js";
+import { deriveAskId, deriveBatchId } from "./approval-ask-machine.js";
+import { ApprovalCardEnvelopeSchema, buildApprovalCard, buildApprovalCardEnvelope, buildApprovalRequestFrame, buildRevokeFrame, } from "./approval-card.js";
+/** #151 车2:本模块自有的日志出口——同 config-provider.ts/runtime-caps-resolver.ts 先例(协调器不走
+ *  DI logger,构造签名是设计定稿钉死的三键 options bag,加第四个 logger 键属于重议已裁事项）。仅用于
+ *  D5 的一次性 store-故障 warn。 */
+const defaultLogger = createLogger();
 /** Size bound on the redacted args payload in a `tool_approval` frame (parity with question's MAX_QUESTIONS_BYTES).
  *  Over the cap ⇒ the frame still goes out WITHOUT args (`argsOmitted: true`) — unlike a question (undisplayable ⇒
  *  headless default is safe), an approval must still reach the human: toolName+message suffice to decide, and the
@@ -50,8 +57,45 @@ import { redactDeep, redactSecrets } from "./trace/redact.js";
 const MAX_APPROVAL_ARGS_BYTES = 16384;
 /** How long an unanswered approval waits before it DENIES (fail-closed — the human walked away; don't hold core). */
 const DEFAULT_APPROVAL_TTL_MS = 5 * 60_000;
+/** #151 车2(design/172 §3.3 D3):窗长三元公式里的安全余量默认值——`STREAM_ASK_WINDOW_MARGIN_MS` 缺省时
+ *  用这个(config.ts 的 numEnv fallback 字符串与本常量保持同值,便于对表)。 */
+const DEFAULT_WINDOW_MARGIN_MS = 10_000;
 /** Bound on the remembered allow-all grants (insertion-order evict — a long-lived worker must not grow unbounded). */
 const MAX_ALLOW_SESSIONS = 4096;
+/** #151 车3 刀 3b(设计稿 §0 X-2):写侧准入门两帽的**代码默认**——与 `config.ts` 的
+ *  `STREAM_APPROVAL_ADMIT_MAX_PER_TASK` / `_PER_OWNER` fallback 同值(便于对表)。装配点恒显式传,
+ *  这两个常量只服务「手搓协调器」的测试与防御性缺省。 */
+const DEFAULT_ADMIT_MAX_PER_TASK = 32;
+const DEFAULT_ADMIT_MAX_PER_OWNER = 256;
+/** #151 车5(X-1 状态感知分派):CAS 干净地输之后重读持久态的**有界**退避表(ms,一次退避一格)。
+ *  长度 = 重试次数上限(6 次,累计 ≈ 3.1s)。为什么必须有界:重读是为了「不挂死」,一个无界重试循环
+ *  只是把挂死从 promise 挪到 store —— 用尽仍读不出 ⇒ D5 fail-open 退回纯进程内语义。期间任何一步发现
+ *  `done`(真赢家已在本进程落定)立即退出,退避 timer 一律 `unref`(绝不持住进程)。 */
+const DURABLE_CONVERGE_BACKOFF_MS = [50, 100, 200, 400, 800, 1600];
+/** 单次重读的**墙钟上限**(ms)。🔴 codex 交叉复审 C5(2026-08-06 真缺陷):只数重试次数是**不够**的 ——
+ *  次数只约束「已经返回或已经 reject 的调用」,一次**挂住不返回**的 `getAsk`(DB 连接黑洞、池饿死)会让
+ *  整个退避循环连一格都走不完,`onAsk` 的 promise 于是永久悬挂 —— 正是这段代码要消灭的那个形。每次读都
+ *  与这个 deadline 显式 race,超时算一次失败继续退避;全部用尽走 D5 fail-open。 */
+const DURABLE_CONVERGE_READ_TIMEOUT_MS = 2_000;
+/** #151 车5(codex round2 R2-5):**决定 onAsk 能否落定**的那些 store 调用(`ensureAsk` 及其复核读、
+ *  窗到期/取消/emit-全灭三臂的 CAS)的墙钟上限。
+ *
+ *  🔴 为什么必须有:R2-5 抓的是「重读有 deadline、但**它之前**的调用没有」——`ensureAsk` 在窗定时器与
+ *  abort 监听器**装上之前**被 await,一次黑洞化的 `ensureAsk` 会让整只 ask 连一个兜底都没有地永久悬挂。
+ *  比 converge 的 2s 宽(这些是真正在做事的调用,不是轮询复核),但必须是**有限**的:超时后走的正是各自
+ *  既有的「store 抛错」路径(D5 fail-open / 防御性复核),语义不新增,只是把触发条件从「抛了」放宽到
+ *  「抛了**或**久到不可能再有意义」。 */
+const DURABLE_CALL_TIMEOUT_MS = 5_000;
+/** {@link ToolApprovalCoordinator.withStoreDeadline} 超时时抛的**具名**错误。
+ *  🔴 具名类而不是「按 message 文本判别」:错误文案是给人看的,拿它当控制流 = 上游改一句人话下游静默
+ *  失效(#90 工程规范 v3 门②,机械门在 test/engineering-code-gates.test.ts 盯着)。调用点用
+ *  `instanceof` 分「超时(不知道做没做成)」与「店真报错(没做成)」两条**处置方向不同**的臂。 */
+class ApprovalStoreDeadlineError extends Error {
+    constructor(label, timeoutMs) {
+        super(`approval store call ${label} timed out after ${timeoutMs}ms`);
+        this.name = "ApprovalStoreDeadlineError";
+    }
+}
 /** The fs-write tool family the session allow-all collapses into ONE capability bucket (canonical space — a
  *  5.0.0 RB-476:折叠面退役,三名即 CC canonical(旧拼法在 core roster 层响亮 miss)。Mirrors core's
  *  PATH_WRITE_TOOLS + NotebookEdit (the same set `createFsWriteGatePolicy` gates); NOT exported by core's
@@ -96,7 +140,13 @@ function isChildAsk(req) {
 function boundArgs(args) {
     const redacted = redactDeep(args);
     try {
-        if (JSON.stringify(redacted).length > MAX_APPROVAL_ARGS_BYTES)
+        // 🔴 #151 车3 刀 3b(设计稿 §6.5,codex 复审抓获的真缺陷):`.length` 数的是 **UTF-16 编码单元**,
+        // 而常量名写的是 `_BYTES`——含中文/emoji 的 args 实际 UTF-8 字节数可达该值的约 3 倍(CJK 每字符
+        // 3 字节)⇒ 帽名不副实,而设计 §3.1 把「全量 args 的**字节**帽与洗涤」明写成 server 的新增责任
+        // (引擎无此层)。改按真字节数判,常量语义与名字对齐。
+        // 同一判据**同时**服务 wire 帧与 `card_json` 落库:两侧共用本函数的这一份 `bounded` 结果
+        // (见 askBroadcast 里 frame/card 的构造),不各算各的。钉:E-3(纯 CJK 压线的变异钉)。
+        if (Buffer.byteLength(JSON.stringify(redacted), "utf8") > MAX_APPROVAL_ARGS_BYTES)
             return { omitted: true };
     }
     catch {
@@ -104,6 +154,115 @@ function boundArgs(args) {
     }
     return { args: redacted, omitted: false };
 }
+/** #151 车3 刀 3b:`AskRequest.boundInputHash` 的**边界窄读**(车5 §9 C2 的对账 join 键)。
+ *
+ *  ✅ **已点亮**(#164 翻真验证车,2026-08-07 亲验 core 5.15.0):`AskRequest.boundInputHash` 现在既在类型面
+ *  (`core/tool-policy.d.ts:83`,`readonly boundInputHash?: string`)也在真码面(`core/tool-policy.js:610`:
+ *  `onAsk({ ...req, boundInputHash: boundInputHashOf(presented.value), args: approverView.value })`)——
+ *  每一只经 `resolveAsk` 的 ask 都带值。窄读当初就是为这一刻写的:**同一行代码**不改而自然点亮,收敛器
+ *  判据 1 从「结构上恒不命中」变成会命中,`unmatchableNoHash` 从「响亮化的盲区」退回它该有的边缘含义。
+ *  (旧注写的「树上 core 5.13.0 没有这个键 ⇒ 今天恒回 null」自 core 5.15.0 提货起即过期,勿据以判断。)
+ *
+ *  🔴 保留窄读而不改 import 的理由不变:`boundInputHashOf` 至今**不在 core 的公开导出面**上
+ *  (package `exports` 只有 `.` / `./bench` / `./fixtures`),server 因此既算不出也不该算这个摘要 ——
+ *  它的职责恒是「原样透传落列」。非字符串/空串一律按缺席处置:一个形不对的 hash 比没有 hash 更危险
+ *  (它会让「硬相等」这道门在一个垃圾值上偶然成立)。钉:test/stream-approval-on-e2e.test.ts 件4
+ *  (正控 / 缺席 / 空串三臂 + 收敛器 `unmatchableNoHash` 归零的非零对照)。 */
+function readBoundInputHash(req) {
+    if (req === null || typeof req !== "object")
+        return null;
+    const v = Reflect.get(req, "boundInputHash");
+    return typeof v === "string" && v.length > 0 ? v : null;
+}
+export function resolveStreamApprovalGate(input) {
+    if (!input.toolApprovalEnabled)
+        return { active: false, reason: "no_tool_approval" };
+    if (!input.streamApprovalEnabled)
+        return { active: false, reason: "protocol_disabled" };
+    if (!input.backend)
+        return { active: false, reason: "no_backend" };
+    if (input.backend.kind === "local")
+        return { active: false, reason: "volatile_ask_ledger" };
+    if (!input.parkFacility)
+        return { active: false, reason: "no_park_facility" };
+    return { active: true, askStore: input.backend.approvalAsk() };
+}
+/**
+ * #151 车3 刀 3b(codex 交叉复审 round2 R2-1,2026-08-06 真 finding)—— 呈卡帧的**双写投递口**。
+ *
+ * 🔴 为什么必须收成一个有属主的工厂:round1 之后「新帧送达」开始**参与**「卡到底有没有送到人手上」的
+ * 判定(见 `emitOne` 顶注)。而 sync 腿原来那个内联闭包把两个 sink 的失败都吞掉、然后**正常返回** ——
+ * 于是「账本写失败 ∧ socket 已死」这种**真的一路都没送到**的情形被上报成成功,`anySucceeded` 因此压住了
+ * park 路由,ask 会一直挂到窗到期而**没有任何人可能回答它**。诚实的形只有一个:**至少一个 sink 真的接下
+ * 了才算送达**,一个都没接下就抛 —— 调用点(`emitOne`)的 catch 会把它如实记成 `card: false`。
+ *
+ * 顺序 = **先账本后 live**(与 file_link 的先例相反,理由是本帧的用武之地恰好在 live 面已死的时候):
+ * detach 断连后 live 写被丢弃,而壳换道 events tail 必须还能看到这张未决卡(§4.3(c) 的案A)。
+ *
+ * 命名(CLAUDE.md 工厂命名律):`create*` —— 返回的是**捕获了两个 sink 的闭包**,不是纯数据。
+ */
+export function createApprovalCardEmitter(sinks) {
+    return async (frame) => {
+        let accepted = false;
+        if (sinks.appendDurable) {
+            try {
+                await sinks.appendDurable(frame);
+                accepted = true;
+            }
+            catch {
+                /* 账本瞬断不 fault 卡面 —— 但也**不算**送达(下面还有一路,两路都没接下才抛) */
+            }
+        }
+        if (sinks.writeLive) {
+            try {
+                await sinks.writeLive(frame);
+                accepted = true;
+            }
+            catch {
+                /* 死流/已 destroy 的 socket —— 同上 */
+            }
+        }
+        if (!accepted)
+            throw new Error("approval card undeliverable — no sink accepted the frame (live stream closed and/or the durable append failed)");
+    };
+}
+export function resolveApprovalLeg(input) {
+    if (!input.streamApprovalOn)
+        return { active: false, windowZero: false };
+    const tightDeadline = input.legWalltimeMs !== undefined && input.legWalltimeMs - input.windowMarginMs <= 0;
+    if (input.windowMs === 0 || tightDeadline)
+        return { active: true, windowZero: true };
+    return {
+        active: true,
+        windowZero: false,
+        ...(input.legWalltimeMs !== undefined ? { legDeadlineMonotonic: input.nowMonotonicMs + input.legWalltimeMs } : {}),
+    };
+}
+/** #151 车2(design/172 §3.3 D3,窗长三元,逐字):有效窗 = `min(ttlMs 配置, legRemainingMs − windowMarginMs)`。
+ *  `legDeadlineMonotonic` 缺席(现行为绝大多数腿——装配点车3 才真传)⇒ 有效窗退化成 `ttlMs`,逐字不变
+ *  (D1 零行为变化)。在场且算出的窗 ≤ 0(本 leg 剩余 walltime 撑不住安全余量)⇒ 折 0——调用方按 0ms
+ *  定时器处理,等同「不开窗,立即走窗到期同路」(§3.3 不变量:窗不得把一个可 park 的 ask 拖成
+ *  abort-deny)。纯函数(禁 if 链风格的最小实现,`nowMonotonicMs` 显式入参便于测试注入,不裸读全局时钟)。 */
+function effectiveAskWindowMs(ttlMs, windowMarginMs, legDeadlineMonotonic, nowMonotonicMs) {
+    if (legDeadlineMonotonic === undefined)
+        return ttlMs;
+    const legRemainingMs = legDeadlineMonotonic - nowMonotonicMs;
+    return Math.min(ttlMs, Math.max(0, legRemainingMs - windowMarginMs));
+}
+/** #151 车2(codex 交叉复审 round4 抓获,真 finding):`ensureAsk` 幂等 upsert 撞见一条**已经终结**(或
+ *  正在 PARKING/PARKED)的既有行时,把它翻译成一个直接可回放的 `AskOutcome`——不重新挂一条注定赢不了
+ *  CAS 的本地待决。三态映射:`DECIDED` 按记录的决定回放(仅布尔臂,持久层不存 `updatedInput`,ctrl+g
+ *  编辑重放的字面丢失属已知、可接受的降级——`updatedInput` 全链条本就是纯 wire 层语义,未进车1 的行
+ *  schema);`PARKING`/`PARKED` 统一按「已转投递面」回放 `"unavailable"`(park 路由,与 D2 窗到期赢的
+ *  语义一致);`DENIED`/`VOID` 回放 `false`(routing_failure 与人拒/取消的两分归因是车4 的活,本车只
+ *  保证不挂死、不用一个捏造的 true 掩盖真实终局)。`STREAM_PENDING` 不会走到这里(调用点已经判过)。 */
+function replayTerminalAskRow(row) {
+    if (row.state === "DECIDED")
+        return row.decision === "approve";
+    if (row.state === "PARKING" || row.state === "PARKED")
+        return "unavailable";
+    return false; // DENIED | VOID(STREAM_PENDING 由调用点排除在外)
+}
 /**
  * Coordinates the live tool-approval HITL for the singleton runner. Process-local + same-replica (the pending map is
  * in memory, like QuestionCoordinator): a respond that lands on another replica finds nothing → 404. Present (passed
@@ -119,6 +278,22 @@ function boundArgs(args) {
 export class ToolApprovalCoordinator {
     als = new AsyncLocalStorage();
     pending = new Map();
+    /** #151 车2(codex 交叉复审 round3 抓获真 finding,round5 精化成 Set):次级索引,键 = 持久层 askId
+     *  (与 {@link pending} 的 wire-面 uuidv7 `id` 是两条独立的身份轴,顶注同精神)——只在 askStore 在场且
+     *  这只 ask 真有 askId 时才登记。**同一 askId 下可能同时挂着不止一条本地条目**(round5 抓获:
+     *  `ensureAsk` 是幂等 upsert,若 core 对同一 (sourceTaskId,runId,toolCallId,legKey) 真发起过两次并发调用——如
+     *  重试/failover 场景,round4 finding2 的顶注同源——两次 `askBroadcast` 各自的调用栈都会在行仍是
+     *  STREAM_PENDING 时各自注册一条独立的本地 pending 条目,值形若是单值 Map 会被后到者覆盖前者的登记,
+     *  前者从此再也没有任何本地事件会驱动它 settle),故值形是 `Set`,不是单个 `PendingApproval`。
+     *  存在理由(两类真实成因共用同一套修复):①同一批(相同 sourceTaskId+leg)下若有多只**不同** ask 并发
+     *  在飞(不同 toolCallId,同一 batchId),`expireAsk` 赢家的同一次持久事务会把批内其余 STREAM_PENDING
+     *  兄弟原子撤成 VOID 并把它们的 askId 列在 `voidedSiblings` 里;②同一 askId 的**重复本地注册**(见上)。
+     *  两类情形下,那些"没赢"的本地条目各自独立的 timer/settle 闭包都对"这只 askId 其实已经有了终局"一无
+     *  所知:它们自己的窗到期/取消若稍后也去打 CAS,只会干净地输(D2 round2「输⇒什么都不做」),从此再没有
+     *  任何本地事件会驱动它们 settle——TTL 形同虚设,ask 会挂到进程重启。这个索引让赢家能反过来找到同一
+     *  askId 下全部本地条目(自己 + 兄弟 + 重复注册),直接调用它们各自的 `settle`,而不是被动等一个永远
+     *  不会来的本地信号。 */
+    pendingByAskId = new Map();
     /** Per-capability session grants — keys = sessionAllowKey(owner, sessionId, category) (修2; bounded). */
     allowAllSessions = new Set();
     /** [1546] HIGH-1(broker)→[1559]四 core 产品裁定「多活集合+广播+首决胜出」:per-(owner, host-session)
@@ -131,8 +306,234 @@ export class ToolApprovalCoordinator {
      *  收 dismiss 通知(见 askBroadcast)。 */
     streams = new Map();
     ttlMs;
-    constructor(ttlMs = DEFAULT_APPROVAL_TTL_MS) {
-        this.ttlMs = ttlMs;
+    /** #151 车2(design/172 §7 协调器半场,D1):可选持久层——缺席 ⇒ 每一条现行为逐字不变(in-memory
+     *  promise 机械即契约);在场 ⇒ 四竞争者(回决/窗到期/取消/emit 全灭)的终局多一道持久 CAS 记账。
+     *  additive 改造,不是替换——settle 闭包/pending map/TTL/broker 全保留,CAS 只决定「谁有权 settle
+     *  成什么终局」。 */
+    askStore;
+    /** #151 车2(design/172 §3.3 D3):窗长三元公式的安全余量,构造期定,详见 {@link effectiveAskWindowMs}。 */
+    windowMarginMs;
+    /** #151 车3 刀 3b(设计稿 §0 X-2 写侧准入门):per-task / per-owner 的未决 ask 上限。 */
+    admitMaxPerTask;
+    admitMaxPerOwner;
+    /** X-2 的两把**在飞计数**。键 = 出处 taskId / owner(`null` 折一个不可能与真 principal 相撞的哨兵)。
+     *  值在**准入那一刻**加、在 `settle`(或准入后的任何早退路径)减 —— 计的是「已经分配了资源的未决 ask」,
+     *  不是「注册进 pending map 的条目」:两者之间隔着 `ensureAsk` 的一次 await,只在注册时计数会让并发的
+     *  一群 ask 全部越过门。 */
+    admitByTask = new Map();
+    admitByOwner = new Map();
+    /** #151 车2(D5 一次性 warn 节流):同实例只报第一次,后续只计数(避免 store 抖动期间刷屏)。 */
+    storeErrorWarned = false;
+    storeErrorTally = 0;
+    constructor(opts) {
+        this.ttlMs = opts?.ttlMs ?? DEFAULT_APPROVAL_TTL_MS;
+        this.askStore = opts?.askStore;
+        this.windowMarginMs = opts?.windowMarginMs ?? DEFAULT_WINDOW_MARGIN_MS;
+        this.admitMaxPerTask = opts?.admitMaxPerTask ?? DEFAULT_ADMIT_MAX_PER_TASK;
+        this.admitMaxPerOwner = opts?.admitMaxPerOwner ?? DEFAULT_ADMIT_MAX_PER_OWNER;
+    }
+    /**
+     * #151 车3 刀 3b —— design/172 §3.3 / 设计稿 §0 X-2 的**写侧准入门**。
+     *
+     * 位置(硬条款):在落 `pending`、建 timer、`ensureAsk` 落行、发帧**之前**。资源分配发生在**创建侧**
+     * (每只未决 ask 各带一条持久行 + 一只 timer + 一个 promise + 一份 SSE 载荷;`pending` map 本身无容量
+     * 上限,`MAX_ALLOW_SESSIONS` 只管 grant 集合),所以回决腿与恢复扫描都只能在**已经分配之后**动手 ——
+     * 门必须长在这里。
+     *
+     * 超限的处置是 `"unavailable"`(park 路由),**永不 deny**:过载是**我方**的容量事实,不是人对这次
+     * 操作的判断;用 deny 表达过载会把一次「本可以 park 后由人补批」的操作变成任务失败(§3.3 硬条款)。
+     *
+     * 只在 `askStore` 在场(= 协议开着)时把关:开关关闭时本方法恒放行,现行为逐字不变(D1/A-1)。
+     *
+     * ⚠️ **已认领的偏离**(设计 X-2 字面要求「计数在持久层做」):v1 是**进程内**计数 —— 它对单副本完整
+     * 有效,多副本下每个副本各自把关(真实上限 = N × 帽)。理由=持久层计数要么在每只 ask 的热路径上多一次
+     * 往返(与「门必须在分配之前」叠加成两跳),要么引入一张新的计数表与它自己的收敛问题;而本门的目的是
+     * **防单腿失控**(一个疯狂 ask 的 run 打爆本副本的内存/连接),那正是进程内计数能完整覆盖的形。
+     * 多副本级的总量控制登记为后续件(汇报存疑单)。
+     */
+    admit(taskId, owner) {
+        if (!this.askStore)
+            return () => undefined; // 协议未上场:门不参与(D1 零行为变化)
+        // JSON 元组编码(同 sessionAllowKey 先例):`null` 与字面量 "null" 的 principal 不可能算出同一把键。
+        const ownerKey = JSON.stringify(["owner", owner]);
+        const taskCount = this.admitByTask.get(taskId) ?? 0;
+        const ownerCount = this.admitByOwner.get(ownerKey) ?? 0;
+        if (taskCount >= this.admitMaxPerTask || ownerCount >= this.admitMaxPerOwner)
+            return undefined;
+        this.admitByTask.set(taskId, taskCount + 1);
+        this.admitByOwner.set(ownerKey, ownerCount + 1);
+        let released = false;
+        return () => {
+            if (released)
+                return; // 幂等:settle 与早退路径可能都调到它
+            released = true;
+            const t = (this.admitByTask.get(taskId) ?? 1) - 1;
+            if (t <= 0)
+                this.admitByTask.delete(taskId);
+            else
+                this.admitByTask.set(taskId, t);
+            const o = (this.admitByOwner.get(ownerKey) ?? 1) - 1;
+            if (o <= 0)
+                this.admitByOwner.delete(ownerKey);
+            else
+                this.admitByOwner.set(ownerKey, o);
+        };
+    }
+    /** 测试/可观测性钩子(X-2):某 (taskId) 维当前占用的准入名额数。 */
+    admittedCount(taskId) {
+        return this.admitByTask.get(taskId) ?? 0;
+    }
+    /** #151 车2(D5 store 故障姿势):任何 store 调用 throw ⇒ fail-open 到进程内机械照旧(store 是记账/
+     *  收敛层,不是投递面——裁决可用性不因它抖动而降级),一次性 `logger.warn`(同实例只报第一次,后续
+     *  只计数)。**区分**「store threw」(本方法专管)与「CAS 输」(如实拒绝,D2 必须服从,绝不算故障、
+     *  绝不走本方法)。 */
+    noteStoreError(err, where) {
+        this.storeErrorTally++;
+        if (!this.storeErrorWarned) {
+            this.storeErrorWarned = true;
+            defaultLogger.warn("approval-ask store call failed — falling back to in-process semantics", {
+                where,
+                err: err instanceof Error ? err.message : String(err),
+            });
+        }
+    }
+    /** #151 车5(R2-5):给一次 store 调用套墙钟上限。超时 = 以 `Error` 拒绝 ⇒ 调用点既有的 catch(D5
+     *  fail-open / 防御性复核)原样接住,不需要为超时新增一条语义。定时器一律 `unref`(绝不持住进程),
+     *  竞速输的那一路由 `Promise.race` 自己的 rejection handler 接住(不会变成 unhandled rejection)。 */
+    withStoreDeadline(op, label, timeoutMs = DURABLE_CALL_TIMEOUT_MS, onLateSuccess) {
+        let timedOut = false;
+        // 🔴 codex 交叉复审 round3 R3-1(2026-08-06 真缺陷):deadline **只能取消等待,取消不了副作用** ——
+        // store 没有 abort 面,一条超时的 `expireAsk` 事务完全可能**稍后真的提交**(行进 PARKING、兄弟被原子
+        // 撤成 VOID)。旧形把那次结果整个丢掉,于是:兄弟的本地条目永远等不到 settle(挂死),撤卡帧一张不发
+        // (壳上留着已作废的卡)。判据不能是「我等到了吗」,得是「它到底做成了吗」。
+        // 修法:保留原 promise 的续接 —— 迟到的成功仍然把该做的收尾做完(`onLateSuccess`)。这不是「取消副作用」
+        // (那要 store 层给可中止事务,超本车范围),而是**不丢失**副作用;本地终局那一半由 `settle` 的幂等性
+        // 保证不被二次改写。回调自身抛错一律吞掉(收尾的收尾不许再变成故障源)。
+        // ⚠️ 迟到成功的观测器必须**旁挂**,不能挂进返回链(`op.then(...)` 会多插一个 microtask 跳,而本方法
+        // 包着的第一个调用点是 `ensureAsk` —— 它在开卡帧发射**之前**,多一跳就把「卡什么时候出现」整体推后
+        // 一格;存量用例用 `await Promise.resolve()` 计跳等这张卡,会静默拿到 undefined 的 approvalId)。
+        // 旁挂 = 观测得到、时序零影响(codex round4 的同款建议)。两个 handler 都给:`op` 的 rejection 因此
+        // 恒有处理者,不会变成 unhandled rejection。
+        if (onLateSuccess) {
+            void op.then((value) => {
+                if (!timedOut)
+                    return;
+                try {
+                    onLateSuccess(value);
+                }
+                catch {
+                    /* 收尾的收尾不许成为故障源 */
+                }
+            }, () => undefined);
+        }
+        // R4-3:正常落定时**清掉**定时器 —— `unref` 只让它不持住进程,不释放定时器本身与它闭包里捕获的
+        // (coordinator / ctx / 回调)引用。审批流量持续时,这就是一堆本可立刻回收的定时器与堆。清定时器
+        // **不影响**迟到成功的续接:那一半挂在 `tracked` 上,与本定时器无关。
+        let timer;
+        const deadline = new Promise((_resolve, reject) => {
+            timer = setTimeout(() => {
+                timedOut = true;
+                reject(new ApprovalStoreDeadlineError(label, timeoutMs));
+            }, timeoutMs);
+            timer.unref?.();
+        });
+        const raced = Promise.race([op, deadline]);
+        // 清定时器同样**旁挂**(`.finally()` 会给返回链再插一跳,理由同上面的观测器):调用方拿到的就是
+        // `raced` 本身,时序零影响;清理晚一个 microtask 发生,对定时器毫无影响。
+        const clear = () => {
+            if (timer !== undefined)
+                clearTimeout(timer);
+        };
+        void raced.then(clear, clear);
+        return raced;
+    }
+    /** 测试/可观测性钩子(D5):store 调用失败的累计次数(第一次触发 warn,其余只计数——本方法让「只计数」
+     *  那部分可断言）。 */
+    storeErrorCount() {
+        return this.storeErrorTally;
+    }
+    /** #151 车2(codex 交叉复审 round3 抓获、round5 精化,真 finding,{@link pendingByAskId} 顶注有完整
+     *  背景):某个 ask 赢下持久 CAS 时,同一 askId 下**全部**其余本地条目(批内被原子撤卡的兄弟、或同一
+     *  askId 的重复本地注册——两类成因,{@link pendingByAskId} 顶注)都对"这只 askId 其实已经有了终局"一无
+     *  所知,任其自生自灭会让它们的 TTL 形同虚设(round2 之后,它们自己的窗到期/取消一旦发现 CAS 已经干净
+     *  地输,只会「什么都不做」,永远等不到本地事件驱动 settle)。这里直接反查这些 askId 各自的本地 pending
+     *  条目集合并逐个调用它们自己的 `settle` 闭包(复用它们自己的 timer 清理/abort 监听器摘除/pending
+     *  删除),把远程/其他调用栈发生的终局如实同步回本地——查无对应条目(不在这个副本、或从未真正注册过)
+     *  是正常情况,静默跳过。**调用方职责**:传入的 `askIds` 应当包含调用方自己的 askId(捕获"同一 askId
+     *  的重复本地注册"这一支)以及(如适用)`expireAsk` 返回的 `voidedSiblings`(捕获"批内兄弟被撤卡"那一
+     *  支)——赢家自己的条目此刻已经 settle 过、已经从集合里摘除(见 settle() 内的摘除逻辑),故这里对它
+     *  自己重复调用 `settle` 天然是无操作,不会有副作用。 */
+    settleVoidedSiblings(askIds) {
+        for (const askId of askIds) {
+            const entries = this.pendingByAskId.get(askId);
+            if (!entries)
+                continue;
+            for (const entry of [...entries])
+                entry.settle(false, "expired"); // 拷贝快照:settle 会修改原集合
+        }
+    }
+    /**
+     * #151 车4 §12-E(F29/F30 裁定形):外部回决(车4 端点或本类 respond 腿)**赢下持久 CAS 之后**,把同
+     * askId 下全部本地悬挂条目按**真实决议**结算——端点已是唯一权威(CAS 已落),本地只是同步终局;查无
+     * 条目(跨副本/无流内窗)= 正常,返回 `{ settled: 0 }`,调用方据此诚实回显 `updatedInputForwarded`。
+     *
+     * 🔴 与 {@link settleVoidedSiblings} 是**两个语义,禁合并**(F29):那边是撤卡收尾,结算值恒
+     * `(false, "expired")`——批内兄弟被原子撤卡,它们的终局就是「没了」;这边是「同一只 askId 已经有了
+     * 真决议」,重复注册必须拿到**同一个**决议(approve 就是 approve)——合并会把外部批准的重复条目错
+     * 结算成拒绝。已被结算过的条目再调 settle 天然无操作(幂等),所以本口对「赢家自己已 settle」安全。
+     */
+    notifyExternalDecision(askId, allowed, updatedInput) {
+        const entries = this.pendingByAskId.get(askId);
+        if (!entries)
+            return { settled: 0 };
+        let settled = 0;
+        for (const entry of [...entries]) {
+            entry.settle(allowed, allowed ? "allowed" : "denied", updatedInput);
+            settled += 1;
+        }
+        return { settled };
+    }
+    /**
+     * #151 车6:把一张**批级撤卡帧**投给给定的一组连接(live only —— 见 `ApprovalRevokeFrame` 顶注:
+     * 撤卡帧不进 durable tail,丢帧的结构补偿是重连 preamble 的全量对账基准)。
+     *
+     * 空名单不发(零信息的帧只会让壳多一次无意义的对账)。每路独立 catch:一路 emit 失败(连接刚死、
+     * durable-append 目标抖动)**绝不回滚已经落定的持久 CAS** —— 帧是通知,行才是真源。
+     */
+    emitRevokeTo(ctxs, frame) {
+        if (frame.askIds.length === 0)
+            return;
+        for (const c of ctxs) {
+            if (!c.emitRevoke)
+                continue; // 本连接没接撤卡口(见 ToolApprovalRunContext.emitRevoke 顶注)
+            try {
+                void Promise.resolve(c.emitRevoke(frame)).catch(() => undefined);
+            }
+            catch {
+                // 同步 throw 的 emit 目标(流已结束的那种)——吞掉:卡的作废已经是持久事实,通知投不出去
+                // 不改变它,更不回滚已经赢下的 CAS。
+            }
+        }
+    }
+    /**
+     * #151 车6 发射点③④:**进程外**收敛器(reaper 腿的 `approval-reconciler.ts`)产出的撤卡帧的投递口。
+     * 收敛器没有 ctx —— 它只有行上的 (owner, sessionId, taskId),经 broker 反查该身份下**当前**的活跃
+     * 连接集合。查无活连接 = 正常(壳不在线;重连 preamble 会把这张卡对账掉),返回 0。
+     *
+     * 两把 key 都试(session 形 + adhoc 形)并去重:行上的 `sessionId` 对 adhoc 腿折的是 taskId
+     * (车2 落行时的折叠),而 broker 的 adhoc 分桶键用的正是 taskId —— 两形各试一次比在这里猜哪种腿
+     * 更诚实,代价是一次 Map 查找。
+     */
+    emitRevoke(frame, target) {
+        const targets = new Set();
+        for (const key of [this.streamKey(target.owner, target.sessionId, target.taskId), this.streamKey(target.owner, undefined, target.taskId)]) {
+            for (const c of this.streams.get(key) ?? [])
+                targets.add(c);
+        }
+        if (targets.size === 0)
+            return 0;
+        this.emitRevokeTo([...targets], frame);
+        return targets.size;
     }
     /** Broker key:宿主 session 优先(retained/续聊子代跨 SSE 找得到新流),sessionless adhoc 退 taskId。
      *  并发审查加固:显式维度前缀(`"session"`/`"adhoc"`)分隔两个取值域,不再靠 `task:` 字符串前缀"祈祷"
@@ -197,7 +598,8 @@ export class ToolApprovalCoordinator {
         // "unavailable"(交 durable park),不再把「无人可问」翻译成 deny(1.295 前无三值只能 fail-closed)。
         if (!ctx)
             return "unavailable";
-        return this.askBroadcast([ctx], req, signal);
+        // 出处 = 本 ctx 自身(ALS 腿的投递集合恒是它一个),显式传,不靠 askBroadcast 去猜。
+        return this.askBroadcast({ taskId: ctx.taskId, legKey: ctx.legKey ?? "", ...(ctx.legDeadlineMonotonic !== undefined ? { legDeadlineMonotonic: ctx.legDeadlineMonotonic } : {}) }, [ctx], req, signal);
     };
     /** [1535] server 半场(审批链战役,[1539] 定谳断点①的修;[1546] HIGH-1 broker 形):宿主 sync
      *  streaming 腿在装配点以本闭包挂 `spec.onAsk`;core 继承链(parentConstraints 冻结
@@ -212,7 +614,12 @@ export class ToolApprovalCoordinator {
             const live = set && set.size > 0 ? [...set] : [];
             if (live.length === 0)
                 return Promise.resolve("unavailable");
-            return this.askBroadcast(live, req, signal);
+            // 🔴 codex 交叉复审(刀 3a,high)修:身份轴取**捕获的出处身份**,不取投递集合的第一条流。
+            // `streamKey` 的 session 形不含 taskId ⇒ 同一集合里可以躺着不同 run 的 ctx,`aliveCtxs[0]` 只是
+            // 「当下第一条活着的投递连接」。用它当 runId 会双向出错:同一只出处 ask 在集合组成变化后重入拿到
+            // 不同 askId(幂等 upsert 失效 ⇒ 重入挂到 TTL),不同出处 run 经同一条流下发拿到同一 askId
+            // (正是换轴要封死的复用面)。`legKey` 同理随出处走(装配点 3b 供真值,缺席折空串)。
+            return this.askBroadcast({ taskId: identity.taskId, legKey: identity.legKey ?? "", ...(identity.legDeadlineMonotonic !== undefined ? { legDeadlineMonotonic: identity.legDeadlineMonotonic } : {}) }, live, req, signal);
         };
     };
     /** 广播版裁决路径——`ask()`(ALS,恒单元素数组)与 `boundAsk`([1559]四多活集合,可能多元素)共用。
@@ -226,7 +633,7 @@ export class ToolApprovalCoordinator {
      *  "unavailable"。人类 respond() 落地的裁决永远照旧信任、不受本判据影响:它只可能在 approvalId 已经
      *  送达某个客户端之后发生(respond 需要客户端手上有这个 id),这是 outcome==="allowed"/"denied" 与
      *  "expired"(TTL/abort/run-exit-cleanup/emit 广播全灭四类共用)的天然分野。 */
-    async askBroadcast(ctxs, req, signal) {
+    async askBroadcast(origin, ctxs, req, signal) {
         if (signal?.aborted)
             return false;
         // 连接级存活过滤:单连接(ask() 的 ALS 语义,今日 100% 生产流量)沿用「这条连接已经死了 ⇒ false」的
@@ -243,15 +650,264 @@ export class ToolApprovalCoordinator {
         if (primary.sessionId && this.allowAllSessions.has(sessionAllowKey(primary.owner, primary.sessionId, sessionAllowCategory(req.toolName)))) {
             return true;
         }
+        // #151 车3 刀 3b(设计稿 §0 X-2):**写侧准入门** —— 落 pending / 建 timer / 落行 / 发帧之前。
+        // 超限 ⇒ `"unavailable"`(park 路由,永不 deny)。协议未上场时恒放行(见 {@link admit})。
+        const releaseAdmission = this.admit(origin.taskId, primary.owner);
+        if (!releaseAdmission) {
+            defaultLogger.warn("approval admission gate: too many pending asks — routing to park", {
+                taskId: origin.taskId,
+                perTask: this.admitByTask.get(origin.taskId) ?? 0,
+                admitMaxPerTask: this.admitMaxPerTask,
+                admitMaxPerOwner: this.admitMaxPerOwner,
+            });
+            return "unavailable";
+        }
+        // `id` = **本地** pending 条目的键(每次注册各一个,绝不共享 —— {@link pendingByAskId} 顶注记的
+        // 「同 askId 重复本地注册」两类成因下,两条条目必须各占一格,否则后到者会覆盖先到者的登记)。
         const id = uuidv7();
+        const child = isChildAsk(req);
+        const bounded = boundArgs(req.args);
+        const frame = {
+            type: "tool_approval",
+            approvalId: id,
+            toolName: req.toolName,
+            // [1939]:core 的 tool-call id 逐字透传(AskRequest.toolCallId 是必填);理由见字段顶注。
+            ...(typeof req.toolCallId === "string" && req.toolCallId !== "" ? { toolCallId: req.toolCallId } : {}),
+            // 帧上 sourceTaskId/fromSubagent/sourceAgentName 只出**子代** ask(server 侧判别收口,现判别
+            // 键 = req.fromSubagent[core RB-39② 显式受信键]——sourceTaskId 仍旁随传但不再是判别式,复审
+            // F2 案:core 对宿主 ask 也恒填 sourceTaskId=宿主 sessionId,裸透传会让每张宿主卡被误判子代)。
+            ...(child
+                ? {
+                    sourceTaskId: req.sourceTaskId,
+                    fromSubagent: true,
+                    ...(typeof req.sourceAgentName === "string" ? { sourceAgentName: redactSecrets(req.sourceAgentName) } : {}),
+                    // core 5.9.0 W1:出处链透传(agentName 同 sourceAgentName 待遇 redact;其余为 core-mint 标识非内容)。
+                    ...(req.delegation
+                        ? {
+                            delegation: {
+                                parentToolCallId: req.delegation.parentToolCallId,
+                                depth: req.delegation.depth,
+                                ...(typeof req.delegation.agentName === "string" ? { agentName: redactSecrets(req.delegation.agentName) } : {}),
+                            },
+                        }
+                        : {}),
+                }
+                : {}),
+            message: typeof req.message === "string" ? redactDeep(req.message) : "",
+            ...(bounded.omitted ? { argsOmitted: true } : { args: bounded.args }),
+        };
+        // #151 车2(design/172 §3.3 D3 窗长三元):有效窗——legDeadlineMonotonic 缺席时退化成 ttlMs(D1 零
+        // 行为变化)。用它既定时器时长,也是 store 在场时 ensureAsk 的 expiresAtMs。
+        // 🔴 车3 刀 3b 收口(3a 在此留的坐标):`legDeadlineMonotonic` 现取自 **`origin`**(出处腿),
+        // 不再取投递连接 `primary` —— 理由见 {@link AskOriginIdentity.legDeadlineMonotonic}(session 形的
+        // 投递集合可以躺着别的 run 的 ctx,读 primary 会拿到另一条腿的 deadline)。缺席仍退化成 ttlMs。
+        const effectiveWindowMs = effectiveAskWindowMs(this.ttlMs, this.windowMarginMs, origin.legDeadlineMonotonic, performance.now());
+        // 🔴 窗的**绝对** deadline 一次铸定(§3.1「永不赋新 deadline、永不重启窗」):落库的 `expires_at_ms`、
+        // 呈卡帧的 `expiresAtMs`、以及重放腿回读的那一份**必须**是同一个数。此前它内联在 ensureAsk 的入参里,
+        // 呈卡帧接上来之后若各算各的 `Date.now() + effectiveWindowMs`,两处就会差出一个 await 的时间。
+        const expiresAtMs = Date.now() + effectiveWindowMs;
+        // #151 车2(D4 askId/batchId 铸造 + register-before-emit):只在 askStore 在场时计算/落盘——askId 派生
+        // 与 pending map 的 uuidv7 `id` 是两条独立的身份轴(顶注)。ensureAsk 在此处调用(register-before-emit
+        // 之前),cardJson 存 frame 的已洗投影(boundArgs 之后的 frame 对象,D4)。
+        let askId;
+        let batchId;
+        // #151 车3 刀 3b:design/172 §3.1 的**中性投影**。素材 = 上面那个已洗、已按**字节**帽处理过的
+        // `frame`(结构上满足 `ApprovalCardSource`)—— 于是「wire 帧与 card_json 同一份判据」是结构事实,
+        // 不是两处各算一遍的巧合(§6.5)。`risk` 三态由 `buildApprovalCard` 从 `req` 窄读(缺席=未标注)。
+        // 只在协议上场(askStore 在场)时铸:关着时这几行连算都不算,现行为逐字不变(A-1)。
+        const card = this.askStore ? buildApprovalCard(frame, req, req.requiresRealApproval === true) : undefined;
+        /**
+         * 发帧时真正用的**卡 / deadline / wire 身份** —— 默认是本地刚铸的这一份;`ensureAsk` 返回一条
+         * **早已存在**的 STREAM_PENDING 行时改采信行(codex 交叉复审 F2,2026-08-06 真 finding)。
+         *
+         * 🔴 与上面的 `id` 是**两条轴,不可合并**:`id` 是本地 pending 的键(重复注册各占一格),
+         * `wireApprovalId` 是这只 ask 在 **wire 上的唯一身份**(消费端按它去重、`respond` 按它寻的那把)。
+         * 合并会二选一地出错:共用一把 ⇒ 重复注册互相覆盖本地登记(先到者从此无人驱动);各铸各的 ⇒
+         * 同一个 askId 带着两个 approvalId 上 wire(壳把一张卡渲两次)、两个 deadline(破 §3.1
+         * 「窗一次铸定、永不重算」)。分成两条轴,两件事各自成立。
+         */
+        let wireApprovalId = id;
+        let cardForFrame = card;
+        let persistedExpiresAtMs = expiresAtMs;
+        // R4-1 的三件套(见下方 ensureAsk 调用点注):迟到落盘的行 id / 本地是否已放弃 / 放弃时的收尾动作。
+        let lateEnsuredAskId;
+        let abandonedEnsure = false;
+        /** 本次 `ensureAsk` 传给店里的 `createdAtMs` —— 兼作**这次插入的归属凭据**(R2-2,见 onLateSuccess）。 */
+        const attemptCreatedAtMs = Date.now();
+        const voidAbandonedRow = (orphanAskId) => {
+            const store = this.askStore;
+            if (!store)
+                return;
+            void store
+                .transitionAsk(orphanAskId, "STREAM_PENDING", "VOID", { updatedAtMs: Date.now() })
+                .catch((err) => this.noteStoreError(err, "transitionAsk(abandon-late-ensure)"));
+        };
+        // `card` 与 `askStore` 一律同在同不在(上面同一个三元铸的)——把两者一起narrow,下面落行时就不必
+        // 为「理论上可能缺席」的卡再写一条不可达的兜底分支。
+        if (this.askStore && card) {
+            const sourceTaskId = req.sourceTaskId ?? origin.taskId;
+            // runId 轴 = 本 run 的 wire id,取自**出处**(`origin`)而不是投递连接:core 给
+            // `AskRequest.sourceTaskId` 填的是 sessionId(prepare-task.js:2595),两者在同一会话的多次提交
+            // 之间是「不变」与「必变」的关系——正是这条轴封死了跨 run 复用旧同意(§10 钉 C-1)。
+            // 为什么不是 `primary.taskId`:见 boundAsk 里那条 codex 复审注(投递集合可含别的 run 的流)。
+            const runId = origin.taskId;
+            const legKey = origin.legKey;
+            askId = deriveAskId(sourceTaskId, runId, req.toolCallId, legKey, req.delegation?.parentToolCallId);
+            batchId = deriveBatchId(sourceTaskId, runId, legKey);
+            try {
+                // R2-5:`ensureAsk` 在窗定时器/abort 监听器装上**之前**被 await ⇒ 必须有界(见 DURABLE_CALL_TIMEOUT_MS)。
+                // R4-1(codex round4):**迟到成功**要观测 —— 超时后若复核读也没看见行,下面会把 askId/batchId 清空
+                // 降级成「store 缺席」;而那笔事务完全可能**稍后才提交**,留下一条**没有任何本地属主**的
+                // STREAM_PENDING 行。它随后会被本车的孤儿腿代打 expire → PARKING → 甚至被对账收敛器 PARK 出一张
+                // **幻影 gate**(工具其实早已按本地终局执行完了)。所以:一旦确认本地放弃了这条行,就把它收成
+                // VOID(「这行从来没有过属主」)。best-effort:失败也无妨,收敛器仍是最后兜底。
+                const existingOrCreated = await this.withStoreDeadline(this.askStore.ensureAsk({
+                    askId,
+                    // 行记在**出处** run 名下(listPendingByTask 与恢复扫描按它找人),不是投递流的 run。
+                    taskId: origin.taskId,
+                    sourceTaskId,
+                    // sessionId 是店内必填列;session-less(adhoc)ask 折 taskId——同 streamKey 的 "adhoc" 分桶
+                    // 精神一致(taskId 替身份充当会话锚),非 design/172 字面钉死,是本车工程判断(见汇报存疑单）。
+                    sessionId: primary.sessionId ?? origin.taskId,
+                    owner: primary.owner,
+                    batchId,
+                    toolCallId: req.toolCallId,
+                    legKey,
+                    parentToolCallId: req.delegation?.parentToolCallId ?? null,
+                    // 🔴 车3 刀 3b(设计稿 §6.2,车5 移交②):`card_json` 存的是**信封**(`{schemaVersion, approvalId,
+                    // card}`),不再是整帧。写侧(这里)与读侧(重放腿/车4/车5 的 `ApprovalCardEnvelopeSchema.safeParse`)
+                    // 因此是同一个符号,存的形与读的形不可能各自漂。**直接迁移、不做兼容读**:表与代码都还没出厂
+                    // (未打 tag),按 SCHEMA POLICY drop-and-recreate,不给一个从未出厂的形状留兼容层(§6.2 裁定 +
+                    // 本仓「不做临时方案」纪律)。
+                    cardJson: buildApprovalCardEnvelope(id, card),
+                    // 车5 §9 C2 的对账 join 键。**窄读**(顶注:core 5.15.0 起真有值,窄读的理由改为「摘要函数
+                    // 不在 core 公开导出面,server 只透传不重算」)——有则存、无则 null;缺席 ⇒ 收敛器判据 1
+                    // 结构上不命中(`unmatchableNoHash` 计数),这是**设计要的** fail-safe,不是降级(禁「能取到时才比」)。
+                    boundInputHash: readBoundInputHash(req),
+                    schemaVersion: 1,
+                    expiresAtMs,
+                    createdAtMs: attemptCreatedAtMs,
+                }), "ensureAsk", DURABLE_CALL_TIMEOUT_MS, (late) => {
+                    // 🔴 codex 交叉复审 round2 R2-2(2026-08-06 真 finding):`ensureAsk` 是**幂等 upsert**,它迟到
+                    // 返回的那一行可能根本不是本次插的 —— 而是一条**早已存在、且正被另一次调用持有**的行(askId 是
+                    // 确定性派生,两次并发调用天然指向同一行)。旧形把任何 STREAM_PENDING 结果都当成「本次留下的
+                    // 孤儿」去收 VOID,于是本次超时放弃时会把**别人正在等的那张活卡**作废掉:真属主的 decideAsk
+                    // 随后干净地输,人的批准被吞成拒绝/延迟收敛。
+                    // 归属判据用现成数据:`createdAtMs` 是**插入者**写下的值,幂等命中时返回的是**先到者**的值。
+                    // 相等 ⇒ 这行是本次插的(才轮得到本次收尾);不等 ⇒ 幂等命中别人的行,一个字都不许动。
+                    // (残留:同一毫秒内的两次并发插入无法区分 —— ms 粒度的窄面,记在汇报存疑单。)
+                    lateEnsuredAskId = late.state === "STREAM_PENDING" && late.createdAtMs === attemptCreatedAtMs ? late.askId : undefined;
+                    if (abandonedEnsure && lateEnsuredAskId !== undefined)
+                        voidAbandonedRow(lateEnsuredAskId);
+                });
+                // 🔴 codex 交叉复审 round4 抓获(真 finding):`ensureAsk` 是幂等 upsert(approval-ask-machine.ts
+                // 顶注:「同参数元组——含重试/failover/闭包再入——永远派生同一个 id」)——同一确定性 askId 的重入
+                // 拿到的可能不是一条新鲜的 STREAM_PENDING 行,而是一条**早已终结**(或正在 PARKING/PARKED)的既有
+                // 行。裸忽略返回值、继续往下注册一条全新的本地待决,会让这只 ask 陷入一个永远赢不了 CAS 的死局:
+                // round2/round3 之后,三条竞争者对「干净地输」的响应统一是「什么都不做、信任真赢家」——但真赢家
+                // 是**过去**某次早已返回的 askBroadcast 调用,进程里已经没有任何存活的闭包会再驱动它 settle,
+                // TTL 到点时 expireAsk 对一条非 STREAM_PENDING 行同样只会干净地输,一样什么都不做——挂死到进程
+                // 重启。修法:行不是 STREAM_PENDING ⇒ 不重新挂卡,直接回放既有终局(不落 pending、不 emit)。
+                if (existingOrCreated.state !== "STREAM_PENDING") {
+                    releaseAdmission(); // X-2:回放既有终局 = 这只 ask 从未占用一条未决腿,名额立刻还回去
+                    return replayTerminalAskRow(existingOrCreated);
+                }
+                // 🔴 F2 修:行 = 真源。刚插的行上这三样与本地一致(采信是恒等操作);**重入**拿到既有行时,
+                // 采信才是唯一正确的做法 —— 帧、定时器、落库三处从此只有一个 deadline、一个 approvalId、一份卡。
+                // 🔴 codex 交叉复审 round2 R2-3(2026-08-06 真 finding):**信封与 deadline 是一个校验单元**。
+                // 旧形对 `safeParse` 失败「宽容降级」:留着本地新铸的 approvalId/card、却照样采信行上的
+                // `expires_at_ms` —— 于是同一条持久行会以**编造的** wire 身份上 wire(重放腿反而因为形不合把它
+                // 跳过),而车4 的回决端点按 askId 仍决得动它:人有可能照着一份**不是行上那份**的卡做授权。
+                // 采信行上一个**无界/非有限**的 deadline 同样危险:它会把 pending 条目与准入名额钉在那里远超配置窗。
+                // 裁:两样任一不合 ⇒ 不编造替身、不发帧,**fail-safe 走 park**(行本身交给对账收敛器处理)。
+                const persistedEnvelope = ApprovalCardEnvelopeSchema.safeParse(existingOrCreated.cardJson);
+                const sanePersistedDeadline = Number.isFinite(existingOrCreated.expiresAtMs) && existingOrCreated.expiresAtMs <= Date.now() + effectiveWindowMs + DURABLE_CALL_TIMEOUT_MS;
+                if (!persistedEnvelope.success || !sanePersistedDeadline) {
+                    this.noteStoreError(new Error(`persisted approval row is unusable (envelopeOk=${persistedEnvelope.success}, deadlineOk=${sanePersistedDeadline})`), "ensureAsk(persisted-row-unusable)");
+                    releaseAdmission();
+                    return "unavailable"; // park 路由;绝不用一个编造的身份把这张卡推上 wire
+                }
+                persistedExpiresAtMs = existingOrCreated.expiresAtMs;
+                wireApprovalId = persistedEnvelope.data.approvalId;
+                frame.approvalId = wireApprovalId; // 旧帧的去重键必须与新帧同值(两帧同带 approvalId 是消费端的对账口)
+                cardForFrame = persistedEnvelope.data.card;
+            }
+            catch (err) {
+                this.noteStoreError(err, "ensureAsk");
+                // 🔴 codex 交叉复审 round1 抓获(真 finding):ensureAsk 失败若放任 askId/batchId 留在场,下游
+                // decideAsk/expireAsk/transitionAsk 会对一个(疑似)不存在的行打 CAS——那不是「CAS 输」(某个真
+                // 竞争者已经决定了)而是「压根没有行」,但 round2 的「只在自己赢时才 settle」修正后,三条竞争者
+                // 现在对「干净地输」的响应统一是"什么都不做、信任真赢家"——若压根没有真赢家(行真的没落盘),
+                // 这只 ask 会被三方一致「谦让」到永远,直接违反 D5「裁决可用性不因店抖动而降级」。
+                // 🔴 codex 交叉复审 round2 追加抓获(真 finding,精化 round1 的修法):但反过来裸清空也不对——
+                // `SqlApprovalAskStore.ensureAsk` 与 `decideAsk` 同款「提交后另起一次独立 getAsk 读」形态
+                // (approval-ask-store-sql.ts:382-434),commit 可能已经真的成功、只是这次确认读断了——那种情形下
+                // 行其实已经落盘,裸清空会把一条真实存在的 STREAM_PENDING 行永久架空(未来任何 CAS 都不会再碰
+                // 它,只能靠车5 的恢复扫描兜底)。折中:失败后打一次防御性复核读——行确实存在(不论其当前状态)
+                // 就保留 askId/batchId(后续 CAS 仍有机会打中真行);复核读本身也失败、或行确实不存在,才降级成
+                // 「视同这只 ask 的 store 缺席」(D1 路径)。
+                // 🔴 车3 刀 3b(设计稿 §2.2(b)-3,改车2 的 D5「继续呈卡」臂):复核读要分**两种失败**。
+                //   ①「读成功、行不在」= **确定**的事实 ⇒ 降级成「视同 store 缺席」,活卡腿逐字照旧(D1 路径)——
+                //     这条腿早于本协议、不受「无持久身份不发新帧」约束,只是不发新帧、不落行。
+                //   ②「读本身也失败/超时」= **不确定** ⇒ 有界重试;耗尽仍不确定 ⇒ 返回 `"unavailable"` 走 park,
+                //     **不继续呈卡**。理由(§2.2(b)):在身份是否落盘都不知道的情况下继续收人决,与设计 §3.1
+                //     「身份**先持久化后**发帧」直接相悖 —— 人批了、行却可能不存在(或存在而无人对得上),
+                //     那是一次会凭空消失的批准。park 是这条路上唯一诚实的出路(人仍可经 durable gate 补批)。
+                let confirmedRowExists = false;
+                let indeterminate = true;
+                for (let attempt = 0; attempt <= DURABLE_CONVERGE_BACKOFF_MS.length; attempt++) {
+                    try {
+                        confirmedRowExists = (await this.withStoreDeadline(this.askStore.getAsk(askId), "getAsk(ensureAsk-confirm)")) !== null;
+                        indeterminate = false; // 读到了确定答案(在 / 不在),不必再试
+                        break;
+                    }
+                    catch (readErr) {
+                        this.noteStoreError(readErr, "getAsk(ensureAsk-confirm)");
+                        if (attempt < DURABLE_CONVERGE_BACKOFF_MS.length)
+                            await new Promise((r) => setTimeout(r, DURABLE_CONVERGE_BACKOFF_MS[attempt]).unref?.());
+                    }
+                }
+                if (indeterminate) {
+                    // 🔴 codex 交叉复审 F6(2026-08-06 真 finding):**必须**先登记「本地已放弃」再返回。
+                    // 这一臂是超时 —— 那笔 `ensureAsk` 完全可能**稍后才提交**,留下一条没有任何本地属主的
+                    // STREAM_PENDING 行(没有 pending 条目、没有定时器)。不登记的话 `onLateSuccess` 观测器看到
+                    // `abandonedEnsure === false` 就什么都不做,那条行会被孤儿腿代打 expire → PARKING → 被对账
+                    // 收敛器 PARK 出一张**幻影 gate**(工具其实早就按本地终局 park 掉了)。两个方向都覆盖:
+                    // 观测器已经先跑过 ⇒ 这里补收;还没跑 ⇒ 它稍后自己看到这个标志再收(与下面 D1 降级臂同形)。
+                    abandonedEnsure = true;
+                    if (lateEnsuredAskId !== undefined)
+                        voidAbandonedRow(lateEnsuredAskId);
+                    releaseAdmission(); // 名额还回去:这只 ask 从未真正进场(既没落 pending 也没建 timer)
+                    return "unavailable"; // park 路由(§2.2(b)-3);绝不在身份未定的情况下继续呈卡收人决
+                }
+                if (!confirmedRowExists) {
+                    askId = undefined;
+                    batchId = undefined;
+                    // R4-1:登记「本地已放弃」。迟到的 ensureAsk 若已经落盘(观测器先跑),这里补收;若还没落盘,
+                    // 观测器稍后自己看到这个标志再收。两个方向都覆盖,不依赖谁先谁后。
+                    abandonedEnsure = true;
+                    if (lateEnsuredAskId !== undefined)
+                        voidAbandonedRow(lateEnsuredAskId);
+                }
+            }
+        }
         let done = false;
         let emitFailed = false;
         let emitSettled = false;
+        // #151 车2(D2 窗到期竞争者的返回值覆盖):askStore 在场且 expireAsk 赢 CAS ⇒ 强制返回 "unavailable"
+        // (park 路由,G1 回路)——与旧形的 emit-race 覆盖判据(!emitSettled && lastOutcome==="expired")并存,
+        // 互不排斥(见方法尾的返回值分派)。askStore 缺席时恒 false,不影响 D1 零行为变化。
+        let windowRouteUnavailable = false;
         let timer;
         let resolveAllowed;
         const allowedP = new Promise((resolve) => { resolveAllowed = resolve; });
         let lastOutcome = "expired";
         const abortListeners = [];
+        // #151 车2(round5 精化):`pendingEntry`(下方构造,携带 `settle` 本身)构造之前,`settle` 闭包已经
+        // 需要引用它自己在 {@link pendingByAskId} 那个 Set 里的身份,用来在结算时把自己摘出去——先立一个
+        // 稍后才赋值的引用格(鸡生蛋:settle 是 pendingEntry 的一个字段,pendingEntry 建好之后才能把它自己
+        // 塞进这个引用里)。
+        let selfEntry;
         const settle = (allowed, outcome, updatedInput) => {
             if (done)
                 return;
@@ -261,13 +917,188 @@ export class ToolApprovalCoordinator {
             for (const [sig, fn] of abortListeners)
                 sig.removeEventListener("abort", fn);
             this.pending.delete(id);
+            // #151 车2(round3 兄弟撤卡索引 + round5 精化成 Set,顶注):把自己从同 askId 的集合里摘除——集合
+            // 可能还有其他条目(批内兄弟、或同 askId 的重复本地注册),它们的存亡与自己的结算无关。
+            if (askId !== undefined) {
+                const siblings = this.pendingByAskId.get(askId);
+                if (siblings && selfEntry) {
+                    siblings.delete(selfEntry);
+                    if (siblings.size === 0)
+                        this.pendingByAskId.delete(askId);
+                }
+            }
             lastOutcome = outcome;
+            releaseAdmission(); // X-2:落定即释放名额(幂等;settle 本身已由 `done` 去重)
+            if (selfEntry)
+                selfEntry.settledOutcome = outcome; // 车5:供 respondWithCas 判「有效终局是不是这次回决」
             resolveAllowed({ allowed, ...(allowed && updatedInput !== undefined ? { updatedInput } : {}) });
         };
-        timer = setTimeout(() => settle(false, "expired"), this.ttlMs);
+        // #151 车2(D2 窗到期竞争者):askStore 缺席 ⇒ settle(false,"expired") 逐字不变(D1)。在场 ⇒ settle
+        // 前先赢一把 expireAsk CAS——赢 ⇒ settle 之余把终局强制改判 "unavailable"(windowRouteUnavailable);
+        // 输 ⇒ 人已决(或即将由回决腿落定),这里什么都不做,交 done 标志兜底。⚠️ store CAS 是 async 而 settle
+        // 是 sync,TTL 定时器回调因此变 async(void IIFE 包裹,内部 catch 全部错误按 D5 fail-open 处置)。
+        /**
+         * #151 车5(design/172 §4 状态感知分派表 = 车3 §14 X-1 裁定②的实施件;车5 稿 §8 D-1.2):
+         * **CAS 干净地输之后,重读持久态并按真实终局收敛**——取代此前的「什么都不做、信任真赢家」。
+         *
+         * 🔴 为什么必须改:「信任真赢家」在**单进程**里成立(赢家是本进程另一条闭包,它会 settle 我),在
+         * 跨副本/收敛器上线后**不成立**——赢家可能是另一个副本的回决端点,或本车的 reaper 收敛器。那条
+         * 路径压根不认识本进程的 pending 条目,本地闭包于是永远等不到任何事件:HTTP 200 而持卡腿永挂
+         * (X-1 契约明令排除的那个形)。收敛器上线前必须先落这一段,否则本车自己制造挂死面。
+         *
+         * 映射复用 {@link replayTerminalAskRow}(**同一套 settle 语义,不造第二套**):
+         *   `DECIDED` ⇒ 真决议(approve ⇒ allowed / deny ⇒ denied);
+         *   `PARKING|PARKED` ⇒ park 路由(`"unavailable"`,与窗到期赢家的终局同义,幂等);
+         *   `DENIED|VOID` ⇒ deny。
+         * 行读不出(店抖动)⇒ **有界重试**(指数退避,期间随时被真赢家 settle 就退出),用尽仍失败 ⇒
+         * D5 fail-open 退回纯进程内语义(`settle(false,"expired")`)——绝不无限等。
+         */
+        const convergeFromDurableState = async (where) => {
+            if (!this.askStore || askId === undefined)
+                return;
+            const store = this.askStore;
+            const pinnedAskId = askId;
+            for (let attempt = 0; attempt < DURABLE_CONVERGE_BACKOFF_MS.length; attempt++) {
+                if (done)
+                    return; // 真赢家已经在本进程里落定了终局——无事可做(幂等)
+                try {
+                    // 每次读都带墙钟 deadline(见 DURABLE_CONVERGE_READ_TIMEOUT_MS 顶注):挂住的读不许吃掉整个
+                    // 退避预算。超时抛进下面的 catch,与「读失败」同一条路(退避 → 用尽 → fail-open)。
+                    const row = await this.withStoreDeadline(store.getAsk(pinnedAskId), `getAsk(${where})`, DURABLE_CONVERGE_READ_TIMEOUT_MS);
+                    if (done)
+                        return;
+                    if (row === null) {
+                        // 行不在(被 deleteByTask 清过 / 从未落盘)——没有可信终局可读,退回进程内语义。
+                        settle(false, "expired");
+                        return;
+                    }
+                    if (row.state === "STREAM_PENDING") {
+                        // 竞争者 CAS 输、行却还是 STREAM_PENDING:只可能是刚才那一瞬别人先赢又被回滚一类的窄窗
+                        // (或 batchId 错配导致的 expireAsk 不赢)。退避后再读一次,不在这里替它编造终局。
+                        await new Promise((r) => setTimeout(r, DURABLE_CONVERGE_BACKOFF_MS[attempt]).unref?.());
+                        continue;
+                    }
+                    const outcome = replayTerminalAskRow(row);
+                    if (outcome === "unavailable") {
+                        windowRouteUnavailable = true; // park 语义 ⇒ onAsk 交 "unavailable"(G1 回路)
+                        settle(false, "expired");
+                    }
+                    else if (outcome === true) {
+                        settle(true, "allowed");
+                    }
+                    else {
+                        settle(false, "denied");
+                    }
+                    return;
+                }
+                catch (err) {
+                    this.noteStoreError(err, `getAsk(${where})`);
+                    await new Promise((r) => setTimeout(r, DURABLE_CONVERGE_BACKOFF_MS[attempt]).unref?.());
+                }
+            }
+            if (!done)
+                settle(false, "expired"); // 重试用尽:D5 fail-open,绝不挂死
+        };
+        const windowExpired = () => {
+            void (async () => {
+                if (!this.askStore || askId === undefined || batchId === undefined) {
+                    settle(false, "expired");
+                    return;
+                }
+                try {
+                    const res = await this.withStoreDeadline(this.askStore.expireAsk(askId, batchId), "expireAsk(window)", DURABLE_CALL_TIMEOUT_MS, (late) => {
+                        // R3-1 迟到成功:本地终局已由下面的 catch 落定(幂等,不改写),但**兄弟的结算与撤卡帧**
+                        // 是这次事务真做出来的事实,必须补做 —— 否则兄弟闭包挂死、壳上留一张已作废的卡。
+                        if (!late.won)
+                            return;
+                        this.settleVoidedSiblings([askId, ...late.voidedSiblings]);
+                        this.emitRevokeTo(aliveCtxs, buildRevokeFrame(batchId, late.voidedSiblings, "superseded_by_park", Date.now()));
+                    });
+                    if (res.won) {
+                        windowRouteUnavailable = true;
+                        settle(false, "expired");
+                        // round3:同批兄弟被远程撤卡,本地同步收尾;round5 追加自己的 askId——覆盖「同 askId 重复本地
+                        // 注册」那一支(顶注,settleVoidedSiblings 对已经结算过的自己天然是无操作)。
+                        this.settleVoidedSiblings([askId, ...res.voidedSiblings]);
+                        // #151 车6 发射点①:降级连坐的兄弟被原子撤卡 ⇒ 壳上那些卡必须消失(live only)。
+                        this.emitRevokeTo(aliveCtxs, buildRevokeFrame(batchId, res.voidedSiblings, "superseded_by_park", Date.now()));
+                    }
+                    else {
+                        // 干净地输 ⇒ 重读持久态收敛(X-1;见 convergeFromDurableState 顶注)。
+                        await convergeFromDurableState("windowExpired");
+                    }
+                }
+                catch (err) {
+                    this.noteStoreError(err, "expireAsk");
+                    // R3-1:**超时**与「店报错」的诚实处置方向不同。超时 = 不知道那次 `expireAsk` 做没做成 ——
+                    // 若它稍后提交,行就是 PARKING(已转投递面);此时把 onAsk 判成 deny 会与持久真源矛盾,而且
+                    // 违反 §3.3「窗不得把一个可 park 的 ask 拖成 abort-deny」。交 `"unavailable"`(park 路由)对
+                    // 两种结局都成立:真提交了 ⇒ 与行一致;没提交 ⇒ core 自己走 durable park,不劣于 deny。
+                    if (err instanceof ApprovalStoreDeadlineError)
+                        windowRouteUnavailable = true;
+                    settle(false, "expired"); // fail-open(D5):店抖动不挡窗到期的进程内机械照旧完成
+                }
+            })();
+        };
+        // F2 修:定时器量的是**行上那个绝对 deadline** 的剩余时长(重入拿到既有行时,剩余时长比一整个窗短
+        // —— 旧形会给一条早就该到期的行重新挂一个满窗的表)。store 缺席时逐字沿用 `effectiveWindowMs`(D1)。
+        timer = setTimeout(windowExpired, this.askStore ? Math.max(0, persistedExpiresAtMs - Date.now()) : effectiveWindowMs);
         timer.unref?.();
+        // #151 车2(D2 取消竞争者:task signal abort / 连接全灭同路):askStore 缺席 ⇒ settle(false,
+        // "expired") 逐字不变(D1)。在场 ⇒ settle 前先打一把 transitionAsk(STREAM_PENDING→VOID)CAS。
+        // 🔴 codex 交叉复审 round2 抓获(真 finding,与 D2 原文「赢输都照旧 settle」的字面不同——属主已认领
+        // 的、以「验真优先于不重议」为准的偏离,理由如下):store 各方法的网络往返跳数并不对称——SQL 双方言
+        // 实现里 `decideAsk` 在提交事务后**另起一次独立的 `getAsk` 读**才返回(`approval-ask-store-sql.ts`
+        // :382-434/456-499),而 `transitionAsk` 直接把 UPDATE 的 affected-rows 当结果返回,少一整跳。若取消
+        // 臂真照 D2 字面「赢输都 settle」,在人类回决(`respond`)已经**赢下持久 CAS**、但它自己较慢的第二跳
+        // 还没落地时,取消臂会用一个在 CAS 层面已经**输了**的 transitionAsk 结果抢先把本地终局锁成 false 并
+        // 删掉 pending 条目——回决那边随后真正拿到 `ok:true` 时,`respondWithCas` 的 entry 存活性复核(下方)
+        // 只能如实 404:durable 行写着人已批准,活的终局却是拒绝,自相矛盾。改判:**只在自己真赢时才
+        // settle**;干净地输(transitionAsk 返回 false,不是 throw)⇒ 什么都不做,信任真赢家走它自己的路径
+        // 完成 settle(与 windowExpired 的「输 ⇒ 什么都不做」同精神,两条路径现在对称)。throw(店真的挂了,
+        // 不是「CAS 输」而是「不知道」)仍走 D5 fail-open:退化回 D1 的纯进程内语义,无条件 settle。
+        // #151 车2(codex round4 抓获,真 finding,精化):`runCancel` 改成**可 await 的**async 函数(不再是
+        // void-返回的 fire-and-forget 包装)——事件监听器(下方 `onTaskAbort`/`onTargetGone`)仍然只是
+        // `void runCancel()` 触发它、不等结果(它们是真正的"未来事件"回调,没有调用方在等);但下面的
+        // 「ensureAsk 挂起期间错过的 abort」复核**需要真等它跑完**才能知道是否该在注册/emit 之前就短路收尾
+        // (见复核处的顶注)——这是 round4 finding 1 的直接修复点,round3 的 fire-and-forget 形只触发了取消,
+        // 却让函数继续往下注册/广播一张其实已经作废的卡。
+        const runCancel = async () => {
+            if (!this.askStore || askId === undefined || batchId === undefined) {
+                settle(false, "expired"); // D1:现行为逐字不变
+                return;
+            }
+            try {
+                const won = await this.withStoreDeadline(this.askStore.transitionAsk(askId, "STREAM_PENDING", "VOID", { updatedAtMs: Date.now() }), "transitionAsk(cancel)", DURABLE_CALL_TIMEOUT_MS, (lateWon) => {
+                    if (!lateWon)
+                        return; // R3-1 迟到成功:补做撤卡收尾(本地终局由 catch 落定,幂等)
+                    this.settleVoidedSiblings([askId]);
+                    this.emitRevokeTo(aliveCtxs, buildRevokeFrame(batchId, [askId], "aborted", Date.now()));
+                });
+                if (won) {
+                    settle(false, "expired");
+                    // round5:transitionAsk 不携带 voidedSiblings(批级撤卡只是 expireAsk 的副作用),但「同 askId
+                    // 重复本地注册」那一支(pendingByAskId 顶注)与竞争者种类无关,取消赢下 CAS 时同样要收尾。
+                    this.settleVoidedSiblings([askId]);
+                    // #151 车6 发射点②:取消 ⇒ 本行已 VOID,壳上这张卡必须消失(reason="aborted")。
+                    // 🔴 名单是**这一行自己**,不是「本批全体」:`abortBatch`(整批 STREAM_PENDING→VOID)在本仓
+                    // 今天没有任何调用点(grep 实证,车2/车4 域),取消腿走的是单行 `transitionAsk`。兄弟各自的
+                    // 闭包会走它们自己的这条路径、各发各的撤卡帧;真正的整批名单形要等 `abortBatch` 接线后才成立
+                    // (登记在本车汇报的偏离单里,不在这里凭空造一个不存在的名单)。
+                    this.emitRevokeTo(aliveCtxs, buildRevokeFrame(batchId, [askId], "aborted", Date.now()));
+                }
+                else {
+                    // 干净地输 ⇒ 重读持久态收敛(X-1;与窗到期臂同一条路径,见 convergeFromDurableState 顶注)。
+                    await convergeFromDurableState("runCancel");
+                }
+            }
+            catch (err) {
+                this.noteStoreError(err, "transitionAsk(cancel)");
+                settle(false, "expired"); // fail-open(D5)
+            }
+        };
         if (signal) {
-            const onTaskAbort = () => settle(false, "expired");
+            const onTaskAbort = () => void runCancel();
             signal.addEventListener("abort", onTaskAbort, { once: true });
             abortListeners.push([signal, onTaskAbort]);
         }
@@ -282,7 +1113,7 @@ export class ToolApprovalCoordinator {
         // 必然关系——一条完全不相关、只是恰好也在同一 (owner,session) 广播集合里的连接,处理完它自己另一个
         // 无关的请求正常退出,就会单独触发把整条 ask 误杀,即便真正在等它的那条连接分毫未动、仍然存活。
         // `goneCtxs` 去重:同一个 ctx 理论上可能同时/先后触发 (a)(b) 两条路径(abort 通常伴随其作用域跟着
-        // 退出),避免重复扣减。
+        // 退出),避免重复扣减。#151 车2:归零判死改走 runCancel(D2 取消竞争者,同 task-signal abort 同路)。
         let liveConnections = aliveCtxs.length;
         const goneCtxs = new Set();
         const onTargetGone = (c) => {
@@ -291,7 +1122,7 @@ export class ToolApprovalCoordinator {
             goneCtxs.add(c);
             liveConnections--;
             if (liveConnections <= 0)
-                settle(false, "expired");
+                void runCancel();
         };
         for (const c of aliveCtxs) {
             if (!c.abortSignal)
@@ -300,12 +1131,38 @@ export class ToolApprovalCoordinator {
             c.abortSignal.addEventListener("abort", onCtxAbort, { once: true });
             abortListeners.push([c.abortSignal, onCtxAbort]);
         }
+        // 🔴 codex 交叉复审 round3 抓获、round4 精化(真 finding):上面两组监听器都装在 ensureAsk 的 await
+        // 之后(askStore 在场时那是一个真实的挂起点)——`AbortSignal` 不会给「事件发生之后才装上」的监听器
+        // 补放已经错过的那次 abort。若取消恰好发生在 ensureAsk 挂起期间(店慢),这次取消会被彻底吞掉,直到
+        // 自己的 TTL 才收尾。监听器装完后立即补一次「是不是已经在等待期间触发过」的复核——**必须真等它跑完**
+        // (round3 的 fire-and-forget 形只触发了取消,却让函数继续往下注册/广播一张其实已经作废的卡:respond()
+        // 稍后如果撞上这条已经 settle 过的僵尸 entry,会经同步 `finishRespond` 分支应答成功并可能误记
+        // `allowAllSessions`——`finishRespond` 对"是否已经 settle 过"没有重新核验,round1 那道存活性复核只
+        // 长在 `respondWithCas` 的异步分支里)。等它跑完后若 `done` 已经为真,直接短路返回,绝不再往下注册/
+        // emit——askStore 缺席时整段函数体到这里为止零 await,`earlyAbortDuringEnsure` 恒假,对 D1 零行为
+        // 变化。
+        const earlyAbortDuringEnsure = signal?.aborted === true || aliveCtxs.some((c) => c.abortSignal?.aborted === true);
+        if (earlyAbortDuringEnsure) {
+            await runCancel();
+            // 🔴 #151 车5 自查(属主亲读 diff 抓获,2026-08-06):这里**不能**再写死 `return false`。
+            // 旧形那句注释「取消恒 settle(false,"expired")」在 X-1 状态感知分派之前成立;现在 `runCancel` 的
+            // CAS 输臂会重读持久态并按**真决议**结算 —— 一条在 ensureAsk 悬挂期间被别的副本 approve 掉的 ask,
+            // `done` 为真而落定值是 `true`,写死 false 会把一次真实的人类批准悄悄吞成拒绝(且与 durable 行矛盾)。
+            // 改成把**已经落定的那个值**如实交回去(与方法尾部的返回值分派同一套判据)。
+            if (done) {
+                const early = await allowedP;
+                if (windowRouteUnavailable)
+                    return "unavailable"; // 持久终局是 PARKING/PARKED ⇒ park 路由
+                if (early.allowed && early.updatedInput !== undefined)
+                    return { allow: true, updatedInput: early.updatedInput };
+                return early.allowed;
+            }
+        }
         // Register BEFORE emitting so a (fast) respond can never miss the entry. 子代 ask 的生存期挂子代
         // (originTaskId 在场 = 不被宿主 finally 清扫烧;[1539] 注意事项,判别式 = isChildAsk 顶注)——同理,
         // 子代 ask 从不设 targetCtxs/onTargetGone(任何宿主 ctx 的 runWithContext 退出都不该碰它,只有它
         // 自己的 TTL/abortSignal 才作数;上面的 aliveCtxs abort 倒计时仍照常适用于它自己的连接级 abort)。
-        const child = isChildAsk(req);
-        this.pending.set(id, {
+        const pendingEntry = {
             settle,
             owner: primary.owner,
             ctxTaskId: primary.taskId,
@@ -313,49 +1170,70 @@ export class ToolApprovalCoordinator {
             ...(child ? { originTaskId: req.sourceTaskId } : { targetCtxs: new Set(aliveCtxs), onTargetGone }),
             ...(primary.sessionId ? { sessionId: primary.sessionId } : {}),
             toolName: req.toolName,
-        });
-        const bounded = boundArgs(req.args);
-        const frame = {
-            type: "tool_approval",
-            approvalId: id,
-            toolName: req.toolName,
-            // [1939]:core 的 tool-call id 逐字透传(AskRequest.toolCallId 是必填);理由见字段顶注。
-            ...(typeof req.toolCallId === "string" && req.toolCallId !== "" ? { toolCallId: req.toolCallId } : {}),
-            // 帧上 sourceTaskId/fromSubagent/sourceAgentName 只出**子代** ask(server 侧判别收口,现判别
-            // 键 = req.fromSubagent[core RB-39② 显式受信键]——sourceTaskId 仍旁随传但不再是判别式,复审
-            // F2 案:core 对宿主 ask 也恒填 sourceTaskId=宿主 sessionId,裸透传会让每张宿主卡被误判子代)。
-            ...(child
-                ? {
-                    sourceTaskId: req.sourceTaskId,
-                    fromSubagent: true,
-                    ...(typeof req.sourceAgentName === "string" ? { sourceAgentName: redactSecrets(req.sourceAgentName) } : {}),
-                    // core 5.9.0 W1:出处链透传(agentName 同 sourceAgentName 待遇 redact;其余为 core-mint 标识非内容)。
-                    ...(req.delegation
-                        ? {
-                            delegation: {
-                                parentToolCallId: req.delegation.parentToolCallId,
-                                depth: req.delegation.depth,
-                                ...(typeof req.delegation.agentName === "string" ? { agentName: redactSecrets(req.delegation.agentName) } : {}),
-                            },
-                        }
-                        : {}),
-                }
-                : {}),
-            message: typeof req.message === "string" ? redactDeep(req.message) : "",
-            ...(bounded.omitted ? { argsOmitted: true } : { args: bounded.args }),
+            ...(askId !== undefined && batchId !== undefined ? { askId, batchId } : {}),
         };
+        selfEntry = pendingEntry; // 供 settle() 结算时把自己从 pendingByAskId 的 Set 里摘除(上方顶注)
+        this.pending.set(id, pendingEntry);
+        // #151 车2(round3 兄弟撤卡索引 + round5 精化成 Set,顶注):同一 askId 下可能已经有其他条目在场
+        // (批内兄弟、或同 askId 的重复本地注册)——这里是 add 进集合,不是覆盖单值。
+        if (askId !== undefined) {
+            let siblings = this.pendingByAskId.get(askId);
+            if (!siblings) {
+                siblings = new Set();
+                this.pendingByAskId.set(askId, siblings);
+            }
+            siblings.add(pendingEntry);
+        }
         // 每路 emit 独立兜底(catch 而非任其抛出/reject 冒泡)——一路失败不拖垮整个广播的判定;`emitOne`
         // 因此**永不** reject(同时吸收同步 throw 与异步 rejection),`Promise.all` 也就永不 reject,
         // 下面的 `Promise.race` 才能安全地把它当"正常完成"的一端,不会把某一路的失败错误地冒泡成
         // askBroadcast 自身的未捕获异常。
+        // #151 车3 刀 3b(设计稿 §4.1/§4.2):呈卡帧 —— **并行加帧,不替换**。
+        //  · 只有拿到**确认落盘**的 `askId` 才铸(§2.2(b) 硬条款一:无持久身份不发新帧)⇒ 开关关 / store 缺席 /
+        //    ensureAsk 降级三种情形下恒 `undefined`,wire 字节逐字不变(A-1)。
+        //  · `expiresAtMs` 用上面**一次铸定**的那个数(与落库同值),`expiresInMs` 由它现算。
+        const cardFrame = askId !== undefined && cardForFrame !== undefined
+            ? buildApprovalRequestFrame({ askId, taskId: origin.taskId, approvalId: wireApprovalId, card: cardForFrame, expiresAtMs: persistedExpiresAtMs, nowMs: Date.now() })
+            : undefined;
+        /**
+         * 一条连接的**两种**投递结果。分开记是 codex 交叉复审 F1(2026-08-06 真 finding)的修:
+         *  · `legacy` —— 旧 `tool_approval` 帧送达没有。它单独决定**闭合帧**发不发(没见过开卡帧的连接
+         *    收到一个 `tool_approval_complete` 就是孤儿 close),也是存量壳能否 `respond` 的前提。
+         *  · `card` —— 新 `approval_request` 帧送达没有。它同样算「卡送到人手上了」:detach 车道正是
+         *    **旧帧必失败、新帧走 durable 账本必成功**的形,旧形只数旧帧 ⇒ `anySucceeded=false` ⇒
+         *    `expireAsk` 赢 ⇒ 行被改判 PARKING、`onAsk` 交 `"unavailable"` —— 而消费端手上明明已经拿到
+         *    一张说自己未决的卡,且它带着可回决的 `askId`(车4 端点)。
+         * 「emit 全灭」因此是**两条都没送到**,不是「旧帧没送到」。
+         */
         const emitOne = async (c) => {
+            let delivered = true;
             try {
                 await c.emit(frame);
-                return true;
             }
             catch {
-                return false;
+                delivered = false;
+            }
+            // 🔴 发射序钉死:旧帧在前、新帧在后(§4.2)—— 旧壳的字节流与今天逐字一致,新壳按 `approvalId` 去重
+            // 后优先渲染新帧。**per-连接**串行(排在这条连接自己的旧帧之后),与下面 complete 帧的 per-ctx 排序
+            // 同一条不变式。
+            //
+            // 两条判据都是有意的:
+            //  · 旧帧**失败也照样试新帧** —— 新帧的投递口在 detach 车道上是「live + durable 账本双写」
+            //    (routes/tasks.ts),而那条车道的 live 面**恰恰是死的**;若这里跟着旧帧一起早退,§4.3(c) 要修的
+            //    「断连 ⇒ 卡永久不可见」正好一次都不会被修到。
+            //  · 新帧的成败**不参与** `delivered` —— 「卡有没有送达一个人」这条判断归旧帧(它是存量壳唯一认得的
+            //    那一帧,也是 `respond` 的入口)。把新帧的失败算进去会误触 emit-全灭那条 `"unavailable"` 臂。
+            let cardDelivered = false;
+            if (cardFrame && c.emitCard) {
+                try {
+                    await c.emitCard(cardFrame);
+                    cardDelivered = true;
+                }
+                catch {
+                    /* 投不出去就是没送到;它不影响旧帧那半边的判定 */
+                }
             }
+            return { legacy: delivered, card: cardDelivered };
         };
         // 🔴 [1575] F2 修(cli 复查,红先行确认真红):旧形完成帧广播是"调用序"跟着 `await allowedP`
         // 走,不是"落盘序"——respond() 可能在某条连接自己的 OPEN emit 尚未落盘完成时就已经 settle(TTL/
@@ -369,13 +1247,45 @@ export class ToolApprovalCoordinator {
         const openByCtx = new Map(aliveCtxs.map((c) => [c, emitOne(c)]));
         const emitAllP = (async () => {
             const results = await Promise.all(openByCtx.values());
-            const anySucceeded = results.some(Boolean);
+            // F1 修:**两种帧任一送达**都算「卡送到人手上了」(见 emitOne 顶注)。
+            const anySucceeded = results.some((r) => r.legacy || r.card);
             // ⚠️ 竞态门(cross-review 抓获,原单连接形已有的不变式,广播形延续):respond/abort 可能在 emit
             // 广播完成前已经 settle(entry 先于 emit 注册)。emit 随后才判定全灭时,已有的人类 boolean 裁决/
             // abort 终局必须保持——只有本判定是第一个 settle 者(done 仍 false)才算「卡从未送达任何人」。
             if (!anySucceeded && !done) {
-                emitFailed = true;
-                settle(false, "expired");
+                // 🔴 codex 交叉复审两轮抓获(真 finding,红先复现 [tool-approval-machine.test.ts §3 4/8 emit-race
+                // 用例];round2 精化):`emitFailed` 不能在 store 调用的 await 之前置位(round1 已修),但仅补一个
+                // `!done` 复核仍不够严——`expireAsk` 与 `decideAsk` 的网络往返跳数不对称(`decideAsk` 提交后另起
+                // 一次独立 `getAsk` 读,`expireAsk` 没有,approval-ask-store-sql.ts:382-434/456-499),respond() 可能
+                // 已经**赢下**持久 CAS 但它自己较慢的第二跳尚未落地、本地 `done` 仍是 false——此时 `expireAsk`
+                // 干净地**输**(`res.won===false`,不是 throw),若仍然只看 `!done` 就置位 `emitFailed`,会重演
+                // round2 finding A 同款矛盾(durable 行写着已批准,活的终局却被 emit-全灭强改成
+                // "unavailable")。改判:**只在 `res.won===true` 时才置位 settle**;干净地输 ⇒ 什么都不做,信任
+                // 真赢家走它自己的路径完成 settle(与 windowExpired/runCancel 现在同一形状)。throw(店真的挂了)
+                // 仍走 D5 fail-open,保留 `!done` 保险(避免明知已经有人赢了还去无条件覆盖)。
+                if (this.askStore && askId !== undefined && batchId !== undefined) {
+                    try {
+                        const res = await this.withStoreDeadline(this.askStore.expireAsk(askId, batchId), "expireAsk(emit-failed)");
+                        if (res.won && !done) {
+                            emitFailed = true;
+                            settle(false, "expired");
+                            // round3:同批兄弟被远程撤卡,本地同步收尾;round5 追加自己的 askId(同精神,windowExpired 侧注)。
+                            this.settleVoidedSiblings([askId, ...res.voidedSiblings]);
+                        }
+                        // 干净地输:什么都不做(见上方顶注)。
+                    }
+                    catch (err) {
+                        this.noteStoreError(err, "expireAsk(emit-failed)");
+                        if (!done) {
+                            emitFailed = true;
+                            settle(false, "expired"); // fail-open(D5)
+                        }
+                    }
+                }
+                else if (!done) {
+                    emitFailed = true;
+                    settle(false, "expired"); // D1:现行为逐字不变(store 缺席)
+                }
             }
             emitSettled = true;
         })();
@@ -394,13 +1304,20 @@ export class ToolApprovalCoordinator {
         for (const c of aliveCtxs) {
             void openByCtx
                 .get(c)
-                .then((delivered) => (delivered ? c.emit({ type: "tool_approval_complete", approvalId: id, outcome: lastOutcome }) : undefined))
+                // F1 修:闭合帧的门仍**只看旧帧**(`legacy`)—— 它按 `approvalId` 消卡,只有见过开卡帧的连接才有
+                // 卡可消;拿新帧的成功去放行闭合帧会给只收到 `approval_request` 的连接发一个孤儿 close。
+                .then((delivered) => (delivered.legacy ? c.emit({ type: "tool_approval_complete", approvalId: wireApprovalId, outcome: lastOutcome }) : undefined))
                 .catch(() => undefined);
         }
         // emit 全灭 = 卡从未送达任何人(≠人拒绝/TTL 走人)——同属「无活人可达」类 ⇒ "unavailable" 交 durable
         // park。
         if (emitFailed)
             return "unavailable";
+        // #151 车2(D2/D3):窗到期赢了持久 CAS ⇒ 强制 park 路由,不看 emit 是否已经确认送达——D2 原话
+        // 「赢 ⇒ settle + onAsk 返回 "unavailable"」是无条件的,与下面 emit-race 覆盖判据(供 store 缺席/
+        // emit 尚未确认两种场景)并存、互不排斥。askStore 缺席时本判据恒 false,不影响 D1 零行为变化。
+        if (windowRouteUnavailable)
+            return "unavailable";
         // emit 广播尚未有任何一路确认完成(既非成功也非已知失败)就被 TTL/abort 抢先判定 ⇒ 无法确认卡是否
         // 曾送达任何人,不可扣一个武断的「deny」终局——按 G1 回路交 "unavailable"(同 emit 失败同一处置,
         // core [1559]三 确认方向)。respond() 落地的人类裁决(outcome allowed/denied)不受影响,原因见本
@@ -417,7 +1334,12 @@ export class ToolApprovalCoordinator {
     }
     /** `POST /v1/tool-approvals/:id/respond` — settle a parked approval with the shell's decision. Owner-gated with a
      *  404 (no existence oracle), body validated first (400 is existence-independent) — question/steer parity. The HTTP
-     *  layer owns auth (gatedPrincipal + REQUIRE_PRINCIPAL) before calling. */
+     *  layer owns auth (gatedPrincipal + REQUIRE_PRINCIPAL) before calling.
+     *
+     *  #151 车2(D1/D2):return type 是 UNION,不是把整个方法标 `async`——askStore 缺席时这个方法逐字同步
+     *  完成(D1 现行为不变;现存量测试对它的同步断言/`void` 调用零改动)。在场时才真的变成 Promise(D2 的
+     *  「settle 前先赢一把 decideAsk CAS」离不开 await,同步函数做不到)。唯一生产调用点(`routes/runs.ts`)
+     *  统一 `await`——`await` 对非 Promise 值是恒等操作,两条路径对它透明。 */
     respond(id, principal, body) {
         const parsed = parseToolApprovalResponse(body);
         if (!parsed.ok)
@@ -426,6 +1348,93 @@ export class ToolApprovalCoordinator {
         if (!entry || (entry.owner !== null && entry.owner !== principal)) {
             return { status: 404, body: { error: "no pending tool approval for this id (settled, expired, or not on this replica)", errorCode: "tool_approval.not_pending" } };
         }
+        // #151 车2 D2(回决竞争者):askStore 缺席 ⇒ finishRespond 同步收尾,逐字不变(D1)。在场 ⇒ 先打一把
+        // decideAsk CAS,赢了才 finishRespond;输(某个其他竞争者已经决定了这只 ask 的终局)⇒ 不 settle,照旧
+        // 回现有 404 形(响应体的 409/410 分化是车4 的活,本车只保证「输者绝不覆盖赢者」)。
+        if (this.askStore && entry.askId !== undefined && entry.batchId !== undefined) {
+            return this.respondWithCas(this.askStore, entry.askId, entry.batchId, id, entry, parsed);
+        }
+        return this.finishRespond(id, entry, parsed);
+    }
+    /** store 在场时的回决 CAS 门(D2)——`respond()` 的异步分支,拆出以保持 `respond()` 本身在 store 缺席
+     *  时仍是纯同步函数(D1)。`askStore`/`askId`/`batchId` 由调用方在已窄化的分支里传入(避免非空断言）。 */
+    async respondWithCas(askStore, askId, batchId, id, entry, parsed) {
+        let decidedWon = false;
+        try {
+            const decided = await this.withStoreDeadline(askStore.decideAsk(askId, batchId, { decision: parsed.value === "deny" ? "deny" : "approve" }), "decideAsk", DURABLE_CALL_TIMEOUT_MS, (late) => {
+                // R3-1 迟到成功:HTTP 响应早已发出(这次调用报的是超时),但**决议真落了盘** —— 同 askId 下
+                // 还在悬挂的本地条目必须按真决议结清,否则它们只能等自己的窗/取消再绕一圈。
+                if (late.ok)
+                    this.notifyExternalDecision(askId, parsed.value !== "deny", parsed.updatedInput);
+            });
+            decidedWon = decided.ok;
+            if (!decided.ok) {
+                // CAS 输——respond 绝不覆盖赢家(D2)。逐字复用现行 404 形(409/410 分化留给车4)。
+                return { status: 404, body: { error: "no pending tool approval for this id (settled, expired, or not on this replica)", errorCode: "tool_approval.not_pending" } };
+            }
+        }
+        catch (err) {
+            this.noteStoreError(err, "decideAsk"); // D5 fail-open:店抖动不挡真实回决
+            // 🔴 codex 交叉复审 C6(2026-08-06 真缺陷):`decideAsk` 的 SQL twin 是「commit 之后**另起**一次
+            // `getAsk` 读」的形状 —— 那一跳抛错时,事务**可能已经提交**(人的决定真落了盘),而这里的
+            // `decidedWon` 却还是 false。这种「不知道」如果直接当成「没赢」,下面的守卫会对一个**已经生效**的
+            // 决定回 404。补一次**有界**的复核读:行已是 `DECIDED` 且决议与本次请求逐字一致 ⇒ 就是我们赢的
+            // (`decideAsk` 的 CAS 是单赢者,别人不可能写出同一条决议再让我们看见——除非是同一个请求的重试,
+            // 那本就该回放成功)。复核读本身失败/超时 ⇒ 维持「不知道」,守卫照旧 404(不许把未知说成成功)。
+            try {
+                const row = await this.withStoreDeadline(askStore.getAsk(askId), "getAsk(decideAsk-confirm)", DURABLE_CONVERGE_READ_TIMEOUT_MS);
+                if (row?.state === "DECIDED" && row.decision === (parsed.value === "deny" ? "deny" : "approve"))
+                    decidedWon = true;
+            }
+            catch (confirmErr) {
+                this.noteStoreError(confirmErr, "getAsk(decideAsk-confirm)");
+            }
+        }
+        // 🔴 codex 交叉复审抓获(真 finding):`decideAsk` throw(店抖动、非 CAS 输)时上面完全没有 return——
+        // 两个真正并发的 respond() 调用若都撞上这次抖动,会都揣着同一个(尚未被任何一方 settle 过的)`entry`
+        // 走到这里;`finishRespond` 本身不重新核验 `entry` 是否还活着,会让**两个**调用都拿到 200 且都可能
+        // 修改 `allowAllSessions`(先落地的赢家 settle 生效,晚到的那个理应 404,却会在 store 抖动窗口内被
+        // 误当成「也成功了」——包括它自己的 `allow_session` 语义,即便真正的终局是另一路的 deny)。这里用
+        // `this.pending` 本身当权威:是否还是**这一个** entry 引用(而非仅仅「id 还在」——万一同一 id 已被
+        // 别的机制以别的对象重铸,值比较比键存在性更严——现网这只会是防御性写法,和 [1550] 的 originCtx
+        // identity-compare 同精神)。已被任何竞争者(另一 respond / 取消 / 窗到期)结算过 ⇒ 如实 404,不
+        // 覆盖、不重复应用 session 记忆。
+        const wantAllowed = parsed.value !== "deny";
+        if (this.pending.get(id) !== entry) {
+            // 🔴 #151 车5(X-1 状态感知分派的连带收口,2026-08-06):判据从「本地条目还在不在」精化成
+            // 「**这次回决是不是有效终局**」。两支分开:
+            //  (a) `decideAsk` **抛错**(`decidedWon=false`,不知道谁赢)⇒ 逐字保留 round1 的 404(否则两路
+            //      并发 respond 在店抖动窗内会都自称成功、都改 `allowAllSessions`);
+            //  (b) CAS **真赢**了 ⇒ 再看本地那次抢先结算与本次决议**是否一致**:
+            //      · 一致(取消/窗到期臂经 `convergeFromDurableState` 重读到的正是这次刚写下的 `DECIDED`)
+            //        ⇒ 行是 approve、闭包也交了 approve,回 404「no pending approval」等于对壳撒谎,必须 200;
+            //      · 不一致(D5 fail-open 的无条件 `settle(false)` —— 店真挂了那一支)⇒ 引擎实际收到的是 deny,
+            //        如实 404,绝不把一次没有生效的批准回显成成功(round6 钉住的正是这一支)。
+            // 无论哪一支,只要 CAS 真赢就先把同 askId 下**其余**尚未闻讯的本地条目按真决议清算(F30;round6
+            // 修的「因为提前 404 而跳过收尾」缺口在这里保住)。
+            if (decidedWon)
+                this.notifyExternalDecision(askId, wantAllowed, parsed.updatedInput);
+            const converged = decidedWon && entry.settledOutcome === (wantAllowed ? "allowed" : "denied");
+            if (!converged) {
+                return { status: 404, body: { error: "no pending tool approval for this id (settled, expired, or not on this replica)", errorCode: "tool_approval.not_pending" } };
+            }
+            // 一致 ⇒ 走与正常路径**同一段**收尾:`finishRespond` 对已结算 entry 调 `settle` 天然无操作(幂等),
+            // session 记忆照记(grant 谈的是**将来**的 ask,与这次投递是否由我完成无关)。
+            // 但 `updatedInput` **没有**随那次结算送达闭包(R2-4)⇒ 显式声明未投递,回显里不许出现
+            // `updatedInputForwarded`。
+            return this.finishRespond(id, entry, parsed, { updatedInputDelivered: false });
+        }
+        const result = this.finishRespond(id, entry, parsed);
+        // round5(pendingByAskId 顶注):回决赢下 CAS 时同样要收尾「同 askId 重复本地注册」那一支——与
+        // windowExpired/runCancel/emitAllP 三条竞争者的赢家路径同精神(那三处已经这么做)。此处 entry 已经
+        // 经 `finishRespond` 自行 settle 并从 pendingByAskId 的 Set 里摘除自己,故这里天然只会清算真正
+        // 「其余」的重复注册,不会覆盖自己刚落定的裁决。(F30 收口:按真决议,同上分支的理由。)
+        this.notifyExternalDecision(askId, wantAllowed, parsed.updatedInput);
+        return result;
+    }
+    /** 回决收尾(D1 现行为逐字不变的那一半)——session allow-all 记账 + settle + 200 响应体。原 `respond()`
+     *  方法体的逐字搬运(#151 车2 拆分,行为零改动)。 */
+    finishRespond(id, entry, parsed, opts) {
         // PAIR-REVIEW [1392]②:ack 带 rememberApplied 诚实回显——allow_session 且**真记了**(sessionId 在,
         // grant 落桥内店)= true;allow_session 但无 sessionId(adhoc 无会话,记不了)= false(壳不得渲染
         // 「本 session 全放行」);普通 allow/deny 不涉 remember = 字段省略。durable decide 腿的同名回显
@@ -449,7 +1458,22 @@ export class ToolApprovalCoordinator {
         entry.settle(allowed, allowed ? "allowed" : "denied", parsed.updatedInput);
         // updatedInputForwarded=server 已透传(是否被引擎消费取决于 core OnAsk 对象臂是否在——诚实措辞,
         // 不称 applied;cli 版本门+core 单落地后全链生效)。
-        return { status: 200, body: { approvalId: id, delivery: "applied", decision: parsed.value, ...(rememberApplied !== undefined ? { rememberApplied } : {}), ...(parsed.updatedInput !== undefined && allowed ? { updatedInputForwarded: true } : {}) } };
+        // 🔴 codex 交叉复审 round2 R2-4(2026-08-06 真缺陷):这个回显必须以「**这次调用真的把 updatedInput
+        // 交给了等待中的闭包**」为准,不能只看请求里带没带。已被别的臂(状态感知分派/另一路 respond)结算过的
+        // entry,上面这行 `settle` 是幂等无操作 —— 引擎拿到的是**原始 args**,而编辑是安全相关的(ctrl+g 改
+        // 命令行);此时还回 `updatedInputForwarded: true` 等于告诉壳「你的编辑生效了」,是最不该撒的那种谎。
+        // 调用方在 stale-entry 分支传 `updatedInputDelivered: false`,回显里这个键就整个缺席(壳按未透传处理)。
+        const updatedInputDelivered = opts?.updatedInputDelivered ?? true;
+        return {
+            status: 200,
+            body: {
+                approvalId: id,
+                delivery: "applied",
+                decision: parsed.value,
+                ...(rememberApplied !== undefined ? { rememberApplied } : {}),
+                ...(parsed.updatedInput !== undefined && allowed && updatedInputDelivered ? { updatedInputForwarded: true } : {}),
+            },
+        };
     }
     /** Test/observability hooks. */
     pendingCount() {