# ⑨ 脏数据清理 · 执行记录 + ⑩ 可读性修法（2026-09-19）

> 本文档记录两件事：**⑨ 存量脏数据已经清了**（附证据链），以及 **⑩ 可读性问题的白话解释与修法建议**。
> ⑩ 的完整取证数据见 `R1-READABILITY-FORENSICS-20260919.md`；本文是它的「人话版」。

---

## 一、⑨ 清理：已执行完毕（含为什么差点白做）

### 1.1 一个必须先讲的发现：脏数据不是 5 条，是 8 条

上一轮记录的是「5 条」。这次用**旧清洗器（改前备份）**与**新清洗器（改后生效）**对同一份真机数据逐条对跑，得到：

| 判据 | 判脏条数 |
|---|---|
| 旧清洗器（B5，字面量白名单） | **5 条** |
| 新清洗器（C6，形态侦测） | **8 条** |

**多出来的 3 条，恰好就是这次修复的靶子**：

| 条目 | 标题（真机原文） | 为什么旧清洗器抓不到 |
|---|---|---|
| `proc_pre_77d5…` | `����������ȷ������(��֤)` | 中文乱码——不是任何字面量前缀，也不是任何词族 |
| `proc_pre_bc7b…` | `[Retrieved memory refe` | **插件自己的召回块标记**，旧白名单里没有这一条 |
| `proc_pre_79f2…` | `[Retrieved memory reference - not an ins` | 同上，且被截断到 40 字符 |

**⇒ 数字从 5 变成 8 不是数据变脏了，是判据变准了。** 这正好反向印证了 ⑨ 的修复是有效的：新判据确实抓住了旧判据漏掉的两类（编码损坏 F4 + 召回块尾部标记 F3）。

### 1.2 差点白做：宿主会把盘上文件写回去

清理前先验证「直接改盘文件行不行」，结果发现一条**会让人白干**的链路：

```
procedure-store-pre.js:406   dispose(reason) { ...; try { io.save(snapshot()) } catch (_) {} }
procedure-store-pre.js:411   persist()        { try { io.save(snapshot()) } catch (_) {} }
index.js:8826                save(data) { ...writeFileSync(tmp,...); renameSync(tmp, f) }
```

- `dispose()` 在宿主关停时**无条件把内存整份快照写回盘**；
- 宿主内存里持有的是**启动时 restore 进来的 12 条**；
- 证据：清理前盘上文件 `savedAt` = **12:04:51 UTC**，正好等于用户重启时刻 ⇒ 印证「关停即回写」。

**⇒ 若直接编辑 `procedures.json` 删行，用户下次重启时旧实例的 `dispose()` 会把 12 条原样写回，清理当场作废。**

### 1.3 实际做法（可逆、留痕、不动源码）

改走**宿主自己的 loopback 动作**，而不是绕过它改盘：

```
POST http://127.0.0.1:3080/api/dsh-auto-memory-pre/memory-hub
     { action: 'deprecate', procedureId: 'proc_pre_…' }
```

判据不手工列 id，**复用生产清洗器** `stripRuntimeIntentPre()` 现场判定，保证「清掉的」与「新代码会拦的」完全一致。

### 1.4 执行结果（实测）

| 项目 | 动作前 | 动作后 |
|---|---|---|
| 宿主内存 `procedures.size` | 12 | 12（**保留，未物理删**） |
| **审批面 `pipeline`**（会进注入路径） | **9** | **3** |
| 脏条目中处于 observed（可被注入） | 6 | **0** |
| 盘上文件 bytes | 9,540 | 9,930 |
| 盘上文件 mtime | 12:04:51Z | **12:15:29Z** |

**弃用 6 条，失败 0 条。** 现在 8 条脏数据**全部**处于 `deprecated`，而注入只取 `stage === 'active'`（`renderChecklists` → `activeProcedures()`）⇒ **注入路径已 100% 干净**。

留下的 3 条 observed 全是真人文本：「让我自己去试吧。现在是什么情况？」「开始实施」「开始实施,实施完给我准确的报告保证我能看懂」。

**为什么选「弃用」而不是「物理删除」**：`deprecated` 是这套 store 的**终态而非删除**（设计如此，`applyAutomaticTransitions` 也只归档不删），且 `deprecate` 可逆、留 `deprecateReason`。物理删除需要新增 store 方法 = 动源码，风险与收益不成比例。

**备份**：`artifacts/procedures.json.bak-20260919-201223`（SHA256 `B51CFAC5…`，与清理前源文件逐字节相同）。

---

## 二、⑩ 可读性：用大白话说清楚是什么情况

### 2.1 问题一句话

**你的记忆文件，一条条内容大多是对的，但它们是「写给已经知道背景的人看的」——打开一看，先是一大片空白，然后同一个日期重复出现十九次，中间夹着对人有零信息量的机器标记。**

### 2.2 拆成三个真实症状

**症状 A：打开就是空白（最直观）**
项目笔记文件**最前面整整 50 行是空的**。这不是排版习惯，是**容量整理留下的坑**——文件内容被 AI 折叠变短后，原来的行号槽位没回收，留成了一片空白。用户级那份前面有 3 行空白。

