@sema-agent/server 7.43.0 → 7.44.0

package/dist/plugins/checkpoint-store-sql.js

@@ -1,33 +1,5 @@
-/**
- * Durable `CheckpointStore` (core 1.67 durable-checkpoint / design/45) — SINGLE-FILE DUAL-DIALECT
- * (design/158 A12 定型半场). ONE implementation, TWO dialects; the historical `TiDBCheckpointStore` /
- * `PgCheckpointStore` class names survive as thin ctor subclasses so every consumer (store-backend.ts,
- * local-checkpoint-store.ts, the chaos/ownership/blackbox suites) is untouched.
- *
- * This is the durable backend that makes a policy `ask` survive cross-replica/crash/time as a suspended
- * task an operator can `resume` from any instance. It implements core's `CheckpointStore` (put create-once
- * / get / atomic CAS resolve / reopen / reap), modeled on the proven approval-store CAS, plus two concerns
- * the core interface doesn't own but the service does (DURABLE-CHECKPOINT-PLAN §4.4a):
- *   - `checkpoint_ctx` (sessionId-keyed): the service-side scenario rebuild inputs for `resume`'s taskConfig —
- *     core's `put(token, cp)` can't carry it (it's service "profile", not the generic core checkpoint).
- *   - operator-queue helpers (`listPending` / `findPendingTokenBySession`) that surface NON-secret fields and
- *     map a session → its pending token INTERNALLY — the capability token never leaves the service (token-as-auth).
- *
- * ── Dialect deltas, kept EXPLICIT ────────────────────────────────────────────────────────────────────
- *   - `?` placeholders vs `$n` (and the OPTIONAL `AND rev = ?` / `AND rev = $5` OCC tail)
- *   - `ON DUPLICATE KEY UPDATE … VALUES(col)` vs `ON CONFLICT (session_id) DO UPDATE SET … EXCLUDED.col`
- *   - dup-key errno `1062` (ER_DUP_ENTRY) vs SQLSTATE `23505`
- *   - null-safe owner compare: `<=>` vs `IS NOT DISTINCT FROM` — AND the parameter arity that follows
- *     (`?` cannot be reused, so the TiDB deleteBySession binds sessionId TWICE; PG reuses `$1`)
- *   - affectedRows vs rowCount (via SqlDriver)
- *   - JSON binding: TiDB `JSON.stringify` verbatim vs PG `pgProtocolJsonStringify` + `$n::jsonb` casts.
- *     PG's envelope is LOSSLESS (codex R4-H1): tool_input is the operator's review surface and must agree
- *     with `checkpoint.pendingAction.args` at the NUL position — redact/truncate is the display contract,
- *     byte rewriting is not.
- *   - schema ownership: TiDB DDL in tidb-pool.ts, PG DDL centrally in pg-pool.ts (neither store creates tables).
- */
 import { createHash } from "node:crypto";
-import { APPROVAL_GATE_KINDS_SQL_IN } from "../tool-approval.js"; // A-002.1 单一属主(SQL IN 片段从闭集数组派生)
+import { APPROVAL_GATE_KINDS_SQL_IN } from "../tool-approval.js";
 import { CheckpointError, MAX_RULE_TEXT_CHARS, validatePendingSteer, appendPendingSteer, checkpointVersionOf, winnerFromOutcome, summarizeCheckpoint, MAX_SUPPORTED_CHECKPOINT_VERSION, } from "@sema-agent/core";
 import { redactDeep, redactSecrets } from "../trace/redact.js";
 import { MAX_RULE_SUGGESTIONS, RuleSuggestionRawSchema } from "../approval-card.js";
@@ -36,77 +8,13 @@ import { recordFailOpen } from "../observability/fail-open.js";
 import { mysqlDriver, pgDriver, dialectProtocolJsonEncoder } from "./sql-driver.js";
 import { isDupKeyError } from "./sql-errors.js";
 import { MANAGED_RETENTION } from "./retention-store-sql.js";
-/** Cap the persisted/served pending-approval args so a pathological tool payload can't bloat the checkpoint row
- *  or the operator-queue response (the BFF renders this in an approval card; a few KB is plenty). */
 const MAX_TOOL_INPUT_CHARS = 8192;
-/**
- * design/80 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.
- */
-// A-067 C1-2(F2a):解析必须钳有限——`"Infinity"` 经 `Number(env) || def` 取 Infinity、Math.max 恒
-// Infinity ⇒ 本常量存在的唯一理由(SLA 服务死掉后 pending 行仍被 GC 的 crash-safe 绝对上限)整条失效。
-// 非有限/非法值落默认(与 remote-shell numEnvOr 同判据方向;此处零告警通道,静默落默认承原形)。
 export const TERMINAL_BACKSTOP_MS = Math.max(60_000, (Number.isFinite(Number(process.env.APPROVAL_TERMINAL_BACKSTOP_MS)) ? Number(process.env.APPROVAL_TERMINAL_BACKSTOP_MS) : 0) || 30 * 86_400_000);
-/**
- * design/80 D-D (adversarial 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 const TERMINAL_GRACE_MS = 3_600_000; // exported for the LOCAL twin's read-time terminal_at_ms derivation (anti-drift) // 1h — many reaper intervals of deny-sweep runway past the SLA deadline
-/**
- * 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 const TERMINAL_GRACE_MS = 3_600_000;
 export function tokenFingerprint(token) {
     return "sha256:" + createHash("sha256").update(token).digest("hex").slice(0, 12);
 }
-/** 窄读的**扫描窗**:最多看这么多条原料再判形(基数帽 {@link MAX_RULE_SUGGESTIONS} 扣在合形之后)。
- *  存在的理由是热读路径的有界性,不是基数语义 —— 所以它比基数帽宽得多。 */
 const MAX_RULE_SUGGESTION_SCAN = 32;
