@sema-agent/server 7.133.0 → 7.135.0

package/dist/plugins/remote-shell.d.ts

@@ -25,10 +25,10 @@ export declare function armPipeDestroyGrace(child: ChildProcess): ReturnType<typ
 /** POSIX single-quote a string for safe interpolation into a remote shell command (the only metacharacter
  *  inside '' is ' itself, closed/escaped/reopened). */
 export declare function shellQuote(s: string): string;
-/** S-410:cwd 守卫在**远端**的退出码 —— 包装层自己失败、命令没跑(POSIX 包装工具 `env(1)` / `nohup(1)` / `timeout(1)` 的惯用码;126 / 127 是 shell
+/** [ref]:cwd 守卫在**远端**的退出码 —— 包装层自己失败、命令没跑(POSIX 包装工具 `env(1)` / `nohup(1)` / `timeout(1)` 的惯用码;126 / 127 是 shell
  *  自己的「不可执行 / 找不到」)。buffered `exec` 经 {@link createCwdGuardedCall} 把它收成 `spawn_error`(车PL);命令自己也可能退 125,判别见那只函数。 */
 export declare const CWD_UNAVAILABLE_EXIT = 125;
-/** S-410:cwd 守卫触发时写进 stderr 的那一行的开头(后接 ` [<nonce>]: <目录> (cd failed; command not run)`),也是 `spawn_error` 消息的主句。 */
+/** [ref]:cwd 守卫触发时写进 stderr 的那一行的开头(后接 ` [<nonce>]: <目录> (cd failed; command not run)`),也是 `spawn_error` 消息的主句。 */
 export declare const CWD_UNAVAILABLE_LINE = "sema: working directory unavailable";
 /** 车PL 验修 ②:settled 面上 cd 成功之后、命令之前打到 stderr 的那一行的开头(后接 ` [<同一 nonce>]`)。腿在交出之前把它剥掉。 */
 export declare const CWD_STARTED_LINE = "sema: command started";
