[Feature] 写入准入（non-write 判定）：把「这条该不该进库」前移到 LLM 之前

[modusensus]

背景

2608.22215（Dual-Layer）的映射条目指出我们缺一块机制：写入准入。

现状核对：

现有	位置	性质
saveWithDedupe	src/service.js	只有 write-new / write-update 两分支——默认「都写」
quality-filter	src/quality-filter.js	写入后评分再归档，不是写入前拒绝
密钥/PII 扫描	#164 A2（未实现）	属于同一设计词的一类判据

从成本视角看这件事更清楚：#239 的第 1 项在蒸馏前拦窗口，省的是那次调用的输入；而写入准入是在更上游决定「这条根本不该进库」，省掉的是后续所有环节（写入、抽取、巩固、注入槽位、检索噪声）。量级可能大于窗口级预判。

方案

三级判定，全部留审计，默认关：

1. 确定性拒绝（零 LLM）：密钥/PII 模式命中（与 聊几个我觉得值得做的方向 #164 A2 合流——A2 是本级的一类判据而不是另起一套）、空白或纯噪声、命中已有条目的去重键；
2. 规则放行（零 LLM）：显式高价值信号（importance 显式给出、用户偏好陈述、决策动词 + 实体）；
3. 不确定 → 交 LLM：维持现状路径。

每次判定写一条准入决策回执（拒绝/放行/升级 + 原因），沿用 llm_audit_logs 的 skip 口径，使「这条为什么没进库」可查。

验收

• 默认关：零行为变化（默认路径逐字节一致）
• 开启后被拒绝的写入有审计与明确原因，且可解释（不是静默丢弃）
• 密钥/隐私样例不漏放（配回归样本集，聊几个我觉得值得做的方向 #164 A2 复用同一套）
• 与 聊几个我觉得值得做的方向 #164 A2 的关系写清楚：A2 是第 1 级的判据来源，不是并列的第二个机制
• 新配置键按 config.js schema + settings.js 白名单成对出现，旗标计数锁同步

参考

• 2608.22215（Dual-Layer Agentic Memory with Fast Write Routing and Slow Consolidation）——其"路由三分类 non-write / write-new / write-update"正是在说写入准入；我们的 saveWithDedupe 只实现了后两类
• 聊几个我觉得值得做的方向 #164 A2 密钥/PII 扫描：属于第 1 级的判据来源，不是并列的第二个机制
• [Feature] 巩固/总结的高峰感知调度：成本感知级联 + 有界检查点 + 错峰队列 #239 成本感知级联：本 issue 在其上游（拦在写入前，省掉后续全链路）
• 2609.05553（EdgeMem）：能不用模型判定就不用——本 issue 前两级都是零 LLM

[heptaspirit]

正文现状表三条我按 upstream/main @ 360f7c8 逐条核对过，现在仍成立。附一下代码位置；另外有两个点会改变实现口径，想先请你定。

现状核对

• saveWithDedupe 只有两支：命中合并（src/service.js:1183），否则新建（:1245）——没有拒绝分支，表里「默认都写」准确。
• memoryQualityFilter 在 src/service.js:1143 评分，处置却落在写之后（合并路径 :1239、新建路径 :1264，applyQualityDisposition 定义在 :1287），默认开（src/config.js:478）。它确实不是写入前拒绝。
• 密钥/PII：upstream/main 的 src/ 里 grep secret|PII|redact|api_key 零命中。
• 审计与旗标面可直接复用：llm_audit_logs（src/store.js:181）已有 status: success|error|skipped 与自由 metadata，写入口 saveLlmAudit（:1746）；旗标三处是 src/config.js 的 schema、src/settings.js:42,91（嵌套键按点号平铺）、lib/client.js:1830 的 FEATURE_GROUPS 加双语文案，计数锁在 test/api.test.js:667。

两个口径

1. 第 1 级「命中已有条目的去重键」判 non-write，和现有合并语义冲突。 现在同 title 命中就走 append 合并（src/service.js:1192；_overwrite: true 时直替，:1189），按你的三分类它属于 write-update。若去重键命中一律判 non-write，等于把合并一起取消；若判 write-update 放行，第 1 级就只剩密钥/PII 与空白噪声两类判据。我倾向后者，但「调用方声明新建」与「默认合并」要不要拆成两个入口，得你定。

2. 第 1 级把同步去重从「合并」升级成「拒绝」，会放大一个次序耦合。 我最近读到 2606.24535（Governed Shared Memory for Multi-Agent LLM Systems），里面记了一个同构事故：同步的近重复门抢在异步矛盾检测之前生效，本应被裁决的矛盾写入被门直接拒掉，裁决对象根本进不了库——它把这一类列为四个失效模式之一。mneme 这条路上正好是 saveWithDedupe（同步）与 autoDream 冲突检测（异步）前后相接。所以「去重键命中」这条判据走「拒绝」还是走「合并」，风险不是一个量级；文献那边给的修法是去重门只标记、不拒绝。

如果第 2 点你也认为是同一类风险，第 1 级的「去重键命中」可以降级为标记 + 记审计（不拦），硬拒绝只留密钥/PII 与空白噪声。这样第 2 级的规则放行也不必和合并抢同一个判定面。

最后问一下要不要我搭把手，这个功能的面我这边已经核对过，拍板后就可以开发了。

@modusensus