@modusensus/dsh-mneme 0.9.4 → 0.10.0

package/lib/provenance-http.js

@@ -0,0 +1,251 @@
+// 记忆级溯源读出口的 HTTP 口径 —— 唯一实现。
+//
+// 为什么要单独一个模块：这张脸有两个入口——宿主内的面板路由（src/api.js 的
+// /api/dsh-mneme/memory/provenance）与 Bearer 数据面（src/api-standalone.js 的
+// /memory/provenance）。两者底下是同一份 service（provenanceFor + distillWindowsFor
+// + distillRecordsFor），差别只在鉴权与路径。历史上（#509 第一版）它们是整段复制的，
+// 于是「改一边忘一边」在结构上就可能发生——#411 已经为 reclaim / share 各踩过一次，
+// 本模块照那次的结论办。
+//
+// 口径（错误码、两种「空」的区分、窗口形状、上限）现在只写在这里，两个入口都调它。
+// 真要再写第二份，test/provenance-http.test.js 的静态锁会直接转红。
+//
+// 这里只做协议层的事：解析入参、判开关、组装窗口、区分「用户关了」「没接线」与
+// 「没有来源」。一行数据都不改——读取在 src/store.js，透传在 src/service.js。
+//
+// 两个读方向（#421 拆成两条，方向 1 由 #509 交付、方向 2 由 #524 补上）：
+//   memory: ?id=<memoryId>     一条记忆 → 派生它的那些蒸馏窗口
+//   session: ?sessionId=<sid>  一个会话 → 它产出的那些蒸馏窗口
+// 两个主键互斥（都缺 400、都给 400）。共用同一条路径是有意的：多一条路径就多一处
+// 要登记的地方（SECURITY.md 两张表、README 路由表、security-doc 的清单锁），而这两
+// 个方向读的是**同一批数据**，只是入口不同。
+//
+// 状态码阶梯（自前而后，先匹配的先回）：
+//   401 未鉴权      ——两个壳各自的门（api.js 的 register 包装 / standalone 的
+//                     isAuthorized），在本模块之前，不在这里重复。
+//   400 缺参/多参   ——语法畸形，与服务端状态无关，所以排在功能开关之前；与
+//                     reclaim 的 invalid-json 同档（reclaim-http.js:30-33 立的是
+//                     「503 要赢过**字段校验**的 400」，缺参不是字段校验而是请求
+//                     本身不成立，所以不适用那条）。判断在壳里
+//                     （parseProvenanceSelector），走到本模块时选择器一定成型。
+//                     limit 越界属**语义类** 400，按上面那条口径仍排在接线检查之前
+//                     ——它是入参本身的形状问题，不是「服务端现在能不能读」。
+//   409 功能关了    ——distillRecords.enabled !== true。回的是「端点的属性」，
+//                     与 src/api.js:525 的 profileExtractEnabled 同构：用户关了
+//                     某功能 = 409，装配坏了 = 503，两者必须是可区分的答案
+//                     （src/index.js:589-591 的设计原话）。
+//   503 装配没接线  ——service 上缺该方向要用的方法（按选择器分方向判，见
+//                     REQUIRED_METHODS：只缺 session 那侧的方法时，memory 查询
+//                     仍然该能用）。
+//   读（200 / 500）
+// 刻意不用 404：本端点永远不就「这条记忆/这个会话是否存在」作断言（缺参是 400、
+// 未知 id 是 200 + 空 windows），404 在本仓另有稳定含义——未知路由与资源不存在
+// （src/api-standalone.js:506/515、src/api.js:1367/1445）。把「功能关了」塞进
+// 404，调用方会在状态码这个唯一被代理 / 监控 / 重试逻辑读取的通道上，把它读成
+// 「这条记忆不存在」。
+
+/**
+ * 「溯源能力没接线」的错误码。headless / 旧装配下 service 上没有本方向要用的方法，
+ * 那是装配坏了，不是「这条记忆没有来源」——两种空必须分开读数，
+ * 否则调用方看到一个空 windows 会以为拿到了答案。
+ */
+export const PROVENANCE_UNAVAILABLE = "provenance-unavailable";
+
+/**
+ * 「用户把蒸馏原文留存关掉了」的错误码。distillRecords.enabled 既是写侧的总闸
+ * （src/summarize.js:988）也是本读出口的总闸（#509 评审整改）：关着时盘上可能
+ * 还有历史原文（保留期裁剪与写入同在 src/index.js:270 一道门里），但本端点不再
+ * 把它们读出去。与 api.js:525 的 "disabled" 分开：那个面只有一个功能开关，本仓
+ * 数据面上会有多个，特定码才让调用方分得清是哪一个被关。
+ */
+export const DISTILL_RECORDS_DISABLED = "distill-records-disabled";
+
+/**
+ * 一次答复最多带几个窗口。缺省 20。
+ *
+ * 为什么**必须**有上限（#524 的第 2 条前置）：按会话读是这张脸里天然最容易放大
+ * 的方向——一个会话几十个窗口，每个窗口都是整段逐字原文，不限量就是「按会话导出
+ * 全量转录」，与 /export（一次拿全库）同量级、只是换了形状，而它同样受门控。
+ * 20 这个数的取法：本机实测一个蒸馏会话的窗口数在个位数，20 已覆盖正常排查；
+ * 真要更多就带 limit 往上要，**不许**靠缺省值默默给全量。
+ */
+export const PROVENANCE_DEFAULT_WINDOWS = 20;
+
+/**
+ * limit 的硬上界。取值与 api.js 的 MAX_PAGE_LIMIT（1000）/ MAX_SEARCH_TOP_K（200）
+ * 同一考虑：参数直接进 SQL LIMIT，上界是防御。这里比列表类接口更小，因为每个窗口
+ * 带的是一整段原文而不是一行元数据——100 个窗口已经是一份不小的转录。
+ */
+export const PROVENANCE_MAX_WINDOWS = 100;
+
+/**
+ * 读侧唯一的开关判据，**与写侧 src/summarize.js:988 逐字同源**。
+ *
+ * 为什么不放在两个壳里各算一次：那句话已经是本仓第 3、第 4 份拷贝了
+ * （summarize.js:988、index.js:270），而 #411 的结论就是「两张皮整段复制必然
+ * 漂移」——读写两道门一旦漂移，就会出现「以为关了却还能读出去」或「开着却读不到」
+ * 这两种都更难排查的状态。壳只转发 config，判据只在这里出现一次。
+ *
+ * fail-closed：config 缺失（null / undefined）、distillRecords 组缺失、值不是
+ * 严格的 true（"true" 字符串 / 1 / undefined）一律算关。这个端点返回的是蒸馏
+ * 窗口的逐字会话原文，判不出来时必须往「不读」那一侧倒。
+ *
+ * @param {object|null|undefined} config 启动期冻结的装配后 cfg（宿主 index.js:597
+ *   的 createApi 第 8 参 / index.js:621 的 createStandaloneApi config / daemon
+ *   serve.js 的最小 cfg）。
+ * @returns {boolean}
+ */
+export function isDistillRecordsEnabled(config) {
+  return config?.distillRecords?.enabled === true;
+}
+
+/** 溯源读取失败的 warn 文案。两个入口共用，日志里不会出现两种拼法。 */
+export function provenanceWarnMessage(error) {
+  return `[dsh-mneme] memory provenance read failed: ${String(error)}`;
+}
+
+/**
+ * 按选择器分方向列出「要读必须先有哪个方法」。503 只在**该方向**缺方法时回：
+ * 只补了 session 侧的装配不该让 memory 查询一起 503（那是把一个方向的问题
+ * 报成整张脸坏了）。
+ */
+const REQUIRED_METHODS = {
+  memory: ["provenanceFor", "distillRecordsFor"],
+  session: ["distillWindowsFor", "distillRecordsFor"]
+};
+
+function trimmed(raw) {
+  return typeof raw === "string" ? raw.trim() : "";
+}
+
+/**
+ * 解析 ?limit。**只收十进制整数字面量**，缺省落默认值。
+ *
+ * 不用 Number()：它把 "" / " " / 十六进制 / 指数写法都化成数，于是 `?limit=`
+ * 会静默变成 0 个窗口——一个畸形输入拿到最坏解释（reclaim-http.js 的
+ * parseReclaimQuery 为同一理由立过这条规矩）。越界也算畸形：调用方要 1000 个
+ * 窗口，实际给 100 而不说一声，比直接拒更糟。
+ *
+ * @returns {{ok: true, limit: number} | {ok: false, status: 400, error: string}}
+ */
+export function parseProvenanceLimit(raw) {
+  if (raw === null || raw === undefined) return { ok: true, limit: PROVENANCE_DEFAULT_WINDOWS };
+  const text = typeof raw === "string" ? raw.trim() : "";
+  if (!/^\d+$/.test(text)) return { ok: false, status: 400, error: "invalid-limit" };
+  const limit = Number(text);
+  if (!Number.isSafeInteger(limit) || limit < 1 || limit > PROVENANCE_MAX_WINDOWS) {
+    return { ok: false, status: 400, error: "invalid-limit" };
+  }
+  return { ok: true, limit };
+}
+
+/**
+ * 解析两个互斥主键。都缺 → 400 missing-id；都给 → 400 ambiguous-id。
+ *
+ * 「都给时择一」是刻意不做的：择一意味着调用方可以发一个自己也不知道会被读哪个
+ * 主键的请求，而两边的结果形状不同——那种静默选择只会在出事之后才被发现。
+ * 400 是两个都错，比猜一个更好。
+ *
+ * @param {{memoryId?: string|null, sessionId?: string|null, limit?: string|null}} params
+ * @returns {{ok: true, selector: {mode: "memory"|"session", memoryId?: string,
+ *   sessionId?: string, limit: number}} | {ok: false, status: 400, error: string}}
+ */
+export function parseProvenanceSelector({ memoryId, sessionId, limit } = {}) {
+  const mem = trimmed(memoryId);
+  const ses = trimmed(sessionId);
+  // 参数形状排在功能开关之前：请求本身不成立时报「功能关了」是误导。
+  if (mem && ses) return { ok: false, status: 400, error: "ambiguous-id" };
+  if (!mem && !ses) return { ok: false, status: 400, error: "missing-id" };
+  const parsedLimit = parseProvenanceLimit(limit);
+  if (!parsedLimit.ok) return parsedLimit;
+  return {
+    ok: true,
+    selector: mem
+      ? { mode: "memory", memoryId: mem, limit: parsedLimit.limit }
+      : { mode: "session", sessionId: ses, limit: parsedLimit.limit }
+  };
+}
+
+/**
+ * 组装答复：一个窗口一项（区间 + 区间内原文行，按 seq 升序）。
+ *
+ * 顺序敏感（阶梯全貌见文件头）：409 功能关了 → 503 装配没接线 → 读。
+ * 503 要赢过空结果——装配没接线时报「这条记忆没有来源」是误导，与 reclaimReply 的
+ * maintenance-unavailable 同构；而 409 要赢过 503——「用户关了」比「装配坏了」更
+ * 具体，把前者报成后者会让人去查一个没坏的部署。
+ *
+ * `truncated` 是两种模式共有的读数（#524）：撞上 limit 时把「还有更多」说出来。
+ * 少了它，被截断的答复与「本来就只有这么多」逐字节相同，调用方会把半份转录
+ * 当成全部——那正是这张脸最容易骗人的地方。
+ *
+ * @param {{service: object, selector: object, config?: object|null, warn?: Function}} args
+ *   config 缺省即关（fail-closed），见 isDistillRecordsEnabled。
+ * @returns {{status: number, body: object}}
+ */
+export function provenanceReply({ service, selector, config = null, warn = null }) {
+  if (!isDistillRecordsEnabled(config)) {
+    return { status: 409, body: { error: DISTILL_RECORDS_DISABLED } };
+  }
+  const mode = selector?.mode === "session" ? "session" : "memory";
+  if (REQUIRED_METHODS[mode].some((name) => typeof service?.[name] !== "function")) {
+    return { status: 503, body: { error: PROVENANCE_UNAVAILABLE } };
+  }
+  const limit = selector?.limit > 0 ? selector.limit : PROVENANCE_DEFAULT_WINDOWS;
+  try {
+    // session 侧多取一行判截断（store 侧只照 limit 取，不替调用方判断「还有没有」；
+    // memory 侧 provenanceFor 本来就全量返回，按长度判即可）。
+    const rows = mode === "session"
+      ? service.distillWindowsFor(selector.sessionId, limit + 1)
+      : service.provenanceFor(selector.memoryId);
+    const truncated = rows.length > limit;
+    // #512：run 是归因主体，窗口只是它的一批输入。能读到 run 就带上 run_type /
+    // trigger_source / status，读不到（旧库历史链接、或 store 没这一步）就整组
+    // 缺省——**不拿区间或时间戳去猜**：「看起来能追、实际是编的」比没有更坏。
+    const canReadRuns = typeof service?.getDistillRun === "function";
+    const windows = rows.slice(0, limit).map((link) => {
+      const base = {
+        session_id: link.session_id,
+        seq_start: link.seq_start,
+        seq_end: link.seq_end,
+        created_at: link.created_at,
+        // 到期裁剪后区间可能变空：链接刻意保留并指向空区间（clearDistillRecords 的
+        // 语义），面板据此显示「原文已过期」而非「没有来源」。
+        records: service.distillRecordsFor(link.session_id, link.seq_start, link.seq_end)
+      };
+      if (mode === "session") {
+        // link_count 只有方向 2（session）会带：一个窗口派生出几条记忆。方向 1 的每
+        // 一行本来就是「一条记忆 → 一个窗口」，这个计数恒为 1，带出去只会是噪音（用
+        // ?? 兜住，免得方向 1 的答复凭空多一个 null 键）。
+        return { ...base, link_count: link.link_count ?? 1 };
+      }
+      // 方向 2 的一行是一个窗口、可能派生多条记忆，没有单一归因主体，所以运行归因
+      // 只挂在方向 1 上；要逐条查某条记忆出生自哪一轮，仍走方向 1。
+      const run = canReadRuns && link.distill_run_id ? service.getDistillRun(link.distill_run_id) : undefined;
+      return {
+        ...base,
+        // #512：distill_run_id 为 null 就是历史行为——改造之前写下的链接没有第二轮
+        // 真相可查，面板据此显示「这一条没有运行归因」而不是给一个像样的空壳。
+        distill_run_id: link.distill_run_id ?? null,
+        run_type: run?.run_type ?? null,
+        trigger_source: run?.trigger_source ?? null,
+        run_status: run?.status ?? null
+      };
+    });
+    // 行级铸造归因（#512）：这条记忆出生自哪一轮。与窗口级是两层，各自独立缺省。
+    const mints = mode === "memory" && typeof service?.mintsFor === "function"
+      ? service.mintsFor(selector.memoryId).map((mint) => ({
+        run_id: mint.run_id,
+        run_type: mint.run_type,
+        trigger_source: mint.trigger_source,
+        created_at: mint.created_at
+      }))
+      : [];
+    const body = mode === "session"
+      ? { sessionId: selector.sessionId, windows, truncated }
+      : { memoryId: selector.memoryId, windows, truncated, mints };
+    return { status: 200, body };
+  } catch (error) {
+    warn?.(provenanceWarnMessage(error));
+    return { status: 500, body: { error: "internal" } };
+  }
+}

