@sema-agent/server 7.99.0 → 7.101.0

package/dist/approval-card.d.ts

@@ -21,7 +21,7 @@
  * 没有方法、没有捕获的行为。
  */
 import { z } from "zod";
-import { READ_ROOT_CANDIDATE_DIR_MAX, type AskEvidenceAbsence, type AskRequest as CoreAskRequest, type ReadRootGrantCandidate, type RuleOffer } from "@sema-agent/core";
+import { READ_ROOT_CANDIDATE_DIR_MAX, type AskEvidenceAbsence, type AskRequest as CoreAskRequest, type PendingAction as CorePendingAction, type ReadRootGrantCandidate, type RuleOffer } from "@sema-agent/core";
 import type { AskRow } from "./plugins/approval-ask-store-sql.js";
 /** 模型自由文本(`sourceAgentName` / `delegation.agentName`)的限长(设计稿 §6.2)。设计 §3.1 把
  *  「限长 + 脱敏」写成 **server 新增责任**(引擎无此层):spawning model 挑的名字是自由文本,
@@ -351,12 +351,97 @@ export declare const RuleOffersAbsenceSchema: z.ZodEnum<{
     lane_cannot_speak: "lane_cannot_speak";
     shadowed: "shadowed";
 }>;
+/**
+ * `ruleOffersAbsence` 座的**三态读数**(S-663 codex r1 起;此前是 {@link readRuleOffersAbsence} 函数体内的两步)。
+ * 一只 schema、一处解析,两个读者各自处置「**在场却读不出**」(集外词 / 非串值 = 世代差或第三方 producer):
+ *  · 展示面 {@link readRuleOffersAbsence}(活卡帧 / `card_json`)—— 按缺席丢并计 F 类(卡上少一行解释 ≪ 卡上出现生词);
+ *  · 耐久 `/decide` 腿的 remember 判据(`tool-approval.ts` 的 `parkRowStandingAnswerFacts` 的 `mandated` 一格,读 park 行上的
+ *    孪生座 `PendingAction.tool_approval.ruleOffersAbsence`,core 同一 factory 铸)—— 判不出是不是强制 ⇒ **按强制**(fail-closed)。
+ * 同一个词在两处方向相反是刻意的:展示面的最坏后果是少一行字,权限面的最坏后果是一张会话级免询问。
+ * 本函数**不计数**(计不计、计哪个 tag 是读者的处置,不是读数)。
+ */
+export type RuleOffersAbsenceSeat = {
+    readonly state: "absent";
+} | {
+    readonly state: "word";
+    readonly word: RuleOffersAbsence;
+} | {
+    readonly state: "unreadable";
+    readonly raw: unknown;
+};
+export declare function readRuleOffersAbsenceSeat(x: unknown): RuleOffersAbsenceSeat;
 /**
  * `AskRequest.ruleOffersAbsence`(core [ref] 修②)的**边界窄读** —— 活卡帧与 `card_json` 的唯一铸造点
  * (与 {@link readProbeCause} 同款分工),两面结构性同值。闭集词 verbatim(非内容族,零 redact);
  * 形不合/缺席 ⇒ 不铸键(缺席不是断言 —— 它同时覆盖「有 offers」与结构性无车道的门,core 契约逐字)。
+ * 解析在 {@link readRuleOffersAbsenceSeat}(与耐久腿判据共用一只 schema)。S-700 起第三个读者:运维队列行经
+ * {@link parkRowFacts} 读寄存行上的 park 孪生座(`PendingAction.tool_approval.ruleOffersAbsence`,core 同一个 factory 铸的同一
+ * 闭集)—— 同一只 schema、同一个集外 tag,三面结构性同值;集外 detail 经 {@link outOfSetDetail}(只读值,从不调用值)。
  */
 export declare function readRuleOffersAbsence(req: unknown): RuleOffersAbsence | undefined;
