@sema-agent/server 7.98.0 → 7.100.0

package/deploy/sema-up/sema-up.sh

@@ -15,7 +15,7 @@
 set -euo pipefail
 
 HERE="$(cd "$(dirname "$0")" && pwd)"
-# `.env` 文法(写口 encode / 读口 ENVF_WORD 与规范行判据)的唯一定义 —— 写读两半从这一处取判据。
+# `.env` 文法(写口 envf_representable + envf_encode / 读口 envf_canonical_line)的唯一定义 —— 写读两半从这一处取判据。
 . "$HERE/lib/envf.sh"
 # 执行车道表的唯一读者(S-599)。定义在**最前面**:`--help` 的词表也从表渲(手抄的词表会在加一条
 # 车道时静默分叉),而 `-h` 在参数循环里就被处理,那时后面的函数还没定义。
@@ -169,11 +169,20 @@ log() { printf '[sema-up] %s\n' "$*" >&2; }
 
 # compose 入口解析:优先 docker compose(插件),缺了退 docker-compose(独立版)——
 # homebrew 裸 docker CLI 不带插件是真场景;都没有=报错带下一步
-dc() {
-  if docker compose version >/dev/null 2>&1; then docker compose "$@"
-  elif command -v docker-compose >/dev/null 2>&1; then docker-compose "$@"
+# dc_argv 设 DC_ARGV(选中的 compose 入口);dc 调它 —— 渲染对账给运维的复现命令也从 DC_ARGV 渲,不另写一份。
+dc_argv() {
+  if docker compose version >/dev/null 2>&1; then DC_ARGV=(docker compose)
+  elif command -v docker-compose >/dev/null 2>&1; then DC_ARGV=(docker-compose)
   else log "⛔ 没有可用的 compose(docker compose 插件/docker-compose 都缺)。下一步:装 Docker Desktop/OrbStack,或 brew install docker-compose"; exit 1; fi
 }
+dc() { dc_argv; "${DC_ARGV[@]}" "$@"; }
+# compose 的全局参数(-p / --env-file / -f)只在这里拼一次(相对 `$HERE/stack`):up / config 走 compose()、teardown 的
+# down、渲染对账给运维的复现命令,都从同一张 COMPOSE_GLOBALS 取(S-646 ④:复现命令曾是手抄的第二份,漏了
+# -f compose.dataroot.yaml 与 profile;teardown 是第三份)。数据根由调用方先定好 DATA_ROOT。
+compose_globals() {
+  COMPOSE_GLOBALS=(--project-name "$PROJECT" --env-file "$ENVF" -f compose.yaml)
+  if [ -n "$DATA_ROOT" ]; then COMPOSE_GLOBALS+=(-f compose.dataroot.yaml); fi
+}
 
 # ── 跨平台探针(Linux 目标机为主;macOS 开发机跑 docker 档也是真场景——npx 分发)────────────
 ram_mb() { if [ -r /proc/meminfo ]; then awk '/MemTotal/{printf "%d", $2/1024}' /proc/meminfo
@@ -237,22 +246,23 @@ if $TEARDOWN; then
   cd "$HERE/stack"
   if [ -f "$ENVF" ]; then
     # 读 .env 一律经 lib 的严格读口(S-618 续):裸 grep|cut 会连编码形的单引号一起读出来。
-    OV=""; envf_has DATA_ROOT_DIR && OV="-f compose.dataroot.yaml"
+    # 数据根以 .env 登记的为准(卸载的是首装那一份,不看本次 --data-root);全局参数与 up 同一张表(compose_globals)。
+    DATA_ROOT="$(envf_get DATA_ROOT_DIR)" || exit 1
     # 全 profile down 会对未启用服务也做 config 校验——.env 缺 SEMA_*_IMAGE(该面没开过)时
     # 整个 down 失败(真踩:假「已卸载」)。补占位符只为过校验;shell env 优先级高于 --env-file
     envf_has SEMA_SERVER_IMAGE || export SEMA_SERVER_IMAGE="teardown-placeholder"
     envf_has SEMA_REGISTRY_IMAGE || export SEMA_REGISTRY_IMAGE="teardown-placeholder"
-    if ! dc --project-name "$PROJECT" --env-file "$ENVF" -f compose.yaml $OV \
+    compose_globals
+    if ! dc "${COMPOSE_GLOBALS[@]}" \
       --profile data --profile pg --profile s3 --profile agent --profile registry --profile git \
       down $($TEARDOWN_VOLUMES && echo -v); then
       log "⛔ 卸载未完全成功。下一步:docker ps -a --filter label=com.docker.compose.project=$PROJECT 手查残留"
       exit 1
     fi
     log "已卸载 project=$PROJECT $($TEARDOWN_VOLUMES && echo '(含数据卷)' || echo '(数据卷保留:pgdata/miniodata/registrydata/gitdata)')"
-    if $TEARDOWN_VOLUMES && [ -n "$OV" ]; then
-      DR="$(envf_get DATA_ROOT_DIR)" || exit 1
-      # ${DR} 必须带花括号:后面紧跟中文破折号,bash 3.2(macOS 系统壳)会把多字节并进变量名(真踩)
-      log "⚠ 数据根在大盘 bind 目录 ${DR}——卷对象已删,盘上文件还在;确认不要了再手动 rm -rf"
+    if $TEARDOWN_VOLUMES && [ -n "$DATA_ROOT" ]; then
+      # ${DATA_ROOT} 必须带花括号:后面紧跟中文破折号,bash 3.2(macOS 系统壳)会把多字节并进变量名(真踩)
+      log "⚠ 数据根在大盘 bind 目录 ${DATA_ROOT}——卷对象已删,盘上文件还在;确认不要了再手动 rm -rf"
     fi
   else log "没有找到 $ENVF,无可卸载"; fi
   exit 0
@@ -566,8 +576,8 @@ PG_TUNE_FLAGS="-c max_connections=100 -c shared_buffers=${SB}MB -c effective_cac
 genpw() { openssl rand -hex 24; }
 touch "$ENVF"; chmod 600 "$ENVF"
 # 写口 = lib/envf.sh 的 envf_put(setk / setk_new / resetk 都落到它):值按同一文法序列化 —— 安全裸词原样,
-# 含空白 / 特殊字符的走整值单引号编码形(compose 读成字面量、闭引号后不续解析;被 source 也不执行);换行 /
-# 回车 / 单引号 ⇒ 写之前响亮拒,点名键、不回显值。setk 判「键在不在」也走严格读口:旧文件里该键那一行不是
+# 含空白 / 特殊字符 / 反斜杠的走整值单引号编码形(compose 读成字面量、闭引号后不续解析;被 source 也不执行);换行 /
+# 回车 / 单引号 / 以奇数个反斜杠结尾 ⇒ 写之前响亮拒,点名键、不回显值,「下一步」按拒因给。setk 判「键在不在」也走严格读口:旧文件里该键那一行不是
 # 规范形(比如同物理行闭引号带出的二次赋值)⇒ 响亮拒,不再「见行在就跳过」把毒行原样留着(test srv796 RT1)。
 setk SEMA_PROJECT "$PROJECT"
 setk PG_PASSWORD "$(genpw)"
@@ -683,7 +693,9 @@ fi
 envf_load SERVER_PORT PG_PORT MINIO_PORT MINIO_CONSOLE_PORT REGISTRY_PORT GIT_HTTP_PORT GIT_SSH_PORT
 
 command -v docker >/dev/null || { log "⛔ 未装 docker。下一步:curl -fsSL https://get.docker.com | sh(cn region 用镜像站,如 https://mirrors.aliyun.com/docker-ce)"; exit 1; }
-compose() { ( cd "$HERE/stack" && dc --project-name "$PROJECT" --env-file "$ENVF" -f compose.yaml ${DATA_ROOT:+-f compose.dataroot.yaml} "$@" ); }
+compose() { compose_globals; ( cd "$HERE/stack" && dc "${COMPOSE_GLOBALS[@]}" "$@" ); }
+# shq —— 单引号引用一个词(复现命令要能原样粘贴:路径里可能有空格)。
+shq() { printf "'%s'" "$(printf '%s' "$1" | sed "s/'/'\\\\''/g")"; }
 
 # ── D:渲染对账(S-618 的类闭环;生成 .env 之后、compose up 之前)──────────────────────────────────
 # .env 的写口 / 读口都按物理行判,认不出 compose dotenv 的跨行引号值等边角;唯一能确知「容器真正拿到
@@ -692,22 +704,23 @@ compose() { ( cd "$HERE/stack" && dc --project-name "$PROJECT" --env-file "$ENVF
 # REQUIRE_EXECUTION_LANE,与本次决策逐值对比,不一致 ⇒ 拒并点名渲染值与决策值。**以 compose 为唯一属主**。
 # docker 不可达在上面 `command -v docker` 那道已 fail-loud 拦下;config 本身失败(YAML/插值坏)也拒,
 # 不新铸降级臂:未经对账就不 up。只有 agent 面有这三个决策键,别的档跳过。
-reconcile_render() {
-  case ",$COMPOSE_PROFILES," in *,agent,*) : ;; *) return 0 ;; esac
-  local exp_rp="$REQUIRE_PRINCIPAL_WANT" exp_re="$LANE_REMOTE_EXEC" exp_rl rendered
-  exp_rl="$(printf '%s\n' "$LANE_ENV" | sed -n 's/^REQUIRE_EXECUTION_LANE=//p')"
-  rendered="$(COMPOSE_PROFILES="$COMPOSE_PROFILES" compose config --format json 2>&1)" || {
-    local rc=$?
-    # 7.98.0 合并复审 F3:compose 的报文**不回显** —— 它解析 .env 失败时会原样引用那一行(凭据就在行里)。只报退出码 + 出路。
-    log "⛔ 渲染对账:docker compose config 失败(退出码 $rc),无法确认容器会拿到什么 —— 拒绝在未对账的情况下 up"
-    log "   ↳ 下一步:在本机亲跑 docker compose --project-name $PROJECT --env-file $ENVF -f $HERE/stack/compose.yaml config 看报文(本脚本不转印它:.env 解析失败的报文会原样引用那一行,可能带凭据);常见成因是手改过的 .env 行"
-    exit 1
-  }
-  RECON_JSON="$rendered" python3 - "$exp_rp" "$exp_re" "$exp_rl" <<'PY' || {
-import json, os, sys
+#
+# 拒因分两种、各给各的出路(S-656;7.98.0 曾把 stderr 并进 stdout 当 JSON 解析 ⇒ compose 的任何警告都让它 traceback,
+# 拒因还冒充「不一致」):
+#   · 渲染结果解析失败 —— compose 退出码非零,或退出 0 但 stdout 不是可解析的 compose JSON:没拿到渲染值,谈不上比对;
+#   · 渲染值与决策值不一致 —— 拿到了、逐值比对不上。
+# JSON 只从 stdout 取;stderr 只数行数作诊断,**不转印**(compose 解析 `.env` 失败时报文会原样引用那一行,凭据就在行里;
+# 插值警告里的变量名也可能是凭据的一段)。
+RECON_PY='
+import json, sys
 want = {"REQUIRE_PRINCIPAL": sys.argv[1], "REMOTE_EXEC": sys.argv[2], "REQUIRE_EXECUTION_LANE": sys.argv[3]}
-d = json.loads(os.environ["RECON_JSON"])
-env = ((d.get("services") or {}).get("server") or {}).get("environment") or {}
+try:
+    d = json.loads(sys.stdin.read())
+    env = d["services"]["server"].get("environment") or {}
+    if not isinstance(env, dict):
+        raise TypeError("environment")
+except Exception:
+    raise SystemExit(4)  # 渲染结果解析失败:不是 compose JSON / 没有 server 服务
 bad = []
 for k, w in want.items():
     got = env.get(k)
@@ -716,13 +729,42 @@ for k, w in want.items():
         bad.append("%s:渲染=%r 决策=%r" % (k, got, w))
 if bad:
     sys.stderr.write("[sema-up]    ↳ 明细:" + " | ".join(bad) + "\n")
-    raise SystemExit(3)
-PY
-    log "⛔ 渲染对账失败:compose 渲染出的容器决策值与本次决策不一致 —— 以 compose 为唯一属主,拒绝 up"
-    log "   ↳ 下一步:检查 .env 里 REQUIRE_PRINCIPAL / REMOTE_EXEC / REQUIRE_EXECUTION_LANE,以及 shell / -f 里是否**导出**了同名变量(compose 插值 shell 优先于 --env-file,导出为空会盖掉 .env)"
+    raise SystemExit(3)  # 渲染值与决策值不一致
+'
+reconcile_render() {
+  case ",$COMPOSE_PROFILES," in *,agent,*) : ;; *) return 0 ;; esac
+  local exp_rp="$REQUIRE_PRINCIPAL_WANT" exp_re="$LANE_REMOTE_EXEC" exp_rl rendered errf nerr rc=0 prc=0 repro a
+  exp_rl="$(printf '%s\n' "$LANE_ENV" | sed -n 's/^REQUIRE_EXECUTION_LANE=//p')"
+  # 复现命令:与这次 config 同一个 compose 入口、同一张全局参数表、同一组 profile(从源渲,不手抄)。
+  dc_argv; compose_globals
+  repro="(cd $(shq "$HERE/stack") && COMPOSE_PROFILES=$(shq "$COMPOSE_PROFILES") ${DC_ARGV[*]}"
+  for a in "${COMPOSE_GLOBALS[@]}"; do repro="$repro $(shq "$a")"; done
+  repro="$repro 'config' '--format' 'json')"
+  errf="$(umask 077 && mktemp "$WORK/.recon-stderr.XXXXXX")" || { log "⛔ 渲染对账:在 $WORK 建不了临时文件,无法对账 —— 拒绝在未对账的情况下 up"; exit 1; }
+  rendered="$(COMPOSE_PROFILES="$COMPOSE_PROFILES" compose config --format json 2>"$errf")" || rc=$?
+  nerr="$(wc -l < "$errf" | tr -d '[:space:]')"; rm -f "$errf"
+  if [ "$rc" -ne 0 ]; then
+    log "⛔ 渲染对账:渲染结果解析失败 —— docker compose config 失败(退出码 $rc;它在 stderr 输出了 $nerr 行,本脚本不转印),无法确认容器会拿到什么 —— 拒绝在未对账的情况下 up"
+    log "   ↳ 下一步:在本机亲跑 $repro 看 compose 的报文(本脚本不转印它:.env 解析失败的报文会原样引用那一行,可能带凭据);常见成因是手改过的 .env 行"
     exit 1
-  }
-  log "渲染对账通过:REQUIRE_PRINCIPAL=$exp_rp REMOTE_EXEC=$exp_re REQUIRE_EXECUTION_LANE=$exp_rl(compose 渲染逐值一致)"
+  fi
+  printf '%s' "$rendered" | python3 -c "$RECON_PY" "$exp_rp" "$exp_re" "$exp_rl" || prc=$?
+  case "$prc" in
+    0) : ;;
+    3)
+      log "⛔ 渲染对账:渲染值与决策值不一致 —— compose 渲染出的容器决策值与本次决策对不上;以 compose 为唯一属主,拒绝 up"
+      log "   ↳ 下一步:检查 $ENVF 里 REQUIRE_PRINCIPAL / REMOTE_EXEC / REQUIRE_EXECUTION_LANE,以及 shell / -f 里是否**导出**了同名变量(compose 插值 shell 优先于 --env-file,导出为空会盖掉 .env);亲跑 $repro 可看容器 environment"
+      exit 1 ;;
+    4)
+      log "⛔ 渲染对账:渲染结果解析失败 —— docker compose config 退出 0,但 stdout 不是可解析的 compose JSON(或其中没有 server 服务;compose 另在 stderr 输出了 $nerr 行,本脚本不转印),无法确认容器会拿到什么 —— 拒绝在未对账的情况下 up"
+      log "   ↳ 下一步:亲跑 $repro 看 stdout 是不是一份 JSON;不是 ⇒ 这个 compose 入口不支持 --format json 或往 stdout 多打了东西(${DC_ARGV[*]}),换 Docker Compose v2(docker compose 插件)后重跑"
+      exit 1 ;;
+    *)
+      log "⛔ 渲染对账:对账脚本自身失败(python3 退出码 $prc),无法确认容器会拿到什么 —— 拒绝在未对账的情况下 up"
+      log "   ↳ 下一步:确认本机 python3 可用(python3 -c 'import json'),然后重跑"
+      exit 1 ;;
+  esac
+  log "渲染对账通过:REQUIRE_PRINCIPAL=$exp_rp REMOTE_EXEC=$exp_re REQUIRE_EXECUTION_LANE=$exp_rl(compose 渲染逐值一致)$([ "$nerr" -gt 0 ] && printf ';compose 另在 stderr 输出了 %s 行(多为插值警告;本脚本不转印,up 时 compose 会自己打出来)' "$nerr")"
 }
 
 # ── 外接端点连接检测(装配前 fail-loud;只验兼容可用,不校验证书——内网自签是常态)────────────

