Repository navigation
[feature] distill_records 只有写入路径：给「这条记忆是哪次蒸馏带进来的」一个读出口 #421
Description
要解决的问题
PR #417 按 #399 的约定把蒸馏窗口的原始记录落进了 distill_records，并把 memory → (session_id, seq_start, seq_end) 的归因写进 memory_provenance。但那次只做了写：没有任何读路径 —— 面板不显示、API 没有端点、service 没有查询方法。结果是这批数据只进不出：它占了库、进了回收面，却没人能看见。
具体场景：一条记忆的来源可疑（内容与原文对不上，或需要确认它到底是从哪几句里蒸出来的），现在唯一的办法是直接开 sqlite 手写 JOIN。而 #399 里「我们测不出自己丢了多少」这个目标，恰恰要靠读出口才成立。
期望的方案
给一个最小读出口，两个方向：
- 按记忆看窗口：给定
memory_id，返回它在memory_provenance里的区间[(session_id, seq_start, seq_end)]，再按区间取出distill_records的原文行。 - 按会话看窗口：给定
session_id，列出该会话所有已留存的窗口（按 seq 升序）。
形态上倾向先走 GET /api/dsh-mneme/memory/provenance?memoryId=（面板与外部 API 同一份实现）；面板侧挂在哪里由维护者定。distillRecords.enabled=false 时按既有习惯返回空或 404，依附既有开关，不新增。上面两条是形态建议，不是实现要求。
考虑过的替代方案
- 直接暴露
distill_records全表（连text一起）：数据面积与敏感度最大，且没有解决「从记忆回去」这个真实入口，先不做。 - 面板只显示条数、不返回原文：判断不了「原文里到底有没有这句话」，等于没解决 [feature] 蒸馏窗口原始记录留存 + 记忆级溯源：把蒸馏从「替换」降级为「叠加索引」 #399 的原始目标。
实现口径确认 / Implementation gates
- 新行为开关 opt-in 默认关（本提案依附既有
distillRecords.enabled，不新增开关） - 无 schema 变更（只读既有两张表，无需迁移）
- 接受带回归测试的验收线
披露 / Disclosure
- 本提案由 AI 辅助整理（人工审核后提交）
Activity
modusensus commentedon Oct 20, 2026
现状（2026-10-21 对照
main实测）读方法已经有了，但没有 HTTP 出口——差最后一段接线。
dsh-mneme/src/service.js:2600：provenanceFor: (memoryId) => store.provenanceFor(memoryId)—— 方法存在（随 [feature] 蒸馏窗口原始记录留存 + 记忆级溯源：把蒸馏从「替换」降级为「叠加索引」 #399 落地，写+读都有）。dsh-mneme/src/api.js：memory/provenance路由 0 命中；distill_records在api.js里 0 命中。所以现在「这条记忆是哪次蒸馏带进来的」在库里有答案、在代码里能查，但外部（面板、standalone API、脚本）拿不到。
还缺什么
api.js与api-standalone.js各加一条只读路由（建议GET /api/dsh-mneme/memory/provenance?id=<id>），响应至少含distill_run_id/run_type/created_at/trigger_source；dream写入的记忆断言distill_run_id非空，对一条memory_save写入的断言为null（而不是报错）。接手建议
这是纯出口的活：
service.js不用改，只加路由 + 面板一行。没有设计分歧，可以直接提 PR。