+/**
+ * park 行上两只 **`?: true` 孪生座**的名(core d.ts:「present (`true`) ⇔ … Absent otherwise (never `false`)」):
+ *  · `requiresRealApproval`([ref])—— 这一问只有**真人**清得掉(连一揽子席也不得答;蕴含下一位);
+ *  · `mandated`(#1079,core 7.31.0;S-663 二段 / S-723)—— 没有任何持久规则、也没有任何站着的答案退得掉这一问
+ *    (`AskRequest.mandated` 的 park 孪生,core 从行的规则报价工厂读的**同一份**清障事实铸)。
+ * 两位同形同律 ⇒ 同一只读法 {@link readParkRowTrueSeat}(一处解析,名字是参数,不是两只各写一遍的函数)。
+ * 型从 core 寄存行上取键(`keyof ToolApprovalPark` 约束):core 改名 / 退役任一位 ⇒ 这里 tsc 红。
+ */
+export type ParkRowTrueSeat = Extract<keyof ToolApprovalPark, "requiresRealApproval" | "mandated">;
+/**
+ * park 行 `?: true` 座的读数(NP-1 起;S-663 二段起名字是参数)—— **`=== true` 严判**,`false` 与其它值读作缺席
+ * (core d.ts「Absent otherwise (never `false`)」;与 core `summarizeCheckpoint` 同一条判法:它把两位都筛成字面 `true`)。
+ * `kind` 由调用方先判(本函数只读这一位)。两个读者共用这一只,解析单源、处置各归读者(与 {@link readRuleOffersAbsenceSeat}
+ * 同一条分工):展示投影 {@link parkRowFacts}(队列行顶层展开)与耐久 `/decide` 腿的 remember 判据(`tool-approval.ts`
+ * 的 `parkRowStandingAnswerFacts`)。这两位在两处方向相同(在场才算、读不出 = 缺席)⇒ 不需要三态、不计数(inbox 面对同一形
+ * 同样静默缺席,两面同律);也因此权限面读它们**不经** `parkRowFacts` —— 那只展示投影顺手读 `ruleOffersAbsence` 并对集外词计
+ * 展示面的 F 类 tag,而权限面对同一格是 fail-closed 的另一种处置(S-663 codex r1 钉「权限面不计展示面 tag」)。
+ */
+export declare function readParkRowTrueSeat(toolApproval: object, seat: ParkRowTrueSeat): boolean;
+/** core 寄存行的 `tool_approval` 臂(park 行事实全部住在这一臂上;其余臂没有工具字段)。 */
+type ToolApprovalPark = Extract<CorePendingAction, {
+    kind: "tool_approval";
+}>;
+/**
+ * 🔴 S-700 P1(client-core CC-180 / cli L-652 的根子;板 [ref] 订正 → [ref] 立案)—— **park 行事实**:
+ * 运维队列行(`GET /v1/approvals` + `/stream`)顶层展开的那几位。型**从 core 寄存行派生,不手抄**(S-249 同一条
+ * 纪律):core 改名 / 退役任一位 ⇒ 这里 tsc 红;这一位与 {@link RuleOffersAbsence}(从 `AskRequest` 派生)两个
+ * 联合漂开 ⇒ {@link parkRowFacts} 的返回处 tsc 红(core 说两座是同一个 factory 铸的同一闭集,本仓照此钉)。
+ *
+ * 两只店的 `PendingCheckpoint` **直接继承本型**(`extends`),于是 core 再给这一臂加一位同类事实时,两店与路由零改 ——
+ * S-663 二段(core #1079,7.31.0)的 `mandated` 就是这么到货的。要改的三处,编译器逐一点名:这张 Pick 表加一个名 +
+ * {@link parkRowFacts} 函数体一行 + `trace/core-keyset-guard.ts` ⑧b 的 EXCLUDED 簿删掉这个名(⑧b 的事实段**从本型派生**,
+ * 8D-1 / 车OC 起单写者 —— 名字进了本表却还躺在 EXCLUDED 里 ⇒ `_NoDoubleBookParkArmQueue` 当拍红);`test/park-row-facts.test.ts`
+ * 的 `FACT_KEYS` 对本型双向围栏,少列一名同样编译红。
+ * core d.ts 说三位彼此独立:`requiresRealApproval`(只有人能清 —— 蕴含 `mandated`)、`mandated`(没有规则能清)、
+ * `ruleOffersAbsence`(报价车道有什么可给;「never a substitute for this one」)—— 投影逐位照投,不互推。
+ */
+export type ParkRowFacts = Pick<ToolApprovalPark, "requiresRealApproval" | "ruleOffersAbsence" | "mandated">;
+/**
+ * S-700 —— park 行事实的**唯一投影**(`pendingAction` 是寄存行上 core 铸的那一只,读自持久层 ⇒ `unknown`)。
+ *
+ * 病:core 在寄存行 `PendingAction.tool_approval` 上铸的「卡读者该看的事实」(core [ref] 原话:「the SAME fact,
+ * restated where a card reader looks for it」)中 `requiresRealApproval` 经 core `summarizeCheckpoint` 早就上了 inbox(`ruleOffersAbsence`
+ * 不在 core 的 `CheckpointSummary` 上),而运维队列的两只店
+ * `listPending` 是逐键手工组行、一位都没取 ⇒ 同一张卡「inbox 上看得到只有真人能清、队列上看不到」,壳的 park
+ * 卡因此恒不知道这件事(client-core 0.82.4 `26fca98b` 的透传在真部署上恒不触发)。
+ *
+ * 判据(每一条都是 core d.ts 的消费纪律,不是本仓自定):
+ *  · **kind 先判**(「Every consumer that reads the tool fields MUST branch on `kind` first」)—— 非对象 / 缺席 /
+ *    非 `tool_approval` 臂 ⇒ `{}`,那些臂上出现的同名键不是这两位;
+ *  · `requiresRealApproval` / `mandated` —— 经 {@link readParkRowTrueSeat}(`=== true` 严判,真才带;`false` 与其它值读作
+ *    缺席,「Absent otherwise (never `false`)」)。与 core `summarizeCheckpoint` 逐字同一条判法 ⇒ inbox 行与队列行对同一张卡
+ *    同答(`test/park-row-facts.test.ts` 钉)。不计数:inbox 那一面对同一形同样静默缺席,两面同律;
+ *  · `ruleOffersAbsence` —— 经 {@link readRuleOffersAbsence}(活卡帧 / `card_json` 同一只 schema、同一个集外 tag):
+ *    park 孪生座与同步座是 core 同一个 factory 铸的同一闭集,不另起第二份词表;
+ *  · 缺席 ≠ false:两位都只在「真」时在场,消费端读**在场**。
+ *
+ * 🔴 **这是展示/分诊投影,不是权限判据**(core 对两位的定性都是 display metadata:「the resume belts keep reading
+ * the gate's own bit」)。本投影对「在场却读不出」的方向是**缺席**(卡上少一行 ≪ 卡上出现生词);一条要从
+ * `ruleOffersAbsence` 推「强制」的**权限**判据需要的是三态(读不出 ⇒ 按强制,fail-closed),方向相反,所以权限面
+ * 不许拿本函数的产物去推强制 —— 两者共用的是 schema,不是折叠。
+ */
+export declare function parkRowFacts(pendingAction: unknown): ParkRowFacts;
 /** S-114(core 7.4.0 [ref])—— 回落卡的计数与窗。`limit` 是**闭二词**(core d.ts 逐字),两个计数是
  *  非负整数,`autoDenyAfterMs` 是 core 契约里的 `0..2147483647` 非负整数(`0` = 本卡不武装窗:部署把
  *  旋钮关了,或 TOTAL 档的卡按 [ref]① 恒 0 等人)。四成员**全必填**——core 的 `DenialLimitFallback` 上

package/dist/approval-card.js

@@ -236,15 +236,49 @@ export function readRuleEvidence(req) {
 const RULE_OFFERS_ABSENCE_VALUES = ["mandated", "lane_cannot_speak", "shadowed"];
 export const RuleOffersAbsenceSchema = z.enum(RULE_OFFERS_ABSENCE_VALUES);
 const RuleOffersAbsenceEnvelopeSchema = z.object({ ruleOffersAbsence: RuleOffersAbsenceSchema.optional() });
-export function readRuleOffersAbsence(req) {
-    const parsed = RuleOffersAbsenceEnvelopeSchema.safeParse(req);
+export function readRuleOffersAbsenceSeat(x) {
+    const parsed = RuleOffersAbsenceEnvelopeSchema.safeParse(x);
     if (parsed.success)
-        return parsed.data.ruleOffersAbsence;
-    const raw = req !== null && typeof req === "object" ? req.ruleOffersAbsence : undefined;
-    if (raw === undefined)
-        return undefined;
-    recordFailOpen("server.approval-card.closed-word-out-of-set", `ruleOffersAbsence=${redactSecrets(String(raw)).slice(0, 40)}`);
-    return undefined;
+        return parsed.data.ruleOffersAbsence === undefined ? { state: "absent" } : { state: "word", word: parsed.data.ruleOffersAbsence };
+    const raw = x !== null && typeof x === "object" ? x.ruleOffersAbsence : undefined;
+    return raw === undefined ? { state: "absent" } : { state: "unreadable", raw };
+}
+export function readRuleOffersAbsence(req) {
+    const seat = readRuleOffersAbsenceSeat(req);
+    switch (seat.state) {
+        case "word":
+            return seat.word;
+        case "absent":
+            return undefined;
+        case "unreadable":
+            recordFailOpen("server.approval-card.closed-word-out-of-set", `ruleOffersAbsence=${outOfSetDetail(seat.raw)}`);
+            return undefined;
+    }
+}
+function outOfSetDetail(raw) {
+    if (typeof raw === "string")
+        return redactSecrets(raw).slice(0, 40);
+    if (raw === null)
+        return "<null>";
+    if (Array.isArray(raw))
+        return "<array>";
+    if (typeof raw === "object" || typeof raw === "function")
+        return `<${typeof raw}>`;
+    return String(raw).slice(0, 40);
+}
+export function readParkRowTrueSeat(toolApproval, seat) {
+    const v = seat in toolApproval ? toolApproval[seat] : undefined;
+    return v === true;
+}
+export function parkRowFacts(pendingAction) {
+    if (typeof pendingAction !== "object" || pendingAction === null || !("kind" in pendingAction) || pendingAction.kind !== "tool_approval")
+        return {};
+    const ruleOffersAbsence = readRuleOffersAbsence(pendingAction);
+    return {
+        ...(readParkRowTrueSeat(pendingAction, "requiresRealApproval") ? { requiresRealApproval: true } : {}),
+        ...(readParkRowTrueSeat(pendingAction, "mandated") ? { mandated: true } : {}),
+        ...(ruleOffersAbsence !== undefined ? { ruleOffersAbsence } : {}),
+    };
 }
 const DenialLimitFallbackSchema = z
     .object({

package/dist/approval-policy-settlement.d.ts

@@ -0,0 +1,31 @@
+/**
+ * S-702 / S-706 —— 「无人可答」的**政策感知终态 claim**:全仓唯一一只(NP-2 的政策结算抽出来,四处调用,不写第二份)。
+ *
+ * 一句话:一只没人答的 ask 在持久 ask 行上**落什么终局**,由部署政策(`UNATTENDED_APPROVAL_POLICY`)一处决定 ——
+ *  · `park` ⇒ `expire` 意图:STREAM_PENDING→PARKING、批转投递面、同批流内兄弟连坐 VOID(park 路由的单位是整批,core 随后
+ *    durable park,对账收敛器再把行绑到 checkpoint 上);
+ *  · `deny` ⇒ `refuse` 意图:**按 ask 作用域**把这一只行 CAS 成 DECIDED(deny) + `settled_by="policy"`,不碰批、不连坐兄弟
+ *    (deny 政策下没有 park 路由这个单位,7.99.0 铸的整腿批存量行同判)。落行的来源词是店侧常量 `POLICY_REFUSAL_DECISION`,
+ *    协调器交给 core 的部署政策拒对象读的是**同一个**常量 ⇒ 同 ask 重入 / 收敛后重入由 `outcomeOfDecidedRow` 读回同一个对象,
+ *    不退化成裸 `false`(core 的 onAsk 契约里那是「一个人拒了」,可停批)。
+ *
+ * 四个调用点(都调这一只,谁也不自己挑意图):
+ *  1. live 腿 —— 窗到期臂的终局 claim(`tool-approval.ts` `windowExpired`,经 claim 阶梯 `resolveLocalOutcome`);
+ *  2. live 腿 —— emit 全灭臂的终局 claim(同上,`emitFailed` 支);
+ *  3. 两兜底臂 —— `ensureAsk` 行不可用 / ensure 身份不定(`tool-approval.ts` `landUnattendedOutcome`,只在交给 core 的是**结算**时
+ *     调:park 路由不是结算,行留给投递面的既有机器,park 行为逐字不变),以及后者迟到落盘那条行的收尾;
+ *  4. 崩溃恢复腿 —— 对账收敛器段二的孤儿 STREAM_PENDING 代打(`approval-reconciler.ts`):它就是窗到期竞争者在崩溃后的补位,
+ *     同一只 claim、同一个转移(S-706 之前它无条件 `expireAsk`,deny 部署上崩溃后行进 PARKING,run 完成后成不带来源的 DENIED)。
+ *
+ * 形:纯委托 —— 店的原子终局 claim(`ApprovalAskStore.claimTerminal`,三 twin 一台 CAS 机器,律 2)+ 政策→意图的穷举映射。
+ * 答案自足(律 1):赢 ⇒ `{claimed:true, voidedSiblings}`(refuse 恒空名单);输 ⇒ 携行真相;抛错 ⇒ 什么也不证明。
+ * 各调用点对这三种答案的处置归各自(阶梯 / 兜底 / 收敛器),不在这里。
+ */
+import type { ApprovalAskStore, AskRow, AskTerminalClaimOutcome } from "./plugins/approval-ask-store-sql.js";
+import type { UnattendedApprovalPolicy } from "./tool-approval.js";
+/**
+ * 按部署政策给这一只 ask 行打原子终局 claim(见文件头:四个调用点、两个意图、答案自足)。`row` 只取 scope 两维 ——
+ * `batchId` 必须是**行上**的批(幂等命中的存量行可能是别的政策 / 旧版本铸的整腿批,错 scope 的 claim 如实 `absent`)。
+ */
+export declare function settleByPolicy(store: Pick<ApprovalAskStore, "claimTerminal">, row: Pick<AskRow, "askId" | "batchId">, policy: UnattendedApprovalPolicy): Promise<AskTerminalClaimOutcome>;
+//# sourceMappingURL=approval-policy-settlement.d.ts.map

