@sema-agent/server 7.4.0 → 7.6.0

package/dist/plugins/approval-ask-store-sql.js

@@ -71,13 +71,46 @@ export const APPROVAL_BATCHES_TABLE = "approval_batches";
  *
  * SCHEMA POLICY 同 `tidb-pool.ts` 头注:纯 CREATE,禁 ALTER 增量 seam,改列直接改这里 + 重建库
  * (`docs/schema/baseline-mysql.sql` 是由这些文本机器录制出的**产物**,永不手改)。
+ *
+ * ── 列宽的**测量依据**(#192 A10;U2 逐列取证在档)──────────────────────────────────────────────────
+ * 本表家族原先一律 VARCHAR(255),是"先建表后想"的产物。按"每列的值到底由谁铸、有没有入口上限"重新裁:
+ *
+ *  收窄(有硬上限背书,证据即上限本身):
+ *   · `ask_id` / `batch_id` / `bound_ask_id` → 64:`deriveAskId`/`deriveBatchId` 恒是 sha256 hex 取前
+ *     64 字符(`approval-ask-machine.ts` deterministicId),按构造不可能更长。
+ *   · `task_id` → 64:入口 `UUIDV7_RE`(`security.ts:134`)只放行 36 字符的规范 uuidv7;与兄弟列
+ *     `task_run.task_id VARCHAR(64)` 同宽(此前 255 是本家族独有的偏离,无依据)。
+ *   · `session_id` → 64:提交入口硬拒 >64(`http/server.ts` "sessionId must be at most 64 characters"),
+ *     与 `session_meta`/`task_run` 同宽。
+ *   · `owner` → 190:`assertPrincipalShape` 的 `PRINCIPAL_MAX_LENGTH = 190`(`security.ts:350`)硬拒更长者;
+ *     全仓每一根 owner/scope 轴都是 190,此前 255 同样是无依据偏离。
+ *   · `gate_token` → 120:它抄的是 checkpoint 的 token(core `mintCheckpointToken` = 16 字节 hex = 32 字符),
+ *     取与**被抄那一列** `checkpoint.token VARCHAR(120)` 同宽 —— 同一个值在两张表上宽度必须一致,
+ *     否则抄的那一步就是一道静默截断。512 是原先的 16 倍冗余。
+ *
+ *  🔑 上面四条收窄之所以**不引入任何新暴露面**,靠的不是入口断言而是一条更硬的事实:同一个 session_id /
+ *     task_id / owner **早就**同时躺在 `session_meta.session_id VARCHAR(64)` / `task_run.task_id VARCHAR(64)` /
+ *     `task_run.owner VARCHAR(190)` 里。任何长到能撑爆本表新宽度的值,在写到那几张**更中心**的表时就已经
+ *     先炸了 —— 本表此前的 255 从来不是一道额外的安全余量,只是一处与全仓不一致的偏离。
+ *     ⇒ 收窄的风险上界 = 0;真正要担心的是反过来:留着 255 会让人误以为这里可以存更长的 id。
+ *
+ *  🔴 **刻意不收窄**(测量结果不支持,记在这里免得下一个人以为是漏了):
+ *   · `source_task_id` / `tool_call_id` / `parent_tool_call_id` / `gate_bound_call_id` —— 这四列的值是
+ *     **模型/引擎铸的原始 id**,服务端在写行这一步**没有任何长度断言**(`approval-card.ts` 的
+ *     `MAX_IDENT` 只裁了给人看的那份 card 投影,不是本列)。没有入口上限就收窄 = 把"存不下"这件事
+ *     推迟到 INSERT 才炸(MySQL 更糟:静默截断),换来的只是几十字节。要收窄,先补入口断言
+ *     (照 `assertPrincipalShape`/`assertIdempotencyKeyShape` 的姿势),那是另一件事。
+ *   · `bound_input_hash` / `gate_bound_input_hash` —— 按约定是 sha256 hex(64),但 `readBoundInputHash`
+ *     只校验"非空字符串",没校长度/字形 ⇒ 同上,先有断言再谈收窄。
+ *   · `idempotency_key` —— 255 **正是**入口断言的上限本身(zod `.max(255)` + 店内 `assertIdempotencyKeyShape`
+ *     双执法),宽度与上限同源,恰好正确,动它反而制造截断面。
  */
 export const TIDB_APPROVAL_ASK_STATEMENTS = [
     `CREATE TABLE IF NOT EXISTS ${APPROVAL_BATCHES_TABLE} (
-    batch_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
+    batch_id VARCHAR(64) NOT NULL,
+    task_id VARCHAR(64) NOT NULL,
     state VARCHAR(32) NOT NULL,
-    bound_ask_id VARCHAR(255) NULL,
+    bound_ask_id VARCHAR(64) NULL,
     version INT NOT NULL DEFAULT 0,
     created_at_ms BIGINT NOT NULL,
     updated_at_ms BIGINT NOT NULL,
@@ -85,12 +118,12 @@ export const TIDB_APPROVAL_ASK_STATEMENTS = [
     KEY idx_batch_task (task_id)
   ) COLLATE utf8mb4_bin`,
     `CREATE TABLE IF NOT EXISTS ${APPROVAL_ASKS_TABLE} (
-    ask_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
+    ask_id VARCHAR(64) NOT NULL,
+    task_id VARCHAR(64) NOT NULL,
     source_task_id VARCHAR(255) NOT NULL,
-    session_id VARCHAR(255) NOT NULL,
-    owner VARCHAR(255) NULL,
-    batch_id VARCHAR(255) NOT NULL,
+    session_id VARCHAR(64) NOT NULL,
+    owner VARCHAR(190) NULL,
+    batch_id VARCHAR(64) NOT NULL,
     tool_call_id VARCHAR(255) NOT NULL,
     -- leg_key: 车3 §3.2′ 身份轴——sha256(resume checkpoint token) 的 hex(64 字符),首腿存空串。
     -- 取代原来的数值 leg 列:一腿一凭据,零 DDL 依赖 task_run、零 markResuming 改动。NOT NULL(空串
@@ -110,7 +143,7 @@ export const TIDB_APPROVAL_ASK_STATEMENTS = [
     decision_note TEXT NULL,
     decided_at_ms BIGINT NULL,
     denied_reason VARCHAR(64) NULL,
-    gate_token VARCHAR(512) NULL,
+    gate_token VARCHAR(120) NULL,
     gate_bound_call_id VARCHAR(255) NULL,
     gate_bound_input_hash VARCHAR(255) NULL,
     idempotency_key VARCHAR(255) NULL,
@@ -141,10 +174,10 @@ export async function ensureTiDBApprovalAskSchema(pool) {
 }
 export async function ensurePgApprovalAskSchema(q) {
     await q(`CREATE TABLE IF NOT EXISTS ${APPROVAL_BATCHES_TABLE} (
-    batch_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
-    state VARCHAR(32) NOT NULL,
-    bound_ask_id VARCHAR(255),
+    batch_id VARCHAR(64) COLLATE "C" NOT NULL,
+    task_id VARCHAR(64) COLLATE "C" NOT NULL,
+    state VARCHAR(32) COLLATE "C" NOT NULL,
+    bound_ask_id VARCHAR(64) COLLATE "C",
     version INT NOT NULL DEFAULT 0,
     created_at_ms BIGINT NOT NULL,
     updated_at_ms BIGINT NOT NULL,
@@ -152,33 +185,33 @@ export async function ensurePgApprovalAskSchema(q) {
   )`);
     await q(`CREATE INDEX IF NOT EXISTS idx_batch_task ON ${APPROVAL_BATCHES_TABLE} (task_id)`);
     await q(`CREATE TABLE IF NOT EXISTS ${APPROVAL_ASKS_TABLE} (
-    ask_id VARCHAR(255) NOT NULL,
-    task_id VARCHAR(255) NOT NULL,
-    source_task_id VARCHAR(255) NOT NULL,
-    session_id VARCHAR(255) NOT NULL,
-    owner VARCHAR(255),
-    batch_id VARCHAR(255) NOT NULL,
-    tool_call_id VARCHAR(255) NOT NULL,
+    ask_id VARCHAR(64) COLLATE "C" NOT NULL,
+    task_id VARCHAR(64) COLLATE "C" NOT NULL,
+    source_task_id VARCHAR(255) COLLATE "C" NOT NULL,
+    session_id VARCHAR(64) COLLATE "C" NOT NULL,
+    owner VARCHAR(190) COLLATE "C",
+    batch_id VARCHAR(64) COLLATE "C" NOT NULL,
+    tool_call_id VARCHAR(255) COLLATE "C" NOT NULL,
     -- leg_key: 车3 §3.2′ 身份轴——sha256(resume checkpoint token) 的 hex(64 字符),首腿存空串
     -- (空串是首腿的真值,不是缺席,故 NOT NULL)。MySQL 侧 twin 逐字同形。
-    leg_key VARCHAR(64) NOT NULL,
-    parent_tool_call_id VARCHAR(255),
+    leg_key VARCHAR(64) COLLATE "C" NOT NULL,
+    parent_tool_call_id VARCHAR(255) COLLATE "C",
     -- bound_input_hash(车5 §9 C2)——MySQL twin 逐字同形(宽度/语义见那侧注)。
-    bound_input_hash VARCHAR(255),
-    state VARCHAR(32) NOT NULL,
+    bound_input_hash VARCHAR(255) COLLATE "C",
+    state VARCHAR(32) COLLATE "C" NOT NULL,
     -- clay 批 TINYINT(1) 归一先例:PG 侧统一 SMALLINT 0/1(此前本家族用过 BOOLEAN,已裁弃).
     provisional SMALLINT NOT NULL DEFAULT 0,
     version INT NOT NULL DEFAULT 0,
-    decision VARCHAR(16),
-    decision_actor TEXT,
-    decision_note TEXT,
+    decision VARCHAR(16) COLLATE "C",
+    decision_actor TEXT COLLATE "C",
+    decision_note TEXT COLLATE "C",
     decided_at_ms BIGINT,
-    denied_reason VARCHAR(64),
-    gate_token VARCHAR(512),
-    gate_bound_call_id VARCHAR(255),
-    gate_bound_input_hash VARCHAR(255),
-    idempotency_key VARCHAR(255),
-    card_json TEXT NOT NULL,
+    denied_reason VARCHAR(64) COLLATE "C",
+    gate_token VARCHAR(120) COLLATE "C",
+    gate_bound_call_id VARCHAR(255) COLLATE "C",
+    gate_bound_input_hash VARCHAR(255) COLLATE "C",
+    idempotency_key VARCHAR(255) COLLATE "C",
+    card_json TEXT COLLATE "C" NOT NULL,
     schema_version INT NOT NULL,
     expires_at_ms BIGINT NOT NULL,
     created_at_ms BIGINT NOT NULL,
@@ -330,13 +363,17 @@ export class SqlApprovalAskStore {
     }
     async ensureAsk(row) {
         const now = row.createdAtMs;
+        /** 本次 ask 插入的 affected 行数(1 = 真插入 / 0 = 幂等命中)——判别位的**唯一**来源,见
+         *  {@link EnsureAskResult}。两方言各自的语句形不同(`INSERT IGNORE` vs `ON CONFLICT DO NOTHING`),
+         *  但 affected 的语义是同一个,`SqlDriver` 已把 mysql2 的 `affectedRows` 与 pg 的 `rowCount` 归一。 */
+        let insertedRows = 0;
         const conn = await this.db.connect();
         try {
             await conn.begin();
             await conn.query(this.q(`INSERT IGNORE INTO ${APPROVAL_BATCHES_TABLE} (batch_id, task_id, state, version, created_at_ms, updated_at_ms) VALUES (?, ?, 'OPEN', 0, ?, ?)`, `INSERT INTO ${APPROVAL_BATCHES_TABLE} (batch_id, task_id, state, version, created_at_ms, updated_at_ms) VALUES ($1, $2, 'OPEN', 0, $3, $4) ON CONFLICT (batch_id) DO NOTHING`), [row.batchId, row.taskId, now, now]);
             // 🔴 `idempotency_key` **不在 INSERT 列清单里**(车4 §12-E 双写者收口):该列已归回决专用,只有
             // `decideAsk` 赢 CAS 时写它,铸行恒 NULL。留在这里的 NULL 字面量就是这条纪律的落笔处。
-            await conn.query(this.q(`INSERT IGNORE INTO ${APPROVAL_ASKS_TABLE} (ask_id, task_id, source_task_id, session_id, owner, batch_id, tool_call_id, leg_key, parent_tool_call_id, bound_input_hash, state, provisional, version, decision, decision_actor, decision_note, decided_at_ms, denied_reason, gate_token, gate_bound_call_id, gate_bound_input_hash, idempotency_key, card_json, schema_version, expires_at_ms, created_at_ms, updated_at_ms) ` +
+            const askInsert = await conn.query(this.q(`INSERT IGNORE INTO ${APPROVAL_ASKS_TABLE} (ask_id, task_id, source_task_id, session_id, owner, batch_id, tool_call_id, leg_key, parent_tool_call_id, bound_input_hash, state, provisional, version, decision, decision_actor, decision_note, decided_at_ms, denied_reason, gate_token, gate_bound_call_id, gate_bound_input_hash, idempotency_key, card_json, schema_version, expires_at_ms, created_at_ms, updated_at_ms) ` +
                 "VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'STREAM_PENDING', 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, ?, ?, ?, ?, ?)", `INSERT INTO ${APPROVAL_ASKS_TABLE} (ask_id, task_id, source_task_id, session_id, owner, batch_id, tool_call_id, leg_key, parent_tool_call_id, bound_input_hash, state, provisional, version, decision, decision_actor, decision_note, decided_at_ms, denied_reason, gate_token, gate_bound_call_id, gate_bound_input_hash, idempotency_key, card_json, schema_version, expires_at_ms, created_at_ms, updated_at_ms) ` +
                 "VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, 'STREAM_PENDING', 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, $11, $12, $13, $14, $15) ON CONFLICT (ask_id) DO NOTHING"), [
                 row.askId,
@@ -355,6 +392,7 @@ export class SqlApprovalAskStore {
                 now,
                 now,
             ]);
+            insertedRows = askInsert.affected;
             await conn.commit();
         }
         catch (err) {
@@ -372,7 +410,9 @@ export class SqlApprovalAskStore {
         const out = await this.getAsk(row.askId);
         if (!out)
             throw new Error(`ensureAsk: row vanished after insert (askId=${row.askId})`);
-        return out;
+        // 判别位取**提交那一刻**引擎报的 affected,不是事后回读推断的:回读发生在提交之后,那时并发的
+        // 第二个调用可能已经改过行,任何「从行上反推谁插的」都是又一次猜。
+        return { row: out, inserted: insertedRows > 0 };
     }
     async transitionAsk(askId, from, to, patch) {
         // machine 层先判(非法转移=编程错误,throw 而非返回 false——设计定稿 §4 原话)。

package/dist/plugins/background-agent-store-sql.js

@@ -163,7 +163,7 @@ export async function ensureTiDBBackgroundAgentSchema(pool) {
     handle VARBINARY(190) NOT NULL,
     scope VARCHAR(190) NOT NULL,
     owner VARCHAR(190) NOT NULL,
-    session_scoped TINYINT NOT NULL,
+    session_scoped TINYINT(1) NOT NULL,
     session_id VARCHAR(190) NULL,
     parent_session_id VARCHAR(190) NULL,
     -- core 1.367 δ(additive):root 锚(listBySession 第二臂;NULL = 该记录无 root 锚,谓词天然拒)
@@ -198,29 +198,29 @@ export async function ensurePgBackgroundAgentSchema(q) {
     await q(`CREATE TABLE IF NOT EXISTS ${BACKGROUND_AGENT_TABLE} (
     scope_key VARCHAR(190) COLLATE "C" NOT NULL,
     handle VARCHAR(190) COLLATE "C" NOT NULL,
-    scope VARCHAR(190) NOT NULL,
-    owner VARCHAR(190) NOT NULL,
+    scope VARCHAR(190) COLLATE "C" NOT NULL,
+    owner VARCHAR(190) COLLATE "C" NOT NULL,
     session_scoped SMALLINT NOT NULL,
-    session_id VARCHAR(190),
-    parent_session_id VARCHAR(190),
+    session_id VARCHAR(190) COLLATE "C",
+    parent_session_id VARCHAR(190) COLLATE "C",
     -- core 1.367 δ(additive,TiDB 同案):root 锚(listBySession 第二臂)
-    root_session_id VARCHAR(190),
-    session_anchor VARCHAR(190),
-    name VARCHAR(255),
-    agent_type VARCHAR(190),
-    status VARCHAR(16) NOT NULL,
+    root_session_id VARCHAR(190) COLLATE "C",
+    session_anchor VARCHAR(190) COLLATE "C",
+    name VARCHAR(255) COLLATE "C",
+    agent_type VARCHAR(190) COLLATE "C",
+    status VARCHAR(16) COLLATE "C" NOT NULL,
     spawned_at_ms BIGINT NOT NULL,
     updated_at_ms BIGINT NOT NULL,
     settled_at_ms BIGINT,
-    usage_json TEXT,
+    usage_json TEXT COLLATE "C",
     rev BIGINT NOT NULL,
     -- core 1.383([1565] / design/153 件3a)ε(TiDB 同案注):updateIf 的 CAS 守卫专用列
-    parked_checkpoint_token VARCHAR(190),
-    park_claim_id VARCHAR(190),
+    parked_checkpoint_token VARCHAR(190) COLLATE "C",
+    park_claim_id VARCHAR(190) COLLATE "C",
     -- core 5.14.0 #22(TiDB 同案注:三态与「写侧投影」口径见 MySQL 孪生的行内注)。
-    admitted_org_scopes TEXT,
-    admitted_org_write_scope VARCHAR(190),
-    record_json TEXT NOT NULL,
+    admitted_org_scopes TEXT COLLATE "C",
+    admitted_org_write_scope VARCHAR(190) COLLATE "C",
+    record_json TEXT COLLATE "C" NOT NULL,
     PRIMARY KEY (scope_key, handle)
   )`);
     await q(`CREATE INDEX IF NOT EXISTS idx_bga_anchor ON ${BACKGROUND_AGENT_TABLE} (scope_key, session_anchor, spawned_at_ms)`);

package/dist/plugins/background-shell-support.d.ts

@@ -11,7 +11,7 @@
  *  - **owned-id isolation** — `poll`/`kill` look the shellId up in THIS manager's registry; an id from another env
  *    (or a forged one) is `not_found`, never resolved against the provider (design/103 §3.8 / interface 越权契约).
  *  - **maxConcurrent** — counts only `running` shells (terminal entries are kept for residual polling but free their
- *    slot, so "KillShell one first" is actionable — matches the TOC `maxConcurrent 终态占槽` review fix).
+ *    slot, so "TaskStop one first" is actionable — matches the TOC `maxConcurrent 终态占槽` review fix).
  *  - **timeout hard wall** — a control-plane timer kills the shell and flips it to `killed` at the bounded BG
  *    timeout (design/103 §3.6); the driver may set an additional provider-level backstop ≥ this wall.
  *  - **dispose** — kills + cleans up EVERY shell, best-effort, MUST NOT throw, idempotent (design/103 §3.7).

package/dist/plugins/background-shell-support.js

@@ -11,7 +11,7 @@
  *  - **owned-id isolation** — `poll`/`kill` look the shellId up in THIS manager's registry; an id from another env
  *    (or a forged one) is `not_found`, never resolved against the provider (design/103 §3.8 / interface 越权契约).
  *  - **maxConcurrent** — counts only `running` shells (terminal entries are kept for residual polling but free their
- *    slot, so "KillShell one first" is actionable — matches the TOC `maxConcurrent 终态占槽` review fix).
+ *    slot, so "TaskStop one first" is actionable — matches the TOC `maxConcurrent 终态占槽` review fix).
  *  - **timeout hard wall** — a control-plane timer kills the shell and flips it to `killed` at the bounded BG
  *    timeout (design/103 §3.6); the driver may set an additional provider-level backstop ≥ this wall.
  *  - **dispose** — kills + cleans up EVERY shell, best-effort, MUST NOT throw, idempotent (design/103 §3.7).
@@ -207,7 +207,7 @@ export class BackgroundShellManager {
     /** The shared spawn/adopt body: limit check, opaque id, terminal-latch buffering, BG-timeout hard wall. */
     async register(launch, timeoutSec) {
         if (this.liveCount() >= this.caps.maxConcurrent) {
-            return fail(new BackgroundShellError("limit_exceeded", `Too many running background shells (max ${this.caps.maxConcurrent}); KillShell one first.`));
+            return fail(new BackgroundShellError("limit_exceeded", `Too many running background shells (max ${this.caps.maxConcurrent}); TaskStop one first.`));
         }
         const bgTimeoutSec = this.boundedBgTimeoutSec(timeoutSec); // #131-T0:与 adoptSync 同座(NaN 当缺席)
         // Opaque brand — NOT derived from the provider job/pid (design/103 §3.8 越权红线).

package/dist/plugins/breaker-state-sql.js

@@ -4,8 +4,8 @@ import { mysqlDriver, pgDriver } from "./sql-driver.js";
  *  centrally in tidb-pool.ts (no PG-side twin needed there — production wires ONE ensureTidbSchema). */
 export const PG_BREAKER_STATE_SCHEMA = [
     `CREATE TABLE IF NOT EXISTS circuit_breaker (
-     breaker_key VARCHAR(190)   NOT NULL,
-     phase       VARCHAR(16)    NOT NULL,
+     breaker_key VARCHAR(190) COLLATE "C"   NOT NULL,
+     phase       VARCHAR(16) COLLATE "C"    NOT NULL,
      failures    INTEGER        NOT NULL DEFAULT 0,
      opened_at   TIMESTAMPTZ(3),
      updated_at  TIMESTAMPTZ(3) NOT NULL,

package/dist/plugins/checkpoint-store-sql.d.ts

@@ -1,6 +1,6 @@
 import type { Pool as MySqlPool } from "mysql2/promise";
 import type { Pool as PgPool } from "pg";
-import { type Checkpoint, type CheckpointGate, type CheckpointState, type CheckpointStore, type CheckpointSummary, type CheckpointToken, type PendingSteerInput, type ResumeOutcome, type ResolveExpectation, type ReopenReason, type RiskDescriptor } from "@sema-agent/core";
+import { type Checkpoint, type CheckpointGate, type CheckpointState, type CheckpointStore, type CheckpointSummary, type CheckpointToken, type PendingSteerInput, type ResumeOutcome, type ResolveExpectation, type ReopenReason, type RiskDescriptor, type StoreDurability, type StoreFidelity } from "@sema-agent/core";
 import { type SqlDriver } from "./sql-driver.js";
 /**
  * design/80 D-1 (§3 invariant #3 — crash-safe reaper backstop): an ABSOLUTE upper bound on a pending
@@ -77,6 +77,16 @@ export interface CheckpointAskCandidate {
     /** `checkpoint.status` 列(权威;`pending` | `resolved` | `expired`)。不做过滤,由收敛器判活性。 */
     status: string;
     createdAtMs: number;
+    /**
+     * 🔴 和解三元组的第一维(#168 件1,黑板 [2897]③①)—— checkpoint 自己带的 `sourceTaskId`(core 在
+     * suspendAsk 铸行时恒填该腿的 `sessionId`)。**没有对应的列**,只能从 blob 窄读;读不出/缺席 = null。
+     *
+     * 为什么必须进候选集:读口按 `(scope, session_id, tool_call_id)` 查,而委派子代那条腿的 ask 落行时
+     * `session_id` 记的是**投递上下文**(根会话),park 却发生在**子代自己**的 sessionId 上 —— 只靠
+     * (toolCallId, hash) 两维,一条根腿的 park 会被一只子代的 ask 认领(摘要相同的两次同 args 调用完全
+     * 正常)。三元组全同才算同一件事。
+     */
+    sourceTaskId: string | null;
     /** 该 park 绑定的 tool call(= `pendingAction.toolCallId`)。`unparseable` 行为 null。 */
     boundCallId: string | null;
     /** 服务端铸的入参摘要——判据 1 的第二道硬等式(与 `approval_asks.bound_input_hash` 相等才算命中)。 */
@@ -109,13 +119,54 @@ export declare class SqlCheckpointStore implements CheckpointStore {
     protected readonly logger?: {
         info?(msg: string, meta?: unknown): void;
     } | undefined;
+    /**
+     * `CheckpointStore.durability` 声明(#167 欠账,#168 件5)—— 行落在 MySQL-protocol / PostgreSQL 的
+     * `checkpoint` 表里,进程重启、副本轮换、整机重建都不丢 ⇒ `"durable"`,如实。
+     *
+     * 🔴 为什么这一格空着是有代价的:core 的 `resolveDeclaredDurability` 把**缺席**折成 `"process-local"`
+     * (它不能替一个没表态的店猜),于是静态装配面对每一个真持久部署都读出 `process_local`,
+     * `GET /v1/diagnostics/wiring` 的 park 车道读数与启动自检的那条警告都因此不可信 —— 而 park 正是流内
+     * 审批协议的降级目的地,「重启后还赎不赎得回」是运维必须能一眼看见的事。声明是店自己的责任,不是
+     * 消费侧靠 backend.kind 猜出来的。
+     */
+    readonly durability: StoreDurability;
+    /**
+     * `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 组;已上报上游求一个能表达该宽度的词。
+     */
+    readonly fidelity: StoreFidelity;
     constructor(db: SqlDriver, logger?: {
         info?(msg: string, meta?: unknown): void;
     } | undefined);
     /** Pick the dialect's SQL text. Both statements stay written out at the call site ON PURPOSE. */
     private q;
-    /** JSON column binding: TiDB stores the string verbatim; PG goes through the LOSSLESS protocol envelope
-     *  (R4-H1 — the operator's review surface must agree with the executed args at the NUL position). */
+    /** 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). */
     private json;
     private isDupKey;
     /** Create-once. core mints the token (`mintCheckpointToken`) and calls this during suspend. */
@@ -175,8 +226,11 @@ export declare class SqlCheckpointStore implements CheckpointStore {
      *
      * 🔴 从「一条无条件 UPDATE」变成「读-改-写」,中间那道窗必须自己有 CAS:两个并发 steer 读到同一份
      * 队列、后写者整个盖掉前者 —— 就是 #147 要消灭的静默丢失换了个位置复发。守卫是 `pending_steer_rev`
-     * **专用整数列**(不是拿旧列值比:本表无显式 COLLATE,*_ci 排序规则会把只差大小写的两份信封判等 ⇒
-     * CAS 假命中;也不是复用 resolve 的 `rev`:bump 它会让并发 resume 的 `resolve(expect)` 白白落败)。
+     * **专用整数列**(不是拿旧列值比:整数按构造唯一,而长 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「已不再挂起」),把争用报成那个是撒谎。
      *
@@ -268,9 +322,14 @@ export declare class SqlCheckpointStore implements CheckpointStore {
      *    扫描(§8 C-6)。什么算读不出:blob 的 `version` 超出本 build 支持(`get()` 那条前向兼容门在这里
      *    不能 throw,否则一条超前行会让整个 session 的对账永久卡死)、或 blob JSON 坏。
      *
-     * 匹配是两段的:`tool_call_id` **列**是 `put()` 从 `pendingAction.toolCallId` 盖下来的权威投影,命中它
-     * 的行零解析即候选;列为 NULL 的行(无工具动作的 park,或列存在之前的旧行)才回落去解 blob——解得出且
-     * 相等才算候选,解不出就标 `unparseable`。
+     * 匹配是两段的:`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 才拿得到它。
      */
     findCheckpointCandidatesForAsk(scope: string, sessionId: string, toolCallId: string, sinceMs: number): Promise<CheckpointAskCandidate[]>;
     /**

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

@@ -99,8 +99,15 @@ 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 }; // 无 pendingAction 的 park:确定不匹配
+        return { readable: true, toolCallId: null, boundInputHash: null, kind: null, sourceTaskId }; // 无 pendingAction 的 park:确定不匹配
     const pa = parsed.pendingAction;
     if (typeof pa !== "object" || pa === null)
         return { readable: false };
@@ -108,7 +115,7 @@ function pendingActionToolCallId(blob) {
     if (kind !== null && typeof kind !== "string")
         return { readable: false };
     if (!("toolCallId" in pa))
-        return { readable: true, toolCallId: null, boundInputHash: null, kind }; // plan_review / task_done / resource_limit 腿
+        return { readable: true, toolCallId: null, boundInputHash: null, kind, sourceTaskId }; // plan_review / task_done / resource_limit 腿
     const id = pa.toolCallId;
     if (typeof id !== "string")
         return { readable: false };
@@ -122,7 +129,7 @@ function pendingActionToolCallId(blob) {
     const bih = "boundInputHash" in pa ? pa.boundInputHash : null;
     if (bih !== null && typeof bih !== "string")
         return { readable: false };
-    return { readable: true, toolCallId: id, boundInputHash: bih, kind };
+    return { readable: true, toolCallId: id, boundInputHash: bih, kind, sourceTaskId };
 }
 const DUP_ENTRY = 1062; // MySQL/TiDB ER_DUP_ENTRY
 const PG_UNIQUE_VIOLATION = "23505";
@@ -228,6 +235,39 @@ const STEER_CAS_ATTEMPTS = 8;
 export class SqlCheckpointStore {
     db;
     logger;
+    /**
+     * `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";
     constructor(db, logger) {
         this.db = db;
         this.logger = logger;
@@ -236,8 +276,16 @@ export class SqlCheckpointStore {
     q(tidb, pg) {
         return this.db.dialect === "tidb" ? tidb : pg;
     }
-    /** JSON column binding: TiDB stores the string verbatim; PG goes through the LOSSLESS protocol envelope
-     *  (R4-H1 — the operator's review surface must agree with the executed args at the NUL position). */
+    /** 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);
     }
@@ -300,8 +348,12 @@ export class SqlCheckpointStore {
         // 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 (winnerFromOutcome → {boundCallId,decision,
-        // updatedInput?}), so it is preserved across a reopen for free (reopen leaves `outcome` untouched).
+        // 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);
@@ -402,8 +454,11 @@ export class SqlCheckpointStore {
      *
      * 🔴 从「一条无条件 UPDATE」变成「读-改-写」,中间那道窗必须自己有 CAS:两个并发 steer 读到同一份
      * 队列、后写者整个盖掉前者 —— 就是 #147 要消灭的静默丢失换了个位置复发。守卫是 `pending_steer_rev`
-     * **专用整数列**(不是拿旧列值比:本表无显式 COLLATE,*_ci 排序规则会把只差大小写的两份信封判等 ⇒
-     * CAS 假命中;也不是复用 resolve 的 `rev`:bump 它会让并发 resume 的 `resolve(expect)` 白白落败)。
+     * **专用整数列**(不是拿旧列值比:整数按构造唯一,而长 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「已不再挂起」),把争用报成那个是撒谎。
      *
@@ -595,9 +650,14 @@ export class SqlCheckpointStore {
      *    扫描(§8 C-6)。什么算读不出:blob 的 `version` 超出本 build 支持(`get()` 那条前向兼容门在这里
      *    不能 throw,否则一条超前行会让整个 session 的对账永久卡死)、或 blob JSON 坏。
      *
-     * 匹配是两段的:`tool_call_id` **列**是 `put()` 从 `pendingAction.toolCallId` 盖下来的权威投影,命中它
-     * 的行零解析即候选;列为 NULL 的行(无工具动作的 park,或列存在之前的旧行)才回落去解 blob——解得出且
-     * 相等才算候选,解不出就标 `unparseable`。
+     * 匹配是两段的:`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, tool_call_id, bound_input_hash, version, checkpoint FROM checkpoint " +
@@ -605,11 +665,14 @@ export class SqlCheckpointStore {
             "WHERE scope=$1 AND session_id=$2 AND created_at>=$3 AND (tool_call_id=$4 OR tool_call_id IS NULL) ORDER BY created_at 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),
                 createdAtMs: Number(r.created_at),
                 boundInputHash: r.bound_input_hash == null ? null : String(r.bound_input_hash),
+                sourceTaskId: null,
             };
             // 🔴 前向兼容门必须在**任何**命中路径之前(codex 复审 F3,2026-08-06 真缺陷):版本超前的行是
             // `get()` 明确拒读的行,而 `tool_call_id` 列命中与否跟能不能读懂 blob 毫无关系。若让列的快路径
@@ -652,7 +715,7 @@ export class SqlCheckpointStore {
             // 列在场时以列为准(权威投影);列为 NULL 的旧行回落用 blob 解出来的值。
             const effective = col ?? derived.toolCallId;
             if (effective === toolCallId)
-                out.push({ ...base, boundInputHash: effectiveHash, boundCallId: effective });
+                out.push({ ...base, boundInputHash: effectiveHash, sourceTaskId: derived.sourceTaskId, boundCallId: effective });
             // 解得出、但不是这只 ask 的 callId(或这条 park 本来就没有工具动作)⇒ **确定**不是候选:
             // 既不返回也不标坏行(标坏行会让收敛器把一条明确的「不匹配」当成「不确定」)。
         }

package/dist/plugins/image-bake-store-sql.d.ts

@@ -7,7 +7,7 @@ import { type BakeStatus, type BakeState, type BakeRecord, type BakeEvent, type
  *  TINYINT(1) 归一(clay 批 2026-07-26):布尔列的 PG 映射统一 SMALLINT 0/1(此前本家族用 BOOLEAN)——
  *  两方言驱动读回同为 number ⇒ 不再存在「忘了配的适配器」这个病族;写入参与 SQL 字面量一律 0/1,
  *  读侧 `!!`/`Boolean()` 保持,store 出口 JS 类型逐字节不变(真双库套件的严格值断言为证)。
- *  The uq_line UNIQUE is given an explicit name so a 23505 can be attributed to it via err.constraint. */
+ *  The line UNIQUE is given the explicit name uq_image_bake_event_line so a 23505 can be attributed to it via err.constraint. */
 export declare const PG_IMAGE_BAKE_SCHEMA: string[];
 /** Idempotent self-contained PG schema apply (for the integration test; central aggregation is done separately). */
 export declare function ensurePgImageBakeSchema(pool: PgPool | PoolClient, poolName?: string): Promise<void>;