# G 系列执行细则 · 记忆治理与白板维护

> 2026-09-17 定稿 · 上游纲领 `MEMORY-GOVERNANCE-20260917.md`
> **本文档 = 施工级细则**，纲领回答"为什么"，本文档回答"怎么做、改哪一行、怎么验"。
> 用户已批准：**增删作废按本文档结论执行；落成文档后即可开工。**

---

## 0. 术语校准（用户已澄清）

| 用户说法 | 实际含义 | 证据 |
|---|---|---|
| **"第 8000 行注入"** | 指 `index.js` **8000 行附近的注入实现区**，不是 8000 字符 | `:8844` / `:8979` 两处 `ctx.systemPrompt.context()` |
| "自动写记忆文档的机制" | **铭文 · 每轮提醒** | `:556` 模板 + `:5244` `pushPart('otherDynamic','frame-inscription',...)` |
| "维护版本也是一个思路" | 即：**把白板维护挂到已有注入机制上**，不新建管线 | 见 §2 |

**关键区分（此前混淆过，务必记牢）**：

| 量 | 值 | 管什么 |
|---|---|---|
| `injectBudgetChars` | **8000 字符** | 每轮往上下文注入多少 |
| `noteCapacityChars` | 12000 字符 | 笔记**文件**能存多少 |
| 白板进接续 | `plan.slice(0,3000)` | 接续时白板节选 |
| 账本进接续 | 8000 | 接续时账本 |
| `SECTION_ORDER` | 10000 | 注入**顺序**（非预算） |

⇒ **调 `noteCapacityChars` 只让"本子更厚"，不影响每轮注入量。** 这正是用户要的：多存不多占上下文。

---

## 1. G2 · 标本处置【立即执行，零风险】

### 1.1 目标
给 `~/.dsh/memory/workspaces/--D--dsh-auto-memory--/MEMORY.md` 的作废结论补**显式作废标记**，防止下一窗口据行 120 按"2 处"施工。

### 1.2 背景（两个活体标本）

**标本一 · 记忆层** — 同文件三条矛盾并存：

| 行 | 内容 | 状态 |
|---|---|---|
| **120** | 「逐处判读后结论 —— **真正该解耦的只有 2 处**」 | ❌ 作废 |
| **122** | GUIDANCE 白板零覆盖（实测） | ✅ 仍成立 |
| **124** | 「动手顺序已重排：①缺口2 → ②缺口4⑤…」 | ❌ 作废（编号体系已换） |
| **161-162** | 「那个结论划窄了范围…漏掉 handoffEnabled 一族」 | ✅ 修正声明 |
| **183** | 「13 处闸门逐条判归属后：**只需动 4 处**」 | ✅ 现行 |

**标本二 · 白板层** — 最新账本 `handoff-20260917-023635.md` 的「进度与下一步」写的是**旧编号计划**（缺口2→缺口1→缺口3→缺口4），与现行 `BATTLE-PLAN` 的 `L3.5→L4→L5→L6→L7→L3.6` **不一致**。

### 1.3 施工步骤

| 步 | 动作 | 说明 |
|---|---|---|
| G2a | 备份 | ✅ **已完成**：`MEMORY.md.bak-20260917-G2`（19610 字节） |
| G2b | 在行 120/124 **原地加作废标记** | 前缀 `> ⚠️ 已作废(2026-09-17)` + 指向 supersede 条目 |
| G2c | 追加一条**处置记录** | 说明三条的关系与现行结论 |
| G2d | 校验 | 字符数不超 12000；`git diff` 确认只增不删 |

**执行原则**：**不删原文**（保留追溯），只加标记。

### 1.4 验收断言
1. 行 120 出现 `已作废` 字样，且指向行 183 的"4 处"结论
2. 文件字符数仍 **< 12000**
3. 原文逐字保留（除新增标记行）

---

## 2. G4 · 白板维护挂进注入机制【用户核心诉求】

### 2.1 用户原话与意图
> "开工有一个核心点，就是白板的维护。现在应该是 8000 行吧，注入进去这样的话，模型能够记住。每次写入记忆的时候，也顺便维护一下白板。"

**意图拆解**：
1. 白板内容要**每轮可见**（靠注入，不是靠读文件）
2. **写记忆时顺带维护白板**（同一次工具调用，不额外增加轮次）

### 2.2 现状核查

