@modusensus/dsh-mneme 0.9.4 → 0.10.0

package/lib/store.js

@@ -11,6 +11,11 @@ import {
   normalizeScopeStateState,
   normalizeScopeStateValue
 } from "./scope-state.js";
+// 外来行的**唯一**定义住在 memory-source.js，这里只取那个常量：store 的查询口径与
+// service/sleep 的 isImportedRow 必须是同一个字符串，自己再拼一份字面量就是第二个口径，
+// 而「本库不巩固别人导入的原文」这条契约正靠它只有一个人说得出口。
+// 依赖方向 store → memory-source 单向（该模块不 import 任何东西），不构成环。
+import { IMPORTED_SOURCE } from "./memory-source.js";
 
 const SCHEMA = `
 CREATE TABLE IF NOT EXISTS memories (
@@ -71,7 +76,13 @@ CREATE TABLE IF NOT EXISTS dream_runs (
   -- 写入就绕过阈值开跑整轮（#291 只持久化了 lastRunAt 那半边）。成功轮才落这两列，
   -- 失败/降级不推进基线的既有语义不变；两列同时有值或同时为 NULL。
   store_count    INTEGER,
-  store_chars    INTEGER
+  store_chars    INTEGER,
+  -- #534：失败轮（拿得到模型输出，但解析或校验没过）的原始输出截断副本。
+  -- 此前失败轮只留一行 logger.warn，进程一退现场就没了——#534 实测 19 轮里
+  -- 17 轮整轮无效，事后一条模型原文都查不到。做成独立列而不是塞进 decisions：
+  -- 那一列的语义是「可重放的决策数组」，失败轮已被 _validationFailed 哨兵占着，
+  -- 塞原文进去会污染按决策数组消费的下游（重放、面板）。
+  raw_output     TEXT
 );
 CREATE INDEX IF NOT EXISTS idx_dream_runs_created ON dream_runs(created_at);
 
@@ -175,6 +186,51 @@ CREATE TABLE IF NOT EXISTS conflict_pending (
 );
 CREATE INDEX IF NOT EXISTS idx_conflict_pending_unresolved ON conflict_pending(resolved_at);
 
+-- differentiated_pairs: 「这一对已经判过 differentiate」的裁决账本（issue #533）。
+-- 起因：#126 的 differentiate 把同一段差异注记同时追加到两侧正文，指望「注记进
+-- embedding 后下一轮就不再判重复」；离线复现证伪了这个假设——两侧共享同一段
+-- 后缀时向量同向靠拢（0.876→0.960/5 轮，注记截到 0 字也一样），而字面 includes
+-- 幂等在措辞漂移下失效，于是同一对每轮都被追加一段，单条堆到 19 段。
+-- 这里记的是「(a,b) 已裁决」这件事本身，正文一个字节都不动；hash_a/hash_b 是
+-- 裁决当时两侧正文的 content_hash，任一侧后来被改写就让该对重新进入候选（宁可
+-- 再判一次，不静音真的演化）。与 conflict_pending 同款的 bookkeeping 表：只做
+-- 裁决记账，不触发 write hooks。
+CREATE TABLE IF NOT EXISTS differentiated_pairs (
+  id           TEXT PRIMARY KEY,
+  memory_a     TEXT NOT NULL,
+  memory_b     TEXT NOT NULL,
+  hash_a       TEXT,
+  hash_b       TEXT,
+  -- 模型给出的差异点（JSON 数组）。不再写进正文，留在这里只为了让「当初为什么
+  -- 判它们互补」事后查得到——裁决本身必须可审计，否则和静音丢弃没有区别。
+  distinctions TEXT,
+  run_id       TEXT,
+  created_at   TEXT NOT NULL
+);
+CREATE UNIQUE INDEX IF NOT EXISTS idx_differentiated_pairs_pair ON differentiated_pairs(memory_a, memory_b);
+
+-- conflict_reviewed: 机器侧裁决台账（issue #529）。冲突相位真正送给 LLM 的每一对
+-- 都在这里留一行，连同最后拿到的结果——判 keep 的对因此不会在下一轮被原样再送。
+--
+-- 为什么不复用 conflict_pending：那张表是**人工**待审队列，countConflictPending()
+-- 与 listConflictPending() 的口径直接喂面板的待确认徽标。机器记账混进去，用户打开
+-- 面板看到的就是几百条自己从没要求审的条目，人工裁决会被淹掉。两者的生命周期也相反：
+-- pending 是「等人来」，reviewed 是「人不用来了」。
+--
+-- 主键就是归一化后的对（sort 过，与 saveConflictPending 同一口径），同一对只留最新
+-- 一次判决，INSERT OR REPLACE 天然幂等。「是否还需重判」不靠本表自身判定，而是比
+-- 两侧 updated_at 与 judged_at（宽松代理，与 conflict_pending 复核项 4 同一条约定：
+-- 任何字段更新都算「值得再看一眼」，宁可多看一眼，不静音真冲突）。
+CREATE TABLE IF NOT EXISTS conflict_reviewed (
+  memory_a  TEXT NOT NULL,
+  memory_b  TEXT NOT NULL,
+  judged_at TEXT NOT NULL,
+  outcome   TEXT,
+  run_id    TEXT,
+  PRIMARY KEY (memory_a, memory_b)
+);
+CREATE INDEX IF NOT EXISTS idx_conflict_reviewed_judged ON conflict_reviewed(judged_at);
+
 -- scope_changes: v0.8.1 底座（issue #170）scope 归属的人工修正审计。显式声明
 -- （memory_save/memory_update 的 scope 参数、面板编辑）每次改变某条记忆的
 -- agent/workspace 归属都落一行：改动前后值 + 来源 + actor（tool=模型侧 /
@@ -275,10 +331,12 @@ CREATE INDEX IF NOT EXISTS idx_distill_records_distilled_at ON distill_records(d
 -- 不该因删掉其中一条派生记忆而消失。
 -- memory_id 是 TEXT 而非 issue 草稿里的 INTEGER：memories.id 是 TEXT 主键，
 -- 类型必须与父表一致（否则 join 恒空）。
--- ON DELETE CASCADE 在本库**不生效**——store.js 从不打开 PRAGMA foreign_keys，
--- 全库唯一那条 REFERENCES 也一直是惰性的。与其为一个新表翻转全局 pragma
--- （会同时改变既有 recall_events 的写入行为），不如在 remove() 里显式清链接：
--- 语义相同、影响面只在本表。见 remove() 的注释。
+-- ON DELETE CASCADE 在本库是**生效的**：createStore 走 new DatabaseSync(path) 不带选项，
+-- 而 node:sqlite 的 enableForeignKeyConstraints 默认为真（实测：新库上 PRAGMA foreign_keys
+-- 返回 1，删父行确实级联清掉本表）。本库两条 FK 都因此一直是活的——这一条，以及
+-- recall_evals(recall_run_id) → recall_runs(id)。级联在兜底，remove() 仍然显式清链接，
+-- 理由不是「FK 没开」，而是这份清理不该挂在一条没人钉过的驱动默认上：连接哪天被以
+-- enableForeignKeyConstraints:false 打开，悬空链接只有那条 DELETE 挡得住。见 remove() 的注释。
 CREATE TABLE IF NOT EXISTS memory_provenance (
   memory_id  TEXT    NOT NULL REFERENCES memories(id) ON DELETE CASCADE,
   session_id TEXT    NOT NULL,
@@ -293,6 +351,77 @@ CREATE INDEX IF NOT EXISTS idx_memory_provenance_session ON memory_provenance(se
 CREATE UNIQUE INDEX IF NOT EXISTS idx_memory_provenance_link
   ON memory_provenance(memory_id, session_id, seq_start, seq_end);
 
+-- #512 蒸馏运行（run）：一次 autoSummarize 调用就是一轮。此前这条链路只在
+-- llm_audit_logs 里留一条计费痕迹，记忆侧的链接却只记到「会话 + seq 区间」——
+-- 「这条记忆是哪一次蒸馏带进来的」答不上，同一个区间重跑两次更分不出前后。
+-- 与 llm_audit_logs 的关系是**归因主体与它的开销读数**：run 是被归因的那一轮，
+-- audit 行是那一轮的开销；两边靠 distill_runs.audit_id 直接连，不靠时间戳猜。
+-- 为什么不复用 llm_audit_logs 的行 id 当 run id：audit 表按 llmAudit.retentionDays
+-- 到期裁剪（index.js 启动即调 deleteOldLlmAudits），归因会悬空；而 memory_provenance
+-- 与蒸馏窗口刻意活得更久（见 clearDistillRecords 注释）。归因不能挂在会被删掉的表上。
+-- 为什么不复用 dream_runs：那张表的每一列（snapshot_hash / input_count / decisions /
+-- outcome / receipt）都是巩固的语义，硬塞一个 run_type='autoSummarize' 会让
+-- 「dream_runs 的每一行都能回放一次巩固」这条契约失效。两张表各自的形状才是真的。
+-- audit_id 可空：llmAudit 关掉时那一轮没有 audit 行，run 仍然成立（归因不该依赖计费开关）。
+CREATE TABLE IF NOT EXISTS distill_runs (
+  id             TEXT PRIMARY KEY,
+  created_at     TEXT NOT NULL,
+  status         TEXT NOT NULL,   -- ok | degraded | noop | failed | aborted
+  error          TEXT,
+  -- 只放**有窗口**的蒸馏（autoSummarize，以及将来手动的 manual）。dream / sleep 的
+  -- 轮次不进这张表：它们是 dream_runs 的行，把同一轮复制成两行会让「哪张表是事实源」
+  -- 这个问题永远没有答案；那些记忆的归因走 memory_mints（见下）。
+  run_type       TEXT NOT NULL,   -- autoSummarize | manual
+  trigger_source TEXT NOT NULL,   -- autoSummarize | manual
+  session_id     TEXT,
+  seq_start      INTEGER,
+  seq_end        INTEGER,
+  memory_count   INTEGER NOT NULL DEFAULT 0,
+  provider       TEXT,
+  model          TEXT,
+  audit_id       INTEGER          -- llm_audit_logs.id（NULL = 那一轮没有 audit 行）
+);
+CREATE INDEX IF NOT EXISTS idx_distill_runs_created ON distill_runs(created_at);
+
+-- #512 记忆级「出生自哪一轮」。为什么它不是 memory_provenance 的一列：那张表的
+-- 粒度是 (记忆, 会话, seq 区间)，能表达的只有**窗口派生**的归因；而 dream / sleep
+-- 铸造的记忆根本没有窗口（session 与 seq 都不存在），硬塞一个合成区间就是
+-- 「看起来能追、实际是编的」。所以归因分两层，各自只记它真知道的事：
+--   · memory_provenance（+ distill_run_id）= 窗口级，「这段原文是哪一轮蒸出来的」；
+--   · 本表 = 行级，「这条记忆出生自哪一轮」，覆盖没有窗口的铸造路径。
+-- 只填 **create** 一种动作：merge/conflict/update/supersede 对既有行的改动，receipt_chain
+-- 已经按 (run_id, record_id) 记过了——再造一份就是第二套账。create 是那边唯一的洞
+-- （buildOutcome 刻意不给 create 派 disposition，receipt_chain 也就不产行）。
+-- run_type / trigger_source 就地冗余：run_id 在 dream_runs 与 distill_runs 两张表里
+-- 各有自己的主键域，读侧不该为了显示一个类型去 union 两张审计表。
+-- ON DELETE CASCADE：记忆行没了，归因没有指代对象；remove() 仍显式清（与
+-- memory_provenance 同一口径，不把清理挂在驱动默认上）。
+CREATE TABLE IF NOT EXISTS memory_mints (
+  memory_id      TEXT NOT NULL REFERENCES memories(id) ON DELETE CASCADE,
+  run_id         TEXT NOT NULL,
+  run_type       TEXT NOT NULL,   -- dream | sleep
+  trigger_source TEXT NOT NULL,   -- autoDream | sleep
+  created_at     TEXT NOT NULL,
+  PRIMARY KEY (memory_id, run_id)
+);
+CREATE INDEX IF NOT EXISTS idx_memory_mints_run ON memory_mints(run_id);
+
+-- #493 补充 §②：连续解析失败的**跨进程**计数（失败护栏 summarizeParseFailureMaxRetries
+-- 的判据）。原先只活在 summarize.js 的进程内 Map 里，于是重启即清零——而这条护栏要
+-- 防的恰恰是「确定性失败反复重试」，重启一次就绕过去了。
+-- 独立成表、不并进 distill_cursors 的三条理由：
+-- 1) 写 streak 不必先有游标行（窗口可能还没成功消费过任何一个 seq）；
+-- 2) 成功即归零是 DELETE，而游标那句 UPSERT 是 last_seq = MAX(...)（单调），
+--    两种语义塞进同一句会把「归零」写成「保留最大值」，护栏永远不解除；
+-- 3) 失效判据要读时间戳，就地一行更省事。
+-- 失效由读侧判（streakStaleAfterMs）：超过窗口没更新就当作 0，**不在写侧定时清**——
+-- 停了几周的会话再开跑时，若拿旧 streak 直接触发熔断，护栏本身就成了新的误伤路径。
+CREATE TABLE IF NOT EXISTS distill_parse_failures (
+  session_id TEXT PRIMARY KEY,
+  streak     INTEGER NOT NULL,
+  updated_at TEXT NOT NULL
+);
+
 -- entity gene (v0.3.0): named entities mentioned across memories, with
 -- time-boxed attributes (valid_from → valid_until) and typed relations.
 -- Attributes follow the snapshot style: saveAttr invalidates the previous
@@ -403,6 +532,10 @@ export const TYPES = new Set(["preference", "project", "decision", "history", "s
 // 截断上限（continuity.js）是两件事。
 const MAX_CONTINUITY_PENDING = 200;
 
+// dream_runs.run_type 的取值域（schema 注释同款）。既是白名单也是下推条件的护栏：
+// listDreamRuns 的 excludeRunType 会拼进 SQL 的 != 比较，非白名单值一律忽略。
+const DREAM_RUN_TYPES = ["auto", "sleep", "organize"];
+
 // Epistemic status: what kind of evidence a memory rests on. Defaults to
 // 'subjective' so legacy rows (and rows without any signal) stay compatible.
 const EPISTEMIC_STATUSES = new Set(["observation", "subjective", "inferred"]);
@@ -536,6 +669,11 @@ function toRow(row) {
     // 顺手 `?? updated_at` 把代理口径捡回来。
     archived_at: row.archived_at ?? undefined,
     source: row.source ?? undefined,
+    // 车道 C：外来行身份两格。NULL 读作 undefined（与 archived_at 同款「不可知就不编
+    // 值」）。注意「这行是不是外来行」的判据仍是 source（memory-source.js 的
+    // isImportedRow）——这两格只回答「来自哪个包 / 幂等键是什么」，不回答身份。
+    share_pack_id: row.share_pack_id ?? undefined,
+    share_external_id: row.share_external_id ?? undefined,
     content_history: parseJsonArray(row.content_history),
     evidence: parseJsonArray(row.evidence),
     doc_path: row.doc_path ?? undefined,
@@ -578,7 +716,29 @@ function toDreamRun(row) {
     skipped: row.skipped ? JSON.parse(row.skipped) : undefined,
     // Issue #89（基线半边）：成功轮落下的阈值基线（NULL = 该轮没有推进基线）。
     store_count: row.store_count ?? undefined,
-    store_chars: row.store_chars ?? undefined
+    store_chars: row.store_chars ?? undefined,
+    // #534：失败轮的模型原始输出截断副本（NULL = 该轮没留下，或该轮是历史行）。
+    raw_output: row.raw_output ? JSON.parse(row.raw_output) : undefined
+  };
+}
+
+function toDistillRun(row) {
+  if (!row) return undefined;
+  return {
+    id: row.id,
+    created_at: row.created_at,
+    status: row.status,
+    error: row.error ?? undefined,
+    run_type: row.run_type,
+    trigger_source: row.trigger_source,
+    session_id: row.session_id ?? undefined,
+    seq_start: row.seq_start ?? undefined,
+    seq_end: row.seq_end ?? undefined,
+    memory_count: row.memory_count ?? 0,
+    provider: row.provider ?? undefined,
+    model: row.model ?? undefined,
+    // NULL = 那一轮没有 audit 行（llmAudit 关着，或还没写回）。
+    audit_id: row.audit_id ?? undefined
   };
 }
 
@@ -616,6 +776,20 @@ function toConflictPending(row) {
   };
 }
 
+function toDifferentiatedPair(row) {
+  if (!row) return undefined;
+  return {
+    id: row.id,
+    memory_a: row.memory_a,
+    memory_b: row.memory_b,
+    hash_a: row.hash_a ?? undefined,
+    hash_b: row.hash_b ?? undefined,
+    distinctions: row.distinctions ? JSON.parse(row.distinctions) : undefined,
+    run_id: row.run_id ?? undefined,
+    created_at: row.created_at
+  };
+}
+
 function toScopeChange(row) {
   if (!row) return undefined;
   return {
@@ -886,6 +1060,32 @@ export function createStore(path) {
   // 存量行的值是 NULL，且**不推断**：按 updated_at 猜出的模型名会变成日后审计信
   // 以为真的证据。NULL 一律读作「出身未知」，等价的补法是重算，不是猜。
   addColumn("memories", "embedding_model", "ALTER TABLE memories ADD COLUMN embedding_model TEXT");
+  // 车道 C：外来行的身份两件套。share_pack_id 是「整包退出」的寻址键，share_external_id
+  // 是导入的幂等键。它们只对自己铸造的行有意义，所以缺省是 NULL 而不是 ''：空串会参与
+  // 唯一性（第二条本地行就撞响），而存量行零重写、读侧 undefined = 「不是外来行」。
+  addColumn("memories", "share_pack_id", "ALTER TABLE memories ADD COLUMN share_pack_id TEXT");
+  addColumn("memories", "share_external_id", "ALTER TABLE memories ADD COLUMN share_external_id TEXT");
+  // 索引建在加列之后而非写进 SCHEMA（本文件 content_hash 那段：存量库打开时 CREATE TABLE
+  // 是 no-op，列还不存在就建索引会直接 no such column）。
+  // 部分索引（WHERE ... IS NOT NULL）是刻意的，但它承重的地方要说准：SQLite 的 UNIQUE
+  // 本就把 NULL 视为互不相等，本地行（这一格恒 NULL）挂在普通 UNIQUE 上也不撞——变异检验
+  // 证实摘掉 WHERE 五个用例照绿。它承的是另外两件事：①约束的适用范围写进索引本身，
+  // 「只有导入路径铸造的 id 参与唯一性」这条语义没有别的表达渠道，读代码的人不必再去猜
+  // NULL 在这里算什么；②本地行不进这棵 b 树——普通 UNIQUE 要给每一条本地记忆插一个永不
+  // 生效的空键，而库里绝大多数是本地行，每次写都白付一次索引维护。
+  // 「NULL 必须自由共享」那条用例锁的是行为而非实现：它防的是将来有人把空串当缺省值写
+  // 进来（'' 参与唯一性，第二条 '' 直接撞响），不是防 WHERE 子句消失。
+  db.exec("CREATE UNIQUE INDEX IF NOT EXISTS idx_memories_share_external ON memories(share_external_id) WHERE share_external_id IS NOT NULL");
+  db.exec("CREATE INDEX IF NOT EXISTS idx_memories_share_pack ON memories(share_pack_id)");
+  // Issue #505：saveWithDedupe 的定向候选是 `type = ? AND TRIM(title) = ?`。只有
+  // idx_memories_type 时这条语句等于「把该类型的行全读一遍、逐行 TRIM」，代价随最大
+  // 类型的行数线性长（本机 node:sqlite 实测同类型 1000 / 5000 / 20000 行 = 0.13 /
+  // 0.68 / 4.63 ms，而它是每存一条都要付一次的写路径）。TRIM 本身不是瓶颈——同句去掉
+  // TRIM 只差 0.07 ms，缺的是能把整个条件当 seek 用的索引；建好之后同一查询在同一批
+  // 数据上 ~0.00 ms。索引表达式必须与 SQL 里的写法逐字相同（TRIM(title)，不是 title），
+  // 差一点优化器就静默不认，而所有行为用例照样全绿——所以 dedupe-candidate-window
+  // 那条用例用 EXPLAIN QUERY PLAN 钉住它真的被选中。改 service 的 WHERE 必须同时改这里。
+  db.exec("CREATE INDEX IF NOT EXISTS idx_memories_type_trimmed_title ON memories(type, TRIM(title))");
   // issue #24 块2（权重演化）：entity_relations 加 weight + source。存量关系
   // 行缺列 → 默认 manual 1.0（最保守：既有语义不因迁移而变弱）。
   addColumn("entity_relations", "weight", "ALTER TABLE entity_relations ADD COLUMN weight REAL NOT NULL DEFAULT 1.0");
@@ -924,6 +1124,9 @@ export function createStore(path) {
   // 成功轮之前播种端拿不到基线，行为与升级前一致；跑过一轮之后闸门即跨重启生效。
   addColumn("dream_runs", "store_count", "ALTER TABLE dream_runs ADD COLUMN store_count INTEGER");
   addColumn("dream_runs", "store_chars", "ALTER TABLE dream_runs ADD COLUMN store_chars INTEGER");
+  // #534：失败轮的模型原始输出。存量行两列皆 NULL——历史失败轮反推不出原文
+  // （那正是这条要补的口子），升级后新失败轮才有值。
+  addColumn("dream_runs", "raw_output", "ALTER TABLE dream_runs ADD COLUMN raw_output TEXT");
 
   // Legacy mirror_state without v0.3.6 generation columns → add each missing
   // column idempotently (old DBs open cleanly, no data loss).
@@ -938,6 +1141,14 @@ export function createStore(path) {
   addColumn("llm_audit_logs", "session_key", "ALTER TABLE llm_audit_logs ADD COLUMN session_key TEXT");
   db.exec("CREATE INDEX IF NOT EXISTS idx_llm_audit_session ON llm_audit_logs(session_key);");
 
+  // #512：把每条溯源链接指回产出它的那一轮蒸馏（distill_runs.id）。
+  // 存量链接一律留 NULL——那是**本次改造之前的历史**，按 (session, 区间, created_at)
+  // 反推一个合成 id 会得到「读数正常、实际是猜的」归因，比不填更坏（与 #534
+  // raw_output「历史失败轮反推不出原文」同一口径：补不出的就承认补不出）。
+  // 索引建在加列之后：老库打开时列还不存在（SCHEMA 的 CREATE TABLE 只对新建库生效）。
+  addColumn("memory_provenance", "distill_run_id", "ALTER TABLE memory_provenance ADD COLUMN distill_run_id TEXT");
+  db.exec("CREATE INDEX IF NOT EXISTS idx_memory_provenance_run ON memory_provenance(distill_run_id);");
+
   // Audit peer F: a legacy DB may hold a non-integer generation/applied_generation
   // (pre-v0.3.9 the JS gate truncated with Math.trunc and SQLite's CHECK only
   // enforced >= 0). Such a value is ambiguous — it cannot map to a real applied
@@ -1042,6 +1253,59 @@ export function createStore(path) {
     return getDistillCursor(sessionId);
   }
 
+  /**
+   * 读指定会话的连续解析失败计数。
+   *
+   * `staleAfterMs` 是**读侧**失效窗口（#493 补充 §②）：超过这么久没更新就把计数
+   * 当作 0，而不是拿几周前攒下的值去触发熔断。劣化方向选得很明确——宁可多试一次
+   * （多花一次 LLM 调用），也不要因为「会话停了很久」而误判一个其实健康的窗口。
+   * 传 0 或负数表示不判失效（照原样返回），测试用它构造边界。
+   * @returns {number} 0 表示没有在途失败（含「已失效」与「从未记录」两种）
+   */
+  function getDistillParseFailureStreak(sessionId, { staleAfterMs = 0, nowMs = Date.now() } = {}) {
+    if (typeof sessionId !== "string" || sessionId.length === 0) return 0;
+    const row = db.prepare(
+      "SELECT streak, updated_at FROM distill_parse_failures WHERE session_id = ?"
+    ).get(sessionId);
+    if (!row) return 0;
+    if (staleAfterMs > 0) {
+      const stamp = Date.parse(row.updated_at);
+      // 时间戳读不出来时按「已失效」处理：一个解析不了的 updated_at 不能当作「刚刚
+      // 失败过」，否则坏数据会永久钉住一道护栏（fail-open，与整条护栏的默认关一致）。
+      if (!Number.isFinite(stamp) || nowMs - stamp > staleAfterMs) return 0;
+    }
+    return Number(row.streak) || 0;
+  }
+
+  /**
+   * 记一次解析失败（+1 并刷新时间戳）。返回写后的计数。
+   *
+   * 先按 staleAfterMs 读一遍再**覆写**，而不是在 SQL 里做 streak + 1——失效判断只
+   * 许有一份（就是上面那个读函数）。写成 + 1 的话，一条几周前的旧行会把「新的第一
+   * 次失败」直接加成 2，等于失效窗口在这条路径上完全不生效（本块实现的首版就是
+   * 这么写的，被回归用例抓出来）。
+   */
+  function bumpDistillParseFailureStreak(sessionId, { staleAfterMs = 0, nowMs = Date.now() } = {}) {
+    if (typeof sessionId !== "string" || sessionId.length === 0) {
+      throw new TypeError("bumpDistillParseFailureStreak: sessionId must be a non-empty string");
+    }
+    const next = getDistillParseFailureStreak(sessionId, { staleAfterMs, nowMs }) + 1;
+    db.prepare(`
+      INSERT INTO distill_parse_failures (session_id, streak, updated_at)
+      VALUES (?, ?, ?)
+      ON CONFLICT(session_id) DO UPDATE SET
+        streak = excluded.streak,
+        updated_at = excluded.updated_at
+    `).run(sessionId, next, nowIso());
+    return next;
+  }
+
+  /** 清零（不是写 0）：没有在途失败时不该留一行，否则「有没有失败过」变得不可区分。 */
+  function clearDistillParseFailureStreak(sessionId) {
+    if (typeof sessionId !== "string" || sessionId.length === 0) return 0;
+    return db.prepare("DELETE FROM distill_parse_failures WHERE session_id = ?").run(sessionId).changes;
+  }
+
   function count(type, { minImportance = null, source = null, includeForgotten = false, includeArchived = false, onlyArchived = false, depositedOnly = false, updatedFrom = null, updatedTo = null, occurredFrom = null, occurredTo = null, visibility = null } = {}) {
     const clauses = [];
     const params = [];
@@ -1123,6 +1387,30 @@ export function createStore(path) {
     return toRow(row);
   }
 
+  /**
+   * 车道 C 导入的幂等读：按包内那条记忆的铸造 id 找本库的行。
+   * 走 idx_memories_share_external（部分索引，非 NULL 那一侧），等值 seek。
+   * 本地行这一格恒 NULL，因此本函数永远不会误命中本地记忆。
+   */
+  function getByShareExternalId(externalId) {
+    if (typeof externalId !== "string" || !externalId) return undefined;
+    return toRow(db.prepare("SELECT * FROM memories WHERE share_external_id = ?").get(externalId));
+  }
+
+  /**
+   * 一个包在本库落下的全部行（撤回前的清点 / 面板「外来区」列表）。
+   *
+   * 不过滤 archived / forgotten：整包退出要连归档面与遗忘面一起收走，否则撤回后库里
+   * 还剩几条「来自那个已经收起的包」的行，身份与包对不上。
+   * 读显式列清单而非 SELECT *（#430 的口径）：一个包可以有几百行，每行 9.4 MB 级别
+   * 的 embedding 拖进来没有任何消费方会读。
+   */
+  function listBySharePackId(packId) {
+    if (typeof packId !== "string" || !packId) return [];
+    return db.prepare(`SELECT ${memoryColumnList} FROM memories WHERE share_pack_id = ? ORDER BY updated_at DESC, id DESC`)
+      .all(packId).map(toRow);
+  }
+
   // #230 写入权分离（存储层唯一铸造口，CodeRabbit 复核最终形态）：document
   // 行只能经 saveDocument 铸造，通用 save 整类拒绝。doc_path 是任意调用方
   // 都能捏造的字符串——「必带 doc_path」挡不住绕过注册校验（flag 闸 / 文件
@@ -1168,8 +1456,8 @@ export function createStore(path) {
       : inferEpistemicStatus(memory);
     runAtomically(() => {
       db.prepare(
-        `INSERT INTO memories (id, type, title, content, tags, importance, forgotten, archived, archived_at, source, content_history, quality_score, embedding, epistemic_status, agent_scope, workspace_scope, agent_scope_source, workspace_scope_source, scope_decided_at, sensitivity, occurred_at, evidence, doc_path, content_hash, created_at, updated_at)
-         VALUES (?, ?, ?, ?, ?, ?, 0, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)`
+        `INSERT INTO memories (id, type, title, content, tags, importance, forgotten, archived, archived_at, source, content_history, quality_score, embedding, epistemic_status, agent_scope, workspace_scope, agent_scope_source, workspace_scope_source, scope_decided_at, sensitivity, occurred_at, evidence, doc_path, content_hash, share_pack_id, share_external_id, created_at, updated_at)
+         VALUES (?, ?, ?, ?, ?, ?, 0, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)`
       ).run(
         id,
         type,
@@ -1197,6 +1485,11 @@ export function createStore(path) {
         evidence,
         docPath,
         contentHash,
+        // 车道 C：外来行身份。空串一律落 NULL——空串会占住 UNIQUE 索引的一格，第二条
+        // 空串外来行就撞响；这两格只由导入路径铸造，其余写入恒 NULL。
+        // created_at / updated_at / content_hash 仍由本函数铸造，不接受调用方传值。
+        typeof memory.share_pack_id === "string" && memory.share_pack_id.trim() ? memory.share_pack_id.trim() : null,
+        typeof memory.share_external_id === "string" && memory.share_external_id.trim() ? memory.share_external_id.trim() : null,
         now,
         now
       );
@@ -1332,12 +1625,15 @@ export function createStore(path) {
 
   function remove(id) {
     runAtomically(() => {
-      // #399：memory_provenance 的 ON DELETE CASCADE 在本库是惰性的（createStore
-      // 从不打开 PRAGMA foreign_keys），所以链接在这里显式清。不用翻转全局 pragma
-      // 换这一条级联：那会同时激活 recall_events 那条既有的 REFERENCES，改变一个
-      // 与 #399 无关的写入路径。记录本身（distill_records）不删——删掉一条派生记忆
+      // #399：memory_provenance 挂着 ON DELETE CASCADE，而 node:sqlite 默认就把
+      // foreign_keys 开成 1（实测 PRAGMA foreign_keys = 1），所以级联今天确实在兜底。
+      // 这条显式 DELETE 不是冗余、也不是「FK 没开才需要」：它是不把清理挂在一份没人
+      // 钉过的驱动默认上——连接哪天以 enableForeignKeyConstraints:false 打开，悬空链接
+      // 只有这一条挡得住。记录本身（distill_records）不删——删掉一条派生记忆
       // 不该让整个窗口的原文凭证消失。
       db.prepare("DELETE FROM memory_provenance WHERE memory_id = ?").run(id);
+      // #512：铸造记录同理——它也只是指着记忆行的索引，行没了索引就没有指代对象。
+      db.prepare("DELETE FROM memory_mints WHERE memory_id = ?").run(id);
       db.prepare("DELETE FROM memories WHERE id = ?").run(id);
       // Mirror sync must reflect the deletion; bump desired generation so a
       // crash between the delete and syncMirror leaves a recoverable debt.
@@ -1345,6 +1641,68 @@ export function createStore(path) {
     });
   }
 
+  // 一条 DELETE ... WHERE id IN (...) 最多绑多少个 `?`。SQLite 的上限是 32766
+  // （SQLITE_MAX_VARIABLE_NUMBER），取 500 后离上限还有六十多倍余量：这条语句一行一个参数，
+  // 而包的大小按字节不按条数封顶（见 deleteBySharePackId 的分块理由），500 让单条语句的
+  // 解析成本可以忽略、又永远够不到那格上限，块数只随包条数线性增长。
+  const DELETE_ID_CHUNK = 500;
+
+  /**
+   * 整包退出（车道 C）。删空一个不存在的包是幂等的 0，不是错误——对方点第二次「收起
+   * 这个包」与「收起一个从来没导入过的包」都该是这个答案；早退也不 bump generation：
+   * 什么都没删就别记一笔镜像债（remove() 每次必 bump，那是它的既有行为，不在这里扩大）。
+   *
+   * side table 清理口径 = remove() 的口径（#399 / #512）：显式同事务清 memory_provenance
+   * 与 memory_mints。
+   * 这条是双保险，不是「FK 没开所以必须手写」：memory_provenance 挂着 ON DELETE CASCADE，
+   * 而 node:sqlite 默认就把 foreign_keys 开成 1（实测 PRAGMA foreign_keys = 1），今天删行
+   * 确实另有级联兜底；显式清理的存在是为了不依赖这份没人钉过的驱动默认，同时跟 remove()
+   * 保持一致的口径（连接哪天以 enableForeignKeyConstraints:false 打开，悬空链接只有它挡得住）。
+   *
+   * remove() 不碰的（entity_attrs / entity_relations 的 memory_id 反查、conflict_pending、
+   * scope_changes、embedding 解析缓存）这里也不碰——批删不是新的清理语义。
+   *
+   * 向量索引这一格 C4 实测过，把 C1 留下的那句「由 C4 在 service 侧处理」改对：service
+   * 侧没有活儿要接。`vector-index.js` 是 memories.embedding 那一列的薄层，余弦检索
+   * (`searchVector`) 每次调用都从 SQL 现取「带向量的行」的 id 集合，行被物理删掉即从集合
+   * 里消失——向量跟着行一起走，一列残值都留不下；事后落到的 embed 也只是
+   * `UPDATE ... WHERE id = ?` 命中 0 行，不会把僵尸行写回来。唯一的残留是 #202 那个
+   * 进程内的解析缓存（id → 已解析向量），它与 remove() 同处置且读不出僵尸：每个调用方
+   * （searchVector / getEmbeddings / document.js / organize.js）的 id 集合都来自活行的
+   * SQL 读，未命中缓存时按 id 点查库，行没了就返回 undefined——最坏是一条等 FIFO 驱逐的
+   * 内存，不是一条搜得到的鬼行。要在这里清它等于给批删加一份 remove() 没有的新语义，
+   * 与本方法的口径声明相反，所以不动（C4 的报告记了这一格，remove() 是否要一起补是
+   * 单独一刀的事）。
+   *
+   * IN 列表分块（chunk = DELETE_ID_CHUNK）：SQLite 一条语句最多绑 32766 个参数
+   * （SQLITE_MAX_VARIABLE_NUMBER，实测第 32767 个报 "too many SQL variables"），而这条
+   * 语句原本一行一个 `?`。车道 A 的包水位按字节不按条数（MAX_PACK_BYTES = 3 MiB），所以
+   * 「正文很短、条数很多」的包理论上能逼近那一格——一条语句撞上限是整笔回滚，效果等于
+   * 「这个包永远撤不掉」，而那正是退出这条路径最不该坏的方式。
+   * 分块不是语义变化，四点逐条对齐分块前的形状：ids 是本事务开头一次读到的固定快照
+   * （slice 出来的连续段，块之间互不相交、并起来就是全集）；按主键删本就幂等；整包裹在同
+   * 一个 runAtomically 里，原子性与快照语义一字未动；generation 只在最后加一次，所以
+   * 「删了行却没记镜像债」这个 crash 窗口和分块前同样不存在。changes 逐块求和——那是
+   * 调用方答复里报出去的数，少加一块就少报一块。
+   */
+  function deleteBySharePackId(packId) {
+    if (typeof packId !== "string" || !packId) return 0;
+    return runAtomically(() => {
+      const ids = db.prepare("SELECT id FROM memories WHERE share_pack_id = ?").all(packId).map((r) => r.id);
+      if (!ids.length) return 0;
+      let deleted = 0;
+      for (let start = 0; start < ids.length; start += DELETE_ID_CHUNK) {
+        const chunk = ids.slice(start, start + DELETE_ID_CHUNK);
+        const marks = chunk.map(() => "?").join(", ");
+        db.prepare(`DELETE FROM memory_provenance WHERE memory_id IN (${marks})`).run(...chunk);
+        db.prepare(`DELETE FROM memory_mints WHERE memory_id IN (${marks})`).run(...chunk);
+        deleted += db.prepare(`DELETE FROM memories WHERE id IN (${marks})`).run(...chunk).changes;
+      }
+      incrementGeneration();
+      return deleted;
+    });
+  }
+
   /**
    * Atomic compare-and-set update: applies `patch` only when the row still
    * carries `expectedUpdatedAt` (the version token read by the caller). Returns
@@ -1521,7 +1879,7 @@ export function createStore(path) {
     return rows.map(toRow);
   }
 
-  function list({ type, excludeTypes = null, limit = 50, offset = 0, order = "importance", includeForgotten = false, includeArchived = false, onlyArchived = false, depositedOnly = false, minImportance = null, source = null, updatedFrom = null, updatedTo = null, occurredFrom = null, occurredTo = null, visibility = null } = {}) {
+  function list({ type, excludeTypes = null, excludeImported = false, limit = 50, offset = 0, order = "importance", includeForgotten = false, includeArchived = false, onlyArchived = false, depositedOnly = false, minImportance = null, source = null, updatedFrom = null, updatedTo = null, occurredFrom = null, occurredTo = null, visibility = null } = {}) {
     const clauses = [];
     const params = [];
     if (type) {
@@ -1545,6 +1903,17 @@ export function createStore(path) {
       clauses.push("source = ?");
       params.push(source);
     }
+    // excludeImported：「本库不巩固别人导入的原文」这条政策轴的查询层口径。
+    // 它必须站在 LIMIT 之前而不是跟着 .filter 走在后面——与上面 excludeTypes 那条同理由
+    // （#230）：先截断后丢弃的话，被丢掉的外来行照样吃掉窗口名额，导入过包的库里
+    // 模式扫描池会因此饿到 sleepPatternMinMemories 以下而静默跳过。
+    // `source IS NULL OR` 那一支不是防御性冗余，是必填：本方行的 source 恒为 NULL，
+    // 而 SQL 里三值逻辑让 `NULL <> IMPORTED_SOURCE` 求值为 NULL（不是 true），只写后者的
+    // 话本方行整批消失。opt-in 默认关，其余调用方的读数逐字节不变。
+    if (excludeImported) {
+      clauses.push("(source IS NULL OR source <> ?)");
+      params.push(IMPORTED_SOURCE);
+    }
     // Optional updated_at closed range (date-only "to" is normalized to the
     // end of that day). Same helper as count() so total matches the rows.
     const bounds = updatedAtBounds(updatedFrom, updatedTo);
@@ -1645,6 +2014,30 @@ export function createStore(path) {
     return rows.map(toRow);
   }
 
+  // Issue #505：写路径的去重候选必须「按同标题定向取」，不能「按 importance 取
+  // 前 N 条」。后者是「该类型最重要的 100 行」，与「找出同标题的那一行」无关：
+  // 某类型里 importance 高于待写行的行数一旦超过窗口，同标题行与待写行双双落在
+  // 窗口外，saveWithDedupe 的 find 恒不命中，于是静默走创建分支——不报错、不告
+  // 警，合并语义随库增长而失效（报告实测 1047 行类型、importance=5 有 180 行时
+  // 稳定复现）。
+  //
+  // 口径刻意与 saveWithDedupe 的比较式对齐：那边用 m.title.trim() 比
+  // String(memory.title).trim()，而 title 入库时并不 trim（见 save() 的
+  // `memory.title` 直写）⇒ 这里必须 TRIM(title)，否则存量里带首尾空白的标题
+  // 会被精确匹配漏掉，退回同一种静默降级。
+  //
+  // archived/forgotten 的过滤与 list() 默认口径一致（两者都为 0）：合并目标必须
+  // 是活跃行，否则会把内容并进一条已经归档/遗忘的记忆里。
+  // 无 LIMIT：同 (type, title) 的活跃行本就极少，加窗口等于把 #505 重新引进来。
+  function activeByTypeAndTitle(type, title) {
+    const rows = db.prepare(
+      `SELECT ${memoryColumnList} FROM memories
+        WHERE type = ? AND TRIM(title) = ?
+          AND forgotten = 0 AND archived = 0`
+    ).all(type, String(title ?? "").trim());
+    return rows.map(toRow);
+  }
+
   // Issue #430：写路径要的「最近若干条正文」。质量过滤的近重复判定只读 content
   // 这一列 + 前 20 行，此前写成 all().slice(0, 20) —— 全表逐行 toRow（27 字段、
   // 三次 JSON 解析）之后只截前 20 条正文；5k 行实测 100ms 级 → 0.06ms 级。
@@ -1801,6 +2194,71 @@ export function createStore(path) {
     }, new Map());
   }
 
+  /**
+   * 维度探针（#383）：**存在性判据**——库里有没有一条活跃向量的维度等于查询维度。
+   *
+   * #508 评审把判据从「读一行的维度」换成了存在性，因为 LIMIT 1 拿任意一条代表全库，
+   * 在混合维度库里两个方向都错：抽到与查询不符的那条 → 明明有可比的 3 维向量却报
+   * degraded；抽到的那条恰好解析失败 → 其余有效向量都不匹配时又漏报成 full。一行
+   * 读数回答不了「这个维度在这库里能不能比」这个问题。
+   *
+   * 行集与 searchVector **必须同源**：下面这段 WHERE 的谓词与 searchVector（本文件
+   * vector search 段）逐条相同（只是书写顺序不同，语义等价），改一处必须同步改另一处
+   * ——否则 tier 的核心断言「searchVector 会不会找到可比向量」会悄悄失真。活跃 = 未
+   * 遗忘未归档、embedding 非空；/context 只经 searchVector 触达检索，从不传
+   * includeArchived。
+   *
+   * 状态语义（后两个是 fail-closed 兜底态，不是正常读数）：
+   *   match      有维度相符的活跃向量 → 语义路通。注意「通」≠「有命中」：type /
+   *              importance / codingGate / scope 四道门（service.js 的 inject 段）
+   *              仍可能让语义档贡献为 0，这是旧探针就有的边界。
+   *   mismatch   有向量，但没有一条维度相符 → 语义召回实际不可用 → degraded
+   *   none       行集本身为空（空库 / 从未建索引）→ 没有东西可比，**不是**维度
+   *              不符 → full
+   *   unreadable 有行，但一条都读不出来（embedding 列损坏）→ 与 none 是**两种空**：
+   *              前者是还没有内容，后者是内容在那儿却读不出来。判不出来 → unknown，
+   *              绝不因为「读不到」就宣称 full。
+   *   invalid    查询维度本身不是正整数 → 同样判不出来 → unknown。当前 /context
+   *              不可达（embedQueryVector 保证返回非空数组），防御性留着：别让
+   *              「判不了」落到 full 上。
+   *
+   * 成本模型（取代原来「只读一行，O(1)」的说法——那句话对现在的实现是假的）：
+   *   · SQL 是一次**无 ORDER BY 无 LIMIT 的全 id 扫描**，每次调用都有，不免费
+   *     （只拖 id 列，约 40 KB/千行，比 SELECT * 的全表 TEXT 便宜得多）。
+   *   · 按匹配短路：全库同维度（常态）时 JS 循环第一行就 return，只解析 1 个向量。
+   *   · 一条都不匹配时才走完整个循环，而那正是要报 degraded 的情形，值得。此时每个
+   *     缓存未命中的行都要点查一次 embedding TEXT（冷缓存下 = N+1 条语句）；
+   *     getParsedEmbedding 不缓存否定结果，所以读不出来的行每次请求都会重解析一次。
+   *   · 缓存热不热是有条件的：/context 里让 embeddingCache 变热的只有 injectCandidates
+   *     内部两个 vectorIndex 分支（service.js:1696 / :1768），需要 hybridInject 与
+   *     selectiveInject 都没被关掉、行数在 4000 条 FIFO 上限内；standalone 装配不设
+   *     vectorIndex 时缓存是冷的。判档跑在 injectCandidates 之后，装配齐时缓存已热。
+   *
+   * @param {number} dimension 查询向量维度
+   * @returns {{state: "match"|"mismatch"|"none"|"unreadable"|"invalid"}}
+   */
+  function vectorDimensionState(dimension) {
+    if (!Number.isInteger(dimension) || dimension <= 0) return { state: "invalid" };
+    // 与 searchVector 的 WHERE 谓词逐条相同（顺序不同、语义等价）——同源行集，同步改。
+    const rows = db.prepare(
+      `SELECT id FROM memories
+       WHERE embedding IS NOT NULL AND embedding != ''
+         AND forgotten = 0 AND archived = 0`
+    ).all();
+    if (!rows.length) return { state: "none" };
+    let sawVector = false;
+    for (const row of rows) {
+      // 走 getParsedEmbedding 的解析缓存，不自己 JSON.parse——与 searchVector /
+      // getEmbedding(s) 同一条读路径，缓存热时零解析。
+      const v = getParsedEmbedding(row.id);
+      if (!v || !v.length) continue;
+      sawVector = true;
+      if (v.length === dimension) return { state: "match" };
+    }
+    // 有行却零条可解析：不是「没有向量」，是「有向量读不出来」。
+    return { state: sawVector ? "mismatch" : "unreadable" };
+  }
+
   function search(query, { limit = 20, includeArchived = false } = {}) {
     const q = String(query).trim();
     if (!q) return [];
@@ -1902,18 +2360,22 @@ export function createStore(path) {
       Number.isInteger(run.store_chars) && run.store_chars >= 0;
     const storeCount = baselineKnown ? run.store_count : null;
     const storeChars = baselineKnown ? run.store_chars : null;
+    // #534：失败轮的模型原始输出（对象：kind/raw_len/raw_head/raw_tail?/parsed?）。
+    // 未提供落 NULL 而不是 "{}"——读侧靠「有没有值」区分「这轮没留」与「留了个空」。
+    const rawOutput = run.raw_output !== undefined ? JSON.stringify(run.raw_output) : null;
     db.prepare(
       `INSERT INTO dream_runs (id, created_at, status, error, provider, model, snapshot_hash,
         input_count, input, decisions, outcome, applied, summary_stored, receipt, policy_epoch, run_type, skipped,
-        store_count, store_chars)
-       VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
+        store_count, store_chars, raw_output)
+       VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
        ON CONFLICT(id) DO UPDATE SET
          created_at=excluded.created_at, status=excluded.status, error=excluded.error,
          provider=excluded.provider, model=excluded.model, snapshot_hash=excluded.snapshot_hash,
          input_count=excluded.input_count, input=excluded.input, decisions=excluded.decisions,
          outcome=excluded.outcome, applied=excluded.applied, summary_stored=excluded.summary_stored,
          receipt=excluded.receipt, policy_epoch=excluded.policy_epoch, run_type=excluded.run_type,
