@sema-agent/server 7.52.1 → 7.53.0

package/dist/bench/s1/oracle.d.ts

@@ -4,11 +4,11 @@
  * ONE standalone oracle, shared by ALL three arms; ONLY the profile (arms.ts) differs. The oracle is:
  *   - OBJECTIVE: it runs `runExecGate` (real exit codes; null-exit never passes; an empty suite never passes —
  *     `exec-gate.d.ts`). There is NO model/LLM parameter ANYWHERE in this type (objective-oracle discipline,
- *     design/89 §2.2.1 — the LLM is a GATE inside an arm, never the MEASURE in the numerator).
+ *     [ref] §2.2.1 — the LLM is a GATE inside an arm, never the MEASURE in the numerator).
  *   - DECORRELATED + ANTI-REWARD-HACK: it grades in a DISTINCT grader env (`ctx.newGraderEnv()`), never the
  *     worker's own env — the SAME isolation the repair-loop §5.1 identity check enforces.
  *   - HIDDEN + RESTORED-BEFORE-SCORING: the worker never sees `task.hiddenTestFiles`; the oracle WRITES them into
- *     the grader checkout, overwriting any worker-authored same-named file (anti-rewrite, design/89 §2.2).
+ *     the grader checkout, overwriting any worker-authored same-named file (anti-rewrite, [ref] §2.2).
  *
  * The repair leg needs core's `RepairOracle = (graderEnv, evidence) => OracleResult` shape — a DIFFERENT
  * signature. `repair-oracle-adapter.ts` wraps this standalone oracle into that closure (do NOT pass `runOracle`

package/dist/bench/s1/reviewer.d.ts

@@ -1,6 +1,6 @@
 /**
  * S1 value-verdict harness — the DETERMINISTIC RUBRIC REVIEWER (the C2 model). SPEC-S1-value-harness.md §9 +
- * design/89 §3.4. PURE / deterministic, NO model call.
+ * [ref] §3.4. PURE / deterministic, NO model call.
  *
  * 🔴 WHY A FIXED RUBRIC, NOT AN LLM REVIEWER: an LLM reviewer reintroduces judge noise AND makes C2
  * (human-review wall-time) non-reproducible. The reviewer is a fixed-checklist approval decider whose

package/dist/bench/s1/row.d.ts

@@ -1,8 +1,8 @@
 /**
- * S1 value-verdict harness — the RawRow `s1.v1` CONTRACT (design/95 metrics layer).
+ * S1 value-verdict harness — the RawRow `s1.v1` CONTRACT ([ref] metrics layer).
  *
- * 🔴 RawRow IS core's `RunRecord` (the design/95 metric input) + the OUT-OF-BAND provenance the harness needs.
- *    core ships the design/95 metrics layer via the SUBPATH export `@sema-agent/core/bench`(1.111.0 首发;L17:版本锚随装机 core 走,见 S1_CORE_VERSION)
+ * 🔴 RawRow IS core's `RunRecord` (the [ref] metric input) + the OUT-OF-BAND provenance the harness needs.
+ *    core ships the [ref] metrics layer via the SUBPATH export `@sema-agent/core/bench`(1.111.0 首发;L17:版本锚随装机 core 走,见 S1_CORE_VERSION)
  *    The harness no longer mirrors the types — it IMPORTS the real `RunRecord` /
  *    `OracleVerdicts` / `DeliveryDecision` / `CoreStatsSubset` / `InterceptCounterfactual` and re-expresses
  *    `RawRow` as `RunRecord & { schemaVersion; meta? }`. A `RawRow[]` is therefore assignable to `RunRecord[]`,
@@ -15,7 +15,7 @@
  * 🔴 OWNERSHIP SPLIT (anti-laundering — load-bearing):
  *   - The HARNESS (this file + arms.ts) is the PRODUCER: it emits ONE conformant row per (task × arm × seed) with
  *     the raw measurement inputs (oracle / stats / delivery / counterfactual) and an HONEST `runStatus`.
- *   - The METRIC TOOL (core `buildReport`, design/95) does the CORRECTLY/INCORRECTLY/UNVERIFIED-withheld split via
+ *   - The METRIC TOOL (core `buildReport`, [ref]) does the CORRECTLY/INCORRECTLY/UNVERIFIED-withheld split via
  *     the counterfactual JOIN + the Simpson grouping. The harness NEVER credits a bare withhold as value.
  *   - The NUMERATOR is ONLY DELIVERED-CORRECT, and the OBJECTIVE oracle (oracle.ts) is the measure — an LLM-judge
  *     is NEVER in the numerator (it may only be a GATE inside an arm).
@@ -90,7 +90,7 @@ export declare function rowToJsonl(row: RawRow): string;
 /** Serialize a batch of RawRows to a JSONL document (one row per line, trailing newline). */
 export declare function rowsToJsonl(rows: RawRow[]): string;
 /**
- * 🔴 Wire the REAL design/95 metric tool. `buildReport` (core 1.111.0 `@sema-agent/core/bench`) is the
+ * 🔴 Wire the REAL [ref] metric tool. `buildReport` (core 1.111.0 `@sema-agent/core/bench`) is the
  * value-verdict JOIN: it SCORES only `scored` rows, GROUPS by `(suiteVersion, taskId, archetype, valueDimension,
  * arm)` (the Simpson guard), folds each cell, splits the withhold bucket by the counterfactual, and emits the
  * `ValueJudgmentReport` (groupedCells / comparisons / cells / pareto / excluded). A `RawRow[]` is assignable to its

package/dist/bench/s1/runner-ctx.d.ts

@@ -3,7 +3,7 @@
  * Runner ingredients (config / brain / pricing), the SAME budget for every arm, and the injected deterministic
  * clock that makes C2 (human-review wall-time) reproducible.
  *
- * 🔴 THE §3.2 RED LINE (design/89's #1 confound): every leaf TaskSpec across all 3 arms carries the SAME
+ * 🔴 THE §3.2 RED LINE ([ref]'s #1 confound): every leaf TaskSpec across all 3 arms carries the SAME
  * `limits.{ maxTokens, maxCostUsd, maxTurns }` (core ≥5.8: budget keys live ONLY in `limits` — a top-level
  * `maxTokens`/`maxCostUsd` is a silently-unread dead key), and TEAM's per-worker budgets sum to ≤ the solo budget — so no
  * arm can win on a bigger pie. `assertBudgetMatch` (below) is the build-time guard the shape test runs.
@@ -36,7 +36,7 @@ export interface RowBudget {
 export declare function budgetDescriptor(budget: BenchBudget, arm: string, teamWorkerBudgetSumUsd?: number): RowBudget;
 /** The single budget every arm shares (the §3.2 red line). All scalars are the SAME across SOLO/SUP/TEAM. */
 export interface BenchBudget {
-    /** SAME base model all arms (design/89 §3.2 — decorrelation is a separate axis, not the value axis). */
+    /** SAME base model all arms ([ref] §3.2 — decorrelation is a separate axis, not the value axis). */
     modelId: string;
     /** `TaskSpec.limits.maxTokens` — SAME all arms. */
     maxTokens: number;
@@ -52,7 +52,7 @@ export interface BenchBudget {
 /**
  * An injectable deterministic clock (SPEC §2). EVERY Runner in EVERY arm is built with `now: ctx.now`, and the
  * reviewer's modeled think-time advances `advanceClock(ms)` — so `stats.humanReview.totalWaitMs` is reproducible
- * and NEVER consumes real wall-time (`RunnerDeps.now`, core types.d.ts:1002 / design/91 §4.3 flaky-guard).
+ * and NEVER consumes real wall-time (`RunnerDeps.now`, core types.d.ts:1002 / [ref] §4.3 flaky-guard).
  *
  * 🔴 CLOCK-ADVANCE OWNERSHIP (review #10 — HARNESS-OWNS-CLOCK, the single fold point per arm): the modeled review
  * wait is folded into ctx.clock by the HARNESS exactly once per arm — SUP in driveSupSuspendResume (per leg), TEAM

package/dist/boot/config-center.d.ts

@@ -40,9 +40,9 @@ export interface ConfigCenterRuntime {
     /** per-model key resolver 首建(原位调用,见文件头注 5)。 */
     initKeyResolver(): void;
     /** 60s refresh cadence + boot-deferred 到货续接。
-     *  `limitSync`(#322 批1)= 恒构造的两只限额座的换代口:commit 之后**零 await 内**推一把,与 pricing /
+     *  `limitSync`([ref] 批1)= 恒构造的两只限额座的换代口:commit 之后**零 await 内**推一把,与 pricing /
      *  keyResolver 那两件派生重建同族(缺席 = 这条腿本部署没装配,例如 run-local)。
-     *  `swapRunnerModels`(core 5.49,[4775]①)= 模型面永久热的换装口:plane 变更候选在 commit 前喂给
+     *  `swapRunnerModels`(core 5.49,[ref]①)= 模型面永久热的换装口:plane 变更候选在 commit 前喂给
      *  全部 boot Runner 原子换代;在场 ⇒ models-tiers defer/restart 臂退役,缺席 ⇒ 旧 defer 行为逐字保留。 */
     startRefreshLoop(a: {
         runnerTierFrozen: boolean;
@@ -53,13 +53,13 @@ export interface ConfigCenterRuntime {
             tiers: Record<string, string>;
         }) => void;
     }): void;
-    /** #131-2:停刷新环(hardShutdown 收尾链;幂等,未起环时 no-op)。 */
+    /** [ref]-2:停刷新环(hardShutdown 收尾链;幂等,未起环时 no-op)。 */
     stopRefreshLoop(): void;
-    /** #324(core 5.50 design/338):mid-turn MCP 撤销台账读口,喂 `RunnerDeps.mcpRevocations` 席。
+    /** [ref](core 5.50 [ref]):mid-turn MCP 撤销台账读口,喂 `RunnerDeps.mcpRevocations` 席。
      *  **取走即声明接线**——调用本方法后,restart 信号的 mcp 片对纯删除向豁免(台账即时承接);
      *  不取 ⇒ 旧 restart 语义逐字保留(fail-closed)。 */
     takeMcpRevocations(): import("../config-center/mcp-revocation.js").McpRevocationLedger;
-    /** #324 诊断投影:当前被撤销的 MCP 服务器名单;纯 env 部署(无配置管道)= undefined(additive 纪律)。 */
+    /** [ref] 诊断投影:当前被撤销的 MCP 服务器名单;纯 env 部署(无配置管道)= undefined(additive 纪律)。 */
     mcpRevocationState(): {
         revoked: string[];
     } | undefined;
@@ -80,11 +80,18 @@ export interface ConfigCenterRuntime {
         since: number;
         blocked?: string[];
     } | undefined;
-    /** #322 世代账:/health 的 target/applied/失败持续时长三键 + 诊断端点的 configApply 段(同一份读数)。
+    /** [ref] 世代账:/health 的 target/applied/失败持续时长三键 + 诊断端点的 configApply 段(同一份读数)。
      *  `undefined` = 本部署没有配置管道(纯 env worker)⇒ 两个读面的形状**逐字不变**(additive 纪律)。 */
     configApplyState(): ConfigApplyLedgerView | undefined;
+    /** DESIGN-278 §5 S2([ref]):center **当前在管**的 ServiceConfig 键集 —— `GET /v1/config/catalog` 判
+     *  `effectiveLane` 的 center 半场。投影自最近一次成功应用的候选(`latestEffective`,LKG/refresh 同一
+     *  份推进点;判据单源 = apply-effective.ts `centerManagedConfigKeys`)。`undefined` = 没有配置管道。
+     *  ⚠️ 部分应用窗(codex R2-F2 登记):某组整拒时 live config 已吃进其它组而 latestEffective 不推进,
+     *  该窗内本键集滞后一代 —— 目录端点只据此报**归因位**(managedNow),值仍是活 config 实算;
+     *  逐键 applied 账(设计稿 §8-7)收口这半格。 */
+    centerManagedKeys(): ReadonlySet<string> | undefined;
     /**
-     * #322 追加件:手动触发**一次既有** refresh 拍(`POST /v1/admin/config/refresh` 的实现面)。
+     * [ref] 追加件:手动触发**一次既有** refresh 拍(`POST /v1/admin/config/refresh` 的实现面)。
      *
      * 一拍在飞 ⇒ **join** 它(并发调用共享同一拍,绝不并发双拍、绝不另铸拉取路径);返回时该拍已落地,
      * 所以调用方紧接着读 `configApplyState()` 就是本次触发的结果。

package/dist/boot/config-center.js

@@ -12,6 +12,7 @@ import { validatePromptsDomain, CORE_ENGINE_VERSION } from "../prompts-domain-va
 import { centerScenarios, centerScenarioDetails } from "../capabilities/scenarios.js";
 import { configLkgEnabled } from "../config.js";
 import { defaultLkgPath, defaultSkillCacheDir, saveLkg, loadLkg } from "../config-lkg.js";
+import { centerManagedConfigKeys } from "../config-center/apply-effective.js";
 import { createConfigProvider, raceBootFetch, BOOT_FETCH_DEFERRED } from "../config-provider.js";
 import { createKeyResolver } from "../key-resolver.js";
 import { ensureSealedKeyStore, reportExecutionPublicKey } from "../sealed-key.js";
@@ -354,6 +355,7 @@ export async function createConfigCenterRuntime(ctx) {
         restartState: () => pendingRestart,
         planeDeferredState: () => planeDeferredNoHandoff,
         configApplyState: () => (configProvider ? applyLedger.view() : undefined),
+        centerManagedKeys: () => (configProvider ? centerManagedConfigKeys(latestEffective) : undefined),
         async refreshNow() {
             if (!manualRefresh)
                 return "not-wired";

package/dist/boot/coordinators.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— 进程内活体 HITL 协调器 + SendUserFile 工具面。
+ * [ref] A10:composition root 分段 —— 进程内活体 HITL 协调器 + SendUserFile 工具面。
  *
  * 纯搬运:函数体逐字来自 `main.ts`(原 1443-1518 行),缩进不变;新增的只有 import 与包壳。
  *
@@ -21,13 +21,13 @@ export interface LiveCoordinatorsCtx {
     logger: Logger;
     backend: StoreBackend | undefined;
     sendUserFileTaskEnvs: TaskEnvRegistry | undefined;
-    /** #154 车二:持久化权限规则的同意车道(main.ts 与 `RunnerDeps.permissionRuleStore` **同源**于
+    /** [ref] 车二:持久化权限规则的同意车道(main.ts 与 `RunnerDeps.permissionRuleStore` **同源**于
      *  `backend.permissionRule()` 的同一个返回值)。在场 ⇒ ask 帧投 `ruleOffers` + 回决可兑付。 */
     ruleConsent: RuleConsentLane | undefined;
-    /** #295(F-1):卡批规则的 project root 解析器(语义单点=task-cwd.ts `cardRuleScopeRoot`;main.ts
+    /** [ref](F-1):卡批规则的 project root 解析器(语义单点=task-cwd.ts `cardRuleScopeRoot`;main.ts
      *  用 per-session cwd 登记簿 + config 铸)。缺席 ⇒ 不铸 scope,卡批规则落 core 的 global 缺省。 */
     ruleScopeRootFor: ((sessionId: string | undefined) => string | undefined) | undefined;
-    /** #329:PARKED 行迟到决议的赎回席**取值口**(晚绑 —— 席本体是 `createHttpServer` 的产物,而本段
+    /** [ref]:PARKED 行迟到决议的赎回席**取值口**(晚绑 —— 席本体是 `createHttpServer` 的产物,而本段
      *  必须排在它之前;同款 holder 先例 = reaper 的 `getRunDenySweep`)。取到 undefined ⇒ 那条臂逐字回落
      *  修前 404(partial 部署安全)。缺席(不传本键)⇒ 协调器整条迟到腿的 PARKED 臂恒 404。 */
     getParkedRedeem?: () => ParkedAskRedeem | undefined;

package/dist/boot/crash-last.d.ts

@@ -1,5 +1,5 @@
 import { z } from "zod";
-/** 遗言文件的读回 schema(宪法 [2704] §2:边界读一律 safeParse,不裸铸)。写侧五键同形。 */
+/** 遗言文件的读回 schema(宪法 [ref] §2:边界读一律 safeParse,不裸铸)。写侧五键同形。 */
 declare const CrashLastSchema: z.ZodObject<{
     at: z.ZodString;
     version: z.ZodString;

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

@@ -1,5 +1,5 @@
 /**
- * design/158 A10 分段 —— **device lane 的装配件**(device-executor-lane-v2 §4.6/§4.7/§5,车A-4)。
+ * [ref] A10 分段 —— **device lane 的装配件**(device-executor-lane-v2 §4.6/§4.7/§5,车A-4)。
  *
  * 一处建齐三件活对象:**店**(四表双库的 `DeviceStore`)→ **准入链**(`DeviceEnrollment`,含跨副本
  * 限速座)→ **WS 汇聚端**(`DeviceWsHub`)。三件的依赖是单向的(hub 吃 store+enrollment),所以它们
@@ -11,7 +11,7 @@
  *
  * 🔴 本模块**不**做车道选择:`REMOTE_EXEC=device` 与否由调用方判(main.ts)。它只回答一件事 ——
  * 「这台机器上,device lane 的三件装配得起来吗」。装不起来就返回 `undefined`,由
- * {@link assertDeviceLaneWired} 响亮拒启(#157:执行车道上没有静默降级臂)。
+ * {@link assertDeviceLaneWired} 响亮拒启([ref]:执行车道上没有静默降级臂)。
  */
 import { type DeviceEnrollRateLimiter, type DeviceEnrollment } from "../device-enrollment.js";
 import type { DeviceStore } from "../device-store.js";
@@ -70,7 +70,7 @@ export declare function createDeviceLane(ctx: DeviceLaneCtx): DeviceLane | undef
  * 建表失败 ⇒ `backend=undefined` + 一条 warn 就继续启动。那次启动里 device lane 的四表整个不在,
  * 而 `boot/execution-env.ts` 的第七臂拿不到三件 ⇒ `executionEnvFactory` 落 `undefined` ⇒ core 拿
  * `StubExecutionEnv`:**一台自称在员工设备上执行的 worker 实际在自己进程里跑,而且回执同形**。
- * 那正是 #157「执行车道禁静默降级」点名的样板病,也正是 A-1 那条临时门当初要拦的东西 —— 换执法点,
+ * 那正是 [ref]「执行车道禁静默降级」点名的样板病,也正是 A-1 那条临时门当初要拦的东西 —— 换执法点,
  * 不是取消执法。
  *
  * 抛而不是 warn:降级的代价由用户承担(他以为命令跑在自己机器上、看到的却是云上一个空目录的结果)。

package/dist/boot/engine-lease.d.ts

@@ -1,10 +1,10 @@
 /**
- * #118(黑板 [5371]②,cli [5394] 认领消费)—— 引擎**附着租约自退**。
+ * [ref](黑板 [ref]②,cli [ref] 认领消费)—— 引擎**附着租约自退**。
  *
  * ## 防的是什么
  *
  * 壳自 spawn 引擎的本机形里,壳正常退出之后引擎**继续活着**:占端口、占库连接池、占模型配额,而且
- * 用户已经离开了、再没有人会关心它。#219 的 parent 监视只覆盖「生我的那个 pid 没了」这一形,而
+ * 用户已经离开了、再没有人会关心它。[ref] 的 parent 监视只覆盖「生我的那个 pid 没了」这一形,而
  * **多壳共享一只引擎**时它结构性地问错了问题 —— 首壳退了 peer 还在用,监视父 pid 要么误杀要么永不触发。
  * 本件问的是那个真正的问题:**还有没有人附着**。
  *
@@ -13,7 +13,7 @@
  *  1. **opt-in**:`ENGINE_AUTO_EXIT` 默认 **false** ⇒ 整件不装配(`boot/shutdown.ts` 连本函数都不调)。
  *     服务器部署形逐字零变化 —— 一台 k8s 上的 replica 半夜没人用不是「该退了」,是**正常的低谷**。
  *     壳 spawn 形由壳在 spawn 时显式注入 `true`。**部署级旋钮无条件生效**:它不派生自任何客户端表态
- *     (本仓 operator-knob 铁律,#153 同病两犯史),`ENGINE_LINGER_MS` 的坏值校验也不挂在本键的表态上。
+ *     (本仓 operator-knob 铁律,[ref] 同病两犯史),`ENGINE_LINGER_MS` 的坏值校验也不挂在本键的表态上。
  *  2. **自退判据 = 三合取,且必须持续满 `lingerMs`**:
  *       · 附着租约集空(`attachedStreams() === 0`);
  *       · 无在飞 run(`inflight() === 0` —— **与 /health 的 `inflight` 同一只 getter**,不另立第二判据);
@@ -27,7 +27,7 @@
  *  4. **退出 = 走 `drain`**,即 `boot/shutdown.ts` 里 SIGTERM 用的那一条 `drainThenShutdown`:拒新提交
  *     (503+Retry-After)→ 候在途腿跑完 → `hardShutdown`。in-flight run 的结算 / park 语义与人工停机
  *     **逐字一致**。本模块自己**从不** `process.exit`。
- *  5. **crash-last 判别位**([5371] ④「flush 判别位标 auto-exit 非崩溃」):走上面那条受控退,
+ *  5. **crash-last 判别位**([ref] ④「flush 判别位标 auto-exit 非崩溃」):走上面那条受控退,
  *     `hardShutdown` 一进来就 `clearCrashLast` ⇒ 遗言文件被删 ⇒「文件在场 ⇔ 上次退出=崩溃」这条契约
  *     对自退**自动成立**。刻意**不**另写一条 `reason:"auto-exit"` 的遗言行:那会把该文件的语义从
  *     「崩溃判别位」稀释成「上次退出记录」,而运维读它就是为了判前者(见 `crash-last.ts` 顶注)。

package/dist/boot/governance-seams.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/170 件B/C/D(#252 件1)—— 三个**部署治理座席**的装配点:把 core 5.13.0 起就存在、本仓一直
+ * [ref] 件B/C/D([ref] 件1)—— 三个**部署治理座席**的装配点:把 core 5.13.0 起就存在、本仓一直
  * 零接线的三个 `RunnerDeps` seam 接上。
  *
  *  · 件B `compliancePostureResolver` —— per-principal 合规档位否决(闭集 profile × 闭集 capability;
@@ -9,9 +9,9 @@
  *
  * ## 真源:为什么三件都只接 env
  *
- * design/170 §1 的三层分工表里,center 那一列对 B/C/D 写的都是「**新建**」——中心侧的档位真源 / 策略
+ * [ref] §1 的三层分工表里,center 那一列对 B/C/D 写的都是「**新建**」——中心侧的档位真源 / 策略
  * 真源 / 保留期真源**至今不存在**。接一条 center 腿等于造一个恒缺席的假面(件A 的 org 目录能接 center,
- * 是因为那一面真被建出来了)。所以本装配点的供数只有部署配置面,并且这**恰好**是 design/170 §4.3 对
+ * 是因为那一面真被建出来了)。所以本装配点的供数只有部署配置面,并且这**恰好**是 [ref] §4.3 对
  * 「谁能解锁」的裁定:锁是**配置期物**,铸锁真源只有 center governance 域与部署 env,二者都是 operator
  * 控制的配置面,自带各自既有鉴权 —— 「谁能解锁」≡「谁能改部署配置」,不引入新鉴权面。
  *
@@ -72,11 +72,11 @@ export interface GovernanceSeamsCtx {
         store: object | undefined;
     }>;
     /**
-     * #270 车1 —— **本 build 是否真的接了留存执行器**(sweep lane;车2 的 `startRetentionLane()`)。
+     * [ref] 车1 —— **本 build 是否真的接了留存执行器**(sweep lane;车2 的 `startRetentionLane()`)。
      * 缺席 = `false`。
      *
      * 🔴 为什么这一位必须存在(codex 交叉复审 R2-[critical],验真后修):core 的
-     * `assertRetentionCapability` 只读**店的声明位**。#270 车1 让三只 SQL 店如实声明了 `"managed"`
+     * `assertRetentionCapability` 只读**店的声明位**。[ref] 车1 让三只 SQL 店如实声明了 `"managed"`
      * (它们的行确实由托管留存删),于是那道门从此**放行** locked policy —— 可执行器还在车2 手里。
      * 两者之间的窗口如果什么都不做,后果正是本仓最忌的那种:部署自述「策略已受管」、审计与能力面
      * 也这么说,而**没有任何东西在删数据**;车1 之前那条 `retention_policy_not_executed` 的响亮 warn

package/dist/boot/leader.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/158 A10:composition root 分段 —— v2 leader endpoint(design/50 + design/68)。
+ * [ref] A10:composition root 分段 —— v2 leader endpoint([ref] + [ref])。
  *
  * 纯搬运:函数体逐字来自 `main.ts`(原 3094-3171 行),缩进不变;新增的只有 import 与包壳。
  *
@@ -22,10 +22,10 @@ export interface LeaderCtx {
     toolResultStore: ToolResultStoreFull | undefined;
     sessionStore: ReturnType<StoreBackend["session"]>;
     checkpointStore: CheckpointStoreFull | undefined;
-    /** design/170 件B/C/D(#252,codex R2-F1):部署治理三座席 —— leader 车道的每一只 Runner 都要带上它,
+    /** [ref] 件B/C/D([ref],codex R2-F1):部署治理三座席 —— leader 车道的每一只 Runner 都要带上它,
      *  否则开了 leader 端点的部署就有一条在部署治理**之外**的执行面(合规否决/锁都够不着)。 */
     governanceSeams: import("./governance-seams.js").GovernanceSeams;
-    /** #193 车4 件1:durable store 后端(leader-run 登记表从这里取)。缺席 = 无 DB 的 env-only worker。 */
+    /** [ref] 车4 件1:durable store 后端(leader-run 登记表从这里取)。缺席 = 无 DB 的 env-only worker。 */
     backend?: StoreBackend | undefined;
 }
 /**
@@ -40,7 +40,7 @@ export interface LeaderCtx {
  */
 export declare function leaderK8sMinioGap(leaderEnabled: boolean, leaderProvider: string | undefined, hasS3: boolean): string[] | null;
 /**
- * #193 车4 件2 的**能力面**门(codex 交叉复审 R1-high①,验真后修)。
+ * [ref] 车4 件2 的**能力面**门(codex 交叉复审 R1-high①,验真后修)。
  *
  * config 层的门②判的是 `DB_BACKEND` 的字面值 —— 那句话回答的是「运维要没要 durable」。它回答不了
  * 「这次启动**真的拿到**了 durable 吗」:`openStoreBackendWithFallback` 在 `SESSION_BACKEND=auto`
@@ -49,7 +49,7 @@ export declare function leaderK8sMinioGap(leaderEnabled: boolean, leaderProvider
  * 跨副本 GET 404、重启失忆 —— 而这条腿的产物是**真 git push**。
  *
  * ⇒ 判据锚**真拿到了没有**。纯谓词、只吃两个原语(与 {@link leaderK8sMinioGap} 同姿势),便于单测。
- * 抛而不是 warn:这正是 #157「安全/执行车道禁静默 fail-open」说的那一类 —— 降级的代价由用户承担,
+ * 抛而不是 warn:这正是 [ref]「安全/执行车道禁静默 fail-open」说的那一类 —— 降级的代价由用户承担,
  * 而承担的方式是重复的真实推送。
  */
 export declare function assertLeaderDurableStore(leaderEnabled: boolean, hasLeaderRunStore: boolean): void;

package/dist/boot/limit-sync.d.ts

@@ -1,5 +1,5 @@
 /**
- * #322 批1 —— 限额座的**换代同步口**(design/322 §2 B簇1)。
+ * [ref] 批1 —— 限额座的**换代同步口**([ref] §2 B簇1)。
  *
  * `applyEffective` 的 commit 段只做一件事:把新值写进 `config`。两只限额座(RateGate / QuotaTracker)持有的
  * 是**比较参数**,不是 config 引用,所以它们要在 commit 之后被推一把 —— 与 `pricing` / `keyResolver` 那两件

package/dist/boot/memory-boundary.d.ts

@@ -1,9 +1,9 @@
 /**
- * #214 记忆边界不变式(板 [3492]② 立案,[3521] 裁1 与 core #151 同窗)—— 启动期把「结构性写不进的记忆
+ * [ref] 记忆边界不变式(板 [ref]② 立案,[ref] 裁1 与 core [ref] 同窗)—— 启动期把「结构性写不进的记忆
  * 部署形」说出来。
  *
- * 根本问题(test 仓 [3479] 实测,[3490]② 定位):core 的记忆工具面是 `memory_search`/`memory_get`/
- * `memory_index`(#493 第五单起第三只,枚举面,仍只读)三只**只读**工具;**写**记忆没有专用工具 —— 模型用 fs 工具往记忆根写文件,harvest 再从那里收编。于是整条链的成立
+ * 根本问题(test 仓 [ref] 实测,[ref]② 定位):core 的记忆工具面是 `memory_search`/`memory_get`/
+ * `memory_index`([ref] 第五单起第三只,枚举面,仍只读)三只**只读**工具;**写**记忆没有专用工具 —— 模型用 fs 工具往记忆根写文件,harvest 再从那里收编。于是整条链的成立
  * 条件是「记忆根落在该次任务的 fs 授权边界之内」。server 把根交给 core(`RunnerDeps.memoryEngineDir`)
  * 之后,没有任何一处保证这一点,也没有任何一处说过「这台部署的记忆写面够不着」。默认根是
  * `~/.ai-agent`(或 `AGENT_DATA_DIR`),默认围栏是任务 cwd —— 两者天然不相交:用户说「记住 X」,模型照
@@ -16,7 +16,7 @@
  * ⚠️ 这不是 fail-open 的托词:真正的 fail-closed 归属面在别处(多租户记忆整体 dark、remote lane 默认 dark)。
  * 本模块判的是「已经决定要开记忆」之后的**可达性**,而可达性的证据一半在部署环境里,不在进程里。
  *
- * ── 指路:声明 `false` 之后引擎那边发生什么(core 5.27.0,[3612] F2;#231 提货批)────────────────────
+ * ── 指路:声明 `false` 之后引擎那边发生什么(core 5.27.0,[ref] F2;[ref] 提货批)────────────────────
  * 本模块两条 warn 的收尾句都在劝 operator 表态(`MEMORY_PERSISTENCE_CAPABLE=true|false`)。表 `false`
  * 之后的语义自 core 5.27.0 起**不止是披露**:该会话成为**受限会话** —— materialize/search/harvest 按
  * 已提交账(ledger + shadow)供给,磁盘上无事务背书的分歧既不收编也不供给,而是留盘 + 响亮点名
@@ -39,7 +39,7 @@
  * 也**不投**这个读面(硬造一个消费点 = 造给自己看的 wire 键)。哪天真要在诊断面露它,先有消费方需求。
  */
 /**
- * #266 A3 源头修(黑板 [4080]/[4082]/[4083],A-044)—— `memoryPersistenceCapable` 的**装配层有效值**:
+ * [ref] A3 源头修(黑板 [ref]/[ref]/[ref],[ref])—— `memoryPersistenceCapable` 的**装配层有效值**:
  * operator 显式 env 恒赢;env 缺席时,`REMOTE_EXEC=host` 腿自动补 `true`;其余一律缺席(现行为)。
  *
  * ## 为什么 host 腿可以自动声明(而且只有 host 腿)

package/dist/boot/memory-consolidation.d.ts

@@ -1,4 +1,4 @@
-import { type ConsolidationDriverRunRow, type ConsolidationRunReceipt, type MemoryBackend, type MemoryConsolidationDriverDeps, type RunMemoryConsolidationOptions } from "@sema-agent/core";
+import { type ConsolidationDriverRunRow, type ConsolidationRunReceipt, type MemoryBackend, type MemoryConsolidationDriverDeps, type RunMemoryConsolidationOptions, type SessionCaptureRecordStore } from "@sema-agent/core";
 /** D3 投影的座标签闭集。`role:<name>` 里的 name 只可能是 core 的 role 链两跳之一。 */
 export type ConsolidationSeatLabel = "explicit" | "role:consolidate" | "role:summarize";
 /** {@link buildConsolidationValveAudit} 的告警名闭集(事件名进日志 ⇒ 运维可按名过滤/告警)。 */
@@ -66,7 +66,7 @@ export declare function createPerScopeSingleFlight<T>(): (scope: string, run: ()
  *     **不带标记**地提交)。这一条本来就会在引擎构造期抛,提前判只为一件事:把**两根**旋钮的名字同时
  *     写进句子 —— core 的那句话只提到 provenance,而运维要知道是哪一根把这台机器拦下的。
  *
- * 阀门关着 ⇒ 整条门不判(缺省姿态,#210「缺席不在律内」)。
+ * 阀门关着 ⇒ 整条门不判(缺省姿态,[ref]「缺席不在律内」)。
  */
 export declare function assertConsolidationDriverWirable(input: {
     enabled: boolean;
@@ -187,5 +187,11 @@ export declare function createMemoryConsolidationFaces(store: {
     /** 停因自由文本的**运维日志**座(缺席 = 没人听,不影响任何行为)。载荷由 {@link buildStopDetailAudit}
      *  铸,调用点在单飞回调**之内** ⇒ 一轮真 run 一行,并入的等待者不各落一行。 */
     onStopDetail?: (audit: ReturnType<typeof buildStopDetailAudit>) => void;
+    /** [ref]②(383 §2.1b):capture opt-out 记录的 SQL 载体(main.ts 单实例,与 Runner 同源)。
+     *  🔴 这只引擎是四只 operator 面里**真读名册**的那只:`consolidationEligibility` 第四臂
+     *  (engine.js `listCaptureOptOutSessions`)拿它筛掉 opt-out 会话的贡献条目 —— SQL 部署上漏喂
+     *  = 驱动器读文件空名册 ⇒ 蒸馏器放大用户明说不要记的内容(S-5 真实失效形;全站同批注入律,
+     *  机器钉 capture-optout-lane ②)。缺席(local 车道)⇒ core 文件三腿,与 Runner 同本。 */
+    captureRecordStore?: SessionCaptureRecordStore;
 }): MemoryConsolidationFaces;
 //# sourceMappingURL=memory-consolidation.d.ts.map

package/dist/boot/memory-consolidation.js

@@ -113,6 +113,7 @@ export function createMemoryConsolidationFaces(store, input) {
         consolidation: {},
         ...(input.provenance !== undefined ? { provenance: input.provenance } : {}),
         ...(input.onIncident !== undefined ? { onIncident: input.onIncident } : {}),
+        ...(input.captureRecordStore !== undefined ? { captureRecordStore: input.captureRecordStore } : {}),
     });
     const flight = createPerScopeSingleFlight();
     return {

package/dist/boot/org-memory.d.ts

@@ -1,5 +1,5 @@
 /**
- * design/170 件A(#148 件3③)——org 记忆准入的装配点:把 org-memory-admission 模块接上 core 5.13.0
+ * [ref] 件A([ref] 件3③)——org 记忆准入的装配点:把 org-memory-admission 模块接上 core 5.13.0
  * 的两个 seam(`RunnerDeps.memoryScopeAdmission` / `RunnerDeps.deploymentMemoryScopes`)。
  *
  * 目录源三态(单选,授权面不做双源合并):
@@ -19,7 +19,7 @@
  * backend 非 file——见下方 `memoryPlaneLive` 注)的 projects 登记簿里挂了 org 键 ——这些键在多租户下
  * 按 request-origin 盖章(N2 部署形态维)——而目录源缺席(含 configCenter dryRun 形)⇒ 启动报错:
  * 该部署的每个 projectId 请求都会在 prepare 期被整拒,「audit 在跑但恒拒」不是可运行状态,响亮拒
- * 启动比静默全拒服务诚实(clay 三裁 [2687]:直接 BREAKING,不留兼容臂)。记忆面 dark 的部署里这些
+ * 启动比静默全拒服务诚实(clay 三裁 [ref]:直接 BREAKING,不留兼容臂)。记忆面 dark 的部署里这些
  * 键根本到不了准入门,不在探测范围(复审 D-1)。
  */
 import type { RunnerDeps } from "@sema-agent/core";
@@ -32,7 +32,7 @@ export interface OrgMemoryAdmissionWiring {
     /**
      * core 准入 seam 的 deployment-origin **回落表**(boot 期一次值快照)。
      *
-     * 🔴 A-057.40:这一席**故意**留快照,不跟 `config.projects` 的热应用走,理由是 core 根本不优先吃它:
+     * 🔴 [ref]:这一席**故意**留快照,不跟 `config.projects` 的热应用走,理由是 core 根本不优先吃它:
      * 本仓每个请求都在 `boot/resolve-spec.ts` 现读 `config.projects[...].defaultScopes`(热加的项目当场
      * 进 spec),并在 `memory-scope.ts` 按 `originPolicy.multiTenant` 给每个 `org:` 键**盖章**;core 的
      * `memory-admission` 先看盖章、只有没盖章时才查这张表 ⇒ 单用户部署下热注册项目的 org 键恒被覆盖为
@@ -41,7 +41,7 @@ export interface OrgMemoryAdmissionWiring {
      */
     deploymentMemoryScopes: RunnerDeps["deploymentMemoryScopes"];
     /**
-     * 同一份判据的**取值口**(A-057.40 修):`createSharedMemoryScopeAuthorizer` 的
+     * 同一份判据的**取值口**([ref] 修):`createSharedMemoryScopeAuthorizer` 的
      * `deploymentScopes` 席用它,每次 `resolve` 现算。
      *
      * 为什么这个消费点必须活取而上面那个可以不:共享记忆读面对 principal-less 请求**直接**把这组 scope
@@ -57,7 +57,7 @@ export interface OrgMemoryAdmissionWiring {
      *  (单用户/无 center 且无 env 表)⇒ 策略面逐字保持收编前的 operator-only 行为。 */
     directory: OrgMemoryDirectory | undefined;
 }
-/** 依赖收窄到真实消费面(warn/inc 各一手)——接口隔离让测试用真形字面量,零铸形([2704] §1)。 */
+/** 依赖收窄到真实消费面(warn/inc 各一手)——接口隔离让测试用真形字面量,零铸形([ref] §1)。 */
 export declare function createOrgMemoryAdmissionWiring(opts: {
     config: ServiceConfig;
     logger: Pick<Logger, "warn">;

package/dist/boot/parked-revive-gate.d.ts

@@ -16,7 +16,7 @@ export interface ApprovalExemptionProbe {
 export interface ParkedReviveGateDeps {
     /** ⚠️ **活引用**:热改字段(autonomy/commandPolicy/守卫集/审批四旋钮)每次赎回现读,见下方「禁 memoize」。 */
     readonly config: ParkedReviveGateConfigView;
-    /** #152:活体 AskUserQuestion 面。赎回腿今天无 ALS ctx ⇒ 判 ask,与原形同判。
+    /** [ref]:活体 AskUserQuestion 面。赎回腿今天无 ALS ctx ⇒ 判 ask,与原形同判。
      *  ⚠️ 它同时是**决议链元数据** `contentMandate` 的唯一判据(见 {@link mandatePostureOf})。 */
     readonly question: LiveQuestionFace | undefined;
     /**
@@ -47,7 +47,7 @@ export interface ParkedReviveGateDeps {
     readonly approverSeat: RunnerDepsOnAsk | undefined;
     readonly approvalExemptionStore: ApprovalExemptionProbe | undefined;
     /**
-     * A-010.1 —— core `RunnerDeps.runtimeCapsResolver` 的**同一只**(main.ts 的 `runtimeCapsResolver`,
+     * [ref] —— core `RunnerDeps.runtimeCapsResolver` 的**同一只**(main.ts 的 `runtimeCapsResolver`,
      * 单一属主同 `boot/runtime-caps.ts`)。重建条目的第三位决议链元数据 `autoModeArmed` 的唯一判据是
      * per-principal 的 `RuntimeCaps.autoMode`,而它只有 center 解得出 —— 见 {@link autoModePostureOf}。
      * 缺席(无 center 的部署 / dry-run)⇒ core 侧 `runtimeCaps` 也恒 undefined ⇒ 该位在 park 时也从不置位,
@@ -82,7 +82,7 @@ export type RebuiltInheritedGate = NonNullable<NonNullable<NonNullable<ToolExecu
  *  能收紧的槽时,本仓的编译面要看得见)。 */
 export type RebuiltParentConstraint = NonNullable<RebuiltInheritedGate["parentConstraints"]>[number];
 /**
- * 赎回腿的父约束链重建(design/181 件二)。
+ * 赎回腿的父约束链重建([ref] 件二)。
  *
  * 语义:**同/跨副本一致地重建「部署 ⊇ 操作员」两层完整链**——审批基线(durable question 门 + F4 高危写
  * 审批门 + 会话豁免探针)作 base 的 `toolPolicy` 座,经**折叠属主** `applyRuntimeGovernance`
@@ -93,7 +93,7 @@ export type RebuiltParentConstraint = NonNullable<RebuiltInheritedGate["parentCo
  * 热改字段(registry 热应用换 config 引用),boot 期铸一次 = 把治理冻在启动那一刻的值上,而 resume 腿的
  * 书面语义是「按**当前** config 重折」(与 resolve-spec 的审批基线读活 config 同一姿势)。
  *
- * 🔴 **单层链是正确的响亮拒**(design/181 §2.5 特征化格):本腿恒建 count=1。嵌套子代(孙代 park,
+ * 🔴 **单层链是正确的响亮拒**([ref] §2.5 特征化格):本腿恒建 count=1。嵌套子代(孙代 park,
  * count≥2)的重建本腿做不到——跨副本连「祖先各层分别是什么」都没有持久化——于是 core 的 pre-CAS
  * `resume.parent_constraint_mismatch` 会响亮拒绝,checkpoint 留 pending。**不许**顺手把它补齐成静默单层:
  * 那等于让孙代在一条比它挂起时更松的祖先链下复活。
@@ -111,7 +111,7 @@ export type RebuiltParentConstraint = NonNullable<RebuiltInheritedGate["parentCo
  * 时点语义(成文进 docs/ASSISTANT-WIRE-CONTRACT.md,免运维当 bug 报):
  *  · toolPolicy 轴 = **当前** config(与 resume 重折一致,收紧与放松都被兑现——放松是一次显式运维动作);
  *  · shellGate 轴 = core 取 max(live, park 时 seed)—— 收紧兑现、放松**不**兑现(fail-safe)。
- *  · `autoModeArmed` 轴(A-010.1)= 按**当前** per-principal entitlement 现解(见 {@link autoModePostureOf});
+ *  · `autoModeArmed` 轴([ref])= 按**当前** per-principal entitlement 现解(见 {@link autoModePostureOf});
  *    与 toolPolicy 轴同族:挂起期间权益被撤/被授 ⇒ 摘要对不上 ⇒ core pre-CAS 响亮拒,不静默换姿势跑。
  *  · `onAsk` 轴 = 部署的活体审批席(`deps.approverSeat`),**在场即供**:park 时那一层冻的就是它。
  *    席位缺席的部署上不供,而**这不等于 auto-deny**(codex R3-中1 验真纠正):此形恒带
@@ -124,7 +124,7 @@ export type RebuiltParentConstraint = NonNullable<RebuiltInheritedGate["parentCo
  *    (test/parked-revive-e2e.test.ts);真 settings→park→赎回的端到端钉未建(候件,随收口件一起)。
  */
 /**
- * 🔴 A-057.44 第二半(codex 交叉复审 medium,验真后采纳)—— 席位多收一位**权威 principal**。
+ * 🔴 [ref] 第二半(codex 交叉复审 medium,验真后采纳)—— 席位多收一位**权威 principal**。
  *
  * 为什么不能只看 `row.scope`:`principal ?? "default"` 这套约定在那一列上是**有损**的(匿名与一个真名叫
  * `default` 的租户同形),而匿名别名匹配(见 `parked-decide.ts` 的 `backgroundScopesForCheckpointScope`)

package/dist/boot/permission-rules-audit.d.ts

@@ -1,8 +1,8 @@
 /**
- * #203 §3(design/203 v2 §6 F4 的**残余采纳**)—— 默认 ON 的**休眠行审计**。
+ * [ref] §3([ref] v2 §6 F4 的**残余采纳**)—— 默认 ON 的**休眠行审计**。
  *
  * 🔴 这条审计存在的唯一理由:`PERMISSION_RULES_ENABLED` 的默认值在本车从 OFF 翻成 ON,而**旋钮翻转
- * 与规则行的寿命是两条独立的时间线**。三张表自 #154 车二起就随中央 `ensureSchema` 建、并且从来没有被
+ * 与规则行的寿命是两条独立的时间线**。三张表自 [ref] 车二起就随中央 `ensureSchema` 建、并且从来没有被
  * 清过,所以下面这两类部署在升级的那一刻会突然带着**既有**规则行开始放行:
  *   · 曾经把旋钮开过一段时间又关掉的部署(行留在库里,只是没人读);
  *   · 从旧库恢复/克隆出来的部署(行跟着数据一起来的)。

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` 里那二十条腿全都是**容忍多副本**的幂等清理:每台副本各扫各的,重复扫一遍只是浪费。