| 项 | 现状 | 结论 |
|---|---|---|
| 白板是否每轮注入 | ✅ `GUIDANCE`（`:143`）+ Tier-0 目录层 | **已注入，但注入的是"目录"不是"全文"** |
| Tier-0 是否保护白板 | ✅ `floorLayers:['whiteboard','user']`（`tier0-catalog-pre.js:353`） | 有保底配额 |
| 接续时白板是否注入 | ✅ `plan.slice(0,3000)`（`:3686`） | 有 |
| **模型是否被要求"维护白板"** | ❌ **GUIDANCE 零覆盖**（实测：白板/PLAN/kind=plan/handoff 全 False） | **真因** |
| **写记忆时是否顺带维护白板** | ❌ 无联动 | **要新增的** |

### 2.3 施工步骤

| 步 | 文件:行 | 动作 |
|---|---|---|
| **G4a** | `lib/index.js:143`（`GUIDANCE`） | 扩写白板纪律（**三条硬约束**）：①条件触发非每轮 ②只报告不自动删 ③白板关闭时跳过 |
| **G4b** | 铭文模板 `:556` | 评估是否加一句白板提醒（**谨慎**：铭文每轮注入，加内容=每轮成本） |
| **G4c** | `memory_log_pre` 的 `description`（`:9018` 附近） | 加一句"完成阶段性工作后，如白板已过时请一并调用 `memory_note_pre(kind=plan)` 更新" |

**⚠️ 边界（必须遵守）**：
- **零新增管线**——只改提示词/描述文本，不新增注入通道
- **不自动写盘**——只提示模型，是否维护由模型判断
- **白板关时无副作用**——`handoffEnabled=false` 时提示不得导致报错

### 2.4 与 M3 的关系
BATTLE-PLAN 的 **M3「GUIDANCE 白板纪律扩写」** 与本项**重叠**。
⇒ **合并**：G4 即 M3，在 M 层执行；G4c（写记忆时提示）是**新增部分**。
⇒ BATTLE-PLAN 的 M3 条目应标注"已被 G4 吸收"。

---

## 3. 增删改作废 · 最终结论【用户已批准按此执行】

### 3.1 结论表

| 能力 | 现状 | 终局决定 |
|---|---|---|
| 增 | ✅ 有 | 不动 |
| 读 | ✅ 有 | 不动 |
| **改（覆盖结论）** | ⚠️ 仅白板 | **本次不扩到笔记层**（成本高，见 §3.3） |
| **删（硬删）** | ❌ 无 | **永远不做**——归档替代，原文必留 |
| **作废（软删）** | ❌ **空白** | ✅ **本次做**（方案 A，见 §3.2） |
| 归档 | ✅ 有 | 不动 |
| **语义重排** | ✅ **不需要** | **确认无需任何改动** |

### 3.2 方案 A（本次实施）· `supersedes` / `status` 约定

**格式**（写在笔记条目内，不影响 Markdown 渲染）：
```markdown
### 2026-09-17 · 白板线解耦边界
<!-- id: mem_abc123  supersedes: mem_def456  status: current -->
结论：只需动 4 处...
```

- `supersedes:` — 本条作废了哪些 id（可多个，空格分隔）
- `status:` — `current`（默认）/ `superseded` / `deprecated`

**读取侧**：`pushL0` / `semSources` / `searchHandoffCorpus` 命中 `status != current` 的条目时，**输出前缀加 `[已作废 → 见 <新id>]`**，不静默丢弃（保留可追溯性）。

**写入侧**：`memory_note_pre` 的模板加这两个字段（**默认 current**，模型显式填 supersedes）。

**⚠️ 风险**：需模型自觉填写 `supersedes`。**缓解**：G5 的 lint 会检测漏填（同主题多条 current）。

### 3.3 方案 C 为何本次不做
笔记层引入 replace+archive 语义 = 改动写入路径 + 归档逻辑 + 迁移旧文件。**收益（自动去重）不如风险（可能误删结论）**。⇒ **留待 G6，等 G3 在真实数据上验证后再评估。**

---

## 4. G1 结论更正【已完成，记录备查】

**我此前的误判**：据 `MEMORY.md` 19610 **字节** 对比上限 12000，判定"超限 63%、疑似 bug"。

**实测推翻**：

| 口径 | 值 |
|---|---|
| 文件字节 | 19610 字节 |
| **实际字符**（`String.length`） | **11956 字符** |
| 上限 | 12000 字符 |
| 判定 | ✅ **未超限，机制正常** |

