feat(api): distill_records 补 HTTP 读出口，记忆溯源可查（#421） - #509

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: slow-stack/mneme
• Branch: main
• File: .coderabbit.yaml
• Commit: 3ee88da
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: c00802cf-433b-4c90-b7c7-cd8cc604dc82

Commits

Reviewing files that changed from the base of the PR and between 3bf0ed7 and 52723c6.

Files selected for processing: 22

• SECURITY.md
• dsh-mneme/README.md
• dsh-mneme/docs/CONFIGURATION.md
• dsh-mneme/docs/DAEMON.md
• dsh-mneme/docs/DISTILL.md
• dsh-mneme/docs/STORAGE.md
• dsh-mneme/lib/api-standalone.js
• dsh-mneme/lib/api.js
• dsh-mneme/lib/provenance-http.js
• dsh-mneme/lib/serve.js
• dsh-mneme/lib/service.js
• dsh-mneme/lib/store.js
• dsh-mneme/src/api-standalone.js
• dsh-mneme/src/api.js
• dsh-mneme/src/provenance-http.js
• dsh-mneme/src/serve.js
• dsh-mneme/src/service.js
• dsh-mneme/src/store.js
• dsh-mneme/test/api.test.js
• dsh-mneme/test/provenance-http.test.js
• dsh-mneme/test/serve.test.js
• dsh-mneme/test/standalone-api.test.js

Files skipped from review as they are similar to previous changes: 1

• SECURITY.md

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

Merge Risk: Minimal · previous review 52723

The provenance read paths and their documented access rules have no identified merge-blocking issue. Merge after normal checks.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		标题“feat(api): distill_records 补 HTTP 读出口，记忆溯源可查（#421）”与变更内容一致。变更新增了 GET /api/dsh-mneme/memory/provenance 与 GET /memory/provenance 两个只读 HTTP 出口，并通过 distillRecords.enabled 门控。标题点明了主要变更：为 distill_records…
Docstring Coverage		Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentati…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

标题“feat(api): distill_records 补 HTTP 读出口，记忆溯源可查（#421）”与变更内容一致。变更新增了 GET /api/dsh-mneme/memory/provenance 与 GET /memory/provenance 两个只读 HTTP 出口，并通过 distillRecords.enabled 门控。标题点明了主要变更：为 distill_records 增加 HTTP 读出口，使记忆溯源可查。标题简短，使用了 conventional commit 格式，没有文件清单或模糊用语。

Full details: Docstring Coverage

Explanation

Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 15 functions across 16 files. (6 skipped: 6 unsupported.)

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

先谢谢在 #421 下的认领与清单——四个问题，都是口径核对，不是质疑实现质量。

1（最想要答案的）：响应里带了会话原文，那 policy: "open" 还成立吗？
留言里写的响应是 distill_run_id / run_type / created_at / trigger_source 四个元数据键，实现里是
{ memoryId, windows: [{ session_id, seq_start, seq_end, created_at, records: [{ seq, role, text, window_id, distilled_at }] }] }
——多出来的 records 是蒸馏窗口内的逐条原文。按「只读元数据」定 open 是一回事，按「能按 id 取回原文」定 open 是另一回事：/list 同样是 open 且逐条带 id，所以任何一个本地进程（或跑在宿主同源页面里的脚本）可以先枚举 id、再逐条把这些原文捞回去。本仓 2026-10 审计之后把 /export（一次拿全库）列成了 gated 读，这条链路的可达结果与它同量级，只是换了形状。

两个结局我都能接受，请挑一个：① 改 policy: "token"；② 保持 open，但在 SECURITY.md 的开放读那一节写出这条界线由什么守住（回环 + 宿主 Origin 校验只防 DNS rebinding 与跨站，它不建立身份——这是仓里已经写明的事实）。现在只是把它列进清单，读者会以为归类是笔误。
如果 records 不是有意加进来的，那就更简单：去掉它，问题消失。

2：#421 问的那个问题这条路由还没答上。
「这条记忆是哪次蒸馏带进来的、什么类型、被谁触发」对应的是 distill_run_id / run_type / trigger_source，这三个键在实现里没有。所以我打算先不把 #421 关联到这条 PR（原文区间是另一件有用的事，不是那件）。你补键还是要我把它拆成第二条 issue？

