@sema-agent/server 7.52.0 → 7.53.0

package/dist/boot/reapers.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— 后台 reaper / 维护 tick。
+ * [ref] A10:composition root 分段 —— 后台 reaper / 维护 tick。
  *
  * 纯搬运:函数体逐字来自 `main.ts`(原 2387-2599 行),缩进不变;新增的只有 import 与
  * `startReapers(ctx)` 包壳。
@@ -22,7 +22,7 @@ import type { WorkflowNotifyGate, WorkflowNotifyJournalStore } from "../orchestr
 import type { TaskAttachmentStore } from "../plugins/task-attachment-store.js";
 import type { CheckpointStoreFull, CostQuotaStore, ImageBake, RateLimiterStore, ServiceWorkflowJournalStore, StoreBackend, ToolResultStoreFull } from "../plugins/store-backend.js";
 import type { ToolApprovalCoordinator } from "../tool-approval.js";
-/** #157 / [2762]§五(sema-comms `audits/failopen-governance-176.md` §7 "Z 类 1 条"):default consecutive-failure
+/** [ref] / [ref]§五(sema-comms `audits/failopen-governance-176.md` §7 "Z 类 1 条"):default consecutive-failure
  *  count before a reaper leg's swallowed error gets a `warn` line. The ~15 `.catch(() => undefined)` sites
  *  below are correct in DIRECTION (a hiccuping periodic sweep must never crash the whole tick loop — one bad
  *  leg cannot be allowed to starve its ~15 siblings), but were zero-observability: an operator watching only
@@ -51,7 +51,7 @@ export interface ThrottledReaperCatch {
  * survives across ticks — a fresh instance per tick would never accumulate past 1.
  */
 export declare function createThrottledReaperCatch(name: string, logger: Logger, threshold?: number): ThrottledReaperCatch;