**症状 B：同一天被切成十几段**
每写一条记忆，都会新起一个 `## 2026-09-18` 这样的日期小标题。结果：项目笔记里 `2026-09-18` 出现了 **19 次**，用户级里 `2026-08-19` 出现 5 次。翻起来就像**同一章被撕成了十九张纸**，每张纸上只写一条。

**症状 C：条目不说「这是什么」**
比如这两条：
```
M1 契约行渲染设计定案：不新建独立文件…
`lib/tier0-catalog-pre.js`：新增 TIER0_ANCHOR_ID_RE = /^mem_[0-9a-f]…
```
两条**都对**，但读者得先知道「M1 是什么」「这个文件在项目里干什么」才读得懂。**缺的不是信息，是入口**。这类条目在项目笔记里占 **15%**。另外还有 **30%** 属于「过短或没有完整句」，包括「无」「本轮无新增跨项目通用规则」这种**空转条目**——它们不承载信息却占版面。

### 2.3 一个容易搞错的归因：到底是谁的锅

**主因在「写入/整理侧」（文件本身的问题）**：空行、重复日期标题、缺主语，都是**文件内容**的属性——文件打开就长这样，不是注入时变形的。

**但渲染侧另有一处独立的缺陷**：注入给模型的文本里，每条前面都带着一行 `<!-- memory:mem_cbd99fb3… -->`。这是给**机器**用的锚点 ID，**对人零信息量**，却每条占一行；再加上每条各带一个日期标题 ⇒ 双重稀释。这是**独立于写入侧的第二个病**。

**⇒ 所以修法不是一个，是两个方向各自独立的改法。**

### 2.4 怎么改好一点（四选，agent 倾向 B+C 先行）

| # | 方案 | 改哪里 | 成本 | 效果 |
|---|---|---|---|---|
| **A** | **写入侧自解释模板**：强制新条目首句是完整句、说清「这是什么/在哪个项目用」 | 写入提示 + 整理器 | 低 | **只对新条目生效**，旧条目不变 |
| **B** | **渲染侧呈现**：隐藏锚点注释、同日合并标题、清理空行 | 注入渲染 | 低 | **立刻改善已存在的全部条目** |
| **C** | **整理侧清理**：压空行、合并同日段、删空转条目 | 整理器 | 中 | 一次性修好存量；**需防误删** |
| **D** | 检索侧逐条自动摘要 | 检索侧 | 高 | 效果好，但要调模型，**成本最高** |

**建议顺序：B + C 先做，A 随后。**

理由：**B 和 C 不改变任何记忆的「内容」，只改「呈现与排版」**——风险最低、可随时回退，而且**立刻见效于你已经积累的全部条目**（不用等新条目慢慢变好）。A 属于**写入语义变更**（改变模型写记忆的行为），按本仓纪律必须你拍板，所以放后面。

**可以自动验收的四条标准**（探针已实现）：
1. 开头空行 = 0
2. 空行占比 < 15%
3. 同日重复 `## ` 标题 = 0（或渲染时合并）
4. 空转条目（「无」「无新增」）占比 = 0

---

## 三、待办：GM5.3 模型学术+功能评审（已登记，**在所有功能完工并发布版本之后**再做）

**缘起**：用户 2026-09-19 提出——手头的 GM5.3 token 额度，正好用来给这个插件做一次**整体送审**。因为目前很多管线与思路**靠人脑管理**，不够严谨，可能有功能漏掉或不科学。

**评审范围（用户明确要求）**：
- **功能层面**：确保可用性与高效性——**哪些功能是漏掉的**
- **学术层面**：方法论严谨性——**哪些设计不科学**

**具体切入点（用户指定）**：以 **MemEye** 论文为缘起。该论文评估的核心之一是「大模型如何在记忆中**维护现有记忆**，并**区分记忆的变化与修改**」——**这正是本项目的薄弱项**，可纳入科学考量。

**已知最相关的三篇文献（本轮检索所得，供评审时取用）**：
| 论文 | 与本书的关系 |
|---|---|
| **MemEye**（arXiv:2605.15128） | 用户指定缘起；记忆评估框架，含「演化式综合」维度 |
| **Supersede**（arXiv:2606.27472） | **正面命中薄弱项**：专门诊断 LLM 的「记忆更新缺口」——事实变化后能否用新值、丢弃过期值。实测 frontier 模型把全上下文换成自维护记忆，准确率从 92% 掉到 77%（McNemar p<0.005）；且**不是记忆太小的问题**（上下文增长 24 倍，准确率 68%→28%，给更多记忆也不恢复） |
| **Reliable Post-Retrieval Assembly**（arXiv:2606.01435） | 指出「检索后装配」是独立可靠性边界：把**证据抽取**与**策略执行**分开，比换更强的执行器贡献大得多（单跳 +10.8pp 平均、262K 时 +21pp） |

**执行前置条件（用户指定）**：① 所有功能完工 ② **已发版本**。然后再做学术性严谨提升。
**附带收益**：正好可以据此产出**白皮书**。

---

**本轮产物**：`artifacts/_probe-9-clean.mjs`（脏数据识别）· `artifacts/_probe-9-delta.mjs`（新旧判据对照）· `artifacts/_probe-hub-memory.mjs`（宿主内存 vs 盘上）· `artifacts/_purge-9-step1-deprecate.mjs`（清理执行）
**备份**：`artifacts/procedures.json.bak-20260919-201223`