@sema-agent/server 7.33.0 → 7.34.0

package/USAGE.md

@@ -307,16 +307,19 @@ QUESTION_TTL_MS=300000
 > [`docs/ASSISTANT-WIRE-CONTRACT.md` §4a-quint](docs/ASSISTANT-WIRE-CONTRACT.md)(错误码 `feature.approval_ask_disabled` 在附录 A)。
 
 ```bash
-# 协议总开关。默认 true;显式 =false 是**唯一干净还原键**(全链逐字回到翻转前:不发 approval_request、
-# 不落 ask 行、不起收敛器腿,窗回到 DEFAULT_APPROVAL_TTL_MS)
+# 协议总开关。默认 true;显式 =false 是**本协议面**的干净还原键(不发 approval_request、不落 ask 行、
+# 不起收敛器腿,窗回到 DEFAULT_APPROVAL_TTL_MS)。⚠️ 它**不**回滚 7.34.0 的 R-13 窗到期语义——那一条的
+# 回滚键是下面的 UNATTENDED_APPROVAL_POLICY=deny(两根旋钮正交,别当一根用)
 STREAM_APPROVAL_ENABLED=true
-# 活卡窗(毫秒,默认 300000=5min)。0 = 运维显式关窗 ⇒ 恒 park(不是"还原",还原用上面那个键)
+# 活卡窗(毫秒,默认 300000=5min)。0 = 运维显式关窗 ⇒ 恒 park(不是"还原",还原用上面那个键;
+# 配了 UNATTENDED_APPROVAL_POLICY=deny 的部署这里是"恒当场拒",见下面那段)
 STREAM_ASK_WINDOW_MS=300000
 # 协调器窗长三元的安全余量(毫秒,默认 10000):有效窗 = min(ttl, 本 leg 余量 − 本值)
 STREAM_ASK_WINDOW_MARGIN_MS=10000
 # 开流重放:一次最多投几张未决卡(默认 50)。超出只投最新的并记一次 warn,开流不失败
 STREAM_APPROVAL_REPLAY_MAX=50
-# 写侧准入帽:单个 task / 单个 owner 的未决 ask 上限(默认 32 / 256)。超限走 park,**永不 deny**
+# 写侧准入帽:单个 task / 单个 owner 的未决 ask 上限(默认 32 / 256)。超限走 park(**缺省 park 政策下
+# 永不 deny**;配了 UNATTENDED_APPROVAL_POLICY=deny 的部署按它的自声明当场拒——见下面那段)
 STREAM_APPROVAL_ADMIT_MAX_PER_TASK=32
 STREAM_APPROVAL_ADMIT_MAX_PER_OWNER=256
 # 对账收敛器每 tick 每段最多处理的行数(默认 200,有界 [1,10000],且必须是**整数**)
@@ -346,12 +349,35 @@ STREAM_APPROVAL_ORPHAN_TTL_MS=604800000
 - **无 durable 前置的部署(五合取不满足:local backend / 无 checkpoint 能力)**:流内协议整个不上场
   (启动一行 `stream_approval_disabled` 点名缺哪项),ask 走旧活卡腿——断连场景的最坏结局是活卡 TTL
   窗满**自动 deny(fail-closed)后 run 继续**,不会死锁在等一张没人能回的卡上;代价是断连期间用户的
-  批准机会直接过期。要「断连也不丢决策」的语义,配齐 durable 前置(持久 store + `DURABLE_APPROVAL=true`)。
+  批准机会直接过期。(7.34.0 起这条 deny 由**引擎**在「没有可停靠的 durable 门」时给出——服务侧只报
+  「此刻无人可答」,见上面的 `UNATTENDED_APPROVAL_POLICY`;结局不变,拒绝理由的文案更准确。)要「断连也不丢决策」的语义,配齐 durable 前置(持久 store + `DURABLE_APPROVAL=true`)。
   默认值(300s + 60s vs 7d)自然满足,只有显式改坏才会撞上。
 - **调参方向**:想让人有更长时间点审批卡 → 调大 `STREAM_ASK_WINDOW_MS`;卡太多刷屏 → 调小两个 `ADMIT_MAX_*`
   (代价是超限的 ask 走 park,要有人去审批队列捞);库压大 → 调小 `STREAM_APPROVAL_RECONCILE_BATCH`
   (代价是收敛变慢,靠队列轮转保证下轮接着扫)。
 
+**无人值守政策(`UNATTENDED_APPROVAL_POLICY`,7.34.0 起 / #280 R-13)**
+
+```bash
+# 闭集 park|deny,缺省 park。拼错词**启动期响亮拒**(不静默回缺省)
+UNATTENDED_APPROVAL_POLICY=park
+```
+- 管的是**同一个问题**:一只需要人批的 ask 到了,而此刻**没有任何人**能答(窗走完没人点、连接全断、
+  运维把窗关成 0、bg/headless 腿本来就没有活流、未决卡撞上准入帽)。
+  - `park`(缺省)⇒ 服务报「此刻无人可答」,**durable 部署**(`DURABLE_APPROVAL=true` + checkpoint 能力的
+    backend)把 run **挂起候人**(`done(suspended)` + `pendingGate`),人回来经审批面补批就接着跑;
+    没有 park 设施的部署由引擎 fail-closed 拒绝并告诉模型「没有可停靠的 durable 审批门」。
+  - `deny` ⇒ **真无人值守/headless 部署的显式声明**:这类 ask 当场拒绝,让模型自己改道,不积压一堆
+    等不到人的挂起 run。它是**收紧**方向(不放行任何东西)。
+- **7.34.0 的行为变化(park 侧)**:此前「窗走完没人答」是**当场拒绝 + 一条 error 回模型**(模型往往就
+  绕开了那次治理);现在它与其余「无人可答」的情形一样走 park。要恢复旧结局请显式配 `deny`。
+- 纯部署级:**不看**客户端的任何表态/权限模式。协调器整体关掉(`TOOL_APPROVAL_ENABLED` 关)时这个旋钮
+  没有施加对象;`APPROVAL_REQUIRE` 名单里的工具走的是 durable 审批门,不受它影响。
+- 🔴 **与 `STREAM_APPROVAL_ENABLED` 正交**:把流内协议开关关掉**不会**回滚 R-13 —— 它只是不发
+  `approval_request`、不落 ask 行、不起收敛器腿,活卡窗到期照样走 park(park 的承载是引擎的 checkpoint,
+  不是 server 的 ask 行,「有 durable 设施但没开协议」正是 R-13 要救的那类部署)。要回到旧的「窗满即拒」
+  就配 `UNATTENDED_APPROVAL_POLICY=deny`。
+
 **可选 — READ 面姿态(readFace,7.18.0 起;缺席=引擎当家)**
 
 ```bash

package/dist/boot/coordinators.js

@@ -74,6 +74,13 @@ export function createLiveCoordinators(ctx) {
             admitMaxPerOwner: config.streamApproval.admitMaxPerOwner,
             // #154 车二:同意车道(缺席 = 规则店没装配 ⇒ 帧上零候选、回决的 persistRule 如实拒)。
             ...(ruleConsent !== undefined ? { ruleConsent } : {}),
+            // #280 R-13 C:无人值守政策(闭集 park|deny)。**恒传**(不挂任何在场性推断):它是纯部署级的一位,
+            // 语义/三问/射程边界一处成文见 `config-types.ts` 的 `unattendedApprovalPolicy` 域注。
+            // ⚠️ 恒传是**刻意**的,不是顺手(codex R2-F2 点过这一行):`streamApprovalGate.active` 为假时只
+            // 省略 askStore/窗,协调器照常在场,R-13 的 D1 窗到期臂照样按政策走 —— 那正是设计稿点名的主受益
+            // 部署(park 的承载是 core checkpoint,不是 ask 行)。把政策挂到协议开关上会把它整个切掉。
+            // 协调器本身缺席时(`TOOL_APPROVAL_ENABLED` 关)本旋钮无处施加 —— 成文事实,不是推断腿。
+            unattendedPolicy: config.unattendedApprovalPolicy,
         })
         : undefined;
     // SendUserFile(真 CC 契约,clay 2026-07-14)两种 lane 形态,其余缺席=诚实(工具不进 roster):

package/dist/boot/runner-deps.js

@@ -63,6 +63,11 @@ export function createEngineNoticeSeat(logger) {
     const warn = logger?.warn?.bind(logger);
     return warn ? { onNotice: createEngineNoticeForwarder({ warn }) } : {};
 }