-/** A-010.17 —— 维护 tick 真正消费的那**一手**(窄口;理由见 `ReapersCtx.permissionRuleStores`)。
+/** [ref] —— 维护 tick 真正消费的那**一手**(窄口;理由见 `ReapersCtx.permissionRuleStores`)。
  *  可选成员:File 车道没有这一面(追加日志的压实是另一件事,如实登记在 `rules-consent.ts` 的
  *  `PermissionRuleStoreBundle.reapExpired` 注里),缺席 ⇒ 本腿零调用。 */
 export interface PermissionRuleRetentionSweeper {
@@ -74,7 +74,7 @@ export interface ReapersCtx {
     imageBakes: ImageBake | undefined;
     worktreeReap: (() => Promise<void>) | undefined;
     workflowNotifyGate: WorkflowNotifyGate | undefined;
-    /** [2995]/[2999] recover 的两半 opts(boot 与周期扫描共用,单点合成在 workflow-orchestration)。 */
+    /** [ref]/[ref] recover 的两半 opts(boot 与周期扫描共用,单点合成在 workflow-orchestration)。 */
     workflowRecoverOpts: Parameters<WorkflowNotifyGate["recover"]>[0];
     workflowJournalStore: ServiceWorkflowJournalStore | undefined;
     sqlWorkflowRunStore: WorkflowRunStore | undefined;
@@ -82,11 +82,11 @@ export interface ReapersCtx {
     rosterStore: RunnerDeps["rosterStore"];
     backgroundAgentStore: RunnerDeps["backgroundAgentStore"];
     mailboxStore: RunnerDeps["mailboxStore"];
-    /** #151 车6:流内审批撤卡帧的 live 投递口(收敛器/孤儿代打腿产出的帧经它反查 broker 的活连接)。
+    /** [ref] 车6:流内审批撤卡帧的 live 投递口(收敛器/孤儿代打腿产出的帧经它反查 broker 的活连接)。
      *  `TOOL_APPROVAL_ENABLED=false` 的部署恒 undefined ⇒ 收敛器照常收敛,只是不发通知帧(壳侧靠
      *  重连 preamble 对账,见 approval-card.ts 的 `ApprovalRevokeFrame` 顶注)。 */
     toolApproval: ToolApprovalCoordinator | undefined;
-    /** A-010.17:规则店的**保留期口**。`PERMISSION_RULES_ENABLED=false` 或后端没实装 ⇒ undefined
+    /** [ref]:规则店的**保留期口**。`PERMISSION_RULES_ENABLED=false` 或后端没实装 ⇒ undefined
      *  ⇒ 本腿根本不注册(零扫描),与它的同族旋钮腿同姿势。
      *
      *  🔴 类型刻意窄到 {@link PermissionRuleRetentionSweeper} 而不是整个 `PermissionRuleStoreBundle`:
@@ -141,7 +141,7 @@ interface ReapSessionsInputs {
     };
 }
 /**
- * 🔴 #292 C18(core 5.48.0 design/323,[4743] 提货单)——**分区腿武装**的判据本体。
+ * 🔴 [ref] C18(core 5.48.0 [ref],[ref] 提货单)——**分区腿武装**的判据本体。
  *
  * core 5.48 起 `reapDurableAgents` 的 `deps.sessions` 多一只可选 `listPlaced`:在场即启用**分区收割
  * 腿** —— 一条 placed 转录的属主行已经不在(put 从未落地 / 上一轮条件删赢了但 release 失败)时,行驱动
@@ -153,7 +153,7 @@ interface ReapSessionsInputs {
  *  · `release` 对 **placed id** 必须走 host 店:路由店(`ForkRoutingSessionStore`)对一个重启后不认识
  *    的 id 会回落 transient(进程内 no-op),那会让 core 数出一次**从未发生**的 release
  *    (`orphanPlacedReleased` 当场变成谎)而字节还在库里。故先按**持久化元组**判(一次 PK 探针),
- *    placed 走 host 店的真删除;其余 id 原样保留 [1522] 裁定的双店语义。
+ *    placed 走 host 店的真删除;其余 id 原样保留 [ref] 裁定的双店语义。
  *  · 🔴 探针本身失败 ⇒ **响亮抛**(codex 交叉复审 R1-[medium],验真后修:本函数的初版把探针错误
  *    改写成 `undefined` 再落路由店 —— 而重启后路由店不认识 placed id ⇒ transient no-op,core 却因为
  *    release 正常 resolve 而 `orphanPlacedReleased++`。间歇性 DB 故障于是被**伪装成 GC 成功**:监控

package/dist/boot/resolve-spec.d.ts

@@ -23,7 +23,7 @@ type PrincipalCaps = ReturnType<typeof createPrincipalEntitlementsClient>;
 /** `resolveSpec` 原先从 `main()` 闭包里拿到的全部 boot 局部量。 */
 export interface ResolveSpecCtx {
     config: ServiceConfig;
-    /** #196:hands lane 登记簿。resolveSpec 在产出 TaskSpec 时按场景判别位登记本请求的表态,HTTP 执行点
+    /** [ref]:hands lane 登记簿。resolveSpec 在产出 TaskSpec 时按场景判别位登记本请求的表态,HTTP 执行点
      *  凭同一只登记簿选 Runner —— **必须与 main.ts 传给 `runnerFor` 的是同一实例**(异实例 = 每个请求都
      *  落回 full,收窄静默失效)。 */
     handsLanes: HandsLaneRegistry;
@@ -65,12 +65,12 @@ export interface ResolveSpecCtx {
         root: string;
     } | undefined;
     durableEnabled: boolean;
-    /** #152 ([2703] 案二):活体 AskUserQuestion 面(QuestionCoordinator 的判决探针切面)。在场(=
+    /** [ref] ([ref] 案二):活体 AskUserQuestion 面(QuestionCoordinator 的判决探针切面)。在场(=
      *  ASK_QUESTION_ENABLED)时 durable question 门按活流上下文分腿、spec 不再 stamp QUESTION_AWAITS_RESUME
      *  (否则 spec.onQuestion 恒遮蔽 RunnerDeps.onQuestion 的活人腿);缺席时行为与旧形逐字一致。 */
     liveQuestionFace: LiveQuestionFace | undefined;
     /**
-     * S-46 件C —— 部署级**活体审批席**(`RunnerDeps.onAsk` 的同源铸法,main.ts 递
+     * [ref] 件C —— 部署级**活体审批席**(`RunnerDeps.onAsk` 的同源铸法,main.ts 递
      * `createRunnerDepsOnAsk(toolApproval)`;单一属主同 `boot/runner-deps.ts`,与 `parked-revive-gate.ts`
      * 的 `approverSeat` 是同一格)。
      *
@@ -87,7 +87,7 @@ export interface ResolveSpecCtx {
     imageIndex: ReturnType<NonNullable<StoreBackend["imageIndex"]>> | undefined;
     perTaskImage: PerTaskImageRegistry;
     sessionEnvSelection: SessionEnvironmentSelection;
-    /** design/170 件C:本部署已校验的锁集(boot/governance-seams.ts 的产物,与 `RunnerDeps.lockedConfig`
+    /** [ref] 件C:本部署已校验的锁集(boot/governance-seams.ts 的产物,与 `RunnerDeps.lockedConfig`
      *  同源一次解析)。空集 = 无锁 = 现行为。本域只用它做**同步拒面**(§4.3),不做第二次裁决。 */
     lockedKeys: ReadonlySet<import("@sema-agent/core").LockedKey>;
 }

package/dist/boot/retention-lane.d.ts

@@ -1,5 +1,5 @@
 /**
- * #270 车2 —— 托管留存的 **sweep lane**(设计稿 `docs/DESIGN-270-retention-lane.md` v1.3 §3/§4/§7)。
+ * [ref] 车2 —— 托管留存的 **sweep lane**(设计稿 `docs/DESIGN-270-retention-lane.md` v1.3 §3/§4/§7)。
  *
  * ── 为什么是独立文件、独立定时器,而不是折进 `startReapers()`(设计稿 §3 首条)───────────────────
  * `boot/reapers.ts` 里那二十条腿全都是**容忍多副本**的幂等清理:每台副本各扫各的,重复扫一遍只是浪费。

package/dist/boot/runner-deps.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— `RunnerDeps` 装配(含 self-orchestration 成组段)。
+ * [ref] A10:composition root 分段 —— `RunnerDeps` 装配(含 self-orchestration 成组段)。
  *
  * 纯搬运:两个字面量逐字来自 `main.ts`(原 1579-1881 行),缩进不变(顶层键仍在 4 空格,
  * `deps-literal-shape-gate` 的顶层条件展开门覆盖面不变);新增的只有 import 与包壳。
@@ -24,16 +24,16 @@ import { WorkflowNotifyGate, type WorkflowCompletionPayload } from "../orchestra
 import type { ServiceWorkflowJournalStore, StoreBackend, ToolResultStoreFull } from "../plugins/store-backend.js";
 import type { QuestionCoordinator } from "../question.js";
 import type { ToolApprovalCoordinator } from "../tool-approval.js";
-import type { MemoryBackend } from "@sema-agent/core";
+import type { MemoryBackend, SessionCaptureRecordStore } from "@sema-agent/core";
 import type { MemorySyncRunner } from "../memory-sync-client.js";
 /**
- * `RunnerDeps.onAsk` 的装配(#168 件4:从内联闭包提为具名导出,**纯 testability 重构、零行为变化**)。
+ * `RunnerDeps.onAsk` 的装配([ref] 件4:从内联闭包提为具名导出,**纯 testability 重构、零行为变化**)。
  *
- * 为什么值得有名字(历史理由,#168 当时):bg / resume 两条腿彼时没有 per-task `spec.onAsk` 装配点,
+ * 为什么值得有名字(历史理由,[ref] 当时):bg / resume 两条腿彼时没有 per-task `spec.onAsk` 装配点,
  * 它们唯一的审批接缝就是这一格。端到端测试此前只能把这一行**照抄**一份,再靠一条读源码
  * 的正则当漂移告警 —— 那种锚只抓得到「这一行没了/改名了」,抓不到任何语义变化,而且抄件与真件从此是两
  * 份实现。提成导出之后,测试直接取本函数,接缝与 production 是**同一个符号**。
- * ⚠️ S-52 起**三腿都装** per-task `spec.onAsk = boundAsk`(sync=routes/tasks.ts、bg=runs.ts、
+ * ⚠️ [ref] 起**三腿都装** per-task `spec.onAsk = boundAsk`(sync=routes/tasks.ts、bg=runs.ts、
  * resume=server.ts driveResumeLeg;core `resolveAsk` 取 `spec.onAsk ?? deps.onAsk` ⇒ 这三条腿及其继承链
  * 子代不再落到本格)—— 本格现役的到达面 = 没有 per-task 装配的腿(headless/durable-submit、协调器在场
  * 但 taskId 缺席的退化 resume 腿)与任何未来新腿的缺省兜底,fail-direction 不变(零 ctx ⇒ 政策口)。
@@ -42,10 +42,10 @@ import type { MemorySyncRunner } from "../memory-sync-client.js";
  *
  * 返回型**刻意窄于** `RunnerDeps["onAsk"]`(它还允许 `"allow"`/`"deny"` 两个字符串常量):本仓的接缝
  * 恒是回调形,而 core 的 sync-first 判据只看 `onAsk !== undefined` ⇒ 字符串模式会顶掉 durable park
- * (core backlog #73,黑板 [2897]④ / [2899] 已知悉)。窄返回型把「本仓零受迫于那一形」变成编译期事实。
+ * (core backlog #73,黑板 [ref]④ / [ref] 已知悉)。窄返回型把「本仓零受迫于那一形」变成编译期事实。
  *
- * 语义逐字不变:[816]/[820]② 的 live tool-approval 接缝(core `resolveAsk` 读 `spec.onAsk ?? deps.onAsk`),
- * ALS 路由同 `onQuestion` —— 被协调器 `runWithContext` 包住的腿才够得着人。[879] G1 终态(core 1.295
+ * 语义逐字不变:[ref]/[ref]② 的 live tool-approval 接缝(core `resolveAsk` 读 `spec.onAsk ?? deps.onAsk`),
+ * ALS 路由同 `onQuestion` —— 被协调器 `runWithContext` 包住的腿才够得着人。[ref] G1 终态(core 1.295
  * OnAsk 三值化)下**恒**接线:回调逐 ask 时刻判活人,无附着/卡送达失败 ⇒ 返 `"unavailable"`,core 以
  * `approverUnavailable` 回路把该 ask 交回 `suspendAsk` 走 durable park;无 park 设施的部署 core 自己
  * fail-closed deny。协调器缺席(协议未上场)⇒ `undefined`,即「这条部署没有活人接缝」。
@@ -61,7 +61,7 @@ export interface RunnerDepsCtx {
     rosterStore: RunnerDeps["rosterStore"];
     backgroundAgentStore: RunnerDeps["backgroundAgentStore"];
     mailboxStore: RunnerDeps["mailboxStore"];
-    /** design/166-T1:治理窗账本店(USAGE_WINDOWS 配置时才在场;与 config.usageWindows 成对进 deps)。 */
+    /** [ref]-T1:治理窗账本店(USAGE_WINDOWS 配置时才在场;与 config.usageWindows 成对进 deps)。 */
     usageWindowStore: RunnerDeps["usageWindowStore"];
     brain: ReturnType<typeof createBrain>;
     pricing: ReturnType<typeof buildPricing>;
@@ -75,16 +75,22 @@ export interface RunnerDepsCtx {
         backend: MemoryBackend;
         root: string;
     } | undefined;
+    /** [ref]②([ref] §2.1b,core 7.0.2 [ref] 件2):会话 capture opt-out 记录的 SQL 载体
+     *  (`backend.sessionCaptureRecords()`,main.ts 取**一次**、与四只 operator 面引擎同实例 —— 全站同批
+     *  注入律,机器钉 = test/memory-capture-optout-lane.test.ts ②)。缺席(local 车道)⇒ core 用控制面
+     *  文件三腿,单机字节不变;在场 ⇒ 远端车道 `capture:"off"` 声明从 409 `config.memory_capture_unsupported`
+     *  稳态转为真持久(core prepare-memory 的 §2.1b 能力信号)。 */
+    sessionCaptureRecordStore: SessionCaptureRecordStore | undefined;
     memorySyncRunner: MemorySyncRunner | undefined;
-    /** design/170 件A(#148 件3③):org 记忆准入两 seam 的装配产物(boot/org-memory.ts)。进**共享
+    /** [ref] 件A([ref] 件3③):org 记忆准入两 seam 的装配产物(boot/org-memory.ts)。进**共享
      *  基座**——主/sub 两 Runner 必须同源:委托子代的 prepare 同样跑准入(委托冻结的重判腿),漏挂
      *  subRunner=子代平面跳过目录判决。 */
     orgMemoryAdmission: import("./org-memory.js").OrgMemoryAdmissionWiring;
-    /** design/170 件B/C/D(#252 件1):三个部署治理座席的装配产物(boot/governance-seams.ts)。进**共享
+    /** [ref] 件B/C/D([ref] 件1):三个部署治理座席的装配产物(boot/governance-seams.ts)。进**共享
      *  基座** —— 合规否决与锁定层必须同样管住委托子代那条腿(子代 prepare 走同一套 preflight;漏挂
      *  subRunner = 子代平面跳过档位与锁,与件A 同一个理由)。`retentionPolicy` 是纯声明,同源携带。 */
     governanceSeams: import("./governance-seams.js").GovernanceSeams;
-    /** design/177 —— org 共享记忆库的供给面(core `RunnerDeps.sharedMemoryStores`)。在场即挂载
+    /** [ref] —— org 共享记忆库的供给面(core `RunnerDeps.sharedMemoryStores`)。在场即挂载
      *  `memory_list`/`memory_read` 两只工具(core 没有 TaskSpec 伴生旋钮:dep 的在场**就是**部署意图);
      *  缺席 ⇒ 两只都不挂,连占位都没有。装配点按「SQL 供给面 ∧ org 折叠面」双在场才铸它,与 HTTP 面
      *  同一个合取式(main.ts)。 */
@@ -92,17 +98,17 @@ export interface RunnerDepsCtx {
     toolResultStore: ToolResultStoreFull | undefined;
     sessionPolicyStore: ReturnType<StoreBackend["sessionPolicy"]> | undefined;
     runtimeCapsResolver: RunnerDeps["runtimeCapsResolver"];
-    /** S-15 per-edited-file rewind history (core `RunnerDeps.fileHistoryStore`; replaces the retired E19
+    /** [ref] per-edited-file rewind history (core `RunnerDeps.fileHistoryStore`; replaces the retired E19
      *  whole-tree snapshot seat — core 94632197 renamed the seat, not a coexistence). WIRING IS THE OPT-IN. */
     fileHistoryStore: ReturnType<StoreBackend["fileHistory"]> | undefined;
     /** S-1 legacy-epoch discriminant (core `RunnerDeps.legacyRewindBoundaryProbe`): lets the rewind refusal
      *  distinguish "never existed / reaped" from "exists in the RETIRED whole-tree epoch". Consulted only on
      *  the refusal path; diagnostic input, never a control input (a bad probe cannot change the outcome). */
     legacyRewindBoundaryProbe: RunnerDeps["legacyRewindBoundaryProbe"];
-    /** #154 车二:持久化权限规则店 provider(core `RunnerDeps.permissionRuleStore`)。缺席 ⇒ 引擎的
+    /** [ref] 车二:持久化权限规则店 provider(core `RunnerDeps.permissionRuleStore`)。缺席 ⇒ 引擎的
      *  `permissionRules.storeWired` 如实报 false、`AskRequest.ruleOffers` 不铸(诚实缺席)。 */
     permissionRuleStore: RunnerDeps["permissionRuleStore"];
-    /** #324(core 5.50 design/338):mid-turn MCP 撤销台账席 —— core 每次 MCP dispatch 前同步探
+    /** [ref](core 5.50 [ref]):mid-turn MCP 撤销台账席 —— core 每次 MCP dispatch 前同步探
      *  `isRevoked(serverName)`,被撤服务器的调用结算为 coded 拒绝 `mcp.server_revoked`(known-not-executed)。
      *  来源=configCenter.takeMcpRevocations()(取走即声明接线,restart 豁免与承接绑同一动作)。
      *  缺席=undefined=pre-338 语义(纯 env 部署无中心撤销面)。 */
@@ -110,12 +116,12 @@ export interface RunnerDepsCtx {
     /**
      * 交接件⑤ —— commit 尾注的署名座(`RunnerDeps.hands.commitCoAuthor`)。
      *
-     * 🔴 为什么它属于**共享基座**而不是主 runner 的差异键:署名是**部署身份**([931]① clay 拍:
+     * 🔴 为什么它属于**共享基座**而不是主 runner 的差异键:署名是**部署身份**([ref]① clay 拍:
      * 「署名 = 产品身份资产,归部署」),不是「哪一只 Runner 在跑」的属性。一个被委派出去的子代
      * 提交进的是**同一个仓**、代表的是**同一个部署** —— 它的 commit 少一行 trailer 没有任何理由。
      * 修前两条腿都漏:`main.ts` 与 `run-local.ts` 的 subRunner 都只在主 runner 上写了这一键,而两处
      * 的「差异键」注释块逐条列了 sessionStore / checkpointStore / 四个座位,**都没提 hands**
-     * —— 也就是说它不是一次有理由的分歧,是漏配(与本函数头注记的 [1543]§三族A 同一个病族)。
+     * —— 也就是说它不是一次有理由的分歧,是漏配(与本函数头注记的 [ref]§三族A 同一个病族)。
      * 由**调用方**给值(而不是在基座里按 `config` 现算):两条腿的判据本就不同(HTTP 腿按
      * `configProvider === "local"` 分 branded/非 branded,run-local 恒是 Sema 本地形),
      * 各自算一次、传进来一次,两只 Runner 自动同源。
@@ -134,14 +140,14 @@ export interface RunnerDepsCtx {
     /** 晚绑(runStore 在本段之后构造)——见文件头「位置即契约」。 */
     getRunStore: () => ReturnType<StoreBackend["run"]> | undefined;
 }
-/** design/158 A10 留档发现②:main runner `RunnerDeps` 与 main.ts subRunner 字面量之间此前手工重复
+/** [ref] A10 留档发现②:main runner `RunnerDeps` 与 main.ts subRunner 字面量之间此前手工重复
  * 的 ~15 个键,类型标注见 {@link createSharedRunnerDeps} 头注。 */
 export type SharedRunnerDeps = Pick<RunnerDeps, "brain" | "readFace" | "readDenyPatterns" | "readDenyBuiltinTiers" | "readDenyBuiltinExclude" | "memoryDelegationEvidence" | "memoryProvenance" | "memoryCapturePolicy" | "delegationEntryCaps" | "models" | "roles" | "tiers" | "pricing" | "tracer" | "promptSource" | "executionEnvFactory" | "lspManager" | "backgroundAgentStore" | "mailboxStore" | "rosterStore" | "hooks" | "toolResultStore" | "hands" | "sessionPolicyStore" | "usageWindows" | "usageWindowStore" | "memoryScopeAdmission" | "deploymentMemoryScopes" | "sharedMemoryStores" | "compliancePostureResolver" | "lockedConfig" | "retentionPolicy" | "onNotice" | "mcpRevocations">;
 /**
- * design/158 A10 留档发现②(review 2026-07-29,[1543]§三族A 同源修补的延续):main runner 的
+ * [ref] A10 留档发现②(review 2026-07-29,[ref]§三族A 同源修补的延续):main runner 的
  * `RunnerDeps` 字面量(下方 `createRunnerDeps`)与 `main.ts` 里 subRunner 的 `new Runner({...})`
  * 字面量之间,以下 ~15 个键此前是**各自手写、独立展开**的同源值(同一 ctx 变量,两处分别拼字面量,
- * 不是同一引用)——正是 [1543]§三族A 那次「主 runner 挂了、subRunner 漏挂」漏配事故的键族(当时的
+ * 不是同一引用)——正是 [ref]§三族A 那次「主 runner 挂了、subRunner 漏挂」漏配事故的键族(当时的
  * 修法是把 onBackgroundChildEvent/loadProjectMemory/probeInstructionSources/onError 四键改成直引
  * `runnerDeps.X`「同一实例」;这里补的是**剩下未被那次改法覆盖**的 15 个键——两处字面量各自独立
  * 取值,漏配一个不会有任何编译期或运行期信号)。
@@ -153,21 +159,21 @@ export type SharedRunnerDeps = Pick<RunnerDeps, "brain" | "readFace" | "readDeny
  * 消费点(复审 2026-07-30 F1 更新,过期「尚未接上」段已删):**两处都已展开**——下方
  * `createRunnerDeps()`(全量 ctx)与 main.ts 的 subRunner `new Runner({...createSharedRunnerDeps(...)})`
  * (窄面 {@link SharedRunnerDepsCtx})。新增共享键只需加进本函数返回体,两 Runner 自动同源;
- * **不要**再在任一调用点手写同名键(那会 override 展开,回到 [1543] 漏配病)。
+ * **不要**再在任一调用点手写同名键(那会 override 展开,回到 [ref] 漏配病)。
  *
  * 差异键(为何不在本共享基座、逐一注明):
  *  - `sessionStore`:main runner 用宿主 durable 会话店;subRunner 用私有短 TTL 的
  *    `ForkRoutingSessionStore`(main.ts 现场构造,子代转录生命周期与主会话不同)。
  *  - `checkpointStore`:main runner 走 `spec.checkpointStore` 分支(不进 `RunnerDeps`,本 ctx 根本
- *    没有这个字段);subRunner 单独携带(子代执行面的 park 设施,[1584])。
+ *    没有这个字段);subRunner 单独携带(子代执行面的 park 设施,[ref])。
  *  - `onBackgroundChildEvent` / `loadProjectMemory` / `probeInstructionSources` / `onError`:
- *    [1543]§三族A 已用「直引 `runnerDeps.X`」修过(main.ts 两处引用同一个 `runnerDeps` 实例的同一
+ *    [ref]§三族A 已用「直引 `runnerDeps.X`」修过(main.ts 两处引用同一个 `runnerDeps` 实例的同一
  *    属性,比再抽一层共享基座更强的同源保证),不重复收纳进这里。
  */
 /** 基座真实消费的窄面(Pick)——subRunner 调用点(main.ts)只需凑这 13 个字段,不必造全量 ctx。 */
 export type SharedRunnerDepsCtx = Pick<RunnerDepsCtx, "config" | "brain" | "pricing" | "tracer" | "promptSource" | "executionEnvFactory" | "lspManager" | "backgroundAgentStore" | "mailboxStore" | "rosterStore" | "deploymentHooks" | "toolResultStore" | "sessionPolicyStore" | "hands" | "usageWindowStore" | "orgMemoryAdmission" | "sharedMemoryStores" | "logger" | "governanceSeams" | "mcpRevocations">;
 /**
- * core `EngineNotice` → 结构化 `engine_notice` 行的**唯一**转发体(#240②)。
+ * core `EngineNotice` → 结构化 `engine_notice` 行的**唯一**转发体([ref]②)。
  *
  * 🔴 为什么是具名导出而不是就地闭包(合并码重扫):这一席此前只落在共享基座里,于是 leader 车道
  * (`src/leader/wire.ts` 自拼 deps 的五处 `new Runner({...})`)一处都没有 —— core 的契约是「接线 ⇒ 走
@@ -180,8 +186,8 @@ export type SharedRunnerDepsCtx = Pick<RunnerDepsCtx, "config" | "brain" | "pric
  * logger」上会把通告**吞掉** —— 比不接线还坏(不接线时 core 至少还打它自己的 `console.warn`)。所以
  * 「有没有 warn」这个判断留在**装配点**:没有就别铸这一席,让 core 的响亮权留在原处。
  *
- * ## #310:双终点分流器(设计稿 = 黑板 [4630])
- * 本体自 #310 起是**分流器**,两个终点:
+ * ## [ref]:双终点分流器(设计稿 = 黑板 [ref])
+ * 本体自 [ref] 起是**分流器**,两个终点:
  *  1. **日志(全族,逐字保留)** —— 上面那段契约一个字节不变:任何 code、detail 原样、缺 detail 不铸键。
  *     运维观察面零回退是本腿的硬前提(wire 半场是**增量**,不是搬家)。
  *  2. **wire(白名单 + sessionId 路由)** —— `router.route(notice)`:码在
@@ -192,7 +198,7 @@ export type SharedRunnerDepsCtx = Pick<RunnerDepsCtx, "config" | "brain" | "pric
  *     `src/trace/engine-notice-wire.ts`(白名单/归属/消毒/隔离四件同源),这里只负责**先日志后分流**的次序。
  *
  * 🔴 次序是承重的:日志在前 ⇒ 即便 wire 半场整条坏掉(路由抛、口抛),事实仍然完整落在运维面。
- * 反过来写就是「wire 故障吃掉运维日志」,那正是本仓 #157 纪律要根除的形。route 自身按 sink 隔离 +
+ * 反过来写就是「wire 故障吃掉运维日志」,那正是本仓 [ref] 纪律要根除的形。route 自身按 sink 隔离 +
  * F 类留痕(`server.engine-notice.wire-sink-threw`),不向 core 回抛。
  *
  * 🔴 `router` **有默认值**(进程单例)而不是必填:这一席有五个以上装配点(共享基座 / leader 车道四处 /

package/dist/boot/runner-deps.js

@@ -65,7 +65,7 @@ export function createSharedRunnerDeps(ctx) {
     return shared;
 }
 export function createRunnerDeps(ctx) {
-    const { config, logger, metrics, localRoot, outcomeSink, elicitation, question, toolApproval, sessionStore, memoryEngine, memorySyncRunner, runtimeCapsResolver, fileHistoryStore, legacyRewindBoundaryProbe, permissionRuleStore, fleetBus, workflowRunStore, workflowJournalStore, workflowAgentRegistry, workflowNotifyGate, workflowCompletionInbox, deliverWorkflowCompletion, getRunStore, } = ctx;
+    const { config, logger, metrics, localRoot, outcomeSink, elicitation, question, toolApproval, sessionStore, memoryEngine, sessionCaptureRecordStore, memorySyncRunner, runtimeCapsResolver, fileHistoryStore, legacyRewindBoundaryProbe, permissionRuleStore, fleetBus, workflowRunStore, workflowJournalStore, workflowAgentRegistry, workflowNotifyGate, workflowCompletionInbox, deliverWorkflowCompletion, getRunStore, } = ctx;
     const sharedRunnerDeps = createSharedRunnerDeps(ctx);
     const workflowModelAllowlist = workflowModelAllowlistFor(config);
     const selfOrchestrationDeps = config.selfOrchestrationEnabled
@@ -138,6 +138,7 @@ export function createRunnerDeps(ctx) {
         sessionStore,
         memoryBackend: memoryEngine ? memoryEngine.backend : undefined,
         memoryEngineDir: memoryEngine ? memoryEngine.root : undefined,
+        memoryCaptureRecordStore: sessionCaptureRecordStore !== undefined ? () => sessionCaptureRecordStore : undefined,
         onMemoryHarvestReport: memoryEngine
             ? (report, info) => {
                 metrics.inc("memory_harvest_total", { ok: String(report.ok), phase: info.phase, incident: report.incident?.kind ?? "none" });

package/dist/boot/runtime-caps.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— per-principal 运行期准入(design/99 §K caps 客户端)。
+ * [ref] A10:composition root 分段 —— per-principal 运行期准入([ref] §K caps 客户端)。
  *
  * 纯搬运:函数体逐字来自 `main.ts`(原 1520-1577 行),缩进不变;新增的只有 import 与包壳。
  *
@@ -13,12 +13,12 @@ import { type MemoryOptOutVerdictSource } from "../runtime-caps-resolver.js";
 export interface RuntimeCapsCtx {
     config: ServiceConfig;
     logger: Logger;
-    /** design/383 S-2:`RuntimeCaps.allowMemoryOptOut` 的本地 verdict 源(`backend.memoryOptOutGrant()`;
+    /** [ref] S-2:`RuntimeCaps.allowMemoryOptOut` 的本地 verdict 源(`backend.memoryOptOutGrant()`;
      *  SQL 后端在场才有,local 车道 undefined)。缺席 ⇒ 本键不合成(零行为差)。 */
     memoryOptOutGrant?: MemoryOptOutVerdictSource | undefined;
 }
 /**
- * design/383 §3.1(S-49 S-1b)—— `MEMORY_CAPTURE_POLICY=governed` 的**半配置拒启**(`boot/memory-consolidation.ts`
+ * [ref] §3.1([ref] S-1b)—— `MEMORY_CAPTURE_POLICY=governed` 的**半配置拒启**(`boot/memory-consolidation.ts`
  * D1 / `boot/retention-lane.ts` 同姿态:安全/合规控件不得半开)。
  *
  * governed 的语义是「per-principal verdict **必答**」:core 对 verdict 缺席一律**拒跑**(fail-closed,部署显式
@@ -29,7 +29,7 @@ export interface RuntimeCapsCtx {
  * ensureSchema 建),要么改姿态。`open`/`capture-required`/缺席 不依赖源(前者故障放行、后者全拒,
  * 都不问 verdict)。
  *
- * ⚠️ center 键 `EntitlementRuntimeCaps.allowMemoryOptOut` 是 settings-schema 的独立小件(S-50 §四 开放问题①),
+ * ⚠️ center 键 `EntitlementRuntimeCaps.allowMemoryOptOut` 是 settings-schema 的独立小件([ref] §四 开放问题①),
  * 到货前**不算源**;到货后本断言加一条「center 在场」析取臂即可,判据不变。
  */
 export declare function assertMemoryCapturePolicyWirable(input: {

package/dist/boot/session-faces.d.ts

@@ -25,7 +25,7 @@ export interface SessionFacesCtx {
     taskAttachmentStore: TaskAttachmentStore | undefined;
     fileHistoryStore: ReturnType<StoreBackend["fileHistory"]> | undefined;
     workflowCompletionInbox: WorkflowCompletionInbox | undefined;
-    /** #318:会话级任务清单车道(E21 级联的一条腿)。缺席 = 装配未接本车道 ⇒ 无清单可删。 */
+    /** [ref]:会话级任务清单车道(E21 级联的一条腿)。缺席 = 装配未接本车道 ⇒ 无清单可删。 */
     taskListLane: TaskListLane | undefined;
     /** device lane 的四表店(E21 级联的一条腿:`device_session` 绑定行随会话删)。缺席 = 非 SQL 后端。 */
     deviceStore: DeviceStore | undefined;

package/dist/boot/shutdown.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— 进程收尾(hardShutdown / drain / 三个信号处理器)。
+ * [ref] A10:composition root 分段 —— 进程收尾(hardShutdown / drain / 三个信号处理器)。
  *
  * 纯搬运:函数体逐字来自 `main.ts`(原 4385-4488 行),缩进不变;新增的只有 import 与
  * `installShutdownHandlers(ctx)` 包壳。
@@ -12,7 +12,7 @@
  *     "第二个信号"的语义读数。
  *  3. `clearInterval(reaper)` 必须是 hardShutdown 的第一件事(在 `server.close()` 之前),否则
  *     收尾期还会有 reaper tick 打向正在关闭的池。
- *  4. **进程级监听一律成对**(A-070 二轮件4):本函数装的五只(三信号 + #320① 双钩)只能经返回的
+ *  4. **进程级监听一律成对**([ref] 二轮件4):本函数装的五只(三信号 + [ref]① 双钩)只能经返回的
  *     {@link ShutdownHandle} 摘 —— 调用方手写「摘三信号」的收尾会把双钩漏在进程上,而陈旧的那只
  *     rejection 钩仍握着 `process.exit(1)`,会对后续无关的 rejection 把进程打掉。
  */
@@ -29,12 +29,12 @@ import type { BreakerStateStore, CostQuotaStore, RateLimiterStore, StoreBackend
 import type { WorkflowNotifyJournalStore } from "../orchestration/workflow-notify-journal.js";
 export interface ShutdownCtx {
     config: ServiceConfig;
-    /** #320①:崩溃遗言的 version 键(与 /v1/capabilities.version 同源=main 的 serviceVersion())。 */
+    /** [ref]①:崩溃遗言的 version 键(与 /v1/capabilities.version 同源=main 的 serviceVersion())。 */
     version: string;
     logger: Logger;
     server: ReturnType<typeof createHttpServer>;
     reaper: NodeJS.Timeout;
-    /** #261:fleet 存活对账腿(60s 定时器 + 总线订阅)。与 `reaper` 同列文件头契约 3 —— 收尾期不该再有
+    /** [ref]:fleet 存活对账腿(60s 定时器 + 总线订阅)。与 `reaper` 同列文件头契约 3 —— 收尾期不该再有
      *  对账 tick 打向正在关闭的池,订阅也要摘(否则 bus 的扇出还在往一个已停的观察者写)。 */
     fleetReconcile: {
         timer: NodeJS.Timeout;
@@ -42,11 +42,11 @@ export interface ShutdownCtx {
             stop(): void;
         };
     };
-    /** #270 车2:托管留存 sweep lane 的**控制器**(`undefined` = lane 关着,压根没建定时器)。与 `reaper`
+    /** [ref] 车2:托管留存 sweep lane 的**控制器**(`undefined` = lane 关着,压根没建定时器)。与 `reaper`
      *  同列文件头契约 3,但严格更强:那些腿只要停表就够了,本腿的 tick 打的是跨十余张表的**破坏性**事务
      *  ⇒ 必须 `await stop()` 等在飞那一轮真正落地,**然后**才让租、才关连接池(见 hardShutdown 内的三步注)。 */
     retentionLane: RetentionLaneController | undefined;
-    /** #270 车2:主动让租(把 sweep 租约的到期时间归零)—— 优雅停机后另一副本不必等满一个 TTL 才接手。
+    /** [ref] 车2:主动让租(把 sweep 租约的到期时间归零)—— 优雅停机后另一副本不必等满一个 TTL 才接手。
      *  best-effort:一次失败只意味着"下一位等 TTL",绝不阻塞停机。缺席 = lane 关着。 */
     releaseRetentionLease: (() => Promise<void>) | undefined;
     otelExporter: ReturnType<typeof startOtlpExporter> | undefined;
@@ -67,7 +67,7 @@ export interface ShutdownCtx {
         attachedStreams?: () => number;
         lastAttachEndedAt?: () => number;
     };
-    /** #131-2:store 活体探针(main 建)——不停的话 hardShutdown 后仍对正在关闭的池发探针,刷假
+    /** [ref]-2:store 活体探针(main 建)——不停的话 hardShutdown 后仍对正在关闭的池发探针,刷假
      *  store_probe_dead 告警(文件头契约 3 的同族漏网)。缺席 = 该部署形没建探针。 */
     storeLiveProbe: {
         stop(): void;
@@ -80,16 +80,16 @@ export interface ShutdownCtx {
      * HTTP 层不能自作主张。所以 `drainState.draining` 翻真的那一刻,这里同步调 `beginDrain()`。
      */
     deviceHub: import("../device-ws-hub.js").DeviceWsHub | undefined;
-    /** #131-2:config 60s 刷新环(config-center startRefreshLoop)——不停的话停机中途还可能热应用
+    /** [ref]-2:config 60s 刷新环(config-center startRefreshLoop)——不停的话停机中途还可能热应用
      *  一份新配置。缺席 = 纯 env 部署没起环。 */
     configCenter: {
         stopRefreshLoop(): void;
     } | undefined;
 }
 /**
- * `installShutdownHandlers` 的**摘除把手**(A-070 二轮重扫件4)。
+ * `installShutdownHandlers` 的**摘除把手**([ref] 二轮重扫件4)。
  *
- * 存在理由:本函数装的是**进程级**监听(三信号 + #320① 双钩),而进程级注册表是全局单例 —— 一个进程里
+ * 存在理由:本函数装的是**进程级**监听(三信号 + [ref]① 双钩),而进程级注册表是全局单例 —— 一个进程里
  * 装两次就是两套 handler 同时在场。生产进程只装一次、装到死,所以这把手服务的是**同进程内反复装配**的
  * 那一族调用方(测试):此前它们各自手写「只摘三信号」的收尾,双钩每次净泄漏两只,而陈旧 handler 会对
  * **后续无关**的 rejection 执行 `process.exit(1)`。注册/摘除配对因此必须由装配方给,不许调用方各猜一份。

package/dist/boot/side-query-lane.d.ts

@@ -1,8 +1,8 @@
 /**
- * #303([4610] test 报「/model 中途切换校验探针经 POST /v1/side-query 对有效 key 返回上游 401」)——
+ * [ref]([ref] test 报「/model 中途切换校验探针经 POST /v1/side-query 对有效 key 返回上游 401」)——
  * side-query 面的 **per-model key plane** 装配。
  *
- * ## 病灶(#303 立案时亲验 core 5.43.0 dist 实现行)
+ * ## 病灶([ref] 立案时亲验 core 5.43.0 dist 实现行)
  *
  * core 的 side-query verb 当时**结构性没有 key 座位**:
  *   · `core/side-query.d.ts` 的 `SideQuerySpec` 无 `apiKey` / `getApiKeyAndHeaders` 字段;
@@ -16,7 +16,7 @@
  * 当时的窄修 = 一只 **key 注入 brain wrapper**(`createPerModelKeyBrain`),并在顶注写明「core 一旦
  * 给 `SideQuerySpec` 补上 key 座位,本 wrapper 即可撤」,撤除信号挂机器钉。
  *
- * ## #341 换装(core 5.46.0 提货,[4615] 座位到货 —— 撤除条件已满足)
+ * ## [ref] 换装(core 5.46.0 提货,[ref] 座位到货 —— 撤除条件已满足)
  *
  * core 5.46.0 的 `SideQuerySpec` 有了 `getApiKeyAndHeaders?: TaskSpec["getApiKeyAndHeaders"]`,
  * `runSideQuery` 每次调用按**解析后的** `Model` 调它,并把 `{apiKey, headers}` 铸进 brain options
@@ -32,22 +32,22 @@
  *
  * 🔴 **poison(sealed key 不可解)上抛,绝不静默回落网关 key** —— `resolveModelApiKey` 抛
  * `SealedKeyPoisonedError` 是「这个模型配了托管密钥但解不开」的响亮态;吞成 undefined 等于用共享
- * 网关账号去打这只模型的上游,正是毒丸机制存在的理由(CLAUDE.md #157 安全轴 fail-closed)。换装后
+ * 网关账号去打这只模型的上游,正是毒丸机制存在的理由(CLAUDE.md [ref] 安全轴 fail-closed)。换装后
  * 这条语义由 core 承载得更彻底:座位抛 ⇒ `runSideQuery` 的 `await` 直接上抛,brain 一个字节都没发。
  *
- * ## 具名残余已在**源头**清偿(core 5.57.0,#345 提货批)—— 本席的 P-DEBT 腿随之撤线
+ * ## 具名残余已在**源头**清偿(core 5.57.0,[ref] 提货批)—— 本席的 P-DEBT 腿随之撤线
  *
  * 曾经的具名残余是「无 per-model key 的 **off-route** 模型仍收网关 key」(codex R1-F1):座位回
  * `undefined` ⇒ core 用网关 key,而选路仍按 `model.baseUrl` ⇒ 这一次调用真把共享网关凭据发给了别家
  * 主机。当年**刻意不在本面收严**,理由是「与主推理链逐字同语义,单面收严 = 同一只模型跑任务能用、
- * 问一句 401」,收严件挂在跨面件 #309;补偿是一条 `P-DEBT` 计数(census 第 32 行)。
+ * 问一句 401」,收严件挂在跨面件 [ref];补偿是一条 `P-DEBT` 计数(census 第 32 行)。
  *
  * core 5.57.0 把这件事**在唯一正确的层**做了:`adjudicateModelRoute`(`brain/route-adjudicator.ts`)
  * 是配对法的单一实现,三只一方 brain(openai / anthropic / open-responses)在 `buildRequest` 里逐次
  * 复判 —— 部署声明了 `config.baseUrl` 而 entry URL 不在那个根上、凭据又只有部署级那一份 ⇒
  * `route.credential_mismatch` 响亮拒;连部署级凭据都没有 ⇒ `route.credential_missing`。**三面同批**
  * (主推理链 / side-query / WebFetch 摘要走的是同一只 brain 栈),旋钮 = 给模型自己的凭据、或不声明
- * `config.baseUrl`(core 的 `"unpinned"` 快速起步姿态)。⇒ #309 要的「三面同批 + 旋钮」由上游一次交齐。
+ * `config.baseUrl`(core 的 `"unpinned"` 快速起步姿态)。⇒ [ref] 要的「三面同批 + 旋钮」由上游一次交齐。
  *
  * 于是本席的 `isOffRouteBaseUrl` + `recordFailOpen("server.model-key.off-route-model-uses-gateway-key")`
  * 两件**一并撤线**:那条计数的语义是「这一次调用真把网关凭据发给了别家」,而在 5.57 上那次调用根本
@@ -67,7 +67,7 @@ export type PerModelAuthSeat = NonNullable<SideQuerySpec["getApiKeyAndHeaders"]>
 /** side-query 执行席:HTTP 路由(`routes/side-query.ts`)唯一的 brain 出口。 */
 export type SideQueryLane = (spec: SideQuerySpec) => Promise<SideQueryResult>;
 export interface SideQueryLaneCtx {
-    /** 与 `RunnerDeps.brain` **同一只**实例(#341 换装后本席不再包它 —— key 走 spec 座位)。 */
+    /** 与 `RunnerDeps.brain` **同一只**实例([ref] 换装后本席不再包它 —— key 走 spec 座位)。 */
     brain: Brain;
     /** 活配置引用:目录/角色表/网关地址被 config-center 就地热应用(`mutateInPlace`),按调用取值才跟得上。 */
     config: ServiceConfig;
@@ -75,7 +75,7 @@ export interface SideQueryLaneCtx {
     getKeyResolver: () => KeyResolver;
 }
 /**
- * per-model auth 座(#341,core 5.46.0 `SideQuerySpec.getApiKeyAndHeaders` 的 server 侧填充物)。
+ * per-model auth 座([ref],core 5.46.0 `SideQuerySpec.getApiKeyAndHeaders` 的 server 侧填充物)。
  *
  * 语义(逐条对齐主推理链 `getApiKeyAndHeaders`,也逐条对齐它取代的 wrapper 那三条臂):
  *  · `upstream`(spec 自带的座位)**解出凭据** ⇒ 原样透传,含 `headers`(上游/装饰器已经定了凭据,
@@ -86,8 +86,8 @@ export interface SideQueryLaneCtx {
  *  · resolver 抛(sealed key 中毒)⇒ **上抛**,`runSideQuery` 的 `await` 直接把它扔给调用方,
  *    本次调用整体失败,一个字节都不发。
  *
- * 🔴 A-057.59 [PARTIAL high](2026-08-19 立;**2026-08-24 / core 5.57.0 源头清偿,本席腿撤线**)——
- * 「无 per-model key 的 off-route 模型仍收网关 key」这条具名残余的收严件曾挂在跨面件 #309,补偿是一条
+ * 🔴 [ref] [PARTIAL high](2026-08-19 立;**2026-08-24 / core 5.57.0 源头清偿,本席腿撤线**)——
+ * 「无 per-model key 的 off-route 模型仍收网关 key」这条具名残余的收严件曾挂在跨面件 [ref],补偿是一条
  * `P-DEBT` 计数。core 5.57.0 的 `adjudicateModelRoute` 在**三只一方 brain 的 request gate** 上把它改成
  * 响亮拒(`route.credential_mismatch` / `route.credential_missing`),三面同批、旋钮成文 ⇒ 那条计数的
  * 前提(「这一次调用真把网关凭据发给了别家」)不再成立,`isOffRouteBaseUrl` 与 `recordFailOpen` 一并
@@ -98,8 +98,8 @@ export declare function createPerModelAuthSeat(getKeyResolver: () => KeyResolver
     readonly upstream?: SideQuerySpec["getApiKeyAndHeaders"];
 }): PerModelAuthSeat;
 /**
- * per-model key 注入 brain wrapper —— **#341 后只服务 WebFetch 摘要面**
- * (`boot/webfetch-summarize-lane.ts`)。side-query 面已换到 core 的 spec 座位(见顶注「#341 换装」);
+ * per-model key 注入 brain wrapper —— **[ref] 后只服务 WebFetch 摘要面**
+ * (`boot/webfetch-summarize-lane.ts`)。side-query 面已换到 core 的 spec 座位(见顶注「[ref] 换装」);
  * core 的 `WebFetchSummarizerOptions` 至今只有 `maxContentChars`(亲验 5.46.0 `dist/tools/web.d.ts`),
  * 那一面**没有座位可换**,只能继续在 brain 层补凭据。
  *
@@ -116,7 +116,7 @@ export declare function createPerModelKeyBrain(brain: Brain, getKeyResolver: ()
  * 装配 side-query 执行席 = 真 `runSideQuery` + core 的 per-model auth 座,models/roles 与 Runner 同源。
  *
  * **按调用**取两件活值(`models` / `getKeyResolver`),因为它们是**同一次** center 下发里成对换代的
- * (#303 codex R1-F2:目录与密钥表零 await 窗成对换代):
+ * ([ref] codex R1-F2:目录与密钥表零 await 窗成对换代):
  *  · `models` = `expandTiers(config.models, config.tiers)` —— 档位词 / CC 别名(`flash`/`opus`/…)在
  *    side-query 上照常可选路(core 的 `Runner` 构造时做同一件事),且 `Runner` 那次展开是**构造时快照**,
  *    而本路由的模型白名单门(`routes/side-query.ts` 的 `isModelAllowlisted`)按请求现算同一张增广目录 ——

package/dist/boot/stores.js

@@ -23,6 +23,7 @@ import { buildMemoryRemoteLaneWarn, memoryEngineBackendFor, memoryEngineRemoteLa
 import { assertToolResultProvenanceSchema } from "../plugins/tool-result-store-sql.js";
 import { assertPermissionRuleApprovalSchema, assertPermissionRuleTicketSchema } from "../plugins/permission-rule-store-sql.js";
 import { assertApprovalAskRuleMaterialSchema } from "../plugins/approval-ask-store-sql.js";
+import { assertCheckpointBidiColumnSchema } from "../plugins/checkpoint-store-sql.js";
 import { assertFileHistorySchema } from "../plugins/file-history-store-sql.js";
 import { resolveStreamApprovalGate } from "../tool-approval.js";
 import { buildMemoryWriteBoundaryAudit, effectiveMemoryPersistenceCapable } from "./memory-boundary.js";
@@ -52,6 +53,10 @@ export async function openStores(ctx) {
             await assertToolResultProvenanceSchema(async (sql) => ({ rows: (await pgPool.query(sql)).rows }), "pg");
         else if (mysqlPool)
             await assertToolResultProvenanceSchema(async (sql) => ({ rows: (await mysqlPool.query(sql))[0] }), "tidb");
+        if (pgPool)
+            await assertCheckpointBidiColumnSchema(async (sql) => ({ rows: (await pgPool.query(sql)).rows }), "pg");
+        else if (mysqlPool)
+            await assertCheckpointBidiColumnSchema(async (sql) => ({ rows: (await mysqlPool.query(sql))[0] }), "tidb");
         if (config.permissionRulesEnabled) {
             if (pgPool)
                 await assertPermissionRuleApprovalSchema(async (sql) => ({ rows: (await pgPool.query(sql)).rows }), "pg");

package/dist/boot/task-list-lane.d.ts

@@ -1,5 +1,5 @@
 /**
- * 会话级任务清单店车道(#318;黑板 [4659] F2 症状 → [4692] 定谳)。
+ * 会话级任务清单店车道([ref];黑板 [ref] F2 症状 → [ref] 定谳)。
  *
  * core 的 task-list 家族(TaskCreate/TaskGet/TaskUpdate/TaskList)把持久化做成了注入缝:
  * `assembleCodeTools({ taskList: true, taskListStore })` —— **不传** `taskListStore` 时 core 落
@@ -13,7 +13,7 @@
  *
  * ## 分区语义:listKey = 会话
  * 任务清单是**会话级待办**:同 session 跨 turn / 跨 resume 连续,不同 session 互不可见。
- * (design/147 §6 D2 的「团队共享清单」是同一张表的另一族分区键 —— 见 {@link taskListKeyFor}
+ * ([ref] §6 D2 的「团队共享清单」是同一张表的另一族分区键 —— 见 {@link taskListKeyFor}
  * 的 `session:` 命名空间位。)
  *
  * ## 后端三态(与 roster / mailbox / background-agent 同姿势)
@@ -25,7 +25,7 @@
  *    这与 local 形其余会话态设施(perSessionCwd / TtlSessionStore)是同一姿势。
  *
  * ## 为什么 SQL 形也进同一只缓存
- * SQL twin 是池上的无状态薄壳,每 turn 新铸一只在**行**的层面完全等价(真源在表里,`[4692]`
+ * SQL twin 是池上的无状态薄壳,每 turn 新铸一只在**行**的层面完全等价(真源在表里,`[ref]`
  * 的 T2 三条就钉这个)。仍然缓存实例的理由是 core 的另一半契约:`createTaskListTools` 对
  * **同一只 store 实例**维护一条 per-store promise 链来串行 read-modify-write。同副本内复用实例
  * ⇒ 本进程内的串行化真生效,跨副本仍由 SQL twin 自己的分区锁兜底;缓存被逐出也只是回到「靠