@sema-agent/server 7.135.0 → 7.137.0

package/deploy/sema-up/README.md

@@ -166,10 +166,24 @@ server 的 `<数据根>/sealed-key/` 存着停驻任务续跑上下文里请求
   有效访问模式是 `ReadWriteOnce` 时 Deployment 用 `Recreate`(RWO 卷同时只能被一个节点挂,滚动更新的新 Pod 落在别的节点就永远等不到卷;代价是升级窗口内短暂没有副本)。
 - **没有 RWX 的集群**:`--set server.replicas=1`,或单节点多副本盖 RWO(上一条),或关持久 `--set sealedKey.persistence.enabled=false` —— 关掉时图表**显式**给每只 worker 设 `DURABLE_APPROVAL=false`
   (耐久审批整条关,不产生续不了的停驻行;`helm install` 打印的安装说明里也有这一句),且同时配 `server.durableApproval=true` 渲染即拒。
-- **首装是空卷**:多个 pod 并发首启会各自生成一把钥匙、各持自己那一把;装好后 `kubectl -n <ns> rollout restart deploy/sema-server`(启用 `serverV4pro` 时再加 `deploy/sema-server-v4pro`)一次,之后每个 pod 读到全部钥匙。
+- **首装是空卷**:多个 pod 并发首启可能各建一把钥匙、各持自己那一把(钥匙创建没有互斥,只有两个副本在同一个目录上同时首启、都没读到可用的钥匙文件时才发生,不是每次都分叉);装好后不论有没有分叉都执行 `kubectl -n <ns> rollout restart deploy/sema-server`(启用 `serverV4pro` 时再加 `deploy/sema-server-v4pro`)一次,之后每个 pod 读到全部钥匙。
 - PVC 的 `accessModes` 建好后不可改:副本数跨过 1 的边界时 `helm upgrade` 会撞「spec is immutable」;卷里是私钥,换卷前先结掉停驻行或备份钥匙文件。
   PVC 带 `helm.sh/resource-policy: keep`:`helm uninstall` 与把 `enabled` 改成 `false` 的 upgrade 都不删它(确认不要了再 `kubectl -n <ns> delete pvc sema-server-sealed-key`)。
 
+## 升级时的副本更新(7.137.0:停驻任务的请求体改写)
+
+7.137.0 起服时把 7.136.x 及以前停驻的任务存下的请求体原地改写(请求键 `promptProfile` 换成布尔 `promptLean`;窗内每次起服都扫,细节见随包 `MIGRATION.md` 7.137.0 节第 4 条)。
+改写过的体 7.136.x 读不懂,所以升级序是**先停光 7.136.x 副本,再起第一个 7.137.0 副本** —— 滚动更新做不到这一点。
+
+**升级前先缩光副本,按安装路径分三种**(滚动更新做不到「先停光 7.136.x、再起第一个本版副本」;下面三段各管一种安装路径,照你的那一种做):
+
+- **Helm 形安装**(`kube-up.sh` 的 `--kube=existing` / `--kube=k3s`;`--kube=machines` 下设了 `STACK_ENGINE=helm`):图表只在钥匙卷是 `ReadWriteOnce` 时给 Deployment 写 `Recreate`;缺省的多副本(`server.replicas: 3`、`ReadWriteMany`)不写更新策略,`helm upgrade` 走 Kubernetes 缺省的滚动更新 —— 第一只本版 pod 起服改写存体时 7.136.x 副本还在跑。所以升级前先 `kubectl -n <命名空间> scale deploy/sema-server --replicas=0`(启用 `serverV4pro` 时同样缩 `deploy/sema-server-v4pro`),等旧 pod 退光,再 `helm upgrade`(重跑 `sema-up` / `kube-up.sh` 在这些安装形上走的就是这条),升完核副本数回到 `server.replicas`。
+- **`--kube=machines` 缺省形**(不设 `STACK_ENGINE` = `render`;`cluster-up.sh` 渲染清单后 `kubectl apply`,不是 Helm):清单里 `sema-server` 的副本数按机器数取 2(少于 3 台)或 3(3 台及以上),没有 `strategy` 键 = Kubernetes 缺省的滚动更新,也没有 `serverV4pro`。所以升级前先 `kubectl -n sema scale deploy/sema-server --replicas=0`(第一台机器上写 `k3s kubectl`),等旧 pod 退光,再 `kubectl apply`(重跑 `sema-up` 做的就是这一步;清单里的 `replicas` 把副本数写回 2 或 3),升完核副本数。
+- **compose 两档**(`--profile=full-single` / `local-plus`):`server` 服务只有一只容器、没有副本数键 —— 没有第二只旧副本在滚动更新里陪跑,零动作。
+
+已经滚动升过的:等最后一只 7.136.x 副本退出之后,`kubectl -n <命名空间> rollout restart deploy/sema-server`(启用 `serverV4pro` 时再加 `deploy/sema-server-v4pro`)重起一轮本版副本 —— 起服即改写窗内没改写到的任务(重启用的配置里须 `DURABLE_APPROVAL=true` —— 多租户部署缺省关,要显式写,且多租户还需 `OPERATOR_PRINCIPALS` 非空,否则起服拒(拒句点名出路);起服日志里 `checkpoint_ctx_prompt_profile_rewritten`(M30)与 `checkpoint_ctx_credentials_sealed`(M28)两行都出现、且 M30 那一行是 `"window":"open"`,才说明守卫过了、改写跑过 —— M28 的窗先关,窗关后它那一行 `"window":"closed"` 属正常)。
+Helm 形里,未启用 `serverV4pro`、钥匙卷是 `ReadWriteOnce` 的形(`server.replicas=1`、或随包 `values-full-single.yaml` 这类显式盖 `ReadWriteOnce` 的形)图表对 `deploy/sema-server` 本来用 `Recreate`,旧 pod 先停,零动作;启用 `serverV4pro` 时两只 Deployment 各自 `Recreate`、互不等待,仍按上面 Helm 形一条先把两只都缩到 0。
+
 ## 凭据纪律
 
 全部凭据生成一次、落 `~/.sema-up/<project>/.env`(0600),重跑**绝不轮换**;

package/deploy/sema-up/chart/templates/NOTES.txt

@@ -8,7 +8,7 @@
 多个 pod 共用这只卷,存储类必须支持 ReadWriteMany(PVC 一直 Pending 就是它不支持:出路 server.replicas=1,或 sealedKey.persistence.enabled=false 并接受耐久审批随之关)。
 {{- end }}
 {{- if gt (int (include "sema.sealedKey.podCount" .)) 1 }}
-首装是空卷:多个副本并发首启会各自生成一把钥匙、各持自己那一把 —— 装好后执行一次 kubectl -n {{ .Release.Namespace }} rollout restart deploy/sema-server{{ if .Values.serverV4pro.enabled }} deploy/sema-server-v4pro{{ end }},此后每个副本读到目录里的全部钥匙。
+首装是空卷:多个副本并发首启可能各建一把钥匙、各持自己那一把(只有两个副本在同一个目录上同时首启、都没读到可用的钥匙文件时才发生,不是每次都分叉)—— 装好后不论有没有分叉都执行一次 kubectl -n {{ .Release.Namespace }} rollout restart deploy/sema-server{{ if .Values.serverV4pro.enabled }} deploy/sema-server-v4pro{{ end }},此后每个副本读到目录里的全部钥匙。
 {{- end }}
 {{- else }}
 停驻封签钥匙:sealedKey.persistence.enabled=false —— 不建卷,图表已给每只 worker 显式设上 DURABLE_APPROVAL=false(耐久审批整条关,不产生续不了的停驻行;代价见 values.yaml 的 sealedKey 块;要重新打开,把它改回 true)。关持久 + 提交体没声明 settings.approvalFrameFamilies 的客户端 ⇒ 受门工具当场拒(没有耐久店,无处停驻;7.134.0 起审批卡只发给声明认得这一族的客户端)。