3：两张皮各写了一份答复代码。
src/api.js 与 src/api-standalone.js 里那段「查链接 → 每条补 records → 区间被裁剪后仍保留空链接」是逐字两份，你留言里也写了「各加一条」。本仓在 #411 之后不收这个形状：reclaim 有 src/reclaim-http.js、分享包有 src/share-http.js，一张面一份薄壳、判据与答复只有一份。能抽 src/provenance-http.js 吗？（复制出去的那份不会留痕迹，只有静态断言抓得住，所以我们给这类共用层都配了一把跨面锁。）

4：?? [] 把两种「空」压成了一个读数。
service.provenanceFor?.(id) ?? [] 与 distillRecordsFor?.(...) ?? [] 在「这个装配根本没有该方法」（headless / 旧装配）和「这条记忆确实没有来源」两种情况下返回同一份 JSON。后者是事实，前者是接线坏了——后者是不是该回 503（仓里有 SHARE_IMPORT_UNAVAILABLE 那种现成形状）？

两条背景，与这条 PR 无关：CI 的测试矩阵这次没跑全（只 1 项有结果），我本地跑了 npm test = 2309 tests / 2308 pass / 0 fail / 1 skipped，绿的；CHANGELOG 该不该由 PR 补是我们仓内的约定问题（#503/#504 补了、#506–#509 没补），我先记着，不要求你改。

#507 / #508 的 CI 已经放行并全绿了，#509 的两个 run 还停在 action_required。如果是同一个批准门，麻烦一并点掉；如果是别的原因，我按需配合。本地已全量验证（2309 passed）。

四条都采纳，已在同一分支追加 commit（#509 已更新）：

1 → 选 ① 改 policy: "token"，同时把中英两份 SECURITY.md 都从开放读移入受门控，并写出界线（records 是蒸馏窗口逐字原文，与开放的路由串起来可枚举 id 后捞回，与 /export 同量级）。records 是有意加的——它是「这条记忆从哪几句蒸出来的」的答案本身，去掉这个端点就只剩区间、没有原文，#421 的原始目标（以及 issue 正文的「再按区间取出 distill_records 的原文行」）就没兑现。

2 → 倾向你拆成第二条 issue。 我核过：distill_run_id / run_type / trigger_source 三键全仓 grep 零命中，根因是 autoSummarize 没有 dream_runs 那样的 run 概念——归因只由 summarize.js:1021 写入，带的是 {memoryId, sessionId, seqStart, seqEnd, createdAt}。补键要改 schema + 写入路径 + 回填，那不是「纯出口」。所以本 PR 缩回只交付「区间 + 原文」，#421 等那三个键真正有着落时再关。这条等你拍板：如果你希望我补键，我另开一条做。

3 → 已抽 src/provenance-http.js，照 reclaim-http.js / share-http.js 的形状，两个入口都调 parseProvenanceQuery + provenanceReply。配了静态锁 test/provenance-http.test.js：口径字面量与共用答复只许出现在该模块，两个入口都必须真的走它——谁再复制一段出去，那里直接转红。

4 → 改 503 provenance-unavailable，与 RECLAIM_UNAVAILABLE 同构，且顺序上 503 赢过空结果。「没有链接」仍是 200 + 空 windows（那是事实），「装配没接线」是 503（那是接线坏了）。

另：CHANGELOG 按你说的不补；CI 矩阵我这边看到 #509 仍卡 action_required，已另发一条提醒。

顺带一提，抽模块时 security-doc.test.js 抓了我一个错：我把 /list 写进了受门控那句的解释里（带反引号），routesInBullet 把它当成路由声明，双向比对转红。已改成不带反引号的表述。这条测试挺护着人的。

Codecov Report

❌ Patch coverage is 99.15966% with 2 lines in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

四条都办了（见上一条回复），另有一条 CodeRabbit 在我 rework 之后新点的，一并修了：

src/api.js:1326 的 warn 回调递错了 logger。 壳里写的是裸 logger，而 createApi 的作用域只有 ctx.logger（同文件另外三处都是 ctx.logger，就我这一处漏了）。provenanceFor 抛错时回调自己抛 ReferenceError，被外层 catch 吞掉——响应仍是 500 internal，但「为什么失败」一个字都不进日志。