package/dist/approval-ask-machine.d.ts

@@ -46,4 +46,14 @@ export declare function deriveAskId(sourceTaskId: string, runId: string, toolCal
 /** batch_id = sha256('batch' ⊕ sourceTaskId ⊕ runId ⊕ legKey).slice(0,64)。同一 (sourceTaskId, runId,
  *  legKey) 恒派生同一批——批 = 同一决策点的兄弟 ask 集合,故不掺 toolCallId。 */
 export declare function deriveBatchId(sourceTaskId: string, runId: string, legKey: string): string;
+/**
+ * 🔴 S-689 codex R1-F1:**单 ask 批** —— batch_id = sha256('ask-batch' ⊕ askId).slice(0,64)。
+ *
+ * 批是 **park 路由的单位**:窗到期赢家把整批转投递面(OPEN → ROUTING_UNBOUND)、兄弟连坐 VOID,core 随后 park,
+ * 这条腿就此结束 —— 所以「整腿一批」成立。不走 park 路由的部署(`UNATTENDED_APPROVAL_POLICY=deny`)上这个前提
+ * 不在:core 拿到的是部署政策拒,腿**继续跑**。整腿一批时,首只到期就把批关了,同腿后续每一只卡 `decideAsk`
+ * 恒 `batch_closed`(卡看得见、答不了),兄弟还被连坐成 VOID。⇒ 没有 park 路由时,批退化成 ask 自己。
+ * 选用处 = 协调器的 `batchIdFor`(唯一消费者);前缀与腿批不同(`ask-batch` 一元组 vs `batch` 三元组),两族 id 不相撞。
+ */
+export declare function deriveAskScopedBatchId(askId: string): string;
 //# sourceMappingURL=approval-ask-machine.d.ts.map

package/dist/approval-ask-machine.js

@@ -33,4 +33,7 @@ export function deriveAskId(sourceTaskId, runId, toolCallId, legKey, parentToolC
 export function deriveBatchId(sourceTaskId, runId, legKey) {
     return deterministicId("batch", [sourceTaskId, runId, legKey]);
 }
+export function deriveAskScopedBatchId(askId) {
+    return deterministicId("ask-batch", [askId]);
+}
 //# sourceMappingURL=approval-ask-machine.js.map

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,85 @@ 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 行 `requiresRealApproval` 座的读数(NP-1 起;此前是 {@link parkRowFacts} 函数体内的一行)—— **`=== true` 严判**,
+ * `false` 与其它值读作缺席(core d.ts「Absent otherwise (never `false`)」;与 core `summarizeCheckpoint` 同一条判法)。
+ * `kind` 由调用方先判(本函数只读这一位)。两个读者共用这一只,解析单源、处置各归读者(与 {@link readRuleOffersAbsenceSeat}
+ * 同一条分工):展示投影 {@link parkRowFacts}(队列行顶层展开)与耐久 `/decide` 腿的 remember 判据(`tool-approval.ts`
+ * 的 `parkRowStandingAnswerFacts`)。这一位在两处方向相同(在场才算、读不出 = 缺席)⇒ 不需要三态;也因此权限面读它
+ * **不经** `parkRowFacts` —— 那只展示投影顺手读 `ruleOffersAbsence` 并对集外词计展示面的 F 类 tag,而权限面对同一格是
+ * fail-closed 的另一种处置(S-663 codex r1 钉「权限面不计展示面 tag」)。
+ */
+export declare function readRequiresRealApprovalSeat(toolApproval: object): 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 再给这一臂加一位同类事实时,改的只有
+ * 下面这张 Pick 表 + {@link parkRowFacts} 函数体一行,两店与路由零改。
+ * `mandated`(core #1079,7.31.0):7.30.1 的 `PendingAction` 上**没有**这一位 ⇒ 本版不铸;到货后表里加
+ * `"mandated"`、函数体按 `requiresRealApproval` 同式加一行。
+ */
+export type ParkRowFacts = Pick<ToolApprovalPark, "requiresRealApproval" | "ruleOffersAbsence">;
+/**
+ * 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` —— 经 {@link readRequiresRealApprovalSeat}(`=== 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,48 @@ 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 readRequiresRealApprovalSeat(toolApproval) {
+    const v = "requiresRealApproval" in toolApproval ? toolApproval.requiresRealApproval : 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 {
+        ...(readRequiresRealApprovalSeat(pendingAction) ? { requiresRealApproval: true } : {}),
+        ...(ruleOffersAbsence !== undefined ? { ruleOffersAbsence } : {}),
+    };
 }
 const DenialLimitFallbackSchema = z
     .object({

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;