package/deploy/sema-up/chart/templates/sandbox-rbac.yaml

@@ -1,4 +1,4 @@
-# ── 沙箱 lane RBAC(k8s+kata;pod 五动词 + 缓存卷四动词 + 出网自检的两只只读:本 ns 的 NetworkPolicy、集群的节点表)────────────────────────────────
+# ── 沙箱 lane RBAC(k8s+kata;pod 五动词 + 缓存卷四动词 + 沙箱秘密座 create + 出网自检的两只只读:本 ns 的 NetworkPolicy、集群的节点表)────────────────────────────────
 apiVersion: v1
 kind: ServiceAccount
 metadata:
@@ -33,6 +33,12 @@ rules:
   - apiGroups: [""]
     resources: [persistentvolumeclaims]
     verbs: [get, create, delete, deletecollection]
+  # 沙箱秘密座:K8S_SANDBOX_ENV 点名的值只进每只 pod 自己的 Secret(pod spec 只带 secretKeyRef;Secret 属于 pod,随 pod 由集群回收)
+  # 动词 = 适配器为 env Secret 真发的调用:create;不读回(无 get)、不删(随属主 pod 由集群 GC)。名单非空而缺它 ⇒ server 起服拒(起服 SelfSubjectAccessReview 问的正是它)
+  # 成员 git 凭据平面(本版恒关)打开时,租约 Secret 还要 patch —— 那时再加
+  - apiGroups: [""]
+    resources: [secrets]
+    verbs: [create]
   # 起服的出网自检读本 ns 的 NetworkPolicy(只读)
   - apiGroups: [networking.k8s.io]
     resources: [networkpolicies]

package/deploy/sema-up/chart/values.yaml

@@ -86,7 +86,7 @@ server:
 #   这只卷里是私钥,不要为了过这个错直接删 PVC:先把停驻行结掉(随包排空检查脚本数一数)或备份钥匙文件,再换卷。
 #   PVC 带 helm.sh/resource-policy: keep:`helm uninstall` 与把 enabled 改成 false 的 upgrade 都不删它(钥匙留着;确认不要了再 `kubectl -n <ns> delete pvc sema-server-sealed-key`);
 #   同名 release 重装会接管这只留下的 PVC。
-#   ⚠ 空卷上多副本并发首启:每个副本看到空目录各自生成一把钥匙,各副本只持有自己那一把,直到下次重启 —— 首装后 `kubectl -n <ns> rollout restart deploy/sema-server`
+#   ⚠ 空卷上多副本并发首启:钥匙创建没有互斥,两个副本在同一个目录上同时首启、都没读到可用的钥匙文件时,各副本可能各建一把钥匙、只持有自己那一把,直到下次重启(不是每次都分叉)—— 首装后不论有没有分叉都执行 `kubectl -n <ns> rollout restart deploy/sema-server`
 #   一次(启用 serverV4pro 时再加 deploy/sema-server-v4pro;NOTES 也说这句),重启之后每个副本读到目录里的全部钥匙,从此一致。
 sealedKey:
   persistence:

package/deploy/sema-up/stack/sema-stack-cluster.yaml

@@ -92,7 +92,7 @@ kind: Service
 metadata: { name: sema-minio, namespace: sema }
 spec: { selector: { app: sema-minio }, ports: [{ name: s3, port: 9000 }, { name: console, port: 9001 }] }
 ---
-# ── 沙箱 lane RBAC(k8s+kata;测试机同款五动词 + 缓存卷 + 出网自检两只只读)────────────────────────────────
+# ── 沙箱 lane RBAC(k8s+kata;pod 五动词 + 缓存卷四动词 + 沙箱秘密座 create + 出网自检的两只只读:本 ns 的 NetworkPolicy、集群的节点表)────────────────────────────────
 apiVersion: v1
 kind: ServiceAccount
 metadata: { name: sema-runner, namespace: sema-sandbox }
@@ -122,6 +122,12 @@ rules:
   - apiGroups: [""]
     resources: [persistentvolumeclaims]
     verbs: [get, create, delete, deletecollection]
+  # 沙箱秘密座:K8S_SANDBOX_ENV 点名的值只进每只 pod 自己的 Secret(pod spec 只带 secretKeyRef;Secret 属于 pod,随 pod 由集群回收)
+  # 动词 = 适配器为 env Secret 真发的调用:create;不读回(无 get)、不删(随属主 pod 由集群 GC)。名单非空而缺它 ⇒ server 起服拒(起服 SelfSubjectAccessReview 问的正是它)
+  # 成员 git 凭据平面(本版恒关)打开时,租约 Secret 还要 patch —— 那时再加
+  - apiGroups: [""]
+    resources: [secrets]
+    verbs: [create]
   # 起服的出网自检读本 ns 的 NetworkPolicy(只读)
   - apiGroups: [networking.k8s.io]
     resources: [networkpolicies]

package/dist/approval-card.d.ts

@@ -21,7 +21,7 @@
  * 没有方法、没有捕获的行为。
  */
 import { z } from "zod";
-import { ALLOW_RULE_MEMBERS, READ_ROOT_CANDIDATE_DIR_MAX, type AskClass, type AskEvidenceAbsence, type PendingAction as CorePendingAction, type ReadRootGrantCandidate, type ResumeStartupCause, type RuleOffer, type RuleOffersAbsence as CoreRuleOffersAbsence, type SteerReplayFacet } from "@sema-agent/core";
+import { ALLOW_RULE_MEMBERS, READ_ROOT_CANDIDATE_DIR_MAX, type AskClass, type AskEvidenceAbsence, type CheckpointSummary as CoreCheckpointSummary, type PendingAction as CorePendingAction, type ReadRootGrantCandidate, type ResumeStartupCause, type RuleOffer, type RuleOffersAbsence as CoreRuleOffersAbsence, type SteerReplayFacet, type ToolApprovalCard } from "@sema-agent/core";
 import type { AskRow } from "./plugins/approval-ask-store-sql.js";
 import type { SettleCause, SettleOutcome } from "./approval-deny-reasons.js";
 import type { ToolApprovalFrame } from "./tool-approval.js";