provenance-http.test.js 已经锁了「抛错 → 调 warn」，但锁不住壳把哪个 logger 递进去，所以补了 test/api.test.js 一条：读失败必须伴随一条 warn 且带原始异常。已验红→绿（把 ctx.logger 改回裸 logger，该条转红）。api-standalone.js:432 那边没这个问题——那里的 logger 是 createStandaloneApi 的解构参数。

本地全量：2317 passed / 0 failed，npm run sync 77 文件 parity，git diff --check 干净。三个 PR 的 CI 现在都全绿了（#509 之前卡的 action_required 已解除）。

第 2 点（distill_run_id / run_type / trigger_source 三键，还是你拆成第二条 issue）仍等你拍板。

先更正我上一条里的第 2 点——那条问反了，向你道歉。

我去翻了 #421 的原文：「期望的方案 · 方向 1」写的就是「给定 memory_id，返回它在 memory_provenance 里的区间，再按区间取出 distill_records 的原文行」，而「考虑过的替代方案」里明确把「只显示条数、不返回原文」判成「判断不了『原文里到底有没有这句话』，等于没解决 #399 的原始目标」。所以 records 带原文正是这条 issue 要的，不是超范围。我拿你 PR 留言里那句「响应含 distill_run_id / run_type / trigger_source」当成了需求，而那段是你自己写的范围，跟 issue 不一致——要按留言做反而会做成 issue 拒绝过的那个形状。三个溯源键不是这条 PR 的欠账。

新提交里那三条我也确认了：policy: "token" ✓；src/provenance-http.js 抽出来了，「503 要赢过空结果」与 maintenance-unavailable 同构这句写得对 ✓；?? [] 那种「两种空压成一个读数」修了 ✓。CI 矩阵这次也跑全了。

剩一条真缺的：这条读出口没依附 distillRecords.enabled

#421 的「实现口径确认」第一条勾的是「本提案依附既有 distillRecords.enabled，不新增开关」，正文那句是「distillRecords.enabled=false 时按既有习惯返回空或 404」。现在整棵树里行为性地读这个开关的只有两处——src/index.js:270 与 src/summarize.js:988；provenance-http.js → service.distillRecordsFor → store.distillRecordsFor 这一条链上没有任何一处读它（api.js:253 那一行是设置键到路径的映射表，不是门）。

而且关掉开关的实际效果比「读得到」更远一点：保留期裁剪和写入在同一道门里（src/index.js:270 那个 if (cfg.distillRecords?.enabled === true) 里跑 clearDistillRecords）。所以「把 distill_records 关掉」目前的语义是不再写、也永久不再删，再叠上这条 PR 就是——用户以为自己关掉了的功能，历史原文既留在库里、又多了一个能读出去的口。

两种收法都行，挑一种：

1. 读路径也吃这个开关：enabled !== true 时按 issue 的原话给空 windows 或 404（我们仓里 SHARE_IMPORT_UNAVAILABLE / maintenance-unavailable 这类「装配/能力没接」的码有先例，但这次语义是「用户关了」，我倾向空 windows + 一个说明性的键，或者 404 带 {error:"distill-records-disabled"}，别回 503——503 会说成服务端坏了）；
2. 或者你在 [feature] distill_records 只有写入路径：给「这条记忆是哪次蒸馏带进来的」一个读出口 #421 里改那句口径并写清为什么关了还能读（如果结论是「原文本来就在本机库里，读出口只是把它摆出来，开关不该管读」，那是个站得住的理由，但它得写在 issue 上，不然下一个人会以为这一格兑现了）。

方向 2（按 session_id 列窗口）不算你的欠账——issue 里写了那是形态建议不是实现要求，我会另开一条跟这条分开。

补一句 codecov 的读数：#509 这次 patch 覆盖是 pass，我这边没有覆盖缺口要提。

先说结论：这条现在离 main 有 7 处冲突 / 13 个文件（SECURITY.md、src/api.js、src/api-standalone.js、src/service.js、src/store.js 及它们的 lib/ 镜像、test/standalone-api.test.js）。其中一处不是机械活：

