@a9i5k4/dsh-auto-memory 3.0.1 → 3.1.1

package/docs/internal/MEMORY-GOVERNANCE-20260917.md

@@ -1,309 +0,0 @@
-# 记忆治理与接续质量 · 专项攻关纲领
-
-> 2026-09-17 定稿 · 用户明确列为**重点攻关项目**
-> 上游：`BATTLE-PLAN-20260917.md`（执行顺序权威）、`S10-GAP-INVENTORY-20260917.md`（缺口复核）
-> 本文档管辖范围：**记忆正确性治理**（大象）+ **接续材料质量**（白板结构）
-
----
-
-## 0. 为什么单独开一份文档
-
-用户原话（2026-09-17）：
-
-> "如果老记忆是错的，新记忆更正了；或者新记忆更新了，老记忆不适用，这种情况怎么办？
->  我一直在这个过去的对话和项目文档中提过类似的焦虑，但可能每次 AI 提出的回馈，我都没有及时修改或者没有来得及采纳。"
-
-**这不是新问题，是长期未被处理的欠账。** 现有 12 个记忆工具**没有任何一个**能回答"这条记忆还成立吗"。
-
----
-
-## 1. 大象的实证：活体标本（不是推测）
-
-**实测位置**：`~/.dsh/memory/workspaces/--D--dsh-auto-memory--/MEMORY.md`（19610 字节 / 203 行）
-
-同一份文件内，三条结论**互相矛盾且并存**：
-
-| 行 | 内容 | 状态 |
-|---|---|---|
-| **120** | 「逐处判读后结论 —— **真正该解耦的只有 2 处**：`:1993`、`:2037`」 | ❌ **已作废** |
-| **161-162** | 「**那个结论划窄了范围**：只枚举了 `boardMode` 一族，**漏掉并行的 `handoffEnabled` 一族**」 | ✅ 修正声明 |
-| **183** | 「13 处闸门逐条判归属后：**只需动 4 处**」 | ✅ 现行结论 |
-
-**危害**：行 120 排在**最前、语气最肯定**（"逐处判读后结论"），下一个窗口极可能据此按"2 处"施工，**漏掉两处 handoffEnabled 渲染闸门**——正是用户报障的那条线。
-
-**这证明三件事**：
-1. 矛盾确实会产生，且**已经产生**；
-2. 修正**确实写了**，但**没有作废旧条目**（append 语义的固有缺陷）；
-3. 记忆是**纯文本追加**，无版本、无作废标记、无 supersede 链。
-
----
-
-## 2. 根因：append-only 与"结论会变"的根本冲突
-
-| 层 | 现有机制 | 为什么不够 |
-|---|---|---|
-| 日志 | `memory_log_pre` append-only | 追加是**正确**的（日志本就该流水） |
-| 项目笔记 | `memory_note_pre` append | ⚠️ **笔记不是流水，是结论**，但用了流水的语义 |
-| 用户级 | `memory_user_pre` append | 同上 |
-| 白板 | `memory_note_pre(kind=plan)` **replace** | ✅ **唯一有 replace 语义的层** |
-
-**结论**：只有白板支持"重写即替换"。**笔记/用户级只有 append ⇒ 旧结论永远留存 ⇒ 矛盾必然累积。**
-
-而现有"整理"机制（超容量时 AI 折叠成要点）**只在超限时触发**——19610 字节**远未触顶 12000 字符上限**（注：实际已超，见 §2.1），且折叠**不保证识别矛盾**，只做压缩。
-
-### 2.1 容量口径已核实：**未超限，机制正常**（2026-09-17 实测）
-
-| 口径 | 值 |
-|---|---|
-| `MEMORY.md` 文件字节 | 19610 字节 |
-| **实际字符数**（`raw.Length`） | **11956 字符** |
-| 默认上限 `noteCapacityChars` | **12000 字符** |
-| 判定 | ✅ **未超，余量仅 44 字符** |
-
-**关键**：容量按**字符**计，不按字节。中文字符 UTF-8 占 3 字节 ⇒ 字节数约为字符数的 1.6 倍，故 19610 字节 ≠ 超限。
-
-**⚠️ 但余量只有 44 字符** ⇒ **下一次写入几乎必然触发整理**。
-⇒ 这意味着整理机制**即将被实际检验**，其"折叠是否会识别矛盾"的能力（§2 指出的弱点）**马上要在真实数据上见分晓**。
-⇒ **建议**：在下次写入前先人工确认行 120 作废标记已加，**避免整理把作废结论折叠成"要点"而失去作废语义**。
-
-*（更正记录：本节初稿曾据字节数误判为"已超限 63%、疑似 bug"，实测后推翻。属推理未取证即下结论，已按纪律更正。）*
-
----
-
-## 3. 攻关方案（三层，按成本递增）
-
-### 3.1 方案 A（最小可用）· 结论条目带「有效期 + 作废指针」
-
-**不引入新存储**，只在写笔记时约定格式：
-
-```markdown
-### 2026-09-17 · 白板线解耦边界
-<!-- id: mem_xxx  supersedes: mem_yyy  status: current -->
-结论：只需动 4 处...
-```
-
-- `id` = 现有锚点（**已有**，`<!-- memory:mem_32hex -->`）
-- `supersedes:` = 本条作废了哪些 id（**新字段**）
-- `status:` = `current` / `superseded` / `deprecated`（**新字段**）
-
-**检索时**：命中 `status != current` 的条目 ⇒ **降权或标注"（已作废，见 <新id>）"**。
-
-**成本**：改 `memory_note_pre` 写入模板 + `pushL0`/`semSources` 读取时过滤。**零新增文件、零 LLM 调用。**
-
-### 3.2 方案 B（主动巡检）· 矛盾检测 lint
-
-复用已规划的 **M2 lint** 思路（只读、只报告、绝不写盘）：
-- 扫描笔记/用户级记忆，找**同一主题下的多条结论**
-- 条件触发（非每轮），只在**写入新结论**时检查是否与旧结论冲突
-- 输出："检测到可能的结论冲突：`mem_A`（2026-09-16，2 处）vs `mem_B`（2026-09-17，4 处）"
-
-**成本**：中。需定义"同主题"判据（tag / 标题相似度）。**③④ 判据待用户拍板**（已在 BATTLE-PLAN 待决项中）。
-
-### 3.3 方案 C（根治）· 结论层与流水层分离
-
-**识别到根本矛盾**：
-> 日志 = 流水（append 正确）；笔记 = 结论（append 错误）。
-
-⇒ **拆分语义**：
-- `logs/` 保持 append-only（不动）
-- `MEMORY.md` **改为"活结论文档"**：写入新结论时，**同主题旧结论自动移入 `archive/conclusions-<date>.md`**
-
-**这等于把白板的 `replace + archive` 语义推广到笔记层**——而**该机制已经存在且经过验证**（`:1984` PLAN 重写归档、`:2011`）。
-
-**成本**：高，但**复用现成机制**，不是新建。
-
----
-
-## 4. 用户另一个问题：增删改现状（纠正我此前的浅显回答）
-
-**我此前只答了"没有删除工具"——太浅。** 补全：
-
-| 能力 | 状态 | 位置 |
-|---|---|---|
-| **增** | ✅ 完整 | `memory_log/note/user_pre` |
-| **读** | ✅ 完整 | `memory_read/recall/status_pre` |
-| **改（覆盖式）** | ⚠️ **仅白板** | `memory_note_pre(kind=plan)` = replace |
-| **改（笔记/用户级）** | ❌ **只能 append，无法改写已有结论** | —— |
-| **删（硬删）** | ❌ 无，**且按设计不该有** | —— |
-| **作废（软删）** | ❌ **无任何机制** | —— |
-| **归档** | ✅ 有 | PLAN 重写、超容量整理 |
-| **语义重排** | ✅ **不需要** | `miv` 指纹变才重算，`:4719-4748` |
-
-**关键结论**：
-1. **不存在"删记忆搞崩语义库"的风险**——没有硬删，且 miv **不因内容变化全量重建**（只在指纹变时 fail-closed 不复用）。
-2. **但有更隐蔽的风险**：**改不了** ⇒ 错结论只能靠"再写一条对的"来对冲 ⇒ **正是一号标本的成因**。
-
----
-
-## 5. 白板结构评估（用户第二问）
-
-### 5.1 实测现状
-| 文件 | 体积 | 行数 | 更新频率 |
-|---|---|---|---|
-| `PLAN.md` | **1506 字符** | 23 行 | 每次接续重写 |
-| `handoff-*.md` | 2922 字节 | ~30 行 | 每次接续新增 |
-
-**用户判断"量肯定是够了"—— 实测支持这个判断**：1506 字符远未触及 3000 预算。
-
-### 5.2 但结构有真问题
-
-**问题一：PLAN.md 是"项目说明书"，不是"交接单"**
-现内容 = 项目介绍 + 3.0 历史 + 阶段列表。**这些是"是什么/从哪来"，不是"现在卡在哪、下一步做什么"。**
-⇒ 下一个窗口读完知道项目背景，**但不知道手头活的精确状态**。
-
-**问题二：交接账本与 PLAN.md 职责重叠**
-PLAN.md 有"遗留与边界（给下一个窗口）"，账本有"进度与下一步"。**两处都写下一步 ⇒ 可能不同步（又一个小号大象）。**
-
-**问题三：账本按时间文件名排列，但内容无"承接关系"**
-`handoff-20260917-023635.md` 起头写"# 交接账本 · 2026-09-16 02:36"（**文件名日期与标题日期不一致**，因为文件名用写入时刻、标题用内容时刻）。⇒ **按文件名排序 ≠ 按内容时序**。
-
-**问题四：无"已作废"标记**
-老账本里的"下一步"如果已被新账本取代，**老账本无任何标记**，检索到会误导。
-
-### 5.3 结构建议（不增量，只调分工）
-
-| 账户 | 应写什么 | 不应写什么 |
-|---|---|---|
-| `PLAN.md` | **稳定事实**：这是什么、架构、铁律、边界。低频重写 | 不写"下一步" |
-| `handoff-*.md` | **动态状态**：卡在哪、试过什么、下一步（**唯一权威**） | 不重复项目介绍 |
-| `MEMORY.md` | **可复用结论** + `supersedes` 链 | 不写流水 |
-
-**即：下一步只在一个地方写。** 这消除问题二/三/四。
-
----
-
-## 6. 执行顺序（并入 BATTLE-PLAN，不打断 L 层）
-
-用户已批准主线：
-
-```
-L3.5（附件路径）→ L4 → L5 → L6 → L7 → 全量回归绿 → 再开 L3.6
-```
-
-**本文档的攻关项**（建议编号 **G 系列**，与 L/M/S 并列，独立推进）：
-
-| 项 | 内容 | 依赖 | 优先级 |
-|---|---|---|---|
-| **G1** | 核实容量口径（§2.1）：19610 字节为何未触发整理 | 无 | 🔴 立即（疑似 bug） |
-| **G2** | 一号标本处置：给 MEMORY.md 行 120 补作废标记 | 无 | 🔴 立即（防误用） |
-| **G3** | 方案 A：结论条目 `supersedes`/`status` 约定 + 读取时过滤 | 无 | 🟡 **已定案 → 并入 M2（见 §8）** |
-| **G4** | 白板分工调整（§5.3）：下一步只在账本写 | 无 | ✅ **已完工**（三层分工已进 GUIDANCE） |
-| **G5** | 方案 B：矛盾 lint（复用于 M2） | 无（判据改由"主动触发 + 写入兜底"，见 §8.4） | 🟢 **与 G3 同批 → 并入 M2** |
-| **G6** | 方案 C：结论层 replace+archive 语义 | G3 落地后 | 🟢 长期 |
-
-**L3.6**（旧对话可检索化）保持原定位置，不属于本文档管辖。
-
----
-
-## 7. 待用户拍板（历史记录 · 均已裁定）
-
-1. ~~**G1 是否立即查**~~ → 已查：容量口径**未超限**（§2.1 已更正），非 bug。
-2. ~~**G2 是否立即处置**~~ → 已处置（`MEMORY.md.bak-20260917-G2` 留档）。
-3. ~~**G3 的 `supersedes` 自动还是手写**~~ → **已拍板：只在结论层（`memory_note_pre`）自动比对**，见 §8.2。
-4. ~~**§5.3 分工调整是否同意**~~ → 已同意并落地为 G4（三层分工进 GUIDANCE）。
-
----
-
-## 8. G3+G5 合并设计（2026-09-18 用户拍板）
-
-**用户原话**：「b➕c 应该才是正路，每次 memory-log 的时候都应该语义臂检索更新纠正记忆」+「(b) 只在 `memory_note_pre`（结论层）时比对」+「标错成 superseded 后，要不要有个撤销通道？**落到文档里，和 M2 一起做**」。
-
-### 8.1 关键前置事实：地基已经存在（本次实测，附代码证据）
-
-**这不是从零造轮子——机制早已建好，只是从来没有被接线。**
-
-| # | 事实 | 证据 |
-|---|---|---|
-| 1 | **`status` 三值已定义**，与契约 §6 完全一致 | `l0-extract-pre.js:56` `L0_STATUSES = ['current','superseded','retracted']` |
-| 2 | **`layer` 五值已定义** | `l0-extract-pre.js:53` `L0_LAYERS = ['user','project','log','reflection','whiteboard']` |
-| 3 | **L0 索引已带 status 列，且进版本指纹** | `l0-index-pre.js:62` canonical `[id, l0Hash, layer, status]` → `l0idx_pre_<sha256前32>` |
-| 4 | **改 status 会自动失效下游缓存** | 同上：状态进指纹 ⇒ 版本变 ⇒ 缓存 fail-closed 不复用 |
-| 5 | **兼容口径已定**：缺失即默认 | `l0-index-pre.js:35` `layer→log` / `status→current`，**不因缺列拒绝整文件**，旧索引照常加载 |
-| 6 | ★ **但没有任何地方在写这两个字段** | 全仓写 `status` 只有 2 处：`tier0-catalog-pre.js:283`、`wb-contract-pre.js:186`，**均为硬编码 `'current'`** |
-
-> **结论**：缺口不是"没有机制"，而是「**机制只读不写**」。零处写 `superseded`/`retracted`。
-> ⇒ 所以 G3 的工程量远小于方案 A 当时的估计：**不需要改 L0 索引、不需要改版本指纹、不需要动读取侧过滤**——那些全都有了。
-
-### 8.2 触发范围（用户裁定：**只在结论层**）
-
-**只挂 `memory_note_pre`，不挂 `memory_log_pre`。**
-
-理由（与 §2 根因表同源）：
-- **日志 = 流水**，append 是**正确**语义，流水里不存在"这条日志作废了另一条日志"的概念；
-- **笔记 = 结论**，append 是**错误**语义，才是矛盾的滋生地。
-
-> ⚠️ 用户原话提到"每次 memory-log 的时候" —— 但随后自己修正为「只在 `memory_note_pre`」。
-> **以 `memory_note_pre` 为准**，这是更小、更准的落点；日志路径保持零改动（也符合"最热路径不加成本"）。
-
-**链路（四环中三环已有现成机制）**：
-
-```
-memory_note_pre(结论) 被调用
-   ↓
-① 语义臂检索同主题旧条目        ← 已有：recallMemoryPre 的 semSources
-   ↓
-② 判定"本条取代了哪条"           ← ★ 唯一新增：判定 + 写状态
-   ↓
-③ 给旧条目写 status='superseded' ← 字段已有，只差写入方
-   ↓
-④ L0 版本自动变 ⇒ 缓存自动失效   ← 已有：状态进指纹
-   ↓
-⑤ 旧条目归档                    ← 已有：复用 PLAN 的 replace+archive
-```
-
-### 8.3 撤销通道（用户提问，**需要设计**）
-
-**问题**：自动标错 `superseded` 后怎么改回来？
-
-**必须有的理由**：**误判的代价不对称** —— 漏判只是"矛盾继续存在"（回到现状，可接受）；**误判会把一条还有效的结论标成作废，比不改更糟**（下一个窗口会无视它）。所以撤销通道是**必需项**，不是可选项。
-
-**设计（三条，择一或组合，实施前定稿）**：
-
-| 方案 | 形式 | 评价 |
-|---|---|---|
-| **U1** | `memory_note_pre` 加参数 `restore: [mem_id...]` ⇒ 把指定 id 的状态改回 `current` | 明确、可审计；但用户得先知道 id |
-| **U2** | 面板上可点（白板/笔记页签对每条显示 status，点击切换） | 最直观；但有 UI 工作量，且属 S 层（界面层已封存到 3.1） |
-| **U3** | 状态变更是**追加一条变更记录**而非原地改 ⇒ 天然可回滚 | 与 append-only 精神一致；但要注意 §3.1 已定"status 是字段不是新状态源" |
-
-**倾向 U1**（成本最低、零 UI、立即可用），U2 留给 S 层。
-
-> **纪律**：撤销必须**留痕**（谁在何时把它改回 `current`），否则又变成"静默改写"——那正是 §1 标本的成因。
-
-### 8.4 与 M2 的关系（用户裁定：**一起做**）
-
-| 项 | 形态 | 写盘？ | 归属 |
-|---|---|---|---|
-| **M2 lint** | `lintWhiteboardPre(entries)` → 问题清单 | ❌ **绝不写** | 只读体检 |
-| **G3 状态写入** | `memory_note_pre` 内的判定 + 写 `status` | ✅ 写（经正常写入通道） | 写入侧 |
-
-**两者共用同一个"同主题判定"能力**，但**边界必须清晰**：
-
-- **M2 只报告**（契约 §6 纪律，违反即把白板变成状态机）
-- **G3 才写**，且**只写 `status` 字段，不新建状态源**（S10.4 合规：状态归记忆条目）
-
-> ⚠️ **不要把 G3 的写入能力塞进 M2 的 lint**。M2 报"这条可能过时"，G3 在**下次写入时**决定要不要标。**报告与写入分离**，这是两条纪律的交点。
-
-**③④ 判据问题随之消解**：原 M2 卡在"③什么算概念/几次算反复、④什么算相关"。
-⇒ 新方案下，**判据不再需要预先穷举**，改为：**主动触发（用户/模型显式说"这条取代那条"）+ 写入时兜底比对**。
-⇒ 故 §7-3 的悬置问题**已解除**，M2 的 ③④ 不再阻塞。
-
-### 8.5 风险与约束（实施前必读）
-
-1. **★ 语义引擎铁律**：语义臂依赖引擎（**JS 内置 = 默认形态；Python = 发烧友进阶项，两者可互换、严禁互相依赖**）。
-   ⇒ G3 **必须 fail-soft**：语义引擎不可用时退回**词法臂**，**绝不因此不写状态、更不得让一个引擎的存在成为另一个生效的前提**。
-2. **判定阈值要保守**：宁可漏判（回到现状）不可误判（标错作废）。建议**只在高置信度时自动标**，其余**只报告不标**。
-3. **`memory_note_pre` 在热路径上**：新增语义检索有成本。需实测单次开销，必要时加**同主题缓存**或只在结论内容显著时触发。
-4. **不新增状态源**（S10.4）：`status` 是**已有字段**，G3 只是让它**第一次被写入**。任何"另建一份状态表"的做法都违规。
-
-### 8.6 验收口径（能失败）
-
-- [ ] 写一条新结论、显式声明取代旧条目 ⇒ 旧条目 `status` 变 `superseded`，**且 L0 版本指纹随之变化**。
-- [ ] **误标可撤销**：走 U1 改回 `current`，且有留痕。
-- [ ] **语义引擎关闭/不可用时**：退回词法臂，行为正常，**不报错、不跳过写入**。
-- [ ] `memory_log_pre` 路径**零改动**（断言：日志写入不触发任何 status 写入）。
-- [ ] M2 lint 跑完后**文件 mtime 不变**（只读纪律）。
-- [ ] 每条都在 `tests/smoke/` 有套件，且**故意改坏实现时会红**。
-
----
-
-*本文档为专项攻关纲领，执行细节落入 BATTLE-PLAN 的 G 系列。*