@@ -440,7 +440,7 @@ export interface AskClassPair {
  * [ref] ②(core 7.37.0 [ref])第六 / 七位 `askClass` / `classes`:这一问的类对(经 {@link readAskClassPair};两位同在同缺,与活卡帧 / 呈卡帧的卡
  * 同名同义同值)—— durable 审批席按类答的依据。缺席 = 老行(core 7.37.0 之前 park 的,续跑不补)/ 读不出(计 [ref] tag)。
  * [ref](core 7.51.0 [ref])第八位 `boundGrantAbsence`:这张卡为什么没有授予绑定摘要(经 {@link readClosedWordSeat};与活卡帧 / inbox 行同名同义同值)——
- * `not_bindable` = 这一问不绑任何授予(「本会话放行」可按工具记)。缺席 = 技能卡(带摘要;摘要不上队列行,见 ⑧b)/ 7.51.0 之前停驻的行(core inbox 投
+ * `not_bindable` = 这一问不绑任何授予(「本会话放行」可按工具记)。缺席 = 技能卡(带摘要;摘要与清单、成因词三位走另一只投影 {@link skillCardFacts},见其顶注)/ 7.51.0 之前停驻的行(core inbox 投
  * `unreadable`,队列行如实缺席)/ 集外词(计 [ref] tag)。
  */
 export type ParkRowFacts = Pick<ToolApprovalPark, "requiresRealApproval" | "ruleOffersAbsence" | "mandated" | "mandate" | "origin" | "askClass" | "classes" | "boundGrantAbsence">;
@@ -471,6 +471,32 @@ export type ParkRowFacts = Pick<ToolApprovalPark, "requiresRealApproval" | "rule
  * 不许拿本函数的产物去推强制 —— 两者共用的是 schema,不是折叠。
  */
 export declare function parkRowFacts(stored: unknown): ParkRowFacts;
+/**
+ * 🔴 **技能卡三位的唯一投影**:授予绑定摘要 `boundGrantDigest`、它哈希的清单 `boundGrants`、分类器没给判词的成因 `classifierNoRuling` ——
+ * 助手收件箱行(`GET /v1/assistant/inbox`)、运维队列行(`GET /v1/approvals` 的 `pending[]`)、`/v1/approvals/stream` 的 `pending` 帧三张停驻读面
+ * **经这一只函数**投它们。同一张停驻的技能卡于是三面同一份字节:运维从队列决这张卡时,看得到批准它还授予了什么。
+ *
+ * **输入恒是 core 的检查点摘要**({@link CoreCheckpointSummary},`summarizeCheckpoint` 的产物)—— 三位的校验点单点在 core:摘要是串才回显;清单**只在哈希等于摘要时**才发布
+ * (「never a list beside a digest that binds another」—— 一份与摘要对不上的清单会让批准人看着一份清单、批的却是另一份绑定);成因词只在闭集成员时回显。
+ * 本仓**不重算哈希**(core 的 `boundInputHashOf` 不在公开导出面上,清单校验读口 `readBoundBinding` 同样不导出),所以**不许**拿寄存行 `pendingAction` 上的原值直接投 ——
+ * 原值上的清单是未经哈希校验的(这正是三位此前不上队列行的原因,见 `trace/core-keyset-guard.ts` ⑧b 记账的旧注)。两只店各自拿到「这一行的摘要」的办法不同
+ * (LOCAL 孪生本来就握着 core 对同一行投的摘要;SQL 孪生对带三位之一的行读一次该行再调 core 的 `summarizeCheckpoint`,见 `plugins/checkpoint-store-sql.ts`),
+ * 但投影只有这一只:OMIT 契约 —— 缺席即缺席,恒不铸 `undefined` 值的键。
+ *
+ * `boundGrants` 是**部署文本**(技能名、清单条目):本函数不脱敏、不转义,与收件箱行逐字同口径 —— 渲染按上下文转义是客户端的事(契约同句)。
+ * 三位都不进 `card_json`(同步路铸点,另一条纪律)。
+ *
+ * 🚧 清单校验读口 `readBoundBinding` 若成为 core 的公开导出,SQL 孪生那一次整行读与 {@link parkRowCarriesSkillCardFacts} 一并退役:`parkRowFacts` 直接读寄存行原值经 core 的读口投三位。
+ */
+export type SkillCardFacts = Pick<CoreCheckpointSummary, "boundGrantDigest" | "boundGrants" | "classifierNoRuling">;
+export declare function skillCardFacts(summary: SkillCardFacts): SkillCardFacts;
+/**
+ * 这一行的寄存行(`pendingAction`,读自持久层 ⇒ `unknown`)**有没有可能**让 core 的摘要投出三位里的任何一位 —— 只回答「值不值得为它取一次摘要」,**不投值**:
+ * `tool_approval` 臂上摘要字段是串(core 只在这时回显摘要与清单),或成因词键在场(是不是闭集成员由 core 的摘要判)。判错的方向只有一个 —— 多取一次摘要(摘要读数为空),
+ * 绝不漏取:摘要字段不是串 ⇒ core 的摘要既无摘要也无清单;成因词键不在 ⇒ 无成因词 —— 两者都不满足的行,摘要里这三位恒空。普通卡(绝大多数行)因此零额外读。
+ * 只读键在不在 / 是不是串,不读值的内容,所以不需要 {@link readClosedWordSeat} 那样的计数。
+ */
+export declare function parkRowCarriesSkillCardFacts(stored: unknown): boolean;
 /** [ref](core 7.4.0 [ref])—— 回落卡的计数与窗。`limit` 是**闭二词**(core d.ts 逐字),两个计数是
  *  非负整数,`autoDenyAfterMs` 是 core 契约里的 `0..2147483647` 非负整数(`0` = 本卡不武装窗:部署把
  *  旋钮关了,或 TOTAL 档的卡按 [ref]① 恒 0 等人)。四成员**全必填**——core 的 `DenialLimitFallback` 上
@@ -524,6 +550,18 @@ export declare const ApprovalCardSchema: z.ZodObject<{
     }, z.core.$strict>;
     governanceForced: z.ZodOptional<z.ZodLiteral<true>>;
     rememberRefused: z.ZodOptional<z.ZodLiteral<true>>;
+    approvalCard: z.ZodOptional<z.ZodEnum<{
+        question: "question";
+        plan: "plan";
+        skill: "skill";
+        shell: "shell";
+        workflow: "workflow";
+        "file-edit": "file-edit";
+        "file-write": "file-write";
+        "notebook-edit": "notebook-edit";
+        fetch: "fetch";
+        generic: "generic";
+    }>>;
     inputHasBidi: z.ZodOptional<z.ZodLiteral<true>>;
     allowRuleShadowed: z.ZodOptional<z.ZodArray<z.ZodObject<{
         member: z.ZodEnum<{
@@ -664,6 +702,18 @@ export declare const ApprovalCardEnvelopeSchema: z.ZodObject<{
         }, z.core.$strict>;
         governanceForced: z.ZodOptional<z.ZodLiteral<true>>;
         rememberRefused: z.ZodOptional<z.ZodLiteral<true>>;
+        approvalCard: z.ZodOptional<z.ZodEnum<{
+            question: "question";
+            plan: "plan";
+            skill: "skill";
+            shell: "shell";
+            workflow: "workflow";
+            "file-edit": "file-edit";
+            "file-write": "file-write";
+            "notebook-edit": "notebook-edit";
+            fetch: "fetch";
+            generic: "generic";
+        }>>;
         inputHasBidi: z.ZodOptional<z.ZodLiteral<true>>;
         allowRuleShadowed: z.ZodOptional<z.ZodArray<z.ZodObject<{
             member: z.ZodEnum<{
@@ -806,6 +856,9 @@ export interface ApprovalCardSource {
     governanceForced?: true;
     /** 7.116.0 S4:「本会话放行」不会被记住(帧上同名键,见 `ApprovalCardSchema.rememberRefused`)。 */
     rememberRefused?: true;
+    /** 7.136.0:引擎铸的卡词 —— 与 wire 帧**同一份素材**(发帧点经 `readApprovalCard` 读定的那一格)⇒ 活卡帧 / `approval_request` 的卡 / `card_json` /
+     *  重放帧四面同源(见 `ApprovalCardSchema.approvalCard`)。 */
+    approvalCard?: ToolApprovalCard;
     /** E-14:bidi 在场位 —— 与 wire 帧**同一份素材**(`ToolApprovalFrame` 结构上满足本接口)⇒ live 帧 /
      *  `approval_request` / `card_json` / 重放帧四面同源,不是四处各扫一遍。 */
     inputHasBidi?: true;
@@ -880,7 +933,7 @@ export declare function buildApprovalRequestFrame(input: {
 /**
  * 🔴 **呈卡帧的活面事实座**(呈卡腿上旧族退役之后,开卡帧的全部事实都由本族承载)。
  *
- * 这十个座是活卡帧 `tool_approval` 上有、而卡(`ApprovalCardSchema`,`card_json` 的耐久信封)上**没有**的那几位:
+ * 这十个座是活卡帧 `tool_approval` 上有、而卡(`ApprovalCardSchema`,`card_json` 的耐久信封)上**没有**的那几位(`approvalCard` 7.136.0 起也在卡上,见本注末段):
  * 卡外的事实此前只骑活卡帧,呈卡腿的消费方靠「两帧按 approvalId 合读」拿到它们。呈卡腿自此只发本族帧 ⇒ 它们挪到**活铸**的
  * 呈卡帧顶层,同名同型同值 —— 值取自同一只帧对象(活卡帧的那一次铸定,`tool-approval.ts` 的 `askBroadcast`),本仓不另算一遍。
  *
@@ -889,6 +942,9 @@ export declare function buildApprovalRequestFrame(input: {
  * (`readRootCandidate` 有不进卡的硬理由:耐久面兑现不了它,见活卡帧该座顶注)。
  *
  * `requiresRealApproval` 不在表里:卡上 `risk.requiresRealApproval` 是同一个事实(铸卡第三参就是它),一个事实一个读法。
+ * ⚠️ **`approvalCard` 是表里唯一一位 7.136.0 起同时在卡上的座**(`ApprovalCardSchema.approvalCard`:断连重放的卡要渲回同一张专卡,卡词必须进卡;
+ * 同一次读定、同值)。按上一句的规矩它该离表(活铸帧顶层这一份退役 —— wire BREAKING,下游 sdk 的孪生表同改),本版按 additive 交付、未退役:
+ * 一个事实两处读,登记为待收的债,收法 = 离表 + 消费方改读 `card.approvalCard`,不是在这里加第三处。
  */
 export declare const APPROVAL_REQUEST_LIVE_FACT_KEYS: readonly ["mandated", "mandate", "origin", "boundGrantDigest", "boundGrants", "classifierNoRuling", "boundGrantAbsence", "approvalCard", "readRootCandidate", "probeReason"];
 /** 呈卡帧活面事实座的类型面 = 活卡帧同名座的 `Pick`(同型由构造保证,不手抄)。 */
@@ -1015,7 +1071,7 @@ export declare function buildRevokeFrame(batchId: string, askIds: readonly strin
  *    过窗未收敛的行(`expiresInMs === 0`)**仍然重放**,不在这里代打 `expireAsk` CAS(那会制造第五个
  *    竞争者;收敛是车2 的窗到期竞争者与车5 恢复扫描的职责)。
  */
-export declare function buildReplayFrame(row: AskRow, nowMs: number): ApprovalRequestFrame | undefined;
+export declare function buildReplayFrame(row: Pick<AskRow, "askId" | "taskId" | "expiresAtMs" | "cardJson">, nowMs: number): ApprovalRequestFrame | undefined;
 /**
  * [ref] —— 持久行上那张卡**要不要人**:卡面 `risk.requiresRealApproval`(铸卡时取自引擎在 `AskRequest` 上盖的同一位,
  * {@link buildApprovalCard} 第三参)。读者 = 耐久 ask 回决口在裁决之前交给引擎判官 `policyCannotAnswer` 的那一问(`host-decision.ts` 的 `heldAskOf`)。

package/dist/approval-card.js

@@ -1,7 +1,8 @@
 import { z } from "zod";
-import { ALLOW_RULE_MEMBERS, ASK_EVIDENCE_ABSENCE_VALUES, BOUND_GRANT_ABSENCES, DENIAL_LIMIT_BOUNDS, MAX_RULE_TEXT_CHARS, PERSISTED_RULE_MATCHES, UNCOVERED_SEGMENT_REASONS, READ_ROOT_CANDIDATE_DIR_MAX, RESUME_STARTUP_CAUSES, RULE_OFFERS_ABSENCES, RULE_OFFER_KINDS, STEER_REPLAY_FACETS, isAskClass, readRuleOffers, isAskOrigin, isAutoModeFallbackCause, isMintableProbeReason, isPersistedRuleMandate, screenAskClassMembers } from "@sema-agent/core";
+import { ALLOW_RULE_MEMBERS, ASK_EVIDENCE_ABSENCE_VALUES, TOOL_APPROVAL_CARDS, BOUND_GRANT_ABSENCES, DENIAL_LIMIT_BOUNDS, MAX_RULE_TEXT_CHARS, PERSISTED_RULE_MATCHES, UNCOVERED_SEGMENT_REASONS, READ_ROOT_CANDIDATE_DIR_MAX, RESUME_STARTUP_CAUSES, RULE_OFFERS_ABSENCES, RULE_OFFER_KINDS, STEER_REPLAY_FACETS, isAskClass, readRuleOffers, isAskOrigin, isAutoModeFallbackCause, isMintableProbeReason, isPersistedRuleMandate, screenAskClassMembers } from "@sema-agent/core";
 import { redactSecrets } from "./trace/redact.js";
 import { recordFailOpen } from "./observability/fail-open.js";
+import { readApprovalCard } from "./approval-content-kind.js";
 import { capText } from "./caller-text-echo.js";
 import { retireParkArmWords, retireStoredCardWords } from "./retired-card-words.js";
 export const MAX_AGENT_NAME = 200;
@@ -345,6 +346,19 @@ export function parkRowFacts(stored) {
         ...(boundGrantAbsence !== undefined ? { boundGrantAbsence } : {}),
     };
 }
+export function skillCardFacts(summary) {
+    return {
+        ...(summary.boundGrantDigest !== undefined ? { boundGrantDigest: summary.boundGrantDigest } : {}),
+        ...(summary.boundGrants !== undefined ? { boundGrants: summary.boundGrants } : {}),
+        ...(summary.classifierNoRuling !== undefined ? { classifierNoRuling: summary.classifierNoRuling } : {}),
+    };
+}
+export function parkRowCarriesSkillCardFacts(stored) {
+    if (typeof stored !== "object" || stored === null || !("kind" in stored) || stored.kind !== "tool_approval")
+        return false;
+    const digest = "boundGrantDigest" in stored ? stored.boundGrantDigest : undefined;
+    return typeof digest === "string" || ("classifierNoRuling" in stored && stored.classifierNoRuling !== undefined);
+}
 export const DenialLimitFallbackSchema = z
     .object({
     consecutive: z.number().int().nonnegative(),
@@ -377,6 +391,7 @@ export const ApprovalCardSchema = z
         .strict(),
     governanceForced: z.literal(true).optional(),
     rememberRefused: z.literal(true).optional(),
+    approvalCard: z.enum(TOOL_APPROVAL_CARDS).optional(),
     inputHasBidi: z.literal(true).optional(),
     allowRuleShadowed: z
         .array(z
@@ -444,6 +459,7 @@ export function buildApprovalCard(source, req, requiresRealApproval) {
     const sourceTaskId = capText(source.sourceTaskId, MAX_IDENT);
     const sourceAgentName = capText(source.sourceAgentName, MAX_AGENT_NAME);
     const allowRuleShadowed = readAllowRuleShadowed(req);
+    const approvalCard = readApprovalCard(source.approvalCard);
     return {
         toolName: capText(source.toolName, MAX_IDENT) ?? "",
         message: capText(source.message, MAX_MESSAGE) ?? "",
@@ -456,6 +472,7 @@ export function buildApprovalCard(source, req, requiresRealApproval) {
         },
         ...(source.governanceForced === true ? { governanceForced: true } : {}),
         ...(source.rememberRefused === true ? { rememberRefused: true } : {}),
+        ...(approvalCard !== undefined ? { approvalCard } : {}),
         ...(source.inputHasBidi === true ? { inputHasBidi: true } : {}),
         ...(allowRuleShadowed !== undefined ? { allowRuleShadowed } : {}),
         ...(probeCause !== undefined ? { probeCause } : {}),

package/dist/approval-content-kind.d.ts

@@ -19,6 +19,12 @@
  * 不是卡的渲染读法,不在本模块的规则里。
  */
 export { ASK_USER_QUESTION_TOOL_NAME } from "@sema-agent/core";
+/**
+ * core 7.56.0 [ref]:停驻行是不是**引擎自己的问题工具**的(content-ask)—— 读**行的记录**:引擎铸的挂载点 `pendingAction.engineMounted: true` 与保留名同在。
+ * 调用方自己挂的同名工具不带挂载点(引擎只给引擎挂载的工具铸这一位),本版之前停驻的行也没有 ⇒ 都不是。读者:两只决定铸点(顶层 `/decide` 与停驻子代赎回腿)——
+ * 引擎问题工具的决定**不转** `updatedInput`(解析器忽略它,而认领前的编辑复判会在问题专用的 resume-edit 策略下把它拒成 `resume.constraint_rejected`)。
+ */
+export declare function isEngineQuestionRow(pendingAction: unknown): boolean;
 import { PAUSE_REGISTRY, type GateKind, type ToolApprovalCard } from "@sema-agent/core";
 /**
  * 一格卡词的**闭集窄读**(三个载体共用这一只:活 ask、LOCAL 店的停驻门、SQL 店读出的门子树)。成员 ⇒ 那个词;缺席 ⇒ `undefined`(不计);
@@ -48,6 +54,7 @@ export declare function parkedFacetOf(gate: ParkedGateFace | undefined): "A" | "
  * 审批门型 = core `PAUSE_REGISTRY` 里寄存臂是 `tool_approval` 的登记门 —— 与 core `parkedApprovalCardOf` 判「是不是审批门」同一条判据(只在这些门上读卡)。
  * **派生,不手写**(core 7.55.0 [ref] P1 阶段二):此前本仓手写一份二员词表([ref] 时 core 没有导出词表),一次性迁移 M21 又自派生一份;
  * core 加一行审批味的门,这里跟着变,零处要改。读者:决断口与拒扫腿按门型绑定取行(`gateKinds`)、`/decide` 的门型守卫、M21 / M29 的候选扫描。
+ * 包根同出(`index.ts`):嵌入方 / sdk 读这一只,不手抄。
  * 到期分法**不**读这张表 —— SQL 里是由 core 两张表生成的 facet 谓词(`plugins/checkpoint-index-columns.ts`),JS 里是 {@link denySweepOwns}。
  */
 export type ApprovalGateKind = {

package/dist/approval-content-kind.js

@@ -1,4 +1,11 @@
 export { ASK_USER_QUESTION_TOOL_NAME } from "@sema-agent/core";
+import { ASK_USER_QUESTION_TOOL_NAME as QUESTION_TOOL_NAME } from "@sema-agent/core";
+export function isEngineQuestionRow(pendingAction) {
+    if (pendingAction === null || typeof pendingAction !== "object")
+        return false;
+    const pa = pendingAction;
+    return pa.kind === "tool_approval" && pa.engineMounted === true && pa.toolName === QUESTION_TOOL_NAME;
+}
 import { PAUSE_REGISTRY, TOOL_APPROVAL_CARDS, facetOf, isGateKind, parkedApprovalCardOf } from "@sema-agent/core";
 import { recordFailOpen } from "./observability/fail-open.js";
 import { redactSecrets } from "./trace/redact.js";
@@ -33,7 +40,7 @@ export function parkedApprovalCard(gate) {
 export function parkedFacetOf(gate) {
     return gate !== undefined && isGateKind(gate.kind) ? facetOf({ kind: gate.kind, approvalCard: gate.approvalCard }) : undefined;
 }
-export const APPROVAL_GATE_KINDS = Object.keys(PAUSE_REGISTRY).filter((k) => PAUSE_REGISTRY[k].pending === "tool_approval");
+export const APPROVAL_GATE_KINDS = Object.freeze(Object.keys(PAUSE_REGISTRY).filter((k) => PAUSE_REGISTRY[k].pending === "tool_approval"));
 export function isApprovalGateKind(k) {
     return k !== undefined && APPROVAL_GATE_KINDS.includes(k);
 }

package/dist/approval-gate-currency.d.ts

@@ -8,10 +8,26 @@
  *
  * ## 判官
  * 问题:**这把 gate token 是不是该会话当前待决的审批门?**(应答口的答法:`resumeCheckpoint` 的 stale 臂 —— 回显的 token ≠ 该会话当前待决的审批门 ⇒ `409 approval_stale`。)
+ *  · {@link sightsCurrentGate} —— 「决断方回显的**门身份**(token / `checkpointId`)是不是当前门的同一面」的**唯一**比较(`approval_stale` 律,两道决断门一条,见下一节);
+ *    本仓每一处拿**决断方 / 读口给的那把**门身份比「是不是当前门」都经它(`/decide` 的 token 回显、计划审阅的身份回显、下面的 {@link readGateCurrency});
+ *    服务端对**自己选出的那张卡**的复核不是回显比较,不经它(`drivePlanReview` 的卡令牌复核答认领输家 `409 conflict.not_resumable`、唤醒腿的赢家比较);
+ *    射程:本判官问的是「**哪扇门**」;`/decide` 的 [ref] 第二源问的是「**哪只调用**」(回显的 `boundCallId` vs 载入行的 `toolCallId`)—— 两问不同,所以是两条比较,
+ *    不是「不能并」:它们共用同一个 409 答复,缺值规则各按各的问题定(说不出门身份 ⇒ 判「不是」;行上没有 `toolCallId` ⇒ 那一问不判,交引擎的绑定等值校验 fail-closed 兜)。
+ *    过期决断的 409 一族(门身份 / 调用绑定两问怎么排成一族、老行那一形答哪个码)是 7.138.0 的设计票(DEBTS-server,主会话开票);
  *  · {@link currentApprovalGateToken} —— 该会话当前待决的审批门(审批门型优先,没有再退到任一待决行);应答口读它,读口读它,别处不再内联第二份;
  *  · {@link readGateCurrency} —— 一把 token 对着它的读数:`current`(带那一行)/ `absent`(店里没有这一行)/ `settled`(行在,但不再是当前待决门:已结算、已过期、被取代);
  *  · {@link createParkedGateRead} —— 协调器读口的门读席:把读数译成读口要的四种读法({@link ParkedGateReading}),`state` 闭集不加字。
  *
+ * ## `approval_stale` 律(两道决断门一条;[ref] 把计划审阅收进来)
+ * 一句话:**决断体带了「决断方看到的那道门」,而它不是该会话此刻在这道门上待决的那道门 ⇒ `409 approval_stale`,不落决断,拒体带当前门的回显坐标;不带 ⇒ 照旧受理。**
+ * 门的身份有两个面,**同一次铸**在同一行上(core 的每个停驻铸点把 `token` 与 `checkpointId` 一起铸;重开翻的是同一行、两面都不变)⇒ 在带身份的行上两面一一对应:
+ *  · 能力面 `checkpointToken` —— 秘密,永不外发;`/decide` 的老回显键(直连门上拒收);
+ *  · 身份面 `checkpointId` —— 非秘密(park 结果的 `terminal.checkpointId`、运维队列 / 收件行上的那一个);计划审阅能回显的只有它。
+ *    读法只有 `checkpoint-identity.ts` 的信任边界那一只:core 5.42.0 之前铸的老行没有它、没过边界的值不算它 ⇒ 这样的门**说不出**自己的身份面。
+ * 判官 {@link sightsCurrentGate} 只做一件事:回显的那一面 = 当前门的同一面。当前门没有那一面(老行 / 不可信值 / 调用方没读行)⇒ 不是(fail-closed:拒,不放)。
+ * 「当前门」由每道门按**自己的门型**选(`/decide` = {@link currentApprovalGateToken};计划审阅 = 它的选卡读),判官门型无关。
+ * 不把能力面先解成身份面再比:两面在同一行上同生同灭,比能力面就是比这一行;先解一次只会在快路上多一次店读,并在老行上(两边都读不出身份面)把两道不同的门判成同一道。
+ *
  * ## 一个读数只取自一个时刻([ref])
  * 门身份就是 token:引擎重开一张门(`reopen`:续跑腿在被批准的动作开跑之前失败)翻的是**同一行**(resolved → pending,token 不变)。所以「这张卡此刻在哪」可以在两次店读之间
  * 来回变(待决 → 被决 → 被重开);判官的分类只用**同一时刻成立**的读数:
@@ -33,8 +49,10 @@
  *    表明说 `decided` ⇒ 往下读;明说 `void` ⇒ `void`(没有人决过它,答案无处兑现 —— 已过期〔取消 / 收割〕、仍待决却不是当前门〔被取代,应答口答 stale〕、
  *    结算种类是引擎窗到期 / 宿主 SLA 扫 / 无人可答的失败族);**表外 ⇒ `unknown`**(读不懂的词撑不起「有人决过」,也撑不起「没有人决过它」);
  *  ② 结算赢家的门记录 `resolvedOutcome.gateOutcome` 先过 core 唯一的门记录筛 `screenGateOutcome`(**档案读法**:读回的耐久行,闭集 = 今日成员 ∪ 已退役词;
- *    坏形记缺陷、绝不抛;本仓 `trace/project.ts` 投影同一种记录也只经这一只筛),有缺陷 ⇒ `unknown`,过了筛才读它的成员;
- *  ③ 分类之前记录要**读得全**:有结算记录、时刻(引擎写进赢家的 `settlement.when`)是有限数、赢家绑的是这一行的调用且判词是 allow / deny(与
+ *    坏形记缺陷、绝不抛;本仓 `trace/project.ts` 投影同一种记录也只经这一只筛),有缺陷 ⇒ `unknown`,过了筛才读它的成员。core 7.56.0 [ref] 起筛自己判
+ *    I10(`settlement.when` 是有限数)与 I11(调用方把赢家的 `decision` 一并交给筛:它是赢家拿得出的词,方向与记录的结算种类 / 处置同向)—— 本判官在同一次筛调用里
+ *    交 `winnerDecision`,时刻与方向的手判随之退役;
+ *  ③ 分类之前记录要**读得全**:有结算记录、赢家绑的是这一行的调用且判词是 allow / deny(与
  *    `findDecidedApprovalsForBinding` 同一只 {@link approvalDecisionOfWinner})—— 缺一个都是 `unknown`(**不编一个首决**;读口答 404,应答口对已结算的门答 409 `approval_stale`,两口不同判;
  *    `void` 也要读得全:绑在别的调用上的结算说的不是这张卡);读全了再按**结算种类**表分类:人 / 策略的四个种类 ⇒ `decided`(理由取自赢家的 `reason`),其余十个 ⇒ `void`
  *    (按种类不按当事方:跨版本稳定的是种类词,变过义的是当事方词 —— 此前版本的策略拒记 `policy_refused` + `who.party:"none"`,此后记 `"policy"`,按当事方查会把那一代合法历史记录读成 `void`);
@@ -42,14 +60,38 @@
  * `unknown` 的这一类(`decision_unreadable`)带上读不出的那几处(缺陷句,非空):读口答 404 `tool_approval.not_pending`,并记一行 error(首句 + 计数)。
  * 行没了 ⇒ `unknown`(`row_absent`;应答口 PARKED 臂的 404 `not_found.approval` 同判)。
  *
- * ## 盲区(core 的筛不判的两处,如实写下:一处本判官手判有限数,一处本判官也不核)
- *  · 结算时刻 `settlement.when`:筛不判,本判官手判「有限数」;而本仓另一个读同一种记录的读者(trace 投影)把 `when` 原样放上 wire —— 同一个坏时刻,两个读者两种答法;
- *  · 方向与配对:赢家的方向(`resolvedOutcome.decision`)与记录自己的种类 / 处置说的方向是否一致,以及种类 × 当事方的配对 —— 筛不判,本判官也不核:读口以赢家的方向为准、读的是种类。
- * 只有坏行 / 手改行才走得到这两处。候引擎的筛把时刻、方向与种类 × 当事方配对一并判了,两个读者同时退掉各自的手判(配对今天没有手判可退 —— 它无人判)。
+ * ## 盲区(core 的筛仍不判的一处,如实写下)
+ *  · 种类 × 当事方的配对(结算种类与 `settlement.who` 的当事方是否相配)—— 筛不判(core KL-1265-b),本判官也不核:读的是种类。只有坏行 / 手改行才走得到。
+ *  (时刻与方向两处自 core 7.56.0 [ref] 起由筛判:I10 / I11。trace 投影读同一种记录、经同一只筛,零改即得 I10 —— 坏时刻在两个读者那里是同一个答法。)
  */
 import { type Checkpoint, type CheckpointToken, type SettlementKind } from "@sema-agent/core";
 import { type PendingRowBinding } from "./plugins/checkpoint-store-sql.js";
 import { type ParkedGateRead } from "./tool-approval.js";
+/**
+ * 决断方回显的「我看到的那道门」—— 门的两个身份面之一(两面的来历与读法见模块头注「`approval_stale` 律」)。
+ * `face` 就是回显它的那个体键名:`/decide` 的 `checkpointToken`,计划审阅的 `checkpointId`。
+ */
+export type GateSighting = {
+    readonly face: "checkpointToken" | "checkpointId";
+    readonly value: string;
+};
+/**
+ * 当前门的身份面。能力面恒在;身份面在场 ⇔ 行上的 `checkpointId` 过了信任边界 —— 老行 / 没过边界 / 调用方没读行时缺席,
+ * 缺席读作「说不出它的身份面」(判官据此对身份面回显答「不是」),**不**读作「没有门」。
+ */
+export interface CurrentGateFaces {
+    readonly checkpointToken: string;
+    readonly checkpointId?: string;
+}
+/** 一道已载入的当前门 → 它的两个身份面(身份面只经 {@link trustedCheckpointId};它含 token 的形在这里就被当成缺席,永不上比较、永不上 wire)。 */
+export declare function currentGateFacesOf(token: string, row: {
+    readonly checkpointId?: unknown;
+}): CurrentGateFaces;
+/**
+ * `approval_stale` 律的**唯一**判官:回显的那一面是不是当前门的同一面(律全文见模块头注)。没有当前门(`null` / `undefined`)⇒ 不是;
+ * 当前门说不出回显的那一面 ⇒ 不是(fail-closed)。调用点:`/decide` 的 token 回显、计划审阅的身份回显、本模块的 {@link readGateCurrency}。
+ */
+export declare function sightsCurrentGate(sighting: GateSighting, current: CurrentGateFaces | null | undefined): boolean;
 /** 判官要的两个店口(三后端同形;窄接口让测试与装配都不必拿整只店)。 */
 export interface GateCurrencyStore {
     get(token: CheckpointToken): Promise<Checkpoint | null>;

package/dist/approval-gate-currency.js

@@ -1,13 +1,21 @@
-import { REOPEN_REASONS, screenGateOutcome } from "@sema-agent/core";
+import { REOPEN_REASONS, checkpointRevOf, screenGateOutcome } from "@sema-agent/core";
 import { approvalDecisionOfWinner } from "./plugins/checkpoint-store-sql.js";
 import {} from "./tool-approval.js";
 import { APPROVAL_GATE_KINDS } from "./approval-content-kind.js";
+import { trustedCheckpointId } from "./checkpoint-identity.js";
+export function currentGateFacesOf(token, row) {
+    const checkpointId = trustedCheckpointId(row.checkpointId, token);
+    return checkpointId === undefined ? { checkpointToken: token } : { checkpointToken: token, checkpointId };
+}
+export function sightsCurrentGate(sighting, current) {
+    if (current === null || current === undefined)
+        return false;
+    const face = current[sighting.face];
+    return face !== undefined && face === sighting.value;
+}
 export async function currentApprovalGateToken(cs, sessionId) {
     return (await cs.findPendingTokenBySession(sessionId, undefined, { gateKinds: APPROVAL_GATE_KINDS })) ?? (await cs.findPendingTokenBySession(sessionId));
 }
-function revisionOf(cp) {
-    return cp.rev ?? 0;
-}
 const GATE_READ_ROUNDS = 3;
 export async function readGateCurrency(cs, gateToken) {
     const token = gateToken;
@@ -17,10 +25,11 @@ export async function readGateCurrency(cs, gateToken) {
             return { kind: "absent" };
         if (row.status !== "pending")
             return { kind: "settled", checkpoint: row };
-        const isCurrent = (await currentApprovalGateToken(cs, row.sessionId)) === gateToken;
+        const currentToken = await currentApprovalGateToken(cs, row.sessionId);
+        const isCurrent = sightsCurrentGate({ face: "checkpointToken", value: gateToken }, currentToken ? { checkpointToken: currentToken } : null);
         const again = await cs.get(token);
         if (again !== null && again.status === "pending") {
-            if (revisionOf(again) === revisionOf(row))
+            if (checkpointRevOf(again) === checkpointRevOf(row))
                 return isCurrent ? { kind: "current", checkpoint: again } : { kind: "settled", checkpoint: again };
             if (round === GATE_READ_ROUNDS)
                 throw new Error(`the checkpoint row moved between reads in ${GATE_READ_ROUNDS} rounds in a row (decided and reopened each time): there is no single-instant reading of its gate`);
@@ -68,14 +77,12 @@ function decisionReading(checkpoint, gateBoundCallId) {
 function readWinner(checkpoint, gateBoundCallId) {
     const winner = checkpoint.resolvedOutcome;
     const recorded = winner?.gateOutcome;
-    const [defect, ...more] = screenGateOutcome(recorded, { reading: "archive" });
+    const [defect, ...more] = screenGateOutcome(recorded, { reading: "archive", ...(winner !== undefined ? { winnerDecision: winner.decision } : {}) });
     if (defect !== undefined)
         return unreadable([defect, ...more]);
     const settlement = recorded?.settlement;
     if (settlement === undefined)
         return unreadable(["the gate record carries no settlement: no decider and no time"]);
-    if (!Number.isFinite(settlement.when))
-        return unreadable(["settlement.when is not a finite epoch-ms time"]);
     const boundCallId = gateBoundCallId ?? (checkpoint.pendingAction.kind === "tool_approval" ? checkpoint.pendingAction.toolCallId : "");
     const direction = approvalDecisionOfWinner(winner, boundCallId);
     if (direction === null)

package/dist/approval-hmac.d.ts

@@ -20,6 +20,8 @@ import type { ApprovalHmacKey } from "./auth-keys.js";
  * `reason`,以及 [ref] 起的 `permissionModeAfter`)。⇒ 「同一张卡上把 approve 的档偷偷调宽」这件事,
  * 结构上只有 HMAC 这一把拦得住;往 `cnf.bnd` 里加位既不解决它,还会把一份合法 JWT 绑死在一个它签发时
  * 根本不知道的值上。**本次([ref] F1)只动 HMAC 这一把,`approvalBnd` 一个字节不动。**
+ * [ref] 同一判断:`plan_review` 的门身份 `checkpointId` 进 HMAC 的扩展对象,不进 `cnf.bnd` —— 计划审阅的 `cnf.bnd` 绑的是会话(它的第二位是一次性 nonce),
+ * 签发 JWT 的一方不知道此刻是哪道计划门;知道的是作决断的那一方,而 HMAC 正是它签的。
  *
  * ── 🔴 字节构造规则(权威定义;跨仓签名器照此实现,docs/ASSISTANT-WIRE-CONTRACT.md §6.2 同源)──────────
  * 被 HMAC 的是下面这个字符串的 **UTF-8 字节**:
@@ -81,7 +83,7 @@ export declare function questionAnswerFromProjection(p: QuestionAnswerProjection
  * 下面那两条编译期门当场红。**不许有第三种在场判**:恒 `!== undefined`(不是真值判、也不是 `?? null`
  * 折叠)—— `null` 与缺席在扩展位上是两个不同的被签值(「签名方明说这次不动」≠「签名方不知道有这个键」)。
  */
-export declare const APPROVAL_ENVELOPE_EXT_KEYS: readonly ["answer", "permissionModeAfter"];
+export declare const APPROVAL_ENVELOPE_EXT_KEYS: readonly ["answer", "checkpointId", "permissionModeAfter"];
 export type ApprovalEnvelopeExtKey = (typeof APPROVAL_ENVELOPE_EXT_KEYS)[number];
 /** The canonical envelope both {@link approvalHmacMessage} (the signer's/verifier's shared byte-rule) and
  *  {@link verifyApprovalHmac} take — ONE named type so the two signatures cannot silently drift into two
@@ -105,6 +107,16 @@ export interface ApprovalEnvelope {
      * 值是 {@link projectQuestionAnswer} 的产物,不是请求体上那个对象(理由见该函数)。
      */
     answer?: QuestionAnswerProjection;
+    /**
+     * 🔴 **[ref](7.137.0)—— `plan_review` 决断方看到的那道门(`checkpointId`)进签名载荷。**
+     *
+     * 计划审阅的证明只绑会话(`cnf.bnd` = 会话 + 一次性 nonce + 内容哈希),不绑门 ⇒ 决断体上的门身份是这次决断**落在哪道门**的唯一陈述
+     * (不是当前门 ⇒ `409 approval_stale`)。不签它,能改写线上字节的一方就能把它摘掉(陈旧保护整个不在)或换掉;拒收它则把这项保护在直连门部署上整个关掉。
+     * 判据扩成一句:**凡决定这次决断落在哪道门、续跑能做什么 / 落什么账的决裁字段都在签名信封里**。
+     * 与 `permissionModeAfter` 同形:在场才进扩展对象,缺席 ⇒ 字节与不认识它的签名器逐字相同(既有签名器零改动);带了不签 ⇒ `401 approval_mac_invalid`。
+     * `/decide` 不送它(那道门的门身份是 `boundCallId` / `boundInputHash`,已在前五位)。
+     */
+    checkpointId?: string;
     /**
      * 🔴 **[ref] 合并复审 F1 [high]**(7.86.0 立,[ref] 把它从裸尾位挪进扩展对象)—— `plan_review` 的
      * `permissionModeAfter` 选的是**批准之后这条 run 有没有手**(`acceptEdits` = 工作目录内的写不再逐次

package/dist/approval-hmac.js

@@ -5,7 +5,7 @@ export function projectQuestionAnswer(a) {
 export function questionAnswerFromProjection(p) {
     return { answers: p.map(([header, selected, note]) => ({ header, selected: [...selected], ...(note === null ? {} : { note }) })) };
 }
-export const APPROVAL_ENVELOPE_EXT_KEYS = ["answer", "permissionModeAfter"];
+export const APPROVAL_ENVELOPE_EXT_KEYS = ["answer", "checkpointId", "permissionModeAfter"];
 const APPROVAL_ENVELOPE_HEAD_KEYS = ["sessionId", "boundCallId", "boundInputHash", "decision", "reason"];
 export function approvalHmacMessage(env) {
     const head = [env.sessionId, env.boundCallId ?? null, env.boundInputHash ?? null, env.decision, env.reason ?? null];

package/dist/approval.js

@@ -1,4 +1,4 @@
-import { createApprovalPolicy, isNamespacedCoveringRuleName, namespacedRuleNameCovers } from "@sema-agent/core";
+import { createApprovalPolicy, isCoveringRuleName, ruleNameCovers } from "@sema-agent/core";
 import { operatorAlwaysHumanAsk, operatorAsk, requestAlwaysHumanAsk } from "./operator-ask.js";
 import { ASK_USER_QUESTION_TOOL_NAME } from "./approval-content-kind.js";
 import { isExplicitPosture } from "./posture-source.js";
@@ -116,10 +116,10 @@ export function createDeploymentListExemption(store, sessionId, logger, leg) {
 }
 function createNameSetMatcher(names) {
     const exact = new Set(names);
-    const covering = names.filter((name) => isNamespacedCoveringRuleName(name, NAME_TABLE_BEHAVIOR));
+    const covering = names.filter((name) => isCoveringRuleName(name, NAME_TABLE_BEHAVIOR));
     if (covering.length === 0)
         return (toolName) => exact.has(toolName);
-    return (toolName) => exact.has(toolName) || covering.some((rule) => namespacedRuleNameCovers(rule, toolName));
+    return (toolName) => exact.has(toolName) || covering.some((rule) => ruleNameCovers(rule, toolName));
 }
 export const AUTO_APPROVE_BUDGET_APPROVER = "auto_approve_budget";
 function budgetSeatAnswer(req, requireHit, signal) {

package/dist/auth-bridge.d.ts

@@ -1,7 +1,7 @@
 import { type AuthBridgeErrorCode, type VerifiedIdentity } from "@sema-agent/settings-schema/api/auth-bridge";
+import { type TokenScopeRefusal } from "@sema-agent/settings-schema/api/scopes";
 import type { Logger } from "./observability/logger.js";
 import type { Metrics } from "./observability/metrics.js";
-export type { VerifiedIdentity } from "@sema-agent/settings-schema/api/auth-bridge";
 /**
  * [ref] ② —— 鉴权桥 issuer 的**唯一**取值(装配 `boot/stage-09-leader.ts` 与 caps `centerWiring.issuer` 同读,不各写一份回退):
  * 显式 `AUTH_BRIDGE_ISSUER`(`config.authBridgeIssuer`)恒赢 ⇒ `source:"explicit"`;缺席则回退中心基址 `webAdmin.baseUrl`
@@ -34,13 +34,41 @@ export interface WebAdminJwtVerifierOptions {
     fetchImpl?: typeof fetch;
     nowMs?: () => number;
 }
+/** 验证腿的拒因(闭集)= 契约 R9 的五个码 ∪ `readTokenScope` 的拒词;两边都是契约的闭集,加词 ⇒ 这里随之变宽(穷举分支的读者编译红)。 */
+type AuthBridgeRefusal = AuthBridgeErrorCode | TokenScopeRefusal;
+/** 本服务受理的桥身份:契约 `VerifiedIdentity`(验证器「令牌带了什么」的报告形)之上,scope 经 `readTokenScope` 读定后**必带**。 */
+type BridgeIdentity = Omit<VerifiedIdentity, "scope"> & {
+    scope: string;
+};
 export type VerifyOutcome = {
     ok: true;
-    identity: VerifiedIdentity;
+    identity: BridgeIdentity;
+} | {
+    ok: false;
+    error: AuthBridgeRefusal;
+};
+/** 拒因记账的去处(验证器选项与 HTTP 装配各自持有同一对 logger / metrics)。 */
+type BridgeSinks = {
+    readonly logger?: Logger | undefined;
+    readonly metrics?: Pick<Metrics, "inc"> | undefined;
+};
+/** 注入边界收的结局:与 {@link VerifyOutcome} 同形,只是成功身份的 `scope` 是 `unknown` —— 这一位正是边界要判的形,它不信型面
+ *  (席是嵌入方可换的:`""` 过得了 `scope: string`,JS 侧连缺省 / 非串都交得进来)。`VerifyOutcome` 可赋给它,调用方零改动。 */
+type ReportedOutcome = {
+    ok: true;
+    identity: Omit<BridgeIdentity, "scope"> & {
+        scope?: unknown;
+    };
 } | {
     ok: false;
-    error: AuthBridgeErrorCode;
+    error: AuthBridgeRefusal;
 };
+/**
+ * 注入边界:任何验证器(内建 {@link createWebAdminJwtVerifier},或嵌入方注入的 `ServiceDeps.webAdminJwtVerifier`)交来的结局,在这里定「装不装身份」。
+ * 成功身份的 scope 经**同一只** `readTokenScope` 再读一次(入参型见 {@link ReportedOutcome})。
+ * 读不出 ⇒ 同一只记账口、不交身份(调用方按验证失败处置:不设身份 ⇒ 门答 generic 401)。验证失败的结局验证器自己已记过账,这里只答「不装」。
+ */
+export declare function admitBridgeIdentity(outcome: ReportedOutcome, sinks: BridgeSinks): BridgeIdentity | undefined;
 /** The live object `createWebAdminJwtVerifier` produces — a single `verify` entry point over the process-level JWKS cache. */
 export interface WebAdminJwtVerifier {
     verify: (bearer: string) => Promise<VerifyOutcome>;
@@ -50,8 +78,9 @@ export declare const DEFAULT_JWKS_TTL_SEC: number;
 /** 一次 JWKS 拉取的时限(毫秒):kid 未知、超离线宽限、后台刷新三条路用同一只拉取,同一个时限。 */
 export declare const JWKS_FETCH_TIMEOUT_MS = 10000;
 /**
- * registry-JWT verifier(单例,进程级 JWKS 缓存)。`verify(bearer)` 全程不 throw——一切异常折为
- * AUTH_BRIDGE_ERROR_CODES(HTTP 面由调用方恒答 generic 401,码只进日志/metrics,R9)。
+ * registry-JWT verifier(单例,进程级 JWKS 缓存)。`verify(bearer)` 全程不 throw——一切异常折为拒因闭集
+ * {@link AuthBridgeRefusal}(HTTP 面由调用方恒答 generic 401,码只进日志/metrics,R9)。
  */
 export declare function createWebAdminJwtVerifier(opts: WebAdminJwtVerifierOptions): WebAdminJwtVerifier;
+export {};
 //# sourceMappingURL=auth-bridge.d.ts.map