• src/service.js 的 saveWithDedupe 汇流口那一行，main 上已经挂外来行谓词（store.list({ type, limit: 100 }).filter((m) => !isImportedRow(m))）。把这行整句改写掉的那类改动，我们今天在 fix(dedupe): candidates were the type's top-100 by importance, not the same-title rows #506 上刚撞到同一个位置并合进去了——解法是两个候选集都挂谓词，只挂一个等于给「本机巩固改写别人导入的原文」留后门；test/share-imported-guard.test.js 的 SERVICE_SITES 锁的是这个字面量，漏挂当场红。参考即可，你的分支里未必撞到同一段。
• lib/ 是 sync 产物，解完 src/ 跑一次 npm run sync，别手改。

merge 当前 main 进来就行，不用 rebase——我们收 merge commit。

还欠一个答案，也是这条 PR 唯一真正悬着的一件事（上一条里标的「剩一条真缺的」）：这条读出口要不要依附 distillRecords.enabled，两种收法挑一种。你不认同我读法的话，指出我错在哪一步也行——我去翻 #421 原文那次就是这么翻错的。

关于 CI：两个 run 停在 action_required 不是漏点。在维护者的 runner 上跑第三方代码是我们这边的决定，不是默认放行，所以之前 #507/#508 放行的是那两条的形状没问题、不是给所有 fork 开门。你 rebase 完在这条下 @ 我们一下，我们会点掉这一轮。

时间上我不想让这条无声无息地烂在这儿：11 月 5 日之前没有动静，我们就关掉这条、按 #421 自己实现那一格（读路径的开关归属与跨面共用层已经在上一条说清，不需要你再同意），并在提交里写明这几条发现来自你在 #421 的认领与清单。你现在这版里已经做对的三条（policy: "token"、src/provenance-http.js、503 赢过空结果）我们会照单收下，不会因为换成我们写就当没发生过。

你指出的缺口我核实过，全部为真，已实现并推送（#509 已更新）。先说三件我做错/漏了的事，再说实现。

我原来的方案错在哪（都是你这条评论逼出来的）

状态码我选错了，应该是 409 不是 404。 我给 404 找的依据是「错误码进 body 仓里有先例」和 issue 原文那句「空或 404」——两条都不成立：provenance-unavailable、SHARE_IMPORT_UNAVAILABLE 都是 503，missing-id 是 400，没有一条是「用户关了」的 4xx；而 issue 那句自带「上面两条是形态建议，不是实现要求」，已勾的只有「依附既有开关、不新增开关」。

仓里唯一同型先例就在 src/api.js:525：

if (config?.profileExtractEnabled !== true) return sendJson(res, 409, { error: "disabled" });
if (typeof profileExtract !== "function")      return sendJson(res, 503, { error: "unavailable" });

而 src/index.js:589-591 把理由写成了原话：「503 unavailable 只该出现在旧宿主/装配缺失上，不该被读成「用户没开」」。更关键的是这条端点被明确设计成永远不出 404——provenance-http.js 与 api.js 的注释都写着「读端点不替调用方判断记忆是否存在」，缺 id 是 400、未知 id 是 200 + 空 windows。把「功能关了」塞进 404，等于在状态码这个唯一被代理/监控/重试逻辑读取的通道上，让它读成「这条记忆不存在」——那正是我想避免的误读，只是从 body 挪到了状态码。

所以现在是 409 {"error":"distill-records-disabled"}。这是对你字面建议的偏离，想听你一句确认。 你没提 409，我猜是因为没想起 #497 那条先例——如果你要 404，我改，但那需要同时接受「本端点从此会 404」这个不变量被打破。

我的测试判断是假的。 我写「enabled===true → 既有用例即覆盖，确认没被改坏」——实际上三处夹具全都拿不到 enabled: true（api.test.js 的 setup 默认 config=null、provenance-http.test.js 4 条直调不传、standalone-api.test.js 的 setup 默认 {}），11 条既有用例会直接转红。已经全部换成显式夹具。

我的文档前提也是假的。 我说「README 路由表里那行要补 404」——实际全仓 grep，README 主要路由表和 docs/DAEMON.md 的路由面枚举里从来没有 /memory/provenance 这一行。#421 加路由的那次 PR 没写文档。所以这是从零新增，不是改一行。

实现

判据只在共用模块出现一次，isDistillRecordsEnabled(config)，函数体就是 config?.distillRecords?.enabled === true，与 src/summarize.js:988 逐字同源。两个壳只转发 config。我原方案写的是「壳算好布尔量传进来」，那会让判据变成第 4、第 5 份拷贝——正是 #411 要消灭的形状，所以改了。静态锁扩成四条：口径字面量、开关判据、config 转交、读写判据逐字同源（最后一条让「永不分歧」从注释变成可验证的）。

