@sema-agent/server 7.145.0 → 7.147.0

package/dist/{plugins → stores-sql}/checkpoint-store-sql.d.ts

@@ -1,252 +1,18 @@
 import type { Pool as MySqlPool } from "mysql2/promise";
 import type { Pool as PgPool } from "pg";
-import { type ExecutionOutcomeRecordWord, type GateOutcome, type Checkpoint, type CheckpointGate, type CheckpointRowVerdict, type CheckpointState, type CheckpointStore, type CheckpointSummary, type CheckpointToken, type PendingSteerInput, type ResumeOutcome, type ResolvedOutcome, type ResolveExpectation, type ReopenReason, type RiskDescriptor, type StoreDurability, type StoreFidelity, type ToolApprovalCard } from "@sema-agent/core";
-import { type ParkRowFacts, type RuleOfferProjection, type SkillCardFacts } from "../approval-card.js";
-import type { KindlessBatchRowSource, KindlessBatchScan } from "../approval-batch-census.js";
-import { type SqlDialect, type SqlDriver } from "./sql-driver.js";
-import type { SqlRunStore } from "./run-store-sql.js";
-import type { FencedRun } from "./store-contracts.js";
+import { type ExecutionOutcomeRecordWord, type GateOutcome, type Checkpoint, type CheckpointState, type CheckpointStore, type CheckpointSummary, type CheckpointToken, type PendingSteerInput, type ResumeOutcome, type ResolveExpectation, type ReopenReason, type StoreDurability, type StoreFidelity } from "@sema-agent/core";
+import { type SqlDialect, type SqlDriver } from "../plugins/sql-driver.js";
+import type { SqlRunStore } from "../plugins/run-store-sql.js";
+import type { FencedRun } from "../plugins/store-contracts.js";
 import type { RetentionDeclaration } from "@sema-agent/core";
+import { type CheckpointAskCandidate, type CtxClaimRewrite, type CtxRowRewrite, type CtxRowsRewrite, type DecidedApprovalRecord, type PendingCheckpoint, type PendingRowBinding } from "../plugins/checkpoint-store-face.js";
 import type { SealedCheckpointCtx } from "../http/checkpoint-ctx.js";
-/** ctx 行改写店腿的读数(两孪生同形):扫到的可读行 · 回写成的行 · 回写成的行里改写函数报的改动数 · 读不出的行 · 改写之后一行装不下的行。 */
-export interface CtxRowsRewrite {
-    readonly scanned: number;
-    readonly rewritten: number;
-    readonly valuesRewritten: number;
-    readonly unreadable: number;
-    readonly tooLarge: number;
-}
-/** 一行的改写:交回新的落盘形(只有封口模块的铸点产得出 —— 品牌型)与这一行的改动数;`undefined` = 这一行不写。 */
-export type CtxRowRewrite = (sessionId: string, ctx: object) => {
-    readonly ctx: SealedCheckpointCtx;
-    readonly values: number;
-} | undefined;
-/**
- * 🔴 **一次性迁移的 ctx 行改写店腿**(两孪生:`SqlCheckpointStore` / `LocalCheckpointStore` 的 `rewriteCtxRows`;逐行判词两孪生同):扫全部 `checkpoint_ctx` 行、
- * 交给 `rewrite`、交回新体的行原地回写(续跑时钟不动)。店不知道改写是什么 —— 用它的迁移各自带行改写:M28(凭据位明文封好)、M30(退役请求键改写)。
- * 窗与删法逐条在 `plugins/one-time-migrations.ts` 登记表;登记表里最后一条用它的迁移删码时,本腿、读数型与扫描页一起删。
- */
-export interface CheckpointCtxRowsRewriter {
-    rewriteCtxRows(rewrite: CtxRowRewrite): Promise<CtxRowsRewrite>;
-}
-export { approvalPayloadFingerprint } from "./approval-payload-fingerprint.js";
-/**
- * [ref] D-1 (§3 invariant #3 — crash-safe reaper backstop): an ABSOLUTE upper bound on a pending
- * checkpoint's lifetime, stamped at put() into `terminal_at_ms` INDEPENDENT of the per-approval `deadline`. The
- * SLA-timer (D-D) does the fine, per-gate-kind resolve-deny; THIS coarse backstop ensures even a pending row
- * with a NULL `deadline` (no approval TTL configured) is eventually GC'd if the SLA service dies — closing a
- * forever-leak of a never-resolved suspension (the current `reap`/`reapExpired` only catch non-NULL deadlines).
- * Generous (default 30d) so it never pre-empts a legitimately long-lived human/irreversible_ask gate;
- * env-overridable. Clamped ≥1min so a misconfig can't expire live suspensions instantly.
- */
-export declare const TERMINAL_BACKSTOP_MS: number;
-/**
- * [ref] D-D (cross-review fix): the crash-safe `terminal_at_ms` backstop must fall STRICTLY AFTER any SLA
- * `deadline`, never AT it. `terminal_at_ms = max(createdAt+backstop, deadline)` made the two coincide whenever an
- * operator tuned APPROVAL_TERMINAL_BACKSTOP_MS at/below the SLA — and reapExpired's terminal_at_ms-branch (which
- * has NO gate_kind filter) then abort-EXPIRED a human/irreversible_ask gate in the SAME tick the deny-sweep
- * wanted to gracefully DENY it, racing it away. Adding this grace to the deadline term guarantees the deny-sweep
- * at least this window of clean ticks before the absolute backstop can fire. Far smaller than the backstop, so
- * it never meaningfully delays the eventual crash-safe GC.
- */
-export declare const TERMINAL_GRACE_MS = 3600000;
 /**
  * The capability token IS the resume credential (token-as-auth) — anyone who reads it can impersonate a
  * resume, so it must never reach the logs (which fan out to a log-aggregation pipeline). For the diagnostic
  * resume-read-path log we emit a stable, non-reversible fingerprint instead, enough to correlate get↔resolve.
  */
 export declare function tokenFingerprint(token: string): string;
