# 合并总纲 v1 · dsh-auto-memory 3.0

> **这份文档是什么**：把三份输入调和成**一份可施工的总体规划**——
> ① `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md`（GPT：7 Phase / 50 断言）
> ② `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md`（386 行白板整合方案）
> ③ `docs/internal/DECISIONS-20260914-SESSION.md`（本会话 8 条裁决 + 三处前提推翻）
> **调和过程**见 `docs/internal/MERGE-CONFLICT-SCAN-20260914.md`（4 冲突 / 5 重叠 / 4 互补 / 3 悬空）。
> **这份文档不是**：不是施工完成报告；所有内容均为**待施工设计**，代码尚未改动。
> **用法**：先交 GPT 复核（§8 列出要它审的 6 件事），复核通过后按阶段开工。

---

## 0.5 v2 修订（2026-09-14 深夜 · GPT 第三轮复核后生效）

> 第三轮复核的**逐条核实与采纳记录**见 `docs/internal/reviews/ROUND3-REVIEW-INTEGRATION-20260914.md`。
> 该文件是本总纲的**组成部分**：本节只列"改了哪几处"，细节以该文件为准。
> **复核总裁决：方向成立，但"总纲不能原样作为施工依据"——本 v2 即为其修订结果。**

**我方三处实质错误（已改）**：
1. **归因错误**：把"单会话快照"算到了 GPT 头上 —— 实际写那句话的是 `WB-GRAPH-INTEGRATION-PLAN.md:42`。GPT 自己的 `SnapshotRef` 带 `workspaceKey`、`writePlanSnapshot` 收 `projectDir`，**本来就是按工作区定位的**。共享图裁决**结论不变**，但理由改为"**调整持久数据与会话执行态的分工**"。
2. **判据错配**：**H1–H4/S1–S4 是"交接账本"的判据，不能整体套给 PLAN**；PLAN 用 **P-H1/P-H2/P-S1** + 卡片完整性 + 用户区保护。
3. **真源自相矛盾**：裁决记录写用户级 `MEMORY.md`，本总纲 Phase 6 写新增 `RULES.md`。**已统一为：既有用户级记忆中的类型化规则为唯一真源**；`RULES.md` 若生成，**只作单向派生视图**。

**六处关键设计修正（已改）**：
4. **写入门 ≠ 注入边界**：写入门阻止**破坏源数据**，状态过滤阻止**不应使用的数据进上下文** —— 同阶段交付，但是**两个独立检查**。
5. **并发不是"不加锁"就够**：`expectedDigest` **必须在提交边界内检查**（保留现有 `_queue` 短队列，`replace` 已在队列内检查 ✓）；两个写者都先读 D 再各写 A/B 的时序**真实存在**。
6. **预算改为分项账本 + 选 (ii)**：规则与参考**分开预算，但只保留一个组装器、一本账**。`R`（规则实际长度，无魔数）+ `Bm` + `Bo`；**明确代价：不再承诺"全部动态内容有与规则规模无关的固定上限"**。
7. **Phase 6 拆成 6A / 6B**：6A（表达 + 既有节奏接线）紧随 P0；6B（分类持久化、规则修改撤回、跨窗口失效）接在 P1 上 —— 因为 **6B 不能绕过状态提交**。另：`Number(v) || 5` 使 **`0` 无法表达**（`index.js:7455`），须修零值解析。
8. **T7-4 关键词强制升级被我方过度设计**：`"文档写着必须重启"`、`"曾经要求必须 X 但已取消"` 也会命中 ⇒ 改为**只有明确规则来源才进规则层；普通资料命中关键词只产生「待确认候选」**。
9. **精排**：一分钟定义为**有界后台窗口**（从入队起算、到期不续命、仅 `inputKey` 完全匹配才复用、重跑当轮全部检查）；精排用**独立懒加载 worker**，不与稠密查询共进程；**T5-5 是 H1 生成式费用门，不因 H2 变慢而重算**；实测表须**标注候选规模**（qwen 是小样本探针，不可与 bge 直接比）。