-         skipped=excluded.skipped, store_count=excluded.store_count, store_chars=excluded.store_chars`
+         skipped=excluded.skipped, store_count=excluded.store_count, store_chars=excluded.store_chars,
+         raw_output=excluded.raw_output`
     ).run(
       id,
       run.created_at ?? now,
@@ -1933,7 +2395,8 @@ export function createStore(path) {
       runType,
       skipped,
       storeCount,
-      storeChars
+      storeChars,
+      rawOutput
     );
     return getDreamRun(id);
   }
@@ -1943,11 +2406,16 @@ export function createStore(path) {
     return toDreamRun(row);
   }
 
-  function listDreamRuns({ limit = 50, offset = 0 } = {}) {
+  // #495：excludeRunType 是可选下推条件，默认不过滤——审计面（面板的最近运行、
+  // 回放脚本、各测试的 `listDreamRuns()` 无参调用）本来就该看全量，过滤只在
+  // 「最近一次真·巩固」这种需要排除 agent 主动整理的场合由调用方显式指定。
+  // 值走白名单：这个参数会拼进 SQL 的 != 条件，不接受任意字符串。
+  function listDreamRuns({ limit = 50, offset = 0, excludeRunType = null } = {}) {
     const { limit: lim, offset: off } = sanitizePage(limit, offset, 50);
+    const excluded = DREAM_RUN_TYPES.includes(excludeRunType) ? excludeRunType : null;
     const rows = db.prepare(
-      "SELECT * FROM dream_runs ORDER BY created_at DESC, id LIMIT ? OFFSET ?"
-    ).all(lim, off);
+      "SELECT * FROM dream_runs WHERE (? IS NULL OR run_type != ?) ORDER BY created_at DESC, id LIMIT ? OFFSET ?"
+    ).all(excluded, excluded, lim, off);
     return rows.map(toDreamRun);
   }
 
