@sema-agent/server 7.132.0 → 7.133.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,7 @@ 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 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 +83,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 +105,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`  —— 行 `PARKING` / `PARKED`(转后台候批;应答口走迟到受理,耐久回决口照收);
+ *  · `void`    —— 行 `DENIED` / `VOID`(没有人决过它,答案无处兑现;`cause` 同晚答 404)。
+ */
+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 +184,9 @@ export type SettleVerdict = {
  *
  * 语义边界(禁扩读):它答的是「本副本此刻有没有活体消费者」,**不是**「这条 run 还活着吗」——持有
  * 悬挂 promise 的可能是另一个副本(F4 的轮询腿会在它自己的下一拍续跑)。run 的生死读 run 面。
+ *
+ * S-247 起**同一个词、同一句语义**也出现在 live 面:审批机起服时从问账接管的登记(没有引擎腿在等)在 `livePending` 行上带它,
+ * 在 live 应答口的 200 回执上按同一判据(本副本被唤醒的等待腿数 = 0)带它。一个事实,各面一个读法。
  */
 export declare const ASK_DECISION_CONSUMER_ABSENT = "absent";
 /**
@@ -315,7 +362,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;
@@ -684,10 +733,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 +767,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 +819,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 | ApprovalRequestFrame;
+    /**
+     * S-247:**本副本上没有引擎腿在等这只问** —— 与耐久决断口 200 体同名同值同义的那一位({@link ASK_DECISION_CONSUMER_ABSENT})。
+     * 在场 ⇔ 这一行是审批机起服时从问账接管的问(前一个进程 / 别的副本铸下、行仍 `STREAM_PENDING`;见 {@link ToolApprovalCoordinator.adoptOpenAsks}):
+     * 它照常列得出、照常应答得了(行落 `DECIDED`,应答回执同带这一位),但这一决不会让本副本上任何在跑的东西续跑 —— 续没续跑读 run 面。
+     * 只记真:缺席 = 本副本有引擎腿在等它(或老 server)。
      */
-    frame?: ToolApprovalFrame;
+    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 +868,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 +969,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;
@@ -1024,6 +1109,19 @@ export interface StreamApprovalGateInput {
     parkFacility: boolean;
 }
 export declare function resolveStreamApprovalGate(input: StreamApprovalGateInput): StreamApprovalGate;
+/**
+ * 审批开卡帧的**帧族词表**(闭集)—— 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];
 /**
  * [ref] 车3 刀 3b —— **一条执行腿的审批装配裁定**(sync / bg / resume **三腿共用**)。
  *
@@ -1073,25 +1171,31 @@ export interface ApprovalLegAssembly {
     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>;
+    writeLive?: (frame: ApprovalCardLegFrame) => void | Promise<void>;
+}): (frame: ApprovalCardLegFrame, registration: string) => Promise<void>;
 export declare function resolveApprovalLeg(input: {
     /** = `resolveStreamApprovalGate(...).active`(协议在本 worker 上场没有)。 */
     streamApprovalOn: boolean;
@@ -1179,6 +1283,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 +1321,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,13 +1349,13 @@ 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 部署安全。 */
@@ -1293,12 +1401,12 @@ 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})。
+        /** [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})。 */
@@ -1353,7 +1461,7 @@ export declare class ToolApprovalCoordinator {
     private unattendedOutcome;
     /** 政策**读**口(不是终局铸口)—— 回答「这台部署把无人可答翻成 park 吗」。
      *
-     *  🔴 与 {@link unattendedOutcome} 分家是 S-187 的一半:此前两件事共用一只方法,于是墓碑腿那次
+     *  🔴 与 {@link unattendedOutcome} 分家是 S-187 的一半:此前两件事共用一只方法,于是 park 路由判别那次
      *  纯粹的**政策查询**(`unattendedOutcome() !== false`)会和同一只 ask 的真终局各记一条遥测 ——
      *  「一只 ask 一条线」当场不成立。读口不落日志,铸口落;谁也不兼职。 */
     private get unattendedRoutesToPark();
@@ -1440,7 +1548,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 +1669,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})都只调这一只。
@@ -1684,24 +1792,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 +1922,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 +1972,67 @@ 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;
+    /** 一条行 → 按问读口的答案(行态六态穷举:新增 `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 +2069,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 +2120,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 +2245,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