daemon 那一格我加了 src/serve.js。 这是你这条评论我没料到的部分：daemon 的 cfg 是刻意的最小集 { language, "zh", documentMemoryEnabled: false }，与宿主共用同一个 memory.db。按我原方案落地后，dsh-mneme-serve 的 /memory/provenance 会对每个请求永久回「功能关了」——包括那些在面板里开着开关、库里明明有活跃原文的用户。那个错误码在这种情况下是不实陈述（用户没关，是 daemon 不知道这个键）。现在把面板持久化的 distillRecords.enabled 展开进 cfg，index.js:217-233 同款展开，只取蒸馏这一组，daemon 其余键仍刻意不吃宿主 config schema。

残留不对称，写进文档了没修：只靠 bundle 配置打开、从没在面板点过的用户，宿主认、daemon 不认——daemon 结构上看不到宿主的 bundle config，这是它看不见的那一半。docs/DAEMON.md 与 serve.js 注释都写了。

状态码阶梯：401 → 400 缺 id → 409 功能关了 → 503 装配没接线 → 读。409 赢 503 的理由与你给的顺序一致（更具体的赢）；400 最前是因为缺 id 是语法畸形、与服务端状态无关，与 reclaim 的 invalid-json 同档——但我在注释里标了警告：将来要加语义类 400（如 limit 越界）必须挪到接线检查之后，因为 reclaim 立的口径正是「503 要赢过字段校验的 400」。

测试：18 条新增 + 11 条既有换夹具。新增覆盖 409 单键 body、409 赢 503、400 赢 409、关着时已知/未知 id 同答（不当存在性预言机）、关着时一次 SQL 都不发、lightMode 预设 → 409、daemon 级两条（面板开着读得到 / 从没设过 → 409）。已验红→green 三轮：门强制打开 16 红、壳不转发 config 6 红、拆掉 400 闸 5 红——失败全是断言失败，没有一次是编译失败。

文档（都是新增）：README 主要路由表新增该端点一行（状态码阶梯 + 启动快照语义 + 「关 ≠ 删」）；README 安全段敏感读清单补上它；docs/DAEMON.md §2 路由面枚举补该端点 + 专段讲开关门与 daemon 不对称；docs/DISTILL.md 新增 §10「读出口」，含「为什么不是 404」；docs/CONFIGURATION.md 的 distillRecords.enabled 行补读写两侧同门；docs/STORAGE.md 修掉「只在 enabled=true 时才有行」的绝对化说法——曾经开过再关的库有行。

本地全量 2515 passed / 0 failed，check-sync 81 文件一致。

两件必须说清的残留

1. 你复合指控的后半「永久不再删」，我只文档化、没修。 保留期裁剪与写入仍在 index.js:270 同一道门里，所以关开关之后的完整语义是：不再写、启动期也不再裁、已留的原文永久冻在盘上。任何能摸到 memory.db 的进程仍可读，dsh-mneme reclaim 仍能清（maintenance.js 不读这个键）。诚实的表述是「关 = 不再经 HTTP 提供」，不是「关 = 删掉」——这句话写进了 README / DISTILL.md §10 / CONFIGURATION.md / STORAGE.md 四处。真正的修法（retentionDays 有值就裁、无论 enabled）超出了这条 PR 的范围，DISTILL.md §10 记成了后续项。顺带一提，index.js:265-268 给「裁剪也吃开关」的性能理由（空表被每次启动扫一遍）只在表为空时成立，而那正是「先开后关」场景的反面。

2. 开关是启动快照，不是活配置。 cfg 在启动期冻结（index.js:209-231 明写「合并结果只作用于本次启动」），所以用户在面板关掉开关后，读出口要到下次重启才 409，写侧同样到重启才停写。缓解是现成的：该键在 settings 白名单与 NESTED_FLAG_PATHS 里都登记着，面板会显示「待重启」（#481 的教训）。这个语义写进了端点文档——不写的话，等于把 #481 换了个端点重演。

另外