package/dist/approval-policy-settlement.js

@@ -0,0 +1,16 @@
+function unattendedClaimIntent(policy) {
+    switch (policy) {
+        case "park":
+            return "expire";
+        case "deny":
+            return "refuse";
+        default: {
+            const unreachable = policy;
+            throw new Error(`unattendedClaimIntent: unknown UNATTENDED_APPROVAL_POLICY word ${String(unreachable)}`);
+        }
+    }
+}
+export function settleByPolicy(store, row, policy) {
+    return store.claimTerminal(row.askId, row.batchId, unattendedClaimIntent(policy));
+}
+//# sourceMappingURL=approval-policy-settlement.js.map

package/dist/approval-reconciler.d.ts

@@ -1,4 +1,5 @@
 import type { AskRow, ApprovalAskStore } from "./plugins/approval-ask-store-sql.js";
+import type { UnattendedApprovalPolicy } from "./tool-approval.js";
 import type { BatchState } from "./approval-ask-machine.js";
 import type { CheckpointAskCandidate } from "./plugins/checkpoint-store-sql.js";
 import { type RunRecord } from "./plugins/store-contracts.js";
@@ -189,7 +190,8 @@ export interface ReconcileStats {
     /** 段一/段二因**墙钟预算**用尽而提前收工的段数(0/1/2)。>0 ⇒ 依赖在退化,剩余行留给下一轮
      *  (见 {@link RECONCILE_SEGMENT_BUDGET_MS})。 */
     budgetExhausted: number;
-    /** 段二:被代打 `expireAsk` 的孤儿 `STREAM_PENDING` 行数(赢 CAS 的)。 */
+    /** 段二:被代打**窗到期终局 claim** 的孤儿 `STREAM_PENDING` 行数(赢 CAS 的)。「expired」指触发(窗过了没人收),
+     *  不指意图 —— 与 live 腿 `window_expired` 同一个读法:park 部署 ⇒ expire(进投递面);deny 部署 ⇒ refuse(当场落政策结算,S-706)。 */
     orphansExpired: number;
 }
 /** 撤卡帧的投递面(逐 ctx 分发:durable 腿落账本、sync 腿 live,见 `ApprovalRevokeFrame` 顶注)。
@@ -222,6 +224,11 @@ export interface ApprovalReconcilerDeps {
     pendingGraceMs: number;
     adhocGraceMs: number;
     orphanTtlMs: number;
+    /**
+     * S-706:部署的无人值守政策(`UNATTENDED_APPROVAL_POLICY`)—— 段二孤儿代打打的是哪个终局 claim。**必填**、恒传(与协调器
+     * 读同一个部署值;没有缺省 —— 缺省 park 会让 deny 部署在崩溃恢复这一形上静默退回「进投递面 → 不带来源的 DENIED」)。
+     */
+    unattendedPolicy: UnattendedApprovalPolicy;
     emitRevoke?: ApprovalRevokeEmitter | undefined;
 }
 /** {@link createApprovalReconciler} 返回的活对象。 */

