@sema-agent/server 7.133.0 → 7.135.0

package/dist/plugins/sql-driver.d.ts

@@ -26,14 +26,14 @@
  *     exec; this seam stays on the plain (sql, params) form.
  *
  * ─────────────────────────────────────────────────────────────────────────────────────────────────
- * @contract txn.read-semantics — 本仓「事务里的读看到什么」的**唯一**成文处(S-131 / B-020 / B-022)
+ * @contract txn.read-semantics — 本仓「事务里的读看到什么」的**唯一**成文处([ref] / [ref] / [ref])
  * ─────────────────────────────────────────────────────────────────────────────────────────────────
  * 五只店的头注此前各写一套「为什么用这个事务动词」的理由(截断的、漏数的、讲历史沿革的都有)。
  * 判据从今天起只有这一处,店里只留一行 `{@link SqlTxConn.begin}` 指回来。
  *
  * **① 事务动词只有一个** —— `begin()`。曾经那个「悲观」专用动词(MySQL 腿发 TiDB 专有的
  *    `BEGIN PESSIMISTIC`)已删除:那条语句在真 MySQL / MariaDB 上是 `ER_PARSE_ERROR`,四店 18 个事务
- *    一个都开不了(**B-020**),而它真正保证的东西现在由 ② 结构性地给出。同理,那个「可重复读」专用
+ *    一个都开不了(**[ref]**),而它真正保证的东西现在由 ② 结构性地给出。同理,那个「可重复读」专用
  *    动词也一并并入:隔离级不再由动词决定。
  *
  * **② 隔离级与事务模式是「连接的事实」,不是「动词的参数」** —— 见 {@link SqlDriver.facts}。
@@ -54,12 +54,12 @@
  *    的行**、读**值/时钟表达式**(不触任何存量行)、以及 PG 语法明禁加锁的形(**只有**聚合 / GROUP BY /
  *    DISTINCT / 窗口 / 集合运算;`ORDER BY … LIMIT 1` 尾行读在 PG 上**合法**加锁,不属此类——7.60.0 重扫纠)。
  *    理由:TiDB 悲观事务的普通 SELECT 仍钉 `start_ts`,`lockScope` 的锁等待窗内别副本的提交看不见
- *    (**B-022**);InnoDB REPEATABLE READ 下则由本事务的第一条一致性读建 read view —— 两条都是
+ *    (**[ref]**);InnoDB REPEATABLE READ 下则由本事务的第一条一致性读建 read view —— 两条都是
  *    **版本相关的副作用**,不是保证。机器门:`test/sql-txn-semantics-gate.test.ts`(G-B,例外闭集
  *    `INTRA_TXN_PLAIN_READS` 每条带理由);真值神谕:`test/sql-txn-semantics-integration.test.ts`(三引擎)。
  *
  * **④ 引擎事实不进店** —— `SqlDriver.facts` 是**运维读面**(`GET /v1/diagnostics/wiring` 的 `sqlEngine`
- *    段与 `GET /v1/capabilities` 的 `store.sql` 位(7.106.0 起;此前顶层 `sql`,S-866 ①))的料。店里不许出现 `if (engine === …)`:引擎判别在全仓
+ *    段与 `GET /v1/capabilities` 的 `store.sql` 位(7.106.0 起;此前顶层 `sql`,[ref] ①))的料。店里不许出现 `if (engine === …)`:引擎判别在全仓
  *    只有连接初始化这一处,机器门 G-A 守着。`SqlDialect`(SQL **文本**方言,两值)与 `engine`(运行期
  *    引擎事实,三值)是两条轴,刻意不合成一个三值。
  *