package/docs/internal/MEMORY-MUTATION-AND-INDEX-DESIGN.md

@@ -1,85 +0,0 @@
-# 记忆可变 × 索引稳定：方案设计（2026-09-14）
-
-> 起因：用户指出一个真实痛点 —— **记忆必须能增删改**（AI 发现自己记错了要改；用户反映"过去的错误记忆影响了现在的工作"），但当前**一改就要把整个语义库重排**。
-> 本文只做方案设计，不动工。状态：待与"跨会话/跨 Agent 检索"一并拍板。
-
----
-
-## 一、先把因果拧准（实测数据）
-
-| 说法 | 判定 |
-| --- | --- |
-| "多 Agent 协作导致记忆被订正/增删，进而导致向量检索失败" | **部分成立**：51 个阻塞文件里**只有 3 个**是"增删"直接造成的（9/13 修重复 `tool_call_id` 时删过事件 → seq 缺口）；另外 48 个与增删无关（39 个 `descriptor` v2、7 个 `permission/preset` 多出 `origin`、2 个畸形字段）——那是 DSH 对老日志的 schema 冻结清单过严。 |
-| "和多个 Agent 有关" | **相关但不是因果**：只有跑过子代理的会话里才有 `descriptor` 事件，但让校验失败的是**版本号**（v2 不在冻结清单里），不是协作本身。 |
-| "**一改就让整个语义库重排**" | ✅ **完全成立**，且发生在插件自己的索引里（见 §二）。 |
-
-**归纳出的唯一原则**：对"不可变日志"做物理删除 → 必然留下空洞（seq 缺口 / 断链），而事后读取器可能拒绝空洞。**改正只能用"标记 + 追加"，不能用"物理删除"。** 这一条同时适用于 DSH 会话日志、我们的每日日志、以及向量索引。
-
----
-
-## 二、现状：为什么"一改就整体重排"（代码级）
-
-1. **语料身份是整份的**：`memoryIndexVersion`(miv) 是整个语料的哈希 → 任何一处改动 = 新 miv。
-2. **同步是全量的**：宿主 `ensureIndexReady` 以 `(wsRef, scope)` + miv 为 key；miv 变了就重发**整份** records（`index-sync-pre.js` 的 `buildIndexSyncPlansPre` 每次都从全量 records 造页）。
-3. **嵌入是全量的**：worker 收到 commit 后，对 payload 里**所有** record 做 `_chunk_texts_for` → `encode_texts(encode_items)` → 整体重算并原子覆写 `vectors-<key>.json`（`python/worker_semantic_pre_v1.py:355-372`）。
-4. **块级 ID 早就有、但没用于缓存**：`chunkId = chunk_id_for(memoryId, recordDigest, ordinal)`（天然内容寻址）→ 完全够做"只重嵌变化块"。
-5. 持久化格式也是整块快照：`{'identity', 'chunks': [...], 'vectors': [...]}` —— 没有 `chunkId → vector` 的映射表。
-
-**结论**：改一条记忆 = 重嵌整个工作区语料。语料一旦上万块，这个代价就是用户说的"重排"。
-
----
-
-## 三、五个方案（按"性价比"排序）
-
-### 方案 1｜块级向量缓存（**首选**，改动最小、收益最大）
-- **做法**：持久化改为 `Map<chunkId, {vector, meta}>`；commit 时对 `chunkId` 做集合差 →
-  - 新增 id → 只 embed 这些；
-  - 消失 id → 只删条目；
-  - 未变 id → 直接复用旧向量。
-- **identity 校验收窄**：仍校验 embedding provider/model/config（换模型才全量重算）——这是**正确且必要**的行为，不能省。
-- **效果**：改一条记忆 ≈ 嵌一条（毫秒级）；删一条 = 零计算。工程量：worker 内 ~60 行 + 一个迁移（旧格式首次读入即转成新映射）。
-- **风险**：低。旧文件可原地迁移；迁移失败退化为"重新嵌一次"。
-
-### 方案 2｜差量同步（让"整份重发"也消失）
-- **做法**：同步走 **upsert + tombstone** 差量；宿主 readyCache 改为记录"已同步的 `memoryId → recordDigest` 集合"而不是单一 miv；miv 退化为"语料版本号"仅用于诊断。
-- **收益**：wire 成本与改动量成正比；大语料不再顶 256KB/page 预算（`INDEX_SYNC_PAGE_BUDGET`）；数千次编辑不再重复发送未变内容。
-- 工程量：`index-sync-pre.js` + `m7-index-sync-host-pre.js` ~80 行 + 测试。
-
-### 方案 3｜改正语义：**supersede（替代）而不是删除**
-- **做法**：AI 发现记忆有错 → 写**新**记录并声明 `supersedes: <旧 memoryId>`；旧记录保留、标记 `supersededBy`；检索阶段过滤掉被替代项（或大幅降权）。删错记忆 = 新增一条"作废声明"。
-- **收益**：①改正变成"只增不改"→ 与增量索引天然契合；②审计链完整（"当时为什么这么记"可回放）；③与既有 append-only 日志纪律一致；④**直接回答用户痛点**：过时/错误记忆不再被检索命中，但没被销毁。
-- 工程量：`memory_note_pre`（工具侧加参数）+ L0 检索过滤 ~40 行 + 契约文档。
-
-### 方案 4｜检索侧 fail-open（防重蹈 DSH 覆辙）
-- 索引不可用 / 部分过期时：**退回词法结果 + 明示"语义索引未就绪/部分过期"**，绝不整条失败（对照：DSH 因单文件坏而全库拒答）。
-- 工程量：小（`recall()` 降级分支）。
-
-### 方案 5｜三层分离的纪律（写进文档与工具说明）
-- **不变层**：每日日志（append-only，永不改）——事实来源。
-- **可变层**：项目笔记 / 用户记忆（可编辑）——当前认知。
-- **派生层**：向量索引（随时可重建、可丢弃）——加速器。
-- 规则：**改正 = 追加更正 + 改当前认知；永不改日志；索引永远可从"不变层 + 可变层"重建**（重建成本由方案 1 压到与改动量成正比）。
-
----
-
-## 四、推荐落地顺序
-
-| 阶段 | 内容 | 工程量 | 直接解决的问题 |
-| --- | --- | --- | --- |
-| P0 | 方案 1 块级向量缓存 + 方案 4 检索 fail-open | ~1 天 | "一改就重排"消失；索引故障不再让检索整体失败 |
-| P1 | 方案 3 supersede + L0 过滤 | ~半天 | "过去的错误记忆影响现在的工作" |
-| P2 | 方案 2 差量同步 | ~1 天 | 大语料下的 wire/时间成本 |
-| P3 | 方案 5 纪律固化（工具说明 + 契约文档） | 小 | 防止未来再引入"物理删除"类问题 |
-
-**验收判据（可测）**：
-1. 编辑 1 条记忆 → 断言 `encode` 调用只覆盖变化的 chunk（不是全部）；
-2. 删除 1 条 → 断言向量表条目减少、不触发任何 encode；
-3. 被 supersede 的记录 → 断言不在检索结果里、但仍在审计视图里；
-4. 故意破坏一个源文件 → 断言检索仍返回词法命中 + 明确的降级标注（不抛错）。
-
----
-
-## 五、与另外两条线的关系
-
-- **DSH 会话日志那条**（§一 的 51 个文件）：属于上游 schema 过严 + fail-closed，**不由本方案解决**；本方案只保证"我们自己的索引不重蹈这条路"。上游仍建议单独上报。
-- **跨会话/跨 Agent 检索**（`CROSS-SESSION-SEARCH-RESEARCH.md`）：那个 P0 是"自建 FTS5 索引"。**两者共享同一套 ID 与增量纪律**（chunkId 内容寻址 + 差量 + 标记删除），建议合并到同一版实现，别做两套。