**开工顺序（v2，替代 §2 的顺序原则）**：
```
P0 与白板最小适配边界 → P6A → P1 与 P6B → P2 → P3 → P4 → P5
（完整白板线独立推进，在"共同接口"与"最终集成回归"两处汇合）
```

---

## 0. 三句话概括变化

1. **GPT 的 Phase 4 拆开**：通用原则（写入门 / 状态过滤 / 引擎隔离）留在 3.0；白板特有部分（锚点、人机分区、lint、归档）**整体移交独立的白板线**。
2. **新增 Phase 6（注入表达与约束分层）**：这是**用户最痛的病**，而 GPT 与 WB-GRAPH **都没覆盖**——GPT 全在修检索算法，WB-GRAPH 只管白板。
3. **白板从"单会话快照"升格为"工作区级共享图"**（用户裁定），并发用**乐观并发 + 冲突可见**，不加锁。

---

## 1. 目标态（一页图）

```
                       [用户配置 / 预算 / 增强授权]
                                      |
                                      v
   ┌────────────────────── 写入路径 ──────────────────────┐
   │  记忆工具 / 自动沉淀 / 白板→图                        │
   │        ↓                                              │
   │  统一提交门（expectedDigest 校验 + 事务恢复）          │
   │        ↓                                              │
   │  原子写正文 → 更新 sidecar → 提交状态 → 发布新快照 miv │
   │        ↓                                              │
   │  后台增量索引（只编码 miss；按 engineIdentity 隔离）   │
   └───────────────────────────────────────────────────────┘
                                      |
                                      v
   ┌────────────────────── 查询路径 ──────────────────────┐
   │  push / pull → 固定一个 MemorySnapshot                │
   │        ↓                                              │
   │  词法臂（独立扫描）+ 稠密臂（当前引擎）                │
   │        ↓                                              │
   │  current / scope / miv 校验  ←── 【Phase 0 三关之一】  │
   │        ↓                                              │
   │  共同 RRF 排名（排序用）                               │
   │        ↓                                              │
   │  可选精排（多级：关 / int8+CPU / GPU；1 分钟异步窗口）  │
   │        ↓                                              │
   │  fv2 决策（用绝对分，不用融合分）                      │
   │        ↓                                              │
   │  Tier-0 目录 → Tier-1 摘要 / Tier-2 原文               │
   │        ↓                                              │
   │  唯一动态预算组装器                                    │
   │  ├─ 【Phase 6】规则类：每轮注入、不参与裁剪             │
   │  └─ 参考类：受预算约束                                 │
   └───────────────────────────────────────────────────────┘
                                      |
                                      v
                           宿主输出 / 一次交付记账
```

**不变的两条架构事实**（今天实测确认，两条设计线都必须遵守）：
- **排序用融合分，决策用绝对分**——代码已经这么做了（`recall-fusion-pre.js:10-12`），R2 维持现状。
- **注入块前缀稳定、尾部变化**——已经这么做（用户确认），Phase 6 的"规则每轮注入"依赖它命中前缀缓存。

---

## 2. 总体结构

```
【3.0 主体】改 lib/index.js 的检索与注入链
  Phase 0  注入边界（状态 / 版本 / 预算三关 + 写入门前后比对）
  Phase 1  统一状态提交与快照（miv 单源）
  Phase 2  真增量（2A L0 → 2B 块缓存 → 2C 差量传输）+ 引擎隔离
  Phase 3  共同检索、融合与决策
  Phase 4  对照实验与最优档增强（H2 按实测重写）
  Phase 5  分档运行验收与发布（含真实用户兼容档）
  Phase 6  注入表达与约束分层          ← 【新增，建议紧随 Phase 0】

【白板线】独立立项、独立排期、独立回归窗口
  WB-GRAPH P0→P1→P2→P3
  ＋ 并入 lint（R5）· 每卡片人机分区（R6）· 锚点 · archiveAnswerPre
  ＋ 工具数 14→16，三处测试硬锁同步
```