**容量按字符计，不按字节。** 中文字符 UTF-8 占 3 字节 ⇒ 字节数 ≈ 字符数 × 1.6。

⚠️ **但余量仅 44 字符** ⇒ **下次写入必然触发整理**。而整理**不保证识别矛盾**（只做压缩），可能把作废结论折叠成"要点"而**丢失作废语义**。
⇒ **这就是 G2 必须赶在下一次写笔记之前做的原因。**

*（本条为自我更正记录，按"根因结论必须附证据、推断须标注为推断"纪律留痕。）*

---

## 5. 容量建议值【用户自行在设置里调】

| 设置项 | 现值 | 建议 | 理由 |
|---|---|---|---|
| `noteCapacityChars` | 12000 | **24000** | 余量 44 字符太危险；今日单日日志峰值 ~30000 字符，结论层给 2 倍余量较稳 |
| `userCapacityChars` | 12000 | **不动** | 实测注入目录里用户级 46 条被裁 45 条 ⇒ **瓶颈在注入配额，不在文件容量**，加容量无效 |

**同时需知**：调大 `noteCapacityChars` **不影响每轮注入体积**（那是 `injectBudgetChars=8000` 的职责）。⇒ **多存不多占上下文。**

---

## 6. 白板结构问题（标本二的深处）

### 6.1 实测现状

| 文件 | 体积 | 行数 |
|---|---|---|
| `PLAN.md` | **1506 字符** | 23 行 |
| `handoff-*.md`（最新） | 2922 字节 | ~30 行 |

**用户判断"量肯定是够了"——实测支持**：1506 字符 vs 接续预算 3000、注入预算 8000，**余量充足**。

### 6.2 四个结构问题

| # | 问题 | 证据 |
|---|---|---|
| 1 | **PLAN.md 是"项目说明书"不是"交接单"** — 写"是什么/从哪来"，没写"现在卡在哪" | 全文 23 行，全是 3.0 收尾期内容 |
| 2 | **PLAN 与账本都写"下一步"** — 两处可能不同步 | 标本二即此 |
| 3 | 账本**文件名日期 ≠ 标题日期** — 按文件名排序 ≠ 时序 | `handoff-20260917-023635.md` 标题是 `2026-09-16 02:36` |
| 4 | 老账本**无作废标记** | 检索到会误导 |

### 6.3 分工调整（**待用户确认**）

| 账户 | 应写 | 不应写 |
|---|---|---|
| `PLAN.md` | **稳定事实**：是什么/架构/铁律/边界 | ❌ 不写"下一步" |
| `handoff-*.md` | **唯一权威的动态状态**：卡在哪/试过什么/下一步 | ❌ 不重复项目介绍 |
| `MEMORY.md` | **可复用结论** + `supersedes` 链 | ❌ 不写流水 |

**一句话**：**下一步只在一个地方写。**

---

## 7. 执行顺序总表

```
【立即】G2 · 标本处置          ← 用户已批，压缩前先做
【立即】G1 结论已更正          ← 已完成（文档层）
────────── 以下并入主线 ──────────
L3.5 附件路径进转写            ← 已批准
L4   白板进检索
L5   锚点解耦（原义：:1993/:2037）
L6   账本注释对齐（原义）      ← 用户已批"按你的结论做"
L7   死导出
── 全量回归绿 ──
L3.6 旧对话可检索化            ← 最后开
────────── 与 M 层合并 ──────────
G4=M3 · GUIDANCE 白板纪律 + 写记忆时提示维护
G5   矛盾检测 lint（需 ③④ 判据）
G6   结论层 replace+archive（长期）
```

---

## 8. 待用户拍板

1. **§6.3 白板分工调整**是否同意（PLAN 不写下一步，账本唯一权威）
2. **`supersedes` 自动还是手写**（自动需 AI 判同主题；手写可靠但靠自觉）
3. **`noteCapacityChars` 是否调 24000**（用户说自己调，此处仅给建议值）

---

## 9. 收尾纪律（每个 G 项完成后）

1. 改动前备份（G2 已做）
2. `node --check` 语法校验（涉及代码时）
3. 可失败断言 + 变异演示（涉及代码时）
4. 留痕：`memory_log_pre` + 必要时 `memory_note_pre`
5. **白板回写**：PLAN.md / 账本同步更新（**这正是 G4 要固化的习惯**）

---

*本文档与 `MEMORY-GOVERNANCE-20260917.md` 配套：纲领答"为什么"，本文档答"怎么做"。*