-/**
- * `pendingAction.ruleSuggestions` 的**铸行侧**投影(mint 面,与 {@link boundedToolInput} 同位同待遇)。
- *
- * 三件事,一件都不能少:
- *  1. **结构窄读**(宪法 [2704] 边界必 schema / 禁裸 as-cast):blob 里的这一格是 `unknown`(旧 core /
- *     坏行 / 未来加字段都可能)。形不合的**整条丢弃**(不是整只丢弃)——一条坏候选不该让另一条真候选消失。
- *     判据只看 `rule`/`match`/`command` 三键合形(`RuleSuggestionRawSchema` 是**默认 strip 形** `.strip()`,
- *     多余键**剥掉**、且不拒收 —— 重扫二轮更正:旧注写 `.loose()`,而 zod 4 的 loose = passthrough,
- *     未知键会**留在** `parsed.data` 里,与「剥掉」相反)。上游 additive 加一键是 core 的常规做法,拿 strict 去窄读会让那一次加字段把整只
- *     候选静默清零 —— 「有供给」当场变「无供给」,与本键的存在理由正相反(顶注第三段)。
- *  2. **脱敏**:候选文本是从**命令原文**铸出来的(`Bash(curl -H "Authorization: Bearer …")` 这种 exact
- *     形拼得出秘密),而 `GET /v1/approvals` 是**跨租户可见**的运维队列。落列前过 `redactSecrets` ——
- *     与同行 `tool_input` 在 mint 就 `redactDeep` 是**同一条**纪律(#209 件4 把 `shadowedRule` 修在读面
- *     是因为那条路的行早已落库、改铸点救不了存量;本键是**新**列,没有存量行要救,修在铸点更彻底:
- *     秘密从此连**落库**都不落,不是落了库再在两条读面各洗一遍)。
- *  3. **脱敏之后**才截长(codex 对抗复审 [medium],验真后修):`redactSecrets` 会**变长**,先按限长校验
- *     原文再脱敏会产出超限文本,而 SQL 腿有**回读**(列 → 本函数再跑一遍)、LOCAL 腿没有 ⇒ 同一份素材
- *     两个后端给出不同卡面。顺序反过来之后本函数对自己的输出**幂等**,两条腿同形。完整论证见
- *     `RuleSuggestionRawSchema` 顶注。
- *  4. **限基数**:core 契约今天 ≤2,这里按 {@link MAX_RULE_SUGGESTIONS}(=4,server 侧容忍帽,两个数的
- *     分工逐字见该常量顶注)截 —— 一条被改坏/未来放宽的上游不该把运维队列的一行撑爆。
- *     🔴 **扣预算在合形之后**(合并码重扫):旧序先 `slice` 再判形,于是 ≥MAX 条坏候选能把唯一的真候选
- *     挤出预算,读数是 `undefined` —— 与上面第 1 条自证的不变量(坏的丢、好的照投)正相反。扫描窗
- *     {@link MAX_RULE_SUGGESTION_SCAN} 仍是有界的:一条被改坏成上万条的行不该让每 3s 一拍的读路径去逐条判形。
- *
- * 🔴 `opts.countRedactions`:**两条腿都照常脱敏,只有回读腿不计数**(合并码重扫;codex 复审第一轮
- * 指出「回读不脱敏」会把纵深防御一起关掉,验真后按这条收)。`redactSecrets` 对自己的输出是**值幂等、
- * 计数不幂等**(URL-userinfo / JSON 秘密字段两条 pattern 会命中自己的输出并再计一次),而回读腿正是
- * `/v1/approvals/stream` 每 3s 一拍的热路径 ⇒ 每条订阅每行每拍给 `redactions_applied_total` +1,把那个
- * 用来识别「过度脱敏 / pattern 从不触发」的指标灌成不可读。关掉的是**计数**:重扫仍在,手改过的行 /
- * 将来某条写路径漏了脱敏,读面照样兜住(运维队列跨租户可见,少脱一次的代价永远不能省)。
- *
- * 返回 `undefined` = **无供给**(键不落列):core 没给、给了空数组、或整只形不合。
- */
 export function boundedRuleSuggestions(raw, opts = {}) {
     if (!Array.isArray(raw))
         return undefined;
@@ -114,11 +22,10 @@ export function boundedRuleSuggestions(raw, opts = {}) {
     const out = [];
     for (const item of raw.slice(0, MAX_RULE_SUGGESTION_SCAN)) {
         if (out.length >= MAX_RULE_SUGGESTIONS)
-            break; // 基数帽扣在**合形之后**
+            break;
         const parsed = RuleSuggestionRawSchema.safeParse(item);
         if (!parsed.success)
-            continue; // 坏的那条丢掉,好的那条照投
-        // 先脱敏、再截 —— 截完必然满足 `RuleSuggestionSchema` 的 `.max()`,于是回读再跑一遍是恒等操作。
+            continue;
         out.push({
             rule: redactSecrets(parsed.data.rule, { observe }).slice(0, MAX_RULE_TEXT_CHARS),
             match: parsed.data.match,
@@ -127,19 +34,6 @@ export function boundedRuleSuggestions(raw, opts = {}) {
     }
     return out.length > 0 ? out : undefined;
 }
-/**
- * `checkpoint.rule_suggestions` 这一格的**回读口**(合并码重扫)。
- *
- * 🔴 为什么不是直接 `parseJson`:本文件的 `parseJson` 是 **strict** flavor(畸形 JSON 文本直接抛),而
- * `listPending` 是 `rows.map(...)` —— 一处抛就中止整只映射 ⇒ **一行**手改坏的 cell 打掉整个租户的运维
- * 队列(`GET /v1/approvals` 500;`/v1/approvals/stream` 落进它的 catch,每 3s 一次静默重试,心跳照常而
- * 队列永远空)。而 {@link boundedRuleSuggestions} 的顶注承诺的是「手改过的行在这里当场落成**无供给**」——
- * 承诺只对「合法 JSON 但错形」成立,对「JSON 文本本身坏了」不成立。这里把两者补齐:坏 cell ⇒ 这一行
- * 这一格缺席,其余行照常读出来。
- *
- * 🔴 **响亮**:F 类兜底(丢的是一格展示/分诊材料,不是判据),按仓内纪律走 `recordFailOpen` —— 登记 tag
- * + 逐次计数 + 逐次探针 + 每进程一次 warn。静默 `catch` 在这条路上正是本仓要消灭的形。
- */
 function readRuleSuggestionsCell(cell) {
     let parsed;
     try {
@@ -151,25 +45,6 @@ function readRuleSuggestionsCell(cell) {
     }
     return boundedRuleSuggestions(parsed, { countRedactions: false });
 }
-/**
- * `checkpoint.risk_descriptor` 这一格的**回读口**(重扫二轮)——与 {@link readRuleSuggestionsCell} 同族同待遇。
- *
- * 🔴 病(红先复现):上一格补了容错,而**同一个 `rows.map`** 里这一格还走 strict `parseJson`。两个后端里
- * 这两列是同一种存储形(`tidb-pool.ts` / `pg-pool.ts` 双方言都是 TEXT),坏法完全同族(运维手改 / 回滚
- * 残留 / 列语义漂)⇒ 坏的若是这一格,`listPending` 照样整只 reject,上一格顶注与 FAIL-OPEN-CENSUS 宣称的
- * 「一行坏 cell 不再打掉整只队列」在「手改过的行」这个真实场景上并不成立。
- *
- * 🔴 **失败方向自证**(能力语义一致性,#157 纪律):这一格在本读面上只有三个**展示/分诊**消费者 ——
- * ① severity 分诊排序(缺席折 0,排在有 descriptor 的行之后)② `shadowedRule` 的读面脱敏 ③ 读面派生的
- * `governanceForced` 徽章。三者**都不是执法判据**:门早已 park,队列只负责把它显示给人;真按
- * `riskDescriptor.shellGateDoctrine` 判的 `active-run-conflict.ts` 读的是 checkpoint blob 的 `get()`,
- * 不经本读面。而 `governanceForced` 的成文语义本就是「缺席 = 没有治理来源的**证据**」(恒不写 `false`),
- * 缺席是保守读法。对照另一支:整只队列 500 时这三样连同**其余所有行**一起消失。⇒ 行级容忍严格优于整只
- * 毒化,不是把保护型判据静默放行。
- *
- * tag **单列不并计**:两格的缺席后果不同(候选=「不再询问」那一格;本格=分诊排序与出身徽章),并计会让
- * 「哪一格在坏」在遥测里读不出来。
- */
 function readRiskDescriptorCell(cell) {
     try {
         return parseJson(cell);
@@ -179,33 +54,17 @@ function readRiskDescriptorCell(cell) {
         return null;
     }
 }
-/** 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 function boundedToolInput(args) {
     if (args === undefined)
         return null;
     const redacted = redactDeep(args);
     const json = JSON.stringify(redacted);
     if (json === undefined)
-        return null; // non-serializable (e.g. a bare function) — nothing to surface
+        return null;
     if (json.length > MAX_TOOL_INPUT_CHARS)
         return { truncated: true, bytes: json.length };
     return redacted;
 }
-/**
- * checkpoint blob → `pendingAction.toolCallId`。
- *
- * 🔴 三态、**不是**两态(真双库实跑抓到的缺陷,2026-08-06):「读不出」与「读出来了、但这条 park 本来就
- * 没有 toolCallId」是两件事,压成同一个 `undefined` 会把每一条 `plan_review`/`task_done`/`resource_limit`
- * 腿(core 的 `PendingAction` 联合里三个成员结构上就没有 toolCallId)都误报成坏行。前者应标 `unparseable`
- * 交给收敛器当「不确定」,后者是**确定的不匹配**——干净地不是候选。
- *  - `{ readable: false }`        —— JSON 坏 / 形状根本不是对象:真的读不出。
- *  - `{ readable: true, toolCallId: null }` —— 读出来了,这条 park 无工具动作:确定不匹配。
- *  - `{ readable: true, toolCallId: "…" }`  —— 读出来了,拿去比。
- *
- * 逐层 `typeof` 收窄,不做裸 `as` 断言:blob 是持久层读回来的 `unknown`,是信任边界(宪法 [2704])。
- */
 function pendingActionToolCallId(blob) {
     let parsed;
     try {
@@ -216,15 +75,12 @@ function pendingActionToolCallId(blob) {
     }
     if (typeof parsed !== "object" || parsed === null)
         return { readable: false };
-    // 🔴 `sourceTaskId` 是 checkpoint 的**顶层**字段(不在 pendingAction 里),没有对应的列 ⇒ 只能从
-    // blob 读。它是和解三元组的第一维(#168 件1);形不合(有这个键但不是字符串)= 结构漂移,按本函数
-    // 一贯的收窄纪律判 `readable: false`,不静默折成缺席。
     const rawSource = "sourceTaskId" in parsed ? parsed.sourceTaskId : null;
     if (rawSource !== null && rawSource !== undefined && typeof rawSource !== "string")
         return { readable: false };
     const sourceTaskId = typeof rawSource === "string" ? rawSource : null;
     if (!("pendingAction" in parsed))
-        return { readable: true, toolCallId: null, boundInputHash: null, kind: null, sourceTaskId }; // 无 pendingAction 的 park:确定不匹配
+        return { readable: true, toolCallId: null, boundInputHash: null, kind: null, sourceTaskId };
     const pa = parsed.pendingAction;
     if (typeof pa !== "object" || pa === null)
         return { readable: false };
@@ -232,17 +88,12 @@ function pendingActionToolCallId(blob) {
     if (kind !== null && typeof kind !== "string")
         return { readable: false };
     if (!("toolCallId" in pa))
-        return { readable: true, toolCallId: null, boundInputHash: null, kind, sourceTaskId }; // plan_review / task_done / resource_limit 腿
+        return { readable: true, toolCallId: null, boundInputHash: null, kind, sourceTaskId };
     const id = pa.toolCallId;
     if (typeof id !== "string")
         return { readable: false };
-    // 🔴(属主兜底轮 F1)带 toolCallId 却挂着词表外的 kind = 结构漂移,不是「读得出」——这条 blob 声称
-    // 自己是一次工具审批 park(有 callId)又否认(kind 不是 tool_approval)。让它带着匹配的 callId 混进
-    // 健康候选,等于给「外部改库 / schema 偏斜」开一条错配 PARK 的路。词表判据窄取 "tool_approval":
-    // 其余合法 kind(plan_review 等)在 core 的类型里结构上**没有** toolCallId,走不到这里。
     if (kind !== "tool_approval")
         return { readable: false };
-    // hash 只做逐层收窄,不在这层与列比对(比对是调用处的列/blob 一致性门)。缺席 = null(旧行/无 hash 形)。
     const bih = "boundInputHash" in pa ? pa.boundInputHash : null;
     if (bih !== null && typeof bih !== "string")
         return { readable: false };
@@ -258,8 +109,6 @@ function readActorAssertion(v) {
     const issuer = "issuer" in v ? v.issuer : undefined;
     return { id, hostAsserted, ...(typeof issuer === "string" ? { issuer } : {}) };
 }
-/** 队列化之前的**裸单座**形(`{text,trusted}`)—— 旧行原样躺在库里,core 的 `readPendingSteerQueue`
- *  会把它折成 member 0,所以读出来照原样保留、不改写、不迁移。 */
 function readLegacySeat(v) {
     if (typeof v !== "object" || v === null)
         return undefined;
@@ -269,8 +118,6 @@ function readLegacySeat(v) {
         return undefined;
     return { text, trusted };
 }
-/** 队列条目的逐层窄读(持久层读回的是 `unknown`,是信任边界 —— 禁裸 `as`)。四个必备键任一不合形 ⇒
- *  整条不认(返回 undefined,由调用方判 lossy);`actor`/`priority` 可选,不合形即缺席。 */
 function readQueueEntry(v) {
     if (typeof v !== "object" || v === null)
         return undefined;
@@ -295,14 +142,6 @@ function readQueueEntry(v) {
         ...(priority === "now" || priority === "next" || priority === "later" ? { priority } : {}),
     };
 }
-/**
- * 两个 steering 列 → `{pendingSteer?, pendingSteerQueue?}`(= core `appendPendingSteer`/`readPendingSteerQueue`
- * 的入参形)。**两列各管一形**,不是一列两形:
- *  · `pending_steer`(旧列,本服务只读不写)—— 裸单座 `{text, trusted}`。来源有二:队列化之前的存量行,
- *    以及**滚动升级窗里仍在跑的旧副本**写下的座。core 的 `readPendingSteerQueue` 把它折成 member 0。
- *  · `pending_steer_queue`(新列)—— `PendingSteerEntry[]`。
- * 任一列有内容却读不出 ⇒ `lossy`(两个调用点对它的处置见 {@link SteerColumnRead})。
- */
 export function readPendingSteerColumns(seatRaw, queueRaw) {
     let lossy = false;
     const parse = (raw) => {
@@ -343,97 +182,31 @@ export function readPendingSteerColumns(seatRaw, queueRaw) {
         lossy,
     };
 }
-/** 读-改-写的 CAS 重试上限。队列本身只有 `MAX_PENDING_STEER_ENTRIES`(= 3)个位子,再多就 fail-loud,
- *  所以真实争用者数量天然很小;给足冗余后仍然全败 ⇒ 是异常,必须 fail-loud(见 setPendingSteer 尾注)。 */
 const STEER_CAS_ATTEMPTS = 8;
-/** Dual-dialect durable CheckpointStore. See the file header for the dialect-delta ledger. */
 export class SqlCheckpointStore {
     db;
     logger;
-    /** #270 车1:托管留存声明。读法与「为什么 SQL 店答 managed 而三方法的实现体在 `retention-store-sql.ts`」
-     *  逐字见 {@link MANAGED_RETENTION}(本店的 `checkpoint`/`checkpoint_ctx` 两表由那只聚合店按期清)。 */
     retention = MANAGED_RETENTION;
-    /**
-     * `CheckpointStore.durability` 声明(#167 欠账,#168 件5)—— 行落在 MySQL-protocol / PostgreSQL 的
-     * `checkpoint` 表里,进程重启、副本轮换、整机重建都不丢 ⇒ `"durable"`,如实。
-     *
-     * 🔴 为什么这一格空着是有代价的:core 的 `resolveDeclaredDurability` 把**缺席**折成 `"process-local"`
-     * (它不能替一个没表态的店猜),于是静态装配面对每一个真持久部署都读出 `process_local`,
-     * `GET /v1/diagnostics/wiring` 的 park 车道读数与启动自检的那条警告都因此不可信 —— 而 park 正是流内
-     * 审批协议的降级目的地,「重启后还赎不赎得回」是运维必须能一眼看见的事。声明是店自己的责任,不是
-     * 消费侧靠 backend.kind 猜出来的。
-     */
     durability = "durable";
-    /**
-     * `CheckpointStore.fidelity` 声明(core 5.17.0 [3052] 提货批 #172)——**如实按介质判**:本店把整个
-     * checkpoint 经 {@link SqlCheckpointStore.json} 编码进一个 JSON 列(TiDB 逐字文本 / PG lossless
-     * `::jsonb` 协议信封),读侧 `parseJson` 还原 ⇒ 能扛过 round-trip 的只有 JSON 值域,`"json"`。
-     *
-     * 🔴 为什么必须显式写、哪怕缺席也折向 json:core 的 `resolveDeclaredFidelity` 对缺席是 fail-closed
-     * (读 json),所以沉默不会立刻错——但沉默**表达不出**「我核对过我的介质就是这个宽度」。park 铸行
-     * 的 args / preview / 风险描述 / `boundInputHash` 全部从这一格算出的投影铸;哪天这四行编码里任何
-     * 一处改了介质(换存储格式、换列类型),声明在场才有东西可以红,沉默那格只会安静地按错宽度铸出
-     * 一份「审批人看到的 ≠ 盘上躺着的 ≠ resume 执行的」。同 `durability` 的 #168 件5 教训:表态是店
-     * 自己的责任,不是消费侧靠 backend.kind 猜。
-     *
-     * ⚠️ **已知残余(不是遮掩,是这两个词表达不了的那一格)**:PG 臂比 `"json"` 字面**略窄** ——
-     * {@link pgProtocolJsonStringify} 对含 NUL / lone surrogate 的串 fail-loud 拒绝(R4-H1 有意裁定:
-     * 复核面必须与真执行的 args 在 NUL 那一位上一致,「悄悄清洗再存」是不可接受的那一支),而 core 的
-     * json 宽度收下这些码位。`StoreFidelity` 的闭集只有 `"structured-clone" | "json"`,没有第三个词能说
-     * 「json 减去本介质存不下的码位」——声明 `"structured-clone"` 是大得多的谎,所以 `"json"` 仍是两者
-     * 里唯一诚实的选择。后果有界且 fail-closed:core 5.17.0 起 park 铸行失败会把 cause 带到 gate、追加
-     * 到 fallback 的 deny 上,这条 args 退回**同步门**由人判(不静默漏批、不挂死)。边界钉在
-     * `wiring-governance-operator.test.ts` 的 #172 组;已上报上游求一个能表达该宽度的词。
-     */
     fidelity = "json";
-    /**
-     * `CheckpointStore.redecision` 声明(core 5.22.0 F-012 L2/L3;[3342] clay 裁放行)——**如实按能力判**:
-     * 本店的 {@link SqlCheckpointStore.reopen} 是真 CAS 实现(`resolved`→`pending` 原子翻回 + `reopen_reason`
-     * 权威列,design/80 D-1 的两条重开腿都走它),声明 `reopen: true` 是读数不是抬举。core 的沙箱准入
-     * 模式(pre-flight 要求 `redecision.reopen === true`,declaration never duck-typing——方法在场不算数)
-     * 由这一格武装:Kata 腿(`capabilities.isolation` 真声明)+ durable park 部署下,`sandbox_local` ask
-     * 自动放行并以 `permission.sandbox_admitted` durable 事件披露(缺席披露=core 侧变异恰红)。
-     * `validatingLease` **不声明**:本店没有 durable validating-lease 纪律,不承诺没有的东西。
-     * 翻向钉:`wiring-governance-operator.test.ts`(修前恰红,与本声明同 commit)。
-     */
     redecision = { reopen: true };
     constructor(db, logger) {
         this.db = db;
         this.logger = logger;
     }
-    /** Pick the dialect's SQL text. Both statements stay written out at the call site ON PURPOSE. */
     q(tidb, pg) {
         return this.db.dialect === "tidb" ? tidb : pg;
     }
-    /** JSON column binding. TiDB: plain `JSON.stringify`, stored verbatim. PG: `pgProtocolJsonStringify` —
-     *  ordinary `JSON.stringify` that **refuses** (throws `PgUnstorableError`) when the value carries a code
-     *  point PG cannot hold (NUL / lone surrogate); the `::jsonb` at the call site is just the bind cast, not
-     *  an escaping layer.
-     *
-     *  "LOSSLESS" in R4-H1 means exactly **"never silently lossy"**, not "encodes everything": the contrast is
-     *  with `pgSanitizeText`, the lossy U+FFFD-scarring path used for CONTENT faces. An approval row is not a
-     *  content face — the operator's review surface has to agree with the executed args AT the NUL position, so
-     *  scrubbing the byte and storing the scrubbed row is the unacceptable arm; refusing loudly is the chosen one.
-     *  That refusal is why {@link SqlCheckpointStore.fidelity} carries a documented residual (see it). */
     json(value, label) {
         return dialectProtocolJsonEncoder(this.db.dialect)(value, label);
     }
-    /** 判据属主 = `sql-errors.ts`(A-032 P1-①;旧形 tidb 臂只认 errno ⇒ 只带 `code` 的 dup 会把
-     *  `checkpoint.already_exists` 这条 typed 契约错误退化成裸驱动对象上抛)。 */
     isDupKey(e) {
         return isDupKeyError(this.db.dialect, e);
     }
-    /** Create-once. core mints the token (`mintCheckpointToken`) and calls this during suspend. */
     async put(token, cp) {
         const pa = cp.pendingAction;
-        const version = checkpointVersionOf(cp); // core helper: cp.version ?? 0 (1.67/1.68-era no-field = legacy 0)
-        // Persist the (redacted, bounded) tool args alongside so the operator queue can serve the approval-card
-        // payload without an N+1 trace.turns fetch. Stored as a stringified JSON column value.
+        const version = checkpointVersionOf(cp);
         const toolInput = boundedToolInput(pa?.args);
-        // [3684]②:归因键之一——core 挂在 pendingAction 上的规则候选,**在 mint 这一刻**落成自己的列。
-        // 为什么是列而不是 listPending 里现拆 blob:`checkpoint` 列是整只 suspend 快照(会话状态全在里面),
-        // 运维队列每行拖一份那个 blob 是数量级错误的读放大;同行的 `tool_input`/`bound_input_hash`/`gate_kind`/
-        // `risk_descriptor` 四列都是同一条「铸行时反范式一格,读口零 blob」的先例。
         const ruleSuggestions = boundedRuleSuggestions(pa?.ruleSuggestions);
         try {
             await this.db.query(this.q("INSERT INTO checkpoint (token, scope, session_id, version, status, tool_name, tool_call_id, tool_input, checkpoint, deadline, created_at_ms, terminal_at_ms, gate_kind, bound_input_hash, risk_descriptor, rule_suggestions) " +
@@ -449,16 +222,15 @@ export class SqlCheckpointStore {
                 this.json(cp, "checkpoint"),
                 cp.deadline ?? null,
                 cp.createdAt,
-                Math.max(cp.createdAt + TERMINAL_BACKSTOP_MS, (cp.deadline ?? 0) + TERMINAL_GRACE_MS), // D-1 §3 inv#3 backstop — STRICTLY after any SLA deadline (grace) so the terminal_at_ms-branch never races the D-D deny-sweep, and never pre-empts an operator's longer TTL
-                cp.gate?.kind ?? null, // D-D SLA split: human/irreversible_ask deadline → resolve-deny; others → expire
-                pa?.boundInputHash ?? null, // D-1: the opaque hash the portal must echo on /decide (surfaced via listPending so the TOCTOU binding is reachable)
-                ((g) => (g?.riskDescriptor ? this.json(g.riskDescriptor, "risk descriptor") : null))(cp.gate), // riskDescriptor inbox: stamp core's INERT descriptor for triage-sort
-                ruleSuggestions === undefined ? null : this.json(ruleSuggestions, "rule suggestions"), // [3684]②:无供给 ⇒ 列 NULL(读口据它省键,绝不铸 [])
+                Math.max(cp.createdAt + TERMINAL_BACKSTOP_MS, (cp.deadline ?? 0) + TERMINAL_GRACE_MS),
+                cp.gate?.kind ?? null,
+                pa?.boundInputHash ?? null,
+                ((g) => (g?.riskDescriptor ? this.json(g.riskDescriptor, "risk descriptor") : null))(cp.gate),
+                ruleSuggestions === undefined ? null : this.json(ruleSuggestions, "rule suggestions"),
             ]);
         }
         catch (e) {
             if (this.isDupKey(e)) {
-                // a reused token would clobber a live suspension — never a silent overwrite (checkpoint-store contract)
                 throw new CheckpointError("checkpoint.already_exists", `checkpoint token already exists`);
             }
             throw e;
@@ -469,41 +241,19 @@ export class SqlCheckpointStore {
         const r = rows[0];
         if (!r)
             return null;
-        // Forward-compat guard: never hand a too-new checkpoint to a resume that can't
-        // parse it. Compare with `<= MAX` (never `=== CURRENT`) using core's exported constant so this
-        // stays aligned when core bumps the format. This durable-store get-path is the STRONGEST guard (protects a
-        // worker that doesn't check version itself); core's resume has a second pre-CAS guard.
         const version = Number(r.version);
         if (version > MAX_SUPPORTED_CHECKPOINT_VERSION) {
             throw new Error(`checkpoint format version ${version} is newer than this build supports (max ${MAX_SUPPORTED_CHECKPOINT_VERSION}) — upgrade the service to resume it`);
         }
         const cp = parseJson(r.checkpoint);
-        // the COLUMN status is authoritative (resolve/reap update it, not the blob) — reflect it on the returned cp.
         cp.status = r.status;
-        // design/80 D-1: surface the reopen-by-reason + OCC fields off the AUTHORITATIVE columns (the blob is the
-        // suspend-time snapshot; resolve/reopen mutate only the columns). Core's resume reads these to validate an
-        // env_failed re-resume against the persisted winner, and to require the `rev` it observed is still live (OCC).
-        // resolvedOutcome is DERIVED from the stored full outcome by core's `winnerFromOutcome`, so it is preserved
-        // across a reopen for free (reopen leaves `outcome` untouched). Do NOT read a key list into this line: the
-        // derived shape is core's and it GROWS (`answer` since 5.7.0, `reason` since 5.16.0 — the operator's deny
-        // note IS persisted; an older copy of this comment enumerated only {boundCallId,decision,updatedInput?} and
-        // read as if it weren't). We store the whole outcome blob and round-trip it, so additive keys ride for free
-        // — `ResolvedOutcome` in core's `checkpoint-store.d.ts` is the single owner of that list.
         const outcomeRaw = parseJson(r.outcome);
         if (outcomeRaw)
             cp.resolvedOutcome = winnerFromOutcome(outcomeRaw);
         cp.reopenReason = r.reopen_reason ?? undefined;
-        cp.rev = r.rev == null ? 0 : Number(r.rev); // legacy/pre-migration rows ⇒ 0 (the .d.ts "Absent ⇒ legacy 0")
-        // design/80 D-A: overlay the parked steer off the AUTHORITATIVE column (set by setPendingSteer AFTER the
-        // suspend-time blob was written) so core injects it on resume. The blob never carries it.
-        // core 5.14.0(#147):列现在承载**两个**字段 —— 队列本体 + 旧行折下来的裸单座。两者都要盖上去,
-        // core 的 `readPendingSteerQueue` 才能把「legacy 座 = member 0,其余按 seq」拼成完整投递序。
-        // 🔴 坏列在这里**只丢 steer、不抛**:resume 是这条挂起的 run 唯一的出路,为一条读不出的转向把整条
-        // run 变成不可 resume 是错误的失败方向(写侧相反,见 setPendingSteer)。
+        cp.rev = r.rev == null ? 0 : Number(r.rev);
         const steer = readPendingSteerColumns(r.pending_steer, r.pending_steer_queue);
         if (steer.lossy) {
-            // 「静默」到此为止:读不出的部分确实丢了(投递腿不能为一条坏列把整条 run 变成不可 resume),
-            // 但它必须**留痕** —— 丢的是操作员指令,而 #147 的全部意义就是这类丢失不许无声。
             this.logger?.info?.("checkpoint_pending_steer_unreadable", { tokenFp: tokenFingerprint(token) });
         }
         if (cp.state) {
@@ -512,11 +262,8 @@ export class SqlCheckpointStore {
             if (steer.state.pendingSteerQueue !== undefined)
                 cp.state.pendingSteerQueue = steer.state.pendingSteerQueue;
         }
-        // Diagnostic: log what the REAL runner.resume store.get returns for the remote
-        // workspaceHandle (the isolated round-trip test can't prove the real-path get). undefined here ⇒ store/get
-        // drops it; present ⇒ core's 910→614 threading drops it. Cheap, on the resume read-path only.
         this.logger?.info?.("checkpoint_get", {
-            tokenFp: tokenFingerprint(token), // NEVER the raw token — it is the resume credential (token-as-auth)
+            tokenFp: tokenFingerprint(token),
             status: cp.status,
             version,
             hasWorkspaceHandle: !!cp.state?.workspaceHandle,
@@ -524,25 +271,6 @@ export class SqlCheckpointStore {
         });
         return cp;
     }
-    /**
-     * Atomic CAS: pending → resolved, scoped. Returns true for the single winner, false if already
-     * resolved/expired (AlreadyResolved → caller no-ops, never re-executes). `outcome` is persisted atomically
-     * with the flip (R20 #1 — a future v2 resumable-resume can recover a crash-after-CAS; v1 runner write-only).
-     *
-     * design/80 D-1 (atomicity): the winner-persist (the full `outcome` is stored; the winner
-     * {boundCallId,decision,updatedInput?} is derived from it on read) + the `rev` bump happen ATOMICALLY in the
-     * SAME UPDATE as the pending→resolved CAS — one statement, no get→write window. When the caller passes the
-     * `rev` it observed at get() (ResolveExpectation), the CAS additionally requires the LIVE rev to still equal
-     * it: ANY intervening resolve/reopen cycle bumps rev, so a cycle in the get→resolve window loses the CAS
-     * (returns false → core re-inspects → checkpoint.reopened_concurrently). Omitting `expect` keeps the legacy
-     * unconditional CAS (a first resume of a never-reopened checkpoint is unconstrained by rev).
-     * 🔴 reopen_reason = NULL on a winning resolve — parity with the core reference InMemoryCheckpointStore
-     * (MINOR-12: "a freshly-resolved row carries no stale reopen reason"). Without this, an env_failed reopen
-     * followed by a correct winner-replay resolve leaves reopen_reason='env_failed' stale on the now-resolved
-     * row; a later DUPLICATE resume of that token would hit core's pre-CAS env_failed winner-replay guard
-     * against the stale reason and throw checkpoint.reopen_revote (which the service classifies RETRIABLE →
-     * re-parks the run suspended) instead of the terminal checkpoint.already_resolved — stranding the run.
-     */
     async resolve(token, scope, outcome, expect) {
         const params = [this.json(outcome, "checkpoint outcome"), Date.now(), token, scope];
         if (expect)
@@ -552,147 +280,56 @@ export class SqlCheckpointStore {
             (expect ? " AND rev = $5" : "")), params);
         return res.affected === 1;
     }
-    /**
-     * Inverse of `resolve` (core `CheckpointStore.reopen`): CAS `resolved → pending`. Returns the CAS winner
-     * (true = was resolved → now pending again). Compensates a post-CAS env-restore failure
-     * (`resume.env_failed`): `resumeStream` consumes the checkpoint BEFORE `resumeVM`, so a restore failure
-     * would otherwise strand the suspended work as `resolved` + unfindable (`findPendingTokenBySession` only
-     * matches `pending`). Reopening lets a retry re-resume the SAME work.
-     *
-     * design/80 D-1 (reopen-by-reason): the `reason` distinguishes the two triggers (both fire at core's
-     * runtask.ts) so the re-resume can validate per reason (§3 inv #1) — `env_failed` = the action is still
-     * valid, the re-resume MUST replay the persisted winner (core rejects a different decision with
-     * `checkpoint.reopen_revote`); `tool_unavailable` = the action could not run and may now be stale, so a
-     * FRESH decision is allowed (P-7). We RECORD the reason on the row and bump `rev` (so a concurrent resume's
-     * resolve CAS loses — atomicity). 🔴 We DELIBERATELY leave the persisted `outcome` UNTOUCHED (NOT stale junk
-     * as a pre-D-1 reopen treated it): `resolvedOutcome` derives from it on get(), and an `env_failed` re-resume
-     * is validated against it — clearing it would defeat the winner-replay invariant.
-     */
     async reopen(token, scope, reason) {
         const res = await this.db.query(this.q("UPDATE checkpoint SET status = 'pending', reopen_reason = ?, rev = rev + 1 WHERE token = ? AND scope = ? AND status = 'resolved'", "UPDATE checkpoint SET status = 'pending', reopen_reason = $1, rev = rev + 1 WHERE token = $2 AND scope = $3 AND status = 'resolved'"), [reason, token, scope]);
         return res.affected === 1;
     }
-    /**
-     * design/80 D-A (durable steering) —— **core 5.14.0(#147 BREAKING)起是「追加进一条有界有序队列」**,
-     * 不再是「盖掉单座」。两个人同时给一条挂起的 run 转向,旧语义会让第二条**静默销毁**第一条(一条没人
-     * 知道丢了的操作员指令);新语义是两条都在,resume 按 `seq` 全数投递。
-     *
-     * 语义与边界**全部铸在 core**,本 store 一个都不自铸(契约原文:`appendPendingSteer` is "the shared
-     * append every backend must build its next queue with: bounds + `seq` mint live there, not once per store"):
-     *  · `validatePendingSteer` —— 每个 impl 内部必跑的 fail-closed 不变式(M2,接入审计 2026-07-08):内容
-     *    越狱/控制字符 `steering.invalid_content`;**未知字段现在是 REFUSE 而不是丢弃**(领先一个版本的
-     *    producer 必须知道自己的新字段活不过这条挂起的腿);缺席的 `inputId` 在这里铸(uuidv7)。
-     *  · `appendPendingSteer` —— 铸 `seq`、判 `inputId` 幂等(同 id 同载荷 = no-op 返回 true;同 id **不同**
-     *    载荷 = `steering.duplicate_input_id`,吞掉它就等于把队列要消灭的那种静默丢失原样请回来)、
-     *    执行两条上界(条数 + 48000 字节整信封),越界一律 `steering.queue_full` fail-loud,**绝不驱逐**
-     *    一条已被接受的指令。
-     *
-     * 🔴 从「一条无条件 UPDATE」变成「读-改-写」,中间那道窗必须自己有 CAS:两个并发 steer 读到同一份
-     * 队列、后写者整个盖掉前者 —— 就是 #147 要消灭的静默丢失换了个位置复发。守卫是 `pending_steer_rev`
-     * **专用整数列**(不是拿旧列值比:整数按构造唯一,而长 JSON 文本的相等性取决于排序规则/字段序/空白与
-     * 转义形,任一处判等松一点就是一次 CAS 假命中 = 悄悄丢一条 steer。#192 A11 更正:本注原先的理由写的是
-     * "本表无显式 COLLATE,*_ci 会把只差大小写的两份信封判等",那半已不成立——`checkpoint` 现在钉了
-     * `COLLATE utf8mb4_bin`/PG 侧 `COLLATE "C"`;结论不变,理由回到上面那条更根本的;
-     * 也不是复用 resolve 的 `rev`:bump 它会让并发 resume 的 `resolve(expect)` 白白落败)。
-     * CAS 输了就重读重算(队列只有 3 个位子,争用者天然极少);给足冗余仍全败 ⇒ **抛**,不返回 false ——
-     * `false` 在调用方的语义是「没有 pending 行可转向」(HTTP 409「已不再挂起」),把争用报成那个是撒谎。
-     *
-     * 返回:`true` = 落在一条活的 pending 行上(含幂等重放);`false` = 没有该 (token,scope) 的 pending 行。
-     */
     async setPendingSteer(token, scope, steer) {
-        const clean = validatePendingSteer(steer); // throws CheckpointError(steering.invalid_content) — per-impl 一致拒绝
+        const clean = validatePendingSteer(steer);
         for (let attempt = 0; attempt < STEER_CAS_ATTEMPTS; attempt++) {
             const { rows } = await this.db.query(this.q("SELECT status, pending_steer, pending_steer_queue, pending_steer_rev FROM checkpoint WHERE token = ? AND scope = ?", "SELECT status, pending_steer, pending_steer_queue, pending_steer_rev FROM checkpoint WHERE token = $1 AND scope = $2"), [token, scope]);
             const row = rows[0];
             if (!row || row.status !== "pending")
-                return false; // 没有活的 pending 行(与旧的 CAS 落空同义)
+                return false;
             const read = readPendingSteerColumns(row.pending_steer, row.pending_steer_queue);
             if (read.lossy) {
-                // 🔴 写侧与 get() 的失败方向刻意相反:往一份读不全的队列上追加,写回时就会把读不出的那部分
-                // **永久抹掉** —— 那正是 #147 存在的理由(静默丢一条已 park 的操作员指令)。宁可这一次转向失败。
                 throw new Error(`the parked steering queue on checkpoint ${tokenFingerprint(token)} is unreadable — refusing to append onto it ` +
                     `(appending would silently drop the entries this build cannot parse)`);
             }
             const before = read.state.pendingSteerQueue?.length ?? 0;
-            const next = appendPendingSteer(read.state, clean); // throws steering.queue_full / steering.duplicate_input_id
-            // 幂等重放(同 inputId 同载荷):core 原样奉还既有队列 ⇒ 一个字都不用写,也不必烧一个 rev。
+            const next = appendPendingSteer(read.state, clean);
             if (next.length === before)
                 return true;
             const rev = Number(row.pending_steer_rev ?? 0);
-            // 🔴 只写队列列 —— `pending_steer`(旧单座列)本服务**从不写**:滚动升级窗里旧副本对那一列是无条件
-            // 覆盖写,两边写同一列 = 互相清零(codex 复审 F3)。分列之后旧副本的座与新队列共存,读侧合并。
             const res = await this.db.query(this.q("UPDATE checkpoint SET pending_steer_queue = ?, pending_steer_rev = pending_steer_rev + 1 " +
                 "WHERE token = ? AND scope = ? AND status = 'pending' AND pending_steer_rev = ?", "UPDATE checkpoint SET pending_steer_queue = $1, pending_steer_rev = pending_steer_rev + 1 " +
                 "WHERE token = $2 AND scope = $3 AND status = 'pending' AND pending_steer_rev = $4"), [this.json(next, "pending steer queue"), token, scope, rev]);
             if (res.affected > 0)
                 return true;
-            // CAS 输了:另一个 steer 抢先追加(或这行刚被 resolve/expire)⇒ 重读重算。下一轮的 SELECT 会
-            // 分辨这两种情形:行还 pending 就再追加一次,不 pending 就返回 false。
         }
         throw new Error(`setPendingSteer lost the pending_steer_rev CAS ${STEER_CAS_ATTEMPTS} times on checkpoint ${tokenFingerprint(token)} — ` +
             `refusing to report it as "no pending checkpoint" (that would silently discard an operator instruction)`);
     }
-    /**
-     * CAS-expire a SINGLE checkpoint by token (core 1.71 `CheckpointStore.expire`, for `TaskStream.destroy`'s
-     * suspended-worker reap — core [R33] {delta}). `pending → expired`, returns the CAS winner (true = we
-     * expired it; false = already resolved/expired). Same UPDATE as `reap`, keyed by **token** not deadline.
-     * It races the SAME `pending` row as `resolve`, so the two are mutually exclusive: destroy() must `expire`
-     * (fence) BEFORE destroying the env — if a concurrent resume already won `resolve`, expire returns false and
-     * destroy leaves the env for that resume; if expire wins, the resume's resolve fails → never resume-to-dead-env.
-     * Uses `expired` (not a `resolve`-deny) so a CANCELLED checkpoint never pollutes resolved-count / outcome.
-     */
     async expire(token, scope) {
         const res = await this.db.query(this.q("UPDATE checkpoint SET status = 'expired', decided_at_ms = ? WHERE token = ? AND scope = ? AND status = 'pending'", "UPDATE checkpoint SET status = 'expired', decided_at_ms = $1 WHERE token = $2 AND scope = $3 AND status = 'pending'"), [Date.now(), token, scope]);
         return res.affected === 1;
     }
-    /** Interface reap: CAS-expire pending checkpoints in `scope` past `cutoff`. Returns count. */
     async reap(scope, cutoff) {
         const res = await this.db.query(this.q("UPDATE checkpoint SET status = 'expired', decided_at_ms = ? WHERE scope = ? AND status = 'pending' AND deadline IS NOT NULL AND deadline <= ?", "UPDATE checkpoint SET status = 'expired', decided_at_ms = $1 WHERE scope = $2 AND status = 'pending' AND deadline IS NOT NULL AND deadline <= $3"), [Date.now(), scope, cutoff]);
         return res.affected;
     }
-    /**
-     * GLOBAL sweep for the service's per-replica TTL reaper (expiry isn't tenant-
-     * sensitive — only `resolve` is scoped). Idempotent across replicas (DB serializes; no election). Returns count.
-     * Called with `cutoff = Date.now()` (deadline/terminal_at_ms are ABSOLUTE epoch-ms), so it expires any pending row
-     * whose per-approval `deadline` OR its design/80 D-1 §3-inv#3 `terminal_at_ms` crash-safe backstop has passed —
-     * the latter closes the forever-leak of a pending row with a NULL `deadline` (no approval TTL was configured).
-     *
-     * design/80 D-D: the deadline-branch EXPIRES (≈ abort) every kind EXCEPT a tool-approval human/irreversible_ask
-     * gate — those are resolve-DENIED gracefully by the SLA deny-sweep (listExpiredApprovalGates →
-     * resumeCheckpoint(deny)), so expiring them here too would race + lose the graceful denial. 🔴 A durable
-     * AskUserQuestion ALSO mints gate.kind='human' (no question-specific kind in core) — but DENYING a question is
-     * incoherent (the model gets a "denied" tool-result, not an answer), so it is carved BACK INTO the expire path
-     * (COALESCE(tool_name,'')='AskUserQuestion') to abort-expire on timeout instead. Legacy rows (gate_kind NULL)
-     * stay on the expire path. The terminal_at_ms-branch is the crash-safe backstop for ANY kind (incl. a human gate
-     * whose deny-resume keeps failing) — it always abort-expires past the absolute cap (which is now STRICTLY after
-     * the deadline, so it never races the deny-sweep at the deadline instant).
-     */
     async reapExpired(cutoff) {
         const res = await this.db.query(this.q("UPDATE checkpoint SET status = 'expired', decided_at_ms = ? " +
             `WHERE status = 'pending' AND ((deadline IS NOT NULL AND deadline <= ? AND (gate_kind IS NULL OR gate_kind NOT IN ${APPROVAL_GATE_KINDS_SQL_IN} OR COALESCE(tool_name,'') = 'AskUserQuestion')) OR (terminal_at_ms IS NOT NULL AND terminal_at_ms <= ?))`, "UPDATE checkpoint SET status = 'expired', decided_at_ms = $1 " +
             `WHERE status = 'pending' AND ((deadline IS NOT NULL AND deadline <= $2 AND (gate_kind IS NULL OR gate_kind NOT IN ${APPROVAL_GATE_KINDS_SQL_IN} OR COALESCE(tool_name,'') = 'AskUserQuestion')) OR (terminal_at_ms IS NOT NULL AND terminal_at_ms <= $3))`), [Date.now(), cutoff, cutoff]);
         return res.affected;
     }
-    /**
-     * design/80 D-D (SLA-timer): the sessions of pending human/irreversible_ask checkpoints past their `deadline`
-     * (the per-approval SLA). The reaper resolve-DENIES each (re-resume with decision=deny → the model continues
-     * with the denial) — graceful, vs the abort that expire() gives resource_limit/needs_review. Excludes legacy
-     * rows (gate_kind NULL — they predate the split and fall through to reapExpired's expire path). LIMIT bounds
-     * the per-tick deny-resume work (each is a model run). Scope is read off the COMMITTED row (invariant #4).
-     * 🔴 EXCLUDES AskUserQuestion gates (which also mint gate.kind='human'): denying a question is incoherent —
-     * the model would get a "denied" tool-result instead of an answer — so a timed-out durable question falls to
-     * reapExpired's abort-expire path instead of this graceful-deny path.
-     */
     async listExpiredApprovalGates(cutoff, limit = 100) {
         const { rows } = await this.db.query(this.q(`SELECT session_id, scope FROM checkpoint WHERE status = 'pending' AND gate_kind IN ${APPROVAL_GATE_KINDS_SQL_IN} ` +
             "AND COALESCE(tool_name,'') <> 'AskUserQuestion' AND deadline IS NOT NULL AND deadline <= ? ORDER BY deadline ASC LIMIT ?", `SELECT session_id, scope FROM checkpoint WHERE status = 'pending' AND gate_kind IN ${APPROVAL_GATE_KINDS_SQL_IN} ` +
             "AND COALESCE(tool_name,'') <> 'AskUserQuestion' AND deadline IS NOT NULL AND deadline <= $1 ORDER BY deadline ASC LIMIT $2"), [cutoff, limit]);
         return rows.map((r) => ({ sessionId: String(r.session_id), scope: String(r.scope) }));
     }
-    // ─────────────────────── operator approval queue (non-secret; token stays internal) ───────────────────────
-    /** Pending checkpoints for the operator queue — NON-secret fields only (never the token). `taskId` is
-     *  joined from task_active (the JOIN KEY to the run/trace — a suspended run KEEPS its
-     *  session claim, so the join is live for every pending row; null only in pathological windows). */
     async listPending(scope) {
         const base = "SELECT c.session_id, c.scope, c.tool_name, c.tool_call_id, c.tool_input, c.bound_input_hash, c.risk_descriptor, c.rule_suggestions, c.created_at_ms, c.deadline, c.gate_kind, ta.task_id " +
             "FROM checkpoint c LEFT JOIN task_active ta ON ta.session_id = c.session_id WHERE c.status='pending'";
@@ -703,60 +340,29 @@ export class SqlCheckpointStore {
             const toolCallId = r.tool_call_id ?? null;
             const boundInputHash = r.bound_input_hash ?? null;
             const gateKind = r.gate_kind ?? null;
-            // [3684]②:回读也走**同一个** `boundedRuleSuggestions`(不是裸 parse 直投)—— 形的属主只有一个,
-            // 手改过的行/未来列语义漂了都在这里当场落成「无供给」而不是把垃圾投上运维队列。列已在 mint 面脱敏,
-            // 这一遍照常脱敏(纵深防御:手改过的行也不许把凭证投上跨租户队列),只是**不计数**
-            // (值幂等但计数不幂等,见该函数 `opts.countRedactions` 顶注)。
             const ruleSuggestions = readRuleSuggestionsCell(r.rule_suggestions);
             return {
                 sessionId: String(r.session_id),
                 scope: String(r.scope),
                 toolName: r.tool_name ?? null,
                 toolCallId,
-                // D-1: boundCallId === the pending tool call id; boundInputHash is the server-minted opaque hash. The
-                // portal echoes BOTH on /decide so the resume binds to the exact action shown (TOCTOU guard reachable).
-                // [1995]②: a park with no tool action (plan_review / resource_limit / task_done — both columns NULL)
-                // OMITS the keys entirely; the wire contract says absent, never `null` (LOCAL twin does the same).
                 ...(toolCallId !== null ? { boundCallId: toolCallId } : {}),
                 ...(boundInputHash !== null ? { boundInputHash } : {}),
-                // [1995]③ additive: the gate kind the row is parked on (NULL only on a pre-`gate_kind` legacy row) —
-                // lets a durable-recovery consumer route plan / tool / resource off this ONE queue.
                 ...(gateKind !== null ? { gateKind } : {}),
                 taskId: r.task_id ?? null,
-                // Both drivers return the JSON column already parsed; null for pre-migration rows. PG 库内恒干净
-                // (拒绝式)——直读即审阅面=执行面。
                 input: r.tool_input ?? null,
                 createdAt: Number(r.created_at_ms),
                 deadline: r.deadline == null ? null : Number(r.deadline),
-                // 重扫二轮:与下一格同族的**容错回读**(strict 形会把一行手改坏的 cell 变成整只队列 500,
-                // 判据与失败方向逐字见 {@link readRiskDescriptorCell} 顶注)。
                 riskDescriptor: readRiskDescriptorCell(r.risk_descriptor),
-                // [3684]②:无供给 ⇒ **省键**(同 boundCallId/gateKind 的 [1995]② 纪律,绝不 null/[])。
                 ...(ruleSuggestions !== undefined ? { ruleSuggestions } : {}),
             };
         });
-        // riskDescriptor inbox: triage-sort by severity DESC (highest-risk asks first), then oldest-first within a
-        // tier. A row with no descriptor (pre-migration / non-gate) sorts to severity 0 (after the descriptored ones).
         return out.sort((a, b) => (b.riskDescriptor?.severity ?? 0) - (a.riskDescriptor?.severity ?? 0) || a.createdAt - b.createdAt);
     }
-    /**
-     * design/80 #2 (scheduler seam, core 1.105): a scope's PENDING checkpoints as lightweight
-     * {@link CheckpointSummary} rows in ONE query — the cross-task triage view a supervisor scheduler needs
-     * (gate kind + risk severity + budget spent + deadline per suspended task), no N+1 `get`s. The projection is
-     * core's shared {@link summarizeCheckpoint} run over the persisted blob (the `checkpoint` column = the same full
-     * {@link Checkpoint} `get()` parses), so this stays byte-identical to core's InMemory/Pg/File impls. Order =
-     * created_at_ms ASC; callers (the inbox/scheduler) sort by severity. The COLUMN `status` is authoritative (the blob
-     * is the suspend-time snapshot), so it overrides the blob's status before the summary is derived.
-     *
-     * LIMIT bounds the fan-out (review w16yqkkxv): a triage view never needs more than a few — 500 is a generous
-     * ceiling that still protects memory/latency if a scope ever accumulates pathologically many pending gates.
-     */
     async listByScope(scope) {
         const { rows } = await this.db.query(this.q("SELECT checkpoint, status FROM checkpoint WHERE status = 'pending' AND scope = ? ORDER BY created_at_ms ASC LIMIT 500", "SELECT checkpoint, status FROM checkpoint WHERE status = 'pending' AND scope = $1 ORDER BY created_at_ms ASC LIMIT 500"), [scope]);
         const out = [];
         for (const r of rows) {
-            // A corrupt/missing blob skips THAT row rather than crashing the whole scheduler view (review w16yqkkxv):
-            // unlike get() (a single-token read where a null blob is a hard error), a bulk triage list must degrade.
             const cp = parseJson(r.checkpoint);
             if (!cp)
                 continue;
@@ -765,52 +371,18 @@ export class SqlCheckpointStore {
         }
         return out;
     }
-    /**
-     * Map a session (the non-secret handle the operator decides by) → its single pending checkpoint token,
-     * INTERNALLY. A suspended session has exactly one pending checkpoint. `scope` is enforced so an operator
-     * can only resolve within its own tenant. Returns null if there is no pending checkpoint for that session/scope.
-     */
     async findPendingTokenBySession(sessionId, scope) {
         const { rows } = scope
             ? await this.db.query(this.q("SELECT token FROM checkpoint WHERE session_id=? AND scope=? AND status='pending' LIMIT 1", "SELECT token FROM checkpoint WHERE session_id=$1 AND scope=$2 AND status='pending' LIMIT 1"), [sessionId, scope])
             : await this.db.query(this.q("SELECT token FROM checkpoint WHERE session_id=? AND status='pending' LIMIT 1", "SELECT token FROM checkpoint WHERE session_id=$1 AND status='pending' LIMIT 1"), [sessionId]);
         return rows[0] ? String(rows[0].token) : null;
     }
-    /**
-     * 🔴 #151 车5 §9 C4 —— 流内审批对账收敛器判据 1 的**窄读口**(店面承载;收敛器本体不在本车)。
-     *
-     * 「这条 PARKING 的 ask 究竟 park 成了哪张 checkpoint?」的唯一读法。为什么不是「按 session 翻历史页」:
-     * 分页宽读会漏匹配,而漏匹配在收敛器那侧的后果是**假阴性 ⇒ 落一条不可逆的 DENIED**。所以这里改成
-     * 谓词精确查——`(scope, session_id, tool_call_id, created_at_ms ≥ sinceMs)` 这组条件下的行数天然极小,
-     * 一次全量返回,结构上没有分页假阴性。
-     *
-     * 三条口径,逐条都是判据:
-     *  - **`scope` 必填**(不是 optional):对账是跨腿读,租户门是读口自己的责任,不靠调用方记得过滤
-     *    (同 `listPendingBySession` 姿势;`resolve`/`reap` 的 scope enforced 同族)。
-     *  - **不按 status 过滤**:已 `resolved`/`expired` 的行照样返回。后到的 resume 会把行翻成 resolved,
-     *    若只看 pending 就会把「park 成功过」这个既成事实读成「没 park 过」⇒ 又是一条假阴性 DENIED
-     *    (对账三约束③)。park 成功是事实,gate 的活性由 `status` 表达,交给收敛器自己判。
-     *  - **单行读不出 ⇒ 标记返回,不抛**:`unparseable` 的行由收敛器视同「不匹配」,一条坏行不许打断整段
-     *    扫描(§8 C-6)。什么算读不出:blob 的 `version` 超出本 build 支持(`get()` 那条前向兼容门在这里
-     *    不能 throw,否则一条超前行会让整个 session 的对账永久卡死)、或 blob JSON 坏。
-     *
-     * 匹配是两段的:`tool_call_id` **列**是 `put()` 从 `pendingAction.toolCallId` 盖下来的权威投影,SQL 谓词
-     * 先按它(或 NULL)收窄;列为 NULL 的行(无工具动作的 park,或列存在之前的旧行)靠解 blob 补判——解得出
-     * 且相等才算候选,解不出就标 `unparseable`。
-     * 🔴 **没有「列命中即零解析」的快路径**(原注写过,已作废,别照它优化):函数体对**每一行**无条件解
-     * blob,原因有二 ——(a) 前向兼容门与 blob 可读性门必须门在**所有**命中路径之前(codex F3 + 确认轮:
-     * 列长得对不代表 blob 读得出,放行一条读不出的行去 `bindBatch` 会把 ask 钉成 PARKED + 一张本进程读不出
-     * 的 resume 坐标,而 PARKED 不可回滚);(b) `#168` 之后 blob 顶层的 `sourceTaskId` 是和解三元组的第一
-     * 维,列命中行结构上也必须解 blob 才拿得到它。
-     */
     async findCheckpointCandidatesForAsk(scope, sessionId, toolCallId, sinceMs) {
         const { rows } = await this.db.query(this.q("SELECT token, status, created_at_ms, tool_call_id, bound_input_hash, version, checkpoint FROM checkpoint " +
             "WHERE scope=? AND session_id=? AND created_at_ms>=? AND (tool_call_id=? OR tool_call_id IS NULL) ORDER BY created_at_ms ASC", "SELECT token, status, created_at_ms, tool_call_id, bound_input_hash, version, checkpoint FROM checkpoint " +
             "WHERE scope=$1 AND session_id=$2 AND created_at_ms>=$3 AND (tool_call_id=$4 OR tool_call_id IS NULL) ORDER BY created_at_ms ASC"), [scope, sessionId, sinceMs, toolCallId]);
         const out = [];
         for (const r of rows) {
-            // `sourceTaskId: null` 是**所有 unparseable 臂的共同底**(读不出的行不许带出一个可用于身份比对的
-            // 值);健康臂在下面用 blob 解出来的值覆盖它。
             const base = {
                 token: String(r.token),
                 status: String(r.status),
@@ -818,67 +390,37 @@ export class SqlCheckpointStore {
                 boundInputHash: r.bound_input_hash == null ? null : String(r.bound_input_hash),
                 sourceTaskId: null,
             };
-            // 🔴 前向兼容门必须在**任何**命中路径之前(codex 复审 F3,2026-08-06 真缺陷):版本超前的行是
-            // `get()` 明确拒读的行,而 `tool_call_id` 列命中与否跟能不能读懂 blob 毫无关系。若让列的快路径
-            // 绕过这道门,收敛器就会把它当健康候选去 `bindBatch` ⇒ ask 被钉成 **PARKED + 一张本进程读不出的
-            // checkpoint 的 resume 坐标**,而 PARKED 不可回滚。判据只能是「宁可不命中,绝不错配」(§8 D-2)。
-            // 门在这里**不抛**(见头注):标 unparseable 交给收敛器当「不确定」,单行不打断整段扫描。
             if (Number(r.version) > MAX_SUPPORTED_CHECKPOINT_VERSION) {
                 out.push({ ...base, boundCallId: null, unparseable: true });
                 continue;
             }
-            // 🔴 blob 可读性同样门在**所有**命中路径之前(codex 确认轮补抓):`tool_call_id` 列长得对,不代表
-            // 这张 checkpoint 读得出来——列是 put() 时的投影,blob 才是 resume 真正要吃的东西。让「列命中」
-            // 跳过可读性检查,等于给「blob 损坏 / schema 偏斜」留了一条与 F3 完全相同的不可逆后果:
-            // 收敛器把 ask 钉成 PARKED + 这张 checkpoint 的坐标,而后续 `get()` 必然失败。
-            // 读口的契约只有一条——**读不出就标记**,没有「有一列长得对就豁免」的例外。
             const derived = pendingActionToolCallId(r.checkpoint);
             if (!derived.readable) {
                 out.push({ ...base, boundCallId: null, unparseable: true });
                 continue;
             }
             const col = r.tool_call_id == null ? null : String(r.tool_call_id);
-            // 列与 blob **互相矛盾** ⇒ 判别不出谁对,标 unparseable(「宁可不命中,绝不错配」,§8 D-2)。
-            // 🔴 矛盾的定义是「列说得出、而 blob 不同意」——同时覆盖两形:blob 给了**别的** callId,以及
-            // blob 说这条 park **根本没有工具动作**(`toolCallId === null`)。后者一样是漂移(列声称有一次
-            // 工具调用、blob 否认),早先只判「两边都非空且不等」会把它漏成健康候选。
-            // 现网 put() 把列与 blob 同源同刻写下,矛盾只可能来自外部改库或 schema 偏斜——正是该保守的场合。
             if (col !== null && col !== derived.toolCallId) {
                 out.push({ ...base, boundCallId: null, unparseable: true });
                 continue;
             }
-            // 🔴 bound_input_hash 的列/blob 一致性门(属主兜底轮 F1)——与上面 toolCallId 的矛盾门同款:
-            // 返回给收敛器的 hash 是「identity ∧ hash 双等」硬谓词的**输入**,列被外部改成漂移值(乃至恰好
-            // 改成另一只 ask 的 hash)时,只信列 = 把双等谓词架空成单等。两边都在场且不等 ⇒ unparseable;
-            // 列 NULL 而 blob 有值 ⇒ 用 blob 值补齐(旧行回落,与 toolCallId 的「列 NULL 回落 blob」同规)。
             if (base.boundInputHash !== null && derived.boundInputHash !== null && base.boundInputHash !== derived.boundInputHash) {
                 out.push({ ...base, boundCallId: null, unparseable: true });
                 continue;
             }
             const effectiveHash = base.boundInputHash ?? derived.boundInputHash;
-            // 列在场时以列为准(权威投影);列为 NULL 的旧行回落用 blob 解出来的值。
             const effective = col ?? derived.toolCallId;
             if (effective === toolCallId)
                 out.push({ ...base, boundInputHash: effectiveHash, sourceTaskId: derived.sourceTaskId, boundCallId: effective });
-            // 解得出、但不是这只 ask 的 callId(或这条 park 本来就没有工具动作)⇒ **确定**不是候选:
-            // 既不返回也不标坏行(标坏行会让收敛器把一条明确的「不匹配」当成「不确定」)。
         }
         return out;
     }
-    /**
-     * The owner SCOPE of a session's pending checkpoint (the multi-tenant key === the owner principal in the
-     * BFF/non-operator flow, the same key listPending filters by). For the /decide owner-gate: a non-operator
-     * caller may only decide a checkpoint in their OWN scope. Returns `undefined` (no pending row), `null`
-     * (anonymous/dev session — open), or the owner scope string.
-     */
     async peekPendingScope(sessionId) {
         const { rows } = await this.db.query(this.q("SELECT scope FROM checkpoint WHERE session_id=? AND status='pending' LIMIT 1", "SELECT scope FROM checkpoint WHERE session_id=$1 AND status='pending' LIMIT 1"), [sessionId]);
         if (!rows[0])
             return undefined;
         return rows[0].scope ?? null;
     }
-    // ─────────────────────── checkpoint_ctx (service rebuild inputs; sessionId-keyed) ───────────────────────
-    /** Upsert the resume rebuild inputs for a session (written at SUBMIT when durable mode is on). */
     async putCtx(sessionId, ctx) {
         await this.db.query(this.q("INSERT INTO checkpoint_ctx (session_id, ctx, updated_at_ms) VALUES (?,?,?) " +
             "ON DUPLICATE KEY UPDATE ctx = VALUES(ctx), updated_at_ms = VALUES(updated_at_ms)", "INSERT INTO checkpoint_ctx (session_id, ctx, updated_at_ms) VALUES ($1,$2::jsonb,$3) " +
@@ -888,17 +430,6 @@ export class SqlCheckpointStore {
         const { rows } = await this.db.query(this.q("SELECT ctx FROM checkpoint_ctx WHERE session_id=?", "SELECT ctx FROM checkpoint_ctx WHERE session_id=$1"), [sessionId]);
         return rows[0] ? parseJson(rows[0].ctx) : null;
     }
-    /**
-     * 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`.
-     *
-     * The extra `task_active` guard closes a multi-gate window: between a resume's CAS (pending→resolved) and
-     * the task hitting its NEXT gate (writing a new pending checkpoint), the session has no pending checkpoint —
-     * yet `putCtx` only stamps `updated_at_ms` at submit, so the ctx could be older than `cutoff` and was being
-     * reaped, making the next resume 409 ("resume context missing"). `task_active` holds the session lock for
-     * the WHOLE submit→last-resume-complete span (running OR suspended), so excluding sessions with an active
-     * claim keeps the ctx exactly as long as a run still needs it, while still GC'ing it once the run is terminal.
-     */
     async reapCtx(cutoff) {
         const res = await this.db.query(this.q("DELETE FROM checkpoint_ctx WHERE updated_at_ms < ? " +
             "AND session_id NOT IN (SELECT session_id FROM checkpoint WHERE status='pending') " +
@@ -907,22 +438,6 @@ export class SqlCheckpointStore {
             "AND session_id NOT IN (SELECT session_id FROM task_active)"), [cutoff]);
         return res.affected;
     }
-    /**
-     * E21 (§0.5 session delete) — purge ALL checkpoint state for one session: the durable checkpoint rows
-     * (suspended-task gates) AND their service-side resume-context rows (checkpoint_ctx). Keyed on the
-     * `session_id` column both tables carry. Idempotent (returns the count of `checkpoint` rows removed).
-     * Unconditional by design: a session being deleted has no resumable future, so any pending gate is moot.
-     *
-     * `owner` is a single-DB-fleet defense-in-depth guard (adversarial-review MEDIUM). Neither table carries an
-     * owner column, so the guard threads through `session_meta.owner` via an EXISTS sub-select (null-safe compare:
-     * `<=>` on TiDB, `IS NOT DISTINCT FROM` on PG). The purge coordinator runs this BEFORE deleting session_meta,
-     * so the meta row (with its authoritative owner) is still present here — a wrong-owner caller's EXISTS fails
-     * and purges nothing. `owner=null` (legacy/dev, never threaded by the route) keeps the historical
-     * unconditional behaviour via the null-safe match.
-     *
-     * 🔴 Placeholder ARITY differs, not just the syntax: `?` cannot be reused, so the TiDB arm binds `sessionId`
-     * TWICE (row key + guard sub-select) while PG reuses `$1`.
-     */
     async deleteBySession(sessionId, owner) {
         const ownerGuard = this.q("EXISTS (SELECT 1 FROM session_meta sm WHERE sm.session_id = ? AND sm.owner <=> ?)", "EXISTS (SELECT 1 FROM session_meta sm WHERE sm.session_id = $1 AND sm.owner IS NOT DISTINCT FROM $2)");
         const params = this.db.dialect === "tidb" ? [sessionId, sessionId, owner] : [sessionId, owner];
@@ -931,13 +446,11 @@ export class SqlCheckpointStore {
         return res.affected;
     }
 }
-/** MySQL-protocol (TiDB) binding — historical class name + ctor shape preserved. */
 export class TiDBCheckpointStore extends SqlCheckpointStore {
     constructor(pool, logger) {
         super(mysqlDriver(pool), logger);
     }
 }
-/** PostgreSQL binding — historical class name + ctor shape preserved. */
 export class PgCheckpointStore extends SqlCheckpointStore {
     constructor(pool, logger) {
         super(pgDriver(pool), logger);