**顺序原则**：
1. **Phase 0 未通过，不接入任何新算法**（GPT 的硬门，保留）。
2. **Phase 6 可提前**——改动小、收益直接（用户最痛的病），**不依赖任何其他 Phase**。建议排在 Phase 0 之后立即做。
3. **白板线与 3.0 主体并行**，但**涉及同一个 `lib/index.js` 的接线串行合并**（WB-GRAPH 已声明此纪律）。
4. **新旧并存 + 开关回退**是**所有阶段**的强制要求（用户裁定；上千用户 ⇒ 必需而非稳妥）。

---

## 3. 八条裁决的落地位置

| 裁决 | 结论 | 落在哪 |
|---|---|---|
| **R1** 排序展示 | **双显示**（相似度 + 融合排序分）；数据已在手（`recall-fusion-pre.js:35`「原始分数逐条保留供审计」），近零成本 | Phase 3（UI 侧） |
| **R2** margin | **维持现状**：融合分只用于排序，决策用绝对分（代码已如此） | 无需改动；Phase 3 只需**带版本** |
| **R3** 预算边界 | **分开算**：记忆条目一个额度；其他动态内容（白板/账本/日历/外部记忆）另一个总额度。**但"规则类不被裁"的具体记账口径（预留 / 两个钱袋子 / 最后才裁）交由 GPT 裁决、我方审核** —— 见 §3.5.1 | Phase 0 / Phase 6 交汇 |
| **R4** 共用契约 | 两档共用流程、字段、判据；允许适配器/数量/预算不同 | Phase 1（全阶段适用） |
| **R5** 白板 lint | **要做**，且要能改、AI 可主动提问 | **白板线 P1** |
| **R6** 人机分区 | **要用户手写区**（每卡片分「模型维护区 / 用户备注区」） | **白板线 P1/P2** |
| **R7** 数值计量 | 定义源记录已批准数值；字符估计只标"估计"，真实 tokenizer 另报 | Phase 0 |
| **第 8 条** 约束分层 | **规则类（用户级 + 工作区级两层）每轮注入、不参与预算裁剪**；参考类走三层漏斗 | **Phase 6（新增）** |

**两条实测修正**（写方案时不能再沿用旧数）：
- 注入预算实测为 **4800**（配置 `injectBudgetChars`），**不是 GPT 假设的 2000**；
- 精排实测 P95 为 **8.8–37.4 秒**（`artifacts/m7-rerank-pre/results.json`），**不是 GPT 假设的 ≤750ms**。

---

## 3.5 用户追加的三条裁定（2026-09-14 深夜）

### 3.5.1 钱袋子（Phase 6 × Phase 0 的交汇）—— **交给 GPT 判，我方审**

用户原话：「我更偏向用 GPT 自己来决定，然后你来审的情况。」

用户提出两条**约束**（这两条决定了 GPT 该怎么选）：

| 顾虑 | 用户原话 | 含义 |
|---|---|---|
| **预留额度那个数字合不合适** | 「我在考虑这个数字合不合适的问题」 | 如果选"一个钱袋子 + 给规则预留一块"，**预留多少**是个新数字，而它没有实测依据 ⇒ 需要 GPT 给出**确定方式**（比例？绝对值？按规则条数算？），不能拍脑袋 |
| **两个钱袋子太复杂** | 「我怕工程因为太复杂容易出很多 bug，改半天成本太高」 | **反对为了优雅而增加实现复杂度**；上千用户 ⇒ bug 成本被放大 |

**因此这一条不作为我方结论写入总纲，而是原样写进第三轮复核提示词的 Q3**，并附上述两条约束。我方保留**审核权**：它给的方案要能通过"落点到函数名 + 能红断言 + 回滚动作"三关。

### 3.5.2 Phase 6 的节奏部分 —— **本质是改设置默认值**

用户原话：「这个其实就是改个设置的问题。设置已经有相关的了，只要把默认的情况改成每轮注入都没问题的。」

**核实：成立。** `snapshotMinGapRounds` 已是现有配置项（`lib/index.js:326`，当前默认 **5**），注入间隔逻辑也已实现（`:7455`）。所以"规矩每轮在场"的**节奏部分**＝把默认值改成 `1`（或 `0`＝不设间隔），**属配置默认值变更，不是新机制**。

**但必须分清三件事，不能混为一谈**：