@@ -2227,7 +2695,7 @@ export function createStore(path) {
     const now = nowIso();
     const inTokens = Number.isFinite(entry.input_tokens) ? entry.input_tokens : 0;
     const outTokens = Number.isFinite(entry.output_tokens) ? entry.output_tokens : 0;
-    db.prepare(
+    const info = db.prepare(
       `INSERT INTO llm_audit_logs (timestamp, trigger_source, operation_type, model_id,
         input_tokens, output_tokens, total_tokens, cost_usd, duration_ms, status,
         error_message, related_memory_ids, metadata, session_key)
@@ -2250,7 +2718,38 @@ export function createStore(path) {
         : null,
       entry.session_key ?? null
     );
-    return toLlmAudit(db.prepare("SELECT * FROM llm_audit_logs ORDER BY id DESC LIMIT 1").get());
+    // #534 / CodeRabbit on #535：回读必须用**这一次插入**的 rowid，不能用
+    // `ORDER BY id DESC LIMIT 1`。库支持多进程共用（见 AGENTS.md 的
+    // busy_timeout + WAL 约定），另一个写者在这两条语句之间插入就会把这行
+    // 读成别人的调用——调用方拿它去 annotate 校验判决时，会把本轮结论写到
+    // 另一轮头上。lastInsertRowid 是连接内的事实，不受并发写影响。
+    return toLlmAudit(db.prepare("SELECT * FROM llm_audit_logs WHERE id = ?").get(info.lastInsertRowid));
+  }
+
+  /**
+   * #534 建议 3：给已落库的审计行补一层「事后才知道」的读数。
+   *
+   * 两套账的根源是时序：审计行在 LLM 调用返回的那一刻就写死了（状态、token、
+   * 耗时都是调用层事实），而决策校验发生在调用之后——一轮「调用成功、输出却被
+   * 校验整单拒绝」在审计表里永远是 success，于是聚合出来的成功率与 dream_runs
+   * 的真实成功率对不上（作者实测 95% vs 10.5%）。
+   *
+   * 只合并 metadata（表里写明是 free-form extras），绝不改 status / token /
+   * timestamp：那些是调用层的事实，改写它们等于伪造账本。metadata 是「这一轮还
+   * 有什么值得记的」的垃圾桶，把校验判决放进去既补上了分账，又不制造第二张表。
+   *
+   * patch 是浅合并：已有键保留，同名键覆盖。行不存在（被清理/删除）静默返回
+   * undefined——补注失败不该把一轮巩固变成异常。
+   */
+  function annotateLlmAudit(id, patch) {
+    if (id == null || !patch || typeof patch !== "object") return undefined;
+    const row = db.prepare("SELECT * FROM llm_audit_logs WHERE id = ?").get(id);
+    if (!row) return undefined;
+    const current = toLlmAudit(row)?.metadata;
+    const base = current && typeof current === "object" && !Array.isArray(current) ? current : {};
+    const merged = { ...base, ...patch };
+    db.prepare("UPDATE llm_audit_logs SET metadata = ? WHERE id = ?").run(JSON.stringify(merged), id);
+    return toLlmAudit(db.prepare("SELECT * FROM llm_audit_logs WHERE id = ?").get(id));
   }
 
   function listLlmAudits({ limit = 50, offset = 0, source, sessionKey } = {}) {
@@ -2413,22 +2912,151 @@ export function createStore(path) {
    * 重跑的重复链接（否则幂等测试锁会挂）。
    * @returns {number} 实际插入行数
    */
-  function saveMemoryProvenance({ memoryId, sessionId, seqStart, seqEnd, createdAt }) {
+  function saveMemoryProvenance({ memoryId, sessionId, seqStart, seqEnd, createdAt, distillRunId }) {
+    // #512：distill_run_id 是「这条链接由哪一轮蒸馏写下」的可选归因。缺省落 NULL，
+    // 且**不回填**——存量链接没有第二轮真相可查，反推一个合成 id 比留空更坏。
     return db.prepare(
-      `INSERT INTO memory_provenance (memory_id, session_id, seq_start, seq_end, created_at)
-       VALUES (?, ?, ?, ?, ?)
+      `INSERT INTO memory_provenance (memory_id, session_id, seq_start, seq_end, created_at, distill_run_id)
+       VALUES (?, ?, ?, ?, ?, ?)
        ON CONFLICT DO NOTHING`
-    ).run(memoryId, sessionId, seqStart, seqEnd, createdAt).changes;
+    ).run(memoryId, sessionId, seqStart, seqEnd, createdAt, distillRunId ?? null).changes;
   }
 