package/dist/approval-reconciler.js

@@ -1,4 +1,5 @@
 import { CANCELLED_CODE } from "./run-cancel-context.js";
+import { settleByPolicy } from "./approval-policy-settlement.js";
 import { isTerminalRunStatus } from "./plugins/store-contracts.js";
 import { DENY_REASONS, VOID_REASONS } from "./approval-deny-reasons.js";
 import { buildRevokeFrame } from "./approval-card.js";
@@ -78,7 +79,7 @@ export function decideReconcileAction(input) {
     return { kind: "hold" };
 }
 export function createApprovalReconciler(deps) {
-    const { askStore, checkpoints, runs, logger, metrics, batchLimit, pendingGraceMs, adhocGraceMs, orphanTtlMs, emitRevoke } = deps;
+    const { askStore, checkpoints, runs, logger, metrics, batchLimit, pendingGraceMs, adhocGraceMs, orphanTtlMs, unattendedPolicy, emitRevoke } = deps;
     const revoke = (row, askIds, reason, nowMs) => {
         if (askIds.length === 0 || !emitRevoke)
             return;
@@ -245,8 +246,8 @@ export function createApprovalReconciler(deps) {
                 if (row.expiresAtMs + pendingGraceMs >= nowMs)
                     continue;
                 try {
-                    const res = await withDeadline(askStore.expireAsk(row.askId, row.batchId), "expireAsk(orphan)");
-                    if (!res.won)
+                    const res = await withDeadline(settleByPolicy(askStore, row, unattendedPolicy), "claimTerminal(orphan)");
+                    if (!res.claimed)
                         continue;
                     stats.orphansExpired += 1;
                     revoke(row, res.voidedSiblings, "superseded_by_park", nowMs);
@@ -254,7 +255,7 @@ export function createApprovalReconciler(deps) {
                 catch (err) {
                     stats.failed += 1;
                     try {
-                        logger.warn("approval_orphan_expire_failed", { askId: row.askId, taskId: row.taskId, err: err instanceof Error ? err.message : String(err) });
+                        logger.warn("approval_orphan_expire_failed", { askId: row.askId, taskId: row.taskId, policy: unattendedPolicy, err: err instanceof Error ? err.message : String(err) });
                     }
                     catch {
                     }

package/dist/approval.d.ts

@@ -7,7 +7,26 @@ import { type ToolPolicy } from "@sema-agent/core";
 import { type PostureSource } from "./posture-source.js";
 import { type ExecutionLane } from "./execution-lane-caps.js";
 /**
- * 运维**是否表达了门意图** —— boot 的单用户 allow-all 基线只在"零门意图"时才允许铺开,
+ * 门意图判据读的五个量(`ServiceConfig` 结构满足)。单独成型是为了让**热路径**能拿「候选视图」来判
+ * (S-668 波 2:`{ ...config, approvalRequire: 候选名单 }`)—— 判据只有一份,输入可以是活配置也可以是候选。
+ */
+export interface GateIntentView {
+    readonly approvalRequire: readonly string[];
+    readonly approvalDeny: readonly string[];
+    readonly approvalNeverAuto: readonly string[];
+    readonly durableApproval: boolean;
+    readonly durableApprovalSource: PostureSource;
+}
+/**
+ * 三张审批名单(require / deny / never-auto)里**有没有一张在场** —— 「这台部署有一份要执行的审批策略」。
+ *
+ * 🔴 S-668 波 2(codex r1 F1):leader 车道的 durable 审批席曾只按 `approvalRequire` 非空给出。require 名单转热之后,
+ * 中心热撤空它就把 leader worker 上**独立**的 deny / never-auto 两张表一起撤掉(主车道照旧 deny / ask)—— 三张表是
+ * 三条独立的限制,任何一张在场都要装策略。{@link hasOperatorGateIntent} 的名单三格就是本函数(同一判据,不写两份)。
+ */
+export declare function hasApprovalListIntent(config: Pick<GateIntentView, "approvalRequire" | "approvalDeny" | "approvalNeverAuto">): boolean;
+/**
+ * 运维**是否表达了门意图** —— 单用户 allow-all 基线只在"零门意图"时才允许铺开,
  * 所以这个谓词漏一格 = 那一格的意图被 allow-all 静默吞掉。
  *
  * 🔴 由来(2026-07-31 缝合审):这判据本来是 `main.ts` 里的一行内联表达式,只枚举了
@@ -20,26 +39,31 @@ import { type ExecutionLane } from "./execution-lane-caps.js";
  * 判定挪到**与 inv#2 同一个文件**就是为了这个:两者再想漂开,得有人同时改这两段。
  * 新增任何"门意图"配置项时,这里必须同步加一格(下面的表驱动测试会点名漏的那格)。
  */
-export declare function hasOperatorGateIntent(config: {
-    approvalRequire: readonly string[];
-    approvalDeny: readonly string[];
-    approvalNeverAuto: readonly string[];
-    durableApproval: boolean;
-    durableApprovalSource: PostureSource;
+export declare function hasOperatorGateIntent(config: GateIntentView): boolean;
+/**
+ * 单用户 turnkey 的 **auto-accept 基线**适用吗 —— 单用户(未开 `REQUIRE_PRINCIPAL`)∧ 运维零门意图。
+ *
+ * 🔴 S-668 波 2 ③:**每请求现算**,不是 boot 常量。判据的输入 `approvalRequire` 自本批起在进程内会被中心
+ * 热换;boot 期算好的一个布尔会让「名单从空变非空」之后 allow-all 基线仍挂在每个新任务上 —— 运维刚表达的
+ * 门意图被基线静默吞掉([ref] 方向)。所以消费点(`boot/resolve-spec.ts` 每个任务、stage-07 的 boot 姿态行、
+ * run-local 的补偿 warn)一律调本函数,谁也不持有它的快照。
+ */
+export declare function singleUserAutoAcceptBaselineApplies(config: GateIntentView & {
+    readonly requirePrincipal: boolean;
 }): boolean;
 /**
- * 门意图不可服务=boot 拒启(全窗复审 D3-F1,HIGH;与 env 墓碑族同谱系)。
- * v4.3.0 的轮询门形(APPROVAL_REQUIRE + DB backend + DURABLE_APPROVAL 未设)在 5.0.0 只剩 core 每任务
- * warn——**原先拦、现在放**(方向反转)。「留 undefined 让 core warn」对新配置是曝露误配,对升级存量是
- * 门静默消失,后者必须响亮。放这文件与 hasOperatorGateIntent/inv#2 同源(意图判据再漂要同时改两段)。
+ * 门意图**不可服务**的判据 —— 返回拒因(可服务 ⇒ `undefined`)。**全仓唯一一份**,两处调用、处置不同:
+ *  · **boot**(`boot/stage-07-capability-layer.ts`):对装配完的整份 config 判,拒因 ⇒ **拒启**(全窗复审 D3-F1,
+ *    HIGH;与 env 墓碑族同谱系)。v4.3.0 的轮询门形(APPROVAL_REQUIRE + DB backend + DURABLE_APPROVAL 未设)在
+ *    5.0.0 只剩 core 每任务 warn——**原先拦、现在放**(方向反转)。「留 undefined 让 core warn」对新配置是
+ *    曝露误配,对升级存量是门静默消失,后者必须响亮。
+ *  · **热路径**(S-668 波 2 ④,`config-center/apply-effective.ts` 的审批组 stage):对**候选视图**
+ *    (活配置 + 候选名单)判,拒因 ⇒ 审批组**整组拒**、活配置零变化、世代账停旧代。进程在跑,拒启不是选项;
+ *    而放行一份「没有 checkpoint 店可停车」的名单 = 单用户 auto-accept 基线仍在、名单静默不生效。
+ * `checkpointStorePresent` 是**部署事实**(本进程建没建出 checkpoint 店),不在 `ServiceConfig` 里 ⇒ 调用方显式递。
+ * 放这文件与 hasOperatorGateIntent/inv#2 同源(意图判据再漂要同时改两段)。
  */
-export declare function assertGateIntentServiceable(config: {
-    approvalRequire: readonly string[];
-    approvalDeny: readonly string[];
-    approvalNeverAuto: readonly string[];
-    durableApproval: boolean;
-    durableApprovalSource: PostureSource;
-}, checkpointStorePresent: boolean): void;
+export declare function gateIntentUnserviceableReason(config: GateIntentView, checkpointStorePresent: boolean): string | undefined;
 /**
  * S-602 C3 —— 「**无应答面**」两条 boot warn 的判据与文案(纯函数;stage-07 只负责打日志)。
  *
@@ -85,8 +109,8 @@ export declare function buildNoResponderBootWarns(input: {
  * 为什么在 **boot** 判而不是 resolve 时判:两个入参都是**部署级**的(entitlement 源在不在、durable 门开
  * 不开),per-principal 的那一半改变不了结论;放 resolve 里就得自己造去重,而 boot 天然只跑一次。
  *
- * 纯函数(返回一行或 undefined,不自己写日志)= 红先测得动;调用点在 main.ts 的
- * {@link assertGateIntentServiceable} 之后(同一段门装配)。
+ * 纯函数(返回一行或 undefined,不自己写日志)= 红先测得动;调用点在 stage-07 的
+ * {@link gateIntentUnserviceableReason} 拒启判之后(同一段门装配)。
  */
 export declare function buildForceDurableGateInertNotice(input: {
     /** center per-principal entitlement 源在不在(`centerEntitlementSourceWired` 的结果 —— 判据单源在那里)。 */

package/dist/approval.js

@@ -3,19 +3,27 @@ import { operatorAsk } from "./operator-ask.js";
 import { ASK_USER_QUESTION_TOOL_NAME } from "./approval-content-kind.js";
 import { isExplicitPosture } from "./posture-source.js";
 import { handsOnWorkerFilePlane } from "./execution-lane-caps.js";
-export function hasOperatorGateIntent(config) {
+export function hasApprovalListIntent(config) {
     return (config.approvalRequire.length > 0 ||
         config.approvalDeny.length > 0 ||
-        config.approvalNeverAuto.length > 0 ||
+        config.approvalNeverAuto.length > 0);
+}
+export function hasOperatorGateIntent(config) {
+    return (hasApprovalListIntent(config) ||
         (config.durableApproval && isExplicitPosture(config.durableApprovalSource)));
 }
-export function assertGateIntentServiceable(config, checkpointStorePresent) {
+export function singleUserAutoAcceptBaselineApplies(config) {
+    return config.requirePrincipal !== true && !hasOperatorGateIntent(config);
+}
+export function gateIntentUnserviceableReason(config, checkpointStorePresent) {
     if (!hasOperatorGateIntent(config) || checkpointStorePresent)
-        return;
+        return undefined;
     if (!config.durableApproval) {
-        throw new Error("APPROVAL_REQUIRE/APPROVAL_DENY/APPROVAL_NEVER_AUTO are set but the durable gate is off — since 5.0.0 the poll lane is retired and durable is the ONLY gate. Set DURABLE_APPROVAL=true (with a DB/file backend that has a checkpoint face), or remove the APPROVAL_* lists to run ungated on purpose.");
+        return ("an approval list is in force (APPROVAL_REQUIRE / APPROVAL_DENY / APPROVAL_NEVER_AUTO, or the center's governance.approvalRequire) but the durable gate is off — " +
+            "since 5.0.0 the poll lane is retired and durable is the ONLY gate, so the list would never be enforced. Set DURABLE_APPROVAL=true (with a DB/file backend that has a checkpoint face), " +
+            "or remove the approval lists to run ungated on purpose.");
     }
-    throw new Error("DURABLE_APPROVAL=true but no checkpoint store is available — the configured DB backend has no checkpoint face (or no backend is configured). Wire a MySQL-protocol/PostgreSQL/file backend, or unset DURABLE_APPROVAL.");
+    return "DURABLE_APPROVAL=true but no checkpoint store is available — the configured DB backend has no checkpoint face (or no backend is configured). Wire a MySQL-protocol/PostgreSQL/file backend, or unset DURABLE_APPROVAL.";
 }
 export function buildNoResponderBootWarns(input) {
     if (input.approvalFaceWired)

package/dist/boot/config-center.d.ts

@@ -8,6 +8,7 @@ import { type ModelKeyRef } from "../key-resolver.js";
 import type { Logger } from "../observability/logger.js";
 import type { Metrics } from "../observability/metrics.js";
 import type { UnpricedCeilingVerdict } from "./unpriced-ceiling-verdict.js";
+import type { ConsolidationSeatWatch } from "./memory-consolidation.js";
 import { type RestartSignal } from "../config-center/facade.js";
 import { type ConfigApplyLedgerView } from "../config-center/apply-ledger.js";
 import type { LimitSync } from "./limit-sync.js";
@@ -43,19 +44,25 @@ export interface ConfigCenterRuntime {
     /** 60s refresh cadence + boot-deferred 到货续接。
      *  `limitSync`([ref] 批1)= 恒构造的两只限额座的换代口:commit 之后**零 await 内**推一把,与 pricing /
      *  keyResolver 那两件派生重建同族(缺席 = 这条腿本部署没装配,例如 run-local)。
-     *  `swapRunnerDeps`(core 7.10.0 `Runner.swapDeps` 一扇门;5.49 起的 `swapModels` 口在 7.10.0 退役、
-     *  本参数同语义改名)= **可换席**的换装口:模型面 plane 变更候选在 commit 前喂给全部 boot Runner
-     *  原子换代(在场 ⇒ models-tiers defer/restart 臂退役,缺席 ⇒ 旧 defer 行为逐字保留);S-174 起
-     *  read **face** 席也走同一只函数(见 refresh 拍里的 `applyCenterReadFace` 调用点)。
+     *  `swapRunnerDeps`(core 7.10.0 `Runner.swapDeps` 一扇门)= **可换席**的换装口,**必填**:模型面 plane
+     *  变更候选在 commit 前喂给全部 boot Runner 原子换代;S-174 起 read **face** 席也走同一只函数(见 refresh
+     *  拍里的 `applyLiveReadFace`)。S-668 波 0 起必填 —— 它缺席的那一形(模型面整面 defer 到重启 + `models-tiers`
+     *  重启片)在生产上从来到不了(stage-08 唯一调用点恒传),随片一起退役;要刷新环就要有 Runner 可换。
      *  `ceilingVerdict`(S-232)= 「配了 $ 天花板但目录未定价」这条判决的活载体,与 `limitSync` **同族同序**
      *  (commit 之后、零 await 内重判一次;判决不翻转就静默)。缺席 = 这条腿本部署没装配(run-local 一次性
-     *  CLI 之后不再有刷新拍,它继续用纯判据判一次)。 */
+     *  CLI 之后不再有刷新拍,它继续用纯判据判一次)。
+     *  `consolidationSeat`(S-668 波 0,过渡)= 整理驱动席的两侧读数口,喂 `memory-consolidation` 重启片;
+     *  缺席 = 阀门关着(没有 boot 烤死的席)。
+     *  `checkpointStorePresent`(S-668 波 2,**必填**)= 部署事实「本进程建没建出 checkpoint 店」(stage-06 的产物,
+     *  不在 ServiceConfig 里)。审批名单转热之后,热腿要用它判 ④「门意图不可服务」(与 boot 拒启同一只判据);
+     *  必填 = 刷新环不可能在不知道这件事的情况下热应用审批名单。 */
     startRefreshLoop(a: {
-        runnerTierFrozen: boolean;
         pricing: ReturnType<typeof buildPricing>;
         limitSync?: LimitSync;
-        swapRunnerDeps?: (next: SwappableDeps) => void;
+        swapRunnerDeps: (next: SwappableDeps) => void;
         ceilingVerdict?: UnpricedCeilingVerdict;
+        consolidationSeat?: ConsolidationSeatWatch;
+        checkpointStorePresent: boolean;
     }): void;
     /** [ref]-2:停刷新环(hardShutdown 收尾链;幂等,未起环时 no-op)。 */
     stopRefreshLoop(): void;
@@ -78,7 +85,8 @@ export interface ConfigCenterRuntime {
     modelReady(): boolean;
     /** /health.restart(orchestrator 自动重启信号)。 */
     restartState(): RestartSignal | undefined;
-    /** /health.modelPlaneDeferred(codex R18 卡死的 plane,无 next-boot handoff)。 */
+    /** /health.modelPlaneDeferred:被扣着、还没有 next-boot handoff 的候选(codex R18 起的状态机)。S-668 波 0 起
+     *  模型面不再 defer,键名保留,今天承载的是 durable LKG 发布债与 skills 债(见 `planeDeferredNoHandoff`)。 */
     planeDeferredState(): {
         version: number;
         since: number;