[bug] dream 的 merge 被 dreamMergeGuard 永久拦死：提示词仍要求合并长保留类型，46 轮零合并、每轮照付满载 token #521

现象 / What happened

dreamMergeGuard（默认 true）会让所有涉及长保留类型的 merge 决定被拦，但提示词里没有任何一句告诉模型「这些类型不能 merge」——相反它明确要求 merge。结果是死的：模型每轮照提，校验器每轮全拦，一条都合不成，而每轮的成本照付。

实测一天（本地 2026-10-28 全天，46 轮 dream）：

我自己锁死自己：模型提的永远是同一簇 preference → 全被拦 → 什么也没变 → updated_at 不动 → 下一轮同样的条目还在 200 条窗口里 → 再提一次。46 轮下来，合并 0 条，token 一分没少花。

根因是两边没对上：

• 提示词（lib/lang.js zh 版第 26 行）里，长保留类型的禁区只对 archive 说过：

  archive 仅用于确属「重复或已过时」的条目；rejected_solution / constraint / pitfall / preference / pattern 属长保留类型，除非确属重复或过时，否则不要归档

• 同一份提示词的任务清单第 1 条，明确要求合并：

  1. 识别主题相近的条目 → merge（合并为更精炼的摘要，保留信息最完整的 id 作为 keepSource）

• merge 侧唯一的约束是 仅合并同类型条目（type 相同）（对应 allowCrossTypeMerge: false），完全没提哪些类型不能合。

• 校验器（lib/dream/decisions.js:18、:219）是硬拦：

两个护栏不对称，这是关键：archive 护栏会检查 reason 是否命中 ARCHIVE_RATIONALE_RE（「重复／过时」），所以真正重复的 archive 是能过的；merge 护栏没有这条逃生门——只要类型在这个集合里，内容再怎么真重复也一律拦。

模型没错，护栏也没错，它们俩从来没对上过。

复现步骤 / Steps to reproduce

粘到「复现步骤 / Steps to reproduce」框

1. @modusensus/dsh-mneme 0.9.4，dreamMergeGuard 保持默认 true，其余 dream 相关键全默认（allowCrossTypeMerge: false、dreamMaxMergePerRun: 40、dreamMaxSnapshotSize: 200）。
2. 库里有 ≥3 条同类型（preference）且主题相近的记忆。类型必须相同，否则会先被 allowCrossTypeMerge 拦，看到的就不是这条。
3. 触发一轮 dream：新增记忆数达到 dreamThresholdCount（默认 50），或临时把它调低。
4. 查 dream_runs.skipped，会出现：
   {"index": 4, "action": "merge",
   "ids": ["4a39c7b2-…", "ca31049b-…", "446668a6-…"],
   "error": "decision[4]: merge of long-retention type(s) preference is blocked by dreamMergeGuard"}
5. 连跑多轮：上面那几条 id 反复出现，memories.updated_at 不变，dream_runs.applied 里 merge 恒为 0。
   一行 SQL 能一眼看出来（SQLite json1，better-sqlite3 自带）：
   SELECT json_extract(value,'$.error') AS err, COUNT(*) AS n
   FROM dream_runs, json_each(dream_runs.skipped)
   GROUP BY err ORDER BY n DESC;
   返回里那条 merge of long-retention type(s) preference is blocked by dreamMergeGuard 会占掉全部 skipped 的九成以上，而 merge 的成功数是 0。

期望行为 / Expected behavior

我不请求关掉 dreamMergeGuard——它默认开启是有理由的（#339 那次体检里，10/26 条被吃掉的约束正是靠它捞回来的）。问题是它现在是全有或全无，没有第三种设置：