package/docs/internal/MERGE-CONFLICT-SCAN-20260914.md

@@ -1,222 +0,0 @@
-# 矛盾扫描：GPT 方案 ↔ WB-GRAPH 方案（2026-09-14）
-
-> **用途**：在写《合并总纲》之前，先把两份方案的**冲突、重叠、互补**逐项列清。目的有二：
-> ① 总纲不带着未调和的矛盾往下走；② **交 GPT 复核时，让它审「调和是否正确」，而不是审「你跟我哪里不一样」**（后者是已知信息，浪费它的篇幅）。
-> **输入**：`docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md`（GPT，7 Phase / 50 断言）· `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md`（386 行，白板整合）· `docs/internal/WB-GRAPH-DECISIONS-20260914.md`（拍板点）· `docs/internal/DECISIONS-20260914-SESSION.md`（本会话 8 条裁决）。
-> **判定口径**：**冲突**＝两者不能同时成立，必须择一或改写；**重叠**＝目标相同但实现路径不同，可合并；**互补**＝一方覆盖另一方未覆盖的，直接叠加；**悬空**＝两者都没覆盖的。
-
----
-
-## 0. 结论速览
-
-| 类别 | 条数 | 处置 |
-|---|---|---|
-| **真冲突** | **2 条**（原记 4 条，第三轮复核后修正） | 见 §2；**冲突 1 归因已改、冲突 3 分类已改** |
-| **重叠可合并** | 5 条 | §3 |
-| **互补直接叠加** | 4 条 | §4 |
-| **两者都悬空** | **3 条** | §5（本次会话新发现的，GPT 与 WB-GRAPH 都没覆盖） |
-| **集成与版本边界**（新增分类） | 1 条 | 工具数 14→16（原误列为真冲突） |
-
-**修正说明（2026-09-14 深夜 · GPT 第三轮复核）**：
-- **冲突 1 的归因错了**：我把「单对话进度快照」算到了 GPT 头上，实际那是 `WB-GRAPH-INTEGRATION-PLAN.md:42` 里的话，GPT 自己的签名是按 `projectDir`（工作区）定位的。**裁决结论不变，理由已改。**
-- **冲突 3 分类错了**：属集成与版本边界，不是真冲突（原文自相矛盾）。
-- **冲突 4 也应下调**：GPT 指出"实际冲突在**质量门 fail-open 是否绕过数据保护**"，而非"判据体系互斥"（判据表大部分是互补）。
-- **冲突 2 的定性更准的说法**：不是"冲突"，而是**排期与所有权重组**（GPT 原话）。
-
-**最关键的一句（v2 修订）**：GPT 的 **Phase 4 不是"要不要保留"的问题**；真正的边界是——**3.0 拥有"共同提交与保护入口"，白板线拥有"白板格式及其适配器"**。**最小适配器是白板保护启用的前置件**，不必等完整图或两个新工具。我原来"整体移交"的切法过于粗糙。
-
----
-
-## 1. 两份方案的定位差异（先对齐坐标系）
-
-| | GPT 方案 | WB-GRAPH 方案 |
-|---|---|---|
-| **关注对象** | 全链路：注入边界 / 状态提交 / 索引增量 / 检索融合 / 白板 / 实验 / 发布 | 只有一件事：**白板（含账本）怎么从"自由文本"变成"可遍历的图"** |
-| **来源** | 读了 BRIEF + SPEC + 契约 + 代码 | 读了任务书 + 本地审计 + 外部调研（dsh-graph / MRAgent） |
-| **比喻** | 修**引擎、变速箱、油路** | 造**仪表盘与导航** |
-| **粒度** | 7 Phase / 50 断言 / 跨 6 个阶段 | 3 层（P0 判据 / P1 中间件 / P2 sidecar / P3 两工具） |
-| **交付形态** | 待施工设计 | 待施工设计 + 一页纸拍板点（A1–A8 / B1–B7，**多数未拍板**） |
-| **前提** | 白板是**单会话快照**（未读过 WB-GRAPH 方案） | 白板是**工作区级的持久图** |
-
-**差异根源**：**我投喂 GPT 时漏给了 `WB-GRAPH-INTEGRATION-PLAN.md`**。这是我的操作失误，已在 `DECISIONS-20260914-SESSION.md` §9 留痕为教训——**投喂输入包时，凡涉及用户已有方案，必须一并给**。
-
----
-
-## 2. 四条真冲突（必须择一或改写）
-
-### 冲突 1（已被第三轮复核**修正归因**）· 白板的身份：单会话快照 ↔ 工作区级共享图
-
-> **⚠️ 2026-09-14 深夜修正（GPT 第三轮复核指出，我方已核实）**：本节原写「GPT 的 Phase 4 通篇假设白板是**当前会话**的进度快照」——**这个归因是错的**。
-> 实读确认：GPT 自己的 `SnapshotRef` 带 **`workspaceKey`**、`writePlanSnapshot(projectDir, content, …)` 收的是 **projectDir**，**本来就是按工作区定位的**；明确写「白板是**单对话进度快照**」的是 **`WB-GRAPH-INTEGRATION-PLAN.md:42`**（用户自己的方案）。
-> **结论：共享图裁决不变**（用户裁定仍有效），但**理由改为**：应**调整"持久数据"与"会话执行态"的分工**，而不是推倒原快照模型。
-> 详见 `docs/internal/reviews/ROUND3-REVIEW-INTEGRATION-20260914.md` §2.1。
-
-| | 说法 |
-|---|---|
-| **GPT（实际）** | Phase 4 的写入签名按 **projectDir（工作区）**定位；`SnapshotRef` 含 `workspaceKey` |
-| **WB-GRAPH（原方案 §1，`:42`）** | 明写「白板是**单对话进度快照**」 |
-| **用户裁定** | 「只要是一个工作区的接续的不同对话，都要是同一张图」；「被接续的窗口会存档废弃」 |
-
-**调和结论（v2）**：
-- **白板 = 工作区级共享图**（采纳用户裁定）。
-- **并发需要原子提交边界**：保留现有 `_queue` 短队列，所有窗口通过**同一工作区 owner** 提交，`expectedDigest` **必须在提交边界内检查**（`memory-writer-pre.js:344` 的 `replace` 已在队列内部检查 ✓）。**不加锁、不分片**仍成立，但"不需要任何提交串行化"**不成立** —— 两个写者都先读 D、再各写 A/B 的时序真实存在。
-- **持久数据（按工作区）与会话执行态（按会话）必须分开**：共享数据按工作区缓存；**激活、冷却、精排任务、已交付标记仍按会话隔离**。
-- **`Cue(session)` 是节点来源，不能自动成为"只允许检索当前会话内容"的硬过滤**。
-- **`done/passed/archived` 不能塞进 `current/superseded/retracted`** —— 任务进度、判据确认、记忆有效状态**分别表示**。
-- GPT 的 `T4-7`（旧 digest 的提交拒绝覆盖）**保留并升级**为 `T1-7 / T1-7B / T1-7C`。
-
----
-
-### 冲突 2 · Phase 4 的归属：GPT 的第六个阶段 ↔ WB-GRAPH 的整条线
-
-| | 说法 |
-|---|---|
-| **GPT** | Phase 4「完成白板的写入、检索与归档闭环」，排在 Phase 1 之后、Phase 5 之前 |
-| **WB-GRAPH** | 白板有独立的 P0→P1→P2→P3 路线，且 P2/P3 **改 `lib/index.js` 本体**、**工具数 14→16** |
-| **用户裁定** | 「(乙) 两者合并：把 GPT 的『写入门 + 引擎隔离 + 状态过滤』这套通用原则，注入到 WB-GRAPH 方案的 P1/P2 里」 |
-
-**调和结论**：Phase 4 **拆成两半**——
-
-| 拆出部分 | 归属 | 理由 |
-|---|---|---|
-| **写入门（前后比对）** | **留 3.0 的 Phase 0**（不是 Phase 4） | 它是**注入边界**的一部分：未经校验的白板内容会进语料、进而进注入 ⇒ 与 `T0-1/T0-2` 同一关。WB-GRAPH 的 B1 与它同源，合并实现 |
-| **状态过滤（C8：非 current 不进注入）** | **留 3.0 的 Phase 0** | 同上，属注入边界 |
-| **引擎隔离（T2-9）** | **留 3.0 的 Phase 2** | 属索引层 |
-| **锚点 + 人机分区** | **移交 WB-GRAPH P1/P2** | 它是图的数据模型前提（卡片 = 节点，锚点 = id） |
-| **lint（体检报告）** | **移交 WB-GRAPH P1** | 用户裁定 R5：归 WB-GRAPH，且"不只是报告，要能改，AI 可主动提问" |
-| **archiveAnswerPre（结论归档）** | **移交 WB-GRAPH P3** | 需图的遍历能力（`memory_expand_pre`）才有意义 |
-
-**也就是说：GPT 的 Phase 4 里，只有「写入门」和「状态过滤」真正属于 3.0，其余全部移交。** 3.0 因此从 7 个 Phase 变成 **6 个 Phase + 1 条独立的白板线**。
-
----
-
-### 冲突 3（分类已修正）· 工具数：不变 ↔ 14→16
-
-> **⚠️ 2026-09-14 深夜修正**：本节原列在§2「真冲突」，却在正文里写"两者**不真冲突**"——**自相矛盾**，GPT 第三轮复核指出（我方已核实成立）。
-> **修正分类**：属**集成与版本边界**，**不是真冲突**。处置改为：**同一套测试中明确两种能力集合**（白板工具关闭 14 / 启用 16）；三个套件验证**精确名称集合、无重复、schema 及可调用性**，**数量作为派生检查**；测试预期须来自**已批准的公共工具清单**，**不能从被测注册结果自动生成**（否则自证正确）。**独立立项与回归窗口是对的，但不能代替最终集成回归。**
-
-| | 说法 |
-|---|---|
-| **GPT** | Phase 1「工具数不变」；Phase 4 也未提工具数变化 |
-| **WB-GRAPH** | P2/P3 新增 `memory_expand_pre` / `memory_trace_pre`，**工具数 14→16**；§0 记录**三处测试硬锁**：`smoke-test.mjs:67`、`smoke-test-m3b3-pre.mjs:43`、`smoke-test-context-observer.mjs:107` 都断言 `!== 14` 抛错 |
-
-**调和结论（v2）**：
-- 两者**本就不冲突** —— GPT 说的"工具数不变"是针对它的 Phase 1（状态提交）。
-- 3.0 主体**不改工具数**；白板线**会改到 16**，**三处硬锁要同步**。
-- **回归处置**：3.0 主体回归、白板独立回归、**合并后的开关矩阵**各跑一次；共用 `index.js` 接线**串行合并**。
-- **Phase 6 的 `kind` 参数即使不增工具数也改 schema** ⇒ 必须保留旧调用兼容测试。
-
----
-
-### 冲突 4 · 判据体系：GPT 的"卡片集合比对" ↔ WB-GRAPH 的完整判据表
-
-| | 说法 |
-|---|---|
-| **GPT** | `T4-1`：少一张卡且无 archive/rename 记录时拒写（**唯一的写入判据**） |
-| **WB-GRAPH** | 完整判据表：账本 H1–H4 硬 + S1–S4 软；白板 P-H1/P-H2 硬 + P-S1 软；**并区分硬/软**（硬拒绝、软警告），且有 JSON Schema 化的报告产物（`ledger-criteria-report-v1`） |
-
-**调和结论**：
-- **采纳 WB-GRAPH 的完整判据表**（它更细、且已论证硬/软分层的理由：硬判据必须确定性可计算，误拒代价 = 一轮重试）。
-- GPT 的 `T4-1` **并入 WB-GRAPH 的 B1**（卡片集合比对），作为"图完整性"判据的一条，而不是唯一一条。
-- **但 GPT 有一处 WB-GRAPH 没有的**：**判据必须"能失败"且写成 node 断言**（本轮验收的四项之一）。WB-GRAPH 的判据表**没有配套断言**。⇒ **合并时给 WB-GRAPH 的每条判据补一条能红的断言**。
-- GPT 的 `T4-5`（lint 一正一负 fixture）保留，交给白板线。
-
----
-
-## 3. 五条重叠可合并
-
-| # | 主题 | GPT | WB-GRAPH | 合并方式 |
-|---|---|---|---|---|
-| 3.1 | **写入门/卡片集合比对** | `T4-1` 前后比对 | **B1** 同源（`WB-GRAPH-DECISIONS` §B1） | 合并为一处实现，**归 Phase 0**（见冲突 2） |
-| 3.2 | **人机分区** | `T4-3` 用户区保护（一整块） | **B4 选项 (c)** 每卡片分「模型维护区 / 用户备注区」 | 采纳 WB-GRAPH 的**每卡片分区**（更细）；用户裁定 R6「需要用户手写区」 |
-| 3.3 | **expectedDigest / 冲突检测** | Phase 1 的 `expectedDigest`（写入事务）+ `T4-7`（提交冲突） | 未涉及并发写 | **GPT 的机制是现成的解法**，用于解冲突 1 的并发问题 ⇒ 直接复用，不新造 |
-| 3.4 | **状态与版本（miv）** | Phase 1 定义 `miv` = 内容身份 + 状态清单摘要，**不递增、不比较** | WB-GRAPH 的 `index.json` 有 `rebuilt_at` / `versions` | 采纳 GPT 的 `miv` 语义（哈希身份）；**禁止**把 `rebuilt_at` 当成版本序 ⇒ WB-GRAPH 的字段需按此校准 |
-| 3.5 | **"真相源 + 可重建投影"** | Phase 1「统一快照」概念 | §3.3 `index.json` 完全可从 PLAN.md 重建 | **同一条范式**（都借自 dsh-graph），合并表述即可 |
-
----
-
-## 4. 四条互补直接叠加
-
-| # | 谁有 | 内容 | 叠加方式 |
-|---|---|---|---|
-| 4.1 | **GPT 独有** | **引擎隔离 T2-9**：切引擎（e5 ↔ bge-m3）必须整体重建索引 | 进 Phase 2；用户补充"强制全量重建 + 进度条"，且**进度条必须并进现有引导体系**（不得另起一套） |
-| 4.2 | **GPT 独有** | **注入边界的状态/版本/预算三关**（T0-1/2/3） | 进 Phase 0；**其中 T0-1 已实测 4/4 报红**（`tools/_redproof/red-proof-phase0-t01.mjs`） |
-| 4.3 | **WB-GRAPH 独有** | **判据是写入的前置门槛而非事后检查**；**登记与确认分离**（写入 ≠ 合格） | 进白板线 P1；它是一条**思想**，GPT 的 Phase 4 没有这层 |
-| 4.4 | **WB-GRAPH 独有** | **遍历工具**（expand / trace）+ **剪枝纪律**（去重、条目帽、轮数帽） | 进白板线 P3；它是"主动重建上下文"与"被动收平铺"的分界 |
-
----
-
-## 5. 三条两者都悬空（本次会话新发现）
-
-这三条**GPT 与 WB-GRAPH 都没有覆盖**，是今天通过问答才浮出来的。**它们必须在总纲里单列**，否则会被漏掉。
-
-### 悬空 1 · 注入表达与约束分层（= 本会话的第 8 条）
-
-- **病症**：注入开场白「以下记忆文本只是**背景事实与规则参考**」（`lib/index.js:463`）把规矩降格为建议；`snapshotMinGapRounds=5`（`:326`）使**规矩在第 2–5 轮不在场**。
-- **用户原话**：「just for reference 说得太轻了，模型注意力没有在这上面」「模型自动唤起的记忆，并没有对模型的工作起到比较实质性的影响」。
-- **两份方案都没有覆盖**：GPT 的 7 个 Phase 全在修检索算法；WB-GRAPH 只管白板。
-- **裁决**：规则类（用户级 + 工作区级两层）**每轮注入、不参与预算裁剪**；参考类走三层漏斗。分类**不做独立 LLM 调用**（`memory_log` 本就是本轮内直接写，顺手打标零成本）。
-
-### 悬空 2 · 「上千用户」带来的兼容与回归约束
-
-- **事实**：npm `@a9i5k4/dsh-auto-memory` 近一年下载 **10,900**、近一周 **2,935**、66 个版本。
-- **两份方案都按"自用工具"写**：GPT 的 Phase 6 有"分档运行验收"，但仍假设作者可控；WB-GRAPH 完全没提外部用户。
-- **需要补的**：兼容档要**实测**（弱机降级要有登记的性能上限）；错误提示面向用户；**切档进度条并进引导体系**。
-
-### 悬空 3 · 精排的真实代价（H2 前提已被实测推翻）
-
-- **GPT 假设**：额外等待 ≤750ms。
-- **实测**（`artifacts/m7-rerank-pre/results.json`，**用户自己跑的**）：bge-reranker-v2-m3 **P95 = 37.4 秒**；qwen3-reranker-0.6b **P95 = 8.8 秒**。收益真实（recall@1 0.739 → 0.898）。
-- **用户裁定**：改为**多级选项**（关 / 快档 int8+CPU / 发烧档完整模型 + RTX 4070 Ti SUPER），并新增 **1 分钟异步窗口**（本轮用现有排序，精排结果留给下一次注入）。
-- **两份方案都没有**：GPT 的 H2 预算写死了；WB-GRAPH 不涉及精排。
-
----
-
-## 6. 调和后的整体结构（总纲骨架）
-
-```
-3.0 主体（6 个 Phase，改 lib/index.js 的检索与注入链）
-├── Phase 0  注入边界（状态 / 版本 / 预算三关）           ← GPT，其中 T0-1 已报红待修
-│              ＋ 写入门的前后比对（原 Phase 4 拆出）      ← GPT + WB-GRAPH B1 合流
-├── Phase 1  统一状态提交与快照（miv 单源）                ← GPT
-├── Phase 2  真增量（2A L0 → 2B 块缓存 → 2C 差量传输）     ← GPT
-│              ＋ 引擎隔离 T2-9（切档整体重建 + 进度条）   ← GPT + 用户补充
-├── Phase 3  共同检索、融合与决策                          ← GPT
-├── Phase 4  对照实验与最优档增强                          ← GPT，但 H2 按实测重写（多级 + 异步窗口）
-├── Phase 5  分档运行验收与发布（含真实用户兼容档）        ← GPT + 悬空 2
-└── **新增 Phase 6  注入表达与约束分层**                   ← 悬空 1（本会话新增，两份方案都没有）
-
-白板线（独立立项、独立排期、独立回归窗口）
-└── WB-GRAPH P0→P1→P2→P3（判据 / 中间件 / sidecar / 两工具）
-    ＋ 并入：lint（R5）· 每卡片人机分区（R6）· 锚点 · archiveAnswerPre
-    ＋ 工具数 14→16，三处硬锁同步
-```
-
-**顺序原则**：
-1. **Phase 0 未通过，不接入任何新算法**（GPT 的硬门，保留）；
-2. **白板线与 3.0 主体并行**，但**涉及同一个 `lib/index.js` 的接线串行合并**（WB-GRAPH 已声明此纪律，保留）；
-3. **新增 Phase 6 可提前**——它改动小、收益直接（用户最痛的病），且**不依赖任何其他 Phase**。建议排在 Phase 0 之后立即做；
-4. **白板线在 3.0 主体之后或并行，视用户精力**。
-
----
-
-## 7. 交 GPT 复核时，我建议它重点审这 6 件事
-
-（这决定了复核提示词怎么写——让它审**调和**，不是审**它自己的方案**。）
-
-| # | 要它审的问题 | 为什么值得它花篇幅 |
-|---|---|---|
-| 1 | **Phase 4 拆分的边界对不对**：把"写入门 + 状态过滤"留 3.0、其余移交白板线，是否切错？ | 这是最容易切错的地方，而它对代码结构最熟 |
-| 2 | **白板 = 共享图**这个前提变了之后，Phase 0/1 的哪些设计要跟着改？ | 它自己的设计建立在"单会话"，它最清楚哪里受影响 |
-| 3 | **新增 Phase 6（约束分层）与它 Phase 0 的注入预算设计是否冲突**？规则"不参与预算裁剪"会不会破坏它的 `FinalEnvelope` 单一记账口径？ | 这是两条设计线的真实交汇点，**它有独一无二的发言权** |
-| 4 | **H2 按实测重写后（8.8–37.4 秒 + 1 分钟异步窗口）**，Phase 3/5 的哪些断言要改？ | 它写死了 ≤750ms，需要它自己重算 |
-| 5 | **引擎隔离 T2-9 + 切档进度条**，在它的 `engineIdentity` 两级引用上该怎么落？ | 它设计了 `engineIdentity`，但没做硬约束 |
-| 6 | **白板线工具数 14→16** 会不会污染 3.0 的回归基线？ | 它主张"工具数不变"，需要它自己评估这条 |
-
----
-
-## 8. 本次扫描的自我约束（防我自己的判断被当成事实）
-
-- 本文所有"GPT 说"均引自 `PLAN-gpt6astra-round2-20260914.md`；"WB-GRAPH 说"均引自 `WB-GRAPH-INTEGRATION-PLAN.md` / `WB-GRAPH-DECISIONS-20260914.md`。**引用行号来自原文，未逐条回代码复核**（凡涉及代码现状的，已在 `CLAIM-VERIFICATION-20260914.md` 中核过）。
-- §2 的四条冲突判定**基于文本对比**，不是基于运行验证。**若 GPT 复核时指出某条其实不冲突，以它的反驳为准**（它对自身设计意图的解释优先）。
-- §5 的三条悬空是**本次会话新发现**，尚未经任何外部审阅。