@@ -125,7 +125,7 @@ export interface SqlExec {
 /** A pooled connection with transaction control (released by the caller in a `finally`). */
 export interface SqlTxConn extends SqlExec {
     /**
-     * The ONE transaction verb (S-131). What its reads see is NOT decided here — it is decided once per
+     * The ONE transaction verb ([ref]). What its reads see is NOT decided here — it is decided once per
      * pooled connection at initialization and reported by {@link SqlDriver.facts}. Read the
      * `@contract txn.read-semantics` block at the top of this file before adding a transaction: the
      * short version is **intra-transaction collection reads are LOCKING reads**, and a plain `SELECT`
@@ -145,7 +145,7 @@ export interface SqlTxConn extends SqlExec {
  */
 export type SqlEngine = "tidb" | "innodb" | "pg";
 /**
- * What connection initialization ESTABLISHED and then READ BACK on this driver's pool (S-131 §1
+ * What connection initialization ESTABLISHED and then READ BACK on this driver's pool ([ref] §1
  * 补偿面). Operator read faces: `GET /v1/diagnostics/wiring` → `sqlEngine`, `GET /v1/capabilities`
  * → `sql`. Store code must never read this (machine gate G-A) — engine discrimination exists in
  * exactly one place in this repo, and it is `connect()`.
@@ -322,7 +322,7 @@ export declare const SQL_FACTS_ABSENT_WALLS: SqlWallsReading;
 export declare function sqlWallsOf(engine: SqlEngineReading | undefined): SqlWallsReading;
 /**
  * **数据库自己的钟**(毫秒),两方言各一句 —— 本仓这口钟在 SQL 面的**唯一**铸点([ref] A7 / [ref] /
- * 合并复审 R2 把 S-280 的 nonce 店并进来)。
+ * 合并复审 R2 把 [ref] 的 nonce 店并进来)。
  *
  * 用处永远是同一条:**一个时刻量的铸造点与它的判定点必须在同一个钟域**。副本各拿各的墙钟时,两台机器
  * 之间的偏差没有任何一条腿强制过上界(本仓 [ref]③ 记过一次真实的 11 分钟 NTP 纠正),于是
@@ -359,7 +359,7 @@ export interface SqlDriver extends SqlExec {
      *  · `null`(还没借出过连接)—— 没有可报的东西,**不猜**;
      *  · 事实 —— 最近一次初始化**回读复核**过的值。每条池连接首次借出都重跑一次初始化(记忆化按连接身份),
      *    所以池在致命错误后重连时,保证是在新连接上**重新建立**的,不是继承来的;
-     *  · `null`(借出过、但最近一次初始化被**拒**)—— S-137 ④:保证此刻建立不起来,读面就报缺席。
+     *  · `null`(借出过、但最近一次初始化被**拒**)—— [ref] ④:保证此刻建立不起来,读面就报缺席。
      *    此前这里是「一次成功即长期有效」的快照:连接被驱逐、新连接初始化被拒之后,诊断面仍在陈述一条
      *    已经不成立的结构保证。降级由 `establishSession()` 一处完成,并留 loud warn。
      */

package/dist/plugins/sql-errors.d.ts

@@ -90,7 +90,7 @@ export declare const PG_DEADLOCK_DETECTED_SQLSTATE = "40P01";
  * 它**不是**「锁序可以随便写」的许可证 —— 锁序的属主仍是店(真值神谕 =
  * `test/sql-lock-shape-innodb-integration.test.ts` 三引擎并发套)。
  *
- * 引擎事实(2026-09-20 真 InnoDB 实测,S-529 取证):同一把缺行主键上 N=8 路并发「`FOR UPDATE` 缺行读
+ * 引擎事实(2026-09-20 真 InnoDB 实测,[ref] 取证):同一把缺行主键上 N=8 路并发「`FOR UPDATE` 缺行读
  * → `INSERT`」,InnoDB(REPEATABLE READ,gap lock + insert-intention)恒定 1 成 7 死锁;TiDB(悲观、无
  * gap lock)与 PG(READ COMMITTED,缺行 `FOR UPDATE` 不取锁)各自零死锁。⇒ 这条谓词实际的受众是
  * **MySQL 协议腿**,两方言都认只是为了让店不必自己判引擎。

package/dist/plugins/sql-json-column.d.ts

@@ -1,5 +1,5 @@
 /**
- * **SQL JSON 列读腿的唯一属主**(S-550 设计稿 §2)—— 一列 JSON 怎么**投影**、怎么**恰好解一次码**、
+ * **SQL JSON 列读腿的唯一属主**([ref] 设计稿 §2)—— 一列 JSON 怎么**投影**、怎么**恰好解一次码**、
  * 读不出形怎么**拒**,整仓只有这一份定义。
  *
  * ── 病(KM / 7.92.2 C1 的真案,三库实测两次换形之后的终形)────────────────────────────────────
@@ -23,11 +23,11 @@
  * `test/sql-json-column-single-owner.test.ts` 四道:①`JSON.parse(` 在 `src/plugins/**` 只许出现在本文件
  * (未改调的店走显式 `PENDING_STORES` 登记 + 反向门);②JSON 承载列(清单由 `schema-ensure-legs` 的录制
  * 驱动**机器派生**,不手抄)在 SELECT 投影里必须经 {@link jsonColumnText};③{@link decodeJsonColumn} 的
- * `read` 实参必须是具名读者,禁内联 `(b) => b as T`;④(S-577)**读者 × 列可空性**求交,**双向**:每一只
+ * `read` 实参必须是具名读者,禁内联 `(b) => b as T`;④([ref])**读者 × 列可空性**求交,**双向**:每一只
  * 形读者对承载列的可空性要求写在门的那张闭集表里,与 DDL 机器派生的读数不符即红(两个方向各一格)。
  * 那条要求此前是注释里的一句散文,而整仓第二个用它的地方把它违了一整版。
  *
- * ── 「任意 JSON 值」那一族的三只铸点(S-577;区别在**名字**里,不在散文里)─────────────────────
+ * ── 「任意 JSON 值」那一族的三只铸点([ref];区别在**名字**里,不在散文里)─────────────────────
  * 一列的载荷没有声明形时,`null` 字面算不算合法值,**只由这一列有没有「缺席」这个状态**决定 —— 而那是
  * 列可空性的另一种说法。所以这一族按可空性拆成三只,各自的前置条件由门双向咬:
  *  | 铸点 | 承载列必须 | JSON 字面 `null` |
@@ -69,9 +69,9 @@ export interface JsonColumnMember {
  *
  * 🔴 存在的唯一理由是「别名位在那里不合法」,**不是**给读腿留第二条路:读腿一律用 {@link jsonColumnText}
  * (别名是它的产物的一部分,理由见那只函数)。今天整仓**两处**消费方,各自的「别名位不合法」都是真的:
- *  · `one-time-migrations.ts` 的 M4(把 `device_audit.detail` 里 JSON 文本 `null` 的旧行改成列 NULL)——
- *    它要在 `WHERE` 里判这一列的**文本**,而 `WHERE` 没有别名位;
- *  · `workflow-journal-store-sql.ts` 的 `loadPage`(S-550 车③a)—— 那一列的投影裹在一条
+ *  · `one-time-migrations.ts` 的几条改写(M8 / M17 / M18 / M21 的候选扫描与按原文 CAS 回写)——
+ *    它们要在 `WHERE` 里判这一列的**文本**,而 `WHERE` 没有别名位;
+ *  · `workflow-journal-store-sql.ts` 的 `loadPage`([ref] 车③a)—— 那一列的投影裹在一条
  *    `CASE WHEN LENGTH(result) > ? THEN NULL ELSE <expr> END AS result_json` 里:**别名属于整条 CASE**
  *    (`result_json`,因为超字节门的那一支要给 `NULL`),CASE 里面的表达式位上写别名是语法错。
  * 而「怎么把一列 JSON 取成文本」这件事整仓只能有一种写法:两种承载(真 JSON 列 / LONGTEXT 别名)在这条
@@ -106,9 +106,9 @@ export type SqlJsonColumnBodyProblem = Exclude<SqlJsonColumnProblem, "not-text">
  * 店层码,**不上 wire**:店层折码口 {@link foldJsonColumn} 把它折成 {@link StoreCorruptError}
  * (有自己闭集契约词的店折成自己的码)。终局对外码经 7.92.2 的词法门,永不裸穿。
  *
- * 🔴 **它只许在 `not-text` 那一形上穿过店的边界**(S-608):`not-text` 是读腿自己的缺陷(投影漂),
+ * 🔴 **它只许在 `not-text` 那一形上穿过店的边界**([ref]):`not-text` 是读腿自己的缺陷(投影漂),
  * 按 {@link foldJsonColumn} 的规则不折、原样上抛;而体的两形一旦穿出去,上层就得**按列错误类**分类,
- * 那正是 S-608 的病 —— 读口按列错误分类、店按店拒绝形折码,两层各说各话,坏体于是落进「店抖动」臂。
+ * 那正是 [ref] 的病 —— 读口按列错误分类、店按店拒绝形折码,两层各说各话,坏体于是落进「店抖动」臂。
  */
 export declare class SqlJsonColumnError extends Error {
     readonly problem: SqlJsonColumnProblem;
@@ -157,9 +157,9 @@ export declare function decodeNullableJsonColumn<T>(cell: unknown, read: JsonCol
 /**
  * **「这一格耐久载荷读不出来」的店层拒绝**(整仓唯一一只)—— {@link foldJsonColumn} 的**恒定产物**。
  *
- * 🔴 为什么它必须是一只**具名类**而不是 `new Error(…)`(S-608 真案,7.95.1):折码的产物是**店交给
+ * 🔴 为什么它必须是一只**具名类**而不是 `new Error(…)`([ref] 真案,7.95.1):折码的产物是**店交给
  * 上层的契约**。折成裸 `Error` 之后,「这一行确定性地读不出来」与「店抖了一下」在上层**没有任何判别位**,
- * 而两者的处置完全相反(前者要人去修那一行,后者重试 / 保守当缺席)。S-577 给续跑上下文修的正是这条
+ * 而两者的处置完全相反(前者要人去修那一行,后者重试 / 保守当缺席)。[ref] 给续跑上下文修的正是这条
  * 分家,可它在 SQL 车道上**结构不可达**整整一版:读口按**列错误类**分类,而店早把列错误折成了裸
  * `Error` ⇒ 坏体一路掉进「店抖动 ⇒ 当缺席」臂,用户拿到的还是那个 409(local 车道答对,只是因为它
  * 根本没折码、把列错误漏了出来 —— 巧合式正确,不是同一份契约)。
@@ -187,9 +187,9 @@ export declare class StoreCorruptError extends Error {
 /**
  * 店层折码的**唯一规则**(`catch (e) { throw foldJsonColumn(e, (m) => \`XStore: ${m} — refusing …\`); }`)。
  *
- * 🔴 回调交出来的是**一句话**,不是一只错误(S-608 按类改):产物恒是 {@link StoreCorruptError},于是
+ * 🔴 回调交出来的是**一句话**,不是一只错误([ref] 按类改):产物恒是 {@link StoreCorruptError},于是
  * 「折成一只没有判别位的错」在**构造上**写不出来。此前这一格的签名是 `(message) => Error`,21 个调用点
- * 里 19 个折成了裸 `Error` —— 每一个都是一枚等着下一个消费方来踩的 S-608。
+ * 里 19 个折成了裸 `Error` —— 每一个都是一枚等着下一个消费方来踩的 [ref]。
  *
  * 🔴 `not-text` **不折**:它是读腿自己的缺陷(投影漏了),折成「这一行坏了」会把一次代码漂伪装成一次
  * 数据事故 —— 这条判别只写在这里一处(与它的容忍侧孪生 {@link isJsonColumnBodyProblem} 共用),
@@ -233,7 +233,7 @@ export declare function createZodColumnReader<T>(schema: z.ZodType<T>): JsonColu
  * 该店的域型交出去。整仓**只有这一处**做这一跳断言。
  *
  * 🔴 什么时候用它(硬条件,别扩大):这一列的键表属主**不在本层**,而那一层**没有导出验证器**。
- * 两族,判据同一条(S-577 把这段与本函数第一句对齐 —— 它此前只写了 core 那一族,于是第二族要么被迫
+ * 两族,判据同一条([ref] 把这段与本函数第一句对齐 —— 它此前只写了 core 那一族,于是第二族要么被迫
  * 违注、要么被迫另造一只读者,而「加一只特例读者」在本仓是红旗):
  *  · 属主在 **core**:`Checkpoint` / `ResumeOutcome` / `GateOutcome` / `WorkflowRun` /
  *    `BackgroundAgentRecord` …;
@@ -246,7 +246,7 @@ export declare function createZodColumnReader<T>(schema: z.ZodType<T>): JsonColu
  * 一列只要有**本层自己的** schema 属主,就必须用 {@link createZodColumnReader} —— 用本函数等于把形判据关小。
  *
  * 🔴 为什么是一只工厂而不是让每个店各写一遍 `typeof body !== "object"`:那是同一条判据的 N 份拷贝
- * (S-550 车② 初版真的写了六份),而且每一份都要自己那一跳 `as`。收成一处之后,判据只有一个写者,
+ * ([ref] 车② 初版真的写了六份),而且每一份都要自己那一跳 `as`。收成一处之后,判据只有一个写者,
  * 断言也只发生在这一行 —— 类型卫生门因此在每个店里都读到零。
  */
 export declare function createObjectColumnReader<T extends object>(): JsonColumnReader<T>;
@@ -265,17 +265,17 @@ export declare function isJsonObject(v: unknown): v is Record<string, unknown>;
  *
  * 🔴 前置条件(**门④ 机器执法,不是散文**):承载列**可空**,而「缺席」在它上面由**列的 NULL** 单独表达
  * (三态列);于是 JSON 字面 `null` 是一个与缺席**不同形**的合法值。用在 `NOT NULL` 列上当场红 —— 那种列
- * 根本没有缺席态,`null` 字面与「没有这一行」在点读的消费点上逐字同答,而那正是 S-577 的病灶
+ * 根本没有缺席态,`null` 字面与「没有这一行」在点读的消费点上逐字同答,而那正是 [ref] 的病灶
  * (`checkpoint_ctx.ctx`:`JSON NOT NULL` + 有结构的载荷,一整版都读回一个没人分得出来的 `null`)。
  * NOT NULL 且契约不透明的列用 {@link readOpaqueJsonValueColumn};缺席落 SQL NULL 的用
  * {@link readNonNullJsonValueColumn}(那一族把 `null` 字面判坏)。
  *
  * 之所以叫得出「三态」:范本是 `approval_ask.updated_input`([ref] / [ref])—— 列 NULL = 没带编辑,
  * JSON 文本 `"null"` = **编辑成 null**,对象 = 编辑成那只对象;把 `"null"` 判成坏体会把一条合法的人类
- * 编辑抹掉。这一句是**理由**,不是名单:哪几处在用它由门数,别在这里写计数(S-577 之前这里写着
+ * 编辑抹掉。这一句是**理由**,不是名单:哪几处在用它由门数,别在这里写计数([ref] 之前这里写着
  * 「今天整仓只有一处符合」—— 那句话当时就是假的,而没有门看着的计数,下一个人加第二处时不会来改它)。
  *
- * 一列只要有结构,就**不许**用它 —— 那是把形判据静默关掉(这条是 S-577 的病灶判据,三只铸点同守)。
+ * 一列只要有结构,就**不许**用它 —— 那是把形判据静默关掉(这条是 [ref] 的病灶判据,三只铸点同守)。
  */
 export declare const readTriStateJsonValueColumn: JsonColumnReader<unknown>;
 /**
@@ -294,14 +294,14 @@ export declare const readTriStateJsonValueColumn: JsonColumnReader<unknown>;
  * 🔴 **它与 {@link readTriStateJsonValueColumn} 的实现逐字相同,而且必须各自独立写出来** —— 不许收成
  * `export const readOpaqueJsonValueColumn = readTriStateJsonValueColumn`(门④c2 会红)。两只的区别整个
  * 落在**前置条件**上(一只要可空列、一只要 NOT NULL 列),而前置条件的载体就是**名字**:合成一个名字就等于
- * 把两条互斥的前置条件重新揉回一起 —— 那正是 S-577 立案时那条散文析取的形。「去重」在这里去掉的不是重复,
+ * 把两条互斥的前置条件重新揉回一起 —— 那正是 [ref] 立案时那条散文析取的形。「去重」在这里去掉的不是重复,
  * 是判据。
  */
 export declare const readOpaqueJsonValueColumn: JsonColumnReader<unknown>;
 /**
  * **任意 JSON 值,但缺席由「列 NULL」表达**的列的形读者 —— `null` 字面判坏,其余一律是值。
  *
- * 🔴 这是**写腿吃 `unknown` 的那一族列**的正解(codex 对抗复审 [high] 验真后定形,S-550 车②):
+ * 🔴 这是**写腿吃 `unknown` 的那一族列**的正解(codex 对抗复审 [high] 验真后定形,[ref] 车②):
  * 写腿接的是 `unknown`(`PendingAction.args` / 账本行载荷 / leader 结果……),于是**数组 / 串 / 数 /
  * 布尔实参都写得进去** —— 拿 {@link readJsonObjectColumn} 判它们就是「写腿收得下、读腿读不出」,而且
  * 后果往往不是一行坏:`rows.map` 里一条这样的合法行会让整只读面抛。
@@ -312,14 +312,14 @@ export declare const readOpaqueJsonValueColumn: JsonColumnReader<unknown>;
  * (根本没有缺席态),用 {@link readOpaqueJsonValueColumn}。
  *
  * 🔴 与 {@link readTriStateJsonValueColumn} 同属「承载列必须**可空**」这一族,所以同受门④ 约束
- * (S-577):这族读者用在 `NOT NULL` 列上一律红 —— 列上没有 NULL 这个状态,「缺席」就无处安放,而写腿把
+ * ([ref]):这族读者用在 `NOT NULL` 列上一律红 —— 列上没有 NULL 这个状态,「缺席」就无处安放,而写腿把
  * 缺席落成 SQL NULL 这句话在那种列上根本执行不了。
  */
 export declare const readNonNullJsonValueColumn: JsonColumnReader<unknown>;
 /**
  * **一只 JSON 数组**的承载形读者(内容判据归各列自己的既有属主,这里只判承载形)。
  *
- * 🔴 为什么在属主里而不是各店各写一遍(S-550 车③a 把车② 的店内私有形上收):今天有三个消费方
+ * 🔴 为什么在属主里而不是各店各写一遍([ref] 车③a 把车② 的店内私有形上收):今天有三个消费方
  * (checkpoint 的 `rule_suggestions` / `pending_steer_queue`、memory-engine 的 `embedding`),判据逐字
  * 相同,而「这一格是不是一只数组」恰好是坏体四形的落点 —— 三份拷贝迟早有一份忘了判 `null` 字面。
  */

package/dist/plugins/sql-row-helpers.d.ts

@@ -4,8 +4,8 @@
  * These were duplicated verbatim across the pg-/tidb- store twin pairs; each store imports the flavor
  * it was written against so call sites and semantics are byte-identical to before.
  *
- * 🔴 **JSON 列的解析不在这里,也永远不会回来**(S-550):本文件曾住着三只 `parseJson*`
- * (lenient → `null` / strict → 抛 / fallback → 兜底),三种失败方向由**调用点自选** —— 那正是 S-550
+ * 🔴 **JSON 列的解析不在这里,也永远不会回来**([ref]):本文件曾住着三只 `parseJson*`
+ * (lenient → `null` / strict → 抛 / fallback → 兜底),三种失败方向由**调用点自选** —— 那正是 [ref]
  * 要消灭的现状:同一格读不出的 JSON,在一个店里是「空体」、在另一个店里是「这一行不存在」、在第三个
  * 店里是异常。三只在车③b **删除**(零别名、零转出),整仓唯一属主 = `sql-json-column.ts`
  * (按文本投影 · 恰好解一次码 · 坏体一律拒),容忍写在店的调用点上(显式 `try/catch` + `recordFailOpen`)。

package/dist/plugins/store-backend.d.ts

@@ -50,7 +50,7 @@ export type { ApprovalNonceStore } from "./approval-nonce-store.js";
  *  车3 刀 3a 起 `StoreBackend.approvalAsk()` 已在(见接口体的那条注)。 */
 export type { ApprovalAskStore, AskRow, NewAskRow, AskTransitionPatch, DecideAskInput, DecideResult, ExpireResult, BindGateInput, BatchRow, AskDecision } from "./approval-ask-store-sql.js";
 /** E6 SessionPolicyStore — core's interface, incl. its optional `deleteBySession` / `listBySession` seams (E21 purge / 2c
- *  export; core's File and InMemory stores carry both since core 7.25.0 — S-546 A7 retired the service's own in-memory
+ *  export; core's File and InMemory stores carry both since core 7.25.0 — [ref] A7 retired the service's own in-memory
  *  twin that existed only because they once did not). tidb/pg = the SQL twin; local = core's FileSessionPolicyStore
  *  (works local — rules need no cloud-only infra). The rev-line contract kit runs the SQL twin against core's InMemory
  *  as oracle (`test/helpers/session-policy-rev-line-contract.ts`). */
@@ -94,12 +94,13 @@ export type ServiceFileHistoryStore = FileHistoryStore & {
 /** SVC-2 (core CORE-7) WorkflowJournalStore — core's interface PLUS the service `deleteByRun` (GC extra). tidb/pg =
  *  durable SQL twins (cross-replica resume journal); local = the service {@link FileWorkflowJournalStore}
  *  (single-box but RESTART-durable crash-safe JSONL, replacing core's InMemory). The shared equivalence suite keeps
- *  all three byte-matched (scope guard / idempotent-per-ordinal / oversize **refusal** —— S-194 / core 7.12.0
+ *  all three byte-matched (scope guard / idempotent-per-ordinal / oversize **refusal** —— [ref] / core 7.12.0
  *  [ref] 起两臂一律抛 `workflow.journal_oversize`,判长口径归 core `assertJournalEntryFits` 单一属主). */
 export type ServiceWorkflowJournalStore = WorkflowJournalStore & {
-    /** codex R1-H2(journal 读面界):分页+单行字节门的投影读——SQL 端 LIMIT/OFFSET 定行数、LENGTH 门
-     *  定单行(超 maxResultBytes 的行 resultJson=null 只回 resultBytes,读面标 truncated)。HTTP 读面
-     *  优先走此面;缺席(旧实现/in-memory)回落全量 load(元素少的店可受)。 */
+    /** journal 读面的分页投影读:**判整份、取一页**——与 `load` 同一个判的范围(这条 journal 里任一行被 core 的判官判坏,本读就抛
+     *  `WorkflowJournalIncompatibleError`,点名按序数升序的第一条坏行;页不是判的单位),只是内存按块有界:返回 `[offset, offset+limit)` 位置上的行,
+     *  字节超 `maxResultBytes` 的行 `resultJson=null` 只回 `resultBytes`(读面标 truncated,全文不进页)。HTTP 读面优先走此面;
+     *  缺席(file / in-memory 店)回落 `load` 后在进程内切页——`load` 本身就整份判,两条路同答。 */
     loadPage?(runId: string, scope: string, opts: {
         offset: number;
         limit: number;
@@ -140,11 +141,11 @@ export type BreakerStateStore = TiDBBreakerState | PgBreakerState;
 export type CostQuotaStore = TiDBCostQuota | PgCostQuota;
 export type RateLimiterStore = TiDBRateLimiter | PgRateLimiter;
 /**
- * S-215 —— capture opt-out **记录载体的按平面取用座**。形与 core 的
+ * [ref] —— capture opt-out **记录载体的按平面取用座**。形与 core 的
  * `RunnerDeps.memoryCaptureRecordStore`(`(plane: { controlDir }) => SessionCaptureRecordStore`)同构,
  * 多一个**不指名平面**的缺省臂:`src()` = 「本部署记忆引擎自己那一只平面」。
  *
- * 🔴 为什么是工厂而不是一只实例(S-215 codex r1 [high] 验真后改形):core 的记忆平面**不止一个**
+ * 🔴 为什么是工厂而不是一只实例([ref] codex r1 [high] 验真后改形):core 的记忆平面**不止一个**
  * (`prepare-memory.js` 的 personal 平面自带 `derivePersonalControlDir(engineRoot)`,与 project 平面的
  * controlDir 不是同一只)。返回单只实例 ⇒ server 把所有平面折到一只目录上,于是升级前落在 personal
  * 控制面的旧 opt-out 记录在升级后读作**缺席**=采集恢复(隐私面的静默 fail-open)。按平面取用后,
@@ -173,7 +174,7 @@ export interface StoreBackend {
     /** Per-session per-toolName approval exemption ("本会话不再询问") — an approval MEMORY the F4
      *  ask-gate consults after deny/neverAuto. REQUIRED on all backends (works local, like resumeAnchor). */
     approvalExemption(): ApprovalExemptionStore;
-    /** S-280 直连门审批证明的一次性消费记录(`plan_review` 的 nonce)。REQUIRED on all backends —— 与
+    /** [ref] 直连门审批证明的一次性消费记录(`plan_review` 的 nonce)。REQUIRED on all backends —— 与
      *  `approvalExemption` 同姿势:tidb/pg = SQL 双方言(单类双语句),local = File 追加日志 + 压实。
      *  **不能**退化成进程内易失形:一次重启若把记录抹掉,JWT TTL 窗内的重放就复活了,而那正是本店要关的洞。 */
     approvalNonce(): ApprovalNonceStore;
@@ -185,7 +186,7 @@ export interface StoreBackend {
     /** [ref]([ref] §3.0-§3.2)流内审批协议持久层:每个流内工具调用一行的 ask 状态机 + 批行。
      *  REQUIRED **且持久** on all backends — tidb/pg = SQL 双方言 twin;local = {@link FileApprovalAskStore}。
      *
-     *  🔴 **「持久」是本口的契约,不是某条腿的巧合**(S-384):`resolveStreamApprovalGate` 自此**不再**
+     *  🔴 **「持久」是本口的契约,不是某条腿的巧合**([ref]):`resolveStreamApprovalGate` 自此**不再**
      *  单独判一次 ask 账的持久性 —— 那条合取项(旧 `volatile_ask_ledger`)存在的唯一理由是 local 车道
      *  当年交的是 `InMemoryApprovalAskStore`(两个进程内 Map ⇒ 重启同时丢重放基准、丢已接受的决议;
      *  「一次真实的人类批准凭空消失」与「对账便利丢失」不是一个量级)。File 形落地后三条腿全是持久店,
@@ -220,12 +221,12 @@ export interface StoreBackend {
     /** SendUserFile scope↔object ledger (multi-tenant list/revoke handle; the hashed key segment hides the
      *  mapping from URLs). REQUIRED on all backends (works local — one JSONL, like approvalExemption). */
     sendFileLedger(): SendFileLedger;
-    /** S-928 用户输入受理账本的存储孪生(「200 applied」受理的影子;语义属主 `src/user-input-ledger.ts`)。REQUIRED on all backends ——
+    /** [ref] 用户输入受理账本的存储孪生(「200 applied」受理的影子;语义属主 `src/user-input-ledger.ts`)。REQUIRED on all backends ——
      *  local = File(数据根下 `user-input-ledger/ledger.jsonl`,singleton:追加 fd 与内存折叠都在实例里),SQL = 表 `user_input_acceptance`。 */
     userInputLedger(): UserInputLedgerStore;
     /** E6 durable SessionPolicyStore (operator-tightened per-session tool rules). REQUIRED on all backends — works local
      *  (local = core's FileSessionPolicyStore), like resumeAnchor. Backs core's RunnerDeps.sessionPolicyStore.
-     *  `logger`:SQL 孪生抹除封键那一臂(S-891)的点名口(缺席 ⇒ 店退回 `console.warn`);local(core 的 File 店)不收。 */
+     *  `logger`:SQL 孪生抹除封键那一臂([ref])的点名口(缺席 ⇒ 店退回 `console.warn`);local(core 的 File 店)不收。 */
     sessionPolicy(logger?: SessionPolicyStoreLogger): ServiceSessionPolicyStore;
     /** [ref] per-edited-file rewind FileHistoryStore (trackEdit/annulTrack/snapshot/restore over the tracked set;
      *  also the 2c history-transfer store). REQUIRED on all backends (local = core's file-backed
@@ -243,14 +244,14 @@ export interface StoreBackend {
      *  「没有行 ⇒ 代码缺省 allow」—— 那是**放宽面**上的静默降级(permissionRule 那条禁令的同一理由)。
      *  File 形候真实的 local+governed 部署需求出现再落(候需求档)。 */
     memoryOptOutGrant(): MemoryOptOutGrantStore | undefined;
-    /** [ref]②([ref] §2.1b,core 7.0.2 [ref] 件2)/ S-215:会话 capture opt-out **记录**的载体 ——
+    /** [ref]②([ref] §2.1b,core 7.0.2 [ref] 件2)/ [ref]:会话 capture opt-out **记录**的载体 ——
      *  core `RunnerDeps.memoryCaptureRecordStore` / `MemoryEngineOptions.captureRecordStore` 的持久层。
      *  与 §3.1 的**授权表**不是一个轴:那张管「谁**可以** opt-out」(operator 写的 verdict),这张管
      *  「谁**已经** opt-out」(用户写的一次性单向记录)。
      *
      *  返回的是**按平面取用的源**({@link SessionCaptureRecordSource}),不是一只实例 —— core 的记忆平面
      *  不止一只,折平会挪动旧记录的地址(理由全文见该类型的头注)。
-     *  载体按车道分形,但**三条车道都供**(S-215 起):SQL 两支 = 双方言 twin(`session_capture_optout`,
+     *  载体按车道分形,但**三条车道都供**([ref] 起):SQL 两支 = 双方言 twin(`session_capture_optout`,
      *  Promise 形三腿,池即依托 ⇒ 无条件供,`plane` 刻意忽略);`local` = core 的控制面文件三腿
      *  `fileSessionCaptureRecordStore(controlDir)` 按平面现造,依托是**记忆引擎的控制面目录** ⇒ 记忆面暗的
      *  部署上该平面不存在,于是这一支**随引擎接线门缺席**(唯一的 `undefined` 成因,逐字理由见 LocalBackend 的实装注)。
@@ -259,7 +260,7 @@ export interface StoreBackend {
      *  确实就是文件三腿)、在**接线层面**是假的:core 的 `captureCarrierUnsupported`
      *  (core 7.13.0 `prepare-task.js`)判的是「这个席位在不在」而不是「文件形能不能用」,叠上
      *  `isRemoteExecutionEnv` 的接口形鸭子判(`remote-env.js`)把本仓 host lane 一并算作 remote,
-     *  于是单机默认部署上 `memoryCapture:"off"` 两条 ingress 结构性不可达(B-085)。
+     *  于是单机默认部署上 `memoryCapture:"off"` 两条 ingress 结构性不可达([ref])。
      *  刻意仍不给 local 一个**内存** twin:内存形会在重启时把一条隐私记录静默丢掉(比文件三腿严格更差)。 */
     sessionCaptureRecords(): SessionCaptureRecordSource | undefined;
     /** Retired-epoch byte hygiene: GC grace-passed orphan `snapshot_blob` rows/objects — the whole-tree snapshot
@@ -301,7 +302,7 @@ export interface StoreBackend {
     /** 1.108 review fix (lens③ HIGH): the notify-JOURNAL twin — third leg of the same axis (a SQL run store +
      *  inbox with a replica-LOCAL File journal stranded a dead replica's un-acked notify forever). */
     notifyJournal?(): import("../orchestration/workflow-notify-journal.js").WorkflowNotifyJournalStore;
-    /** S-185 车CM:workflow 出身 park 的**有界 join** 索引(子会话 id → 它所属的 workflow run)。
+    /** [ref] 车CM:workflow 出身 park 的**有界 join** 索引(子会话 id → 它所属的 workflow run)。
      *  与 `workflowRun`/`completionInbox`/`notifyJournal` 同一条轴 —— SQL 后端 = 跨副本双生;`local` 车道
      *  缺席**是一个真答案**:那里的索引家在 run 店同一间屋子里(`LocalWorkflowAgentSessionIndex`,文件账本
      *  或纯内存),不需要经过 backend。契约与单写者纪律的属主 = orchestration/workflow-agent-session-index.ts。 */
@@ -396,7 +397,7 @@ export interface StoreBackend {
      *  clock to expose replica clock skew (the write-behind counters bucket on LOCAL floor(now/windowMs); skew
      *  splits a fleet window into disjoint buckets = soft-limit leak). OPTIONAL: local backend omits (no fleet). */
     dbNowMs?(): Promise<number>;
-    /** S-1014(core 7.41.0 #1308):**local 后端专有**的 usage-window 账本店 = core `FileStorageBackend` 自己那一只(`usageWindowStore`)——
+    /** [ref](core 7.41.0 [ref]):**local 后端专有**的 usage-window 账本店 = core `FileStorageBackend` 自己那一只(`usageWindowStore`)——
      *  它的坏读披露座是 backend 构造时那**一只** `onCorruptRead`(core:「`FileStorageBackend` forwards its one sink」),所以坏账本拒(`usage_window.store_corrupt`,
      *  拒绝句不带盘上位置)的同时,路径进本 backend 的 `file_store_corrupt_read` 披露座(逐命中 warn)。修前 `boot/stores.ts` 在同一数据根上自己
      *  `new FileUsageWindowStore(root)` 第二只实例、不接座 ⇒ 坏值只拒不披露,运维找不到是哪只文件。SQL 后端省略(它们有自己的 usage-window 双方言店)。 */

package/dist/plugins/store-backend.js

@@ -1,5 +1,5 @@
 import { homedir } from "node:os";
-import { createCorruptReadFailOpenSeat, createDurableAbsenceSeat } from "../observability/corrupt-read-seat.js";
+import { createCorruptReadSeat, createDurableAbsenceSeat } from "../observability/corrupt-read-seat.js";
 import { createLogger } from "../observability/logger.js";
 import { join } from "node:path";
 import { AdoptionError, FileStorageBackend } from "@sema-agent/core";
@@ -272,7 +272,7 @@ class LocalBackend {
         this.sendFileLedgerStore = new FileSendFileLedger(this.fileBackend.root);
         this.userInputLedgerStore = new FileUserInputLedgerStore(this.fileBackend.root);
         this.workflowJournalStore = new FileWorkflowJournalStore(this.fileBackend.root, undefined, {
-            onCorruptRead: createCorruptReadFailOpenSeat("server.workflow-journal.corrupt-record-skipped"),
+            onCorruptRead: createCorruptReadSeat(corruptReadWarn, "workflow_journal_refused", "workflow journal = a line the engine cannot read refuses the whole load; the run cannot be listed or resumed until the file is repaired from a kept copy"),
         });
         this.outcomeSinkInst = new FileOutcomeSink(this.fileBackend.root);
         const ownControlDir = fileMemoryControlDirFor(config);
@@ -324,7 +324,7 @@ class LocalBackend {
     checkpointStoreOf() {
         return (this.checkpointStoreInst ??= new LocalCheckpointStore(this.fileBackend.root, {
             getActiveTaskId: (sessionId) => this.runStore.getActiveTaskId(sessionId),
-            ownerOf: (sessionId) => this.sessionStore.ownerOf(sessionId),
+            readSessionOwner: async (sessionId) => (await this.sessionStore.headOf(sessionId))?.owner,
         }));
     }
     checkpoint() {

package/dist/plugins/store-contracts.d.ts

@@ -9,7 +9,7 @@
  * Rules for this file:
  *  - ZERO dialect dependencies (no mysql2, no pg) — types + pure functions only. The only imports
  *    allowed are core contract types and the neutral sql-row-helpers leaf.
- *    (S-550 车③a:`mapBakeRow`/`mapImageRow`/`BAKE_SELECT_COLS` 搬回了它们**唯一**的消费者
+ *    ([ref] 车③a:`mapBakeRow`/`mapImageRow`/`BAKE_SELECT_COLS` 搬回了它们**唯一**的消费者
  *    `image-bake-store-sql.ts` / `image-index-sql.ts` —— 「两个 SQL 孪生共用」那条理由在孪生合成
  *    单文件双方言之后就不存在了,而一条 SELECT 的**列清单**必须和它的**投影铸点**、**解码点**长在
  *    同一个文件里:否则 JSON 承载列的投影门(它按「这个文件查了哪张表」定列集)对那份清单是瞎的。)
@@ -20,7 +20,7 @@
  */
 import type { PeerSessionTempo, TaskResult, TaskStatus } from "@sema-agent/core";
 /**
- * **File 店族的 boot 期拒启基类**(S-384;把 `RunStoreStrictHydrateError` 的那条论证升成一条族规)。
+ * **File 店族的 boot 期拒启基类**([ref];把 `RunStoreStrictHydrateError` 的那条论证升成一条族规)。
  *
  * 🔴 **为什么必须是一个可判别的类型,而且必须是一个共同基类**:`openStoreBackendWithFallback` 对
  * **默认推导**的 local(`DB_BACKEND` 未设 —— 也就是绝大多数单机部署)有一条既有降级臂:mkdir / 只读盘
@@ -31,7 +31,7 @@ import type { PeerSessionTempo, TaskResult, TaskStatus } from "@sema-agent/core"
  * 「DB 不可达,已退回内存」把运维支去查连通性。
  *
  * 此前这条纪律是**逐个 `if instanceof` 手工登记**的(`AdoptionError` / `RunStoreStrictHydrateError`),
- * 于是「下一只会拒启的 File 店」默认是**漏的** —— S-384 的 ask 账本拒启就这么漏了一次(替补对抗复审
+ * 于是「下一只会拒启的 File 店」默认是**漏的** —— [ref] 的 ask 账本拒启就这么漏了一次(替补对抗复审
  * F1 [high] 实测:`DB_BACKEND` 未设时坏账本 ⇒ `{backend: undefined, degraded: true}`,不是拒启)。
  * 收法:**一个基类,一条重抛**。新 File 店的拒启只要 `extends StoreBootRefusalError` 就自动落在正确的
  * 一侧;忘了继承是**可见**的(它是一个必须显式选择的父类),而忘了往 if 链里加一行是不可见的。
@@ -97,7 +97,7 @@ export interface RunCancelContext {
     elapsedMs?: number;
 }
 /**
- * 🔴 S-947(cli [ref] 第 3 件 / L-212)—— **server 为什么中止了这条 run**:取消终局的机读成因,闭集。
+ * 🔴 [ref](cli [ref] 第 3 件 / [ref])—— **server 为什么中止了这条 run**:取消终局的机读成因,闭集。
  *
  * 病:非 detach 流断连、`POST /v1/runs/:id/cancel`、断连时有 ask 但 park 宽限用尽 —— 三件事在终局上**逐字同形**
  * (`failed` + `terminal.code:"cancelled"`),壳只能按 `errorMessage` 文案猜。
@@ -109,7 +109,7 @@ export interface RunCancelContext {
  *  · `cancel_verb`              —— `POST /v1/runs/:id/cancel`:同副本快路、跨副本耐久取消旗的轮询(四条腿的心跳 / 登记追平),
  *                                  以及 park 中的 run 被它直接终局化(那一形不经 abort,成因照样是这条动词)。
  * **刻意不在表里**(普查过、没有真站点):抢占(`preempt` 是优雅让出,终局是 `paused`,不是取消)、有序关停
- * (S-929 只把未决卡转 park,从不中止活 run;进程退出后的行由收割器落「持有者死亡」判决,那不是本仓铸的取消终局)、
+ * ([ref] 只把未决卡转 park,从不中止活 run;进程退出后的行由收割器落「持有者死亡」判决,那不是本仓铸的取消终局)、
  * `interrupt`(引擎的 turn 动词,终局 `completed` + `haltedByUser`)、detach 断连(不中止)。
  *
  * 词表属主 = 本文件(与它所在的 {@link PersistedTaskResult} 同住);**单写者** = `run-cancel-context.ts` 的 `createRunAbort`
@@ -123,7 +123,7 @@ export type AbortCause = (typeof ABORT_CAUSES)[number];
  * 本型是这一族键的**唯一登记处**(`trace/core-keyset-guard.ts` 的辖域线指向这里;那边另有一道编译期钉:
  * core 的 `TaskResult` 哪天长出同名键 ⇒ 当场红 —— 同一个键两个铸者是本型存在要防的那件事)。
  *  · `cancelContext`([ref])—— 取消现场快照(分诊材料:多久没动静、起跑多久);
- *  · `abortCause`(S-947)—— 这次取消是谁 / 什么发起的({@link AbortCause})。
+ *  · `abortCause`([ref])—— 这次取消是谁 / 什么发起的({@link AbortCause})。
  * 两键**同一只铸点**(`mintCancelledResult`)、**同一条在场闸**(「只补空座」:终局就是被那次中止打断的那一条,
  * 才挂;与中止赛跑跑完的终局、引擎自带码的失败一律原样立住、两键都不挂)。差别只在缺席纪律:快照一键都证不出 ⇒ 整只缺席;
  * 成因在铸点那一刻恒已知 ⇒ 取消终局上恒在场。
@@ -141,14 +141,14 @@ export interface PersistedResultSideKeys {
  */
 export type PersistedTaskResult = TaskResult & PersistedResultSideKeys;
 /**
- * 🔴 run 店「持有它的实例丢了」那一判的**行上落款**(S-928 codex r1-F1 提为常量):三只 run 店的 `reapStale` 把心跳过期的 running 行翻成
+ * 🔴 run 店「持有它的实例丢了」那一判的**行上落款**([ref] codex r1-F1 提为常量):三只 run 店的 `reapStale` 把心跳过期的 running 行翻成
  * `failed` 并写下这一句。它是 run 店死亡判决留在行上的证据之一(另一只 = {@link RUN_ORPHANED_ERROR})—— 用户输入受理账本的收敛判词
- * (S-969 L8 起两车道同一只)据 {@link isHolderDeathVerdict} 在 reap **之后**仍能判出「写者死了」—— 7.116.0 起判据是同行的机读码 `run.stalled`({@link RUN_HOLDER_DEATH_CODES}),本句只给人读;三个写者同写句子与码。读时折叠成同一句话的 wire 展示站点
+ * ([ref] L8 起两车道同一只)据 {@link isHolderDeathVerdict} 在 reap **之后**仍能判出「写者死了」—— 7.116.0 起判据是同行的机读码 `run.stalled`({@link RUN_HOLDER_DEATH_CODES}),本句只给人读;三个写者同写句子与码。读时折叠成同一句话的 wire 展示站点
  * (`routes/runs.ts` 的 stale 折叠、`routes/trace-usage.ts` 的 WORKER_DOWN 帧)刻意留字面量:它们由文案冻结门逐字钉着,且不参与任何判据。
  */
 export declare const RUN_STALLED_ERROR = "run stalled (instance lost?)";
 /**
- * 🔴 File 车道「持有它的进程随重启没了」那一判的行上落款(S-969 L8 提为常量):boot 孤儿回收(`FileRunStore.reclaimOrphanedAtBoot`,
+ * 🔴 File 车道「持有它的进程随重启没了」那一判的行上落款([ref] L8 提为常量):boot 孤儿回收(`FileRunStore.reclaimOrphanedAtBoot`,
  * 数据根 LOCK 作证前世进程已死 ⇒ 仍 running 的行无条件判孤儿)与运行期 claim 接管的 running 臂(`judgeClaim`,外来 + owner 已死 + 无可续)
  * 都写这一句;接管臂在括号里附上前任持有者的进程指纹(取证用,形 = {@link buildRunOrphanedError})。与 {@link RUN_STALLED_ERROR} 同一种身份:
  * run 店写在行上的**死亡判决**,读者 = {@link isHolderDeathVerdict}(按同行的机读码 `run.orphaned` 判,本句只给人读)。
@@ -220,7 +220,7 @@ export interface RunRecord {
      *  MY replica" (consult the in-process inflight/steerable map authoritatively) from "held elsewhere" (fall
      *  back to the durable cross-replica flag). null for pre-column rows. */
     instanceId: string | null;
-    /** 🔴 S-230 P-45 —— 这条 run 上**挂没挂着取消请求**(耐久 `cancel_requested` 列的投影,跨副本)。
+    /** 🔴 [ref] P-45 —— 这条 run 上**挂没挂着取消请求**(耐久 `cancel_requested` 列的投影,跨副本)。
      *
      *  语义就是那一列的字节:`POST /v1/runs/:id/cancel` 的 running 臂 CAS 成功即置位,持有副本的心跳拍
      *  poll 到它就 abort;`markResuming`(续跑认领)把它清零 —— 一次撞上 suspend 的取消不许在恢复之后
@@ -325,7 +325,7 @@ export interface InProcessClaimFence {
  *    治理判决:门拒绝那条腿在 core 里走 `paused`/`failed`,永远不铸这个词;
  *  · `parked` —— 停在门上还能再动(`suspended` 审批/资源门、`needs_review` 评审门)。
  *
- * 🔴 为什么是**一张表**而不是三张 switch(S-213③,2026-09-11):`blocked` 这个词此前在本仓有**两个
+ * 🔴 为什么是**一张表**而不是三张 switch([ref]③,2026-09-11):`blocked` 这个词此前在本仓有**两个
  * 独立写者**且答案互斥 —— `observability/run-terminal.ts` 判它是「治理判决,不是失败 ⇒ 不打行」,
  * `fleet/fleet-bus.ts` 判它是「非成功终局(agent 放弃)⇒ failed 桶、行离场」。两处各自穷举、各自正确
  * 地编译,而一条 `report_blocked` 的 run 在面板上离场、在引擎日志里一个字都没有。三张手抄的 switch
@@ -355,20 +355,20 @@ export type UnsuccessfulRunStatus = {
     [K in RunRecord["status"]]: (typeof RUN_STATUS_CLASS)[K] extends "unsuccessful" ? K : never;
 }[RunRecord["status"]];
 /** 表判为「park」(停在门上)的词 —— **从表派生**,不是手抄的第二份清单。今天 = `"suspended" | "needs_review"`。
- *  消费点(S-173:同步提交 200 体的 poll 回执 `status`,`http/sync-submit-body.ts`)拿它当型;表翻面 ⇒ 那里当场红。 */
+ *  消费点([ref]:同步提交 200 体的 poll 回执 `status`,`http/sync-submit-body.ts`)拿它当型;表翻面 ⇒ 那里当场红。 */
 export type ParkedRunStatus = {
     [K in RunRecord["status"]]: (typeof RUN_STATUS_CLASS)[K] extends "parked" ? K : never;
 }[RunRecord["status"]];
 /**
  * 一个状态词的类;**表里没有的词 ⇒ `undefined`**。
  *
- * 🔴 形参是 `string` 而不是 `RunRecord["status"]`(S-221):本函数的**全部工作**就是「这个词在不在表里」,
+ * 🔴 形参是 `string` 而不是 `RunRecord["status"]`([ref]):本函数的**全部工作**就是「这个词在不在表里」,
  * 把入参收成闭集等于在签名上宣称「传进来的一定是表内词」,而下一行的 `undefined` 臂正是为了不是的那些 ——
  * 签名与实现自相矛盾时,消费点只能靠 `as RunRecord["status"]` 硬转把窄读口(`{ status: string }`,
  * 三形 store 共同面)喂进来,而那正是本文件头注点名的 `rowToRun` 裸 cast 的同一条病。闭集词照样能传
  * (联合 ⊂ string),编译期的执法点在上面那张表的双向钉,不在这里。
  *
- * 导出面(S-221):`plugins/e2b-orphan-reclaim.ts` 的三臂判决(还能再动 / 终局 / 读不懂)需要的正是
+ * 导出面([ref]):`plugins/e2b-orphan-reclaim.ts` 的三臂判决(还能再动 / 终局 / 读不懂)需要的正是
  * 「类 + unknown」这一对,而不是三条 boolean 谓词各问一遍 —— 它此前因此自带了第二份词表。
  *
  * 🔴 查的是 **null 原型**的那只表,不是 `RUN_STATUS_CLASS` 本身(codex 对抗复审 r1 [high],亲验后修):
@@ -395,7 +395,7 @@ export declare function runStatusClassOf(status: string): RunStatusClass | undef
  */
 export declare function isTerminalRunStatus(status: RunRecord["status"]): boolean;
 /**
- * 「这一行的终局是**非成功**的吗」(S-213③ 的共享判据)——`failed` 与 `blocked` 两词。
+ * 「这一行的终局是**非成功**的吗」([ref]③ 的共享判据)——`failed` 与 `blocked` 两词。
  *
  * 🔴 它回答的问题与 {@link isTerminalRunStatus} **不同**:后者只问「还会不会再动」,本判据问「这次任务
  * 到底成没成」。凡是「这条 run 该不该在失败面上出声/离场」的判断都读这一条,不许再手抄
@@ -434,7 +434,7 @@ export declare function isParkedRunStatus(status: RunRecord["status"]): boolean;
  *    它不是「我知道它闲着」,所以不许铸出 `idle` 这个断言;
  *  · 读不懂的词(滚动升级里新副本写入的新状态词经裸 cast 读到本进程)同判 —— 与
  *    {@link isTerminalRunStatus} 族的保守方向一致。
- *  · **缺席怎么渲染是 core 的辖域,本仓一个字都不复述**(S-514-JU:此处原写着「core 对缺席渲染成 `idle`」
+ *  · **缺席怎么渲染是 core 的辖域,本仓一个字都不复述**([ref]-JU:此处原写着「core 对缺席渲染成 `idle`」
  *    并抄了当时 `list-agents-tool.js` 的旧三元 —— core 7.24.0 [ref] 把那一臂改成了一张 own-key 表 +
  *    `unknown` 兜底,于是那句复述当天就成了假话,而它在本仓被抄了六处)。本表只负责**铸不铸键**;
  *    渲染词由**跑真 core 的黑盒**钉住(`test/peer-lane-e2e.test.ts` 的 G1 格),core 哪天再改那张表,
@@ -453,7 +453,7 @@ export declare const SESSION_TEMPO_BY_RUN_CLASS: {
  *  返回词缺席 ⇒ 调用方**不铸键**(不是铸 `idle`),理由逐字见上表头注。 */
 export declare function sessionTempoOfRunStatus(lastStatus: string): PeerSessionTempo | undefined;
 /**
- * 「**证得出**这条 run 活在别的副本上」——「他副本」那一句话的**唯一判据**(S-381 收编;S-430 迁居)。
+ * 「**证得出**这条 run 活在别的副本上」——「他副本」那一句话的**唯一判据**([ref] 收编;[ref] 迁居)。
  *
  * 成案:这个合取式此前在四处**逐字手抄**(`http/routes/runs.ts` 的 steer 臂与 interrupt 臂、同文件
  * `sendHandleMiss`、`http/routes/run-memory-capture.ts`),`POST /v1/sessions/:id/mcp/reconnect` 是第五处、`fleet/fleet-reconciler.ts` 是第六处 ——
@@ -466,7 +466,7 @@ export declare function sessionTempoOfRunStatus(lastStatus: string): PeerSession
  * `sendHandleMiss` 只对 `running` 行说这句话,而 steer 族在 park/终态两臂之后才走到这里 —— 各调用点
  * 的前置臂不同族,合进来会让某一处悄悄改判。
  *
- * 🔴 **为什么住在这里而不是 `http/route-ctx.ts`**(S-430):`src/fleet/fleet-reconciler.ts` 是第六个手抄点,
+ * 🔴 **为什么住在这里而不是 `http/route-ctx.ts`**([ref]):`src/fleet/fleet-reconciler.ts` 是第六个手抄点,
  * 而 `src/fleet/` 今天对 `src/http/` **零依赖**(边向恒是 http → fleet)。把消费方拉去 http 取一只纯谓词
  * 会凭空造一条反向装载边;而本文件正是 {@link RunRecord} 与它的兄弟谓词({@link isTerminalRunStatus} /
  * {@link isParkedRunStatus})的所在 —— 「关于 run 行的判词」本来就该在行的属主这里,http 与 fleet 都已经
@@ -492,7 +492,7 @@ export interface SessionSummary {
      *  hop (`GET /v1/runs/:lastRunId/events`) when resuming a picked session, instead of a second lookup. */
     lastRunId: string | null;
     /** [ref]([ref]/[ref]):latest run 的 engine runId(`TaskResult.runId`,latest.result JSON 提取的
-     *  零迁移路线 —— result 在终局与 park 时写、认领续跑即清空(S-173)⇒ 在跑 run 键诚实缺席);OMIT-when-absent,恒不铸 null。轴辨析与
+     *  零迁移路线 —— result 在终局与 park 时写、认领续跑即清空([ref])⇒ 在跑 run 键诚实缺席);OMIT-when-absent,恒不铸 null。轴辨析与
      *  wire 半场见 `security.ts SessionListItem.lastTaskRunId`(同名同义)。 */
     lastTaskRunId?: string;
     /** The session's title: the user's (`patchSessionMeta`, unconditional; `null` clears it back to automatic) or the auto-titler's
@@ -504,7 +504,7 @@ export interface SessionSummary {
     pinned: boolean;
 }
 /**
- * S-1371 —— 会话**枚举面**读 run 账里「每会话的 run 投影」的窄读面:`runCount` / `lastStatus` / `lastRunId` / `lastTaskRunId` 四位,
+ * [ref] —— 会话**枚举面**读 run 账里「每会话的 run 投影」的窄读面:`runCount` / `lastStatus` / `lastRunId` / `lastTaskRunId` 四位,
  * 同一次读、同一条「最新一条」的口径。
  *
  * 为什么是 run 店自己的 `listSessions`、不另造一只读口:这四位在 SQL 双生里就是 `task_run` 的 `rn=1` JOIN(计数、最新一条的状态与 task_id、
@@ -521,7 +521,7 @@ export interface SessionRunRollupSource {
     }): Promise<ReadonlyArray<Pick<SessionSummary, "sessionId" | "runCount" | "lastStatus" | "lastRunId" | "lastTaskRunId">>>;
 }
 /**
- * S-297 —— 「这个会话**最近一条腿**是哪一条 run」的窄读面(`latestRunForSession` 的回值)。
+ * [ref] —— 「这个会话**最近一条腿**是哪一条 run」的窄读面(`latestRunForSession` 的回值)。
  *
  * 刻意**不是** {@link RunRecord}:那一形携 `result` 整只 blob,而本读面的三个消费点(run 身份 / 属主门 /
  * 排序口径的自证)一个都用不到它 —— 与 `listSessions` 只提标量 `lastTaskRunId` 而不拉 `result` 是同一条

package/dist/plugins/task-attachment-store.d.ts

@@ -31,7 +31,7 @@ import { type IndexSpec } from "./ensure-index.js";
 /**
  * 一条附件 meta 的**形属主**(整仓唯一那份键集)。
  *
- * 🔴 为什么是一只 schema 而不只是一个 interface(S-550 车③b):SQL 车道把这些字段拆成**标量列**,
+ * 🔴 为什么是一只 schema 而不只是一个 interface([ref] 车③b):SQL 车道把这些字段拆成**标量列**,
  * 形由 DDL 管;local 车道把整条记录**序列化成一个 JSON 档**(`attachments/<id>.json`),于是它需要一个
  * 运行期的形判据 —— 而那个判据必须与这里的键集是**同一份**(第二份键集分叉的那天 = 「写得进、读不出」)。
  * 所以类型从 schema 推导({@link TaskAttachmentRecord}),两者按构造不可能漂。
@@ -126,7 +126,7 @@ export declare function materializeAttachmentsInto(env: {
     }>;
 }, store: TaskAttachmentStore, sessionId: string): Promise<number>;
 export declare function ensureTiDBTaskAttachmentSchema(pool: Pool): Promise<void>;
-/** S-287:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgTaskAttachmentSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
+/** [ref]:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgTaskAttachmentSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
 export declare const TASK_ATTACHMENT_INDEXES: readonly IndexSpec[];
 export declare function ensurePgTaskAttachmentSchema(q: PgQueryFn): Promise<void>;
 /** bytes → 4 MiB 块序列(共享切块器,两方言 + 完整性校验共用)。 */

package/dist/plugins/task-list-store-sql.d.ts

@@ -27,7 +27,7 @@ export declare const TASK_LIST_ITEM_TABLE = "task_list_item";
  */
 export declare function taskListKeyFor(sessionId: string): string;
 /**
- * `task_list_item.item_json` 的**形读者**(S-550)。
+ * `task_list_item.item_json` 的**形读者**([ref])。
  *
  * 🔴 判据刻意只到「一只 JSON 对象 + 一把串 id」为止,**不复刻 core 的 `TaskListItem` 键表**:那张表的
  * 属主在 core(`tools/task-list.d.ts`),而 core 今天没有导出验证器 —— 在这里手写一份等价 schema 就是