@sema-agent/server 7.132.0 → 7.134.0

package/dist/tool-approval.d.ts

@@ -50,7 +50,7 @@
  * — same posture as question/elicit. The frame's model-authored surfaces (message + args) are secret-REDACTED
  * before they are streamed; the SIZE bound is per-surface: args ride a byte cap (`MAX_APPROVAL_ARGS_BYTES`,
  * over-cap ⇒ `argsOmitted`), while the legacy frame's `message` is redacted but NOT length-capped — the char
- * cap (`MAX_MESSAGE`, approval-card.ts `clip`) lives on the card/`approval_request` projection only (same
+ * cap (`MAX_MESSAGE`, approval-card.ts `capText`) lives on the card/`approval_request` projection only (same
  * redact-at-write contract as question; the args are shown to a human,
  * never re-fed to a model). No throttle (unlike question): an approval breach-default would be a DENY (task failure),
  * and asks are turn-blocking by construction — the TTL bounds the human-side exposure instead.
@@ -60,7 +60,8 @@ import { type ApprovalDecidedBy, type HostSettledBy, type RetiredDecisionKeyFact
 import type { IncomingMessage } from "node:http";
 import { type AskClass, type AskRequest, type AskOutcome, type PermissionResult, type CheckpointGate, type PendingAction, type PersistedRuleMandate, type ReadRootGrantCandidate, type RuleOffer, type AutoModeFallbackCause, type BoundGrantAbsence, type BoundSkillGrants, type ToolApprovalCard } from "@sema-agent/core";
 import { type CardRulePersisted, type RuleConsentLane } from "./rules-consent.js";
-import { type AllowRuleShadowProjection, type DenialLimitFallback, type RuleOffersAbsence, type ApprovalRequestFrame, type ApprovalRevokeFrame, type RuleEvidenceProjection } from "./approval-card.js";
+import type { GateCurrencyStore } from "./approval-gate-currency.js";
+import { type AllowRuleShadowProjection, type DenialLimitFallback, type RuleOffersAbsence, type ApprovalRequestFrame, type ApprovalRevokeFrame, type ApprovalCardLegFrame, type ApprovalCompleteFrame, type RuleEvidenceProjection } from "./approval-card.js";
 import { type ApprovalAskStore, type AskRow } from "./plugins/approval-ask-store-sql.js";
 import type { ApprovalAskAuditSink } from "./approval-ask-audit-store.js";
 import { type AskRowEndingCause, type SettleCause, type SettleOutcome } from "./approval-deny-reasons.js";
@@ -83,6 +84,17 @@ export declare function isApprovalGateKind(k: string | undefined): k is Approval
 export declare function denySweepOwns(gate: ParkedGateFace | undefined): boolean;
 /** 两方言同形的 SQL IN 片段(值为闭集常量字面,无注入面)。 */
 export declare const APPROVAL_GATE_KINDS_SQL_IN: string;
+/** {@link ToolApprovalCoordinator.adoptOpenAsks} 的读数(装配点进启动日志)。 */
+interface OpenAskAdoption {
+    /** 本次接管进活集合的问数。 */
+    readonly adopted: number;
+    /** 本副本已有这只问的登记(活登记或先前接管过)而跳过的问数 —— 幂等的那一半。 */
+    readonly alreadyLive: number;
+    /** 行上卡信封读不出(唯一信封读者不认)而没接管的问数 —— 列不出卡就不列(开流 preamble 跳坏行同判)。 */
+    readonly cardUnreadable: number;
+    /** 待决行多于 {@link ADOPT_OPEN_ASKS_MAX}:只接管了最先的那么多只。 */
+    readonly capped: boolean;
+}
 /**
  * 耐久回决口 `POST /v1/approvals/:sessionId/decide` 的路径串 —— S-1280:迟到回决口 PARKING 臂 202 体的机读指路 `decidePath`。
  * 路由表那一行(`http/routes/approvals-assistant.ts` 的 `approval-decide`)按 pattern 匹配它;两者同形由往返钉守
@@ -94,12 +106,45 @@ export declare function approvalDecidePath(sessionId: string): string;
  * DECIDED/PARKED 已从 404 分流(DECIDED ⇒ 200 回放首决,回执带 `decidedBy`,**不是**成因;PARKED ⇒ 赎回席),残余两类:
  *  · 行 `VOID` / `DENIED`(没有人决过它)—— `cause` = **行上记的那个成因词**(问账 `denied_reason` 列;与决断口 410 `gone.ask` 体的 `cause`、审计 settle 行
  *    的 `cause` 同一个词,闭集 {@link SettleCause});行上没写归因(存量行)⇒ 缺席,不替没写的行编一个词;
- *  · {@link NOT_PENDING_UNKNOWN_CAUSE} —— 无墓碑 / 无行 / 行仍在别处活着:换副本或换端点重试才有意义(这个词只属于 404 面,不是结局成因)。
+ *  · {@link NOT_PENDING_UNKNOWN_CAUSE} —— 无行 / 行不是调用方的 / 行仍在别处活着:换副本或换端点重试才有意义(这个词只属于 404 面,不是结局成因)。
  * 对齐 [ref] 反枚举语义:cause 只在**已过属主门**的面上出,不扩枚举面(属主门不过 = 与未知 id 同形)。
  * **无持久店的部署上恒不带**:那台机器压根没有行可判,编一个 cause 是撒谎(D1 体逐字不变)。
  */
 export declare const NOT_PENDING_UNKNOWN_CAUSE: "unknown_or_other_replica";
 export type NotPendingCause = AskRowEndingCause | typeof NOT_PENDING_UNKNOWN_CAUSE;
+/**
+ * `GET /v1/tool-approvals/:approvalId` 应答体 `state` 的**闭集**(一只 ask 此刻在哪一态;读法与应答口逐条同源):
+ *  · `pending` —— 本副本上有在等它的活登记(应答口此刻收得下);
+ *  · `decided` —— 行 `DECIDED`(有人 / 有策略决过;回执三键同晚答回放体),**或**行 `PARKED` 而它的门已被决(S-1915:checkpoint 已结算,见 {@link ParkedGateReading});
+ *  · `parked`  —— 行 `PARKING`,或行 `PARKED` 且门仍是该会话当前待决的审批门(转后台候批;应答口走迟到受理,耐久回决口照收);
+ *  · `void`    —— 行 `DENIED` / `VOID`(没有人决过它,答案无处兑现;`cause` 同晚答 404),**或**行 `PARKED` 而它的门已过期 / 被取代(含停驻 run 被取消;此时 `cause` 缺席)。
+ */
+export declare const TOOL_APPROVAL_READ_STATES: readonly ["pending", "decided", "parked", "void"];
+export type ToolApprovalReadState = (typeof TOOL_APPROVAL_READ_STATES)[number];
+/** 行 → 读口的行投影:键名是列表面 {@link LivePendingRow} 的同名子集(一个读者一套键);`frame` = 断连重放的那一只呈卡帧(卡读不出 ⇒ 缺席)。 */
+export interface AskRowReadProjection {
+    approvalId: string;
+    ts: number;
+    expiresAtMs: number;
+    sessionId?: string;
+    toolName?: string;
+    frame?: ApprovalRequestFrame;
+}
+/** `GET /v1/tool-approvals/:approvalId` 的 200 体:列表面同一只行投影 + `state` + 各态附键。 */
+export type ToolApprovalReadBody = ({
+    state: "pending";
+} & LivePendingRow) | ({
+    state: "decided";
+    decision: "allow" | "deny";
+    decidedAtMs: number;
+    decisionNote?: string;
+} & AskRowReadProjection) | ({
+    state: "parked";
+    decidePath?: string;
+} & AskRowReadProjection) | ({
+    state: "void";
+    cause?: AskRowEndingCause;
+} & AskRowReadProjection);
 /**
  * 结算一张卡的**判决** —— 判别联合,逼每个调用点说清「这次等待是怎么结束的」:
  *  · `by:"human"` —— 一次**决议**到了(人答,或从问账行读回来的决议,含部署政策拒落成的 `DECIDED` 行,`hostSettledBy` 记它的来源词):`allowed` 说方向;审计 settle 行
@@ -140,6 +185,9 @@ export type SettleVerdict = {
  *
  * 语义边界(禁扩读):它答的是「本副本此刻有没有活体消费者」,**不是**「这条 run 还活着吗」——持有
  * 悬挂 promise 的可能是另一个副本(F4 的轮询腿会在它自己的下一拍续跑)。run 的生死读 run 面。
+ *
+ * S-247 起**同一个词、同一句语义**也出现在 live 面:审批机起服时从问账接管的登记(没有引擎腿在等)在 `livePending` 行上带它,
+ * 在 live 应答口的 200 回执上按同一判据(本副本被唤醒的等待腿数 = 0)带它。一个事实,各面一个读法。
  */
 export declare const ASK_DECISION_CONSUMER_ABSENT = "absent";
 /**
@@ -179,6 +227,37 @@ export type ParkedAskRedeem = (req: ParkedAskRedeemRequest) => Promise<{
     status: number;
     body: Record<string, unknown>;
 }>;
+/**
+ * 按问读口对一张 `PARKED` 卡的**门读法**(S-1915;判官的唯一属主 = `approval-gate-currency.ts`,协调器本身不认识 checkpoint 的形):
+ *  · `open` —— 这张卡的门仍是该会话当前待决的审批门(应答口收得下)⇒ 读口说 `parked`;
+ *  · `decided` —— 门已被决:方向 / 时刻 / 理由取自 checkpoint 上的结算赢家 ⇒ 读口说 `decided`;
+ *  · `void` —— 门已过期 / 被取代(含停驻 run 被取消:取消先把门 expire)⇒ 读口说 `void`(没有人决过它,答案无处兑现);
+ *  · `unknown` —— 说不出可信的话:`row_absent` = checkpoint 行没了;`decision_unreadable` = 门已结算却读不出可用的决议(行的 status 词或结算种类不在闭集表里 / 结算记录过不了 core 的
+ *    门记录筛 / 方向或时刻读不出)⇒ 读口答 404 `tool_approval.not_pending`(坏行不包装成首决;应答口并不同判:它的 PARKED 臂只对 checkpoint 行没了答 404,已结算的门答 409 `approval_stale`),
+ *    并记一行 error:`defects` 是读不出的那几处(非空),日志带首句 + 计数。
+ */
+export type ParkedGateReading = {
+    readonly kind: "open";
+} | {
+    readonly kind: "decided";
+    readonly decision: "allow" | "deny";
+    readonly decidedAtMs: number;
+    readonly decisionNote?: string;
+} | {
+    readonly kind: "void";
+} | {
+    readonly kind: "unknown";
+    readonly why: "row_absent";
+} | {
+    readonly kind: "unknown";
+    readonly why: "decision_unreadable";
+    readonly defects: readonly [string, ...string[]];
+};
+/** 门读席:入参 = 问账行上的 gate 坐标(PARKED 行恒带 `gateToken`)。读不出(店抛错)⇒ 抛,协调器按店故障姿势处置(见 `readParkedGate`)。 */
+export type ParkedGateRead = (row: {
+    readonly gateToken: string;
+    readonly gateBoundCallId: string | null;
+}) => Promise<ParkedGateReading>;
 /** 阶梯里**重发**一把 claim 的墙钟上限(ms;首把用 `DURABLE_CALL_TIMEOUT_MS`)。🔴 codex 交叉复审 C5
  *  (2026-08-06 真缺陷):只数重试次数是**不够**的 —— 次数只约束「已经返回或已经 reject 的调用」,一次
  *  **挂住不返回**的店调用(DB 连接黑洞、池饿死)会让整个退避循环连一格都走不完,`onAsk` 的 promise 于是永久
@@ -315,7 +394,9 @@ export declare function parkRowStandingAnswerFacts(stored: Extract<PendingAction
 deploymentListAsks: boolean): StandingAnswerFacts;
 /** A live approval frame delivered to whoever tails this run's stream. `type` IS the SSE event name (named-event
  *  convention, same as question). The shell renders `tool_approval` as the CC three-choice card and dismisses on
- *  `tool_approval_complete`. */
+ *  `tool_approval_complete`.
+ *  🔴 **旧族**:只投给呈卡协议未上场的腿(一条腿一个帧族,见 {@link ToolApprovalRunContext});呈卡腿上同一次铸定的这只对象仍是
+ *  卡外开卡事实的来源(`ApprovalRequestLiveFacts` 取自它)与 `livePending` 行的 `frame`。 */
 export interface ToolApprovalFrame {
     type: "tool_approval" | "tool_approval_complete";
     approvalId: string;
@@ -539,7 +620,7 @@ export interface ToolApprovalFrame {
      *  `approval_request` 帧([ref] 呈卡帧)同名同义:`expiresAtMs` = 本 ask 的绝对到期墙钟
      *  (有店=行上一次铸定的 `expiresAtMs`,与卡帧/落库同值;无店 D1=注册时刻算定的同名初值),
      *  `serverNowMs` = **帧铸造时刻**(cli [ref] 锚定语义:倒计时锚=帧到手时刻的服务器钟),
-     *  `expiresInMs` = `max(0, expiresAtMs - serverNowMs)` 现算。三键同生同缺(windowZero 腿不发帧,
+     *  `expiresInMs` = `max(0, expiresAtMs - serverNowMs)` 现算。三键同生同缺(没有活审批通道的腿不发帧,
      *  发出的帧恒带);旧消费端无感,新壳借此给旧族帧补倒计时([ref] Q2 那类 77 分钟死卡的根治半场)。 */
     expiresAtMs?: number;
     expiresInMs?: number;
@@ -684,10 +765,8 @@ export interface ToolApprovalFrame {
      *  真才带)——`outcome:"expired"` 一词三义(park / 当场 deny / 无设施 deny,见 outcome 注)里 **park
      *  那一义的显式判别位**:在场 ⇔ **这条 ask 本身**按 park 路由收尾(`parkRouted`,settle 咽喉里置位;
      *  [ref] F1/F3:首版读政策口〔unattendedPolicy+askStore 在场〕,对批内被连坐 VOID 的兄弟、取消/断连、
-     *  D5 fail-open 等非 park 终局全撒谎)。⚠️ **判据是路由,不是墓碑**([ref] 起 `recordParkTombstone`
-     *  在两种容量拒新形下不落墓碑,置位与落墓碑可不同步;取舍全文见 settle 咽喉那段注):常态墓碑同拍
-     *  已落 ⇒ 同一把 `approvalId` 仍可打 `respond` 走迟到受理兑现(wire 契约迟到受理段);拒新两形下
-     *  live 迟到腿如实 404(unknown_or_other_replica),壳按既有协议回落 durable gate([ref] Q3)。
+     *  D5 fail-open 等非 park 终局全撒谎)。同一把 `approvalId`(= 行的键)仍可打 `respond` 走迟到受理兑现
+     *  (wire 契约迟到受理段;迟到腿直接读行,任一副本可达)。
      *  壳据此把「卡失效」改渲「已转后台候批」。缺席**禁**读作
      *  「真 deny」:无店部署 / deny 政策 / VOID 兄弟都发不出这个键,缺席只是「无 park 证据」。 */
     parked?: true;
@@ -720,7 +799,7 @@ export interface ToolApprovalFrame {
  *  ——两族行形与决议路由不同:本族行的决议口=`POST /v1/tool-approvals/:approvalId/respond`,durable 行
  *  =decide 口;数组名即路由判据)。可选位全部「只记真、缺席不编」。 */
 export interface LivePendingRow {
-    /** = `respond()` 收的 wire id(pending Map 的 uuidv7 键;同源可达)。 */
+    /** = `respond()` / `GET /v1/tool-approvals/:id` 收的 wire id:有行的 ask = 行的键 `askId`,无行的 ask = 登记本地键(见 {@link PendingApproval.approvalId})。 */
     approvalId: string;
     toolName: string;
     /** 登记时刻(ms epoch)。 */
@@ -772,24 +851,48 @@ export interface LivePendingRow {
      * (规则集不因 `suspended` 分叉:有活流的 ask 多带一份它自己那张卡的副本无害)。
      *
      * 缺席 = 老 server(7.86.0 及以前);本服务自 7.87.0 起**恒在场**(条目上是必填格)。恒不铸 `null`。
+     *
+     * 🔴 **一只 ask 一个帧族(7.133.0 起)**:呈卡族的 ask(有行 —— 呈卡协议上场的 worker)⇒ 呈卡帧 `approval_request`(卡内事实在 `card` 里,
+     * 卡外的活面事实在帧顶层);旧族的 ask(无行)⇒ 活卡帧 `tool_approval`。按 `frame.type` 判别。
      */
-    frame?: ToolApprovalFrame;
+    frame?: ToolApprovalFrame | ApprovalRequestFrame;
+    /**
+     * S-247:**本副本上没有引擎腿在等这只问** —— 与耐久决断口 200 体同名同值同义的那一位({@link ASK_DECISION_CONSUMER_ABSENT})。
+     * 在场 ⇔ 这一行是审批机起服时从问账接管的问(前一个进程 / 别的副本铸下、行仍 `STREAM_PENDING`;见 {@link ToolApprovalCoordinator.adoptOpenAsks}):
+     * 它照常列得出、照常应答得了(行落 `DECIDED`,应答回执同带这一位),但这一决不会让本副本上任何在跑的东西续跑 —— 续没续跑读 run 面。
+     * 只记真:缺席 = 本副本有引擎腿在等它(或老 server)。
+     */
+    consumerState?: typeof ASK_DECISION_CONSUMER_ABSENT;
 }
-export interface ToolApprovalRunContext {
-    taskId: string;
-    sessionId?: string;
-    owner: string | null;
+/**
+ * 一条执行腿的审批上下文 = 腿的身份三位 + 腿轴 + **恰一个帧族的投递口**。
+ *
+ * 🔴 **一条腿一个帧族**({@link ApprovalLegFamilyPorts}):呈卡协议在本腿上场(装配点按 `resolveApprovalLeg(...).active` 接
+ * `emitCard`)⇒ 本腿上一只 ask 的开卡 / 消卡 / 撤卡只走呈卡族(`approval_request` / `approval_complete` / `approval_revoke`),
+ * 旧族帧一帧不发;协议未上场 ⇒ 只走旧族(`tool_approval` / `tool_approval_complete`,经 `emit`)。两族的口在类型上互斥,
+ * 「同一只 ask 在同一条腿上发两种开卡帧」不可构造。消费方在 wire 上判别本腿是哪一族:`GET /v1/capabilities` 的 `streamApproval`
+ * (与装配点同一只判据 `resolveStreamApprovalGate`,按 worker 求值;为真 ⇒ 本 worker 每条呈卡的腿都是呈卡族)。
+ */
+export type ToolApprovalRunContext = ToolApprovalRunContextBase & ApprovalLegFamilyPorts;
+/** 帧族投递口的二选一(见 {@link ToolApprovalRunContext} 顶注)。 */
+export type ApprovalLegFamilyPorts = LegacyApprovalFamilyPorts | CardApprovalFamilyPorts;
+/** 旧族腿(呈卡协议未上场):开卡 `tool_approval` 与消卡 `tool_approval_complete` 都经 `emit`。 */
+export interface LegacyApprovalFamilyPorts {
     emit: (frame: ToolApprovalFrame) => void | Promise<void>;
+    emitCard?: never;
+    emitRevoke?: never;
+}
+/** 呈卡族腿(呈卡协议上场):开卡 / 消卡经 `emitCard`,批级撤卡经 `emitRevoke`。 */
+export interface CardApprovalFamilyPorts {
+    emit?: never;
     /**
      * [ref] 车6:**批级撤卡帧**(`approval_revoke`,语义与发射面见 approval-card.ts 的
      * `ApprovalRevokeFrame` 顶注 —— [ref] 起 bg/resume durable 腿的钩子写本腿账本,sync 腿仍 live)
      * 的投递口。
      *
-     * 🔴 为什么是**独立的可选钩子**而不是给 `emit` 的入参加宽:`emit` 是既有 `tool_approval` 活卡腿的
-     * 通道,它的消费方(装配点 + 全部存量帧断言面)今天只认那两种帧;把入参改成联合会强迫每一个消费点
-     * 立刻处理一个它还不认识的帧形(存量测试的 `ToolApprovalFrame[]` 收集器首当其冲)。撤卡帧属于**新
-     * 协议**(`approval_request` 族)的一员,消费方是新壳 —— 分口投递是诚实的分层,装配点(车3 3b /
-     * 车4 域)可以与 `approval_request` 的发射点**同批**接上。
+     * 与 {@link CardApprovalFamilyPorts.emitCard} 分口的理由是**失败语义**不同:开卡帧的投递结果参与「卡送到人手上没有」的判定
+     * (零 sink 接下 ⇒ 抛 ⇒ park 路由),撤卡帧是通知、行才是真源(失败由 `emitRevokeTo` 的 catch 如实吞);且 sync 腿的撤卡帧
+     * 刻意维持 live 单口(detach 账本撤帧是另一件行为面变更)。
      *
      * 缺席 ⇒ 本连接不收撤卡帧;壳侧的结构补偿恒是重连 preamble 的全量对账基准。
      * (接线现状:[ref] 起三腿全接 —— sync 腿 live 口(`routes/tasks.ts`),bg/resume 两腿 durable
@@ -797,19 +900,22 @@ export interface ToolApprovalRunContext {
      */
     emitRevoke?: (frame: ApprovalRevokeFrame) => void | Promise<void>;
     /**
-     * [ref] 车3 刀 3b:**呈卡帧**(`approval_request`,[ref] §3.1)的投递口。
+     * 呈卡族的**单卡帧**投递口:开卡帧(`approval_request`,[ref] §3.1)与消卡帧(`approval_complete`)。
      *
-     * 🔴 与 {@link ToolApprovalRunContext.emitRevoke} 同一条理由(见其顶注):新协议族的帧走**独立的可选
-     * 钩子**,不把 `emit` 的入参加宽成联合 —— `emit` 是既有 `tool_approval` 活卡腿的通道,它的全部消费点
-     * (三条装配腿 + 每一个存量 `ToolApprovalFrame[]` 收集器)今天只认那两种帧,加宽会强迫它们立刻处理一个
-     * 还不认识的帧形。设计稿 §4.3(a)「新帧同走 `emitApproval`、不新增出口」讲的是**投递面**(同一条 SSE /
-     * 同一条 durable tail),不是同一个 TS 字段:三条装配腿都把本钩子接到与 `emit` **同一个**写出口上,
-     * 于是 wire 上确实是一条面、两种帧。
+     * 三条装配腿都把它接到本腿的投递面(sync 腿 live SSE + detach 车道账本,bg / resume 腿本腿账本;双 sink 的成败判定在唯一
+     * 属主 `createApprovalCardEmitter`)—— 卡帧在哪,消卡帧就在哪。开卡帧只在 `askId` **确认落盘**时铸(设计稿 §2.2(b) 硬条款一:
+     * 无持久身份不发帧);本腿没有旧族兜底 ⇒ 身份没落盘的 ask 在呈卡腿上**呈不出卡**,按无人可答收场(协调器 `askBroadcast`)。
      *
-     * 缺席 ⇒ 本连接不收呈卡帧(旧壳照常靠 `tool_approval` 工作);`askId` 未确认落盘时**也不发**
-     * (设计稿 §2.2(b) 硬条款一:无持久身份不发新帧)。发射序锚定在 `tool_approval` **之后**(§4.2)。
+     * 第二参 `registration` = 协调器这一次**登记**的本地 id(每次注册各一个,同一只 ask 的重复登记各不相同):同一次登记的开卡帧与消卡帧
+     * 带同一个值,投递口据它把开与合配对(帧上的 askId / approvalId 在重复登记之间相同,配不了对)。它不上 wire。
      */
-    emitCard?: (frame: ApprovalRequestFrame) => void | Promise<void>;
+    emitCard: (frame: ApprovalCardLegFrame, registration: string) => void | Promise<void>;
+}
+/** 两族共有的腿身份与腿轴。 */
+interface ToolApprovalRunContextBase {
+    taskId: string;
+    sessionId?: string;
+    owner: string | null;
     abortSignal?: AbortSignal;
     /** [ref]([ref] §3.1 askId 派生的腿轴;车3 刀 3a 换轴:原 `leg?: number` → `legKey?: string`)。
      *  = `sha256(resume checkpoint token)` 的 hex,**首腿缺席折空串**(空串是首腿的真值,不是「未知」)。
@@ -895,9 +1001,20 @@ export declare const PERSIST_RULE_BATCH_EXCLUSIVE_ERROR = "persistRule.batchOffe
 /** S-720(core 7.32.0 #1093)—— `readRootGrant` 只随 `decision:"allow"`(CC 卡的第三选项「Yes, and add directory」= 放行这一次
  *  + 加目录;`allow_session` 不是那一个选项,`deny` 上它没有意义)。裁决之前响亮拒,不静默丢。 */
 export declare const READ_ROOT_GRANT_ALLOW_ONLY = "readRootGrant is only meaningful with decision \"allow\" \u2014 it is the card's \"Yes, and add directory\" answer (allow this call and add the card's readRootCandidate.dir to this run's read directories)";
+/**
+ * S-765:这台部署不受理读根授权时,带 `readRootGrant` 的应答的拒句。受理与否是**部署姿态**(能力事实 `readRootGrant`,位 `approvalReadRootGrant`;
+ * 判据的唯一属主在 `capability-facts.ts`,回决路由把它读来交给 {@link ToolApprovalCoordinator.respond}):不受理 ⇒ 裁决**之前**响亮 400,
+ * 这只 ask 没被结算,同一张卡不带该键的 `allow` 照常成。不静默丢键 —— 壳以为加上了目录而引擎只看到一次普通放行,是 S-720 修过的那一种病。
+ */
+export declare const READ_ROOT_GRANT_NOT_ACCEPTED = "readRootGrant is not accepted on this deployment \u2014 a read-directory grant is honored only on a single-user host-lane deployment (GET /v1/capabilities approvalReadRootGrant is false here); answer with plain decision \"allow\" instead";
 /** S-720:`readRootGrant` 的形 —— 卡上 `readRootCandidate.dir` 的原串(非空,≤ core `READ_ROOT_CANDIDATE_DIR_MAX`;超限整只拒,不截:截过的目录是另一个目录)。 */
 export declare const READ_ROOT_GRANT_SHAPE = "readRootGrant must be the card's readRootCandidate.dir sent back byte for byte \u2014 a non-empty string of at most 1024 characters";
 export declare const PERSIST_RULE_SCOPE_REFUSED = "this endpoint does not accept a rule scope \u2014 the server mints it from where the approval happened (send neither `scope` nor `persistRule.scope`)";
+/** S-765:`respond()` 要的**部署事实**(由回决路由从能力事实交进;协调器不读 config,也不自判姿态)。 */
+export interface ToolApprovalRespondDeployment {
+    /** 这台部署受理不受理应答体里的 `readRootGrant` —— 能力事实 `readRootGrant` 的 `.available`(位 `approvalReadRootGrant` 的同一个值)。 */
+    readonly readRootGrantAccepted: boolean;
+}
 /** {@link parseToolApprovalResponse} 的成功分支形(`respond()` 拆分出的私有收尾方法复用,避免裸内联匿名类型重复三处)。 */
 type ParsedToolApproval = {
     ok: true;
@@ -993,16 +1110,17 @@ export type SessionGrantStore = Pick<ApprovalExemptionStore, "has" | "grant">;
  * `StoreBackend.approvalAsk()` 的接口契约上(那条注 + `wiring-governance-operator.test.ts` 的三腿机器钉)——
  * 它是**装配面**的事实,而本谓词能看见的只有 `kind`,拿 `kind` 当持久性的代理正是这次要拆掉的那层间接。
  */
-export type StreamApprovalGate = {
+export type StreamApprovalGate<TStore extends GateCurrencyStore = GateCurrencyStore> = {
     active: true;
     askStore: ApprovalAskStore;
+    checkpointStore: TStore;
 } | {
     active: false;
     reason: "no_tool_approval" | "protocol_disabled" | "no_backend" | "no_park_facility";
 };
 /** {@link resolveStreamApprovalGate} 的入参。`backend` 用**结构形**(不 import `StoreBackend`):本模块是
  *  协调器的家,不该为一个布尔判据把整棵 store 依赖树拖进类型面。 */
-export interface StreamApprovalGateInput {
+export interface StreamApprovalGateInput<TStore extends GateCurrencyStore = GateCurrencyStore> {
     toolApprovalEnabled: boolean;
     /** 协议总开关。⚠️ 调用点一律写 `config.streamApproval?.enabled === true` —— **可选链的缺席臂折算
      *  false**(段整段缺席 ⇒ 协议不上场)。
@@ -1016,14 +1134,86 @@ export interface StreamApprovalGateInput {
         readonly kind: "mysql" | "pg" | "local";
         approvalAsk(): ApprovalAskStore;
     } | undefined;
-    /** park 设施在场性。本仓真码里 `checkpointStore` 的构造条件本身就是
-     *  `backend?.checkpoint !== undefined && config.durableApproval`(main.ts),所以设计 §8.4 那条析取式的
+    /** park 设施 = checkpoint 店本身:在场(非 `undefined`)即设施在场,上场时它随 `active` 臂交出去(与 `askStore` 同形)—— 在场性与实例是一个事实,调用点不必另持一份布尔再断言实例非空。
+     *  类型只收店的形({@link GateCurrencyStore}:协调器读它的那两个口),`backend.checkpoint` 这种工厂方法过不了 tsc —— 全进程的店只有 stage-06 铸的那一只,装配点喂的是它,不是再造一只。
+     *  本仓真码里 `checkpointStore` 的构造条件本身就是
+     *  `backend?.checkpoint !== undefined && config.durableApproval`,所以设计 §8.4 那条析取式的
      *  「safety 词表非空」一支在**装配时刻**结构上不可达(core 的 irreversible/egress 集合来自 **per-task**
      *  的 `spec.tools[].irreversibility/egress`,composition root 看不到)——两条缺失形因此在本仓收敛成
      *  同一个 `no_park_facility`(D-5/D-6 两钉打的是两种**输入**形,不是两个 reason)。 */
-    parkFacility: boolean;
+    checkpointStore: TStore | undefined;
+}
+export declare function resolveStreamApprovalGate<TStore extends GateCurrencyStore>(input: StreamApprovalGateInput<TStore>): StreamApprovalGate<TStore>;
+/**
+ * 审批开卡帧的**帧族词表**(闭集)—— wire 上一只 ask 的开卡帧可能属于的族:
+ *  · `tool_approval`:旧族(活卡帧 `tool_approval` / 消卡帧 `tool_approval_complete`);
+ *  · `approval_request`:呈卡族(开卡帧 `approval_request` / 消卡帧 `approval_complete` / 批级撤卡帧 `approval_revoke`)。
+ *
+ * 一条腿选哪个族只由上面 {@link resolveStreamApprovalGate} 的 `active` 定(为真 ⇒ 接呈卡族的口 `emitCard` / `emitRevoke`;为假 ⇒ 只接旧族的口 `emit`,
+ * 见 {@link ToolApprovalRunContext});`GET /v1/capabilities` 的 `approvalFrameFamilies` 把**同一份**判据结果(能力事实 `streamApproval` 的那一次求值)
+ * 译成本词表里的词(`capability-facts.ts` 的 `approvalFrameFamilies`,对判据拒因的穷举 switch:拒因多一个 ⇒ 编译红)。
+ * 腿选口的规则与能力位的映射是同一条,由 `test/stream-approval-on-e2e.test.ts` 在同一台 worker 上拿真腿发出的开卡帧族对拍能力位,不靠注释互相提醒。
+ * 词表只有这一份(元组即类型);加一族而没有逐处跟进 ⇒ `test/capability-facts.test.ts` 的 `satisfies Record<ApprovalFrameFamily, true>` 编译红。
+ */
+export declare const APPROVAL_FRAME_FAMILIES: readonly ["tool_approval", "approval_request"];
+export type ApprovalFrameFamily = (typeof APPROVAL_FRAME_FAMILIES)[number];
+/**
+ * 这台 worker **呈卡用的那一个族**(活卡协调器在场时)—— 全仓唯一的映射,两个读者:能力位 `approvalFrameFamilies`(`capability-facts.ts`,
+ * 壳读它决定声明什么)与 {@link resolveApprovalLeg}(腿判「这条 run 声明了没有」)。两处各写一份三元式 = 壳照一份声明、服务端照另一份判,
+ * 那正是 S-1914 要封的「两边各说各话」。入参 = {@link resolveStreamApprovalGate} 的 `active`。
+ */
+export declare function presentedApprovalFrameFamily(streamApprovalOn: boolean): ApprovalFrameFamily;
+/** 坏声明的拒体(fresh 受理面 400 `request.field_invalid`):一句话 + 机读位,形与 S-1351 座位族 / S-904 三桶的 `bad_entry` 同。 */
+export interface ApprovalFrameFamiliesIssue {
+    readonly message: string;
+    readonly fields: {
+        readonly field: "settings.approvalFrameFamilies";
+        readonly reason: "bad_entry";
+        readonly index?: number;
+    };
+}
+/**
+ * S-1914 —— 请求面声明 `settings.approvalFrameFamilies` 的**唯一判官**:这条 run 的客户端渲染得了哪些审批开卡帧族。
+ * 合法 = 数组,每项是 {@link APPROVAL_FRAME_FAMILIES} 里的词、各出现一次(空数组合法 = 一个族都不渲染,与缺席同读)。非数组 / 词表外 / 重复 ⇒ 拒体点名坐标。
+ * 两个读者:fresh 受理门(`http/admission.ts`,400)与宽容读者 {@link declaredApprovalFrameFamilies}(续跑重放读存体)。入参是 `body.settings`
+ * 本身(非对象 / 缺席 ⇒ 本判官不判,留给 `settings` 自己的形门)。拒句不回显调用方的字节,只报坐标与词表。
+ */
+export declare function approvalFrameFamiliesIssue(settings: unknown): ApprovalFrameFamiliesIssue | null;
+/**
+ * S-1914 —— 一条 run 声明的帧族集合(三条执行腿读的**唯一**读者;读的是这条 run 的请求体 `settings`:sync = 本次请求、bg = 受理过的提交体、
+ * resume / wake = 持久化体 —— 声明随体重放,不另存)。缺席 ⇒ 空集。判官说不合法 ⇒ 空集:只有绕过受理门的存体走得到这一形,
+ * 空集 = 这条腿没有活审批通道(问当场交无人值守政策口)—— 失效方向是不呈卡,不是猜一个族去呈。
+ */
+export declare function declaredApprovalFrameFamilies(settings: unknown): ReadonlySet<ApprovalFrameFamily>;
+/** 一条腿**没有活审批通道**的成因(见 {@link ApprovalLegAssembly.unattended});`frame_family_undeclared` 带上缺的那个族。 */
+export type LegUnattended = {
+    readonly arm: "window_zero";
+} | {
+    readonly arm: "frame_family_undeclared";
+    readonly family: ApprovalFrameFamily;
+};
+/** {@link resolveApprovalLeg} 的入参(sync / bg / resume 三腿 + 开流 preamble 共用一份形)。 */
+export interface ApprovalLegInput {
+    /** = `resolveStreamApprovalGate(...).active`(协议在本 worker 上场没有)。 */
+    streamApprovalOn: boolean;
+    /** `config.streamApproval.windowMs`(`STREAM_ASK_WINDOW_MS`)。
+     *  🔴 [ref]:`undefined` = **这份装配没有 `streamApproval` 段**(只出现在只填被测键的 stub-harness ——
+     *  真实 boot 无条件铸该段,见 `config.ts`)。此前三个调用点各写 `?? 0` 把这一形折成「0」,在旧语义下
+     *  是死代码(`windowZero` 那时挂在 `streamApprovalOn` 后面,协议关就恒 false);[ref] 让 `0` 在协议关的
+     *  腿上也真生效之后,那个折算会把一台**什么都没配**的 harness 判成「运维显式关窗」。故本字段收成
+     *  `number | undefined`,由每个调用点如实交出「有没有这个值」,不许再就地编一个。 */
+    windowMs: number | undefined;
+    /** `config.streamAskWindowMarginMs`(`STREAM_ASK_WINDOW_MARGIN_MS`)。 */
+    windowMarginMs: number;
+    /** `spec.limits.maxWalltimeMs`。缺席 = 没有 walltime 墙 ⇒ 第三源不参与(**缺席 ≠ 0**)。 */
+    legWalltimeMs?: number;
+    /** 本腿**开始执行的时刻**的 `performance.now()`。取值点绝不能挪到腿启动之后:误差方向必须是
+     *  「窗偏短」(安全侧,§7.3 的误差方向论证)。 */
+    nowMonotonicMs: number;
+    /** S-1914:这条 run 声明的帧族(唯一读者 {@link declaredApprovalFrameFamilies},读本 run 的请求体 / 存体)。必填 —— 漏传的装配点编译红,
+     *  不许有「没传 ⇒ 当作声明了」的默认。 */
+    declaredFamilies: ReadonlySet<ApprovalFrameFamily>;
 }
-export declare function resolveStreamApprovalGate(input: StreamApprovalGateInput): StreamApprovalGate;
 /**
  * [ref] 车3 刀 3b —— **一条执行腿的审批装配裁定**(sync / bg / resume **三腿共用**)。
  *
@@ -1042,14 +1232,19 @@ export declare function resolveStreamApprovalGate(input: StreamApprovalGateInput
  * `prepare-task.js` 的 durableMandate/contentMandate 与 durableQuestionFace 等),
  * 故不在本函数内。
  *
- * 🔴 **[ref](半接线旋钮族)**:`windowZero` 的第一源(`STREAM_ASK_WINDOW_MS=0`)自此**不再挂在
+ * 🔴 **[ref](半接线旋钮族)**:关窗的第一源(`STREAM_ASK_WINDOW_MS=0`)自此**不再挂在
  * `streamApprovalOn` 后面** —— 那是部署级旋钮,它的语义不该因为这台机器有没有 durable ask 账而改变
- * (`ApprovalLegAssembly.windowZero` 顶注写了那条病)。第三源(贴 deadline)照旧只在协议上场时参与。
+ * (`ApprovalLegAssembly.unattended` 顶注写了那条病)。第三源(贴 deadline)照旧只在协议上场时参与。
  *
- * **`windowZero` 的两件事必须同时做**(调用方契约):不包 ALS **且**注入 immediate-unavailable 闭包。
- * 只做一件另一条路仍会呈卡。⚠️ [ref] 起**三腿都有** per-task `spec.onAsk` 装配点(sync=routes/tasks.ts,
- * bg=runs.ts,resume=server.ts driveResumeLeg),windowZero 的第二件在三腿都是显式闭包 —— 旧文「bg/
- * resume 无装配点,不包 ALS 即等价」的缺席论证已退役,别再据它推断「少装一件也行」。
+ * 🔴 **S-1914**:「这条腿有没有活审批通道」多一个成因 —— 这条 run 没声明本 worker 呈卡用的族。它与关窗是**同一件事**(不呈卡、问当场交政策口),
+ * 所以进同一个字段(`unattended` 的成因词),三条腿零新分支;判据读 {@link presentedApprovalFrameFamily}(能力位读同一只)。
+ * 判据**不**放进 {@link resolveStreamApprovalGate}:那是 worker 级谓词(协调器注入 / 能力位 / 回决 501 都没有 run),且它为假时腿退回旧族 `emit` ——
+ * 正是「回退发 `tool_approval`」。
+ *
+ * **没有活审批通道的两件事必须同时做**(调用方契约):不包 ALS **且** `spec.onAsk` = {@link ToolApprovalCoordinator.boundUnattendedAsk}(带成因)。
+ * 只做一件另一条路仍会呈卡(ALS 腿是 `deps.onAsk` 的到达路;不包 ALS 也让这条腿不进 broker 活流集合 = 不是别的腿的卡的投递目标)。
+ * ⚠️ [ref] 起**三腿都有** per-task `spec.onAsk` 装配点(sync=routes/tasks.ts,bg=runs.ts,resume=http/resume-legs.ts),第二件在三腿都是显式闭包 ——
+ * 旧文「bg/resume 无装配点,不包 ALS 即等价」的缺席论证已退役,别再据它推断「少装一件也行」。
  */
 export interface ApprovalLegAssembly {
     /** 协议在本腿上是否上场。false ⇒ **既不包 ALS、也不接** `emitCard`/`emitRevoke`/`legKey`/
@@ -1059,57 +1254,54 @@ export interface ApprovalLegAssembly {
      *  同 (owner, session) 活流呈活卡(sync 腿 [ref] 起本就如此;bg/resume 的这条行为差 = [ref] CHANGELOG
      *  披露的行为面变更)。旧文「本腿逐字保持协议之前的行为」只对协议件成立,别再把它读成「协议关 = 零呈卡」。 */
     active: boolean;
-    /** §8.3 窗=0 恒 park。
-     *  🔴 **[ref] 起它与 `active` 解耦**(旧文「`active` 为假时恒 false —— 协议都没上场,谈不上关窗」已
-     *  作废):`STREAM_ASK_WINDOW_MS` 是**部署级**旋钮,`0` 的语义(运维显式关窗 ⇒ 恒走
-     *  {@link ToolApprovalCoordinator.unattendedAskOutcome},连卡都不发)在两条车道上必须是同一个意思。
-     *  旧形下 local 车道(S-384 之前的「账不持久」臂)/ 无 park 设施 / 显式关协议的部署配了 `0`,拿到的是一张
-     *  等满 5min 的活卡 —— 与它自己的域注正好相反,且没有任何一行说出来。
-     *  ⚠️ 「窗**缺席**」(`windowMs: undefined` = 这份装配根本没有 streamApproval 段,只出现在 stub-harness)
-     *  **不是**关窗:那时逐字保持活卡腿。 */
-    windowZero: boolean;
-    /** §7.3 本 leg 的 walltime deadline(`performance.now()` 单调基)。只在 `active ∧ ¬windowZero ∧
+    /** **这条腿没有活审批通道**(在场 ⇒ 不包 ALS、不是任何卡的投递目标、`spec.onAsk` 是 {@link ToolApprovalCoordinator.boundUnattendedAsk}
+     *  席 —— 每只问当场交无人值守政策口,臂 = 本值)。缺席 ⇒ 这条腿按 {@link presentedApprovalFrameFamily} 的族呈卡。成因闭集两个,先后即判序:
+     *  · `window_zero`(§8.3)—— 运维关窗(`STREAM_ASK_WINDOW_MS=0`),或协议上场时本腿剩余 walltime 撑不住安全余量。
+     *    🔴 [ref] 起与 `active` 解耦:`0` 是**部署级**旋钮,在两条车道上是同一个意思(旧形下关协议的部署配了 `0` 拿到的是等满 5min 的活卡)。
+     *    ⚠️ 「窗**缺席**」(`windowMs: undefined` = 这份装配根本没有 streamApproval 段,只出现在 stub-harness)**不是**关窗。
+     *    排在声明之前:那时谁都不呈卡,缺的不是客户端的声明。
+     *  · `frame_family_undeclared`(S-1914)—— 这条 run 的请求没有声明本 worker 呈卡用的族(`settings.approvalFrameFamilies`)。判据对两个族同一条:
+     *    不回退发另一族、不双发、没有「键缺席 ⇒ 视作旧族」的默认。
+     *  三条腿只问「在场没有」,成因随席交给唯一铸点(遥测臂 + deny 政策的拒因句)。 */
+    unattended?: LegUnattended;
+    /** §7.3 本 leg 的 walltime deadline(`performance.now()` 单调基)。只在 `active ∧ 有活审批通道 ∧
      *  有 walltime 墙` 时在场 —— 关着时供值会把既有 5min 活卡窗按三元公式缩短(§7.2 真行为变更)。 */
     legDeadlineMonotonic?: number;
 }
 /**
- * [ref] 车3 刀 3b(codex 交叉复审 round2 R2-1,2026-08-06 真 finding)—— 呈卡帧的**双写投递口**。
+ * [ref] 车3 刀 3b(codex 交叉复审 round2 R2-1,2026-08-06 真 finding)—— 呈卡腿的**双 sink 投递口**(开卡帧 + 消卡帧)。
+ *
+ * 🔴 为什么必须收成一个有属主的工厂:「呈卡帧送达」决定「卡到底有没有送到人手上」(见 `emitOne` 顶注;S-1683 起呈卡腿只有这一族)。
+ * sync 腿原来那个内联闭包把两个 sink 的失败都吞掉、然后**正常返回** —— 于是「账本写失败 ∧ socket 已死」这种**真的一路都没送到**的
+ * 情形被上报成成功,`anySucceeded` 因此压住了 park 路由。诚实的形只有一个:**至少一个 sink 真的接下了才算送达**,一个都没接下就抛 ——
+ * 调用点(`emitOne`)的 catch 会把它如实记成没送到。
  *
- * 🔴 为什么必须收成一个有属主的工厂:round1 之后「新帧送达」开始**参与**「卡到底有没有送到人手上」的
- * 判定(见 `emitOne` 顶注)。而 sync 腿原来那个内联闭包把两个 sink 的失败都吞掉、然后**正常返回** ——
- * 于是「账本写失败 ∧ socket 已死」这种**真的一路都没送到**的情形被上报成成功,`anySucceeded` 因此压住了
- * park 路由,ask 会一直挂到窗到期而**没有任何人可能回答它**。诚实的形只有一个:**至少一个 sink 真的接下
- * 了才算送达**,一个都没接下就抛 —— 调用点(`emitOne`)的 catch 会把它如实记成 `card: false`。
+ * 🔴 **两只 sink 各自推进、各自配对**(S-1683 codex 一轮 F1 / F2,红先钉在 `test/approval-leg-frame-family.test.ts`):
+ *  · 开卡帧同时交两只 sink,**任一只接下即算送达**(不按序串行 —— 旧族退场后 live 面只剩呈卡族这一条路,一只挂住的账本写不能挡住
+ *    健康的 live 出口;修前先 await 账本再写 live)。两只都失败才抛。
+ *  · 消卡帧只交给**接下过本卡开卡帧**的那只 sink,且排在该 sink 自己的开卡写之后(每只 sink 内开在合前;没接下开卡的 sink 不收消卡 =
+ *    不留孤儿消卡行)。没有任何 sink 接下过开卡 ⇒ 不投(调用点本就只对送达过开卡的连接发消卡)。
+ *  · 配对按**登记**记(第二参 `registration` = 协调器那一次登记的本地 id;codex 修复验证轮 V1:按 askId 先进先出会让第二次登记的消卡取走
+ *    第一次失败 / 挂起的开卡记录)。开卡全失败的登记当场清账(它不会有消卡);消卡取走即清;挂住的开卡留账到本腿闭包结束。
  *
- * 顺序 = **先账本后 live**(与 file_link 的先例相反,理由是本帧的用武之地恰好在 live 面已死的时候):
- * detach 断连后 live 写被丢弃,而壳换道 events tail 必须还能看到这张未决卡(§4.3(c) 的案A)。
+ * detach 车道的用武之地仍是「live 面已死、账本还在」(§4.3(c) 的案A):那一形里 live 抛、账本接下 ⇒ 送达;消卡只进账本。
  *
- * 命名(CLAUDE.md 工厂命名律):`create*` —— 返回的是**捕获了两个 sink 的闭包**,不是纯数据。
+ * 命名(CLAUDE.md 工厂命名律):`create*` —— 返回的是**捕获了两个 sink 与配对账的闭包**,不是纯数据。
  */
 export declare function createApprovalCardEmitter(sinks: {
     /** durable 账本口(bg/resume 腿恒有;sync 腿只有 detach 车道有)。抛 = 这一路没接下。 */
-    appendDurable?: (frame: ApprovalRequestFrame) => Promise<void>;
+    appendDurable?: (frame: ApprovalCardLegFrame) => Promise<void>;
     /** live SSE 口。**已死的流应当由调用方判成缺席或让它抛**,不要写一个静默 no-op —— 那正是本 finding。 */
-    writeLive?: (frame: ApprovalRequestFrame) => void | Promise<void>;
-}): (frame: ApprovalRequestFrame) => Promise<void>;
-export declare function resolveApprovalLeg(input: {
-    /** = `resolveStreamApprovalGate(...).active`(协议在本 worker 上场没有)。 */
-    streamApprovalOn: boolean;
-    /** `config.streamApproval.windowMs`(`STREAM_ASK_WINDOW_MS`)。
-     *  🔴 [ref]:`undefined` = **这份装配没有 `streamApproval` 段**(只出现在只填被测键的 stub-harness ——
-     *  真实 boot 无条件铸该段,见 `config.ts`)。此前三个调用点各写 `?? 0` 把这一形折成「0」,在旧语义下
-     *  是死代码(`windowZero` 那时挂在 `streamApprovalOn` 后面,协议关就恒 false);[ref] 让 `0` 在协议关的
-     *  腿上也真生效之后,那个折算会把一台**什么都没配**的 harness 判成「运维显式关窗」。故本字段收成
-     *  `number | undefined`,由每个调用点如实交出「有没有这个值」,不许再就地编一个。 */
-    windowMs: number | undefined;
-    /** `config.streamAskWindowMarginMs`(`STREAM_ASK_WINDOW_MARGIN_MS`)。 */
-    windowMarginMs: number;
-    /** `spec.limits.maxWalltimeMs`。缺席 = 没有 walltime 墙 ⇒ 第三源不参与(**缺席 ≠ 0**)。 */
-    legWalltimeMs?: number;
-    /** 本腿**开始执行的时刻**的 `performance.now()`。取值点绝不能挪到腿启动之后:误差方向必须是
-     *  「窗偏短」(安全侧,§7.3 的误差方向论证)。 */
-    nowMonotonicMs: number;
-}): ApprovalLegAssembly;
+    writeLive?: (frame: ApprovalCardLegFrame) => void | Promise<void>;
+}): (frame: ApprovalCardLegFrame, registration: string) => Promise<void>;
+export declare function resolveApprovalLeg(input: ApprovalLegInput): ApprovalLegAssembly;
+/**
+ * 🔴 **开流 preamble 往本连接投卡与否的唯一判据**(S-1914 / H5)—— 两条 preamble 共用:sync 腿(`routes/tasks.ts`,入参的声明读本次请求的 `settings`)与耐久事件流
+ * (`routes/runs.ts`,声明读这条 run 的持久化体,见 `http/run-declared-families.ts`)。preamble 也是往本连接投卡:只在本腿**有活审批通道**时重放、订消卡 ——
+ * 协议在本 worker 上场、没关窗、这条 run 声明了本 worker 呈卡用的族;与本腿呈不呈卡是同一只装配({@link resolveApprovalLeg}),不在 preamble 一侧另写一份合取式。
+ * 为假 ⇒ 零帧且零 ask 账读(与「协议未上场」同形)。时钟不参与这一判:`nowMonotonicMs` 只喂 `legDeadlineMonotonic`(窗长三元),不进 `unattended` 的三个成因。
+ */
+export declare function approvalPreambleReplays(input: Omit<ApprovalLegInput, "nowMonotonicMs">): boolean;
 /** 一条 **DECIDED 行**能交还给引擎的全部形(`AskOutcome` 减掉 park 路由那一臂 —— 一条有决议的行
  *  从定义上不是「投递面拿走了它」)。{@link ToolApprovalCoordinator.notifyExternalDecision} 收的就是它。 */
 export type DecidedAskOutcome = Exclude<AskOutcome, "unavailable">;
@@ -1179,6 +1371,8 @@ export declare class ToolApprovalCoordinator {
      *  askId 下全部本地条目(自己 + 兄弟 + 重复注册),直接调用它们各自的 `settle`,而不是被动等一个永远
      *  不会来的本地信号。 */
     private readonly pendingByAskId;
+    /** preamble 呈出的卡的消卡订阅(键 = askId;见 {@link watchPresentedCards})。只订本副本上此刻在等的 ask,落定即清 ⇒ 有界于活登记数。 */
+    private readonly presentedCardWatchers;
     /** Per-capability session grants — keys = sessionAllowKey(owner, sessionId, category, grant binding) (修2; bounded). */
     private readonly allowAllSessions;
     /** [ref] HIGH-1(broker)→[ref]四 core 产品裁定「多活集合+广播+首决胜出」:per-(owner, host-session)
@@ -1215,6 +1409,8 @@ export declare class ToolApprovalCoordinator {
      *  `pollSuspendedDecisions` 里那段:按 askId 记的形会在「上一拍最后碰的那条被结算掉」时塌回队首,
      *  构造出永久饥饿的前缀)。只回答「上一拍扫到第几个」,单调推进、按当前长度取模。 */
     private suspendedPollOffset;
+    /** S-247:悬挂轮询腿第二层(接管登记)的轮转游标 —— 与 {@link suspendedPollOffset} 同一条理由,两层各一只。 */
+    private adoptedPollOffset;
     /** [ref] + codex R3-[critical]:askId → **此刻正带着 `updatedInput` 决它的请求数**(见
      *  {@link markEditedDecisionInFlight} 顶注)。只在 `decideAsk` 那一次调用期间非空,故天然有界。 */
     private readonly editedDecisionsInFlight;
@@ -1241,17 +1437,20 @@ export declare class ToolApprovalCoordinator {
      *  core 的 global 缺省(= 现行为,恒不更宽;也绝不错铸一个坐标系不对的 root)。装配见 main.ts:
      *  registry cwd(host lane 显式注册的 launch dir)?? in-process 单用户形的 `process.cwd()`。 */
     private readonly ruleScopeRootFor;
-    /** [ref]:park 路由墓碑表(键 = wire `approvalId`,插入序 = 逐出序)。语义与有界理由见
-     *  {@link ParkTombstone} 顶注。 */
-    private readonly parkTombstones;
-    private readonly parkTombstoneMax;
-    private readonly parkTombstoneTtlMs;
-    /** [ref]:per-principal 子帽(语义与取值理由见 {@link DEFAULT_PARK_TOMBSTONE_PER_PRINCIPAL_MAX})。 */
-    private readonly parkTombstonePerPrincipalMax;
+    /** [ref]:停驻行迟到决议的受理回执表(键 = 行的键 `askId`,插入序 = 逐出序)。语义与有界理由见
+     *  {@link ParkRedemption} 顶注。 */
+    private readonly parkRedemptions;
+    private readonly parkRedemptionMax;
+    private readonly parkRedemptionTtlMs;
+    /** [ref]:per-principal 子帽(语义与取值理由见 {@link DEFAULT_PARK_REDEMPTION_PER_PRINCIPAL_MAX})。 */
+    private readonly parkRedemptionPerPrincipalMax;
     /** [ref]:PARKED 臂的赎回席**取值口**(晚绑 —— 赎回腿要 checkpoint/bg 店与裸 Agent 工具,它们在协调器
      *  构造之后才装配;同款 holder 先例 = main.ts 的 `getRunDenySweep`)。取到 undefined ⇒ 该臂逐字回落
      *  修前 404,partial 部署安全。 */
     private readonly parkedRedeem;
+    /** S-1915:按问读口对 `PARKED` 卡的门读席(见 {@link ParkedGateRead})。缺席(没有 checkpoint 店的部署 / 只装 ask 账的嵌入)⇒ 读口只能说行说的话(`parked`)。
+     *  不是晚绑取值口:checkpoint 店在协调器构造之前就装好了(`boot/stage-06`),与 `parkCommits` 同一只店。 */
+    private readonly parkedGate;
     /** [ref] 裁 (c):local 车道的 File ask **审计** sink(在场 ⇔ `DB_BACKEND=local` ∧ 审批面开着,装配点
      *  `boot/coordinators.ts`)。三个挂线点:铸造(askBroadcast register 后)/ 决议(`settle()` 公共咽喉)/
      *  腿闭(`runWithContext` finally)。**纯观察面**:sink 自己吞写失败并 `recordFailOpen`,任何一次审计
@@ -1293,12 +1492,14 @@ export declare class ToolApprovalCoordinator {
         ruleScopeRootFor?: (sessionId: string | undefined) => string | undefined;
         /** [ref]:PARKED 臂赎回席的**晚绑取值口**(见 {@link ToolApprovalCoordinator.parkedRedeem})。 */
         parkedRedeem?: () => ParkedAskRedeem | undefined;
-        /** [ref]:墓碑表两道界(缺省见 {@link DEFAULT_PARK_TOMBSTONE_MAX}/{@link DEFAULT_PARK_TOMBSTONE_TTL_MS})。
+        /** S-1915:按问读口的门读席(见 {@link ToolApprovalCoordinator.parkedGate})。 */
+        parkedGate?: ParkedGateRead;
+        /** [ref]:受理回执表两道界(缺省见 {@link DEFAULT_PARK_REDEMPTION_MAX}/{@link DEFAULT_PARK_REDEMPTION_TTL_MS})。
          *  不是部署旋钮(不接 env),可注入只为让「有界」这件事被判据观测得到。 */
-        parkTombstoneMax?: number;
-        parkTombstoneTtlMs?: number;
-        /** [ref]:per-principal 子帽(同上不接 env;生效值恒 `min(本值, parkTombstoneMax)`)。 */
-        parkTombstonePerPrincipalMax?: number;
+        parkRedemptionMax?: number;
+        parkRedemptionTtlMs?: number;
+        /** [ref]:per-principal 子帽(同上不接 env;生效值恒 `min(本值, parkRedemptionMax)`)。 */
+        parkRedemptionPerPrincipalMax?: number;
         /** [ref] (c):local 车道审计 sink(见 {@link ToolApprovalCoordinator.askAudit})。 */
         askAudit?: ApprovalAskAuditSink;
         /** S-877 候裁 16:耐久会话授权店(见 {@link ToolApprovalCoordinator.sessionGrants})。 */
@@ -1320,7 +1521,7 @@ export declare class ToolApprovalCoordinator {
      * 五臂(设计稿 §1 的表)全部读它,`unattendedPolicy` 因此是一处施加、五处消费:
      *  (a) 有店窗到期 `expireAsk` 赢 CAS / (b) 无店窗到期(D1)/ (c) 有店但 `expireAsk` 报错
      *  —— 三条走 `windowRouteUnavailable` 标志,在 {@link shapeOutcome}(askBroadcast 内)成形;
-     *  (d) `windowZero`(装配层短路)与无 ALS 上下文的 headless 腿 —— 走本方法/{@link ask};
+     *  (d) 没有活审批通道的腿(装配层短路:关窗 / 未声明呈卡族,S-1914)与无 ALS 上下文的 headless 腿 —— 走本方法/{@link ask};
      *  (e) 断连 `forceParkNow` / emit 全灭 / 写侧准入超限 —— 走本方法。
      *
      * **持久回放的两个口也归它管**(codex R1-F1 验真后收口,红先钉在
@@ -1353,7 +1554,7 @@ export declare class ToolApprovalCoordinator {
     private unattendedOutcome;
     /** 政策**读**口(不是终局铸口)—— 回答「这台部署把无人可答翻成 park 吗」。
      *
-     *  🔴 与 {@link unattendedOutcome} 分家是 S-187 的一半:此前两件事共用一只方法,于是墓碑腿那次
+     *  🔴 与 {@link unattendedOutcome} 分家是 S-187 的一半:此前两件事共用一只方法,于是 park 路由判别那次
      *  纯粹的**政策查询**(`unattendedOutcome() !== false`)会和同一只 ask 的真终局各记一条遥测 ——
      *  「一只 ask 一条线」当场不成立。读口不落日志,铸口落;谁也不兼职。 */
     private get unattendedRoutesToPark();
@@ -1365,10 +1566,9 @@ export declare class ToolApprovalCoordinator {
      * 读的是政策**读**口(不落遥测)。
      */
     private batchIdFor;
-    /** {@link unattendedOutcome} 的**公开**口:`windowZero` 的 immediate-unavailable 闭包长在装配层
-     *  (`http/routes/tasks.ts` 的 sync 腿),它必须与协调器内五臂读**同一个**旋钮值,而不是各算一遍。
-     *  出处随调用方给(那条腿知道自己是哪一只 ask)。 */
-    unattendedAskOutcome(site: {
+    /** {@link unattendedOutcome} 的**公开**口:没有活审批通道的腿({@link ApprovalLegAssembly.unattended})的席长在装配层,它必须与协调器内
+     *  五臂读**同一个**政策值,而不是各算一遍。成因(`why`)与出处随调用方给(那条腿知道自己为什么不呈卡、是哪一只 ask)。 */
+    unattendedAskOutcome(site: LegUnattended & {
         taskId?: string;
         owner?: string | null;
         toolName?: string;
@@ -1440,7 +1640,7 @@ export declare class ToolApprovalCoordinator {
      *
      * 两个座两种处置,**刻意不同**:
      *  · `segment` = **纯渲染座**(core 明写「never adjudication input」)⇒ 截长是诚实省略,与
-     *    `toolName`/`message` 的 `clip` 同待遇,也与耐久腿 `boundedRuleOffers` 的同名处置同形。
+     *    `toolName`/`message` 的 `capText` 同待遇,也与耐久腿 `boundedRuleOffers` 的同名处置同形。
      *  · `rule`/`command` = **兑付等式的左边**(回决 `persistRule.rule` 按文本在引擎重铸的 offer 表里定位)
      *    ⇒ 截一个字就恒 `rule_not_offered`,所以**绝不截**;真超尺(= core 放宽了自己的 512 或本仓与 core
      *    版本不同步)⇒ **整条车道撤回**(返回 `undefined`),与本文件既有的治理撤回 / 漂移撤回逐字同形:
@@ -1561,8 +1761,8 @@ export declare class ToolApprovalCoordinator {
      * 读失败 ⇒ 不命中 = fail-closed,人多看一张卡而不是被静默代答)∧ ④ 行上没有与本地 peek 矛盾的出处({@link sessionGrantUncontestedByRow})。
      *
      * **两个读位、一只店、按问句的作者分**(收车档 ⑩ 16):本席兑现**引擎自装的问**(模式写门 / 形状层 —— core 7.34.0 起它们是引擎
-     * 自己的层、不读任何豁免,折叠 ask 赢 ⇒ 策略层探针对它们恒无效,codex F2);**本仓自己的问**(durable 名单门、workflow 问句门、
-     * acceptEdits 的 cwd 域写门)照旧在各自的层上读同一只店「不问」。为什么两处都要:子代经父约束链继承到的问到达祖先审批席时 core
+     * 自己的层、不读任何豁免,折叠 ask 赢 ⇒ 策略层探针对它们恒无效,codex F2;7.133.0 起 acceptEdits 的写也只有引擎模式门这一问);
+     * **本仓自己的问**(durable 名单门、workflow 问句门)照旧在各自的层上读同一只店「不问」。为什么两处都要:子代经父约束链继承到的问到达祖先审批席时 core
      * 盖 `mandated`(`ruleClearanceOf` 的 inheritedUnresolved / ancestorResolved 门),本席依约不退役 —— 只有策略层的「不问」够得着继承链
      * (主会话裁定原想退役那三只探针,施工中被 test/parked-decide-leg.test.ts「[候裁② 修]remember 全链行为」证伪,收车档 ⑩ 16-⑤)。
      * 本席的两个入口(`askBroadcast` 开头、窗 0 / 无活流身份席 {@link boundUnattendedAsk})都只调这一只。
@@ -1577,8 +1777,9 @@ export declare class ToolApprovalCoordinator {
      *  问已经发出去了)。 */
     private durableGrantHas;
     /**
-     * 🔴 **S-877 候裁 16 —— 窗 0 席**:本席**不呈卡**,但在报「无人可答」之前先问站着的答案。装配点 = 三条腿的 `windowZero` 席
-     * (sync `http/routes/tasks.ts`、bg `runs.ts`、resume `http/resume-legs.ts`)。修前三处是装配层的就地闭包 `() => unattendedAskOutcome(...)`
+     * 🔴 **S-877 候裁 16 —— 无通道席**(旧名「窗 0 席」):本席**不呈卡**,但在报「无人可答」之前先问站着的答案。装配点 = 三条腿上没有活审批通道
+     * 的那一支({@link ApprovalLegAssembly.unattended} 在场;sync `http/routes/tasks.ts`、bg `runs.ts`、resume `http/resume-legs.ts`),成因 `why`
+     * 随席交给唯一铸点(遥测臂 + deny 政策的拒因句;S-1914 起两个成因:关窗 / 这条 run 没声明呈卡族)。修前三处是装配层的就地闭包 `() => unattendedAskOutcome(...)`
      * —— 不读授权,引擎那一问(模式写门 / 形状层)在窗 0 部署上 remember 恒无效。改形后:授权命中 ⇒ `true`;否则逐字走
      * {@link unattendedAskOutcome} 这**一个**政策口(五臂一处施加,[ref] R-13 C 不变)。
      * parked 赎回腿的继承条目席**不**改:那条腿上到席的问全是继承问(core 盖 `mandated`),本席依约不退役,改了也兑现不了任何东西 ——
@@ -1589,7 +1790,7 @@ export declare class ToolApprovalCoordinator {
         owner: string | null;
         taskId: string;
         sessionId?: string;
-    }) => ((req: AskRequest) => Promise<AskOutcome>);
+    }, why: LegUnattended) => ((req: AskRequest) => Promise<AskOutcome>);
     /**
      * 🔴 session grant 短路前的**持久出处复核**([ref] 的 codex R1-[high] 补丁;[ref] 换判据;S-944 / SN-C1 换读口)。
      *
@@ -1684,24 +1885,34 @@ export declare class ToolApprovalCoordinator {
      * 单赢者卫兵,对已落的恒无操作。absent / 编辑在飞没有可分发的真相。
      */
     private dispatchClaimTruth;
-    /** [ref]:落一条 park 墓碑(容量帽按**插入序**逐出最旧,与 `allowAllSessions` 同款有界纪律)。
-     *  调用点唯一 = `settle` 里的 park 路由支(见那处注);真终局绝不调它。
-     *
-     *  🔴 **同键第二次调用 = 整个无操作**([ref] 二轮重扫,双 opus confirmed 的修法后半;红先钉
-     *  `test/parked-late-decision.test.ts` 的 [ref]-④)。键换成 wire `approvalId` 之后,「同一把
-     *  approvalId 落两次墓碑」从不可能变成**常态**(同 askId 的重复本地注册各自按 park 路由收尾)。
-     *  两件事因此必须同时成立:
-     *   · **不占第二格、不动插入序** —— 帽与逐出序是按「对外可见的 ask」记的;兄弟刷新插入序会把一条
-     *     早该轮到逐出的墓碑一次次续命,同样是记账失真。
-     *   · **不覆写既有条目** —— `redeemed`/`inflight` 是本副本**已经对客户端做出的受理承诺**(见
-     *     {@link ParkTombstone});覆写等于把一次已受理的决议重新打开,200 丢包后的重试会去动一张
-     *     **已被消费**的 checkpoint(409/404),与本口承诺的「幂等回放首决」相反。
-     *  代价如实登记:`parkedAtMs` 保留**首次** park 的时刻 ⇒ TTL 从首次起算(晚到的兄弟不给续期)。
-     *  方向安全(墓碑早退 = 回落修前的 404,不会错兑),且与「一只 ask 一格」的记账口径自洽。 */
-    private recordParkTombstone;
-    /** [ref]:取墓碑(**惰性清扫**:过期条目读到即删,不另起定时器 —— 这张表只在迟到回决那一刻被读)。
-     *  属主门在调用方(与 live 腿同一句判据:`owner === null` 或逐字相等,否则按不存在处置)。 */
-    private lookupParkTombstone;
+    /**
+     * [ref]:为一次**赎回**开一格(单飞句柄的座位)。调用点唯一 = {@link redeemParkedAsk} 开飞之前。在飞的格不受容量帽约束 ——
+     * 它们有界于此刻在飞的赎回请求数,且开飞即受理承诺之前的那一段(逐它会撕正在进行的兑付);容量帽只管落定之后留下的**回执**
+     * ({@link retainParkRedemption})。
+     */
+    /**
+     * 受理回执表的**准入**半场:在飞的格(赎回腿还没回来)永不被逐 —— 单飞靠它 —— 所以表的两道界对它们只能在开格之前判。
+     * 本 principal 在飞的格已到生效子帽,或全表在飞的格已到全局帽 ⇒ 拒新(`429 limit.rate_exceeded` + `retryAfterSec`,路由据体铸 `Retry-After` 头),
+     * 不开格、不进赎回腿;已在飞的那几只照常落定,之后同一只卡的受理照常。回 `undefined` = 放行。
+     * 两道界与回执半场({@link retainParkRedemption})同一组数:表里每一格都有界 —— 回执靠逐出,在飞的格靠准入。
+     */
+    private parkRedemptionAdmission;
+    private openParkRedemption;
+    /**
+     * [ref] / [ref]:一次赎回**受理成功**之后,它的回执留不留(容量帽按**插入序**逐出最旧,与 `allowAllSessions` 同款有界纪律)。回 `false` = 容量拒新:
+     * 这一格当场收回(那一次受理照旧生效,只是没有本副本的回执可依 —— 200 丢包后的重试再进赎回腿,终局由它的 CAS 定)。
+     *
+     * 两道界**只数回执**(已受理、不在飞的格;在飞的格永不被逐),且**只看本 principal 的那一段**(理由与两条臂的方向差见
+     * {@link DEFAULT_PARK_REDEMPTION_PER_PRINCIPAL_MAX}),生效子帽对全局帽取小。记账用开格那一刻行上的 owner —— 要的是「压力来自谁」这个近似,
+     * 不是「谁有权决这只 ask」(权威属主门恒按行上当下的 `owner` 复判)。
+     *  · 本 principal 的回执数已到子帽 ⇒ 逐本 principal 最旧的那张(过期的优先)—— 量产者自伤;
+     *  · 全表回执已到全局帽 ⇒ 先收全表第一张过期回执(清扫是惰性的,若干租户各自远低于子帽却把全局填满时,TTL 过后没人再来查那些旧 id,
+     *    不回收就永远满 —— 回收过期条目不是「挤他人」,是收垃圾);一张过期的都没有 ⇒ 拒新,一格都不挤别人([ref] Q3)。
+     */
+    private retainParkRedemption;
+    /** [ref]:取受理回执(**惰性清扫**:过期回执读到即删,不另起定时器 —— 这张表只在迟到回决那一刻被读)。**在飞的格不随 TTL 过期**:重叠的请求
+     *  (哪怕晚于 TTL 才到)照样等它、回放它的结果,绝不另起第二次赎回。 */
+    private lookupParkRedemption;
     /**
      * [ref] 车4 §12-E(F29/F30 裁定形):外部回决(车4 端点或本类 respond 腿)**赢下持久 CAS 之后**,把同
      * askId 下全部本地悬挂条目按**真实决议**结算——端点已是唯一权威(CAS 已落),本地只是同步终局;查无
@@ -1804,13 +2015,25 @@ export declare class ToolApprovalCoordinator {
     /** [ref]:发起本次回决的真实 HTTP 请求。**只**沿 PARKED 臂透传给赎回席(那条腿要它做准入解析与
      *  舰队 scope,与 `/decide` 腿同姿势);live 命中路径一个字节都不看它。缺席 = 非 HTTP 调用点
      *  (测试/内部),赎回席按「无请求」形处置。 */
-    httpReq?: IncomingMessage): {
+    httpReq?: IncomingMessage, 
+    /** S-765:本次回决的**部署事实**(协调器自己不读 config;回决路由从能力事实读来交进)。缺席 ⇒ 按「不受理读根授权」读(失败方向 = 拒)。 */
+    deployment?: ToolApprovalRespondDeployment): {
         status: number;
         body: unknown;
     } | Promise<{
         status: number;
         body: unknown;
     }>;
+    /**
+     * S-247:**接管登记**的应答。接管登记是行的投影(没有引擎腿在等它),所以它的属主门读**行当下的** owner —— 接管时记下的那一格可能已被
+     * `/v1/adoption` 改写(契约:应答口的授权判据取当下的持久事实,收编之后旧属主手里的卡作废)。行仍 `STREAM_PENDING` ⇒ 与活登记同一条应答路
+     * ({@link answerRegistration}:同一把 `decideAsk` CAS);行已有终局(别处答了 / 对账器收了,本副本的轮询还没到)⇒ 按行的真相答(与晚答口同一张表)。
+     */
+    private respondAdopted;
+    /** 一条已过属主门的登记(活登记或接管登记)的应答 —— 两者同一条路:规则文本前门 → 要人门 → CAS → 兑付。 */
+    private answerRegistration;
+    /** 一次 live 回决**落定之后**的两件兑付(部署名单那一问的豁免、「不再询问」的规则)—— 两件都只在 200 那一支、都读同一只资格。 */
+    private afterLiveDecision;
     /**
      * **部署名单(`APPROVAL_REQUIRE`)那一问的「本会话放行」只落 server 的会话豁免店**(谁问的,谁的站着的答案算数):名单的问是 server 铸的,
      * 名单门在出问之前读这只店(键 = 会话 × wire 工具名,与耐久 `/decide` 的 `remember:"session"` 写下的同形),命中就不出问 —— 引擎看到的
@@ -1842,17 +2065,73 @@ export declare class ToolApprovalCoordinator {
     /** [ref]:`tool_approval.not_pending` 的**唯一**成形口。文案逐字不变(存量壳/SDK 按它认这条 404),
      *  只 additive 加判别位;`cause` 缺席 = 这台部署没有行可判(D1 无店)或行形不可信(见各调用点)。 */
     private notPending;
+    /**
+     * `GET /v1/tool-approvals/:approvalId` —— **按问读口**:一只 ask 此刻在哪一态({@link TOOL_APPROVAL_READ_STATES})。与 {@link respond} 同根同门
+     * (HTTP 层的鉴权 / 属主身份同一只 `gatedPrincipal`;属主不过与未知同形 404,无存在性谕示),读法与应答口逐条同源:
+     * 本副本上在等它的活登记({@link liveEntryFor})⇒ `pending`(行投影 = 列表面 `livePending[]` 的同一只投影);否则按 id 读行
+     * ({@link askRowFor} + {@link askRowVisibleTo}),行态 → 读态与晚答口的分派同一张表;行仍 `STREAM_PENDING` 而本副本没有在等它的登记 ⇒ 它活在别的副本上,
+     * 与晚答口同答 404 `unknown_or_other_replica`(那里才有兑现它的闭包)。没有 ask 账的部署 ⇒ 晚答口那句 404,不带 `cause`。
+     * 纯读:零写、零结算、不碰本地登记(晚答口的 DECIDED 臂会顺手同步本副本的活登记,读口不做)。
+     */
+    readApproval(id: string, principal: string | undefined): {
+        status: number;
+        body: unknown;
+    } | Promise<{
+        status: number;
+        body: unknown;
+    }>;
+    /** S-247:接管登记的按问读口 —— 行可见且仍 `STREAM_PENDING` ⇒ `pending`(列表面同一只行投影);否则按行的态答(与读行半场同一张表)。 */
+    private readAdopted;
+    /** {@link readApproval} 的读行半场。 */
+    private readAskRowState;
+    /**
+     * `PARKED` 行的门读法(S-1915):问判官「这张卡的门此刻还是不是该会话当前待决的审批门」。行是终态、不随赎回 / 取消改写,所以只有 checkpoint 知道。
+     * 没有门读席 / 行上没有 gate token ⇒ `open`(读口只能说行说的话;应答口对同一张卡的 PARKED 臂此时也答不了受理,不另有第二个答案)。
+     * 读不出(店故障 / 超时)⇒ 按本协调器的店故障姿势(D5:记账 + 一次 warn)退回 `open` —— 这一臂只影响**展示**,应答口对同一张卡仍按自己的判官 fail-closed。
+     */
+    private readParkedGate;
+    /** 一条行 → 按问读口的答案(行态六态穷举:新增 `AskState` 而不在此表态 = **编译错**)。 */
+    private readStateOfRow;
     /**
      * [ref] —— live 未命中之后的**状态感知分派**(设计 §三的那张表)。
      *
-     * 门两道,都在读行之前:①持久店在场(协议上场才有行可读;缺席 ⇒ D1 体逐字不变);②本副本留过
-     * park 墓碑且属主门过(墓碑是 wire id ↔ 店内 askId 的唯一桥,见 {@link ParkTombstone})。任一不过 ⇒
-     * 与修前逐字同形的 404(店在场时带 `unknown_or_other_replica` 判别位 —— 那正是「换副本/换端点重试才
-     * 有意义」的那一因)。
+     * 有行的 ask 的 wire 身份就是行的键 ⇒ 按 id **直接读行**(任一副本、重启前后都读得到;不再经任何进程内的桥)。持久店缺席 ⇒ D1 体逐字不变
+     * (没有行可判,编一个 cause 是撒谎);店在场而行不在 / 不是调用方的 ⇒ 404 `unknown_or_other_replica`(那正是「换副本/换端点重试才
+     * 有意义」的那一因;属主不过与未知同形,无存在性谕示)。
      */
     private respondLate;
-    /** {@link respondLate} 的读行 + 六态穷举分派(闭集:新增 `AskState` 而不在此表态 = **编译错**)。 */
+    /**
+     * 新开的 sync 连接经 **preamble** 呈出的卡 → 登记进这条连接的**消卡订阅**(连接的 `approval_complete` 只投给接下过开卡帧的连接 —— 这些卡的开卡帧
+     * 就是 preamble 那一帧)。这几只 ask 在本副本上的最后一条活登记落定时,`deliver` 收一帧 `approval_complete`(与那次 settle 的判决同值)。
+     *  · 只订本副本上**此刻在等**的 ask(`pendingByAskId` 有登记):活在别的副本上的 / 订阅之前已经落定的,本副本无从得知它何时落定 ——
+     *    那几形的结构补偿仍是下一次 preamble 的全量对账基准(不在基准内的卡一律清)。
+     *  · 投递是 live-only 的通知:`deliver` 抛错 / 连接已死 ⇒ 吞掉(卡的终局是行上的事实,不因通知没送到而改变)。
+     * 返回退订口(连接收场时调;投递一次之后自动退订)。
+     */
+    watchPresentedCards(askIds: readonly string[], deliver: (frame: ApprovalCompleteFrame) => void): () => void;
+    private dropPresentedCardWatcher;
+    /** settle 咽喉调:一只 ask 在本副本上的最后一条活登记落定 ⇒ 给订了它的每条连接投一帧消卡,随即退订。 */
+    private notifyPresentedCardWatchers;
+    /**
+     * 一个 wire 身份 → 本副本上**此刻在等它**的那一条活登记(应答口与读口共用这一只读法)。
+     *  · 有行的 ask:wire 身份 = 行的键 ⇒ 同一只 ask 的活登记(重复登记各一条)里**最早**的那一条(插入序;CAS 单赢,赢后其余登记经
+     *    同 askId 的广播口按同一份行真相结清);
+     *  · 无行的 ask:wire 身份 = 登记本地键 ⇒ 直接取那一条。登记本地键对有行的 ask 不是 wire 身份(它从不上 wire),拿它来问 ⇒ 查无。
+     */
+    private liveEntryFor;
+    /** {@link respondLate} 的读行:按 id 读出行,交 {@link dispatchRowTruth}。 */
     private dispatchLateByRow;
+    /**
+     * 按 wire 身份(= 行的键)读行。读不出 ⇒ 记账并按「查无」交回:读不出 = **不知道**这只 ask 落在哪一态,而晚答口的三条受理臂(200/200/202)
+     * 都在对客户端做承诺 —— 不知道 ⇒ 回那句 404,绝不把未知说成受理(D5 的 fail-open 只覆盖「不挡人的真实回决」那一面,这条腿方向相反)。
+     */
+    private askRowFor;
+    /**
+     * 一条行(的此刻真相)→ 应答口的答案:属主门 + 受理回执 + 六态穷举分派(闭集:新增 `AskState` 而不在此表态 = **编译错**)。两个入口:本副本没有在等
+     * 这只 ask 的登记({@link dispatchLateByRow} 读出行),以及有登记但回决的 CAS 干净地输(行已有终局,`decideAsk` 带回的那条行)—— 一只 ask 的
+     * 应答只看行的真相,与本副本有没有残留登记无关。
+     */
+    private dispatchRowTruth;
     /** [ref]:迟到腿上的 `persistRule` 兑付面 —— 本地条目(规则车道素材的载体)早已随 park 路由散场,
      *  没有任何可对的候选表 ⇒ 如实拒(裁决本身照常受理,与 {@link persistRuleAfterDecision} 的
      *  「失败不翻转裁决」同判)。用既有词 `rule_lane_unavailable`,不为这一支新造词。 */
@@ -1889,7 +2168,7 @@ export declare class ToolApprovalCoordinator {
      *
      * ## 素材从哪来(这是本方法存在的全部理由)
      * live 腿的等式左边是**进程内条目** `PendingApproval.ruleLane`,而 park 路由把条目连同素材一起散场
-     * 了([ref] 的墓碑只桥身份,不携素材)。本腿因此从**行**取,一件一件对着 live 腿的入参:
+     * 了(行之外不留任何进程内素材)。本腿因此从**行**取,一件一件对着 live 腿的入参:
      *  · `command` = `rule_command` 列(**[ref] 新列**;缺席即本方法唯一的新拒因,见下);
      *  · `scope` = `rule_scope_root` 列 ⇒ `{kind:"project", root}`,缺席则**不铸 scope**(core 落 global,
      *    = live 腿 `material.scopeRoot` 缺席时逐字同形 —— 绝不在坐标系不明时编一个 root);
@@ -1940,10 +2219,44 @@ export declare class ToolApprovalCoordinator {
      *  语义。
      *  🔴 **S-454 起行上带整只活卡帧**(`frame`,见 {@link LivePendingRow.frame}):旧文那句「input/args
      *  不上列表,详情走流帧」对**悬挂 ask 结构上不成立**(它永远没有流帧),而 `frame` 是 `askBroadcast`
-     *  那一处构造的同一个对象 ⇒ 仍然只有**一个**脱敏属主、零第二投影。`scope` 与 durable 面同一表达式:`undefined` = operator 全量(含 owner null 的
-     *  条目),串 = 只见 `owner === scope` 的条目(null-owner 行对 principal 不可见,fail-closed——
-     *  宁少列不超范围;`"__none__"` 未鉴权哨兵自然恒空)。行的 `approvalId` 就是 `respond()` 收的 id
+     *  那一处构造的同一个对象 ⇒ 仍然只有**一个**脱敏属主、零第二投影。`scope` 与 durable 面同一个值(checkpoint scope):`undefined` = operator 全量(含 owner null 的
+     *  条目),`_`(`CHECKPOINT_PUBLIC_SCOPE`)= 匿名那一组 = owner null 的条目(R7:不带主体的调用方列得出它答得了的那几张),
+     *  其余串 = 只见 `owner === scope` 的条目(null-owner 行对具名主体不列,宁少列不超范围)。行的 `approvalId` 就是 `respond()` 收的 id
      *  (同源可达,[ref] 判据);`expiresAtMs` 照抄登记时单点铸定的窗死线([ref] 三键同一个数)。 */
+    /**
+     * 🔴 S-247 —— **起服接管**:把问账里仍 `STREAM_PENDING` 的问接进本审批机的活集合,让 `livePending[]`(及 `/v1/approvals/stream` 的 live 半场、
+     * 按问读口、应答口)在重启之后不重开流也看得见、答得了它们。审批机仍是这些读面**唯一**的读源:读问账的只有这里(起服一次),之后列表行由
+     * 同一只 {@link livePendingRowOf} 投影,卡帧 = `buildReplayFrame`(开流 preamble 同一只构造)—— 不是 GET 上加一只读表的第二 reader。
+     *
+     * 律(设计稿 `design-S-247.md` §2):接管登记**没有引擎腿在等它**(铸它的进程没了,或它活在别的副本上),与活登记同一只状态机 ——
+     * 应答 = 同一把 `decideAsk` CAS({@link answerRegistration}),收敛 = 同一条悬挂轮询腿读行({@link pollSuspendedDecisions});它活多久只由行说了算,
+     * 没有自己的窗(无等待腿的行的到期写者已经存在:对账器段二,同一只政策感知终态 claim,窗 + 宽限 —— 接管不新增竞争者)。
+     * 「本副本没有引擎腿在等它」机读披露:列表行与应答回执带 `consumerState:"absent"`({@link ASK_DECISION_CONSUMER_ABSENT})。
+     *
+     * 装配点 = `boot/stage-07` 起服收敛之后、reaper / HTTP 之前(local 车道上收敛先把前世问收成 `VOID` ⇒ 这里读到零行,车道无分叉)。
+     * 幂等:本副本已有这只 askId 的登记就跳过;每次起服由行重新推导。读失败 ⇒ **拒启**(抛;与起服收敛同一拍、同姿态 —— 照常起来等于让
+     * 仍待决的问在列表面上消失,而审批中心只读列表)。
+     * ⚠️ 射程:接管的是**起服那一刻**问账里的待决行;之后别的副本新铸的问不接管(`livePending` 是本副本投影、多副本要会话粘性 —— 契约原句不变)。
+     */
+    adoptOpenAsks(): Promise<OpenAskAdoption>;
+    /**
+     * S-247:由一条待决行铸一条接管登记并放进活集合(唯一铸点;读法见 {@link AdoptedRegistrationPart})。事实全部取自行与行上的卡:属主 / 会话(adhoc 替身
+     * = taskId 时不投,与按问读口的行投影同读)/ 子代出身(卡 `fromSubagent` ⇒ 行 `sourceTaskId`)/ 窗死线 / 铸造时刻取行;工具名、要人位、治理位、类集取卡;
+     * 授予绑定卡上没有 ⇒ `unreadable`(于是站着的答案判据答 `none`:`rememberRefused`,`allow_session` 只放行这一次 —— 既有律);规则素材不在 ⇒ `persistRule`
+     * 答 `rule_lane_unavailable`(晚答腿同一个词)。卡面的 `rememberRefused` 与条目同一只判据(活登记那一处的同一条纪律)。
+     */
+    private registerAdopted;
+    /** S-247:放掉这只 askId 的全部接管登记(不碰行、不发消卡帧)。两个读者:悬挂轮询读到行没了(接管登记没有窗,没有行就没有活着的依据);本副本来了这只问的活登记(它让位)。活登记不动。 */
+    private releaseAdoptedRegistrations;
+    /**
+     * S-247:问账里**这只问的行没了**(行被删)⇒ 放掉它的接管登记;放完本副本若已没有这只问的任何登记,经 preamble 订了它的消卡订阅也一并撤掉
+     * (不发帧 —— 问不是被谁答掉的,编一帧消卡就是撒谎;壳的结构补偿仍是下一次 preamble 的全量对账基准)。还有活登记 ⇒ 订阅留给它的结算。
+     */
+    private forgetAdoptedAsk;
+    /** S-247:接管登记的属主跟行走 —— 悬挂轮询每读到一次仍待决的行就对齐一次(`/v1/adoption` 改写 `approval_ask.owner` 之后,列表面在一拍之内跟上;应答口与读口另读行当下的 owner)。 */
+    private followAdoptedOwner;
+    /** 这只 askId 在本副本上有几条**有引擎腿在等**的登记(接管登记不算)—— 轮询腿的「被唤醒数」读它。 */
+    private waitingRegistrationCount;
     listLivePending(scope: string | undefined): LivePendingRow[];
     /**
      * S-751:某只委派子代此刻有没有**待决**的活卡 —— fleet 对账腿「子代活性由属主说了算」的属主②读口(另一只是
@@ -2031,8 +2344,10 @@ export declare class ToolApprovalCoordinator {
     /** [ref]:当前挂着的**悬挂**条目数(零投递集合铸的那一类)——运维/判据读它证「悬挂队列有多长」。 */
     suspendedCount(): number;
     sessionAllowedCount(): number;
-    /** [ref]:当前在场的 park 墓碑数(有界性的可观测面 —— 判据据它证「帽是硬的、过期会被清」)。 */
-    parkTombstoneCount(): number;
+    /** S-247:当前在场的 preamble 消卡订阅(按 askId)数 —— 判据据它证「订阅有界于本副本的登记,没有登记、没有行的问不留订阅」。 */
+    presentedCardWatcherCount(): number;
+    /** [ref]:当前在场的受理回执数(有界性的可观测面 —— 判据据它证「帽是硬的、过期会被清」)。 */
+    parkRedemptionCount(): number;
 }
 export {};
 //# sourceMappingURL=tool-approval.d.ts.map