| 子项 | 是不是"改设置" | 说明 |
|---|---|---|
| **节奏**（每轮注入） | **是**——改默认值即可 | 用户判断正确 |
| **措辞**（"只是参考"降格） | **不是**——改代码 | `lib/index.js:463` 的开场白要把"规则"与"资料"分开措辞 |
| **分层与预算**（规则不被裁） | **不是**——改代码 + 需定预算口径 | 即 §3.5.1 交给 GPT 的那条 |

**结论：Phase 6 的原地成本比原先估的低**（节奏部分一行默认值），但**措辞与分层两部分仍是真代码**。总纲据此把 Phase 6 的"改动量"下修，其余不变。

### 3.5.3 白板线 —— **同意"先拍 15 个待定点"，并确认耦合是具体的而非泛泛的**

用户问：「我觉得第一个回答就先拍这 15 个待定点是正确的。它和我的记忆应该是紧密啮合的，应该是提前或者一起做的。你同意我的看法吗？」

**我方答复：同意，且可以把"紧密啮合"说得更准——它是具体映射，不是感觉。**

| WB-GRAPH 待拍板点 | 与 3.0 的具体啮合 |
|---|---|
| **B1**（丢卡风险 / 卡片集合比对） | **＝ 3.0 Phase 0 的写入门**（同一件事，必须一起定，否则会各做一套） |
| **B5**（双状态源：账本 ↔ 看板） | **＝ Phase 1 的 `miv` 语义**（"现状唯一事实源"若定错，`miv` 的摘要对象就错） |
| **B4**（人机分区） | **＝ Phase 0 写入门要保护的"用户区"**（不定，写入门就不知道该拒绝什么） |
| **A8**（条目锚点是否做） | **＝ 白板进语料的前提**（没有锚点，白板内容进不了 L0 检索） |
| **A2**（sidecar 位置） | 与 Phase 1 的存储布局相关 |

**"提前或一起做"的准确含义**：**决策一起定**（不这么做，Phase 0 会先做一版写入门，白板线再做一版），但**实装按归属分两条线**——因为白板线会改工具数 14→16 并触发三处测试硬锁，与 3.0 主体共用一个回归基线会互相污染。

**下一步**：拍这 15 个待定点，属于**独立的一件事**，不阻塞 GPT 复核（复核针对的是 3.0 主体与调和结果）。

---

## 4. 3.0 主体：七个阶段

> 每阶段沿用 GPT 的六项结构（目标 / 改动点 / 能失败断言 / 回滚 / 成本 / 风险），此处只写**调和后的变化**；未变化部分以 `PLAN-gpt6astra-round2-20260914.md` 为准，**断言编号保持可追溯**。

### Phase 0 · 注入边界（状态 / 版本 / 预算三关 + 写入门）

**目标**：最终输出同时守住**状态、版本、完整条目、总预算**四条约束。

**调和后的改动点**：

| 项 | 来源 | 变化 |
|---|---|---|
| 状态过滤（T0-1） | GPT | **已实测 4/4 报红**（`tools/_redproof/red-proof-phase0-t01.mjs`）——`superseded` / `retracted` 条目**现在真的会进注入**。修复后把该脚本移入 `tests/smoke/` |
| 版本校验（T0-2） | GPT | `recordTierGateHits` 投影携带 `miv/contextVersion/requestKey`，不得仅凭时间复用（现行 `lib/index.js:3894` 只查时间） |
| 预算单一口径（T0-3） | GPT | 现行两处缺陷：`tier-layer-inject-pre.js:327–335` 只裁下探段、裁剪后又追加降级行；`index.js:3986` 扣账成本被 35% 封顶而目录按全文注入 |
| **写入门前后比对** | **GPT + WB-GRAPH B1 合流** | 白板内容进语料前必须过门；**格式判据采纳 WB-GRAPH 的完整判据表**（H1–H4 硬 / S1–S4 软），给每条补**能红断言** |
| **数值守卫范围（T0-6）** | GPT | `smoke-test-doc-code-consistency-pre.mjs:149` 现只列 7 字段，未覆盖 `L1`/`K` 等 |