SECURITY.md 我没有改。两个原因：一是我核到它已经写对了（英文「/memory/provenance is gated because it returns the verbatim raw text … opt-in via distillRecords.enabled」、中文「distillRecords.enabled 打开才有」），所以收法 1 是让代码追上已发布的安全模型，收法 2 反而会让代码与它矛盾；二是它在本工作树之外（仓库根的控制区），按我的纪律不擅动。但我发现它有两份逐字重复的「受门控路由」清单，旧那份（「五条读」）里没有 /memory/provenance，而 security-doc.test.js 的 bullet() 用 .find() 只校验第一份——那份陈旧副本没有任何测试在看，现在会变成一句明确的谎话。要我删掉那两行吗？ 它在控制区，需要你授权。

409 收下，你是对的。 我去核了你搬来的三处，全部逐字命中：

• src/api.js:525-526：profileExtractEnabled !== true → 409 disabled / typeof profileExtract !== "function" → 503 unavailable，同一对语义；
• src/index.js:589-591：「503 unavailable 只该出现在旧宿主/装配缺失上，不该被读成「用户没开」」——你要的就是这句话的反面被守住；
• src/provenance-http.js:81：「读端点不替调用方判断记忆是否存在」。把「功能关了」写成 404，等于让代理/监控在唯一它读的那个通道上读成「这条记忆不存在」。

我给 404 是照着 #421 那句「空或 404」说的，而那句和方向 2 一样在「形态建议」格里，已勾的只有「依附既有开关、不新增开关」。issue 那句我去更正，不用你动。distill-records-disabled 这个码也比裸 disabled 好——同一状态码在不同端点上含义不同，读日志的人不该猜。

判据那份实现我也核了：isDistillRecordsEnabled 的函数体与 src/summarize.js:988 同表达式，test/provenance-http.test.js:170 那条「读写判据逐字同源」的静态锁是真的。你说「壳算好布尔传进来会变成第 4、第 5 份拷贝」——这个自我否决正是 #411 想要的判断，不用再解释一遍。

那对重复清单不是仓里的旧账，是你这次 merge 带进来的

3bf0ed7（你 merge main 之前）   - **Gated routes: 1 条    - **Open reads: 1 条
b5c0b09 Merge upstream/main     - **Gated routes: 2 条    - **Open reads: 2 条
52723c6（当前）                 同上

两份 Open reads 逐字相同（各 1065 字符）；两份 Gated routes 不同：第一份含 /memory/provenance，第二份不含、也没有任何独有内容（严格子集）。所以留 156-157 那一对，把 158-159 整块删掉就行，不需要额外授权——SECURITY.md 就在你 PR 的文件里，它不是控制区外的东西。

但它暴露的是我们的缺陷，已经开 issue 自己修

test/security-doc.test.js:107-111 的 bullet() 用 .find()，只读第一条命中——重复出来的第二份副本结构上不可见。我们把「清单只许有一份」立成纪律（#411 那条「两张皮只许剩鉴权与路径不同」），守卫却只看第一份，所以任何把 SECURITY.md 解成「两边都要」的 merge 都会静默留下一份没人看的过期清单。

→ #523（含变异自证验收：故意复制一份清单必须红，两份内容不同也必须红）。这条测试你别动，免得我们两边改同一个文件打架——你的 PR 只管删自己那对重复，锁的加固走 #523。

还剩一步机械的

再 merge 一次当前 main（428f98a，#503/#504/#506 都进去了）。我拿当前 main 试算过：0 处冲突——#506 把汇流口那行改成了 store.activeByTypeAndTitle(...).filter((m) => !isImportedRow(m))，而你分支里那行旧候选从 merge base 起没被动过，所以 main 的版本干净胜出，合并后外来谓词仍是两处。CI 这轮已经真跑且全绿，谢谢。

两处残留我认可你现在的收法

1. 「关 = 不再经 HTTP 提供，不是关 = 删掉」这句比我原本期待的一个「修」更诚实，写进四处文档是对的。retention 裁剪与写入同门那件事超出本 PR，我不塞进来——但我会把它记在自己的账上，不烂在你 PR 描述里。你顺手指出 index.js:265-268 那条性能理由只在空表成立，这一眼是对的，我记下了。
2. 启动快照语义 + 面板「待重启」的缓解，正是 fix(embed): embedText 静默失败改带可区分 reason #481 那条教训该有的形状。