+// #289(core 5.43.0 #316 观测席,[4448] 表态② 的评估结论,如实登记):`onSecretEnvScrub` 席在 server
+// 侧**无真挂点**——host lane 的执行 env(真跑用户 Bash 的那只)由 core 引擎自建,server 构造的三只
+// NodeExecutionEnv(resolve-spec 裁决 env / parked-revive-gate 裁决 env / run-local 治理探测 env)都不
+// 执行用户 Bash,挂席=假遥测面。终态=core 的 once-per-process console 摘要腿(5.43 起自带,响亮权在
+// core);若未来 core 给 RunnerDeps 开执行 env 构造参透传席,再按表态制接(上游件,不在此仓旁路)。
 export function createSharedRunnerDeps(ctx) {
     // 具名带类型的字面量(非裸 return)——deps-literal-shape-gate 的 POINTS 按 `const X: T = {` 咬装配
     // 字面量,裸 return 形在它的覆盖外(复审 2026-07-30 F5):conditional-spread 病在这里就会失检。

package/dist/config-types.d.ts

@@ -10,6 +10,7 @@ import type { A2aServerSpec, CompliancePosture, LockedKey, McpServerSpec, Model,
 import type { ApprovalHmacKey, PrincipalJwtKey } from "./auth-keys.js";
 import type { ElicitationThrottle } from "./elicitation.js";
 import type { QuestionThrottle } from "./question.js";
+import type { UnattendedApprovalPolicy } from "./tool-approval.js";
 import type { InfraCostRates } from "./observability/cost-taxonomy.js";
 import type { Autonomy, CommandRule } from "./runtime-governance.js";
 import type { GitApiKind } from "./git-api-kind.js";
@@ -126,7 +127,8 @@ export interface StreamApprovalConfig {
      *  `STREAM_APPROVAL_REPLAY_MAX`,默认 **50**。 */
     replayMax: number;
     /** 写侧准入门(§0 X-2)的 per-task 未决 ask 上限。超限 ⇒ 在落 pending/建 timer/发帧**之前**返回
-     *  `"unavailable"`(park 路由,**永不 deny**——过载 bypass 到 park 是 §3.3 的硬条款)。
+     *  `"unavailable"`(park 路由;**缺省 park 政策下永不 deny**——过载 bypass 到 park 是 §3.3 的硬条款。
+     *  #280 R-13 C:`UNATTENDED_APPROVAL_POLICY=deny` 的部署按自声明当场拒,理由见该键域注)。
      *  `STREAM_APPROVAL_ADMIT_MAX_PER_TASK`,默认 **32**。消费点在刀 3b。 */
     admitMaxPerTask: number;
     /** 同上,per-owner(租户)维。`STREAM_APPROVAL_ADMIT_MAX_PER_OWNER`,默认 **256**。 */
@@ -1157,6 +1159,44 @@ export interface ServiceConfigFlat {
      *  `STREAM_APPROVAL_RECONCILE_BATCH` / `STREAM_APPROVAL_PENDING_GRACE_MS` /
      *  `STREAM_APPROVAL_ADHOC_GRACE_MS` / `STREAM_APPROVAL_ORPHAN_TTL_MS`(后四键 = 车5 收敛器)。 */
     streamApproval: StreamApprovalConfig;
+    /**
+     * #280 R-13 C(`UNATTENDED_APPROVAL_POLICY`;裁定 [4297]Q1「裁2:A+C」/[4338] 裁②)——一只治理 ask
+     * 到了而**没有任何人**能答时,这条部署要什么终局。闭集 `park`(缺省)/ `deny`,**坏值 boot 拒启**
+     * (#210 A 档:一个拼错的词若被当成「未设」静默回缺省,运维会以为自己关掉了 park 积压而实际没有)。
+     *
+     * **谁需要**:auto / headless / 无人值守部署(夜间批处理、CI 里的 agent、没有任何人盯屏的 worker)。
+     * 它们的 park 是死信:run 挂起候一个永远不会来的人,占着 checkpoint 与配额直到 TTL。
+     * **谁被伤**:配了 `deny` 却其实有人的部署 —— 那些本可以补批的操作变成当场拒绝。补偿 = 这是**显式**
+     * 一句声明,缺省永远是 `park`;改回来只需删掉这一行 env。
+     * **不看任何客户端表态**(纯部署级;memory: operator-knob-must-be-unconditional —— #153 shellGate 让
+     * 一个部署级旋钮的生死由客户端 posture 决定,同病犯过两次)。
+     *
+     * 施加点 = `ToolApprovalCoordinator` 的构造参 `unattendedPolicy` **一处**,五条「无人可答」的臂读同一
+     * 个值(设计稿 §1 的表:(a) 有店窗到期赢 CAS /(b) 无店窗到期 /(c) 店报错 catch /(d) windowZero 与
+     * headless 腿 /(e) 断连强转 + emit 全灭 + 写侧准入超限)。`"timeout"` 宿主自报只留在 (b)(c) ——
+     * 结束等待的确实是本仓的窗;其余三臂结束等待的是容量/连接/装配,自报恒缺席。
+     *
+     * 🔴 **射程边界(成文,不是遗漏)**:
+     *  · 唯一让本旋钮**无处施加**的键是 `TOOL_APPROVAL_ENABLED=false`(协调器整体不构造,core 走它自己的
+     *    headless 姿态)。**不造推断腿**:旋钮只在协调器在场时有意义,这一句是成文而不是代码分支。
+     *  · ⚠️ **与 `STREAM_APPROVAL_ENABLED` 正交**(codex 对抗复审 R2-F2 验真后纠正 —— 本注上一版把两者
+     *    写成了一回事,是错的):协议开关关掉只是不注入 `askStore`/协议窗,协调器照常在场,于是 R-13 的
+     *    D1 窗到期臂**照样**走 park 路由。这不是漏网:设计稿 §2 明写 park 的承载是 **core checkpoint**
+     *    而不是 server 的 ask 行,「无 askStore 但有 durable 设施」正是 R-13 点名的**主受益部署**。
+     *    要回滚 R-13 的行为面,键是 `UNATTENDED_APPROVAL_POLICY=deny`,**不是**协议开关。
+     *    射程钉:`test/unattended-approval-policy.test.ts` 的 codex R2-F2 两格。
+     *  · APPROVAL_REQUIRE 名单工具走 `createApprovalBaselinePolicy` 的 durable gate 类,**不经流内臂**,
+     *    结构上不受本旋钮影响(裁定「非名单工具」的限定因此无需码内名单分支)。
+     *  · **持久回放**(窗到期后向真源收敛、`ensureAsk` 幂等重入撞上已终结的行)读出 PARKING/PARKED 时
+     *    **同样按旋钮改判** —— 它们与 (a) 是同一件事(赢家可能是别的副本或上一次调用),不统一的话同一只
+     *    ask 的终局会取决于「谁赢了那把 CAS / 重试没重试」。人的真决议回放不受影响。
+     *  · 唯一**不受**改判的是 `ensureAsk` 身份未定 / 坏行两臂(「身份不确定」的处置,不是「没有人」的
+     *    处置),于是 `deny` 部署上仍可能落极少数 park(店抖动期),已知且有意的残余。
+     *  · `deny` 部署上 ask **行**仍会经 PARKING 记账(旋钮改的是交给引擎的终局,不是店语义)。收敛器只把
+     *    PARKING 行绑到**已经存在的** checkpoint 上,而 deny 部署里引擎从不 park ⇒ 绑不上,行按 run 终局
+     *    自行收敛成 DENIED/VOID,不会凭空生出 park;残余 = 那类行的归因记成 `routing_failure`。
+     */
+    unattendedApprovalPolicy: UnattendedApprovalPolicy;
     /** [824]① (clay A 案 = workflow 权限全面 CC parity): workflow 子 agent 的默认权限基线与主 LLM 同权(base `{}`)。
      *  安全论证:主 LLM 与子 agent 同 root 同信任域,主 LLM 本就能写这棵树([816] ask 门照管),单独钳子 agent 的
      *  安全增益≈0(只防绕路不防直路的门不是边界);实测产品代价=[814]A 死锁。`WORKFLOW_AGENTS_READONLY=true` =
@@ -1296,7 +1336,7 @@ export type ServiceStoreConfig = Pick<ServiceConfigFlat, "sessionBackend" | "ses
 export type ServiceModelPlaneConfig = Pick<ServiceConfigFlat, "gatewayBaseUrl" | "gatewayApiKey" | "gatewayFallbackUrls" | "gatewayMaxRetries" | "anthropic" | "resilience" | "model" | "models" | "modelApiKeyEnv" | "modelApiKeys" | "modelQuotaWeights" | "tiers" | "projects" | "roles" | "atModelAllowlist" | "cascadeLadder" | "degrade">;
 /** 组:approval(审批 / HITL 门)。`directDoorActive` 无 env 解析腿(装配层三域合取的产物),但语义上
  *  就是本组的门状态,故进组;`parseApprovalDomain` 的返回类型相应是 `Omit<…, "directDoorActive">`。 */
-export type ServiceApprovalConfig = Pick<ServiceConfigFlat, "approvalRequire" | "approvalDeny" | "approvalTimeoutSec" | "approvalAutoBudget" | "approvalNeverAuto" | "approvalHmacKeys" | "durableApproval" | "directApprovalDoor" | "directDoorActive" | "resourceSuspend" | "resourceSuspendTtlSec" | "askQuestionEnabled" | "questionThrottle" | "toolApprovalEnabled" | "permissionRulesEnabled" | "permissionRulesEnabledExplicit" | "streamAskWindowMarginMs" | "streamApproval" | "mcpElicitation" | "sensitiveWritePatterns" | "manualModeShellGate">;
+export type ServiceApprovalConfig = Pick<ServiceConfigFlat, "approvalRequire" | "approvalDeny" | "approvalTimeoutSec" | "approvalAutoBudget" | "approvalNeverAuto" | "approvalHmacKeys" | "durableApproval" | "directApprovalDoor" | "directDoorActive" | "resourceSuspend" | "resourceSuspendTtlSec" | "askQuestionEnabled" | "questionThrottle" | "toolApprovalEnabled" | "permissionRulesEnabled" | "permissionRulesEnabledExplicit" | "streamAskWindowMarginMs" | "streamApproval" | "unattendedApprovalPolicy" | "mcpElicitation" | "sensitiveWritePatterns" | "manualModeShellGate">;
 /** 组:memory(记忆面 + TOC 同步腿)。 */
 export type ServiceMemoryConfig = Pick<ServiceConfigFlat, "memoryEngineEnabled" | "memoryEngineDir" | "memoryEngineRemoteLaneAllowed" | "memoryEngineBackend" | "memoryScope" | "memoryPersistenceCapable" | "memorySync" | "memoryEmbedder" | "memoryOrgAdmissionMode" | "memoryOrgDirectoryJson" | "memoryOrgGrantTtlMs" | "memoryOrgUnavailableBackoffMs" | "projectMemoryEnabled" | "syncImportLeaseStaleSec">;
 /** 组:auth(鉴权 / 身份 / 治理棒)。`commandPolicy` 只有 sema-registry 腿(无 env 标量形),故 env 解析

package/dist/config.js

@@ -1194,6 +1194,27 @@ function streamApprovalConfig() {
     }
     return cfg;
 }
+/**
+ * #280 R-13 C —— `UNATTENDED_APPROVAL_POLICY` 的闭集解析(#210 A 档:坏值**拒启**)。
+ *
+ * 词表 = `park`(缺省)| `deny`,**逐字精确匹配**(小写、两侧空白裁掉):`PARK` / `Deny` / `true` / `off`
+ * 一律落到拒启臂 —— 与 `MANUAL_MODE_SHELL_GATE` 同姿势,理由逐字同(「看起来被接受了」= 它其实什么都没做,
+ * 而这条轴决定的是权限门在无人值守时的终局方向,静默失效是运维面最贵的那一类)。
+ * ⚠️ 与 `MANUAL_MODE_SHELL_GATE` 的一处**刻意不同**:本键**没有** `off` 词。它的两个值都是真姿态
+ * (park / deny),不存在「这个旋钮不参与」的第三态;空串/未设 = 缺省 `park`,那是文档化的出厂姿态,
+ * 不是「关掉」。语义与射程成文见 `config-types.ts` 的域注。
+ */
+function unattendedApprovalPolicyEnv() {
+    const raw = (process.env.UNATTENDED_APPROVAL_POLICY ?? "").trim();
+    if (raw === "")
+        return "park";
+    if (raw === "park" || raw === "deny")
+        return raw;
+    throw new Error(`env UNATTENDED_APPROVAL_POLICY="${raw.slice(0, 120)}" is not a recognized value — use "park" (default: an ask nobody can answer becomes a durable park, the run suspends and waits for a human) ` +
+        `or "deny" (an unattended/headless deployment declaring that NOBODY will ever answer: such asks are denied on the spot instead of piling up parked runs). ` +
+        `The words are matched EXACTLY (lowercase, surrounding whitespace trimmed) and there is no "off" — both values are real postures, and unset simply means the documented default "park". ` +
+        `Refusing to boot rather than treating a misspelled value as "unset": that runs the deployment on a policy the operator did not choose, with no trace anywhere`);
+}
 function parseApprovalDomain(ctx) {
     const { postureOn } = ctx; // 跨域入参②:posture 三态(single-user turnkey ⇒ HITL 面默认 ON)
     // design/80 D-G: the direct-connect approval door anchors (all must be present to ACTIVATE; fail-closed).
@@ -1309,6 +1330,9 @@ function parseApprovalDomain(ctx) {
         // 的上一版正是这么漂的(默认翻 ON 之后它还写着「总开关默认 false」整整一版)。
         // 三问记录(翻转前那一版)见 config-types.ts 的 StreamApprovalConfig。
         streamApproval: streamApprovalConfig(),
+        // #280 R-13 C:无人值守政策(闭集 park|deny,缺省 park)。语义/三问/射程边界**一处成文** =
+        // `config-types.ts` 的 `unattendedApprovalPolicy` 域注,这里只解析,不复述(复述的两份必然各自漂)。
+        unattendedApprovalPolicy: unattendedApprovalPolicyEnv(),
         // [875]a 成文:0(缺省)= durable HITL 无限期等人,时间型 reapSuspended 不跑;file/memory lane 的回收
         // 探针只在 DURABLE_APPROVAL=true 时注入(无 durable 的部署两只 suspended 回收器恒 NO-OP,parked 行的
         // 恢复把手 = POST /v1/runs/:id/cancel,[868]①)。checkpoint 过期驱动的那只不受本旋钮门控。
@@ -2314,7 +2338,7 @@ const MODEL_PLANE_GROUP_KEYS = [
 const APPROVAL_GROUP_KEYS = [
     "approvalRequire", "approvalDeny", "approvalTimeoutSec", "approvalAutoBudget", "approvalNeverAuto",
     "approvalHmacKeys", "durableApproval", "directApprovalDoor", "directDoorActive", "resourceSuspend",
-    "resourceSuspendTtlSec", "askQuestionEnabled", "questionThrottle", "toolApprovalEnabled", "permissionRulesEnabled", "permissionRulesEnabledExplicit", "streamAskWindowMarginMs", "streamApproval", "mcpElicitation",
+    "resourceSuspendTtlSec", "askQuestionEnabled", "questionThrottle", "toolApprovalEnabled", "permissionRulesEnabled", "permissionRulesEnabledExplicit", "streamAskWindowMarginMs", "streamApproval", "unattendedApprovalPolicy", "mcpElicitation",
     "sensitiveWritePatterns", "manualModeShellGate",
 ];
 const MEMORY_GROUP_KEYS = [

package/dist/http/routes/tasks.js

@@ -1070,6 +1070,9 @@ async function handleTasksBody(req, res, url, ctx, miss) {
                         }
                         : undefined;
                     if (deps.toolApproval) {
+                        // 🔴 具名一次再进闭包(自审:`deps.toolApproval!` 的非空断言在这里是**可避免**的 —— 断言只
+                        // 在本 if 成立时正确,而闭包是稍后才跑的;拿捕获到的常量才是真的把那条不变量携进去)。
+                        const toolApproval = deps.toolApproval;
                         // [1546] HIGH-1:闭包只携身份——emit 经 broker 取「当前」活跃流(宿主重连的新 SSE 在
                         // runWithContext 注册时覆盖指针),internalsSnapshot 冻结的闭包不再携死 response/死 signal。
                         // #151 车3 刀 3b(§8.3 ⑦):`windowZero` ⇒ 换成**立即** `"unavailable"` 的闭包。为什么不是
@@ -1077,9 +1080,13 @@ async function handleTasksBody(req, res, url, ctx, miss) {
                         // per-task 的「缺席」结构上不可达;而 core 的 `approverUnavailable === true` 分支
                         // (prepare-task.js:3328-3335)**直接绕过** onAsk 在场判定去铸 checkpoint —— 与「onAsk 缺席」
                         // 在 park 结局上逐字等价,且可 per-task 表达。
+                        // #280 R-13 C 臂(d):这条短路的取值走协调器公开的**同一个**政策口
+                        // (`unattendedAskOutcome()`)—— `UNATTENDED_APPROVAL_POLICY=deny` 的部署上它是裸 `false`。
+                        // 🔴 不在这里读 `deps.config` 自己算一遍:五臂一处施加是本件的硬条款,两处各算必然漂
+                        // (协调器与装配层对同一只 ask 给出不同终局)。
                         prepared.spec.onAsk = windowZero
-                            ? () => Promise.resolve("unavailable")
-                            : deps.toolApproval.boundAsk({
+                            ? () => Promise.resolve(toolApproval.unattendedAskOutcome())
+                            : toolApproval.boundAsk({
                                 owner: askOwner,
                                 taskId: askTaskId,
                                 ...(prepared.spec.sessionId ? { sessionId: prepared.spec.sessionId } : {}),

package/dist/tool-approval.d.ts

@@ -68,6 +68,15 @@ export interface ToolApprovalFrame {
      *  本键让 live-only 部署(店缺席、帧无卡)也能读到出身位;安全类标记不得依赖店在场([4392] 结构性
      *  缺口成文)。消费语义(cli 挂点已预埋):在场 ⇒ 一切自动放行让位(含记住的规则与 bypass 姿态)。 */
     requiresRealApproval?: true;
+    /** #288([4429]② cli 请托;**ADDITIVE**,`"tool_approval"` only,7.34.0+)——窗三键,与
+     *  `approval_request` 帧(design/172 呈卡帧)同名同义:`expiresAtMs` = 本 ask 的绝对到期墙钟
+     *  (有店=行上一次铸定的 `expiresAtMs`,与卡帧/落库同值;无店 D1=注册时刻算定的同名初值),
+     *  `serverNowMs` = **帧铸造时刻**(cli [4429] 锚定语义:倒计时锚=帧到手时刻的服务器钟),
+     *  `expiresInMs` = `max(0, expiresAtMs - serverNowMs)` 现算。三键同生同缺(windowZero 腿不发帧,
+     *  发出的帧恒带);旧消费端无感,新壳借此给旧族帧补倒计时([4297] Q2 那类 77 分钟死卡的根治半场)。 */
+    expiresAtMs?: number;
+    expiresInMs?: number;
+    serverNowMs?: number;
     /**
      * #144(core 5.25.0,[3438] 接力契约 / [3443] 主件;**ADDITIVE**,`"tool_approval"` only)——
      * 这只 ask **命中了**调用方的一条持久 allow 规则,而那条规则**没能清掉它**。值 = 被越级的那条规则
@@ -256,6 +265,20 @@ export declare function parseToolApprovalResponse(body: unknown): {
     ok: false;
     error: string;
 };
+/**
+ * #280 R-13 C —— `UNATTENDED_APPROVAL_POLICY` 的**闭集**词表([4297]Q1「裁2:A+C」/[4338] 裁②)。
+ *
+ * 语义轴 = 「一只治理 ask 到了、而**没有任何人**能答」时这条部署要什么终局:
+ *  · `park`(缺省)—— 交 `"unavailable"`,由 core 走 durable park:run 挂起候人(done(suspended) +
+ *    pendingGate),人回来补批就能续。要求部署真有 park 设施(`durableApproval` + checkpoint 店);
+ *    没有的话 core 自己 fail-closed deny(文案自带「no durable approval gate is armed」)。
+ *  · `deny` —— 真无人值守 / headless 部署的**显式**自声明:不积压 park,当场 deny 让模型自己改道。
+ *
+ * 闭集 + 穷举 `switch`/三元的理由(#157 无静默 fail-open):这条轴决定的是**权限门的终局方向**,
+ * 一个拼错的词若被当成「未设」静默回缺省,运维会以为自己关掉了 park 积压而实际没有。坏值 boot 拒启
+ * (`config.ts` 的解析腿,#210 A 档)。
+ */
+export type UnattendedApprovalPolicy = "park" | "deny";
 /**
  * #151 车3 刀 3b —— 「流内审批协议到底上不上场」的**单一谓词**(设计稿 §2.3 注入 / §2.4 能力面 /
  * §8.4 park 设施自检,三处同一份判据)。
@@ -442,6 +465,12 @@ export declare class ToolApprovalCoordinator {
      *  `RunnerDeps.permissionRuleStore` 同源于一个对象)⇒ ①ask 帧投 `ruleSuggestions`;②回决带
      *  `persistRule` 时兑付进店。缺席 ⇒ 两件都不做(诚实缺席,不发无处可兑的候选)。 */
     private readonly ruleConsent;
+    /** #280 R-13 C(`UNATTENDED_APPROVAL_POLICY`,设计稿 §2):**无人可答**时这条部署要的终局。
+     *  `park`(缺省)= 交 `"unavailable"` 走 core durable park;`deny` = 显式自声明「真无人值守、不积压
+     *  park、要模型当场自走」⇒ 同样五臂改判 deny。**纯部署级**:不看任何客户端 posture / 表态
+     *  (memory: operator-knob-must-be-unconditional —— #153 shellGate 让部署级旋钮的生死由客户端表态
+     *  决定,同病两犯过一次)。安全轴:`deny` 是收紧方向(不放行任何东西),fail-closed 铁律不受损。 */
+    private readonly unattendedPolicy;
     constructor(opts?: {
         ttlMs?: number;
         askStore?: ApprovalAskStore;
@@ -452,7 +481,40 @@ export declare class ToolApprovalCoordinator {
         governanceAskMarks?: GovernanceAskMarks;
         /** #154 车二:同意车道(在场 = 规则店已装配)。 */
         ruleConsent?: RuleConsentLane;
+        /** #280 R-13 C:无人值守政策(见 {@link ToolApprovalCoordinator.unattendedPolicy});缺省 `park`。 */
+        unattendedPolicy?: UnattendedApprovalPolicy;
     });
+    /**
+     * #280 R-13 C —— 「**无人可答**」这一类终局的**唯一**成形口(park 路由 vs deny 政策)。
+     *
+     * 五臂(设计稿 §1 的表)全部读它,`unattendedPolicy` 因此是一处施加、五处消费:
+     *  (a) 有店窗到期 `expireAsk` 赢 CAS / (b) 无店窗到期(D1)/ (c) 有店但 `expireAsk` 报错
+     *  —— 三条走 `windowRouteUnavailable` 标志,在 {@link shapeOutcome}(askBroadcast 内)成形;
+     *  (d) `windowZero`(装配层短路)与无 ALS 上下文的 headless 腿 —— 走本方法/{@link ask};
+     *  (e) 断连 `forceParkNow` / emit 全灭 / 写侧准入超限 —— 走本方法。
+     *
+     * **持久回放的两个口也归它管**(codex R1-F1 验真后收口,红先钉在
+     * `test/unattended-approval-policy.test.ts`):`convergeFromDurableState` 与 `ensureAsk` 幂等重入,
+     * 只要回放出来的是 `"unavailable"`(行 PARKING/PARKED)就过这个口。理由:那三处与臂 (a) 是**同一件
+     * 事**(本 ask 的等待以「行进了投递面」收场,赢家可能是别的副本 / 上一次调用),不统一的话同一只 ask
+     * 的终局会取决于「谁赢了那把 CAS」「重试没重试」—— 比残余更坏的不可解释性。人的**真决议**(回放出
+     * `true`/`false`)当然不过这个口:那不是「无人可答」。
+     *
+     * 🔴 **不**归它管的一类(刻意,不是遗漏):`ensureAsk` **身份未定 / 坏行**两臂 —— 那里的 park 路由是对
+     * **身份不确定**的处置(与「有没有人」无关),且背后可能正躺着一条真行。于是 `deny` 部署上仍可能落
+     * 极少数 park(店抖动期),已知且有意的残余,成文在 config-types 的域注。
+     *
+     * ⚠️ **`deny` 部署上持久行仍会经 PARKING 记账**(codex R1-F1 的另一半,验真后**不采纳**其「给 deny
+     * 造一条原子 deny 终态转移」的建议):那是店语义变更(新转移 + 批内兄弟连坐语义 + 真双库套件),且与
+     * 已裁的设计稿(§2:(a) 在 deny 下只改交给 core 的终局)相左。**危害亲验为零**:收敛器判据①的
+     * `bindBatch` 只把 PARKING 行绑到**已经存在的 core checkpoint** 上,而 `deny` 部署里 core 从不 park
+     * ⇒ 结构上绑不上,该行按判据②/④/⑤ 自行收敛成 DENIED/VOID,不会凭空生出一张 park 或幻影 gate。
+     * 残余 = 那类行的归因会记成 `routing_failure`(其实是政策 deny),归因精化登记为候件。
+     */
+    private unattendedOutcome;
+    /** {@link unattendedOutcome} 的**公开**口:`windowZero` 的 immediate-unavailable 闭包长在装配层
+     *  (`http/routes/tasks.ts` 的 sync 腿),它必须与协调器内五臂读**同一个**旋钮值,而不是各算一遍。 */
+    unattendedAskOutcome(): "unavailable" | false;
     /**
      * #151 车3 刀 3b —— design/172 §3.3 / 设计稿 §0 X-2 的**写侧准入门**。
      *
@@ -461,7 +523,7 @@ export declare class ToolApprovalCoordinator {
      * 上限,`MAX_ALLOW_SESSIONS` 只管 grant 集合),所以回决腿与恢复扫描都只能在**已经分配之后**动手 ——
      * 门必须长在这里。
      *
-     * 超限的处置是 `"unavailable"`(park 路由),**永不 deny**:过载是**我方**的容量事实,不是人对这次
+     * 超限的处置是 `"unavailable"`(park 路由),**缺省 park 政策下永不 deny**:过载是**我方**的容量事实,不是人对这次
      * 操作的判断;用 deny 表达过载会把一次「本可以 park 后由人补批」的操作变成任务失败(§3.3 硬条款)。
      *
      * 只在 `askStore` 在场(= 协议开着)时把关:开关关闭时本方法恒放行,现行为逐字不变(D1/A-1)。
@@ -511,11 +573,39 @@ export declare class ToolApprovalCoordinator {
      *  地输,只会「什么都不做」,永远等不到本地事件驱动 settle)。这里直接反查这些 askId 各自的本地 pending
      *  条目集合并逐个调用它们自己的 `settle` 闭包(复用它们自己的 timer 清理/abort 监听器摘除/pending
      *  删除),把远程/其他调用栈发生的终局如实同步回本地——查无对应条目(不在这个副本、或从未真正注册过)
-     *  是正常情况,静默跳过。**调用方职责**:传入的 `askIds` 应当包含调用方自己的 askId(捕获"同一 askId
-     *  的重复本地注册"这一支)以及(如适用)`expireAsk` 返回的 `voidedSiblings`(捕获"批内兄弟被撤卡"那一
-     *  支)——赢家自己的条目此刻已经 settle 过、已经从集合里摘除(见 settle() 内的摘除逻辑),故这里对它
-     *  自己重复调用 `settle` 天然是无操作,不会有副作用。 */
+     *  是正常情况,静默跳过。
+     *
+     *  🔴 **本口只收「行真的没了」那一类**(#280 codex R3-F2,验真后拆分;红先钉在
+     *  `test/unattended-approval-policy.test.ts`):`expireAsk` 返回的 `voidedSiblings` 的行是 **VOID**,
+     *  裸 `(false,"expired")` 正是它们的真终局。而**调用方自己那个 askId** 的行是 **PARKING**(已转投递
+     *  面)—— 把它混进本名单会让「同 askId 的重复本地注册」拿到裸 deny,而赢家拿的是 park 路由:同一条
+     *  持久行、两种 live 终局。那一支改走 {@link settleSameAskIdParkRoute}。 */
     private settleVoidedSiblings;
+    /**
+     * #280 codex R3-F1 —— 「行上此刻有没有一个**真决议**」的一次性窄读(窗到期臂的店报错支专用)。
+     *
+     * 返回 `true`/`false` = 行是 `DECIDED` 且决议是 approve/deny(**人的**裁决,或车4 端点代人落的那一次);
+     * `undefined` = 其它一切(读失败、行不在、行是 STREAM_PENDING/PARKING/PARKED/DENIED/VOID)——调用方按
+     * 自己的臂继续。判别复用 {@link replayTerminalAskRow}(不造第二套映射),这里只把它的**布尔臂**取出来:
+     * `"unavailable"`(PARKING/PARKED)刻意**不**在本口消费,那属于路由面、归 `unattendedPolicy` 管。
+     *
+     * 一次读 + 墙钟 deadline(不重试):店已经在报错的语境里,重试只会把窗到期的收尾拖成秒级,而这一口要
+     * 回答的问题(「有没有人已经答过了」)读一次就够 —— 读不到就按「不知道」处置,与本臂原语义一致。
+     *
+     * ⚠️ **已登记的残余(codex R4-F1/F2,验真后不在本批修)**:本读与随后的本地 settle 之间没有持久 CAS,
+     * 所以「读到 STREAM_PENDING、另一副本**随后**才提交 DECIDED」这条窄窗仍会得到 park/deny 终局(行是
+     * approve 而本腿不执行);`emit` 全灭臂与取消臂的 store-未知态 catch 有**同形**缺口(两者都早于本件、
+     * 各自有既有判据钉着)。方向仍是 fail-closed(没有任何东西在未经人批时执行),补偿是 core 侧那张仍然
+     * pending 的 checkpoint —— 人再批一次就走。真正的收口 = 把窗/emit-全灭/取消三条 ambiguous-CAS catch
+     * 统一到一次**持久**恢复流程(带 CAS 与终态回读),那是店语义级改动,须由本模块属主立设计件,施工车
+     * 不私开(本批已试过整段复用 `convergeFromDurableState`,被自己的全量跑打回,理由见其顶注)。
+     */
+    private readDecidedForRecovery;
+    /** #280 codex R3-F2:同一 askId 下**其余本地注册**(重复注册,见 {@link pendingByAskId} 顶注)按
+     *  **park 路由**收尾 —— 行已 PARKING,它们看的是同一条行,终局必须与赢家同形(`unattendedPolicy`
+     *  由各自的闭包读同一个口,deny 部署上一起是 deny)。赢家自己此刻已 settle 过、已从集合里摘除,
+     *  故对它重复调用天然无操作。 */
+    private settleSameAskIdParkRoute;
     /**
      * #151 车4 §12-E(F29/F30 裁定形):外部回决(车4 端点或本类 respond 腿)**赢下持久 CAS 之后**,把同
      * askId 下全部本地悬挂条目按**真实决议**结算——端点已是唯一权威(CAS 已落),本地只是同步终局;查无

package/dist/tool-approval.js

@@ -108,8 +108,11 @@ const DURABLE_CONVERGE_READ_TIMEOUT_MS = 2_000;
 const DURABLE_CALL_TIMEOUT_MS = 5_000;
 /** {@link ToolApprovalCoordinator.withStoreDeadline} 超时时抛的**具名**错误。
  *  🔴 具名类而不是「按 message 文本判别」:错误文案是给人看的,拿它当控制流 = 上游改一句人话下游静默
- *  失效(#90 工程规范 v3 门②,机械门在 test/engineering-code-gates.test.ts 盯着)。调用点用
- *  `instanceof` 分「超时(不知道做没做成)」与「店真报错(没做成)」两条**处置方向不同**的臂。 */
+ *  失效(#90 工程规范 v3 门②,机械门在 test/engineering-code-gates.test.ts 盯着)。
+ *  ⚠️ **判别用途已退役**(#280 R-13 A2,2026-08-18):窗到期 catch 臂此前用 `instanceof` 分「超时(不知道
+ *  做没做成)」与「店真报错」两条方向不同的臂;A2 把两支合判成 park 路由之后没有调用点再分它。类留着的
+ *  理由是**归因**(`noteStoreError` 的日志/计数里那个 name 区分得出「店挂了」与「店慢到没意义」)与
+ *  `withStoreDeadline` 的迟到回调语义,不是控制流。 */
 class ApprovalStoreDeadlineError extends Error {
     constructor(label, timeoutMs) {
         super(`approval store call ${label} timed out after ${timeoutMs}ms`);
@@ -387,6 +390,12 @@ export class ToolApprovalCoordinator {
      *  `RunnerDeps.permissionRuleStore` 同源于一个对象)⇒ ①ask 帧投 `ruleSuggestions`;②回决带
      *  `persistRule` 时兑付进店。缺席 ⇒ 两件都不做(诚实缺席,不发无处可兑的候选)。 */
     ruleConsent;
+    /** #280 R-13 C(`UNATTENDED_APPROVAL_POLICY`,设计稿 §2):**无人可答**时这条部署要的终局。
+     *  `park`(缺省)= 交 `"unavailable"` 走 core durable park;`deny` = 显式自声明「真无人值守、不积压
+     *  park、要模型当场自走」⇒ 同样五臂改判 deny。**纯部署级**:不看任何客户端 posture / 表态
+     *  (memory: operator-knob-must-be-unconditional —— #153 shellGate 让部署级旋钮的生死由客户端表态
+     *  决定,同病两犯过一次)。安全轴:`deny` 是收紧方向(不放行任何东西),fail-closed 铁律不受损。 */
+    unattendedPolicy;
     constructor(opts) {
         this.ruleConsent = opts?.ruleConsent;
         this.governanceAskMarks = opts?.governanceAskMarks;
@@ -395,6 +404,42 @@ export class ToolApprovalCoordinator {
         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;
+        this.unattendedPolicy = opts?.unattendedPolicy ?? "park";
+    }
+    /**
+     * #280 R-13 C —— 「**无人可答**」这一类终局的**唯一**成形口(park 路由 vs deny 政策)。
+     *
+     * 五臂(设计稿 §1 的表)全部读它,`unattendedPolicy` 因此是一处施加、五处消费:
+     *  (a) 有店窗到期 `expireAsk` 赢 CAS / (b) 无店窗到期(D1)/ (c) 有店但 `expireAsk` 报错
+     *  —— 三条走 `windowRouteUnavailable` 标志,在 {@link shapeOutcome}(askBroadcast 内)成形;
+     *  (d) `windowZero`(装配层短路)与无 ALS 上下文的 headless 腿 —— 走本方法/{@link ask};
+     *  (e) 断连 `forceParkNow` / emit 全灭 / 写侧准入超限 —— 走本方法。
+     *
+     * **持久回放的两个口也归它管**(codex R1-F1 验真后收口,红先钉在
+     * `test/unattended-approval-policy.test.ts`):`convergeFromDurableState` 与 `ensureAsk` 幂等重入,
+     * 只要回放出来的是 `"unavailable"`(行 PARKING/PARKED)就过这个口。理由:那三处与臂 (a) 是**同一件
+     * 事**(本 ask 的等待以「行进了投递面」收场,赢家可能是别的副本 / 上一次调用),不统一的话同一只 ask
+     * 的终局会取决于「谁赢了那把 CAS」「重试没重试」—— 比残余更坏的不可解释性。人的**真决议**(回放出
+     * `true`/`false`)当然不过这个口:那不是「无人可答」。
+     *
+     * 🔴 **不**归它管的一类(刻意,不是遗漏):`ensureAsk` **身份未定 / 坏行**两臂 —— 那里的 park 路由是对
+     * **身份不确定**的处置(与「有没有人」无关),且背后可能正躺着一条真行。于是 `deny` 部署上仍可能落
+     * 极少数 park(店抖动期),已知且有意的残余,成文在 config-types 的域注。
+     *
+     * ⚠️ **`deny` 部署上持久行仍会经 PARKING 记账**(codex R1-F1 的另一半,验真后**不采纳**其「给 deny
+     * 造一条原子 deny 终态转移」的建议):那是店语义变更(新转移 + 批内兄弟连坐语义 + 真双库套件),且与
+     * 已裁的设计稿(§2:(a) 在 deny 下只改交给 core 的终局)相左。**危害亲验为零**:收敛器判据①的
+     * `bindBatch` 只把 PARKING 行绑到**已经存在的 core checkpoint** 上,而 `deny` 部署里 core 从不 park
+     * ⇒ 结构上绑不上,该行按判据②/④/⑤ 自行收敛成 DENIED/VOID,不会凭空生出一张 park 或幻影 gate。
+     * 残余 = 那类行的归因会记成 `routing_failure`(其实是政策 deny),归因精化登记为候件。
+     */
+    unattendedOutcome() {
+        return this.unattendedPolicy === "deny" ? false : "unavailable";
+    }
+    /** {@link unattendedOutcome} 的**公开**口:`windowZero` 的 immediate-unavailable 闭包长在装配层
+     *  (`http/routes/tasks.ts` 的 sync 腿),它必须与协调器内五臂读**同一个**旋钮值,而不是各算一遍。 */
+    unattendedAskOutcome() {
+        return this.unattendedOutcome();
     }
     /**
      * #151 车3 刀 3b —— design/172 §3.3 / 设计稿 §0 X-2 的**写侧准入门**。
@@ -404,7 +449,7 @@ export class ToolApprovalCoordinator {
      * 上限,`MAX_ALLOW_SESSIONS` 只管 grant 集合),所以回决腿与恢复扫描都只能在**已经分配之后**动手 ——
      * 门必须长在这里。
      *
-     * 超限的处置是 `"unavailable"`(park 路由),**永不 deny**:过载是**我方**的容量事实,不是人对这次
+     * 超限的处置是 `"unavailable"`(park 路由),**缺省 park 政策下永不 deny**:过载是**我方**的容量事实,不是人对这次
      * 操作的判断;用 deny 表达过载会把一次「本可以 park 后由人补批」的操作变成任务失败(§3.3 硬条款)。
      *
      * 只在 `askStore` 在场(= 协议开着)时把关:开关关闭时本方法恒放行,现行为逐字不变(D1/A-1)。
@@ -602,10 +647,13 @@ export class ToolApprovalCoordinator {
      *  地输,只会「什么都不做」,永远等不到本地事件驱动 settle)。这里直接反查这些 askId 各自的本地 pending
      *  条目集合并逐个调用它们自己的 `settle` 闭包(复用它们自己的 timer 清理/abort 监听器摘除/pending
      *  删除),把远程/其他调用栈发生的终局如实同步回本地——查无对应条目(不在这个副本、或从未真正注册过)
-     *  是正常情况,静默跳过。**调用方职责**:传入的 `askIds` 应当包含调用方自己的 askId(捕获"同一 askId
-     *  的重复本地注册"这一支)以及(如适用)`expireAsk` 返回的 `voidedSiblings`(捕获"批内兄弟被撤卡"那一
-     *  支)——赢家自己的条目此刻已经 settle 过、已经从集合里摘除(见 settle() 内的摘除逻辑),故这里对它
-     *  自己重复调用 `settle` 天然是无操作,不会有副作用。 */
+     *  是正常情况,静默跳过。
+     *
+     *  🔴 **本口只收「行真的没了」那一类**(#280 codex R3-F2,验真后拆分;红先钉在
+     *  `test/unattended-approval-policy.test.ts`):`expireAsk` 返回的 `voidedSiblings` 的行是 **VOID**,
+     *  裸 `(false,"expired")` 正是它们的真终局。而**调用方自己那个 askId** 的行是 **PARKING**(已转投递
+     *  面)—— 把它混进本名单会让「同 askId 的重复本地注册」拿到裸 deny,而赢家拿的是 park 路由:同一条
+     *  持久行、两种 live 终局。那一支改走 {@link settleSameAskIdParkRoute}。 */
     settleVoidedSiblings(askIds) {
         for (const askId of askIds) {
             const entries = this.pendingByAskId.get(askId);
@@ -615,6 +663,51 @@ export class ToolApprovalCoordinator {
                 entry.settle(false, "expired"); // 拷贝快照:settle 会修改原集合
         }
     }
+    /**
+     * #280 codex R3-F1 —— 「行上此刻有没有一个**真决议**」的一次性窄读(窗到期臂的店报错支专用)。
+     *
+     * 返回 `true`/`false` = 行是 `DECIDED` 且决议是 approve/deny(**人的**裁决,或车4 端点代人落的那一次);
+     * `undefined` = 其它一切(读失败、行不在、行是 STREAM_PENDING/PARKING/PARKED/DENIED/VOID)——调用方按
+     * 自己的臂继续。判别复用 {@link replayTerminalAskRow}(不造第二套映射),这里只把它的**布尔臂**取出来:
+     * `"unavailable"`(PARKING/PARKED)刻意**不**在本口消费,那属于路由面、归 `unattendedPolicy` 管。
+     *
+     * 一次读 + 墙钟 deadline(不重试):店已经在报错的语境里,重试只会把窗到期的收尾拖成秒级,而这一口要
+     * 回答的问题(「有没有人已经答过了」)读一次就够 —— 读不到就按「不知道」处置,与本臂原语义一致。
+     *
+     * ⚠️ **已登记的残余(codex R4-F1/F2,验真后不在本批修)**:本读与随后的本地 settle 之间没有持久 CAS,
+     * 所以「读到 STREAM_PENDING、另一副本**随后**才提交 DECIDED」这条窄窗仍会得到 park/deny 终局(行是
+     * approve 而本腿不执行);`emit` 全灭臂与取消臂的 store-未知态 catch 有**同形**缺口(两者都早于本件、
+     * 各自有既有判据钉着)。方向仍是 fail-closed(没有任何东西在未经人批时执行),补偿是 core 侧那张仍然
+     * pending 的 checkpoint —— 人再批一次就走。真正的收口 = 把窗/emit-全灭/取消三条 ambiguous-CAS catch
+     * 统一到一次**持久**恢复流程(带 CAS 与终态回读),那是店语义级改动,须由本模块属主立设计件,施工车
+     * 不私开(本批已试过整段复用 `convergeFromDurableState`,被自己的全量跑打回,理由见其顶注)。
+     */
+    async readDecidedForRecovery(askId) {
+        if (!this.askStore)
+            return undefined;
+        try {
+            const row = await this.withStoreDeadline(this.askStore.getAsk(askId), "getAsk(expire-error-recovery)", DURABLE_CONVERGE_READ_TIMEOUT_MS);
+            if (row === null || row.state !== "DECIDED")
+                return undefined;
+            const replayed = replayTerminalAskRow(row);
+            return typeof replayed === "boolean" ? replayed : undefined;
+        }
+        catch (err) {
+            this.noteStoreError(err, "getAsk(expire-error-recovery)");
+            return undefined;
+        }
+    }
+    /** #280 codex R3-F2:同一 askId 下**其余本地注册**(重复注册,见 {@link pendingByAskId} 顶注)按
+     *  **park 路由**收尾 —— 行已 PARKING,它们看的是同一条行,终局必须与赢家同形(`unattendedPolicy`
+     *  由各自的闭包读同一个口,deny 部署上一起是 deny)。赢家自己此刻已 settle 过、已从集合里摘除,
+     *  故对它重复调用天然无操作。 */
+    settleSameAskIdParkRoute(askId) {
+        const entries = this.pendingByAskId.get(askId);
+        if (!entries)
+            return;
+        for (const entry of [...entries])
+            entry.settleParkRoute(); // 拷贝快照:结算会修改原集合
+    }
     /**
      * #151 车4 §12-E(F29/F30 裁定形):外部回决(车4 端点或本类 respond 腿)**赢下持久 CAS 之后**,把同
      * askId 下全部本地悬挂条目按**真实决议**结算——端点已是唯一权威(CAS 已落),本地只是同步终局;查无
@@ -745,8 +838,10 @@ export class ToolApprovalCoordinator {
         const ctx = this.als.getStore();
         // No run context (background/workflow/headless/durable-submit leg — [820]④) = nobody to render the card ⇒
         // "unavailable"(交 durable park),不再把「无人可问」翻译成 deny(1.295 前无三值只能 fail-closed)。
+        // #280 R-13 C 臂(d):bg/resume 两腿的 `windowZero` 在装配层的表达就是**不包 ALS**
+        // (`resolveApprovalLeg` 顶注),于是它与 headless 腿一起落在本臂上 —— 政策取值走同一个口。
         if (!ctx)
-            return "unavailable";
+            return this.unattendedOutcome();
         // 出处 = 本 ctx 自身(ALS 腿的投递集合恒是它一个),显式传,不靠 askBroadcast 去猜。
         return this.askBroadcast({ taskId: ctx.taskId, legKey: ctx.legKey ?? "", ...(ctx.legDeadlineMonotonic !== undefined ? { legDeadlineMonotonic: ctx.legDeadlineMonotonic } : {}) }, [ctx], req, signal);
     };
@@ -767,8 +862,10 @@ export class ToolApprovalCoordinator {
         return (req, signal) => {
             const set = this.streams.get(this.streamKey(identity.owner, identity.sessionId, identity.taskId));
             const live = set && set.size > 0 ? [...set] : [];
+            // #280 R-13 C 臂(e)的入口形:查无活流 = 「卡送不到任何人」的**到达时刻**版本(emit 全灭是它的
+            // 事后版本)—— 同一类事实,同一个政策口。
             if (live.length === 0)
-                return Promise.resolve("unavailable");
+                return Promise.resolve(this.unattendedOutcome());
             // 🔴 codex 交叉复审(刀 3a,high)修:身份轴取**捕获的出处身份**,不取投递集合的第一条流。
             // `streamKey` 的 session 形不含 taskId ⇒ 同一集合里可以躺着不同 run 的 ctx,`aliveCtxs[0]` 只是
             // 「当下第一条活着的投递连接」。用它当 runId 会双向出错:同一只出处 ask 在集合组成变化后重入拿到
@@ -802,11 +899,14 @@ export class ToolApprovalCoordinator {
         // Session allow-all (CC "Yes, allow all edits during this session"): keyed [owner, sessionId, category] — the
         // asking tool's OWN capability category must have been granted in THIS owner's session (修2; module header).
         // 多活集合下 owner/sessionId 对全体 ctxs 恒同(streamKey 分组保证),primary 取值代表整个集合安全。
-        if (primary.sessionId && this.allowAllSessions.has(sessionAllowKey(primary.owner, primary.sessionId, sessionAllowCategory(req.toolName)))) {
+        // #287([4434]② P0):`requiresRealApproval` 的成文语义=「必须真人逐次批,一揽子放行不得覆盖」——
+        // 这条短路正是它要禁的 blanket-allow,安全类 ask 无视既有 grant、恒往下走真出卡(core 侧持久规则
+        // 半场已源头关死:ruleSuggestionsOf 对该位返 {};流内这半在此)。写侧配对臂见 finishRespond。
+        if (req.requiresRealApproval !== true && 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})。
+        // 超限 ⇒ park 路由(缺省 `park` 政策下即 `"unavailable"`,永不 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", {
@@ -815,7 +915,10 @@ export class ToolApprovalCoordinator {
                 admitMaxPerTask: this.admitMaxPerTask,
                 admitMaxPerOwner: this.admitMaxPerOwner,
             });
-            return "unavailable";
+            // #280 R-13 C 臂(e):`deny` 政策下同样改判 deny —— 「过载 ⇒ 永不 deny」那条硬条款的成立前提是
+            // **有** park 可落(把一次可补批的操作变成任务失败才是它要禁的);声明了无人值守的部署里 park 本身
+            // 就是死信,当场 deny 反而是它要的诚实终局。方向仍是收紧(不放行任何东西)。
+            return this.unattendedOutcome();
         }
         // `id` = **本地** pending 条目的键(每次注册各一个,绝不共享 —— {@link pendingByAskId} 顶注记的
         // 「同 askId 重复本地注册」两类成因下,两条条目必须各占一格,否则后到者会覆盖先到者的登记)。
@@ -1036,7 +1139,12 @@ export class ToolApprovalCoordinator {
                 // 重启。修法:行不是 STREAM_PENDING ⇒ 不重新挂卡,直接回放既有终局(不落 pending、不 emit)。
                 if (existingOrCreated.row.state !== "STREAM_PENDING") {
                     releaseAdmission(); // X-2:回放既有终局 = 这只 ask 从未占用一条未决腿,名额立刻还回去
-                    return replayTerminalAskRow(existingOrCreated.row);
+                    // 🔴 #280 codex 对抗复审 R1-F1 [high](验真后**部分采纳**,红先复现):回放出来的
+                    // `"unavailable"`(行是 PARKING/PARKED)必须**同样过政策口**。不过的话,`deny` 部署上臂 (a)
+                    // 写下的 PARKING 行会让**同一只 ask** 的终局取决于「重试没重试」:首次 deny、重入 park。
+                    // 人的真决议(DECIDED ⇒ true/false)不经这个口 —— 那不是「无人可答」,回放它是幂等复述。
+                    const replayed = replayTerminalAskRow(existingOrCreated.row);
+                    return replayed === "unavailable" ? this.unattendedOutcome() : replayed;
                 }
                 // 🔴 F2 修:行 = 真源。刚插的行上这三样与本地一致(采信是恒等操作);**重入**拿到既有行时,
                 // 采信才是唯一正确的做法 —— 帧、定时器、落库三处从此只有一个 deadline、一个 approvalId、一份卡。
@@ -1184,7 +1292,9 @@ export class ToolApprovalCoordinator {
         let emitSettled = false;
         // #151 车2(D2 窗到期竞争者的返回值覆盖):askStore 在场且 expireAsk 赢 CAS ⇒ 强制返回 "unavailable"
         // (park 路由,G1 回路)——与旧形的 emit-race 覆盖判据(!emitSettled && lastOutcome==="expired")并存,
-        // 互不排斥(见方法尾的返回值分派)。askStore 缺席时恒 false,不影响 D1 零行为变化。
+        // 互不排斥(见方法尾的返回值分派)。
+        // ⚠️ #280 R-13 A1/A2 起,**askStore 缺席的 D1 窗到期臂与店报错臂也置位它**(park 路由是三条窗臂
+        // 共用的终局形),所以「缺席时恒 false」那句话已作废;三臂的差别只剩宿主自报(见各臂注)。
         let windowRouteUnavailable = false;
         let timer;
         let resolveAllowed;
@@ -1216,13 +1326,14 @@ export class ToolApprovalCoordinator {
          *    审计面由店的 decisionNote 承载)。理由只从 respond 腿流入(finishRespond),窗到期/取消/
          *    外部清算臂无人写理由,恒缺席。
          *  · 其余 ⇒ 裸 boolean(falsy 纪律)。
+         *
+         * #280 R-13 C:`windowRouteUnavailable` 那一位在 `deny` 政策下**不返回 `"unavailable"`**,而是落到
+         * 同一份 deny 成形上(自报/理由若在场照旧带上)—— 五臂一处施加的落点之一(见
+         * {@link ToolApprovalCoordinator.unattendedOutcome})。⚠️ 那一支**不能**直接 fall through 到下面的
+         * `settled.allowed` 分派:park 路由的语义是「持久终局压过一切」,而它可能与一个 `allowed:true` 的
+         * 本地落定值并存(窗赢了 CAS 而人的 respond 稍后才到的那个交错)—— fall through 会把它渲成放行。
          */
-        const shapeOutcome = (settled) => {
-            if (windowRouteUnavailable)
-                return "unavailable";
-            if (settled.allowed) {
-                return settled.updatedInput !== undefined ? { allow: true, updatedInput: settled.updatedInput } : true;
-            }
+        const shapeDeny = () => {
             if (hostSettled !== undefined || (denyReasonSettled !== undefined && denyReasonSettled !== "")) {
                 return {
                     allow: false,
@@ -1232,6 +1343,14 @@ export class ToolApprovalCoordinator {
             }
             return false;
         };
+        const shapeOutcome = (settled) => {
+            if (windowRouteUnavailable)
+                return this.unattendedOutcome() === false ? shapeDeny() : "unavailable";
+            if (settled.allowed) {
+                return settled.updatedInput !== undefined ? { allow: true, updatedInput: settled.updatedInput } : true;
+            }
+            return shapeDeny();
+        };
         const settle = (allowed, outcome, updatedInput, hostSettledBy, denyReason) => {
             if (done)
                 return;
@@ -1278,6 +1397,12 @@ export class ToolApprovalCoordinator {
          *   `DENIED|VOID` ⇒ deny。
          * 行读不出(店抖动)⇒ **有界重试**(指数退避,期间随时被真赢家 settle 就退出),用尽仍失败 ⇒
          * D5 fail-open 退回纯进程内语义(`settle(false,"expired")`)——绝不无限等。
+         *
+         * ⚠️ #280 施工纪要(留一句免得下一个人重走):codex R3-F1 的第一版修法是让 `expireAsk` 报错臂整段复用
+         * 本收敛,被**自己的全量跑**打回来了 —— 整套收敛会在几秒的退避里把终局让给并发的取消臂,而「行仍
+         * STREAM_PENDING」恰是那条臂的**期望态**(我们这次 expire 就是没做成),预算等于白烧;两条既有判据
+         * (codex-R2-2 / codex-R3-1)当场红。最终收窄成一次性窄读,见
+         * {@link ToolApprovalCoordinator.readDecidedForRecovery}。
          */
         const convergeFromDurableState = async (where) => {
             if (!this.askStore || askId === undefined)
@@ -1294,7 +1419,8 @@ export class ToolApprovalCoordinator {
                     if (done)
                         return;
                     if (row === null) {
-                        // 行不在(被 deleteByTask 清过 / 从未落盘)——没有可信终局可读,退回进程内语义。
+                        // 行不在(被 deleteByTask 清过 / 从未落盘)——没有可信终局可读,退回进程内语义
+                        // (调用方声明自己收尾时不落终局,见 opts 顶注)。
                         settle(false, "expired");
                         return;
                     }
@@ -1306,7 +1432,10 @@ export class ToolApprovalCoordinator {
                     }
                     const outcome = replayTerminalAskRow(row);
                     if (outcome === "unavailable") {
-                        windowRouteUnavailable = true; // park 语义 ⇒ onAsk 交 "unavailable"(G1 回路)
+                        // park 语义 ⇒ onAsk 交 `"unavailable"`(G1 回路)。#280 R-13 C:本臂与臂 (a) 是**同一件事**
+                        // (本 ask 的等待以「行进了投递面」收场,只是赢家可能在别的副本)⇒ `deny` 政策下随 (a) 一起
+                        // 改判 deny(自报缺席 —— 结束等待的不是本仓的窗)。理由全文见 unattendedOutcome 顶注。
+                        windowRouteUnavailable = true;
                         settle(false, "expired");
                     }
                     else if (outcome === true) {
@@ -1325,12 +1454,44 @@ export class ToolApprovalCoordinator {
             if (!done)
                 settle(false, "expired"); // 重试用尽:D5 fail-open,绝不挂死
         };
+        /**
+         * park 路由 + 结算的**单赢者**提交(🔴 #280 codex 对抗复审 R2-F1 [high],验真后修,红先复现器 =
+         * `test/unattended-approval-policy.test.ts` 的 R2-F1 格)。
+         *
+         * 病灶:`windowRouteUnavailable = true` 与受 `done` 保护的 `settle` 是**两句**,而 `shapeOutcome` 把
+         * 标志读在最前面。于是「回决先落定 → 迟到的窗臂再置标志」这条交错里(实测确定性可复现:窗先到期
+         * 让 `expireAsk` 在飞,回决晚一拍赢下 CAS 并**回了 200**,店的报错续接恰好排在 settle 之后、
+         * `askBroadcast` 尾部读标志之前),端点已经告诉人「已批准」、持久行也是 DECIDED(approve),
+         * `onAsk` 却交出 `"unavailable"`(deny 政策下是 `false`)—— 人批了、工具不跑、run 反而再挂起。
+         *
+         * 修法 = 让改判路由这件事**继承 `settle` 的单赢者语义**:没赢下这次结算就一个字都不改。
+         * ⚠️ 只给「不知道持久真源是什么」的两条臂用(D1 无店 / `expireAsk` 报错)。臂 (a)(`expireAsk` 真赢
+         * CAS)与向持久真源收敛那两处**故意不走它**:那里的 PARKING/PARKED 是**读出来的持久事实**,按设计
+         * (§D2「赢 ⇒ 无条件 park 路由」)压过一切本地落定值 —— 那条语义早于本件,不在本修射程内。
+         */
+        const settleParkRouteIfUnsettled = (hostSettledBy) => {
+            if (done)
+                return;
+            windowRouteUnavailable = true;
+            settle(false, "expired", undefined, hostSettledBy);
+        };
         const windowExpired = () => {
             void (async () => {
                 if (!this.askStore || askId === undefined || batchId === undefined) {
-                    // D1(无持久 ask 店)——终局**完全**由本仓这个窗决定,没有第二个写者。core 5.23.0 起如实自报
-                    // `"timeout"`:这条腿的窗归宿主,引擎观察不到它走完,不说就被记成「一个人拒绝了」。
-                    settle(false, "expired", undefined, "timeout");
+                    // D1(无持久 ask 店)——终局**完全**由本仓这个窗决定,没有第二个写者。
+                    //
+                    // 🔴 #280 R-13 A1(设计稿 §2;[4297] 现场那条 error 的铸点):本臂**改判 park 路由**
+                    // (`windowRouteUnavailable` ⇒ `"unavailable"`),与 forceParkNow 的无店支同形。park 的承载是
+                    // **core checkpoint**(`spec.durableApproval`),不是 server 的 ask 行 —— 所以无 askStore 的
+                    // 部署同样受益;两者皆缺席时 core 以 `approverUnavailable` 文案 deny(fail-closed 保持,
+                    // 文字从「窗走完」变「无 durable 门可停靠」,对模型更可行动)。
+                    //
+                    // `"timeout"` 自报**留着但只在 `deny` 政策下才读得到**(shapeOutcome 的 park 支在它之前短路):
+                    // 5.23 立这个词是为了防「没人理」被记成「一个人拒绝了」—— park 路由下那种误记结构上不存在
+                    // (根本不是 deny),词的存在理由被 park 语义整体取代;而 `deny` 政策下结束这次等待的**确实**
+                    // 是本仓的窗,词仍然如实,必须留。
+                    // 单赢者提交(codex R2-F1):人已落定 ⇒ 一个字都不改(D1 的 respond 是同步收尾,这条交错真实可达)。
+                    settleParkRouteIfUnsettled("timeout");
                     return;
                 }
                 try {
@@ -1339,15 +1500,20 @@ export class ToolApprovalCoordinator {
                         // 是这次事务真做出来的事实,必须补做 —— 否则兄弟闭包挂死、壳上留一张已作废的卡。
                         if (!late.won)
                             return;
-                        this.settleVoidedSiblings([askId, ...late.voidedSiblings]);
+                        // #280 codex R3-F2:两类分开收 —— 同 askId 重复注册的行是 **PARKING**(park 路由),
+                        // `voidedSiblings` 的行是 **VOID**(裸 expired)。混在一个名单里会让前者拿到裸 deny。
+                        this.settleSameAskIdParkRoute(askId);
+                        this.settleVoidedSiblings(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]);
+                        // 注册」那一支(顶注)。#280 codex R3-F2:那一支的行是 **PARKING** ⇒ 走 park 路由口,不能与
+                        // 行已 VOID 的兄弟混用同一个裸 expired 结算(否则同一条行两种 live 终局)。
+                        this.settleSameAskIdParkRoute(askId);
+                        this.settleVoidedSiblings(res.voidedSiblings);
                         // #151 车6 发射点①:降级连坐的兄弟被原子撤卡 ⇒ 壳上那些卡必须消失(live only)。
                         this.emitRevokeTo(aliveCtxs, buildRevokeFrame(batchId, res.voidedSiblings, "superseded_by_park", Date.now()));
                     }
@@ -1358,27 +1524,50 @@ export class ToolApprovalCoordinator {
                 }
                 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;
-                    // fail-open(D5):店抖动不挡窗到期的进程内机械照旧完成。自报仍是 `"timeout"` 且如实 —— 结束这次
-                    // 等待的**确实**是本仓的窗(店只是没能给出更精确的终局);deadline 那一支已经改判 park 路由,
-                    // 走不到用得上这个词的返回臂。
-                    settle(false, "expired", undefined, "timeout");
+                    // R3-1 原文只把**超时**支改判 park:超时 = 不知道那次 `expireAsk` 做没做成 —— 若它稍后提交,
+                    // 行就是 PARKING(已转投递面);此时把 onAsk 判成 deny 会与持久真源矛盾,而且违反 §3.3
+                    // 「窗不得把一个可 park 的 ask 拖成 abort-deny」。交 `"unavailable"`(park 路由)对两种结局都
+                    // 成立:真提交了 ⇒ 与行一致;没提交 ⇒ core 自己走 durable park,不劣于 deny。
+                    //
+                    // 🔴 #280 R-13 A2:**同一条理由逐字覆盖「店真报错」那一支** —— SQL 店的 `expireAsk` 同样是
+                    // 「事务提交 + 另一跳确认」的形,一次报错既可能是事务没做成,也可能是做成了而回报断了;两种
+                    // 结局下 park 路由都不劣于 deny。于是 deadline 与非 deadline 两支从此**同判**,分支消失。
+                    // fail-open(D5)不变:店抖动不挡窗到期的进程内机械照旧完成。`"timeout"` 自报的存留理由与 D1
+                    // 臂逐字同(park 政策下读不到,`deny` 政策下如实)。
+                    // 🔴 单赢者提交(codex R2-F1,红先复现):回决可能已经赢下 CAS 并**回了 200**,而这次报错的
+                    // 续接恰好排在它之后 —— 无条件置标志会把一次人类批准改判成 park/deny。没赢下结算就不改判。
+                    //
+                    // 🔴 **先看一眼行上有没有真决议**(codex R3-F1,三轮追问后改判采纳;红先钉 =
+                    // `test/unattended-approval-policy.test.ts` 的 R3-F1 两格):店报错 ≠ 没有真决议 —— **另一个
+                    // 副本**的回决腿可能刚把行判成 `DECIDED`,而本臂此前直接按政策收窗,等于把一次已经落盘的
+                    // 人类决议丢掉(工具不跑、run 还要人再批一次)。
+                    //
+                    // ⚠️ **只消费 `DECIDED`,而且只读一次**(收窄是刻意的,第一版写成整套
+                    // `convergeFromDurableState` 被自己的全量跑打回来了,两条既有判据当场红):
+                    //  · 只读一次(一次带墙钟的 `getAsk`)⇒ 不把整段退避预算烧在「行仍 STREAM_PENDING」这个**期望
+                    //    态**上,也不会在那几秒里把终局让给并发的取消臂(codex-R2-2 钉的形当场翻)。
+                    //  · 只认 `DECIDED` ⇒ `VOID`(批内兄弟被撤卡)/`PARKING`/读不出 三态的处置**逐字不动**,
+                    //    它们各自的判据早有钉(codex-R3-1 的迟到提交形、settleVoidedSiblings 的 F29 语义)。
+                    //    本修只补「人的真决议不许被丢」这**一条**缺口,不顺手改别人的语义。
+                    const decided = await this.readDecidedForRecovery(askId);
+                    if (decided !== undefined && !done) {
+                        settle(decided, decided ? "allowed" : "denied");
+                        return;
+                    }
+                    settleParkRouteIfUnsettled("timeout");
                 }
             })();
         };
         // #241:断连强制转 park(接口注释见 PendingApproval.forceParkNow)。有店 ⇒ 走窗到期同路(expireAsk
         // CAS+兄弟撤卡,赢=unavailable/输=向持久真源收敛——人已决就尊重人);无店 ⇒ 进程内直接改判 park 路由。
+        // ⚠️ #280 R-13 之后无店支**仍不**复用 windowExpired,理由换了一条:两臂的 park/deny 方向如今同判
+        // (A1),但**宿主自报**不同——窗到期臂说得出 `"timeout"`(结束等待的是本仓的窗),断连臂说不出
+        // (结束等待的是连接没了,那个词会把「任务的流没了」谎成「没人答」)。自报只在 `deny` 政策下可见。
         const forceParkNow = () => {
             if (done)
                 return;
             if (!this.askStore || askId === undefined || batchId === undefined) {
-                windowRouteUnavailable = true;
-                settle(false, "expired");
+                settleParkRouteIfUnsettled(); // 单赢者提交(自报缺席:结束等待的是断连,不是窗)
                 return;
             }
             windowExpired();
@@ -1507,6 +1696,9 @@ export class ToolApprovalCoordinator {
         const pendingEntry = {
             settle,
             forceParkNow,
+            // #280 codex R3-F2:同 askId 重复注册的 park 路由收尾口(自报缺席 —— 结束这份注册等待的不是它
+            // 自己的窗,是「这只 askId 已经有了投递面终局」这件事)。
+            settleParkRoute: () => settleParkRouteIfUnsettled(),
             owner: primary.owner,
             ctxTaskId: primary.taskId,
             originCtx: primary,
@@ -1519,6 +1711,8 @@ export class ToolApprovalCoordinator {
             // #204 件7:治理标随条目落定(回决侧第二道门的输入,理由见字段顶注)。读的是**并集后**的值
             // (`effectiveGovernanceForced`),不是本地 peek —— 幂等命中既有行那条路上,只有并集才是武装的。
             ...(effectiveGovernanceForced ? { governanceForced: true } : {}),
+            // #287:安全类出身位随条目落定(回决侧拒铸 grant 的输入;真才带,同 governanceForced 形)。
+            ...(req.requiresRealApproval === true ? { requiresRealApproval: true } : {}),
             ...(askId !== undefined && batchId !== undefined ? { askId, batchId } : {}),
         };
         selfEntry = pendingEntry; // 供 settle() 结算时把自己从 pendingByAskId 的 Set 里摘除(上方顶注)
@@ -1544,6 +1738,15 @@ export class ToolApprovalCoordinator {
         const cardFrame = askId !== undefined && cardForFrame !== undefined
             ? buildApprovalRequestFrame({ askId, taskId: origin.taskId, approvalId: wireApprovalId, card: cardForFrame, expiresAtMs: persistedExpiresAtMs, nowMs: Date.now() })
             : undefined;
+        // #288([4429]②):旧族帧补窗三键 —— 必须在这里(emit 前、ensureAsk 后)而不是 frame 字面量里:
+        // `persistedExpiresAtMs` 在有店重入既有行时才被行值覆盖(F2 修),字面量铸造点还拿不到最终值;
+        // 这里与 cardFrame 用**同一个数**,两族帧的到期读数从此同源(锚=此刻的服务器钟)。
+        {
+            const serverNowMs = Date.now();
+            frame.expiresAtMs = persistedExpiresAtMs;
+            frame.serverNowMs = serverNowMs;
+            frame.expiresInMs = Math.max(0, persistedExpiresAtMs - serverNowMs);
+        }
         /**
          * 一条连接的**两种**投递结果。分开记是 codex 交叉复审 F1(2026-08-06 真 finding)的修:
          *  · `legacy` —— 旧 `tool_approval` 帧送达没有。它单独决定**闭合帧**发不发(没见过开卡帧的连接
@@ -1619,7 +1822,9 @@ export class ToolApprovalCoordinator {
                             emitFailed = true;
                             settle(false, "expired");
                             // round3:同批兄弟被远程撤卡,本地同步收尾;round5 追加自己的 askId(同精神,windowExpired 侧注)。
-                            this.settleVoidedSiblings([askId, ...res.voidedSiblings]);
+                            // #280 codex R3-F2:同 askId 那一支的行是 PARKING ⇒ park 路由口;兄弟(VOID)裸 expired。
+                            this.settleSameAskIdParkRoute(askId);
+                            this.settleVoidedSiblings(res.voidedSiblings);
                         }
                         // 干净地输:什么都不做(见上方顶注)。
                     }
@@ -1659,20 +1864,23 @@ export class ToolApprovalCoordinator {
                 .catch(() => undefined);
         }
         // emit 全灭 = 卡从未送达任何人(≠人拒绝/TTL 走人)——同属「无活人可达」类 ⇒ "unavailable" 交 durable
-        // park。
+        // park(#280 R-13 C 臂(e):`deny` 政策下同样改判 deny,取值走 unattendedOutcome 那**一个**口)。
         if (emitFailed)
-            return "unavailable";
+            return this.unattendedOutcome();
         // #151 车2(D2/D3):窗到期赢了持久 CAS ⇒ 强制 park 路由,不看 emit 是否已经确认送达——D2 原话
         // 「赢 ⇒ settle + onAsk 返回 "unavailable"」是无条件的,与下面 emit-race 覆盖判据(供 store 缺席/
-        // emit 尚未确认两种场景)并存、互不排斥。askStore 缺席时本判据恒 false,不影响 D1 零行为变化。
+        // emit 尚未确认两种场景)并存、互不排斥。askStore 缺席时本判据在 #280 之前恒 false;A1 之后 D1 窗到期
+        // 臂也会置位它(park 路由是三臂共用的终局),两条路因此汇到同一个成形口。
+        // 🔴 经 {@link shapeOutcome} 而不是就地 `return "unavailable"`:政策与宿主自报的判据只写一份
+        // (deny 政策下 (b)(c) 要带 `settledBy:"timeout"`,就地返回会把它丢掉)。
         if (windowRouteUnavailable)
-            return "unavailable";
+            return shapeOutcome(settled);
         // emit 广播尚未有任何一路确认完成(既非成功也非已知失败)就被 TTL/abort 抢先判定 ⇒ 无法确认卡是否
         // 曾送达任何人,不可扣一个武断的「deny」终局——按 G1 回路交 "unavailable"(同 emit 失败同一处置,
-        // core [1559]三 确认方向)。respond() 落地的人类裁决(outcome allowed/denied)不受影响,原因见本
-        // 方法顶注。
+        // core [1559]三 确认方向;`deny` 政策同臂(e)一并改判)。respond() 落地的人类裁决(outcome
+        // allowed/denied)不受影响,原因见本方法顶注。
         if (!emitSettled && lastOutcome === "expired")
-            return "unavailable";
+            return this.unattendedOutcome();
         // [1458] 编辑放行对象臂 + core 5.23.0(#187/#114②)宿主自报臂 —— 两条判据都在
         // {@link shapeOutcome} 里,与早退出口**共用同一份**(codex 复审 round2:此前这里与早退臂各写一份
         // 等价分派,本批的 `settledBy` 于是只加到了其中一份上)。
@@ -1883,10 +2091,14 @@ export class ToolApprovalCoordinator {
         // grant 落桥内店)= true;allow_session 但无 sessionId(adhoc 无会话,记不了)= false(壳不得渲染
         // 「本 session 全放行」);普通 allow/deny 不涉 remember = 字段省略。durable decide 腿的同名回显
         // (`routes/approvals-assistant.ts` 的 `rememberApplied`)语义对齐。
+        // #287([4434]② P0 的写侧配对臂):安全类 ask(requiresRealApproval)的卡上点了 allow_session,
+        // 只放行**这一次**调用、绝不铸 session grant——铸了就等于把「必须逐次真人批」的位翻译成「批一次
+        // 解锁整族」。rememberApplied=false 诚实回显(壳不得渲染「本 session 全放行」)。读侧配对臂
+        // (askBroadcast 短路跳过)保证即使别的普通 ask 铸过同族 grant,安全类 ask 也照样出卡。
         let rememberApplied;
         if (parsed.value === "allow_session")
-            rememberApplied = Boolean(entry.sessionId);
-        if (parsed.value === "allow_session" && entry.sessionId) {
+            rememberApplied = Boolean(entry.sessionId) && entry.requiresRealApproval !== true;
+        if (parsed.value === "allow_session" && entry.sessionId && entry.requiresRealApproval !== true) {
             // Bounded remember (insertion-order evict). 修2 scope: the grant is keyed by THIS ask's own capability
             // category — a Write/Edit-family ask unlocks the fs-write family for the (owner, session); ANY other tool's
             // allow_session unlocks only that same tool. A cheap non-write ask can therefore never become a session-wide

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sema-agent/server",
-  "version": "7.33.0",
+  "version": "7.34.0",
   "description": "Sema Server — the server/API implementation layer for Sema, wiring core, registry, model providers, and cloud agent execution. Built on @sema-agent/core.",
   "type": "module",
   "license": "BUSL-1.1",
@@ -54,7 +54,7 @@
     "build:binary:run-local:darwin-arm64": "bun build --compile --target=bun-darwin-arm64 src/run-local.ts --outfile dist/run-local-darwin-arm64"
   },
   "dependencies": {
-    "@sema-agent/core": "^5.42.0",
+    "@sema-agent/core": "^5.43.0",
     "@sema-agent/registry-core": "^0.18.0",
     "e2b": "^2.28.0",
     "libsodium-wrappers": "^0.8.4",