**能失败断言**：沿用 T0-1…T0-7，**新增 T0-8**（写入门：卡片集合消失且无 archive 记录 → 拒写）。
**回滚**：`memoryInjectionMode='catalog-only'` + 关闭 `memoryEvidenceBlocksEnabled`。
**成本**：额外 LLM token 为 0；每 runtime 只保留一个当前准备结果。
**风险**：唯一动态出口可能改变宿主去重与交付时机。

---

### Phase 1 · 统一状态提交与快照

> **变化点**：R4（共用契约）与**冲突 1（白板 = 共享图）**影响此阶段。

**调和后的变化**：
- `expectedDigest` 机制**升级用途**——不仅防"用户改了白板"，还防**"另一个窗口改了图"**（乐观并发，不加锁）。
- `miv` = 内容身份 + 状态清单摘要，**哈希身份、不递增、不比较**；WB-GRAPH 的 `index.json` 里 `rebuilt_at` **不得**被当作版本序（需按此校准）。
- 白板的 `Cue(session)` 进图：**同一张图上有多个 Cue 节点**（接续链上每个会话一个）——GPT 完全没有这层。
- `T1-5`（仅状态变化时 `miv` 必变）**保留**，并**扩展到白板**：白板卡片状态变化也必须改 `miv`。

**能失败断言**：T1-1…T1-6 **+ T1-7**（另一窗口持有旧 digest 时提交被拒，且**拒绝信息可见**，不静默覆盖）。
**回滚**：`memoryMutationMode='readonly'`。

---

### Phase 2 · 真增量 + 引擎隔离

> **变化点**：**悬空 2**（引擎隔离 + 进度条）在此落地。

**调和后的变化**：
- 2A→2B→2C 三小步**保留**（先证明计算增量，再承担协议变更）。
- **T2-9 引擎隔离（新增）**：用 e5 建的索引，切到 bge-m3 后**必须整体失效并重建**；若两套向量参与同一次排序，**判失败**。成本为零（仅加身份校验）。
- **用户补充**：切换时**强制全量重建 + 进度条**；**进度条必须并进现有引导体系**（Python BGE 下载 / venv 建环境已有可视化指导），**不得另起一套**——这是用户明确点出的耦合风险。
- C7 的两级引用（`engineIdentity + chunkId → alias → hash(exactEncoderInput) → 向量对象`）**保留**：它绕开了"改一块则全记录块 ID 全变"的问题，且**不改现有 `chunkId` 公式**。

**能失败断言**：T2-1…T2-8 **+ T2-9**（引擎隔离）。
**回滚**：`indexDeltaSyncEnabled=false` → `embeddingCacheV2Enabled=false`；旧、新缓存目录**均不就地覆盖**。

---

### Phase 3 · 共同检索、融合与决策

> **变化点**：R1（双显示）与 R2（维持）都在此收口。

**调和后的变化**：
- **R1 双显示**：`RankedHit` 已同时携带 `denseScore`（绝对，决策用）与 `fusionScore/fusionRank`（相对，排序用）——UI **两个都显示**，相似度在前、融合分在后。因为**没拿融合分冒充相似度**，与 S5.4 的冲突不存在。
- **R2 维持**：融合分**只用于排序**，决策用绝对分 + 校准阈值；新策略消费**带版本**的融合间隔，**必须重新校准**。两档 margin 尺度不同（实测：bge-m3 的 0.03 用在 e5 上会**拦掉全部候选**，`lib/index.js:7254`）。
- 词法臂**必须独立扫描**（不能只给稠密 top-K 打词法分）。

**能失败断言**：T3-1…T3-7（含秩不变性、顺序贯穿、臂独立、决策一致）。
**回滚**：`retrievalPipelineMode='shadow' | 'off'`。

---

### Phase 4 · 对照实验与最优档增强（H2 按实测重写）

> **变化点**：**悬空 3**——H2 的预算被实测推翻，整块重写为多级选项。

**调和后的变化**：