package/lib/serve.js

@@ -61,6 +61,19 @@ export async function createServeRuntime({
   // documentMemoryEnabled 关掉 document 子系统(daemon 不建 documentIndex,service
   // 内部 if-guard 安全,index.js:261 的 documentIndex 仅宿主装配)。
   const cfg = { language: "zh", documentMemoryEnabled: false };
+  // #509 评审整改补的一格:GET /memory/provenance 的读门读 cfg.distillRecords.enabled
+  // (判据在 src/provenance-http.js,与写侧 src/summarize.js:988 同源)。daemon 与宿主
+  // 共用同一个 memory.db、同一份 feature_flags kv,所以这里把用户显式开关展开进 cfg
+  // ——index.js:217-233 同款展开,只取蒸馏这一组(daemon 其余键仍刻意不吃宿主 config
+  // schema)。不展开的后果:daemon 对这一面恒定回「功能关了」,哪怕用户在面板里开着、
+  // 库里明明有原文——对这个端点那是一句谎话,而「两种空必须分开读数」正是本仓纪律。
+  // 残留不对称(写进 docs/DAEMON.md 与 PR):只靠 bundle 配置打开、从没在面板点过的
+  // 用户,宿主认、daemon 不认——daemon 结构上看不到宿主的 bundle config,这是它看不见
+  // 的那一半,不是本处能补的。
+  const persistedFlags = settings.getFeatureFlags?.() ?? {};
+  if (typeof persistedFlags["distillRecords.enabled"] === "boolean") {
+    cfg.distillRecords = { ...(cfg.distillRecords ?? {}), enabled: persistedFlags["distillRecords.enabled"] };
+  }
   const mirror = createMirror(dir, langOf(cfg));
   const service = createService({ store, mirror, config: cfg, logger });
 

package/lib/service.js

@@ -7,9 +7,13 @@ import { STR, langOf } from "./lang.js";
 import { computeHeat } from "./heat.js";
 import { recallStats } from "./recall-stats.js";
 import { evaluateMemoryQuality } from "./quality-filter.js";
+// 外来行（source='imported'，导入路径落的来源）的身份判定只许有一个定义处——本文件的
+// 两处汇流口与巩固/降级那些读侧行池都调这同一个谓词，避免各处自己写字符串比较然后各自漂移。
+import { isImportedRow } from "./memory-source.js";
 import { applyDecisions } from "./dream/decisions.js";
 import { createDocumentRegistrar } from "./document.js";
 import { createOrganizer } from "./organize.js";
+import { createShareImport } from "./share-import.js";
 import { createBM25Index } from "./search/bm25.js";
 import { adaptiveThreshold } from "./search/adaptive.js";
 import { anchorSeeds, normalizePath, cascadeDepths, HOP_QUOTA } from "./graph/anchoring.js";
@@ -1368,7 +1372,31 @@ export function createService({ store, mirror, config, onWrite, logger, document
     // dream 总览按 source 身份去重，而非本地化标题：memory.language 切换后
     // 标题变化，若仍按 (type, title) 匹配会出现两个活跃的 summary 同时注入。
     // 其余类型维持 (type, title) 匹配不变。
-    const candidates = store.list({ type: memory.type, limit: 100 });
+    //
+    // Issue #505：候选集此前是 store.list({ type, limit: 100 }) —— 那是「该类型
+    // 最重要的 100 行」（order 默认 importance），与「找出同标题的那一行」无关。
+    // 某类型里 importance 高于待写行的行数一旦超过 100，同标题行与待写行双双落在
+    // 窗口外，下面的 find 恒不命中，于是静默走创建分支：不报错、不告警，合并语义
+    // 随库增长而失效（实测 1047 行类型、importance=5 有 180 行时稳定复现）。
+    // 改为按同标题定向取（store.activeByTypeAndTitle，无窗口）。
+    //
+    // spec §5 决策 2：本机巩固不许改写别人的原文。这里不是防呆——蒸馏路径的每一次
+    // 同题命中都会 appendContent 覆盖外来行的正文与 updated_at，别人的记忆从此变成
+    // 我们两家的混杂物。把外来行剔出候选集后只会落回既有的「新建一行」分支。
+    // 谓词挂在**两个**候选集上：sourceScopedCandidates 在 dream/narrative 那两条分支
+    // 里就是候选集本身，只挂 candidates 等于给外来行留一条后门。这一处过滤留在 JS 侧
+    // 而不是下推 SQL（同 #515 的反面）：那里下推是因为外来行会吃掉 LIMIT 窗口名额，
+    // 这里 limit: null 本就无界，没有窗口可饿，而下推会多出第二份外来行判据。
+    const candidates = store.activeByTypeAndTitle(memory.type, memory.title).filter((m) => !isImportedRow(m));
+    // dream/narrative 两条分支按 source（及 tags[0]）匹配，而不是按标题：它们的
+    // 去重键本来就不含标题（语言切换后标题会变）。定向取同标题会把这两条路径
+    // 打回「永远不命中」——所以这两类仍走「该类型活跃行」的候选集，只是窗口换成
+    // 了无界且不带 importance 排序。类型内行数由 summary 的生产方（autoDream /
+    // generateNarratives）决定，量级远小于普通记忆，且这两条分支本来就要求扫全
+    // 类型才能找到同 source 的那一行——原来的 100 行窗口对它们同样是错的。
+    const sourceScopedCandidates = (memory.type === "summary" && (memory.source === "dream" || memory.source === "narrative"))
+      ? store.list({ type: memory.type, limit: null }).filter((m) => !isImportedRow(m))
+      : candidates;
     // v0.8.0 A1（issue #17）：去重键由 (type, title) 扩展为
     // (type, title, agent_scope, workspace_scope, sensitivity)——不同作用域的同
     // 标题记忆绝不互相物理合并（旧逻辑跨 agent/workspace 并行，事后无法拆分）。
@@ -1386,17 +1414,20 @@ export function createService({ store, mirror, config, onWrite, logger, document
     // 下面这段并入逻辑（appendContent + content_history + 质量处置），不另写第二份
     // 实现。目标已被并发删除时回落到常规匹配。显式目标同样过 scope 门：跨作用域
     // 的语义相似不并入（防泄漏），回落为独立新行。
-    const explicitTarget = memory._mergeInto ? store.getById(memory._mergeInto) : undefined;
+    // 显式目标还过外来门（spec §5 决策 2）：调用方指到别人导入的原文时，这个目标
+    // 按「未命中」处理，同样落回新建一行——两条路都只有 merged/created 两种结局。
+    const explicitCandidate = memory._mergeInto ? store.getById(memory._mergeInto) : undefined;
+    const explicitTarget = explicitCandidate && !isImportedRow(explicitCandidate) ? explicitCandidate : undefined;
     const existing = explicitTarget
       ? (scopeMatches(explicitTarget) ? explicitTarget : undefined)
       : (memory.type === "summary" && memory.source === "dream")
-        ? (candidates.find((m) => m.source === "dream" && scopeMatches(m))
+        ? (sourceScopedCandidates.find((m) => m.source === "dream" && scopeMatches(m))
           ?? candidates.find((m) => scopeMatches(m) && m.title.trim() === String(memory.title).trim()))
         : (memory.type === "summary" && memory.source === "narrative")
           // 叙述条（#164）按主题键去重而非本地化标题：标题随语言变
           // （叙述：X / Narrative: X），title 匹配在语言切换后会残留同 tag 双行。
           // tag 存于 tags[0]（generateNarratives 落库），跨语言稳定 → 原地刷新。
-          ? (candidates.find((m) => m.source === "narrative" && m.tags?.[0] === memory.tags?.[0] && scopeMatches(m))
+          ? (sourceScopedCandidates.find((m) => m.source === "narrative" && m.tags?.[0] === memory.tags?.[0] && scopeMatches(m))
             ?? candidates.find((m) => scopeMatches(m) && m.title.trim() === String(memory.title).trim()))
         : candidates.find((m) => scopeMatches(m) && m.title.trim() === String(memory.title).trim());
     if (existing) {
@@ -2564,6 +2595,12 @@ export function createService({ store, mirror, config, onWrite, logger, document
     }
   });
 
+  // 车道 C 收侧的入库与整包退出（spec §5）：内聚块在 src/share-import.js，这里只做依赖
+  // 注入 + barrel 出口。注入的是本文件的 transaction 而不是 store.runAtomically——嵌入
+  // 队列由 transaction 的最外层 COMMIT 排空，换那个助手等于静默不嵌入（#372 修过两次）；
+  // 退出那侧用它则是为了 finally 里的 syncMirror + notifyWrite（删完得让其余读侧知道）。
+  const shareImport = createShareImport({ store, transaction, scheduleEmbed });
+
   return {
     saveWithDedupe,
     registerDocument,
@@ -2577,6 +2614,15 @@ export function createService({ store, mirror, config, onWrite, logger, document
     getMirrorState: () => store.getMirrorState(),
     injectCandidates,
     mergeHumanEdits,
+    // 车道 C 收侧：两张皮（面板路由 / standalone 数据面）各自的壳只认这一份实现——
+    // createApi 手里没有 store，「api 层不直接摸 store」这条纪律（见下面 embeddedCount
+    // 那组 passthrough 的注释）要求导入从 service 进，否则两皮各摸一遍 store、幂等
+    // 口径随之变成两份。
+    importSharePack: shareImport.importSharePack,
+    // 整包退出（C4）与导入同住 src/share-import.js：收侧的「进与出」共用同一份 store
+    // 注入与同一个事务口径，键名照计划里的契约留在 service 的返回表上，两张皮（C5/C6）
+    // 只认 service 这一个入口——api 层不直接摸 store 那条纪律对退出同样成立。
+    deleteSharePack: shareImport.deleteSharePack,
     toApiList,
     isVisibleInScope,
     // issue #471 政策轴：按下/松开与读取照 store 那三条件透传（纯 bookkeeping，
@@ -2592,6 +2638,11 @@ export function createService({ store, mirror, config, onWrite, logger, document
     transaction,
     getDistillCursor: (sessionId) => store.getDistillCursor(sessionId),
     setDistillCursor: (sessionId, lastSeq) => store.setDistillCursor(sessionId, lastSeq),
+    // #493 补充 §②：解析失败计数是**跨进程**的事实（护栏默认关，但开着时重启一次
+    // 就清零等于让护栏可被重启绕过）。整条是 bookkeeping，不挂 write hook。
+    getDistillParseFailureStreak: (sessionId, opts) => store.getDistillParseFailureStreak(sessionId, opts),
+    bumpDistillParseFailureStreak: (sessionId, opts) => store.bumpDistillParseFailureStreak(sessionId, opts),
+    clearDistillParseFailureStreak: (sessionId) => store.clearDistillParseFailureStreak(sessionId),
     // #399 蒸馏原始记录与溯源：与上面两条游标一样是纯 passthrough——它们不是
     // 记忆写入，不该触发 syncMirror / notifyWrite / 实体抽取（那些钩子挂在
     // saveWithDedupe 上）。distill_records 的落盘由 summarize.js 在蒸馏窗口内
@@ -2599,6 +2650,21 @@ export function createService({ store, mirror, config, onWrite, logger, document
     saveDistillRecords: (records) => store.saveDistillRecords(records),
     saveMemoryProvenance: (link) => store.saveMemoryProvenance(link),
     provenanceFor: (memoryId) => store.provenanceFor(memoryId),
+    // #421 读出口：按 (session, seq 区间) 取蒸馏原文。与 provenanceFor 成对——
+    // 一个给区间、一个给区间里的原文，合起来才是「这条记忆从哪几句蒸出来的」。
+    distillRecordsFor: (sessionId, seqStart, seqEnd) => store.distillRecordsFor(sessionId, seqStart, seqEnd),
+    // #524 方向 2：按会话列出它的蒸馏窗口。与 provenanceFor 同一张表、另一条索引
+    // （idx_memory_provenance_session），所以也是纯 passthrough——读的是 #399 早就
+    // 落好的事实，不产生任何写入。
+    distillWindowsFor: (sessionId, limit) => store.distillWindowsFor(sessionId, limit),
+    // #512 蒸馏运行与铸造归因：同样是 bookkeeping passthrough（与 saveDreamRun
+    // 那一组同语义）——run 是审计主体，notifyWrite 会绕回它自己的调度器。
+    saveDistillRun: (run) => store.saveDistillRun(run),
+    attachDistillRunAudit: (id, auditId) => store.attachDistillRunAudit(id, auditId),
+    getDistillRun: (id) => store.getDistillRun(id),
+    listDistillRuns: (opts) => store.listDistillRuns(opts),
+    saveMemoryMint: (mint) => store.saveMemoryMint(mint),
+    mintsFor: (memoryId) => store.mintsFor(memoryId),
     enqueue,
     setDreamHook(fn) { dreamHook = fn; },
     setSleepHook(fn) { sleepHook = fn; },
@@ -2670,6 +2736,20 @@ export function createService({ store, mirror, config, onWrite, logger, document
     // passthrough 形状与 embeddedCount 同款，api 层不直接摸 store。
     embeddingModelBreakdown: () => store.embeddingModelBreakdown(),
     embeddingDimensionBreakdown: () => store.embeddingDimensionBreakdown(),
+    // #383：维度探针，供 /context 判「库里有没有一条活跃向量与查询同维」。注意
+    // 它**不再是**「读一行的维度」（那个判据在混合维度库里两个方向都错，见 store.js
+    // vectorDimensionState 的注释）：换成存在性判据后成本是「一次全 id 扫描 + 按匹配
+    // 短路的解析」，同维度健康库只解析 1 个向量，只有要报 degraded 时才走完全表。
+    // 与上面那个全表扫的 breakdown 仍是两件事：一个是状态页的完整分布，一个是每请求
+    // 用得起的判据。透传而非让 api 层摸 store，与同组其他条目一致；api 侧负责把探针
+    // 异常隔离成 unknown，不在这里吞。
+    vectorDimensionState: (dimension) => store.vectorDimensionState(dimension),
+    // 整包透传：store.list 的每个口径（excludeTypes / excludeImported / includeArchived…）
+    // 都从这里过去，service 侧不再枚举一遍——枚举就是第二份口径表，加一个键就要改两处，
+    // 漏改的那处静默失效。政策轴一律走这里的查询参数，不许退回调用方的 .filter：
+    // LIMIT 先生效的话，被丢掉的行照样吃掉窗口名额。前例是同文件 syncMirror 的那条注释
+    // （src/service.js:2247，document 轴改由 excludeTypes 在 LIMIT 之前排除），
+    // 同一取舍的另两次是 #230 与 #471。
     list: (o) => store.list(o),
     all: () => store.all(),
     count: (type, opts) => store.count(type, opts),
@@ -2759,6 +2839,17 @@ export function createService({ store, mirror, config, onWrite, logger, document
     listConflictQueue,
     resolveConflictPending,
     countConflictPending: () => store.countConflictPending(),
+    // Issue #533：differentiate 的裁决账本。同样只做记账、绝不改正文——正文
+    // 一旦互相追加同一段注记，两条向量会被同向拉近（复现见 store 侧建表注释）。
+    saveDifferentiatedPair: (r) => store.saveDifferentiatedPair(r),
+    findDifferentiatedPair: (a, b) => store.findDifferentiatedPair(a, b),
+    listDifferentiatedPairs: (opts) => store.listDifferentiatedPairs(opts),
+    // #529：机器侧冲突裁决台账。同样只有 bookkeeping 语义——一行台账既不是记忆
+    // 内容也不是人工裁决，写它不该触发 syncMirror / notifyWrite / 实体抽取，否则
+    // 记账本身会反过来把睡眠调度器叫醒（与上面 saveDreamRun 同一个理由）。
+    saveConflictReviewed: (r) => store.saveConflictReviewed(r),
+    loadConflictReviewed: () => store.loadConflictReviewed(),
+    listConflictReviewed: (opts) => store.listConflictReviewed(opts),
     // Recall evaluation trail (方案 B): audit-bookkeeping semantics like the
     // dream/recall passthroughs above — a recall_evals write is a snapshot, not
     // a memory mutation, so it never triggers write hooks.
@@ -2768,6 +2859,8 @@ export function createService({ store, mirror, config, onWrite, logger, document
     // LLM audit trail (Bug8): bookkeeping semantics like the recall/dream
     // passthroughs — a saveLlmAudit write never triggers write hooks.
     saveLlmAudit: (entry) => store.saveLlmAudit(entry),
+    // #534：校验层的判决要补回到调用层已经写死的审计行上（两套账分账，见 store 侧注释）。
+    annotateLlmAudit: (id, patch) => store.annotateLlmAudit(id, patch),
     listLlmAudits: (opts) => store.listLlmAudits(opts),
     countLlmAudits: (opts) => store.countLlmAudits(opts),
     getLlmAuditStats: (opts) => store.getLlmAuditStats(opts),

package/lib/session-gate.js

@@ -0,0 +1,91 @@
+// #539 逐会话无痕闸门：总开关关闭时保留既有行为；每个消费点读取同一份配置，
+// 因此配置对象更新后，下一次操作即按新值判定。
+export function createSessionGate(config) {
+  // 已观察到的子会话 id。作用只有一个：日志扫描只拿得到一个 id 与一段**可能解析
+  // 不出 header** 的帧，那时没有活会话对象可问。上限与会话日志扫描的批次无关，
+  // 纯粹是防「长驻宿主跑上几百个子代理后这张表只涨不落」——本机 641 个真实会
+  // 话里 455 个是子代理，不设界等于把每个子代理 id 永久留在内存里。淘汰最旧的
+  // 是安全的：淘汰只影响「header 解析不出时的那次日志过滤」，活路径一律直接用
+  // 会话对象判定，不查这张表。
+  const MAX_TRACKED_SESSIONS = 512;
+  const childSessions = new Set();
+
+  const read = (target, key) => {
+    try {
+      return target?.[key];
+    } catch {
+      return undefined;
+    }
+  };
+
+  const headerOf = (session) => {
+    const header = read(session, "header");
+    if (header && typeof header === "object") return header;
+    try {
+      const requestHeader = read(session, "requestHeader");
+      const request = typeof requestHeader === "function" ? requestHeader.call(session) : null;
+      const fallback = read(request, "config");
+      return fallback && typeof fallback === "object" ? fallback : null;
+    } catch {
+      return null;
+    }
+  };
+
+  /**
+   * 子会话判据：**只看宿主自己的委派标记**。
+   *
+   * 刻意不把 `parentSession` 当判据。它是「有父会话」而不是「是子代理」：
+   * `dsh-session` 的 `sessions.fork()` 造出来的**主会话分支**同样写它
+   * （`@deepseek-ai/dsh-session/lib/index.js` 的 fork 只写 cwd / parentSession /
+   * isSeeded，不写 origin、不写 delegationDepth），而宿主对
+   * `origin` 的取值校验只有一个合法值 "subagent"。本机 641 个真实会话头实测：
+   * origin/delegationDepth 命中 455 个子代理、零漏检；parentSession 对子代理
+   * 识别零贡献，只额外判出 3 个 fork 出来的主会话（那些会话里各有 74–136 条
+   * 用户消息、694 次工具调用，不是空壳）。把它们一起关掉 = 普通主会话突然失忆。
+   *
+   * `parentSessionId` 是 #539 描述的兼容别名，641 个真实头里一次都没出现过；
+   * 这里同样不读——留着它当判据只会把同一个误判换个键名再犯一次。
+   */
+  const isChild = (session) => {
+    const header = headerOf(session);
+    const origin = read(header, "origin") ?? read(session, "origin");
+    if (origin === "subagent") return true;
+    const depth = read(header, "delegationDepth") ?? read(session, "delegationDepth");
+    return Number(depth) > 0;
+  };
+
+  const idOf = (sessionOrId) => {
+    if (typeof sessionOrId === "string") return sessionOrId || null;
+    const id = read(sessionOrId, "id");
+    return typeof id === "string" && id.length > 0 ? id : null;
+  };
+
+  const observe = (session) => {
+    const id = idOf(session);
+    if (!id || !isChild(session)) return;
+    if (!childSessions.has(id) && childSessions.size >= MAX_TRACKED_SESSIONS) {
+      // 与 src/continuity.js:193 的边缘表同一手法：Map/Set 保持插入序，淘汰最旧。
+      childSessions.delete(childSessions.values().next().value);
+    }
+    childSessions.add(id);
+  };
+
+  const isEnabled = () => read(config, "sessionGateEnabled") === true;
+
+  const isOff = (sessionOrId) => {
+    if (!isEnabled()) return false;
+    // id 只服务两件事：手动名单的精确匹配、已观察子会话的记账查询。它**不是**
+    // 判定子会话的前提——#539 明写「子会话在首个 session/event 之前就可能组装
+    // 上下文」，那时过去只有会话对象、未必有可用 id。以前在这里 `if (!id) return
+    // false` 早退，等于把这类会话整个放过去，而下面的 isChild 本来就是为这个
+    // 场景准备的。
+    const id = idOf(sessionOrId);
+    const sessions = read(config, "sessionGateSessions");
+    if (id && Array.isArray(sessions) && sessions.includes(id)) return true;
+    if (read(config, "sessionGateSubagents") === false) return false;
+    if (id && childSessions.has(id)) return true;
+    return typeof sessionOrId === "object" && sessionOrId !== null && isChild(sessionOrId);
+  };
+
+  return { observe, isEnabled, isOff };
+}

package/lib/settings.js

@@ -143,6 +143,9 @@ const FEATURE_FLAG_BOOLEANS = [
   // 有效间隔 = 基数 × 2^连续失败数（成功清零），封顶 30 分钟；面板可启停。
   "autoDreamFailureBackoff",
   "sleepModeEnabled",
+  // Issue #529：sleep 连续失败退避（默认关）。基数是 sleepMinIntervalHours，
+  // 有效间隔 = 基数 × 2^连续失败数（成功清零），封顶 max(基数, 24h)；面板可启停。
+  "sleepFailureBackoff",
   "heatEnabled",
   // issue #218 / E5：注入侧 heat 独立开关（默认关，老用户 injectHeatEnabled=true 回滚）。
   "injectHeatEnabled",
@@ -239,7 +242,11 @@ const FEATURE_FLAG_BOOLEANS = [
   "personaStrictAddressing",
   // Issue #497：画像提取草稿（POST /profile/extract）。默认关——每次调用一次 LLM 且
   // 读上百行记忆；产物只回草稿，绝不写 user_settings。进 LIGHT_MODE_OFF（预设关）。
-  "profileExtractEnabled"
+  "profileExtractEnabled",
+  // #539：逐会话无痕默认关闭；子代理开关受总开关约束。手动 session id 名单留在配置，
+  // 不进入只支持标量的 feature_flags 白名单。
+  "sessionGateEnabled",
+  "sessionGateSubagents"
 ];
 // 整数开关的闭区间，与 config.js 里 z.natural().min().max() 对齐。
 const FEATURE_FLAG_INT_RANGES = {
@@ -279,6 +286,11 @@ const FEATURE_FLAG_INT_RANGES = {
   pinnedInjectBudget: [0, 5],
   // Issue #257：sleep 冲突/模式阶段的 LLM 输出预算（原硬编码 2048，实测不足）。
   sleepMaxTokens: [256, 131072],
+  // Issue #529：sleep 冲突阶段的输入侧预算（此前完全没有——全部候选对一次进一个
+  // prompt，实测 163,054 token 撞服务端 163,840 上限）。两个键都是 0 = 不设上限，
+  // 与 config.js 的 z.natural().min(0).max() 成对。
+  sleepConflictMaxPairs: [0, 500],
+  sleepConflictMaxPairsPerRun: [0, 5000],
   // Issue #258：总览（dream_summarize）输入条数硬上限（0 = 不设上限）。
   dreamSummaryMaxInputs: [0, 100000],
   // Issue #24 块1：锚定种子上限与级联深度（闭区间与 config.js 的 z.natural() 对齐）。