• dreamMergeGuard: false → preference 的 merge 全放过去，包括模型真提的跨主题乱配（我们这边就出现过把一条 SOUL.md 骨架记忆和一条「身份证文件状态」配成一对——同类型，allowCrossTypeMerge: false 挡不住）；
• dreamMergeGuard: true（默认）→ preference 的 merge 永久全死，且每轮照付满载 token。
  任何一个修法都能打断这个循环，按我建议的优先级：
  A. 提示词与校验器对齐（最小改动，两行，最希望先上）
  在 lang.js 的硬规则里，照 archive 那句的样子加一句 merge 禁区（zh / en 各一处）：
  merge 仅适用于非长保留类型；rejected_solution / constraint / pitfall / preference / pattern 之间的相近条目请输出 keep
  模型不再提 → 成本直接归零 → 什么也没丢（这些条目本来就一条也合不成）。这是我唯一希望「单独发一版」的改动。
  B. 给 merge 和 archive 同一条逃生门
  若该 merge 的 reason 命中 ARCHIVE_RATIONALE_RE（重复／过时）且所有 id 同类型，则允许穿过护栏。覆盖「确实重复」的真需求，又不至于把两条相近但不同的约束揉成一段糊话。
  C. 按类型配置
  例如 dreamMergeGuardedTypes: ["constraint","pitfall","rejected_solution"]，让愿意接受权衡的人自己把 preference / pattern 放出来。语义变了，建议先跑一轮 eval 再上。
  另外一个请求（不属于 bug，但这条 bug 就是被它藏住的）：希望面板或 dream_runs 里能有一列「按 skip 原因归类的计数」。现在从外面看，status: degraded + summary_stored: 1 + applied: 3–18 完全是健康轮的样子——不写 SQL 把 skipped 里的 error 聚合一遍，根本看不出「一整个 action 类型 100% 失败」这种事。这个 bug 我们跑了整整一天才发现。

环境 / Environment

• dsh-mneme 版本 / plugin version: 0.9.4（npm，已在 package.json 里钉死，不用 ^）
• DSH 桌面端版本与通道 / DSH version & channel: 桌面端，profile: desktop（Electron 43.3.0 / Windows 版）
• 操作系统 / OS: Windows 11
• Node 版本 / Node version: v22.22.2
• 安装方式 / install method (npm / dsh-market): npm
• 相关路由模型 / relevant model routes: deepseek-official:deepseek-flash（dream_consolidate / dream_summarize / entity_extract / summarize_compress 全部走这一条）
  其它相关配置（其余全默认）：
  dreamThresholdCount: 50
  dreamThresholdChars: 20000
  dreamMinIntervalMinutes: 60 → 事发后已临时调到 360，只为降频止血，不是修复
  dreamMergeGuard: true（默认）
  dreamMaxMergePerRun: 40（默认）
  dreamMaxSnapshotSize: 200（默认）
  allowCrossTypeMerge: false（默认）
  embedding: 本地 bge-small-zh-v1.5（512 维）

日志 / Logs

A. 单条 skipped 原文（dream_runs.skipped，2026-10-28T15:02:41.224Z 那轮）：

B. 按原因聚合（这就是建议里那条面板计数器要的东西）：

实测结果（299 条 skipped）：

⚠ 这里有个坑值得说：如果直接 GROUP BY json_extract(value,'$.error')，280 条会被拆成 20 组——因为 error 前面带了 decision[N]: 的序号。我第一版就是这么数的，看到「每组十几条、一个都不显眼」，差点没认出这是一整类失败。这也是建议「面板按归一化原因计数」的直接来由。

同期 merge 成功条数：0。

C. 那一簇 preference 被反复提了多少次（自锁的硬证据）：

实测前 5：

46 轮里，同一条记忆被提出去合并 40 次，一次没成。 单这一条就占了这轮成本的一部分，46 轮都在为同一个决定付钱。

口径说明（免得数字对不上）：全部数字取本地日 2026-10-28（UTC 2026-10-27T16:00 ~ 2026-10-28T16:00），46 轮。skipped 是用 json_each 展开后按 error 计数，不是按轮数。初稿里写过的 642 / 257 两个数是错的（那是把别的字段也算进来了），以这一版为准。

需要完整数据我这边都留着：dream_runs 全行、那 82 条记忆的 type / 长度 / 内容（可脱敏，只留结构和相似度矩阵）、以及同一时间窗的 llm_audit_logs（token 与花费）。要哪一份说一声。

披露 / Disclosure

• 本报告由 AI 辅助整理（人工审核后提交）/ Drafted with AI assistance, reviewed by a human