| | GPT 原设计 | **调和后（依实测）** |
|---|---|---|
| 精排延迟预算 | ≤750 ms | **实测 P95：bge 37.4 秒 / qwen 8.8 秒** |
| 触发时机 | 自动注入同步等待 | **仅主动翻记忆时**（默认）；自动注入走 **1 分钟异步窗口** |
| 档位 | 单一 | **关 / 快档（int8+CPU）/ 发烧档（完整模型 + RTX 4070 Ti SUPER）** |

- 收益真实：recall@1 **0.739 → 0.898**（bge）/ 0.800（qwen）。
- **模型资产不缺**：bge-reranker-v2-m3（2.1GB）、qwen3-reranker-0.6b（1.1GB）**已下载**，各带 tokenizer ⇒ GPT 的 **U5「阻塞」判定作废**。
- **U5 的真实缺口**变成：**GPU 版 torch**（当前 `torch 2.13.0+cpu`，有卡但未用上）。
- 实验顺序 5A→5B→5C→5D（单独归因）**保留**；断言 T5-1…T5-8 保留，**T5-5 费用门按新预算重算**。

---

### Phase 5 · 分档运行验收与发布

> **变化点**：**悬空 2**——真实用户约束必须落进验收。

**调和后的变化**：
- **兼容档必须实测**：登记设备与负载，测冷启动 / P95 / RSS / 峰值 / 磁盘 / 索引积压年龄。
- **错误提示面向用户**（不是面向作者）。
- **切档进度条属必需品**（并进引导体系）。
- **发布材料逐项记录通过 / 失败 / 未执行**——不把"没测试环境"写成"已验收"。
- 断言 T6-1…T6-7 保留，**T6-3 资源界限必须事前登记**。

---

### Phase 6 · 注入表达与约束分层【新增】

> **这是本会话最重要的产出**，GPT 与 WB-GRAPH 都没覆盖。

**目标**：让"规矩"真正约束模型行为——**它在场、它醒目、它不被裁掉**。

**病症（两条独立病因，均有代码行号）**：

| | 病因 | 证据 |
|---|---|---|
| **A. 措辞** | 注入开场白把"规矩"与"资料"统一降格为「只是背景事实与规则参考」；且写在最醒目的开头位置却写着"别太当真" | `lib/index.js:463` |
| **B. 节奏** | `snapshotMinGapRounds = 5` ⇒ **规矩在第 2–5 轮不在场**；模型不是不听话，是**没收到** | `lib/index.js:326`、`:7455` |

**用户原话（决策依据）**：
> 「这个 just for reference 说得太轻了，模型注意力没有在这上面。」
> 「模型自动唤起的记忆，并没有对模型的工作起到比较实质性的影响。」

**改动点**：

| 文件 / 组件 | 改动 | 类型 |
|---|---|---|
| `lib/index.js:463` 注入开场白 | 拆成两类措辞：规则类用**约束语**（"以下为必须遵守的约束"）；参考类保留"参考"语义 | 替换 |
| 规则文件（新增，两层） | 用户级 `~/.dsh/memory/RULES.md`（跨工作区恒定）+ 工作区级规则文件（换工作区即换） | 新增 |
| 预算组装器 | **规则类不参与任何裁剪**（R3 的额度只约束参考类） | 替换 |
| 注入节奏 | 规则类**每轮注入**；参考类维持现有间隔 | 接线 |
| `memory_log` 写入路径 | 写入时**顺手打 `kind` 标记**（rule / preference / fact / todo）——**不做独立 LLM 调用**（`memory_log` 本就是本轮内直接写，零额外成本） | 扩展 |
| 前缀双保险 | 出现 `【用户硬性规则】`/「严禁」/「必须」/「绝不」等字样 ⇒ **无论 AI 怎么判，强制进规则类** | 新增 |
| 约束视图（UI） | 记忆窗格新增一页显示"当前模型受什么约束"，可精修（现有 12 个标签页**没有任何一页**做这件事） | 新增，归 UI 提质排期 |