期限作废（你当天就答完了）。删掉那两行、再 merge 一次 main 之后在这条下说一声，我们就把它合进去。

补一条不那么「工单」的话：这次真的谢谢你，而且有几件事你做得比我们要的多。

• 你推翻了我的建议，而且推翻得对。 409 那一手不是「选了个不同的码」——你先去找仓里有没有同型先例（api.js:525-526），再核注释里那句原话（index.js:589-591），再回头看这条端点自己承诺过什么（不出 404），最后才落到「状态码是唯一被代理/监控/重试读取的通道」这一层。我给 404 是照 [feature] distill_records 只有写入路径：给「这条记忆是哪次蒸馏带进来的」一个读出口 #421 那句话抄的，你查的是那句话本身成不成立。判断归我，但流程归你。
• 三条自我更正不是我们要求的。 「我的测试判断是假的」「我的文档前提也是假的」「状态码我选错了」——这三句每一条都省下我们一轮返工，而且写出来的时候没有人会追问。特别是「11 条既有用例其实全都拿不到 enabled: true」这一句：如果你不说，我们会带着一条假的绿灯合进去。
• daemon 那一格是我评论里没料到的。 按我原话落地之后，dsh-mneme-serve 会对每个请求报「功能关了」，而用户其实开着、库里也有活跃原文——那种错误码是不实陈述，不是保守。你把它从「读不到」纠正成「读错了」，这是范围外的贡献。
• 「关 = 不再经 HTTP 提供，不是关 = 删掉」 这句表述比我原本期待的「顺手修 retention」更值钱：它把语义说准了，而文档里说准的语义不会过期。

#523 那条缺陷是你撞出来的（你的合并损伤只是让它现形，问题本来就在我们的守卫里），我们已经自己认领：加固 bullet()，配变异自证。那个测试文件你别碰，免得我们两边同时改它打架。

#421 正文那句「空或 404」我也按你的论证原地更正了，原措辞留在括号里，读者不会再被那句误导。

还差两件机械的就合：

1. 删掉 SECURITY.md 里 158-159 那一整块（你自己 merge 带进来的重复对；156-157 那份是新的，含 /memory/provenance）；
2. 再 merge 一次当前 main——现在是 c1c4087（fix(dream): merge 护栏与 archive 护栏对齐，提示词补上 merge 类型禁区（#521） #522 也进去了）。我刚用你的当前 head 试算过：与 main 0 处冲突，fix(dedupe): candidates were the type's top-100 by importance, not the same-title rows #506 那次汇流口改动会干净胜出，合完外来谓词仍是两处。

推完在这条下说一声就行，CI 我们已经看过一轮全绿了。

已合入 main：6a05618。 谢谢你把这条做完——尤其是 409 那一手，你查先例、核注释原话、再回头看这条端点自己承诺过什么，最后才推翻我给的建议，这个流程比我们收到的一切结论都值钱。

为了今天合进去，我替你把两件机械的做了（提交署名是我，实现与判断都是你的）：

• 02f06fd 并上当前 main（c1c4087）。0 处冲突；fix(dedupe): candidates were the type's top-100 by importance, not the same-title rows #506 那次汇流口改动干净胜出，合完外来谓词仍是两处。
• b1491ff 删掉 SECURITY.md 里那次 merge 复制出来的 Open reads + 旧 Gated routes 那一块，留下含 /memory/provenance 的那一份。守卫为什么没抓到它、以及我们自己要怎么加固，全在 [bug] security-doc.test.js 的 bullet() 只校验第一条命中：SECURITY.md 里重复出来的路由清单副本对守卫隐形（#509 撞到） #523，不占你的时间。
• 12a58f1 补了一条 CHANGELOG 的 Unreleased 条目（新路由的 PR 自带条目这条约定，今天起算定下来了）。

本地验证：全量 npm test = 2541 tests / 2540 pass / 0 fail / 1 skipped，check-sync ✓ 81 文件，security-doc 6/6；CI 这一轮批准跑完也是全绿（ubuntu + windows × 22/24、两条 host-legacy、gitleaks / dependency-review / CodeRabbit / codecov）。

两件后续都归我们，不用你跟：#421 的方向 2（按 session_id 列窗口）已经另开 #524，因为 #509 落的是方向 1，那条也随 #509 的合入关掉；「关而不删」那条 retention 语义我接在自己账上。