@@ -57,7 +57,7 @@ export interface CwdEnvCommand {
  */
 export type CwdGuardFace = "settled" | "raw";
 /**
- * 🔴 S-410(7.103.1)—— 三条远端 shell 腿(ssh / k8s / adb)交给远端 `sh -c` 的那一串**唯一**的组装:进工作目录 →(settled 面)打 started 行 →
+ * 🔴 [ref](7.103.1)—— 三条远端 shell 腿(ssh / k8s / adb)交给远端 `sh -c` 的那一串**唯一**的组装:进工作目录 →(settled 面)打 started 行 →
  * 导出任务 env → 跑命令。各腿只决定 `dir`(自己的缺省 cwd 规则 + 路径绝对化),串的形状只在这里。
  *
  * 形:`cd '<dir>' || { echo '<marker>: <dir> (cd failed; command not run)' >&2; exit 125; }; echo '<started>' >&2; export K='v'; … <command>`
@@ -109,7 +109,7 @@ export interface CwdGuardedCall extends CwdStartedStderrFilter {
  * (<cd 自己的话>)")`。
  *
  * 为什么是 spawn_error:core 的 ExecutionEnv 契约把「命令没跑(死 cwd 在列)」给了它;core 的 Bash 工具只在 `spawn_error` / `shell_unavailable` 上
- * 走死 cwd 诊断(`diagnoseDeadCwd`:目录真没了 ⇒ 复位到任务根、答「reset to <root>; re-run」)。S-410 初版把同一形报成 `{ ok:true, exitCode:125 }`,
+ * 走死 cwd 诊断(`diagnoseDeadCwd`:目录真没了 ⇒ 复位到任务根、答「reset to <root>; re-run」)。[ref] 初版把同一形报成 `{ ok:true, exitCode:125 }`,
  * core 读作命令自己失败 ⇒ cwd 不复位,前缀又挡在模型自救的 `cd` / `mkdir` 前面 ⇒ 本轮后续 Bash 全退 125。host 腿(`remote-env-host.ts` 的
  * `child.on("error")`)本就报 `spawn_error`,四条腿一条规则。
  *
@@ -146,7 +146,7 @@ export declare function numEnvOr(name: string, def: number, min: number): number
  *
  * 🔴 **整条命令包在一个 `{ …; }` 里**,让它**只有一个退出状态**,不依赖调用方加的前缀是什么形。今天三条远端 shell 腿的文件面探针
  *   (本命令经 `PosixShellFs` 发出)**不带 cwd**(车PL 验修 ③:只用绝对路径,不进目录 ⇒ 前面没有 {@link buildCwdEnvCommand} 的守卫前缀);
- *   local-docker 用 `docker exec -w <dir>`,e2b 走 SDK 的 `cwd`,都不拼前缀。S-410 之前三条远端腿给它拼过 `cd <dir> && <命令>`,在那个形下
+ *   local-docker 用 `docker exec -w <dir>`,e2b 走 SDK 的 `cwd`,都不拼前缀。[ref] 之前三条远端腿给它拼过 `cd <dir> && <命令>`,在那个形下
  *   这里连着犯过两次错,记下来是因为它们是**同一个坑的两面**,换任何一种链式前缀都会再来:
  *   · 写成 `command -v … || { …; }`:`||` 与前缀的 `&&` 结成一条链(`cd X && command -v … || { … }`),
  *     **`cd` 失败时跑的是探测的失败臂** —— 报「readlink 不在」而真相是「那个目录没了」,运维去修一个没坏的东西;
@@ -165,7 +165,7 @@ export declare function buildSymlinkChainCommand(absPath: string): string;
  *
  * 三件事**只在这里**做一次(四条 shell 腿 + e2b 共读):
  *  · **环即止** —— 出现重复跳时在**重复的那一跳之前**截断(CC `vr` 的 `d.has(u)` 同律),且 seen 表用
- *    **被寻址的拼法播种**(S-408,core 裁 2026-09-17:契约句「不重复被寻址的拼法」的正解是**起点本身不是一跳**——
+ *    **被寻址的拼法播种**([ref],core 裁 2026-09-17:契约句「不重复被寻址的拼法」的正解是**起点本身不是一跳**——
  *    链视图列的是「从被寻址拼法出发经过的中间拼法」,链绕回起点即结束、起点不再列;成环的事实由终点判决
  *    `canonicalPath`(realpath ELOOP ⇒ unresolvable ⇒ 拒)承担,不由链视图承担)。于是 `a -> b`、`b -> a`,问 `a`,
  *    答 `[b]`,与 core `NodeExecutionEnv.canonicalChain`(`new Set([resolved])` 播种)逐字节同形。此前本族从空表

package/dist/plugins/retention-lane-store-sql.d.ts

@@ -15,9 +15,9 @@
  *
  * ── 方言差异台账(显式,永不藏进抽象;A12 判据)───────────────────────────────────────────────────
  *   - `?` 占位符 vs `$n`;
- *   - 幂等建行(哨兵形 A,S-127):`ON DUPLICATE KEY UPDATE <pk> = <pk>` vs `ON CONFLICT (…) DO NOTHING`
+ *   - 幂等建行(哨兵形 A,[ref]):`ON DUPLICATE KEY UPDATE <pk> = <pk>` vs `ON CONFLICT (…) DO NOTHING`
  *     —— MySQL 侧刻意**不用** `INSERT IGNORE`:重复键的 IGNORE 取 S 锁,与随后的 `FOR UPDATE` 之间是
- *     S→X 升级,InnoDB 上两并发事务互等即 ER_LOCK_DEADLOCK(B-013);ON DUPLICATE 的重复键取的就是 X;
+ *     S→X 升级,InnoDB 上两并发事务互等即 ER_LOCK_DEADLOCK([ref]);ON DUPLICATE 的重复键取的就是 X;
  *   - upsert:`ON DUPLICATE KEY UPDATE col = VALUES(col)` vs `ON CONFLICT (…) DO UPDATE SET col = EXCLUDED.col`;
  *   - 条件自增:`IF(cond, 0, 1)` vs `CASE WHEN cond THEN 0 ELSE 1 END`(本文件不用 —— 见 `acquire` 顶注:
  *     自增判据在**应用层**算,因为它同时要产出返回给调用方的 token);
@@ -124,9 +124,9 @@ export declare class SqlRetentionLaneStore implements RetentionLaneStore {
      * **本 tick 零写静默跳过**。
      *
      * 事务三步,一步不能省:
-     *  ① 幂等建一条 `expires_at_ms = 0` 的**哨兵行**(形 A,S-127:MySQL `ON DUPLICATE KEY UPDATE
+     *  ① 幂等建一条 `expires_at_ms = 0` 的**哨兵行**(形 A,[ref]:MySQL `ON DUPLICATE KEY UPDATE
      *     singleton = singleton` / PG `ON CONFLICT DO NOTHING`)—— 它永远不会改写一条既存租约(两方言的这
-     *     两个动词都只在缺行时写),且重复键取的是 **X** 锁,与 ② 的 `FOR UPDATE` 同锁模式(B-013:
+     *     两个动词都只在缺行时写),且重复键取的是 **X** 锁,与 ② 的 `FOR UPDATE` 同锁模式([ref]:
      *     `INSERT IGNORE` 在这里取 S 再升 X,InnoDB 上两副本抢租互等直接死锁);
      *  ② `SELECT … FOR UPDATE` —— 行现在必定存在,锁真的拿得到;
      *  ③ 判 + `UPDATE`,同事务提交。

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

@@ -28,7 +28,7 @@
  * ── 方言差异台账(显式,永不藏进抽象;A12 判据)───────────────────────────────────────────────────
  *   - `?` 占位符 vs `$n`;多值集合 MySQL 用 `IN (?,?,…)`、PG 用 `= ANY($n::text[])`(先例:
  *     workflow-run-store-sql 的 reap)
- *   - 幂等建行:哨兵形(形 A,S-127)`ON DUPLICATE KEY UPDATE <pk> = <pk>` vs `ON CONFLICT (…) DO NOTHING`
+ *   - 幂等建行:哨兵形(形 A,[ref])`ON DUPLICATE KEY UPDATE <pk> = <pk>` vs `ON CONFLICT (…) DO NOTHING`
  *     —— 随后有同行 `FOR UPDATE` 的建行**必须**用 ON DUPLICATE(重复键取 X,同锁模式);墓碑那种
  *     「只读 affected 不加锁读」的写点(形 B)才保留 `INSERT IGNORE`
  *   - 级联 DELETE 的 JOIN 形:`DELETE te FROM a te JOIN b …` vs `DELETE FROM a te USING b …`
@@ -92,7 +92,7 @@ export declare const TIDB_RETENTION_STATEMENTS: readonly string[];
 /** PG 方言的建表语句(MySQL 孪生的逐条翻译:AUTO_INCREMENT→BIGSERIAL,逐列 `COLLATE "C"`,内联 KEY→独立
  *  CREATE INDEX)。语义逐字见 MySQL 孪生的行内注,此处不复述(两份注释迟早分叉)。 */
 export declare const PG_RETENTION_SCHEMA: readonly string[];
-/** S-287:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgRetentionSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
+/** [ref]:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgRetentionSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
 export declare const RETENTION_INDEXES: readonly IndexSpec[];
 /** PG 侧的幂等 schema apply(由 `pg-pool.ts` 的中央 `ensurePgSchema` 组合;裸 `PgQueryFn` 形,与
  *  approval-ask / leader-run 同姿势 —— DDL 仍跑在中央那条 client 上,advisory lock 的 session 语义不受影响)。 */
@@ -211,10 +211,10 @@ export declare class SqlRetentionStore implements ManagedRetentionCapability {
      * 事务**首步**:拿本域的互斥行锁,并读出「这个域是不是冻结中」(§5 F2 承重)。
      *
      * 两步,缺一不可:
-     *  ① 幂等建一条 `held = 0` 的**哨兵行**(形 A,S-127:MySQL `ON DUPLICATE KEY UPDATE domain = domain` /
+     *  ① 幂等建一条 `held = 0` 的**哨兵行**(形 A,[ref]:MySQL `ON DUPLICATE KEY UPDATE domain = domain` /
      *     PG `ON CONFLICT DO NOTHING`)—— 它永远不会改写一条既存的 hold(两方言的这两个动词都只在缺行时
      *     写),只保证**接下来那把行锁有东西可锁**;重复键取的是 **X** 锁,与 ② 的 `FOR UPDATE` 同锁模式
-     *     (`INSERT IGNORE` 在这里取 S 再升 X = InnoDB 上两个并发 sweep 互等的死锁形,B-013);
+     *     (`INSERT IGNORE` 在这里取 S 再升 X = InnoDB 上两个并发 sweep 互等的死锁形,[ref]);
      *  ② `SELECT held … FOR UPDATE` —— 现在这行必定存在,于是锁真的拿到了。
      *
      * 🔴 为什么必须先造行(codex 交叉复审 R1-[high],验真后改):`FOR UPDATE` 锁不住缺席行(TiDB 无 gap

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

@@ -26,7 +26,7 @@ import type { PgQueryFn } from "./pg-query.js";
 import { type IndexSpec } from "./ensure-index.js";
 export declare const ROSTER_TABLE = "agent_roster";
 export declare function ensureTiDBRosterSchema(pool: Pool): Promise<void>;
-/** S-287:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgRosterSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
+/** [ref]:本 store 的索引**声明**(两方言共用一份)。PG 侧由下面的 `ensurePgRosterSchema` 应用,MySQL 侧由 `tidb-pool.ts` 的中央 `ensureSchema` 应用(那里内联 `KEY` 已在 `CREATE TABLE` 里 ⇒ 新建库探到即零 DDL,存量库缺谁补谁)。加索引以外的 schema 变更仍归运维,见 `plugins/ensure-index.ts` 头注。 */
 export declare const ROSTER_INDEXES: readonly IndexSpec[];
 export declare function ensurePgRosterSchema(q: PgQueryFn): Promise<void>;
 export declare class TiDBRosterStore implements RosterStore {

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

@@ -121,7 +121,7 @@ export declare class SqlRunStore {
      * KEEPS the `task_active` claim — the session stays locked (no new run) until an operator resumes it to a
      * terminal state or the reaper expires it.
      *
-     * 🔴 S-173:park 也落 `result` 列 —— 存的是**摘掉恢复凭据、脱过敏的投影**(`sealRunRowResult`,与 `setTerminal`
+     * 🔴 [ref]:park 也落 `result` 列 —— 存的是**摘掉恢复凭据、脱过敏的投影**(`sealRunRowResult`,与 `setTerminal`
      * 同一只入口、同列同序列化),不是引擎交出的原件:`paused.token` / `failed.nestedPause.token` 两座在落列前摘掉,
      * 所以 poll 这一行的调用方(`GET /v1/runs/:id → result`)拿到的是「停在哪扇门上」而拿不到 resume 能力。
      * `result = null` = 这条腿没观察到 park 结果(断连竞态 / 重开 re-park),列写空 —— 与修前行形同。
@@ -175,7 +175,7 @@ export declare class SqlRunStore {
     getActiveTaskId(sessionId: string): Promise<string | undefined>;
     /** Shared row→record mapper — byte-identical between dialects (both drivers hand back the same column
      *  names + comparable JS types after SqlDriver's result normalization).
-     *  🔴 **读它的每一条查询都必须选 {@link runRowCols}**(S-230):映射器对「没被 SELECT 的列」是
+     *  🔴 **读它的每一条查询都必须选 {@link runRowCols}**([ref]):映射器对「没被 SELECT 的列」是
      *  结构性失明的 —— `undefined ?? null` 与 `Boolean(undefined)` 都会安静地铸出一个**看上去合法的假值**。
      *  修前 `listRuns` 的两条方言臂就漏选 `instance_id`,于是列表面的每一行 `instanceId` 恒 `null`
      *  (今天没有消费点,所以没人发现)。列表收成一个常量 = 这类漏选从此不可能发生。 */
@@ -208,7 +208,7 @@ export declare class SqlRunStore {
      *  the very placeholder-numbering divergence this file exists to keep visible. */
     listRuns(opts: RunListQuery): Promise<RunRecord[]>;
     /**
-     * S-297 —— 这个会话**最近一条腿**的窄指针(`/mcp` 面板的 `lastLegMcp` 与任何「上一条 run 是谁」的读面共用)。
+     * [ref] —— 这个会话**最近一条腿**的窄指针(`/mcp` 面板的 `lastLegMcp` 与任何「上一条 run 是谁」的读面共用)。
      *
      * 排序口径与 {@link listSessions} 的 `rn=1` 窗函数**逐字同一句**(`created_at DESC, task_id DESC`)——
      * 两处答的是同一个问题「哪一条是最新的」,口径分叉会让列表面的 `lastRunId` 与本读口指向不同的 run。
@@ -252,12 +252,12 @@ export declare class SqlRunStore {
      * 那批,具名那批连同它们的 task_event 全部存活 —— 而 `session_meta` 已经删了,留存腿的 sessionCandidates
      * 再也枚举不到这棵树 ⇒ 孤儿行**没有任何清理路径**,路由却回 `{deleted:true}`。那就是一次**报成成功的
      * 右删失效**(anchors 腿的注逐字写着这句)。删除决策的属主门在**路由层**(DELETE /v1/sessions/:id 先
-     * `ownerOf` 再比对 scope,fleet-wide 臂同门),本方法的唯一生产调用点是那条路由后面的 purge 协调器。
+     * 经会话店唯一的按 id 读 `headOf` 取属主再比对 scope,fleet-wide 臂同门),本方法的唯一生产调用点是那条路由后面的 purge 协调器。
      *
      * 🔴 **化身围栏**(`expectedSessionOwner`;codex 交叉复审 R1-[high],验真后修)—— 属主门下来了,但会话
      * **身份**必须在同一个事务里重新确认。会话 id 由调用方自选、且删除之后**可被别人重新登记**
      * (`register` 是 INSERT … ON DUPLICATE KEY / ON CONFLICT,老行没了就是一条新行,新 owner):于是
-     * 「路由 `ownerOf` 已验权」这句话在两只并发 purge 交错时会过期 —— A 与 A' 同时通过属主门,A' 跑完整条
+     * 「路由已按 `headOf` 读到的属主验权」这句话在两只并发 purge 交错时会过期 —— A 与 A' 同时通过属主门,A' 跑完整条
      * purge 把 meta 删掉,租户 B 用同一个 uuid 重新登记并跑完一次 run,慢半拍的 A 才走到这里 ⇒ 按 session_id
      * 单键删就把 **B 的**行删了(修前的行级属主门恰好挡住这一形,因为 B 的行 owner≠A 的会话主)。
      * ⇒ 事务头部 `SELECT owner FROM session_meta WHERE session_id = ? FOR UPDATE`,行不在或 owner 与路由验过的
@@ -304,7 +304,7 @@ export declare class SqlRunStore {
     }>;
     /** Earliest retained event seq for a task (0 if none) → the `retainedFrom` field of `GET /v1/tasks/:id/turns`.
      *  Not an eviction boundary: the ledger has no partial head trim (the only deletion takes the whole session tree),
-     *  so a value > 1 means head rows whose write failed after consuming their seq (S-211 ①). */
+     *  so a value > 1 means head rows whose write failed after consuming their seq ([ref] ①). */
     retainedFrom(taskId: string): Promise<number>;
     /** Events with seq strictly greater than `afterSeq` (use 0 for the whole stream). */
     getEvents(taskId: string, afterSeq: number): Promise<RunEvent[]>;
@@ -348,9 +348,9 @@ export declare class SqlRunStore {
      *
      * Same alias-qualification divergence as {@link reapSuspended} — see its header note.
      *
-     * S-173:两条收割腿都把 `result` 列写回 NULL —— park 行上那份 park 结果(`terminal.kind:"paused"`)说的是
+     * [ref]:两条收割腿都把 `result` 列写回 NULL —— park 行上那份 park 结果(`terminal.kind:"paused"`)说的是
      * 「停在门上」,而这一刻行被打成 `failed`/`approval.expired`;留着它 = 一行两句互相矛盾的话(读面还会从它
-     * 投出 `review.pending` 之类的 park 码)。收割后的行形因此与 S-173 之前逐字同(结果空,码在 error_code 列)。
+     * 投出 `review.pending` 之类的 park 码)。收割后的行形因此与 [ref] 之前逐字同(结果空,码在 error_code 列)。
      */
     failSuspendedWithExpiredCheckpoint(): Promise<number>;
 }

package/dist/plugins/schema-consistency.d.ts

@@ -1,5 +1,5 @@
 /**
- * **启动期「库 ≟ 代码」列集对账探针**(S-547)—— 存量库缺列/多列一律**响亮拒启**。
+ * **启动期「库 ≟ 代码」列集对账探针**([ref])—— 存量库缺列/多列一律**响亮拒启**。
  *
  * ── 病(test T-47 三库一致的真读数)───────────────────────────────────────────────────────────────
  * 7.91.2 建的 `session_policy`(那时还没有 `gen` 列)+ 一行数据,7.92.0 的二进制接上去:`CREATE TABLE
@@ -44,7 +44,7 @@
  * (探针先于它的第一条 CREATE)—— 一次会拒的起服不许先在库里建出几十张本版新表(`task_run` 还带着新列),否则拒句里「没动过库」就是假话,
  * 按拒句指路去 7.125.x 起服的人会撞上「库比 7.125.x 新」的第二道拒。嵌入方走公开序列 `createStoreBackend()` → `ensureSchema()` → `runOneTimeMigrations()`
  * 即得到这一问,零动作。
- * 残余(如实):运维在第一次起带迁移的版本之前就把两件退役 schema 都手工删掉的库,残留的旧拼法由门记录的读腿接住 —— 7.129.0 起(core 7.51.0 #1731)
+ * 残余(如实):运维在第一次起带迁移的版本之前就把两件退役 schema 都手工删掉的库,残留的旧拼法由门记录的读腿接住 —— 7.129.0 起(core 7.51.0 [ref])
  * 那只读腿按 core 的档案读法读,`unresolvable` 是 core 退役词注册表里的词 ⇒ 记录原词原样读回、不改写(`trace/project.ts` `screenedGate`);local 文件车道
  * 没有表与列,没有这一问 —— 引擎 File 店里已决 checkpoint 的记录按契约物理不可变,本仓没有合法缝改写它们,同由那条读腿接住。
  */

package/dist/plugins/schema-ensure-legs.d.ts

@@ -5,7 +5,7 @@ export type SchemaDialect = "mysql" | "pg";
 export declare const LOCK_RE: RegExp;
 /**
  * **「一个新库对 ensure 探针怎么答」的唯一属主**(合并复审 车HB 后收口:此前生成器录制器、`test/ensure-schema.test.ts`
- * 的假池、`test/schema-baseline-generated.test.ts` ③c 的假驱动各抄一份,S-287 加了索引探针 + PG 锁改 `got === true`
+ * 的假池、`test/schema-baseline-generated.test.ts` ③c 的假驱动各抄一份,[ref] 加了索引探针 + PG 锁改 `got === true`
  * 之后三份各漂一处 —— 假池答零行诱发 68 条 ALTER、③c 答 `got: 1` 让 PG 锁永远拿不到)。
  * 返回 `undefined` = 不是探针,由调用方录制 / 执行;三条例外的理由见上面三条正则的注。
  */
@@ -18,7 +18,7 @@ export declare function answerEnsureProbe(text: string): {
  * (`scripts/db-lane-warm.ts` 的按车分库暖库)实现同一组签名 ⇒ {@link MYSQL_LEGS} / {@link PG_LEGS} 是这
  * 两条用途的**单源**:加一条 boot ensure 腿只改那两个数组一处,基线生成与车道库暖库同时跟上。
  *
- * 为什么必须单源(S-285/S-256/S-343 真案):暖库此前手抄了「中央两条」(`ensureSchema`/`ensurePgSchema`),
+ * 为什么必须单源([ref]/[ref]/[ref] 真案):暖库此前手抄了「中央两条」(`ensureSchema`/`ensurePgSchema`),
  * 其余 per-store 腿(现值 mysql 10 / pg 11)在**新建的**车道库上从没被建过 ⇒ 新车道首跑几十格红,而发车机那只老库因为历史上
  * 被跑过一次就有表,于是这个缺口在老库上**恒绿**。两张手抄清单迟早分叉,正是本仓反复吃的亏。
  */
@@ -36,7 +36,7 @@ export interface EnsureDriver {
  * 就是这么漏掉一整张表的 —— 那种漏在两条方言上**同时**发生,判据 ④ 的方言对拍完美对称 ⇒ 永不报警)。
  * ⇒ 遍历与自报清单必须同一份数组,否则清单会自己腐掉,对账就成了自说自话。
  *
- * 第三个消费方(S-285/S-256/S-343):`scripts/db-lane-warm.ts` 拿**同一份数组**对真库跑一遍 ⇒ 按车分库的
+ * 第三个消费方([ref]/[ref]/[ref]):`scripts/db-lane-warm.ts` 拿**同一份数组**对真库跑一遍 ⇒ 按车分库的
  * 新库与生产 boot 建出同一套表。判据 ③c 钉住「warm 跑过的腿名 == 本清单」,任何人把它抄成第二份就当场红。
  */
 export interface EnsureLeg {

package/dist/plugins/schema-indexes.d.ts

@@ -1,6 +1,6 @@
 /**
  * 中央 schema(`tidb-pool.ts` 的 `SCHEMA_STATEMENTS` ⇄ `pg-pool.ts` 的 `PG_SCHEMA_STATEMENTS` 这一对孪生)
- * 所拥有的那批表的索引**声明** —— S-287,两方言**共用同一份**。
+ * 所拥有的那批表的索引**声明** —— [ref],两方言**共用同一份**。
  *
  * ## 为什么自成一个模块
  * 两只池各自 `import` 了自己的驱动(`mysql2/promise` / `pg`,都是**值**导入)。若把这份声明放进其中一只,

package/dist/plugins/schema-live-columns.d.ts

@@ -1,5 +1,5 @@
 /**
- * 库里**实际**的列集 —— 唯一读者(S-547 列册探针 `schema-consistency.ts` 的对账读它;`ensure-index.ts` 的索引补建在失败之后判「是不是这张表
+ * 库里**实际**的列集 —— 唯一读者([ref] 列册探针 `schema-consistency.ts` 的对账读它;`ensure-index.ts` 的索引补建在失败之后判「是不是这张表
  * 缺这条索引的列」也读它)。叶子模块:不值依赖任何模块(列册探针那边经录制驱动 / 建表腿值依赖 `ensure-index.ts`,读者若住在那边,
  * `ensure-index.ts` 读它就是一个运行时环)。方言词是 `ensure-index.ts` 的闭集(类型边,擦除)。
  */

package/dist/plugins/session-event-payload.d.ts

@@ -1,11 +1,11 @@
 /**
- * **`session_event.payload` 这一列的单一属主**(S-550 车③a)—— 投影铸点、解码点、形读者各一份,三个
+ * **`session_event.payload` 这一列的单一属主**([ref] 车③a)—— 投影铸点、解码点、形读者各一份,三个
  * 会话存储腿(`tidb-session-storage.ts` / `pg-session-storage.ts` / `tidb-session-store.ts`)共读本文件。
  *
  * ## 为什么必须收成一处
  * 这一列此前有 **10 个** 各自写一遍的读法(`typeof p === "string" ? JSON.parse(p) : p as SessionTreeEntry`),
  * 分布在三个文件的 wake / getEntry / getEpochAnchor / computeFloor / export / fork / import / 收尾 leaf
- * 计算上。那个三元式正是 S-550 要消灭的歧义本身:**从值本身分不出驱动解过没解过**,而这一列在 MySQL 侧是
+ * 计算上。那个三元式正是 [ref] 要消灭的歧义本身:**从值本身分不出驱动解过没解过**,而这一列在 MySQL 侧是
  * `JSON`、PG 侧是 `JSONB` —— 一台 MariaDB 部署上它以文本到达(驱动不自动解码),一条被迁移脚本多
  * `JSON.stringify` 过一次的行则在真 JSON 列上「串就再解一次」地被读成好体。十份拷贝里只要有一份将来
  * 忘了跟,那一条 wake 就会静默读出半棵树。
@@ -16,9 +16,9 @@
  * 静默跳过它则是**一段对话从历史里消失**(而模型会照着一棵少了一截的树继续说话)。两者都比一次响亮的
  * wake 失败坏。
  *
- * ## 拒的**词** = core 的 `SessionError("corrupt_session")`(S-612,server 7.104.0)
+ * ## 拒的**词** = core 的 `SessionError("corrupt_session")`([ref],server 7.104.0)
  * 写这段代码时 core 的 `SessionError` 闭集里还没有读侧的 corrupt 词(那时这里折成 `StoreCorruptError` / 更早是裸
- * `Error`,点名 `<表>.<列>` + 行标识 —— S-550 车①② 裁定)。core 7.30.0(#1041)给文件会话店铸了
+ * `Error`,点名 `<表>.<列>` + 行标识 —— [ref] 车①② 裁定)。core 7.30.0([ref])给文件会话店铸了
  * `corrupt_session`(「这只会话的存储读不出,无法唤醒」),于是同一件事在三种会话后端上说了两种话:文件后端上 wire
  * 是 500 `corrupt_session`,SQL 后端上是一只未分类的失败。⇒ 改抛**同一个词**;句子只留坐标(`<表>.<列>` + 会话 +
  * 行号 + 坏体种别),不带这一行的内容、不含任何盘上路径(codex r1 [high]:修前的句子带着坏体的前 64 个字符)。失败方向不变:仍然**拒**,不跳过(SQL 行没有「撕裂」这种自然形,坏行 = 被篡改或迁移

package/dist/plugins/session-fork.d.ts

@@ -0,0 +1,34 @@
+/**
+ * 会话 fork 的**分叉点与拷贝范围**(core 7.55.0 [ref] 的本仓一半)—— 三只会话店(local / TiDB / PG)的 fork 同调。
+ *
+ * ## 规则(一句)
+ * 「fork 拷到哪一条」只有引擎一只判官:`settledForkOptions(源会话)` 答 `{}`(整份日志)或 `{ entryId: <在飞轮的父>, position: "at" }`(拷到那一条为止)。
+ * 本仓的店不写第二份「什么算在飞」—— local 店把它的答案原样交给引擎自己的 `repo.fork`;两只 SQL 孪生没有 `repo.fork`(它们按行搬字节),所以这里只管**按答案拷**:
+ *  · `{}` ⇒ 整份日志(含别的分支),叶 = 源会话的叶(与引擎 `getEntriesToFork` 的无 `entryId` 臂同);
+ *  · `at` 点 ⇒ 根到分叉点那一条**路径**上的条目(与引擎 `getPathToRoot(entryId)` 同:路径,不是日志前缀,别的分支不随),叶 = 分叉点。
+ *
+ * ## 为什么拷贝仍读整份日志、判官却读唤醒出来的会话
+ * 拷贝要的是**整份**持久日志(压缩地板绕过 —— 唤醒只装 `[地板..叶]`,从唤醒里拷会丢地板之前的全部历史);判官要的只是叶链上最近几条(它是引擎的一份纯函数,
+ * 吃一只 `Session`):唤醒出来的会话 `getEntry` 在地板之下会回读持久日志,所以判官在压缩过的会话上也看得见整条叶链。
+ */
+import { settledForkOptions, type SessionStorage } from "@sema-agent/core";
+/** 引擎答的分叉点(`{}` = 整份;`entryId` + `position: "at"` = 拷到这一条为止)。 */
+export type ForkPoint = Awaited<ReturnType<typeof settledForkOptions>>;
+/** 问引擎:这只(已唤醒的)源会话从哪里拷。SQL 孪生用它;local 店手里就是引擎的 `Session`,直接调 `settledForkOptions`。 */
+export declare function forkPointOf(storage: SessionStorage): Promise<ForkPoint>;
+/** 整份日志里一行的父链两键(其余列原样搬,不读内容)。 */
+export interface ForkLogRow {
+    readonly entry_id: string;
+    readonly parent_id: string | null;
+}
+/**
+ * 按引擎的分叉点从整份日志(oldest-first)里挑出要拷的行,与新会话的叶。行的相对顺序保留(调用方按顺序重铸 seq)。
+ *
+ * 分叉点不在日志里 ⇒ `invalid_fork_target`、路径中途的父不在日志里 ⇒ `invalid_session`(引擎 `getEntriesToFork` / `getPathToRoot` 同词同句);分叉点之上的父链成环 ⇒ `invalid_session`、
+ * 句子与引擎的父链守卫同(守卫类不在包根,走法是同一个意思:走过的条目再踩一次 = 环;沿用它的句子,让同一件事在三种后端上说同一句话);`position` 不是 `at` ⇒ 响亮拒(本函数只认引擎今天答的两形)。
+ */
+export declare function forkCopyOf<R extends ForkLogRow>(rows: readonly R[], sourceLeafId: string | null, point: ForkPoint): {
+    rows: R[];
+    leafId: string | null;
+};
+//# sourceMappingURL=session-fork.d.ts.map

package/dist/plugins/session-fork.js

@@ -0,0 +1,29 @@
+import { SessionError, StoredSession, settledForkOptions } from "@sema-agent/core";
+export async function forkPointOf(storage) {
+    return settledForkOptions(new StoredSession(storage));
+}
+export function forkCopyOf(rows, sourceLeafId, point) {
+    if (point.entryId === undefined)
+        return { rows: [...rows], leafId: sourceLeafId };
+    if (point.position !== "at") {
+        throw new SessionError("invalid_fork_target", `fork point ${point.entryId} comes with a position this store does not copy (${String(point.position)}) — only the engine's "at" point is read here`);
+    }
+    const byId = new Map();
+    for (const r of rows)
+        byId.set(r.entry_id, r);
+    const onPath = new Set();
+    let cursor = point.entryId;
+    while (cursor !== null) {
+        if (onPath.has(cursor)) {
+            throw new SessionError("invalid_session", `Entry ${cursor} is its own ancestor (parent chain cycles at ${cursor}) — start a new session, or fork from an entry above the loop`);
+        }
+        const row = byId.get(cursor);
+        if (row === undefined) {
+            throw new SessionError(cursor === point.entryId ? "invalid_fork_target" : "invalid_session", `Entry ${cursor} not found`);
+        }
+        onPath.add(cursor);
+        cursor = row.parent_id;
+    }
+    return { rows: rows.filter((r) => onPath.has(r.entry_id)), leafId: point.entryId };
+}
+//# sourceMappingURL=session-fork.js.map

package/dist/plugins/session-ownership.d.ts

@@ -0,0 +1,11 @@
+/**
+ * fork 拷贝的属主 —— core `SessionStore.fork` 契约的唯一读法:
+ * 显式串 ⇒ 该串;无参 / 显式 `null` ⇒ 源会话记下的属主(`undefined` = 源会话没记,拷贝也不记)。
+ */
+export declare function forkOwnerOf(requested: string | null | undefined, sourceOwner: string | null | undefined): string | null | undefined;
+/**
+ * `register` 首写的 owner 守卫 —— core `SessionStore.register` 契约的唯一读法(三只店同调):首写的 owner 既不是串也不是 `null` ⇒ 响亮拒(不留行);
+ * 「首写」由调用方判(已记下属主的会话上的调用照旧静默不改,不经这里)。
+ */
+export declare function assertFirstOwnerWritable(sessionId: string, owner: unknown): asserts owner is string | null;
+//# sourceMappingURL=session-ownership.d.ts.map

package/dist/plugins/session-ownership.js

@@ -0,0 +1,11 @@
+import { SessionError } from "@sema-agent/core";
+export function forkOwnerOf(requested, sourceOwner) {
+    return typeof requested === "string" ? requested : sourceOwner;
+}
+export function assertFirstOwnerWritable(sessionId, owner) {
+    if (typeof owner === "string" || owner === null)
+        return;
+    throw new SessionError("storage", `register(${sessionId}): a first ownership write must carry a principal (string) or null (anonymous), got ${owner === undefined ? "undefined" : typeof owner} — ` +
+        "a stored value that the head read reads back as 'no row' would leave the session claimable forever and ownable never; refusing, nothing written");
+}
+//# sourceMappingURL=session-ownership.js.map

package/dist/plugins/session-placement.d.ts

@@ -33,7 +33,7 @@
  *    宿主可枚举、release 不真删的普通会话 ——「声明了 full tier 却在静默说谎」。⇒ 在**声明了分区**的
  *    店上,带 placement 的 acquire 必须回读到**已持久化**且同一元组身份的行,回读缺失/异组=响亮拒。
  */
-import { type PlacedSessionRow, type SessionPlacement, type SessionPlacementRecord } from "@sema-agent/core";
+import { type PlacedSessionRow, type SessionPlacement, type SessionPlacementRecord, type SessionStore } from "@sema-agent/core";
 /**
  * 两支 SQL 孪生的 placement **声明**(core `SessionStore.placements`)。
  *
@@ -88,20 +88,18 @@ export interface PlacementAcquireOpts {
     placement?: SessionPlacement;
 }
 /**
- * 准入判据 —— **两个方向**(顶注 ①②;core `TtlSessionStore.assertPlacementAdmission` 的 SQL 镜像,
- * 逐条同义,文案自铸)。
- *
- * @param persisted 该 id 在库里**已持久化**的元组(缺席 = 普通会话 / 无此行)。
- *
- * · 方向①(claim 关门):`persisted` 在场 + 非 `requireExisting` + 调用方没带创建 placement ⇒ 拒。
- *   `requireExisting`(读/复活形,义务 5)与「创建调用及其幂等重取」(带 placement 的可信内部链)
- *   是仅有的两个合法形。placement 不可变意味着带 placement 的参数**永远重写不了**任何东西——持久化
- *   的那一份恒赢,所以放行它不开任何口子。
- * · 方向②(镜像/squat):带 placement 的创建形回读到**缺席**或**异组**元组 ⇒ 拒。缺席 = 并发的
- *   claim 形抢先建出了普通会话(或带外写把元组抹了);异组 = 同 id 上坐着另一条委派链的转录。
- *   两者都不许让「声明了 durable 分区」这句话在静默中变成谎。
+ * 准入判据 —— 只有引擎那一只:core 包根导出 `admitSessionPlacement(sessionId, persisted, request, capability)`(core 7.54.0 [ref] K2;
+ * `TtlSessionStore` 自己调的同一只函数,两个方向:claim 关门 / 镜像·squat,`placement_refused`)。`capability.subagentPlacement` 读的是**店自己的声明**
+ * (`placements.subagent` 在场 —— 与 core `TtlSessionStore` 同一只读法,{@link placementCapabilityOf}),不是另写一个「这只店声明了」的常量:声明只有一处。
+ * 修前本模块持一份 SQL 镜像(`assertPlacementAdmission`,逐条同义、文案自铸)—— 与引擎是两份判据;随 7.54.0 退役、零别名。
+ * 拒句随之换成引擎的句子(缺元组那一形的结尾词:「or the repo dropped the tuple」,此前本仓写「written away out of band」)——
+ * 按原句匹配告警的运维规则要跟着改(MIGRATION 7.134.0 节记了这一句)。
  */
-export declare function assertPlacementAdmission(sessionId: string, persisted: SessionPlacementRecord | undefined, opts?: PlacementAcquireOpts): void;
+export declare function placementCapabilityOf(store: {
+    readonly placements?: SessionStore["placements"];
+}): {
+    readonly subagentPlacement: boolean;
+};
 /**
  * 一次 `listPlaced` 最多带回的行数。
  *

package/dist/plugins/session-placement.js

@@ -45,21 +45,8 @@ export function placementInsertValues(placement, placedAt) {
         placedAt,
     ];
 }
-export function assertPlacementAdmission(sessionId, persisted, opts) {
-    if (opts?.requireExisting === true)
-        return;
-    if (persisted !== undefined && opts?.placement === undefined) {
-        throw new SessionError("placement_refused", `session ${sessionId} belongs to the ${persisted.kind} placement partition — a claim-form acquire cannot attach to it (read it with requireExisting, or address the agent through its a* handle)`);
-    }
-    if (opts?.placement === undefined)
-        return;
-    const want = opts.placement;
-    if (persisted === undefined) {
-        throw new SessionError("placement_refused", `session ${sessionId} exists OUTSIDE the ${want.kind} placement partition it was declared into — refusing to run a subagent transcript on it (a concurrent claim-form create won this id, or the tuple was written away out of band)`);
-    }
-    if (persisted.kind !== want.kind || persisted.scope !== want.scope || persisted.handle !== want.handle) {
-        throw new SessionError("placement_refused", `session ${sessionId}'s persisted placement does not match the declared one (persisted ${persisted.kind}/${persisted.scope ?? "-"}/${persisted.handle ?? "-"} vs declared ${want.kind}/${want.scope ?? "-"}/${want.handle ?? "-"}) — refusing a cross-tuple attach`);
-    }
+export function placementCapabilityOf(store) {
+    return { subagentPlacement: store.placements?.subagent !== undefined };
 }
 export const LIST_PLACED_BATCH = 1000;
 //# sourceMappingURL=session-placement.js.map

package/dist/plugins/session-policy-store-sql.d.ts

@@ -21,7 +21,7 @@ export type StoredSessionRulesBody = SessionPermissionRules & Pick<StoredSession
  * `grammar` 戳同样由它拒)。本仓不另持一只读者:修前本仓自己那一只形读者与它对纯空白的 `allowDirs` 项给两个答案(本仓读得出、引擎判坏 ——
  * 读出来交给运行期,运行期又把整份规则判成读不出、每个调用都拒),同一问两只读者。
  *
- * 🔴 **戳原样交出,不补、不改**(core 7.51.2 #1761,行自带规则文法):一行条目的意思由行自带的 `grammar` 戳说,文法只有引擎一处读 ——
+ * 🔴 **戳原样交出,不补、不改**(core 7.51.2 [ref],行自带规则文法):一行条目的意思由行自带的 `grammar` 戳说,文法只有引擎一处读 ——
  * 戳在写口判官的返回值里盖(`judgeSessionRulesWrite`,本店整只存),引擎读行时按戳读(`readSessionRulesShape`:戳缺席 ⇒ 与 `rev` 并排的值是戳之前
  * 写的行,文法 0;不与 `rev` 并排的值是一次新写,文法 1)。列体里没有 `rev`(计数是另两列),所以形读法对一只**无戳的列体**解出的文法是「新写」的 1 ——
  * 不是这一行的。本函数因此只取形读法读出的**桶**,戳按体里有无原样带出:带戳 ⇒ 戳(与形读法读出的同一个数);无戳 ⇒ 缺席,引擎拿到回装点交出的行
@@ -41,11 +41,11 @@ export type StoredSessionRulesBody = SessionPermissionRules & Pick<StoredSession
  * JSON 列里的字符串标量按文本取出来**带着引号**(真库实测两方言同形:`"\"{}\""`)⇒ 解一次得到一只串 ⇒ 判坏;
  * 文本承载的列取出来就是它自己 ⇒ 解一次得到对象 ⇒ 好体。**一条规则,两种承载,零方言分叉,不依赖驱动行为。**
  *
- * 🔴 S-550:上面这一整段现在是**整仓**的口径,实现搬进唯一属主 `sql-json-column.ts`(投影 `jsonColumnText`
+ * 🔴 [ref]:上面这一整段现在是**整仓**的口径,实现搬进唯一属主 `sql-json-column.ts`(投影 `jsonColumnText`
  * + 恰好解一次 `decodeJsonColumn` + 折码 `foldJsonColumn`);本店只留「形判据是哪一只」与「坏体折成哪个码」。
  */
 export declare function readSessionRulesBody(body: unknown): JsonColumnShape<StoredSessionRulesBody>;
-/** 本店唯一的日志口:抹除封键那一臂(S-891)的点名。缺席 ⇒ 退回 `console.warn`(不静默)。 */
+/** 本店唯一的日志口:抹除封键那一臂([ref])的点名。缺席 ⇒ 退回 `console.warn`(不静默)。 */
 export type SessionPolicyStoreLogger = Pick<Logger, "warn">;
 /** Dual-dialect durable SessionPolicyStore. See the file header for the dialect-delta ledger. */
 export declare class SqlSessionPolicyStore implements SessionPolicyStore {
@@ -57,13 +57,13 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
     /** 判据属主 = `sql-errors.ts`([ref] P1-①;本站点旧形已是并集形,收编后语义不变)。 */
     private isDupKey;
     /** Read the stored rules for (session, principal-owner); null when none (parity with InMemory).
-     *  🔴 S-891(codex r1 [high] ①):同一条语句带上这把键的**封键记号** —— 封着 ⇒ `corrupt`,不答「没有规则」(见 {@link sealedKeyError})。 */
+     *  🔴 [ref](codex r1 [high] ①):同一条语句带上这把键的**封键记号** —— 封着 ⇒ `corrupt`,不答「没有规则」(见 {@link sealedKeyError})。 */
     getRules(sessionId: string, principal?: string): Promise<StoredSessionRules | null>;
     /** 2c session-sync: every (principal, rules) record for a session across ALL principals — getRules is
      *  per-(session,principal), but a cross-backend session EXPORT must bundle the WHOLE session's policy (the importer
      *  replays each via putRules). principal is read from the DENORMALIZED column (the sha256 policy_key is one-way);
      *  NULL → undefined = the session-wide row (parity with core's InMemory `principal ?? undefined`). Rules carry rev.
-     *  🔴 S-891:会话里有**封着的键** ⇒ 整只枚举 `corrupt`(与一行读不出形时整只枚举拒同一口径 —— 导出一份缺了那把键的规则,
+     *  🔴 [ref]:会话里有**封着的键** ⇒ 整只枚举 `corrupt`(与一行读不出形时整只枚举拒同一口径 —— 导出一份缺了那把键的规则,
      *  导入方就会把「状态未知」当成「这个 principal 没有规则」)。 */
     listBySession(sessionId: string): Promise<SessionRulesRecord[]>;
     /** Operator/owner write: CAS + tighten-only (unless operator) + rev bump, atomic in one txn; first-write race retried. */
@@ -80,9 +80,9 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *    `test/sql-lock-shape-innodb-integration.test.ts` (site ⑩, three engines). It exists because on REAL InnoDB
      *    (REPEATABLE READ) a `FOR UPDATE` read of a MISSING primary key takes a GAP lock, and gap locks are mutually
      *    compatible while both block the other side's INSERT — so N concurrent first writes on one key deadlock NO
-     *    MATTER what order any table is touched in. Measured on the real engine (2026-09-20, S-529, 8-way race on
+     *    MATTER what order any table is touched in. Measured on the real engine (2026-09-20, [ref], 8-way race on
      *    `main`'s statement sequence, zero mark table involved): InnoDB 1 winner / 7 `ER_LOCK_DEADLOCK`, TiDB 0,
-     *    PG 0 — i.e. this is a PRE-EXISTING MySQL-leg defect that S-529's lock-shape site made visible, not a new one.
+     *    PG 0 — i.e. this is a PRE-EXISTING MySQL-leg defect that [ref]'s lock-shape site made visible, not a new one.
      *    After the first insert commits, the retried writers find the row and take the UPDATE path (record lock,
      *    no gap) ⇒ the loop converges in one extra round per missing-row window; the bound is the suite's concurrency.
      *  Lock-WAIT-TIMEOUT is deliberately NOT retried ({@link isDeadlockError}'s own note: it is a latency signal,
@@ -94,7 +94,7 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *  (`Promise<void>`) — the affectedRows count was incidental and unconsumed; the integration test asserts the
      *  post-state (listBySession empty) instead.
      *
-     *  S-529 (`@contract session_policy.rev_survives_delete`): the rules ROW dies, the key's REV LINE does not, and the
+     *  [ref] (`@contract session_policy.rev_survives_delete`): the rules ROW dies, the key's REV LINE does not, and the
      *  erase ALSO ENDS THE ROW'S LINEAGE (`gen` + 1 — the next write on this key belongs to another generation, which no
      *  reader treats as a continuation of the erased row whatever rev it wears) — one
      *  transaction, three statements, and BOTH the order and the locking verb are load-bearing:
@@ -102,7 +102,7 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *      order. This is the SAME lock order putRules uses (policy row → mark row), which is the whole point: the
      *      obvious shape (`INSERT … SELECT` the marks, then DELETE) locks the MARK first and takes only a SHARED lock
      *      on the policy rows it reads, i.e. a reversed order PLUS an S→X upgrade — the textbook deadlock this repo
-     *      已经吃过两次(retention-store-sql.ts ④a/④b 的 S-131 案:一边持 boundary 等哨兵,一边持哨兵等 boundary)。
+     *      已经吃过两次(retention-store-sql.ts ④a/④b 的 [ref] 案:一边持 boundary 等哨兵,一边持哨兵等 boundary)。
      *   ② the marks (their revs come from ①'s already-locked rows) — `GREATEST` merge, so a mark only ever RISES and
      *      repeated erases never walk the line back.
      *   ③ the DELETE — scoped to ①'s POLICY_KEY SET, never re-scanned by `session_id`. 🔴 This is the whole of
@@ -111,7 +111,7 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *      DIFFERENT principal that a concurrent putRules commits BETWEEN ① and ③ would be deleted by a session-wide
      *      DELETE while ② never marked it — a silently reset rev line, exactly the defect this batch exists to close.
      *      Scoped to the key set, the invariant is exact and checkable: **every row this seam deletes leaves a mark** —
-     *      a readable row's mark continues its rev line and ends its lineage; an unreadable row's mark SEALS its key (S-891, below).
+     *      a readable row's mark continues its rev line and ends its lineage; an unreadable row's mark SEALS its key ([ref], below).
      *      A row born after ① is simply not part of this erase (same as one born a microsecond after ③ — the caller
      *      that needs "and nothing came back" re-issues; the seam is idempotent).
      *  No rows ⇒ return early: an erase of a session that never had rules writes NO mark (no line, nothing to keep),
@@ -121,7 +121,7 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *  right-to-delete would degrade to buy rev ordering. The mark keeps only the one-way hash, the session id and
      *  an integer.
      *
-     *  🔴 **S-891(7.106.0)—— 抹除恒删行;计数读不出的行留「封键记号」**。一行的计数读不出(三个读点的同一只判词
+     *  🔴 **[ref](7.106.0)—— 抹除恒删行;计数读不出的行留「封键记号」**。一行的计数读不出(三个读点的同一只判词
      *  {@link readRowCounters} 判坏:`rev` 不是 ≥ 1 的安全整数 / `gen` 不是 ≥ 0 的安全整数;或下一代的号 `gen + 1` 已出安全整数)
      *  ⇒ 这一行**照删**,它的记号元组写 `(键, 会话, {@link SEALED_MARK_REV}, 0, 时刻)`、走**同一句** `GREATEST` 合并:rev 落上界,
      *  世代 = `GREATEST(旧记号.gen + 1, 0)`(有旧记号照抬,没有就是 0)。于是这把键的下一次 `putRules` 算出 `上界 + 1`,被写前那道
@@ -139,7 +139,7 @@ export declare class SqlSessionPolicyStore implements SessionPolicyStore {
      *  (驱动错误;那只记号本来就读不回,`putRules` 同样拒)—— 抹除不读记号,这一形不在本判词射程内。 */
     deleteBySession(sessionId: string): Promise<void>;
     /**
-     * S-891 封键的响亮面:一次抹除至多一条 warn。日志座**抛** ⇒ 退回 `console.warn` 带原句 —— 走到这里删除已经提交,
+     * [ref] 封键的响亮面:一次抹除至多一条 warn。日志座**抛** ⇒ 退回 `console.warn` 带原句 —— 走到这里删除已经提交,
      * 一次日志故障不许把它报成失败(E21 会因此 500、overwrite-dst 会因此中止;codex 7.105.0 修复验证轮 [medium] 同形)。
      * 缺日志座(直接 `new` 本店的工具 / 测试)⇒ `console.warn`,不静默。
      */

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

@@ -45,7 +45,7 @@ export declare function ensureSessionDurable(hostStore: SessionStore, sessionId:
  * [ref] 主动晋升版 ensureChildSessionDurable(cli TiDB 真机撞获:1.263 的只查不迁形在拆店生产形下
  * 恒否决 park——bg 子会话住 subRunner 私有 TTL 店、从不在 host 店,core 收 veto 即 expire checkpoint
  * (14ms~2s)+ settle failed,赎回窗口不存在):
- *   0. 属主(S-1770,`delegated-session-owner.ts`):按委派继承律判一次(唯一判据 `judgeDelegatedOwner`)—— 来源集 = 见证的根这一只(调用方交出的委派树根 + 调用方判断那一刻
+ *   0. 属主([ref],`delegated-session-owner.ts`):按委派继承律判一次(唯一判据 `judgeDelegatedOwner`)—— 来源集 = 见证的根这一只(调用方交出的委派树根 + 调用方判断那一刻
  *      读到的根行住客:请求腿 = 本请求经鉴权解析的会话与受理时那一读,`/decide` 赎回腿 = 行上的 `rootSessionId` 与 claim 前后两读的那一位;core 的挂点签名只给子代 id,
  *      场景层把见证绑进闭包交下来)。此刻根行在而住客不是见证的那一位(删了、同 id 被重新登记)⇒ **拒**(`assertRootStillWitnessed`:不按新住客晋升 / 认领);
  *      缺席(行上没有根)或根行此刻不在 ⇒ 孤行哨兵。
@@ -56,7 +56,7 @@ export declare function ensureSessionDurable(hostStore: SessionStore, sessionId:
  *      三步见 ForkRoutingSessionStore.promoteToHost),宿主行在建行那一笔里带第 0 步的属主;写的是哨兵 ⇒ 写落下之后一行 warn。
  *   3. 复验:同一把 `ensureSessionDurable` 严检(leaf 非空)+ 同一只属主定夺 —— 晋升产物必须达到与快路完全相同的
  *      标准,任何一步失败=如实 reject=veto=pre-153 行为(不放大)。
- * 宿主店必须读得出属主(`delegatedOwnerHostOf`:`ownerOf` + `sessionFaceOf`;记录委派树的店另交 `placementOf` + `claimOwnerless`,两只同在或同缺;生产的 SQL / local 店与缓存包装层都满足),
+ * 宿主店必须读得出属主(`delegatedOwnerHostOf`:`headOf`;记录委派树的店另交 `placementOf` + `claimOwnerless`,两只同在或同缺;生产的 SQL / local 店与缓存包装层都满足),
  * 否则响亮拒。
  * 调用方纪律与 {@link ensureSessionDurable} 同款:hostStore 必须是 release 非破坏性的真 durable 店
  * (stage-07 的 `config.sessionBackend === "tidb"` 门不变 —— 该词在 local 后端上同样归一成 `tidb`,所以本腿在 local 宿主店上也跑)。

package/dist/plugins/session-store.js

@@ -26,9 +26,9 @@ export async function ensureSessionDurable(hostStore, sessionId) {
 export async function ensureChildSessionDurableWithPromotion(hostStore, routing, sessionId, root, log) {
     const host = delegatedOwnerHostOf(hostStore);
     if (host === undefined) {
-        throw new Error(`session "${sessionId}" cannot be parked: the host session store cannot read a session's owner (ownerOf / sessionFaceOf), or records delegation trees without being able to claim under them (placementOf / claimOwnerless), so the delegated transcript's owner cannot be derived or checked`);
+        throw new Error(`session "${sessionId}" cannot be parked: the host session store cannot read a session's owner (headOf), or records delegation trees without being able to claim under them (placementOf / claimOwnerless), so the delegated transcript's owner cannot be derived or checked`);
     }
-    const judged = await readDelegatedOwner(sessionId, root === undefined ? {} : { rootSessionId: root.sessionId }, sourceFacesVia(host.sessionFaceOf));
+    const judged = await readDelegatedOwner(sessionId, root === undefined ? {} : { rootSessionId: root.sessionId }, sourceFacesVia(host.headOf));
     assertRootStillWitnessed(sessionId, root, judged);
     let promoted = false;
     try {

package/dist/plugins/shared-memory-store-sql.d.ts

@@ -162,12 +162,12 @@ export declare class SqlSharedMemoryStore implements SharedMemoryStoreProvider {
     /**
      * 盘状态 + 库登记,**一条语句一个快照**。
      *
-     * 🔴 S-131(codex 对抗复审 r1 [high] 采,[ref] 的终局):这一对读要的不是新鲜度,而是「scope 行与
+     * 🔴 [ref](codex 对抗复审 r1 [high] 采,[ref] 的终局):这一对读要的不是新鲜度,而是「scope 行与
      * store 行读齐、不撕」——一个 importer 若落在两条读之间,快照会把**旧的 connected 盘态**和**新登记的
      * 库**拼在一起,于是壳拿到一个「已连接」的盘和一份不完整的库,而 reader 只复核 (store, scope) 归属、
      * 从不复核盘态。
      *
-     * 此前这条保证挂在**隔离级**上(轮2 F3 起用事务,[ref] 又把两臂都钉成 REPEATABLE READ)。S-131 把
+     * 此前这条保证挂在**隔离级**上(轮2 F3 起用事务,[ref] 又把两臂都钉成 REPEATABLE READ)。[ref] 把
      * 隔离级收进连接初始化之后,那条路在 PG 腿上走不通:PG 的 REPEATABLE READ 是快照隔离,把会话钉过去
      * 会让本仓每一条 `SELECT … FOR UPDATE` 从「等锁后读当前」变成 `40001` 序列化失败(`@contract
      * txn.read-semantics` ② 的 PG 段),而 PG 的 `BEGIN` 是 READ COMMITTED、**每条语句各自取快照**。