**能失败断言（新增 T7-1…T7-6）**：
- **T7-1 规则在场**：连续 6 轮对话，**每一轮**注入文本中规则类内容都在（现行代码在第 2 轮起消失）。**注意：节奏部分只需把 `snapshotMinGapRounds` 默认值由 5 改为 1**（配置项已存在，`lib/index.js:326`），无需新机制。
- **T7-2 规则不被裁**：把参考类内容撑到超预算，规则类**仍完整出现**，且最终输出长度合规。
- **T7-3 措辞分层**：规则类与参考类在注入文本中**用不同的引导语**；断言两者引导语不相同（防止改回统一措辞）。
- **T7-4 分类双保险**：构造一条含「必须」但 AI 未标记的记忆，断言它**仍进规则类**。
- **T7-5 零额外调用**：打标过程**不产生任何新的 LLM 调用**（用调用计数断言）。
- **T7-6 缓存友好**：规则块位于注入前缀且内容不变时，**前缀字节稳定**（断言连续两轮的前缀部分完全一致）。

**回滚**：`rulesLayeringEnabled=false` → 回退到统一措辞 + 原有间隔。
**成本**：**规则几乎不变 ⇒ 位于前缀 ⇒ 命中前缀缓存（约原价 1/10）** ⇒ 每轮注入的边际成本极小。
**风险**：AI 分类**漏判**是不对称的（真规则被判成"偏好"就掉进参考类，**而这正是要修的病**）⇒ 故有 T7-4 的前缀双保险。

---

## 5. 白板线（并入 WB-GRAPH，独立立项）

**为什么独立**：它不是 3.0 的一个阶段，而是**另一条产品线**——
- 它有独立的 386 行方案与自己的拍板点（A1–A8 / B1–B7，**多数仍未拍板**）；
- 它**会改工具数 14→16**，触发**三处测试硬锁**（`smoke-test.mjs:67`、`smoke-test-m3b3-pre.mjs:43`、`smoke-test-context-observer.mjs:107`）；
- 它是**用户最在意的接续体验**（"dsh graph 正是我想要的 Karpathy 模块"）。

**从 GPT 方案并入的部分**（详见矛盾扫描 §2 冲突 2）：

| 原属 | 内容 | 归属 |
|---|---|---|
| Phase 4 | 写入门前后比对 | **留 3.0 Phase 0**（属注入边界） |
| Phase 4 | 状态过滤（C8） | **留 3.0 Phase 0** |
| Phase 4 | 锚点 + 人机分区（每卡片） | **白板线 P1/P2** |
| Phase 4 | lint（R5） | **白板线 P1** |
| Phase 4 | `archiveAnswerPre` 结论归档 | **白板线 P3**（需图的遍历能力） |

**必须补的一件事**：WB-GRAPH 的判据表（H1–H4 / S1–S4 / P-H1 / P-H2）**没有配套断言** ⇒ **给每条判据补一条能红的 node 断言**（这是 GPT 方案的纪律，必须移植过来）。

**已知现状缺口（今天实测）**：`WB-FORMAT-CONVENTION.md` §5 **早已定义人机分区**（`<!-- model -->` / 用户区），但实际 `PLAN.md` **一个锚点、一个分区标记都没有**——**规范已批准、代码从未实现**。这正是"白板被整篇覆盖成骨架"事故的根因。

---

## 6. 交付纪律（贯穿所有阶段）

1. **能失败断言**：每条改动必须给"跑什么 / 看到什么算过 / 看到什么算失败"，且**必须能写成 node 断言**（`tests/smoke/*.mjs`，零依赖、串行、非零退出即失败）。**跑不红的断言等于没有断言**——本轮已用 `tools/_redproof/` 演示过这条纪律。
2. **新旧并存 + 开关回退**：每个阶段一个开关，默认关，出问题一键回退（用户裁定；上千用户 ⇒ 必需）。
3. **回滚动作**：每阶段必须写明"还原哪个文件 / 关哪个配置键"。**没有回滚的阶段不许开工。**
4. **落点到函数名**：改动点必须写 `文件:函数名`；行号会飘，函数名不会。
5. **承重守卫纪律**：新增守卫**必须演示变红后再按字节还原**（本项目已三次被"源码接线守卫 ≠ 行为断言"咬到）。
6. **上游同步冻结**：修复只留开发端，**不主动开 PR**（用户裁定）。

