@sema-agent/server 7.10.0 → 7.12.0

package/dist/auth-keys.js

@@ -8,37 +8,82 @@
  * (verifyApprovalHmac / verifyPrincipalJwt) stay in ./approval-hmac.ts and ./principal-jwt.ts; consumers import these four names from HERE ([2354] 兼容面全清).
  */
 /** Parse APPROVAL_HMAC_KEYS — a sema-registry-managed, rotating key-SET, as a JSON array of {kid,key,status}.
- *  Empty / unset / unparseable ⇒ `[]` ⇒ HMAC verification is OFF (D-G inactive; back-compat, BFF-only door). */
-export function parseApprovalHmacKeys(raw) {
+ *  Empty / unset / unparseable ⇒ `[]` ⇒ HMAC verification is OFF (D-G inactive; back-compat, BFF-only door).
+ *  fail-closed 语义与改前**逐字相同**;新增的只有 `onReject`(#210:每一条被丢弃的条目都要说出来)。 */
+export function parseApprovalHmacKeys(raw, onReject) {
     if (!raw)
         return [];
+    let v;
     try {
-        const v = JSON.parse(raw);
-        if (!Array.isArray(v))
-            return [];
-        return v.filter((k) => !!k && typeof k.kid === "string" && typeof k.key === "string");
+        v = JSON.parse(raw);
     }
     catch {
+        // ⚠️ 解析器自带的 message **不能**转述:V8 的 `JSON.parse` 报错里嵌了输入片段
+        // (`Unexpected token 'T', "TOP_SECRET"... is not valid JSON`),而这条 env 的内容就是对称密钥 ——
+        // 把它写进 boot 日志等于把密钥前缀印出来。只说「不是合法 JSON」,定位靠 env 名本身。
+        onReject({ index: "-", reason: "not valid JSON (value withheld: this env holds secrets)" });
         return [];
     }
+    if (!Array.isArray(v)) {
+        onReject({ index: "-", reason: "not a JSON array of {kid,key,status} entries" });
+        return [];
+    }
+    const out = [];
+    v.forEach((raw, i) => {
+        const e = raw;
+        if (!e || typeof e !== "object") {
+            onReject({ index: i, reason: "entry is not an object" });
+            return;
+        }
+        const bad = ["kid", "key"].filter((f) => typeof e[f] !== "string");
+        if (bad.length > 0)
+            onReject({ index: i, reason: `missing/non-string field(s): ${bad.join(", ")}` });
+        else
+            out.push(e);
+    });
+    return out;
 }
 /** Parse PRINCIPAL_JWT_PUBKEYS — a JSON array of {kid,alg,key,status}. Empty/unset/malformed ⇒ [] ⇒ no trust
- *  anchor ⇒ the direct door cannot open (D-G inactive). Each entry must have kid + a pinned alg + a PEM key. */
-export function parsePrincipalJwks(raw) {
+ *  anchor ⇒ the direct door cannot open (D-G inactive). Each entry must have kid + a pinned alg + a PEM key.
+ *  #210: fail-closed 语义逐字不变,但每条被丢弃的条目经 `onReject` 报出(序号 + 缺陷字段名,不带值)——
+ *  这里的 key 是**公**钥,但 reason 仍只说字段名,与 HMAC 那条同形(两个出口的口径不该分岔)。 */
+export function parsePrincipalJwks(raw, onReject) {
     if (!raw)
         return [];
     const ALGS = new Set(["EdDSA", "RS256", "ES256"]);
+    let v;
     try {
-        const v = JSON.parse(raw);
-        if (!Array.isArray(v))
-            return [];
-        return v.filter((k) => {
-            const e = k;
-            return !!e && typeof e.kid === "string" && typeof e.key === "string" && typeof e.alg === "string" && ALGS.has(e.alg);
-        });
+        v = JSON.parse(raw);
     }
     catch {
+        // 同 parseApprovalHmacKeys:不转述 V8 的 message(它嵌输入片段)。这一口装的是**公**钥,但两个出口
+        // 的口径不该分岔 —— 一个「视情况才脱敏」的规矩,迟早会在错的那一侧被抄走。
+        onReject({ index: "-", reason: "not valid JSON (value withheld)" });
+        return [];
+    }
+    if (!Array.isArray(v)) {
+        onReject({ index: "-", reason: "not a JSON array of {kid,alg,key,status} entries" });
         return [];
     }
+    const out = [];
+    v.forEach((row, i) => {
+        const e = row;
+        if (!e || typeof e !== "object") {
+            onReject({ index: i, reason: "entry is not an object" });
+            return;
+        }
+        const bad = ["kid", "key"].filter((f) => typeof e[f] !== "string");
+        // alg 单列:缺席与「不在闭集」是两种手滑,但都必须点名 `alg` —— 运维看到字段名才知道去改哪一格
+        // (alg-confusion 防线就挂在这条钉上,静默滤掉等于防线自己消失了没人知道)。
+        if (typeof e.alg !== "string")
+            bad.push("alg");
+        else if (!ALGS.has(e.alg))
+            bad.push(`alg (must be one of: ${[...ALGS].join(", ")})`);
+        if (bad.length > 0)
+            onReject({ index: i, reason: `missing/invalid field(s): ${bad.join(", ")}` });
+        else
+            out.push(e);
+    });
+    return out;
 }
 //# sourceMappingURL=auth-keys.js.map

package/dist/boot/adoption.d.ts

@@ -0,0 +1,30 @@
+import type { StoreBackend } from "../plugins/store-backend.js";
+export interface AdoptionBootCtx {
+    backend: StoreBackend | undefined;
+    logger: {
+        info?(msg: string, meta?: unknown): void;
+        warn?(msg: string, meta?: unknown): void;
+        error?(msg: string, meta?: unknown): void;
+    };
+    now?: () => number;
+}
+export interface AdoptionBootReading {
+    /** 本次扫到的在飞行数(0 = 常态)。 */
+    scanned: number;
+    /** 推到终态的弧。 */
+    resumed: string[];
+    /** 推不动的弧(锁被别的副本持着,或还差一步)—— 留在库里,下一个副本/下一次读面继续推。 */
+    stalled: string[];
+    /** 续跑时撞上目的地冲突而落 rejected 终态的弧。 */
+    rejected: string[];
+    /** 推不动**且抛了异常**的弧(逐弧兜住 —— 一条坏行不许绑架其它弧的恢复)。 */
+    failed: string[];
+    /** 扫描本身失败(库不可达等)。**不吞** —— 消息进启动日志。 */
+    error?: string;
+}
+/**
+ * boot 期的在飞收编扫描。无 SQL 后端 ⇒ 零动作(收编面在那种部署上本来就 501)。
+ * 绝不抛:一次库抖动不该拒掉整台 worker 的启动,但**必须**留下响亮读数(`error` 位 + error 级日志)。
+ */
+export declare function runAdoptionBootScan(ctx: AdoptionBootCtx): Promise<AdoptionBootReading>;
+//# sourceMappingURL=adoption.d.ts.map

package/dist/boot/adoption.js

@@ -0,0 +1,57 @@
+/**
+ * design/183 I6(server 同族)—— **每副本 boot 必查收编日志**。
+ *
+ * 🔴 为什么这道门必须存在:phase 真源住 SQL 正是为了「发起 host 在两条腿之间被摧毁 ⇒ 接棒副本按日志
+ * 续跑」。可是**没有人会替它按下重试** —— 运维那次 POST 的响应早就丢了。所以每个副本起来时都扫一遍
+ * 在飞行:能推就推到终态,推不动就**响亮**留痕(禁静默跳过 —— 静默跳过等于把半迁移状态带进服务期,
+ * 那正是 I6 存在的理由)。
+ *
+ * 🔴 为什么是「续跑或响亮拒」而不是「拒启」:半迁移的收编**是可恢复的**(每条腿幂等,phase 单调),
+ * 拒启只会让一个能自愈的状态变成一次停机。拒启留给不可恢复的装配谎言(boot/org-memory.ts 那类)。
+ * 与之对称:续跑失败**不吞异常** —— 它落一条 error 级留痕并把 outcome 记进返回值,调用方(main)
+ * 把读数打进启动日志,运维在启动行里就能看见「这台副本上还有 N 条收编没走完」。
+ *
+ * 阻塞性:扫描在**监听之前**跑完(main 的调用点)。一条弧的推进是几条 UPDATE,毫秒级;库里正常状态下
+ * 在飞行数为 0,一次 `WHERE state='in_flight'` 的索引点查而已。
+ */
+import { createAdoptionRunner } from "../adoption/runner.js";
+/**
+ * boot 期的在飞收编扫描。无 SQL 后端 ⇒ 零动作(收编面在那种部署上本来就 501)。
+ * 绝不抛:一次库抖动不该拒掉整台 worker 的启动,但**必须**留下响亮读数(`error` 位 + error 级日志)。
+ */
+export async function runAdoptionBootScan(ctx) {
+    const store = ctx.backend?.adoptionLog?.();
+    if (!store)
+        return { scanned: 0, resumed: [], stalled: [], rejected: [], failed: [] };
+    const runner = createAdoptionRunner({
+        store,
+        dialect: ctx.backend?.kind === "pg" ? "pg" : "tidb",
+        now: ctx.now ?? Date.now,
+        logger: ctx.logger,
+    });
+    try {
+        const inFlight = await store.listInFlight();
+        if (inFlight.length === 0)
+            return { scanned: 0, resumed: [], stalled: [], rejected: [], failed: [] };
+        ctx.logger.warn?.("adoption_in_flight_on_boot", {
+            count: inFlight.length,
+            ids: inFlight.map((r) => r.adoptionId),
+            note: "design/183 I6: resuming in-flight identity adoptions before this replica starts serving",
+        });
+        const out = await runner.resumeInFlight();
+        const reading = { scanned: inFlight.length, ...out };
+        if (reading.stalled.length > 0 || reading.rejected.length > 0 || reading.failed.length > 0) {
+            ctx.logger.error?.("adoption_boot_scan_incomplete", reading);
+        }
+        else {
+            ctx.logger.info?.("adoption_boot_scan_resumed", reading);
+        }
+        return reading;
+    }
+    catch (err) {
+        const error = err instanceof Error ? err.message : String(err);
+        ctx.logger.error?.("adoption_boot_scan_failed", { error });
+        return { scanned: 0, resumed: [], stalled: [], rejected: [], failed: [], error };
+    }
+}
+//# sourceMappingURL=adoption.js.map

package/dist/boot/coordinators.d.ts

@@ -15,11 +15,15 @@ import { ToolApprovalCoordinator } from "../tool-approval.js";
 import { SendUserFileEmitter } from "../capabilities/send-user-file-tool.js";
 import { TaskEnvRegistry } from "../capabilities/sandbox-file-send.js";
 import type { StoreBackend } from "../plugins/store-backend.js";
+import type { RuleConsentLane } from "../rules-consent.js";
 export interface LiveCoordinatorsCtx {
     config: ServiceConfig;
     logger: Logger;
     backend: StoreBackend | undefined;
     sendUserFileTaskEnvs: TaskEnvRegistry | undefined;
+    /** #154 车二:持久化权限规则的同意车道(main.ts 与 `RunnerDeps.permissionRuleStore` **同源**于
+     *  `backend.permissionRule()` 的同一个返回值)。在场 ⇒ ask 帧投 `ruleSuggestions` + 回决可兑付。 */
+    ruleConsent: RuleConsentLane | undefined;
 }
 export declare function createLiveCoordinators(ctx: LiveCoordinatorsCtx): {
     elicitation: ElicitationCoordinator | undefined;

package/dist/boot/coordinators.js

@@ -8,7 +8,7 @@ import { withLedgerRecording } from "../plugins/send-file-ledger.js";
 import { basename, resolve } from "node:path";
 import { stat as fsStat, readFile as fsReadFile } from "node:fs/promises";
 export function createLiveCoordinators(ctx) {
-    const { config, logger, backend, sendUserFileTaskEnvs } = ctx;
+    const { config, logger, backend, sendUserFileTaskEnvs, ruleConsent } = ctx;
     // E23 (shell-host contract): inbound MCP elicitation coordinator (live-only HITL). Present ONLY when MCP_ELICITATION_ENABLED
     // — absent ⇒ onElicit is not wired ⇒ core advertises no elicitation capability to any server (fail-closed). Shared
     // by the runner (the onElicit seam) and the HTTP layer (the respond route + the per-run ALS context wraps).
@@ -71,6 +71,8 @@ export function createLiveCoordinators(ctx) {
             // X-2 写侧准入门两帽(协议未上场时门本身不参与,见 ToolApprovalCoordinator.admit)。
             admitMaxPerTask: config.streamApproval.admitMaxPerTask,
             admitMaxPerOwner: config.streamApproval.admitMaxPerOwner,
+            // #154 车二:同意车道(缺席 = 规则店没装配 ⇒ 帧上零候选、回决的 persistRule 如实拒)。
+            ...(ruleConsent !== undefined ? { ruleConsent } : {}),
         })
         : undefined;
     // SendUserFile(真 CC 契约,clay 2026-07-14)两种 lane 形态,其余缺席=诚实(工具不进 roster):

package/dist/boot/parked-revive-gate.d.ts

@@ -1,5 +1,6 @@
-import { type BackgroundAgentRecord, type ToolExecuteContext } from "@sema-agent/core";
+import { type BackgroundAgentRecord, type RunnerDeps, type ToolExecuteContext } from "@sema-agent/core";
 import type { ServiceConfig } from "../config.js";
+import type { RunnerDepsOnAsk } from "./runner-deps.js";
 import { type ApprovalBaselineConfigView, type DeploymentGovernanceConfigView, type LiveQuestionFace } from "../deployment-governance.js";
 import { type SandboxPathEnvSlots } from "./deferred-sandbox-path-env.js";
 /** 本腿读的配置切面(`ServiceConfig` 结构满足)。两个构造口各自的切面 + lane 判别式读的 `remoteExec`。 */
@@ -15,9 +16,50 @@ export interface ApprovalExemptionProbe {
 export interface ParkedReviveGateDeps {
     /** ⚠️ **活引用**:热改字段(autonomy/commandPolicy/守卫集/审批四旋钮)每次赎回现读,见下方「禁 memoize」。 */
     readonly config: ParkedReviveGateConfigView;
-    /** #152:活体 AskUserQuestion 面。赎回腿今天无 ALS ctx ⇒ 判 ask,与原形同判。 */
+    /** #152:活体 AskUserQuestion 面。赎回腿今天无 ALS ctx ⇒ 判 ask,与原形同判。
+     *  ⚠️ 它同时是**决议链元数据** `contentMandate` 的唯一判据(见 {@link mandatePostureOf})。 */
     readonly question: LiveQuestionFace | undefined;
+    /**
+     * 部署级活体审批席 —— `RunnerDeps.onAsk` 的**同源铸法**(main.ts 递 `createRunnerDepsOnAsk(toolApproval)`,
+     * 单一属主同 boot/runner-deps.ts)。
+     *
+     * ⚠️ **本仓确有 per-task `spec.onAsk` 装配点**(codex 对抗复审 R1-中1 验真纠正 —— 别照抄
+     * `createRunnerDepsOnAsk` 头注那句「bg/resume 两条腿没有 per-task 装配点」,那句话的射程只是那两条腿):
+     * `http/routes/tasks.ts` 的宿主 sync/stream 腿在装配点写 `spec.onAsk = toolApproval.boundAsk({owner,
+     * taskId, sessionId, legKey…})`(windowZero 形则写一个恒返 `"unavailable"` 的闭包)。core 冻的是
+     * `spec.onAsk ?? deps.onAsk`,所以那条腿冻下去的是**带身份的** bound 席,不是这一格。
+     *
+     * 这对本腿的两个用途分别意味着什么:
+     *  · **`durableMandate` 判据(承重,见 {@link mandatePostureOf})—— 不受影响**:两个装配点是**同一个
+     *    条件**的两种表达(`spec.onAsk` 的两支都在 `deps.toolApproval` 在场时才写,windowZero 支写的也是
+     *    函数),所以「席位在不在场」这个**布尔**在 spec 位与 deps 位上恒等。core 的
+     *    `isLiveApproverSeat` 只判 `typeof === "function"` ⇒ 本腿算出的位与 park 时冻的位逐字相同,摘要对得上。
+     *  · **重建条目的 `onAsk` 席位本身 —— 是一个诚实的降级,不是等价替换**:bound 席携的身份
+     *    (owner/taskId/sessionId/legKey/腿时限)是**宿主那条腿**的,park 时未持久化 ⇒ 跨副本重建不出来。
+     *    交这一格的效果:赎回腿没有 ALS 上下文,`ToolApprovalCoordinator.ask` 第一行 `if (!ctx) return
+     *    "unavailable"`(tool-approval.ts)⇒ 继承 ask 恒走 core 的 `approverUnavailable` 回路 = **再 park
+     *    一次给人**。它**到不了**宿主原来那张卡(那是残余,与「客户端折叠层重建不出」同族);它也**不会**
+     *    错投到别处(无 ctx 就直接返回,`askBroadcast` 根本不执行 —— codex 提出的「按赎回腿归因/投递」
+     *    这条机制经亲读证伪)。
+     *    为什么仍然要交:席位缺席 + `durableMandate` 为 false(装了活体席的部署就是这一形)⇒ 继承 ask 只剩
+     *    headless auto-deny,比「再问人一次」严且哑。交了之后最坏也是 park,方向 fail-safe。
+     */
+    readonly approverSeat: RunnerDepsOnAsk | undefined;
     readonly approvalExemptionStore: ApprovalExemptionProbe | undefined;
+    /**
+     * A-010.1 —— core `RunnerDeps.runtimeCapsResolver` 的**同一只**(main.ts 的 `runtimeCapsResolver`,
+     * 单一属主同 `boot/runtime-caps.ts`)。重建条目的第三位决议链元数据 `autoModeArmed` 的唯一判据是
+     * per-principal 的 `RuntimeCaps.autoMode`,而它只有 center 解得出 —— 见 {@link autoModePostureOf}。
+     * 缺席(无 center 的部署 / dry-run)⇒ core 侧 `runtimeCaps` 也恒 undefined ⇒ 该位在 park 时也从不置位,
+     * 两侧同为「不供」,逐字零行为差。
+     *
+     * 类型从 **core 的载体位**推导(同 `boot/runner-deps.ts:94` 的先例,理由同 {@link RebuiltInheritedGate}:
+     * 手抄一个等价签名会让 core 改这条 seam 的那天变成静默漂移而不是编译期事件)。
+     */
+    readonly resolveRuntimeCaps?: RunnerDeps["runtimeCapsResolver"];
+    /** `RunnerDeps.autoMode` 分类器面(信任门半场)在不在场 —— core 的武装条件是
+     *  `runtimeCaps.autoMode === true` **∧** 这一面在场,两个半场缺一不武装(prepare-task 原式)。 */
+    readonly autoModeSeatMounted?: boolean;
     readonly logger: {
         info(event: string, fields?: Record<string, unknown>): void;
         warn(event: string, fields?: Record<string, unknown>): void;
@@ -36,6 +78,9 @@ export interface ParkedReviveGateDeps {
  * 事件(载体键集钉见 test/parked-revive-gate-wiring.test.ts)。
  */
 export type RebuiltInheritedGate = NonNullable<NonNullable<NonNullable<ToolExecuteContext["reviveClaim"]>["parkedResume"]>["inheritedGate"]>;
+/** 重建链的**单层条目**形 —— 同样从载体推导(理由同 {@link RebuiltInheritedGate}:core 又加一个
+ *  能收紧的槽时,本仓的编译面要看得见)。 */
+export type RebuiltParentConstraint = NonNullable<RebuiltInheritedGate["parentConstraints"]>[number];
 /**
  * 赎回腿的父约束链重建(design/181 件二)。
  *
@@ -66,13 +111,17 @@ export type RebuiltInheritedGate = NonNullable<NonNullable<NonNullable<ToolExecu
  * 时点语义(成文进 docs/ASSISTANT-WIRE-CONTRACT.md,免运维当 bug 报):
  *  · toolPolicy 轴 = **当前** config(与 resume 重折一致,收紧与放松都被兑现——放松是一次显式运维动作);
  *  · shellGate 轴 = core 取 max(live, park 时 seed)—— 收紧兑现、放松**不**兑现(fail-safe)。
- *  · `onAsk` 不供,但**这不等于 auto-deny**(codex R3-中1 验真纠正):带 `durableMandate` 的继承层
- *    判 `ask` 时,core 只要还看得见 checkpoint 店 + durable 审批配置就把它**重新浮回 durable 门**
- *    (再 park 一次,人再批一次);deny 只是「durable 设施不在场」的兜底臂。⛔ 但**不是无条件**
- *    (codex R4-中1):core 对挂起链计 `suspendCount`,到 `maxSuspends`(默认 5)即终止任务而不再 park。
+ *  · `autoModeArmed` 轴(A-010.1)= 按**当前** per-principal entitlement 现解(见 {@link autoModePostureOf});
+ *    与 toolPolicy 轴同族:挂起期间权益被撤/被授 ⇒ 摘要对不上 ⇒ core pre-CAS 响亮拒,不静默换姿势跑。
+ *  · `onAsk` 轴 = 部署的活体审批席(`deps.approverSeat`),**在场即供**:park 时那一层冻的就是它。
+ *    席位缺席的部署上不供,而**这不等于 auto-deny**(codex R3-中1 验真纠正):此形恒带
+ *    `durableMandate`(见 {@link mandatePostureOf}),继承层判 `ask` 时 core 只要还看得见 checkpoint 店
+ *    + durable 审批配置就把它**重新浮回 durable 门**(再 park 一次,人再批一次);deny 只是「durable
+ *    设施不在场」的兜底臂。⛔ 但**不是无条件**(codex R4-中1):core 对挂起链计 `suspendCount`,到
+ *    `maxSuspends`(默认 5)即终止任务而不再 park。
  *  · 客户端每请求 settings 折出来的层(`settings.permissions` 的 allow/deny/ask、模式派生的 fs-write
  *    ask 门、scratchpad 豁免……整类)park 时未持久化 ⇒ 重建不出。§2.3 已披露的残余,机制面有特征化钉
  *    (test/parked-revive-e2e.test.ts);真 settings→park→赎回的端到端钉未建(候件,随收口件一起)。
  */
-export declare function createParkedReviveInheritedGate(deps: ParkedReviveGateDeps): (row: BackgroundAgentRecord) => RebuiltInheritedGate;
+export declare function createParkedReviveInheritedGate(deps: ParkedReviveGateDeps): (row: BackgroundAgentRecord) => Promise<RebuiltInheritedGate>;
 //# sourceMappingURL=parked-revive-gate.d.ts.map

package/dist/boot/parked-revive-gate.js

@@ -7,7 +7,9 @@
  * 治理矩阵的第三维消费腿)。装配次序契约不变:main.ts 仍在同一位置构造,构造条件逐字保持。
  */
 import { join } from "node:path";
-import { NodeExecutionEnv } from "@sema-agent/core";
+import { createAutoModeDecider, NodeExecutionEnv } from "@sema-agent/core";
+import { recordFailOpen } from "../observability/fail-open.js";
+import { decodeCheckpointScope } from "../security.js";
 import { createApprovalBaselinePolicy, createDeploymentGovernanceInputs, } from "../deployment-governance.js";
 import { applyRuntimeGovernance } from "../runtime-governance.js";
 import { DeferredSandboxPathEnv, isSandboxPathAdjudicationLane, sandboxPathEnvSlots } from "./deferred-sandbox-path-env.js";
@@ -57,18 +59,26 @@ function hostGateCwd(config, localRoot) {
  * 时点语义(成文进 docs/ASSISTANT-WIRE-CONTRACT.md,免运维当 bug 报):
  *  · toolPolicy 轴 = **当前** config(与 resume 重折一致,收紧与放松都被兑现——放松是一次显式运维动作);
  *  · shellGate 轴 = core 取 max(live, park 时 seed)—— 收紧兑现、放松**不**兑现(fail-safe)。
- *  · `onAsk` 不供,但**这不等于 auto-deny**(codex R3-中1 验真纠正):带 `durableMandate` 的继承层
- *    判 `ask` 时,core 只要还看得见 checkpoint 店 + durable 审批配置就把它**重新浮回 durable 门**
- *    (再 park 一次,人再批一次);deny 只是「durable 设施不在场」的兜底臂。⛔ 但**不是无条件**
- *    (codex R4-中1):core 对挂起链计 `suspendCount`,到 `maxSuspends`(默认 5)即终止任务而不再 park。
+ *  · `autoModeArmed` 轴(A-010.1)= 按**当前** per-principal entitlement 现解(见 {@link autoModePostureOf});
+ *    与 toolPolicy 轴同族:挂起期间权益被撤/被授 ⇒ 摘要对不上 ⇒ core pre-CAS 响亮拒,不静默换姿势跑。
+ *  · `onAsk` 轴 = 部署的活体审批席(`deps.approverSeat`),**在场即供**:park 时那一层冻的就是它。
+ *    席位缺席的部署上不供,而**这不等于 auto-deny**(codex R3-中1 验真纠正):此形恒带
+ *    `durableMandate`(见 {@link mandatePostureOf}),继承层判 `ask` 时 core 只要还看得见 checkpoint 店
+ *    + durable 审批配置就把它**重新浮回 durable 门**(再 park 一次,人再批一次);deny 只是「durable
+ *    设施不在场」的兜底臂。⛔ 但**不是无条件**(codex R4-中1):core 对挂起链计 `suspendCount`,到
+ *    `maxSuspends`(默认 5)即终止任务而不再 park。
  *  · 客户端每请求 settings 折出来的层(`settings.permissions` 的 allow/deny/ask、模式派生的 fs-write
  *    ask 门、scratchpad 豁免……整类)park 时未持久化 ⇒ 重建不出。§2.3 已披露的残余,机制面有特征化钉
  *    (test/parked-revive-e2e.test.ts);真 settings→park→赎回的端到端钉未建(候件,随收口件一起)。
  */
 export function createParkedReviveInheritedGate(deps) {
-    const { config, question, approvalExemptionStore, logger, localRoot } = deps;
+    const { config, question, approvalExemptionStore, logger, localRoot, approverSeat } = deps;
     const slots = deps.slots ?? sandboxPathEnvSlots;
-    return (row) => {
+    return async (row) => {
+        // A-010.1:三位决议链元数据。**async 的唯一理由**就是其中两位要按 principal 现解 entitlement
+        // (core 的 resolver 座本身也是 sync-or-async),而这条腿的消费点(parked-decide 的 `decideParkedAgent`)
+        // 从来就在 async 里,「席位必须同步」是本文件此前自设的约束,不是结构事实。
+        const metadata = await chainMetadataOf(deps, row);
         // lane 分形与 resolve-spec 同一判别式(单一属主,取值处只此一个)。
         // 🔑 沙箱腿的 slot 键 = **row.sessionId**(子代自己的会话,design/181 §2.2 裁定):revive 后 core 以
         //    该 sessionId 铸 env 并注册 slot(subagent → prepare-task → 工厂装饰器),这个键真能绑上。
@@ -101,11 +111,170 @@ export function createParkedReviveInheritedGate(deps) {
         // 治理段无可施加时 applyRuntimeGovernance 原样返回 base ⇒ 基线本身即为链(恒非 undefined,无需断言)。
         // shellGate 只在治理段真产出档位时出现在载体上(缺席 = 本次没有 live 值可交,core 用 seed 兜底)。
         return {
-            parentConstraints: [{ policy: governed.toolPolicy ?? baseline, durableMandate: true }],
+            parentConstraints: [
+                {
+                    policy: governed.toolPolicy ?? baseline,
+                    ...(approverSeat !== undefined ? { onAsk: approverSeat } : {}),
+                    ...metadata,
+                },
+            ],
             ...(governed.shellGate !== undefined ? { shellGate: governed.shellGate } : {}),
         };
     };
 }
+/**
+ * 重建条目的**决议链元数据**(core 5.22.0 F-012)—— 三位的逐字重算,**一次** entitlement 现解喂全三位
+ * (第三位与两位 mandate 的 `forceDurableGate` 项读的是同一次 caps,分两次解会开一个「同一条链里两位读到
+ *  不同代 entitlement」的窗)。
+ *
+ * 为什么它承重:5.22.0 把 re-supply 契约从 count 换成 `cpv1:` 内容摘要
+ * (`constraintChainDigest`),而摘要 **把这两位卷了进去**。park 时那一层记的是什么,赎回腿就必须供
+ * 什么——供多了、供少了都是 `resume.parent_constraint_mismatch` 响亮拒(pre-CAS,checkpoint 留
+ * pending)。**不许**为了让摘要对上而回读 checkpoint 里记的那两位再原样回声:那等于把「重算出同一条链」
+ * 换成「抄一份自证」,摘要的防篡改语义当场归零。
+ *
+ * core 的原式(`prepare-task.js` 的 `inheritedGateForChildren`):
+ * ```
+ * durableMandate = runtimeCaps.forceDurableGate || (spec.durableApproval !== undefined && !isLiveApproverSeat(spec.onAsk      ?? deps.onAsk))
+ * contentMandate = runtimeCaps.forceDurableGate || (spec.durableApproval !== undefined && !isLiveQuestionFace(spec.onQuestion ?? deps.onQuestion))
+ * ```
+ * 本仓三项对位:
+ *  · `spec.durableApproval !== undefined` —— 本工厂**只在** `config.durableApproval` 为真时构造
+ *    (main.ts 的构造条件逐字),故这一项在本函数射程内恒成立;
+ *  · 审批席 = `spec.onAsk ?? deps.onAsk` 的**在场性**。本仓两个装配点(deps 级
+ *    `createRunnerDepsOnAsk`、per-task 级 `routes/tasks.ts` 的 `boundAsk`)受**同一个**条件闸
+ *    ——`toolApproval` 协调器在不在场——所以这个布尔在两位上恒等,`approverSeat` 在不在场即判据。
+ *    ⚠️ 判据是**在场性**不是同一只闭包:身份不同不影响摘要(全文见 {@link ParkedReviveGateDeps.approverSeat});
+ *  · 问答席 = resolve-spec 的 `liveQuestionFace`:在场 ⇒ spec 不 stamp sentinel、`deps.onQuestion` 的
+ *    协调器生效(`isLiveQuestionFace` 判 true);缺席 ⇒ spec stamp `QUESTION_AWAITS_RESUME`
+ *    (该 sentinel 被 `isLiveQuestionFace` 判 false)。两支都归结为 `question` 在不在场。
+ *
+ * ✅ **原「已披露残余」销账(A-010.1 同车)**:`runtimeCaps.forceDurableGate`(center 逐 principal 的
+ * 授权位)此前写着「在本装配点解不出来——resolver 是 async 而重供席位的形是同步 `(row) => gate`」。那条
+ * 阻塞是**本文件自设**的,不是结构事实:唯一的消费点(`parked-decide.ts` 的 `decideParkedAgent`)本来
+ * 就在 async 里。席位随本件改成 async 之后,该位与 `autoModeArmed` 走同一条 caps 现解腿一并补齐 —— 否则
+ * 「该位为真 + 部署装了活体席」这个组合上 park 记 true 而本腿供 false,摘要恒不匹配、这批 principal 的
+ * parked 卡同样永不可赎(与 A-010.1 同族同因的第二个总失效面)。
+ *
+ * ⚠️ 时点语义与 toolPolicy 轴同族:两位都按**当前** entitlement 现解,挂起期间被撤/被授 ⇒ 摘要对不上
+ * ⇒ core pre-CAS 响亮拒(带 `parked_resume.startup_failed` 码可观测),绝不静默按新姿势跑。
+ */
+async function chainMetadataOf(deps, row) {
+    const caps = await resolveCapsFor(deps, row);
+    const forced = caps?.forceDurableGate === true;
+    return {
+        ...(forced || deps.approverSeat === undefined ? { durableMandate: true } : {}),
+        ...(forced || deps.question === undefined ? { contentMandate: true } : {}),
+        ...autoModePostureOf(deps, row, caps),
+    };
+}
+/**
+ * 本行 principal 的 entitlement 现解(三位元数据共用**一次**)。
+ *
+ * principal 从哪来:`row.scope`。承重的不是「两个写入方碰巧写了同一个字符串」,而是**取数结构**:
+ * `findParkedAgentForCheckpoint` 走的是 `agentStore.listByScope(cp.scope, …)` 这条**按 scope 分区**的
+ * 查询(parked-decide.ts),所以任何能走到本函数的行都满足 `row.scope === cp.scope` —— 这是构造式的,
+ * 不是巧合。而 `cp.scope` 由 `boot/resolve-spec.ts` 写成 `encodeCheckpointScope(auth.principal)`
+ * (legacy resume 腿反向读回 `principal: decodeCheckpointScope(cp.scope)` 是同一等式的另一半),
+ * 故 `decodeCheckpointScope(row.scope)` 就是那条 run 的 `spec.principal`,与 core 喂给
+ * `runtimeCapsResolver(spec.principal)` 的**同一个**值 —— 摘要两侧因此解到同一份 caps。
+ *
+ * ⚠️ 别把 `row.scope` 当成「和 `cp.scope` 同一个写入方铸的」:**不是**。写行那一侧(core `subagent.js`
+ * 的 `ctx.principal ?? opts.background.scope`,本仓 `capabilities/scenarios.ts` 填字面 `"default"`)用的是
+ * `principal ?? "default"` 这套约定,与 `encodeCheckpointScope` 的 `"_"` 哨兵**不同源**。有 principal 时
+ * 两套折出同一个字符串(encode 只在 null/undefined 时才替换),所以上面那条等式成立;**匿名** run 上两者
+ * 分别是 `"default"` 与 `"_"`,分区查询直接落空 ⇒ 本函数根本到不了(decide 退回 legacy resume 腿,
+ * parked-decide.ts 自述的「未命中=零回归」形)。谁哪天去弥合那个匿名未命中,必须**连本函数一起**重看:
+ * 那时 `decodeCheckpointScope("default")` 会解出字符串 `"default"` 并把它当租户名递进 resolver。
+ *
+ * resolver 缺席(无 center / dry-run)⇒ core 侧 `runtimeCaps` 也恒 undefined ⇒ 这两位在 park 时也从不
+ * 由 caps 置位 ⇒ 逐字零行为差。resolver 抛错(契约上它自己 fail-closed 且不抛)⇒ 当作没解出来:元数据
+ * 位按「无 caps」算 ⇒ 与 park 记的对不上就响亮拒,**绝不**静默按更松的姿势赎回。
+ */
+async function resolveCapsFor(deps, row) {
+    if (deps.resolveRuntimeCaps === undefined)
+        return undefined;
+    try {
+        return await deps.resolveRuntimeCaps(decodeCheckpointScope(row.scope));
+    }
+    catch (err) {
+        // 留痕是必需的:否则「这批卡为什么突然赎不动」查无痕迹。
+        deps.logger.warn("parked_revive_caps_unresolved", { handle: row.handle, err: err instanceof Error ? err.message : String(err) });
+        return undefined;
+    }
+}
+/**
+ * A-010.1 —— 重建条目的**第三位**决议链元数据 `autoModeArmed`(core 5.22.0 F-012 与两位 mandate 同车)。
+ *
+ * ## 病(本函数存在的唯一理由)
+ * core 的摘要口(`tool-policy.js` `constraintChainEntryOf`)把**三**位卷进 `cpv1:` 摘要,而判据是
+ * 「条目上有没有 `autoMode` 这个键」:park 时 `prepare-task.js` 的 `inheritedGateForChildren` 写
+ * `...(autoModeDecider !== undefined ? { autoMode: { decider } } : {})`,赎回时 `runtask.js` 的 pre-CAS
+ * 门按 `pc.autoMode !== undefined` 逐字重算。本腿此前只供 policy/onAsk/两位 mandate,**从不供** autoMode
+ * ⇒ auto-mode 权益 principal 的每一条跨副本 parked 赎回摘要恒不匹配、`resume.parent_constraint_mismatch`
+ * 响亮拒、卡永不可赎(方向 fail-safe,但功能面对这批 principal 是整条失效)。
+ *
+ * ## core 的原式(逐字对位,不绕过)
+ * ```
+ * if (runtimeCaps?.autoMode === true && deps.autoMode !== undefined) autoModeDecider = createAutoModeDecider(…)
+ * ```
+ * 两个半场本仓分别对位:
+ *  · `deps.autoMode !== undefined` ⇒ {@link ParkedReviveGateDeps.autoModeSeatMounted}(装配面恒挂,见
+ *    `boot/runner-deps.ts` 的 `autoMode:{onBreakerOpen}`——**信任门**,单挂它武装不了任何东西);
+ *  · `runtimeCaps.autoMode === true` ⇒ {@link resolveCapsFor} 按**本行的 principal** 现解(时点语义、
+ *    principal 从哪来、resolver 缺席/抛错怎么判,全在那只函数的头注)。
+ *
+ * ## ⛔ 已披露残余:decider 的**身份**跨不了进程(P-DEBT,不是等价替换)
+ * 摘要只看键在不在,但 core 在赎回后的每一次继承 ask 上会**真的调** `pc.autoMode.decider`
+ * (`prepare-task.js` 的继承包装器,顺序:分类器 → 冻结审批席)。而那只 decider 是祖先任务上的活闭包
+ * (绑着它自己的 session 转写窗 + brain),跨副本重建不出来 —— 与本文件 `approverSeat` 那格「诚实的降级」
+ * 同族。本腿交的是 **core 自己的构造器**铸的一只 decider,其 classify 腿如实拒答 ⇒ core 收到
+ * `unavailable`(它自己 `.catch(() => ({kind:"unavailable"}))` 的同一形)⇒ **不产生任何自动裁决**,原样
+ * 落到祖先冻结审批席那条链上(本腿的席位又是无 ALS 的降级形 ⇒ `approverUnavailable` ⇒ 再 park 给人)。
+ * 方向:分类器本会 `allow` 的调用改成问人(**更严**);本会 `block` 的也改成问人(**不是自动放行**,但
+ * 确实比自动拒松一档)。所以它按 P-DEBT 记债而不是当合法兜底 —— tag
+ * `server.parked-revive.ancestor-classifier-unreachable`,逐次计数 + 一次性 warn,收口件二选一:core 把
+ * 分类器判据持久进链条目,或让祖先 decider 有可跨进程重建的形。
+ */
+function autoModePostureOf(deps, row, caps) {
+    if (deps.autoModeSeatMounted !== true || caps?.autoMode !== true)
+        return {};
+    return { autoMode: { decider: createUnreachableAncestorClassifier(deps, row) } };
+}
+/**
+ * 祖先分类器的**跨进程降级形**(全部理由在 {@link autoModePostureOf} 的残余段)。
+ *
+ * 内核用 core 自己的 `createAutoModeDecider` 铸 —— 超时/熔断/verdict 词表(`unavailable` 这个词本身)
+ * 都归 core 单一属主,本仓只提供一条**如实拒答**的 classify 腿,绝不在此手抄 `{kind:"unavailable"}`。
+ * `failureThreshold: 1` 让熔断一拍即开:第一次被咨询就把一次性告警喊出来,之后每次 `decide` 在 core 内
+ * 早返 `unavailable`(不再进 classify、不再起 15s 定时器)。
+ *
+ * 🔴 计数**必须**打在外层 `decide` 上、不能打在 `classify` 里:熔断开了以后 core 早返、classify 再也不
+ * 被调用,计数打在里面就永远只记 1 —— 而这个 tag 的语义(和普查表里那一行的文字)是「**丢了祖先分类器
+ * 判决的继承 ask 次数**」。打在里面等于让遥测读数与它自称的含义不是一回事,债就在账上消失了。
+ */
+function createUnreachableAncestorClassifier(deps, row) {
+    const inner = createAutoModeDecider({
+        failureThreshold: 1,
+        classify: async () => {
+            throw new Error("the ancestor task's auto-mode classifier is a live closure over that task's own transcript/brain — it cannot be " +
+                "reconstructed on a fresh replica, so this inherited layer has no classifier verdict to give (the call falls " +
+                "through to the ancestor's frozen approver chain)");
+        },
+        onBreakerOpen: () => deps.logger.warn("parked_revive_ancestor_classifier_unreachable", {
+            handle: row.handle,
+            sessionId: row.sessionId,
+            note: "an inherited ancestor layer was auto-mode armed at park time; its classifier does not survive the process boundary — inherited asks resolve on the approver chain (durable park) instead of a classifier verdict",
+        }),
+    });
+    return {
+        breakerOpen: () => inner.breakerOpen(),
+        decide: async (input, signal) => {
+            recordFailOpen("server.parked-revive.ancestor-classifier-unreachable", row.handle);
+            return inner.decide(input, signal);
+        },
+    };
+}
 /** host 腿的裁决 env(真 fs;构造是纯字段赋值,不 spawn)。**每次赎回现铸**——与「禁 memoize」同因:
  *  cwd 占位读的是活 config 的 `localDataRoot`。 */
 function createHostAdjudicationEnv(config, localRoot) {

package/dist/boot/permission-rules-audit.d.ts

@@ -0,0 +1,49 @@
+/**
+ * #203 §3(design/203 v2 §6 F4 的**残余采纳**)—— 默认 ON 的**休眠行审计**。
+ *
+ * 🔴 这条审计存在的唯一理由:`PERMISSION_RULES_ENABLED` 的默认值在本车从 OFF 翻成 ON,而**旋钮翻转
+ * 与规则行的寿命是两条独立的时间线**。三张表自 #154 车二起就随中央 `ensureSchema` 建、并且从来没有被
+ * 清过,所以下面这两类部署在升级的那一刻会突然带着**既有**规则行开始放行:
+ *   · 曾经把旋钮开过一段时间又关掉的部署(行留在库里,只是没人读);
+ *   · 从旧库恢复/克隆出来的部署(行跟着数据一起来的)。
+ * 对运维来说,这是「我什么都没改,worker 却开始少问我了」——一次**放宽面**上的静默变化。审计做的事
+ * 很小但是承重:在启动日志里把它说出来,让「少问」是一条能被读到的因果,而不是一次玄学。
+ *
+ * ── 三条判据,逐条有理由 ────────────────────────────────────────────────────────────────────────
+ *  ① **店缺席 ⇒ 整条不上场**(零 I/O、零行)。店缺席包括:显式关旋钮、`local` 车道没接 File 店的旧
+ *     部署、以及压根没有 backend 的 env-only worker。没有店就没有行,谈不上唤醒。
+ *  ② **零桶 ⇒ 不打行**。一条「0 条既有规则随默认 ON 激活」的行是纯噪音:它对读日志的人不传递任何
+ *     可行动的信息,却让真正有东西被唤醒的那一行变得不显眼。
+ *  ③ **运维**显式**表过态(`PERMISSION_RULES_ENABLED` 被设成 true 或 false)⇒ 不打行**。那些行本来
+ *     就是活的(或者旋钮被显式关着、店根本没装配),默认值翻不翻转对它们零影响 —— 说「随默认 ON
+ *     激活」是**假话**,而在启动日志里说假话比不说更坏。判据用 `permissionRulesEnabledExplicit`
+ *     (config.ts 与 `dbBackendExplicit` 同姿势),不是猜。
+ *
+ * ── 失败方向 ────────────────────────────────────────────────────────────────────────────────────
+ * 数不出来(库抖动 / 文件读不了)⇒ **不拒启、也不编一个 0 出来**:返回 `undefined` + 一条 warn。
+ * 这是一条纯诊断面(它不参与任何放行/拒绝判决),所以它的降级方向是「安静地不知道」而不是「谎报
+ * 零」——`{ buckets: 0 }` 会被下游读成「确认没有休眠行」,那是把一次读失败伪装成一个结论。
+ * 因为它零判决,这条 fail-open 不属于 `docs/FAIL-OPEN-CENSUS.md` 的安全轴 P 类,故不占 `recordFailOpen`
+ * 的标签;它的可见性由那条 warn 承担。
+ */
+/** 审计只需要一只桶计数口——**刻意**不吃整个 `PermissionRuleStoreBundle`:诊断面对店的其余能力
+ *  一无所知也不该知道,窄口让测试能用四行 fixture 驱动真实现同一段代码。 */
+export interface DormantRuleCounter {
+    /** 库里已存在的规则**桶**(一只 owner 一只桶)数量。 */
+    countBuckets(): Promise<number>;
+}
+export interface DormantRuleAuditCtx {
+    /** 已装配的规则店束;`undefined` = 本部署没有规则店(判据 ①)。 */
+    stores: DormantRuleCounter | undefined;
+    logger: {
+        info(msg: string, meta?: unknown): void;
+        warn?(msg: string, meta?: unknown): void;
+    };
+    /** 运维是否**显式**设过 `PERMISSION_RULES_ENABLED`(判据 ③)。 */
+    explicit: boolean;
+}
+/** boot 期一次性调用。返回读数(`undefined` = 没店 / 数不出来),绝不抛。 */
+export declare function auditDormantPermissionRules(ctx: DormantRuleAuditCtx): Promise<{
+    buckets: number;
+} | undefined>;
+//# sourceMappingURL=permission-rules-audit.d.ts.map