-  /** 一条记忆的全部溯源链接（#399 面板/CLI 读取面）。 */
+  /** 一条记忆的全部溯源链接（#399 面板/CLI 读取面；#512 起带 distill_run_id）。 */
   function provenanceFor(memoryId) {
     return db.prepare(
-      `SELECT memory_id, session_id, seq_start, seq_end, created_at
+      `SELECT memory_id, session_id, seq_start, seq_end, created_at, distill_run_id
          FROM memory_provenance WHERE memory_id = ? ORDER BY created_at, session_id, seq_start`
     ).all(memoryId);
   }
 
+  /**
+   * 落盘一轮蒸馏运行（#512）。写入幂等（同 id replay 覆写、绝不重复），与
+   * saveDreamRun 同一口径，让同一逻辑轮可以重放核对。
+   *
+   * audit_id 是入参而不是在这里顺手写 audit：audit 行在 summarize.js 的 finally 里
+   * 落盘，而且**可能压根不存在**（llmAudit 关着）。run 先落、audit 后补再回填这一列，
+   * 比把两件事塞进一个事务诚实——归因不该依赖计费开关。
+   */
+  function saveDistillRun(run) {
+    const id = run.id ?? randomUUID();
+    const now = nowIso();
+    db.prepare(
+      `INSERT INTO distill_runs (id, created_at, status, error, run_type, trigger_source,
+         session_id, seq_start, seq_end, memory_count, provider, model, audit_id)
+       VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
+       ON CONFLICT(id) DO UPDATE SET
+         created_at=excluded.created_at, status=excluded.status, error=excluded.error,
+         run_type=excluded.run_type, trigger_source=excluded.trigger_source,
+         session_id=excluded.session_id, seq_start=excluded.seq_start, seq_end=excluded.seq_end,
+         memory_count=excluded.memory_count, provider=excluded.provider, model=excluded.model,
+         audit_id=excluded.audit_id`
+    ).run(
+      id,
+      run.created_at ?? now,
+      run.status,
+      run.error ?? null,
+      run.run_type,
+      run.trigger_source,
+      run.session_id ?? null,
+      Number.isInteger(run.seq_start) ? run.seq_start : null,
+      Number.isInteger(run.seq_end) ? run.seq_end : null,
+      Number.isInteger(run.memory_count) ? run.memory_count : 0,
+      run.provider ?? null,
+      run.model ?? null,
+      Number.isInteger(run.audit_id) ? run.audit_id : null
+    );
+    return getDistillRun(id);
+  }
+
+  /** #512：事后补注某一轮的开销读数 id（audit 行在 run 之后才落盘）。 */
+  function attachDistillRunAudit(id, auditId) {
+    if (!id || !Number.isInteger(auditId)) return 0;
+    return db.prepare("UPDATE distill_runs SET audit_id = ? WHERE id = ?").run(auditId, id).changes;
+  }
+
+  function getDistillRun(id) {
+    return toDistillRun(db.prepare("SELECT * FROM distill_runs WHERE id = ?").get(id));
+  }
+
+  function listDistillRuns({ limit = 50, offset = 0 } = {}) {
+    const { limit: lim, offset: off } = sanitizePage(limit, offset, 50);
+    return db.prepare(
+      "SELECT * FROM distill_runs ORDER BY created_at DESC, id LIMIT ? OFFSET ?"
+    ).all(lim, off).map(toDistillRun);
+  }
+
+  /**
+   * 记一条「这条记忆出生自哪一轮」（#512）。只记 create：既有行的改动由
+   * receipt_chain 按 (run_id, record_id) 记，两套账不能有第二份。
+   * INSERT OR IGNORE 让重放幂等——同一 run 重放不该重复记一次铸造。
+   */
+  function saveMemoryMint({ memoryId, runId, runType, triggerSource, createdAt }) {
+    if (!memoryId || !runId || !runType || !triggerSource) return 0;
+    return db.prepare(
+      `INSERT OR IGNORE INTO memory_mints (memory_id, run_id, run_type, trigger_source, created_at)
+       VALUES (?, ?, ?, ?, ?)`
+    ).run(memoryId, runId, runType, triggerSource, createdAt ?? nowIso()).changes;
+  }
+
+  /** 一条记忆的铸造记录（#512 读侧；通常 0 或 1 条，跨轮重放才会多）。 */
+  function mintsFor(memoryId) {
+    return db.prepare(
+      `SELECT memory_id, run_id, run_type, trigger_source, created_at
+         FROM memory_mints WHERE memory_id = ? ORDER BY created_at, run_id`
+    ).all(memoryId);
+  }
+
+  /**
+   * 一个 (session, seq 区间) 的蒸馏原文行（#399 写入、#421 读出口）。
+   *
+   * 按 seq 升序——原文的先后顺序就是区间顺序，乱序会让「这句从哪来」读不出来。
+   * 到期裁剪后区间可能变空，那时返回 []：链接刻意保留并指向空区间
+   * （见 clearDistillRecords 注释），面板据此显示「原文已过期」而非「没有来源」。
+   */
+  function distillRecordsFor(sessionId, seqStart, seqEnd) {
+    return db.prepare(
+      `SELECT seq, role, text, window_id, distilled_at
+         FROM distill_records
+        WHERE session_id = ? AND seq >= ? AND seq <= ?
+        ORDER BY seq`
+    ).all(sessionId, seqStart, seqEnd);
+  }
+
+  /**
+   * 一个会话产出的蒸馏窗口（#524 方向 2 的存储侧）。
+   *
+   * #421 把溯源读出口拆成两个方向：方向 1（记忆 → 窗口）由 #509 落地，走
+   * provenanceFor；这是方向 2（会话 → 窗口）。两个方向读的是同一张表，只是索引不
+   * 同（idx_memory_provenance_session 就是为这一条建的，早已存在——所以这不是
+   * schema 变更）。
+   *
+   * **必须带 limit**：一个会话可能有几十个窗口，每个窗口接着就是整段逐字原文，
+   * 不限量等于「按会话导出全量转录」（#524 第 2 条前置）。上限的口径在协议层
+   * （provenance-http.js 的 PROVENANCE_MAX_WINDOWS），这一层只照参数取。
+   *
+   * 一行 = 一个窗口（同一 (session, seq_start, seq_end) 的多条链接 GROUP BY 成一行）
+   * ——一条蒸馏窗口通常产出多条记忆，逐链接返回会让「这个会话蒸了几次」这个唯一
+   * 有意义的计数被重复行淹没。link_count 说明该窗口派生出几条记忆，是按窗口看的
+   * 第二维；**刻意不回 memory_id 列表**：方向 1 已经是「记忆 → 窗口」，把 id 也塞进
+   * 这一侧会让两个方向不再正交（同一份映射有两条读法就得有两处维护），而真要逐条
+   * 查仍是按方向 1 走。
+   *
+   * ORDER BY seq_start：seq 是事件序号，就是会话内的先后；窗口按它排才是「这个会话
+   * 按时间蒸了哪几段」，按 created_at 排会把同一批重跑的行打散。
+   */
+  function distillWindowsFor(sessionId, limit) {
+    return db.prepare(
+      `SELECT session_id, seq_start, seq_end, MIN(created_at) AS created_at,
+              COUNT(*) AS link_count
+         FROM memory_provenance
+        WHERE session_id = ?
+        GROUP BY session_id, seq_start, seq_end
+        ORDER BY seq_start, seq_end
+        LIMIT ?`
+    ).all(sessionId, limit);
+  }
+
   // --- 存储生命周期：无损回收（#275 第一批）--------------------------------
   //
   // 两项都零价值判断、零条数变化：行数不变，只把不可重建/不可达的内容丢掉。
@@ -2644,6 +3272,108 @@ export function createStore(path) {
     ).get().c;
   }
 
+  // --- differentiate adjudication ledger (issue #533) ----------------------
+
+  /**
+   * Record that the pair (a, b) has already been adjudicated as "different
+   * enough to both stay" — the differentiate decision itself. Nothing is
+   * written to either memory: #533 的复现证明「把同一段注记追加到两侧」会
+   * 把两条向量越推越近（共享后缀同向拉高余弦），所以裁决只记账、不动正文。
+   *
+   * hash_a/hash_b are the content hashes captured at adjudication time; the
+   * sleep candidate builder uses them to decide whether the verdict still
+   * stands (any later edit to either side re-opens the pair). Sorting the pair
+   * keeps one row per unordered pair, same normalization as saveConflictPending.
+   */
+  function saveDifferentiatedPair({ run_id, memory_a, memory_b, hash_a, hash_b, distinctions }) {
+    const [a, b] = [memory_a, memory_b].sort();
+    // hashes travel with their side; sort the (id, hash) tuples so hash_a
+    // always belongs to memory_a after normalization.
+    const [ha, hb] = memory_a <= memory_b ? [hash_a, hash_b] : [hash_b, hash_a];
+    db.prepare(
+      `INSERT INTO differentiated_pairs (id, memory_a, memory_b, hash_a, hash_b, distinctions, run_id, created_at)
+       VALUES (?, ?, ?, ?, ?, ?, ?, ?)
+       ON CONFLICT(memory_a, memory_b) DO UPDATE SET
+         hash_a = excluded.hash_a,
+         hash_b = excluded.hash_b,
+         distinctions = excluded.distinctions,
+         run_id = excluded.run_id,
+         created_at = excluded.created_at`
+    ).run(
+      randomUUID(), a, b, ha ?? null, hb ?? null,
+      // 没有 distinctions 就落 NULL 而不是 "[]"——空数组会被读成「判过、理由是空」，
+      // NULL 才是「这条账本行没记理由」的诚实写法（与 dream_runs.skipped 同口径）。
+      Array.isArray(distinctions) && distinctions.length ? JSON.stringify(distinctions) : null,
+      run_id ?? null, nowIso()
+    );
+    return findDifferentiatedPair(a, b);
+  }
+
+  /** The adjudication row for an unordered pair, or undefined. */
+  function findDifferentiatedPair(memory_a, memory_b) {
+    const [a, b] = [memory_a, memory_b].sort();
+    return toDifferentiatedPair(
+      db.prepare("SELECT * FROM differentiated_pairs WHERE memory_a = ? AND memory_b = ?").get(a, b)
+    );
+  }
+
+  /** Adjudicated pairs, newest first (audit view / tests). */
+  function listDifferentiatedPairs({ limit = 50, offset = 0 } = {}) {
+    const { limit: lim, offset: off } = sanitizePage(limit, offset, 50);
+    const rows = db.prepare(
+      "SELECT * FROM differentiated_pairs ORDER BY created_at DESC, id LIMIT ? OFFSET ?"
+    ).all(lim, off);
+    return rows.map(toDifferentiatedPair);
+  }
+
+  // --- conflict adjudication ledger (issue #529) ---------------------------
+
+  /**
+   * Record that the conflict phase adjudicated a pair, whatever the verdict was
+   * — including a bare "keep". This is the machine-side ledger that stops a
+   * no-op verdict from being re-sent forever; it is deliberately NOT
+   * conflict_pending (see the schema comment: that one is the human queue).
+   *
+   * 幂等靠主键：同一对（sort 归一化后）只留最新一次判决。多次写是常态——
+   * 一对被重判说明它确实值得重判，旧判决没有留存价值。
+   */
+  function saveConflictReviewed({ run_id, memory_a, memory_b, outcome, judged_at }) {
+    const [a, b] = [memory_a, memory_b].sort();
+    db.prepare(
+      `INSERT INTO conflict_reviewed (memory_a, memory_b, judged_at, outcome, run_id)
+       VALUES (?, ?, ?, ?, ?)
+       ON CONFLICT(memory_a, memory_b) DO UPDATE SET
+         judged_at = excluded.judged_at,
+         outcome   = excluded.outcome,
+         run_id    = excluded.run_id`
+    ).run(a, b, judged_at ?? nowIso(), outcome ?? null, run_id ?? null);
+  }
+
+  /**
+   * Load the ledger as a Map keyed by the normalized pair, for the conflict
+   * phase's pre-filter. Bounded by the number of distinct pairs ever judged,
+   * which is at most the number of pairs the phase can form — the same ceiling
+   * the candidate list itself has.
+   */
+  function loadConflictReviewed() {
+    const map = new Map();
+    for (const row of db.prepare("SELECT * FROM conflict_reviewed").all()) {
+      map.set(`${row.memory_a}\u0000${row.memory_b}`, {
+        judged_at: row.judged_at,
+        outcome: row.outcome ?? undefined,
+        run_id: row.run_id ?? undefined
+      });
+    }
+    return map;
+  }
+
+  /** Test/ops visibility: the raw ledger rows, newest first. */
+  function listConflictReviewed({ limit = 200 } = {}) {
+    return db.prepare(
+      "SELECT * FROM conflict_reviewed ORDER BY judged_at DESC, rowid DESC LIMIT ?"
+    ).all(Math.max(1, Math.min(5000, limit | 0)));
+  }
+
   /**
    * v0.8.1 底座（issue #170）：scope 归属人工修正的审计行。record 描述「一次
    * 决策后的完整状态」（prev_* 为改前、next_* 为改后，NULL=global/未标注），
@@ -3338,6 +4068,9 @@ export function createStore(path) {
     db,
     count,
     getById,
+    // 车道 C：外来行身份的两个读口（幂等键 / 整包清点）。
+    getByShareExternalId,
+    listBySharePackId,
     save,
     // document 唯一铸造口（#230 写入权分离）：registerDocument 专用，通用
     // save/update/CAS 均拒绝 document 创建或类型转换。
@@ -3347,6 +4080,15 @@ export function createStore(path) {
     // #254：写入准入的内容哈希候选集（只读）。
     findContentHashMatches,
     remove,
+    // 车道 C：整包退出（幂等批删，side table 口径同 remove()）。
+    deleteBySharePackId,
+    // 只管 SQLite 回滚的存储层原语（本文件每个写方法都在用它，这里只是对外露一层：
+    // 外层已开着事务时它直接执行回调，db.isTransaction 早退，嵌套不会二次 BEGIN）。
+    // **它不是导入口**：车道 C 的导入走 service.transaction()——那层除回滚外还会随
+    // ROLLBACK 截断 pendingEmbed / pendingEntity，用这个裸原语导入会让队列和库分叉。
+    // 露出的用途是存储级批写与用例：C1 的 UNIQUE 撞库用例（test/share-store.test.js）
+    // 就靠它把「撞一条、整批不落」这条 ROLLBACK 路径直接命中。
+    runAtomically,
     setForget,
     setArchived,
     touchLastAccess,
@@ -3355,6 +4097,9 @@ export function createStore(path) {
     getUnrecalledSince,
     list,
     all,
+    // Issue #505：写路径去重的定向候选（按 type + TRIM(title) 精确取活跃行），
+    // 替代「importance 前 N 条」那个会随库增长失效的窗口。
+    activeByTypeAndTitle,
     // #430：有界单列读，写路径（质量过滤）用。
     recentContents,
     search,
@@ -3367,6 +4112,7 @@ export function createStore(path) {
     hasStaleEmbedding,
     embeddingModelBreakdown,
     embeddingDimensionBreakdown,
+    vectorDimensionState,
     searchVector,
     saveDreamRun,
     lastDreamRunAt,
@@ -3386,8 +4132,14 @@ export function createStore(path) {
     getRecallEval,
     listRecallEvals,
     saveLlmAudit,
+    annotateLlmAudit,
     getDistillCursor,
     setDistillCursor,
+    // #493 补充 §②：解析失败计数跨进程持久化（读侧带失效窗口）。单独成表，
+    // 不并进 distill_cursors——那句 UPSERT 是单调的，归零语义会打架。
+    getDistillParseFailureStreak,
+    bumpDistillParseFailureStreak,
+    clearDistillParseFailureStreak,
     listLlmAudits,
     countLlmAudits,
     getLlmAuditStats,
@@ -3398,6 +4150,16 @@ export function createStore(path) {
     clearDistillRecords,
     saveMemoryProvenance,
     provenanceFor,
+    distillRecordsFor,
+    distillWindowsFor,
+    // #512 蒸馏运行与铸造归因：run 是归因主体，audit 行只是它的开销读数。
+    // 写入幂等（replay 覆写），读侧只读——两处都不触发 write hooks（bookkeeping）。
+    saveDistillRun,
+    attachDistillRunAudit,
+    getDistillRun,
+    listDistillRuns,
+    saveMemoryMint,
+    mintsFor,
     // 存储生命周期（#275 第一批）：无损回收的统计、清理与体积口径。
     dreamRunInputStats,
     clearDreamRunInputs,
@@ -3413,6 +4175,13 @@ export function createStore(path) {
     listConflictPending,
     resolveConflictPending,
     countConflictPending,
+    saveDifferentiatedPair,
+    findDifferentiatedPair,
+    listDifferentiatedPairs,
+    // #529：机器侧裁决台账（与上面四条人工队列的函数刻意分开，见 schema 注释）。
+    saveConflictReviewed,
+    loadConflictReviewed,
+    listConflictReviewed,
     saveScopeChange,
     listScopeChanges,
     // 政策轴（issue #471）：按下/松开一个作用域。纯 bookkeeping，不调