---

## 7. 未决与待补

| 编号 | 内容 | 阻塞什么 |
|---|---|---|
| **U1** | 作者与最低兼容设备、语料规模、写入负载、性能预算 | 阻塞性能认证；不阻塞 Phase 0–4 |
| **U2** | 是否多宿主共享同一记忆根目录 | 已有上千用户 ⇒ **这条从"可选"变成"必须查"**；未确认时按单写 owner 设计 |
| **U3** | 评测题集与标准答案 | 用户答复：题集是**很早期初创算法时做的**，需**结合已有记忆重建一套**（用户记忆量已很丰富）。建议：**从真实记忆语料出发出题**，而非凭空造题 |
| **U4** | LLM 服务的计费输入 / 输出上限 / usage / 取消语义 | 阻塞 H1/H3 在线启用 |
| **U5** | ~~cross-encoder 模型资产~~ **已不缺**（两个模型都已下载）；**真实缺口 = GPU 版 torch**（当前 CPU 版，有卡未用） | 阻塞 H2 的 GPU 档 |
| **U6** | 宿主最终请求确认 / 去重 / 尾注交付语义 | 阻塞"模型请求确实含该内容"的发布声明 |
| **U7** | 真实 tokenizer 计量入口 | 阻塞真实 token 硬上界声明 |
| **白板线 A1–A8 / B1–B7** | WB-GRAPH 的 15 个拍板点，多数仍标 🎯 未拍板 | 阻塞白板线开工（**不阻塞 3.0 主体**） |

---

## 8. 交 GPT 复核的六个问题

> 复核提示词将围绕这 6 个问题写。**核心立场：让它审「调和是否正确」，不是审「你跟我哪里不一样」**——后者是已知信息（因为我投喂时漏给了 WB-GRAPH 方案，这是我的操作失误，已留痕）。

| # | 要它审的问题 | 为什么它最有发言权 |
|---|---|---|
| 1 | **Phase 4 拆分的边界对不对**：把"写入门 + 状态过滤"留 3.0、其余移交白板线，是否切错？ | 它对代码结构最熟，最容易看出切错 |
| 2 | **"白板 = 工作区级共享图"** 这个前提变了之后，Phase 0/1 的哪些设计要跟着改？ | 它自己的设计建立在"单会话"上 |
| 3 | **新增 Phase 6（约束分层）与它的注入预算设计是否冲突**？规则"不参与预算裁剪"会不会破坏 `FinalEnvelope` 的单一记账口径？ | 这是两条设计线**真实的交汇点** |
| 4 | **H2 按实测重写后**（8.8–37.4 秒 + 1 分钟异步窗口 + 多级档位），Phase 3/5 的哪些断言要改？ | 它写死了 ≤750ms，需它自己重算 |
| 5 | **引擎隔离 T2-9 + 切档进度条**在它的 `engineIdentity` 两级引用上该怎么落？ | 它设计了 `engineIdentity` 但没做硬约束 |
| 6 | **白板线工具数 14→16** 会不会污染 3.0 的回归基线？ | 它主张"工具数不变"，需它自己评估 |

**另外要它回答的一件事**：本总纲**是否遗漏了它原方案里必须保留、但被我在调和时误删的内容**。（这是防止我方调和造成信息损失的兜底问法。）

---

## 9. 附：本总纲引用的文件

| 文件 | 角色 |
|---|---|
| `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` | GPT 第二轮交付（7 Phase / 50 断言） |
| `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md` | 12 条主张核实（12/12 成立） |
| `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md` | 白板整合方案（386 行） |
| `docs/internal/WB-GRAPH-DECISIONS-20260914.md` | 白板拍板点（15 项） |
| `docs/internal/DECISIONS-20260914-SESSION.md` | 本会话 8 条裁决 + 三处前提推翻 |
| `docs/internal/MERGE-CONFLICT-SCAN-20260914.md` | 矛盾扫描（4 冲突 / 5 重叠 / 4 互补 / 3 悬空） |
| `tools/_redproof/red-proof-phase0-t01.mjs` | C8「能红」证明（4/4 报红） |