# 矛盾扫描：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 的三条悬空是**本次会话新发现**，尚未经任何外部审阅。