-/** Non-secret view of a pending checkpoint for the operator approval queue — deliberately NO token.
- *
- *  🔴 [ref]:行**顶层**另带 {@link ParkRowFacts}(`requiresRealApproval` / `ruleOffersAbsence`,真才带、缺席 ≠ false)——
- *  型与值都只有一个来源:`approval-card.ts` 的 {@link parkRowFacts}(两只店各读自己手里的那只寄存行 `pendingAction`,
- *  交给它、原样展开)。继承而不是在这里逐键再写一遍:core 给这一臂再加一位同类事实时,改的只有那张 Pick 表。
- *
- *  [ref]:授予绑定那一臂(`boundGrantDigest` / `boundGrantAbsence` 恰带其一)是 {@link ParkRowFacts} 的一部分,同样读自寄存行。
- *  技能卡两位({@link SkillCardFacts}:`boundGrants` / `classifierNoRuling`)另有一只投影 {@link skillCardFacts},输入是 core 的检查点摘要而不是
- *  寄存行原值(清单只在哈希等于摘要时才配上 wire,校验点单点在 core —— 见 {@link skillCardFacts} 顶注);同一张行上与收件箱行逐字同值,在场才带。 */
-export interface PendingCheckpoint extends ParkRowFacts, SkillCardFacts {
-    sessionId: string;
-    /**
-     * 这道停驻门的**非秘密稳定身份**(core `Checkpoint.checkpointId`,引擎每次停驻铸)—— 三处 durable 读面(本行 = `GET /v1/approvals` 的 `pending[]`
-     * 与 `/v1/approvals/stream` 的 `pending` 帧;停驻收件 `GET /v1/assistant/inbox` 的 `inbox[]`)共用的 **join 键**,也是 409 载体 A
-     * `pendingGate.checkpointId` / `terminal.paused.checkpointId` 的同一个值。**在场就是可信的那一个值,缺席就是缺席**:读法唯一 = `checkpoint-identity.ts` 的
-     * `durableRowIdentity`(过信任边界 —— 不含 token、有界),没有它的行(core 5.42.0 之前停驻的老行 / 没过边界的值)**照列**、键缺席(这一行没有可 join 的身份)、
-     * 每行计一次 `server.approvals.durable-row-checkpoint-id-missing`。两只店各读自己手里的那一份(SQL 孪生读 `checkpoint` 列的成员,LOCAL 孪生读 blob)。
-     */
-    checkpointId?: string;
-    scope: string;
-    toolName: string | null;
-    toolCallId: string | null;
-    /** [ref] D-1: the decision-action binding fields the operator/portal must ECHO back on /decide so the
-     *  resume binds to the EXACT action they saw (a stale view is then rejected fail-closed PRE-CAS). `boundCallId`
-     *  === `toolCallId` (the pending tool call); `boundInputHash` is the server-minted opaque hash of the shown
-     *  input (NEVER recomputed by the portal — echoed verbatim). Surfacing them here is what makes the D-1 TOCTOU
-     *  guard REACHABLE by the portal (without it the portal can only do the unbound legacy fallback).
-     *  🔴 [ref]②: ABSENT (key omitted, never `null`) on a park with no tool action (plan_review /
-     *  resource_limit / task_done) or a pre-D-1 legacy row ⇒ the consumer falls back to the unbound resolve.
-     *  The wire contract (§1) is "an absent nullable field is OMITTED, not null" — a `null` here invited a
-     *  consumer to treat the key's PRESENCE as "there is a binding" and echo `null` back into /decide. */
-    boundCallId?: string;
-    boundInputHash?: string;
-    /** 🔴 [ref]③: the checkpoint's gate kind — the operator queue mixes tool approvals with
-     *  plan_review / resource_limit / task_done parks (all of which carry `toolName: null`), so a durable-recovery
-     *  consumer needs this to ROUTE a row to the right wire (`/decide` vs `/plan_review` vs `/resume`). ALWAYS present
-     *  ([ref], 7.132.0): every park stamps it, the one-time migration M21 filled any row without it from the row's gate,
-     *  and a SQL row that still carries none is not listed by `listPending` (counted: `server.approvals.queue-row-gate-kind-missing`; no decide route binds it either). */
-    gateKind: CheckpointGate["kind"];
-    /** The suspended run's taskId (task_active join) — the key to the run/trace ("view task context"). */
-    taskId: string | null;
-    /** The pending tool call's args (post-hook), redacted + bounded — for tool_approval the write payload, for a
-     *  durable AskUserQuestion the question itself. Lets the approval card render WITHOUT an N+1 trace.turns
-     *  fetch. `null` for pre-migration rows (suspended before the column existed) ⇒ consumer falls back. */
-    input: unknown;
-    createdAt: number;
-    deadline: number | null;
-    /** [ref] riskDescriptor inbox: core's INERT triage descriptor ({severity 1-5, axes, toolName, redacted
-     *  summary, touchedPaths}) for human/irreversible_ask gates. listPending returns the queue severity-sorted
-     *  (DESC) so the supervisor inbox triages high-risk asks first. `null` for gates with no descriptor. */
-    riskDescriptor: RiskDescriptor | null;
-    /**
-     * [ref]-2 / [ref]② 起役;core 5.58.0([ref])换 OFFER 判别联合形:这条 park 的「不再询问」
-     * offers —— core 在 mint 这道门时挂到 `pendingAction.ruleOffers` 上的那一份(core
-     * `checkpoint-store.d.ts` 明写与同步腿的 `AskRequest.ruleOffers` 是**同一条契约**:序即契约——
-     * whole-string exact `single` 在场时恒 index 0、`batch` 恒末位,core 契约基数 ≤2 —— server 侧执法帽
-     * 是 `MAX_RULE_OFFERS`=4 的容忍余量,两个数的分工见该常量顶注)。
-     *
-     * 🔴 **本腿的下标不是 core 的 offer index,别把它当选择键**(5.58 复审 F-3,与契约文同批改准)。
-     * core 的契约原话是:丢掉不认识的成员时**必须保住每个留下来成员的原始 wire 下标**,做不到的消费端
-     * 「must suppress its persistence actions entirely (fail toward asking)」。本腿走的是**后者** ——
-     * {@link boundedRuleOffers} 对形不合的 offer 是**逐条丢弃并压紧**的(一条坏 offer 不该让另一条真 offer
-     * 消失,这条不变量本身有它自己的红格),压紧就意味着中间剔除会让后面的下标整体前移。之所以站得住,
-     * 是因为**本腿没有兑付口**:durable 回决体(`/v1/approvals/:id/decide`)不带规则位,选择键一次都没有
-     * 用到本腿的下标。⇒ **硬条款**:哪天 durable 腿真要开兑付位,先把「原始下标随行」显式加进本投影
-     * (或按 core 的另一半整格不投),而不是默默拿压紧后的下标当选择键。
-     * 与**同步腿**刻意分家:`buildRuleLaneMaterial` 那侧是**纯前缀截、零逐条丢弃**,所以活卡帧 /
-     * `card_json` / 重放帧上的下标**恒等于** core 的 offer index —— 兑付真发生在那条腿上。
-     *
-     * 🔴 **混舰队旧行(pre-5.58 的 `ruleSuggestions` 数组,无 `kind` 判别位)**:按新 Raw 形逐条不合
-     * ⇒ 整格落「无供给」——与 [ref] 升级单的舰队条款一致(旧建议面丢失只影响展示,ask 安全面照常;
-     * pending 审批短命,重触发即得新形卡)。**不做兼容读**(schema stale=重问,core 同款纪律)。
-     *
-     * 🔴 **无供给 ≠ 丢失**(本键存在的全部理由):同步腿的卡带这一格(`card_json` 里逐字在),而耐久腿
-     * (park 行 → `GET /v1/approvals`)此前**根本没投**,于是同一张卡走 durable 路时「不再询问」那一格
-     * 恒空 —— 消费端只能读成「本部署不供候选」。本键把 core 真给的那份带上 wire,缺席从此是**真的**没有
-     * 候选(规则车道没武装 / 命令说不出规则 / 这只 ask 规则清不掉),而不是投影层漏了。
-     *
-     * 🔴 **只在为真时在场**:core 不给 ⇒ 键**缺席**(不铸 `null`、不铸 `[]`)——与 `boundCallId`/`gateKind`
-     * 同一条 wire 纪律([ref]②「absent nullable field is OMITTED, not null」)。存量行(本列存在之前
-     * park 的)读回同样是缺席,与「这只 ask 没有候选」在消费端读法一致:本卡无此选项。
-     *
-     * 🔴 **展示用,永不参与 resume**:core 侧同款定性(「never read by the resume path, and never a rule by
-     * itself」)。本仓耐久腿今天也没有兑付口(`/v1/approvals/:id/decide` 的体不带规则位),所以它是**分诊
-     * 材料**不是承诺 —— 消费端渲这一格时要按「同副本活卡腿才兑得动」读(同 `ApprovalCardSchema.ruleOffers`
-     * 顶注那条射程说明)。
-     */
-    ruleOffers?: readonly RuleOfferProjection[];
-    /**
-     * [ref]①([ref]② / [ref];core 5.60.0 [ref]):**bidi 在场位**的耐久运维队列投影 —— 这条 park 行的
-     * 执行载荷里含至少一个 DIRECTIONAL 格式控制符(人眼读到的顺序与真正执行的字节顺序可能不同)。
-     *
-     * 值**完全由 core 供**:park mint 时 core 写在 `pendingAction`(tool_approval 臂)上的那一位
-     * (`PendingAction.hasBidiControls`,core [ref]),`put()` 在铸行
-     * 这一刻反范式成 `checkpoint.has_bidi_controls` 列(同行 `tool_input` / `bound_input_hash` / `gate_kind` /
-     * `risk_descriptor` / `rule_suggestions` 五列同一条「铸行时一格、读口零 blob」先例),server 不重算。
-     * ([ref] 起本读口**确实**逐行读 blob —— 只为 {@link ParkRowFacts} 那几位,且是按「本仓不发 ALTER TABLE、
-     * 加列 = 删库丢在飞 park」裁出来的代价,见 `listPending` 那一段;本位与五列的「铸行时一格」形不变。)
-     *
-     * 🔴 `true` **或缺席,恒不写 `false`/`null`**(core d.ts 的 OMIT 契约逐字点名 BFF:「never null, never
-     * present-but-undefined, never false」):缺席 = **没检出**(干净 / core 的有界扫描没够着 / 本列诞生前
-     * park 的老行),消费端**禁**读成「已确认干净」。与 `/v1/assistant/inbox` 那面的同名键同一份语义
-     * (那面由 `summarizeCheckpoint` 对老行做投影期回填;本面读列不读 blob,老行恒缺席 —— 两面的缺席
-     * 集合因此不完全相等,但两面对「缺席」的读法逐字相同)。同步腿(`tool_approval` 帧 / `approval_request`
-     * 卡)的对应键是 `inputHasBidi`(E-14),名字刻意不同:那一位是 server 对帧自身序列化后的 args 算的。
-     *
-     * 展示/分诊用,永不参与 resume / gate / CAS(core 同款 ECHO-ONLY 定性)。
-     */
-    hasBidiControls?: true;
-    /**
-     * core 7.49.0 [ref]:**这一行渲在哪张卡上** —— 门上引擎铸的 `gate.approvalCard`(闭集 core `TOOL_APPROVAL_CARDS`;`question` = 问用户的
-     * 问题,不是副作用工具),即 core `summarizeCheckpoint` 投给 `CheckpointSummary.approvalCard` 的同一个词。读法单点 = `approval-content-kind.ts`
-     * 的 `parkedApprovalCard`(只在审批门型上读、闭集窄读;两只店同调它:SQL 孪生读 `checkpoint` 列的 `gate` 子树,LOCAL 孪生读 blob 上的门)。
-     * 🔴 缺席即缺席([ref]② OMIT 纪律):非审批门、7.49.0 之前停驻的存量行(门上无卡 —— core 的读法「无卡 = 不是一问」,本仓**不**从
-     * 工具名回推)。两条 durable 读面(`GET /v1/approvals` 行 + `/stream` `pending` 帧)经同一投影同时携带;live 腿的同名键在
-     * `LivePendingRow.approvalCard`。展示/分诊用,永不参与 resume / gate / CAS。(此前此处是按 `tool_name` 列派生的 `contentKind`,随 [ref] 删。)
-     */
-    approvalCard?: ToolApprovalCard;
-    /**
-     * 这一行**本引擎续不续得了** —— core 判官 `judgeCheckpointRow` 对这一行盘上字节的判决(core 7.62.0 [ref];与助手收件箱行的 `rowVerdict`、
-     * 续跑在第一级读到的拒同一个读者、同一答),逐字投、本服务不重算不筛。判官要整行:SQL 孪生按 (库内算的 `checkpoint` 文本 sha256, 引擎构建)
-     * 记忆({@link StoredRowProjectionMemo}),未命中才按令牌批读整行;LOCAL 孪生取 core 店摘要上的同一位。
-     * 盘上字节读不成一只检查点的行(体是 `{}`、缺 `state`、JSON 字面 `null` / 标量 / 数组 / 非 JSON)同样判:判官对任何值都答,这种行答 `damaged`,
-     * 行照列(计 `server.approvals.park-row-blob-unreadable`)—— 一行坏字节只坏它自己那一行,见 {@link SqlCheckpointStore.readStoredRow}。
-     * **在场 ⇔ 这一次列表判过这一行**:缺席只在 SQL 孪生上出现 —— 两次读之间行已离开待决,或两次读之间行的字节变了(判过的是另一份,
-     * 不拼到这一行上;下一次列表即带)。缺席**不是** `ok`。非 `ok` 的行照列(人要看到它停在哪)。
-     */
-    rowVerdict?: CheckpointRowVerdict;
-}
-/**
- * [ref]([ref] / DEBTS [ref]):session 键读口(`findPendingTokenBySession` / `peekPendingScope`)的**行绑定**。
- *
- * 病灶(本仓自己两处成文:`server.ts` mintFreshRun 腿 409 段、`active-run-conflict.ts` `checkpointId` 顶注):
- * `checkpoint` 表**没有** per-session pending 唯一约束 —— 同一 session 下 `task_done` 纯 park(行已终局、
- * `task_active` claim 已释放)与下一条 run 的门 park **合法并存**;而两条读口此前是**无序 `LIMIT 1`**,同
- * session 两条 pending 时选中哪一条由存储引擎的扫描序决定:同一情形两次调用可能答出两张不同的门,路由层
- * 的 owner 门(`peekPendingScope`)与 `resumeCheckpoint` 的载入(`findPendingTokenBySession`)更可能各读到
- * 一条([ref] codex R3 揭的 tokenless TOCTOU 同源;[ref] 在取用点加了行级属主复核 = 下游兜底,本件是源头)。
- *
- * 为什么不是加唯一约束:那两条行的并存是**设计内**的形(见上),约束会把新 run 的 park `put()` 当场打死
- * (core 的 `CheckpointStore.put` 契约不允许);且 MySQL-protocol 侧没有部分唯一索引,TiDB 上要靠生成列
- * 绕,两方言分歧成本高于收益。
- *
- * 修法 = **读口带 gate 坐标 + 显式序**:
- *  · `gateKinds` 在场 ⇒ 只认这些门型的 pending 行(每条 resume 腿本来就只服务一种门型 —— decide 只解
- *    审批门、wake 只解 `task_done`、preempt 只解 `resource_limit`、plan_review 只解 `plan_review`;把
- *    这条已成文的守卫**前移到读口**,选错行这件事结构上不再发生)。**空数组 = 什么都不认**(显式 `1=0`,
- *    不静默退化成「任意门型」)。缺席 ⇒ 任意门型(存在性读口:boot reclaim / reaper probe / 断连竞态卫兵)。
- *  · 无论绑不绑,序恒为 `created_at_ms DESC, token DESC`(**最新优先**,主键兜平局):同一情形下每次读
- *    都答同一行;两条读口共用同一段谓词 + 同一段序({@link SqlCheckpointStore.pendingRowQuery} 单一属主),
- *    路由门与载入点结构上选中同一行。最新优先的理由:并存形里**老**的那条恒是终局后的 `task_done` 纯 park,
- *    活 run 的门在它之后铸。
- *
- * SQL twin 与 LOCAL twin 同判(local 侧按 `cp.gate.kind` 过滤、按 `createdAt`/token 同序取最新)。
- */
-export interface PendingRowBinding {
-    /** gate 坐标:只认这些门型的 pending 行(core `CheckpointGate["kind"]` 闭集)。缺席 ⇒ 任意门型。 */
-    gateKinds?: readonly CheckpointGate["kind"][];
-    /**
-     * 并存候选里取哪一端(缺省 `"newest"`)。两个取向各有一个**结构性**的消费者,别混用:
-     *  · `"newest"`(缺省)—— 「活 run 的门」族:并存形里老的那条恒是终局 task_done 纯 park,活 run 的门
-     *    在它之后铸 ⇒ 最新即正解;
-     *  · `"oldest"` —— **跨副本收敛**族(wake-mint 赢家复核 + wake 消费腿;codex 审批面轮 R2-[medium],
-     *    验真后修):收敛要的是一个**与自己的铸行时刻无关**的不动点。最新优先下「后铸者恒自选」——两副本
-     *    并发铸 task_done park 时,后铸的 B 复核必选中刚铸的自己,先铸的 A 若在 B 落盘前复核也选中自己,
-     *    两行双双留存、消息被拆到两张卡上。最老优先没有这个洞:**后铸者复核时先铸行必然已在**(它比自己老
-     *    ⇒ 选中它、expire 自己),先铸者无论何时复核都选中自己 ⇒ 不动点唯一。消费腿(/wake)取同端,
-     *    赢家卡与被消费卡恒同一张(FIFO 顺带成立)。
-     */
-    pick?: "newest" | "oldest";
-}
-/** [ref]:一条**仍持有 claim 的 run** 可能停在的全部门型(= 除 `task_done` 外全部;派生自上表,不手抄)。
- *  给「按 run 行动」的读口用:cancel / steer 的 park 落点、409 `pendingGate` 材料 —— 这些腿手里有 run 行,
- *  而 run 行一旦 parked 就绝不是 `task_done`,绑上它就把同 session 那条终局 park 排除在候选之外。 */
-export declare const LIVE_RUN_GATE_KINDS: readonly CheckpointGate["kind"][];
-/** [ref]:终局后纯 park 的门型(wake 腿 / wake-mint 赢家复核只认它)。 */
-export declare const TERMINAL_PARK_GATE_KINDS: readonly CheckpointGate["kind"][];
-/**
- * [ref]:LOCAL twin 与测试共用的**同序判据**——「候选集里哪一条是读口该答的那条」。与 SQL 的
- * `ORDER BY created_at_ms {DESC|ASC}, token {DESC|ASC} LIMIT 1` 逐字同义(token 列两方言都是二进制序 ——
- * MySQL `utf8mb4_bin` / PG `COLLATE "C"`,token 是 ASCII ⇒ JS 字符串比较与之同序)。
- * 返回 `true` 表示 `a` 应排在 `b` 前面(缺省最新优先;`pick:"oldest"` 时最老优先,取向语义见
- * {@link PendingRowBinding.pick})。
- */
-export declare function pendingRowPrecedes(a: {
-    createdAt: number;
-    token: string;
-}, b: {
-    createdAt: number;
-    token: string;
-}, pick?: "newest" | "oldest"): boolean;
 /**
  * `checkpoint` 表上**本仓后加、且被无条件引用**的列册 —— 升级前置探针({@link assertCheckpointColumnSchema})
  * 的唯一数据源。一行一列:列名 + 这一列不在时**运行期**先坏在哪(拒启文案逐字用它,所以运维读到的是
@@ -285,171 +51,6 @@ export declare const CHECKPOINT_ADDED_COLUMNS: ReadonlyArray<{
 export declare function assertCheckpointColumnSchema(query: (sql: string) => Promise<{
     rows: Record<string, unknown>[];
 }>, dialect: SqlDialect): Promise<void>;
-/**
- * 本店读者({@link boundedRuleOffers})**交给 core 读者的那份输入**:offer 扫描窗 {@link MAX_RULE_OFFER_SCAN} 与成员前缀帽({@link preboundBatchMembers})都扣在读之前,
- * 不是列表的值原样透传。**唯一写法**:回读 / 铸行 / LOCAL 孪生三条腿与起服普查({@link SqlCheckpointStore.scanKindlessBatchRows} 的 `rule_suggestions` 载体)读同一份输入 ——
- * 普查若对整只数组另判,「前 8 个成员合法、第 9 个是垃圾」的行本店读者读得出(走存量臂)而普查读不出,会把仍靠存量臂的行报成零。
- */
-export declare function boundedReaderInput(raw: unknown): unknown;
-/**
- * `pendingAction.ruleOffers` 的**铸行侧**投影(mint 面,与 {@link boundedToolInput} 同位同待遇)。
- *
- * 四件事,一件都不能少:
- *  1. **读**(宪法 [ref] 边界必判形 / 禁裸 as-cast):blob 里的这一格是 `unknown`(旧 core / 坏行 / 未来加字段都可能)。读者只有一只 =
- *     core `readRuleOffers`(经 `approval-card.ts` 的 {@link readRuleOfferList};core 7.55.0 [ref] P1 阶段二起,修前本仓自己一份 zod 形):读不出的**整条丢弃**
- *     (不是整只丢弃)——一条坏 offer 不该让另一条真 offer 消失;多余键逐级剥、不拒收(上游 additive 加一键是 core 的常规做法,拒收会把「有供给」静默变成「无供给」);
- *     丢弃**响亮**(`server.rule-offers.offer-dropped`,修前这一腿静默)。
- *  2. **脱敏**:offer 文本是从**命令原文**铸出来的(`Bash(curl -H "Authorization: Bearer …")` 这种 exact
- *     形拼得出秘密),而 `GET /v1/approvals` 是**跨租户可见**的运维队列。落列前过 `redactSecrets` ——
- *     与同行 `tool_input` 在 mint 就 `redactDeep` 是**同一条**纪律(秘密从此连**落库**都不落,不是落了库再在两条读面各洗一遍)。
- *  3. **脱敏之后**才截长(codex 交叉复审 [medium],验真后修):`redactSecrets` 会**变长**,先按限长校验
- *     原文再脱敏会产出超限文本,而 SQL 腿有**回读**(列 → 本函数再跑一遍)、LOCAL 腿没有 ⇒ 同一份素材
- *     两个后端给出不同卡面。顺序反过来之后本函数对自己的输出**幂等**,两条腿同形。
- *  4. **限基数**:core 契约今天 ≤2,这里按 {@link MAX_RULE_OFFERS}(=4,server 侧容忍帽,两个数的
- *     分工逐字见该常量顶注)截;`batch.rules` 成员另按 {@link MAX_RULE_OFFER_BATCH_MEMBERS}(=8)截 ——
- *     一条被改坏/未来放宽的上游不该把运维队列的一行撑爆。两个截都是**前缀截**(保序)。
- *     ⚠️ **但本函数整体不保原始下标**:第 1 条的「坏的逐条丢」会压紧数组 ⇒ 中间剔除后下标前移。
- *     本腿因此是**纯展示腿**,下标不得当选择键 —— 硬条款与它站得住的理由逐字见
- *     {@link PendingCheckpoint.ruleOffers} 顶注(同步腿相反:那侧零逐条丢弃,下标恒等于 core 的 offer index)。
- *     🔴 **成员帽扣在读之前**(5.58 复审 F-2):见 {@link preboundBatchMembers} —— offer 条数那一维由
- *     {@link MAX_RULE_OFFER_SCAN} 管,成员那一维在那之前是**无界**的。
- *     🔴 **扣预算在读出之后**(合并码重扫):旧序先 `slice` 再判形,于是 ≥MAX 条坏 offer 能把唯一的真
- *     offer 挤出预算,读数是 `undefined` —— 与上面第 1 条自证的不变量(坏的丢、好的照投)正相反。扫描窗
- *     {@link MAX_RULE_OFFER_SCAN} 仍是有界的:一条被改坏成上万条的行不该让每 3s 一拍的读路径去逐条判形。
- *
- * 🔴 `opts.countRedactions`:**两条腿都照常脱敏,只有回读腿不计数**(合并码重扫;codex 复审第一轮
- * 指出「回读不脱敏」会把纵深防御一起关掉,验真后按这条收)。`redactSecrets` 对自己的输出是**值幂等、
- * 计数不幂等**(URL-userinfo / JSON 秘密字段两条 pattern 会命中自己的输出并再计一次),而回读腿正是
- * `/v1/approvals/stream` 每 3s 一拍的热路径 ⇒ 每条订阅每行每拍给 `redactions_applied_total` +1,把那个
- * 用来识别「过度脱敏 / pattern 从不触发」的指标灌成不可读。关掉的是**计数**:重扫仍在,手改过的行 /
- * 将来某条写路径漏了脱敏,读面照样兜住(运维队列跨租户可见,少脱一次的代价永远不能省)。
- *
- * 返回 `undefined` = **无供给**(键不落列):core 没给、给了空数组、或整只读不出。
- */
-export declare function boundedRuleOffers(raw: unknown, opts?: {
-    countRedactions?: boolean;
-}): RuleOfferProjection[] | undefined;
-/**
- * [ref] —— 运维队列行的门型:**两只孪生同一只判官**(SQL 孪生读 `gate_kind` 列 —— put 时从同一只门反范式下来的那一格,每次停驻都盖,一次性迁移 M21 把没有它的
- * 存量行从门子树补齐;local 孪生读快照上的门 `cp.gate.kind`)。
- * 读到的值是 NULL / 缺席 / 不是 core 登记的门型 ⇒ `undefined`:这一行**不列**(响亮:计一次 `server.approvals.queue-row-gate-kind-missing`)—— 与每一条决断口同一个读法:
- * 按门型绑定取行的读口对这种行本来就不命中(`pendingRowQuery` 的 `gate_kind IN (…)`,证不出门型就不当它是这道门),队列不再把一行谁也决不了的行投出去,
- * 也不按缺键投(消费方按 `gateKind` 路由、缺键即 fail-closed)。不整只拒:一行坏行不许让整个租户的队列(列表 500、SSE 心跳照常而队列永远停在旧帧)消失。
- * 按构造不可达(写口恒盖、M21 补齐);计数非零 = 写腿或手改出了错,按 `SELECT … WHERE status = 'pending' AND gate_kind IS NULL` 查那一行。
- */
-export declare function queueRowGateKind(kind: unknown): CheckpointGate["kind"] | undefined;
-/** Redact + size-bound a pending tool call's args for persistence/serving. JSON-roundtrips so the stored shape
- *  matches what the operator queue serves; oversized payloads collapse to a marker rather than bloating the row.
- *  Exported for the LOCAL twin (local-checkpoint-store.ts) so the operator-queue projection can't drift. */
-export declare function boundedToolInput(args: unknown): unknown;
-/**
- * 🔴 [ref] 车5 §9 C4:`findCheckpointCandidatesForAsk` 的 typed 候选行。刻意只有对账收敛器判据 1 真需要的
- * 五件——**没有 token 之外的任何凭据面**,`token` 本身是 resume 凭据、只在服务端内部流转(同
- * `findPendingTokenBySession`:它从不出网,§12-C「checkpointToken 从不外发」)。
- */
-export interface CheckpointAskCandidate {
-    token: string;
-    /** `checkpoint.status` 列(权威;`pending` | `resolved` | `expired`)。不做过滤,由收敛器判活性。 */
-    status: string;
-    createdAtMs: number;
-    /**
-     * 🔴 和解三元组的第一维([ref] 件1,黑板 [ref]③①)—— checkpoint 自己带的 `sourceSessionId`(core 在
-     * suspendAsk 铸行时恒填该腿的 `sessionId`)。**没有对应的列**,只能从 blob 窄读;读不出/缺席 = null。
-     *
-     * 为什么必须进候选集:读口按 `(scope, session_id, tool_call_id)` 查,而委派子代那条腿的 ask 落行时
-     * `session_id` 记的是**投递上下文**(根会话),park 却发生在**子代自己**的 sessionId 上 —— 只靠
-     * (toolCallId, hash) 两维,一条根腿的 park 会被一只子代的 ask 认领(摘要相同的两次同 args 调用完全
-     * 正常)。三元组全同才算同一件事。
-     */
-    sourceSessionId: string | null;
-    /** 该 park 绑定的 tool call(= `pendingAction.toolCallId`)。`unparseable` 行为 null。 */
-    boundCallId: string | null;
-    /** 服务端铸的入参摘要——判据 1 的第二道硬等式(与 `approval_ask.bound_input_hash` 相等才算命中)。 */
-    boundInputHash: string | null;
-    /** 在场 ⇒ 这行读不出(blob 版本超前 / JSON 坏)。收敛器视同不匹配;**从不是** false,缺席即可读。 */
-    unparseable?: true;
-}
-/**
- * [ref] 件1 —— legacy `/v1/approvals/:sessionId/decide` 腿的**幂等回放**判别行(窄读,非凭据面)。
- *
- * 刻意**不带 token**:回放只需要「这条已决的行归谁、绑的是哪一次调用、判词是什么」三件,而 token 是
- * resume 凭据(§12-C「checkpointToken 从不外发」;`CheckpointAskCandidate` 带它是因为收敛器要拿它去
- * `bindBatch`,本口没有那个用途 ⇒ 不给)。
- */
-export interface DecidedApprovalRecord {
-    /** 行的属主 scope 列(`encodeCheckpointScope` 的产物:principal 或匿名哨兵 `"_"`)。回放属主门的输入。 */
-    scope: string;
-    /** 行上的 D-1 入参摘要(`bound_input_hash` 列);pre-D-1 行为 null。 */
-    boundInputHash: string | null;
-    /**
-     * 这条已决行的**工具审批判词**,或 `null` = **判别不出**(codex R1-[medium] 四的收敛形):
-     * outcome 读不出 / 没有 winner / winner 绑的是**另一个** callId / 判词是 REVIEW 门那三个词。
-     *
-     * 🔴 `null` **不是**「无所谓」:调用方必须把它当「这条命中的行我读不懂」⇒ **整次回放拒绝**。
-     * 一条读不懂的已决行与一条判词相反的已决行在风险上同级 —— 都意味着这只 callId 上的持久事实
-     * 不是本次回放能如实复述的。
-     */
-    decision: "approve" | "deny" | null;
-    /**
-     * 判词**之外**的决议载荷指纹(codex R2-[high] 一,验真后补):`updatedInput` / `answer` / `reason`
-     * 三件都在 core 的持久 winner 里,而**同判词不等于同决议** —— 「approve + 编辑后的实参 A」与
-     * 「approve + 实参 B」是两次不同的放行,只比判词就会把后者谎报成「你的请求已被处理」(而 B 从未执行)。
-     * 调用方按**同一份请求重发**的语义要求它与本次请求的同三件逐字相等。
-     * `null` = 算不出(载荷序列化不了)⇒ 与 `decision: null` 同判:整次拒绝。
-     * 铸法见 {@link approvalPayloadFingerprint}(两条车道共用同一只,免得指纹口径漂)。
-     */
-    payloadFp: string | null;
-    /**
-     * [ref](core 7.7.0 [ref])—— 这条已决行上**已决动作最后被怎么处置**的结算记录,`null` = **未知**。
-     *
-     * 🔴 缺席只有一个含义:未知,**绝不是**「放行过」。`decision` 说的是决定(人批了没有),这一格说的是
-     * 那次决定在 resume 腿上执行时的处置(部署自己的复核可能在 post-CAS 把人批过的、改过参数的调用否掉,
-     * 于是 `decision: "approve"` 与 denied/policy 的处置**同时**在一行上成立)。[ref] 的病正是「流断之后
-     * 从行重建这条 run 的消费者只读得到前半句」——decide 幂等回放正是那种消费者。
-     *
-     * 铸法 = core 的 {@link executionVerdict} **单口**(两条车道共用),不许任何读点自己判列的在场性。
-     */
-    executionOutcome: GateOutcome | null;
-}
-/**
- * [ref] 件1 —— {@link SqlCheckpointStore.findDecidedApprovalsForBinding} 的扫描上界。
- *
- * 🔴 它**同时是判据**,不只是一道 LIMIT:调用方按「命中集里每条判词都一致才回放」判,而一次被截断的
- * 集合可能把分歧藏在第 N+1 行 ⇒ 消费点约定「**回满 = 判别不出**」,整次拒绝回放(回落 404)。现网正常形
- * 恒 0 或 1 行,回满只可能是数据异常。
- */
-export declare const DECIDED_REPLAY_SCAN_CAP = 8;
-/**
- * [ref] 件1 —— core 的 `ResolvedOutcome` → 本腿(工具审批 decide)的二值词表。**闭集穷举**([ref]):
- * core 哪天给 `ResolvedOutcome.decision` 加员,下面的 `never` 当场编译期红,而不是让一个新判词被
- * 静默折成 `deny` 或漏成「没有决议」。
- *
- * 三条判据,缺一即 `null`(= 不回放,调用方逐字回落修前 404 —— **绝不**把 not-found 洗成成功):
- *  ① 有 winner —— `resource_limit` / `wake` / `task_done` 的 resolve 不记 winner(core 契约),那些行
- *     不是「一次人给的工具审批」,没有可回放的判词;
- *  ② winner 绑的正是这次请求回显的那个 `boundCallId` —— 身份第二锚(列谓词是第一锚),两锚同意才算同一件事;
- *  ③ 判词属于**工具审批**那两个词(`allow`/`deny`)—— `approve`/`reject`/`edit` 是 REVIEW 门
- *     (plan_review / dry_run_review)的判词,那些门的决议入口不是本腿,回放它们等于跨门作答。
- */
-export declare function approvalDecisionOfWinner(winner: ResolvedOutcome | undefined, boundCallId: string): "approve" | "deny" | null;
-/** 收敛器读口对一行的身份判词(三态 + 读不出;读法见 {@link pendingActionToolCallId} / {@link candidateIdentityOf})。 */
-export type CandidateIdentity = {
-    readable: true;
-    toolCallId: string | null;
-    boundInputHash: string | null;
-    kind: string | null;
-    sourceSessionId: string | null;
-} | {
-    readable: false;
-};
-/**
- * 收敛器读口的**身份判词**(两只孪生同一只;`findCheckpointCandidatesForAsk` 的 SQL / LOCAL 两形都只经这里):先问 core 判官 `judgeCheckpointRow`
- * (core 7.62.0 [ref],[ref])—— 判 `lacking`(更新的引擎能续它、本引擎缺读法:格式版本超上限,或要求表点名了本引擎不认的读法词)⇒ `{ readable: false }`:
- * 本副本读不准这一行,交给收敛器当「不确定」,留给能续它的副本去绑(修前 SQL 孪生按 `version` 列比 `MAX_SUPPORTED_CHECKPOINT_VERSION`,
- * 射程只有版本一轴,LOCAL 孪生没有这一臂)。`damaged` **不是**这一臂:本引擎不续这些字节(别的副本续不续,引擎没有说、本服务不替它们断言),身份读得出就照常判 —— 绑上之后续跑由判官给那句固定的拒,
- * 比让 ask 停在 PARKING 诚实。其余三态见 {@link pendingActionToolCallId}。
- */
-export declare function candidateIdentityOf(cp: Checkpoint): CandidateIdentity;
 /** `pending_steer_queue` 列承载的 CheckpointState 字段(= core `appendPendingSteer` / `readPendingSteerQueue`
  *  的入参形)。列是**唯一**权威(suspend 时写的 blob 从不带它)。 */
 type SteerColumnState = Pick<CheckpointState, "pendingSteerQueue">;
@@ -472,23 +73,19 @@ interface SteerColumnRead {
  * 列有内容却读不出 ⇒ `lossy`(两个调用点对它的处置见 {@link SteerColumnRead})。
  */
 export declare function readPendingSteerQueueColumn(queueRaw: unknown): SteerColumnRead;
-/** 认领栅栏下改写一行 ctx 的结局(闭集;SQL / local 两孪生同词):`written` 写了;`claim_released` 接下改写的那条腿此刻已不持有这条 run(认领放了 / 不在跑 / 腿判据答否)⇒ 零写;
- *  `context_absent` 持有、但会话没有 ctx 行 ⇒ 零写(不建行)。 */
-export declare const CTX_CLAIM_REWRITES: readonly ["written", "claim_released", "context_absent"];
-export type CtxClaimRewrite = (typeof CTX_CLAIM_REWRITES)[number];
 /** SQL checkpoint 店的装配选项:托管留存声明 + ctx 改写的认领栅栏(同一只池上的 run 店)。 */
 export interface SqlCheckpointStoreOptions {
     readonly retention?: RetentionDeclaration;
     readonly claims?: SqlRunStore;
 }
 /** Dual-dialect durable CheckpointStore. See the file header for the dialect-delta ledger. */
-export declare class SqlCheckpointStore implements CheckpointStore, KindlessBatchRowSource {
+export declare class SqlCheckpointStore implements CheckpointStore {
     protected readonly db: SqlDriver;
     protected readonly logger?: {
         info?(msg: string, meta?: unknown): void;
     } | undefined;
     /** 托管留存声明 = 装配交给它的词(后端按扫车道开不开给;不给 ⇒ `"none"`)。读法与「为什么 SQL 店答 managed 而三方法的实现体在
-     *  `retention-store-sql.ts`」逐字见 {@link MANAGED_RETENTION}(扫车道开着时本店的 `checkpoint`/`checkpoint_ctx` 两表由那只聚合店按期清)。 */
+     *  `retention-store-sql.ts`」逐字见 `plugins/retention-declaration.ts` 的 {@link MANAGED_RETENTION}(扫车道开着时本店的 `checkpoint`/`checkpoint_ctx` 两表由那只聚合店按期清)。 */
     readonly retention: RetentionDeclaration;
     /**
      * `CheckpointStore.durability` 声明([ref] 欠账,[ref] 件5)—— 行落在 MySQL-protocol / PostgreSQL 的
@@ -739,9 +336,11 @@ export declare class SqlCheckpointStore implements CheckpointStore, KindlessBatc
      *
      * 一行停驻行的整行读 = `checkpoint` 列那一份字节 → core 判官 `judgeCheckpointRow` 的判决 + (读得动时)core 的摘要 `summarizeCheckpoint`。
      * 判决**恒在**:判官对任何值都答(core:pure and total),字节读不成一只检查点(JSON 字面 `null` / 标量 / 数组 / 非 JSON)⇒ 交给它的是这一格**原样的文本**
-     * (不是本店编的一行),它答 `damaged`;体是对象而摘要读不动(`{}`、缺 `state` / `pendingAction` / `gate` 的手改行)⇒ 判官对这只对象答 ——
-     * 🚧 判官与摘要对「缺 `pendingAction`」不同答(摘要抛、判官答 `ok`:core 判官不查这一位),这一形的行照列而判决是 `ok`;本店不另判(判官的缺口归 core)。
-     * 摘要读不动的两种都计 `server.approvals.park-row-blob-unreadable`(每次列表都计)、不进记忆;**不抛** —— 修前收件箱 / 任务视图对这种行整张拒
+     * (不是本店编的一行),它答 `damaged`;体是对象而摘要读不动(`{}`、缺 `state` / `pendingAction` / `gate` 的手改行,成员形不对的行)⇒ core 的摘要答它的
+     * 「读不动」那一形({@link isUnreadableSummaryForm}),判决取那一形上的(core:判官的判决,判官答 `ok` 时是「读不动」的固定判决,恒非 `ok`),
+     * 身份由调用方取本店的列组;core 的投影自己抛(它的已知限制:摘要读到成员形表之外的一位)⇒ 判官对这只对象答。
+     * 摘要读不动的几种都计 `server.approvals.park-row-blob-unreadable`(每次列表都计)、不进记忆,core 交给披露座的那一句随之不进风险轴的计数;
+     * **不抛** —— 修前收件箱 / 任务视图对这种行整张拒
      * (`{}` / 缺 `state` 落 503「请重试」,坏行不修同路径恒失败),运维队列对字节解不出的行不带判决:同一张坏行两个读者两个方向。
      * 读腿漂(`not-text`:SELECT 没投影这一列)与摘要格形不对照旧原样抛 —— 那是码坏,不是一行数据坏。
      *
@@ -756,7 +355,7 @@ export declare class SqlCheckpointStore implements CheckpointStore, KindlessBatc
      * {@link Checkpoint} `get()` parses), so a readable row stays byte-identical to core's InMemory/Pg/File impls. Order =
      * created_at_ms ASC; callers (the inbox/scheduler) sort by severity.
      *
-     * 一行读不出摘要(字节解不出 / 体是对象而摘要读不动)⇒ 这一行**照列**,判决由判官给(缺 `pendingAction` 那一形判官答 `ok`,见 {@link SqlCheckpointStore.readStoredRow}),其余几位取本店在字节**之外**握着的事实:
+     * 一行读不出摘要(字节解不出 / 体是对象而摘要读不动)⇒ 这一行**照列**,判决非 `ok`(见 {@link SqlCheckpointStore.readStoredRow}),其余几位取本店在字节**之外**握着的事实:
      * 令牌 / 会话 / scope / 建行时刻 / 截止 / 门型(`gate_kind` 列,与运维队列同一只判官 {@link queueRowGateKind}:读不出 ⇒ 不列、计数)/
      * `checkpointId` 成员(是串才带;入 wire 前过信任边界由路由判)。失败方向与运维队列同一条律({@link SqlCheckpointStore.readStoredRow})。
      *
@@ -908,20 +507,6 @@ export declare class SqlCheckpointStore implements CheckpointStore, KindlessBatc
      * ⇒ 不计、不重试(新写者是本版写下的、已是新形;是旧版副本就由之后的起服再扫到)。一行装不下(如封签比明文长)⇒ 计 `tooLarge`、那一行留原样,其余照扫。
      */
     rewriteCtxRows(rewrite: CtxRowRewrite): Promise<CtxRowsRewrite>;
-    /**
-     * 起服普查的读口({@link KindlessBatchRowSource};用法、范围与『为什么只数不改』见 `approval-batch-census.ts` 头注)—— 两个 SQL 方言**同一份实现**:
-     * 按 `token` 键集分页扫 `checkpoint`(所有状态的行),取两个载体,**各按它的读者判**(判官都是 core `readRuleOffers` 给读出的 batch 打的 `kindlessForm` 记号,
-     * {@link countKindlessBatchOffers};一行里任一载体带旧形成员即算一行):
-     *  · `rule_suggestions` 列(审批候选的落列)—— 读者是本店的回读口,吃的是 {@link boundedReaderInput}(扫描窗 + 成员前缀帽);普查读同一份输入;
-     *  · blob 里 `pendingAction.ruleOffers`(引擎铸、本店原样存、`put` 不校验)—— 读者是引擎(整只数组,没有本店的窗),普查读整只数组;在场却不是列表 ⇒ 数进 `unreadableCells`。
-     * 预筛(只为省传输,**不是判官**):`rule_suggestions` 是原样存的 TEXT(转义写法可以不同于 `JSON.stringify`),所以只问 `IS NOT NULL`,不做字符串匹配;
-     * blob 是 JSON 承载列(MySQL 协议 JSON / PG jsonb 入库即规范化),它的 `pendingAction` 子树文本里一个字符串值 `batch` 恒以 `"batch"` 字面出现 ⇒ `LIKE '%"batch"%'` 对它是完备的
-     * (空白不同无妨:MySQL 协议 `"kind": "batch"`)。
-     * 读不出形的 cell(坏 JSON / 不是列该有的形;读口是 {@link decodeNullableJsonColumn} 同一只,只容忍「体」的问题,读腿漏投影的 `not-text` 原样抛)不计入行,
-     * 数进 `unreadableCells`(到不了读者,但不静默:`rule_suggestions` 坏 cell 在队列读面有 `server.approvals.rule-suggestions-cell-unreadable`,普查另出 warn)。
-     * 行指纹 = {@link tokenFingerprint}(token 是机密,永不进遥测)。**只读**:不改任何一行;逐页读、**不是原子快照**(页间别的副本的写入可以让一行被漏数或多数一行)。
-     */
-    scanKindlessBatchRows(): Promise<KindlessBatchScan>;
     /**
      * GC ctx rows whose lifecycle is over (bound to the checkpoint, don't leak):
      * a session with NO pending checkpoint, NO active run, AND not touched since `cutoff`.
@@ -968,4 +553,5 @@ export declare class PgCheckpointStore extends SqlCheckpointStore {
         info?(msg: string, meta?: unknown): void;
     }, opts?: SqlCheckpointStoreOptions);
 }
+export {};
 //# sourceMappingURL=checkpoint-store-sql.d.ts.map