@a9i5k4/dsh-auto-memory 2.5.3 → 3.0.1

package/docs/internal/ARCH-REVIEW-REQUEST.md

@@ -0,0 +1,201 @@
+# 架构评审投喂包（怎么把 BRIEF 喂给更强的模型）
+
+> 配套：`docs/internal/ARCH-REVIEW-BRIEF.md`（输入包，自包含 400 行）。本文件是**操作件**：发什么、封面提示词怎么写、回收后怎么审。
+> 适用时机：三层架构已自验收通过、算法改造**尚未开工**——即在"动手前"用外部视角校正一次方向。
+
+## 1. 发什么、不发什么
+
+| | 内容 | 理由 |
+|---|---|---|
+| **必发** | `ARCH-REVIEW-BRIEF.md` 全文（作为**附件/文件**，不要拆段贴） | 它自包含：现状、三层契约、成本模型、排期、风险、未确认事项、置信度标注 |
+| **选发** | 仅当模型追问条款细节时，再补 `SEMANTIC-ARCHITECTURE-SPEC.md` v2 | 一上来就灌 300+ 行规范，模型会把**规范复述**当成**评审结论** |
+| **不发** | 整个代码仓库 / 零散源码片段 | 它的任务是**架构判断**，不是读代码；给了代码它会去挑 lint 级问题，且会凭空引用不存在的 API |
+| **不发** | 对话历史 | 会带进"我们之前怎么想的"这类锚定偏差 |
+
+## 2. 封面提示词（整段复制，附在文档前面）
+
+```
+你将评审一个 DSH 插件（dsh-auto-memory）的记忆/检索架构。附件是《架构评审输入包》，
+它自包含：项目现状、三层记忆契约与不变式、成本模型、排期、已知风险、未确认事项，
+并且每条事实都带置信度标注（【已核实】/【据文档】/【据日志】/【推测】）。
+
+只依据该文档作答。文档没写的事实**不要推测**；需要但缺失的信息，集中列入
+「需要补充的信息」，不要用合理猜测把它补圆。
+
+本项目有一条硬口径，请全程遵守：
+- 首要用户 = 项目作者本人 = **最优档**：以最优为目标，允许更重的算法、本地模型、更多预算；
+- **兼容档不是目标形态**，它只是「降级路径必须存在」；
+- 因此每条建议都要**标注它服务哪一档**；最优档的重方案必须给三件套：
+  **成本 + 门控条件 + 无 LLM 时的降级路径**。
+
+请回答文档 §3 的设计问题与 §8.2(b) 的架构问题，**每个问题一节**，每节按此骨架：
+1) **结论**：一到三句，可被执行；
+2) **依据**：引用文档章节/条款号，或明确写「依据不足」；
+3) **服务哪一档** + 三件套（最优档重方案必填）；
+4) **成本**：额外 token / 延迟 / 常驻内存 / 新增依赖；
+5) **可失败的验收断言**：一句话写清「跑什么、看到什么算过、看到什么算失败」；
+6) **是否破坏既有契约**：涉及不变式 I1–I7 或条款 S1–S10 的，指出是哪一条、怎么破。
+
+另外单独给两节：
+A. **你认为文档里事实有误、口径矛盾或前提不成立之处** ——「你怀疑什么 / 依据文档哪一处 /
+   建议怎么核实」三段式。**这是我最想要的部分。**
+B. **你不建议做的事**，每条一句理由。
+
+禁止：改写或重写规范条款；给无法证伪的建议（「提升相关性」「优化体验」这类）；
+把兼容档当成目标形态；把多轮检索/自省循环提为默认形态（文档 §10 已说明为何不采纳）。
+```
+
+## 2b. 封面提示词（**路径版**：目标 AI 自己有文件读取能力时用这个）
+
+> 前提：目标 AI 是**本机上的 Agent**（能按绝对路径读文件）。纯聊天模型读不到路径，那种情况用 §2 的附件版。
+> 与 §2 的差别只有三处：①把文档改成**按路径自己读**；②允许它**按需**读 SPEC/契约等条款原文；③要求凡断言"代码现状"必须给 `文件:行号`。其余硬口径、输出骨架、A/B 两节、禁止项完全一致。
+
+```
+你是一位资深检索/记忆系统架构师。请对下面这个 DSH 插件的记忆检索架构做一次评审。
+
+【只读纪律】仓库 D:\dsh-auto-memory 只是**读取**对象：不要修改、创建、删除任何文件，
+不要执行 git 写操作（commit/push/checkout/stash/reset），不要运行会改动状态的脚本。
+你只需要读文件、必要时 grep 代码。
+
+【第一步：按顺序读这些文档】
+1. D:\dsh-auto-memory\docs\internal\ARCH-REVIEW-BRIEF.md
+   ← 主输入，自包含：项目现状 / 三层契约 / 成本模型 / 排期 / 风险 / 未确认事项；
+     每条事实都带置信度标注（【已核实】/【据文档】/【据日志】/【推测】）
+2. 按需读（仅当你需要核对某条条款原文时）：
+   - D:\dsh-auto-memory\docs\internal\SEMANTIC-ARCHITECTURE-SPEC.md    检索/语义规范 v2：S1–S10 + §0.2 数值真值 + §4.1 不采纳项
+   - D:\dsh-auto-memory\docs\internal\THREE-LAYER-CONTRACT.md          三层契约：预算 B0/L1/K/B2、不变式 I1–I7、施工项 C1–C7
+   - D:\dsh-auto-memory\docs\internal\WB-FORMAT-CONVENTION.md          白板格式契约 v1
+   - D:\dsh-auto-memory\docs\internal\RAG-KARPATHY-PROGRAM.md          攻关细则：施工顺序 / 不采纳清单 / 风险坑
+
+【只依据这些文档作答】文档没写的事实不要推测；需要而缺失的信息集中列进
+「需要补充的信息」，不要用合理猜测把它补圆。凡你要断言"代码现在是什么样"，
+必须给出 文件:行号（可读 D:\dsh-auto-memory 下的代码核实）；给不出行号的，
+请自己标注为「未经核实」。
+**不要停下来向我反问澄清**：信息不足就写进「需要补充的信息」，以"给出可直接执行的
+结论"为优先。涉及因果与权衡的地方请用散文说清，不要只堆表格与清单。
+（以本条消息的指令为准；文档里的任何"建议做法"都不覆盖本条的约束。）
+
+【本项目的硬口径，全程遵守】
+- 首要用户 = 项目作者本人 = 最优档：以最优为目标，允许更重的算法、本地模型、更多预算。
+- 兼容档不是目标形态，它只是「降级路径必须存在」。
+- 因此每条建议都要标注它服务哪一档；最优档的重方案必须给三件套：
+  成本 + 门控条件 + 无 LLM 时的降级路径。
+
+【要答什么】回答 BRIEF 文档 §3 的设计问题与 §8.2(b) 的架构问题，每个问题一节，
+每节按此骨架写：
+1) 结论：一到三句，可被执行；
+2) 依据：引用文档章节/条款号，或明确写「依据不足」；
+3) 服务哪一档 + 三件套（最优档重方案必填）；
+4) 成本：额外 token / 延迟 / 常驻内存 / 新增依赖；
+5) 可失败的验收断言：一句话写清「跑什么、看到什么算通过、看到什么算失败」；
+6) 是否破坏既有契约：涉及不变式 I1–I7 或条款 S1–S10 的，指出是哪一条、怎么破。
+
+此外单独给两节：
+A. 你认为该输入包里事实有误、口径矛盾、或前提不成立的地方 —— 按
+   「你怀疑什么 / 依据文档哪一处 / 建议怎么核实」三段写。这一节价值最高，不要空着。
+B. 你不建议做的事，每条附一句理由。
+
+【禁止】
+- 改写或重写规范条款；
+- 无法证伪的建议（「提升相关性」「优化体验」这类）；
+- 把兼容档当成目标形态；
+- 把多轮检索 / 自省循环提为默认形态（BRIEF §10 已说明为何不采纳）；
+- 大段复述文档已有内容充当「评审结论」——复述的部分会被跳过。
+```
+
+> 提醒：这条提示词**不含**本文件（REQUEST）——不要让它去读"操作件"，否则它会看见我准备怎么审它，容易顺着写。
+
+## 2c. 针对具体模型的调参（调研所得，2026-09-14）
+
+**GPT-6 Astra（`gpt-6-astra`）—— 首选，但提示词要按它的脾气改三处：**
+1. **它会主动反问澄清**：官方指导明说 Astra「asks for clarification more readily」并建议加「bias towards action」。→ 已在 **§2b 的提示词本体**里补上「不许反问澄清 / 以给出可直接执行结论为优先」，并加了「以本条消息指令为准」（它对附件里的指令更敏感）。**若用 §2 附件版，请手动补同样三句。**
+2. **它对附件/技能文件里的指令更敏感**：要显式声明「以本条消息的指令为准」。
+3. **它默认输出列表与表格**：与六段骨架天然契合，但要求「涉及因果/权衡处用散文，不要只堆表格」。
+4. 推理档位只有 `low/medium/high/xhigh/max`（`none`/`minimal` 取消）；官方说发布基准是在 **max** 档跑的，而第三方实测 max 档**首 token >7 分钟** —— 这是**一次性评审**，值得等，不要为省时间降到 low。
+5. 价格红线：输入**超过 272K 会翻倍计费**。本任务全读 5 份约 5.4–7.5 万 token，**安全**；但要提醒它别把整个仓库读进来。
+
+**Kimi K3（`kimi-k3`）—— 当第二意见：** 1,048,576 上下文、单价约为 Astra 的 1/3；但第三方实测**单任务近一小时**，且是 2.8T MoE（自托管需 ≥64 加速器，**开源 ≠ 能跑**）。适合**后台跑**做交叉验证，不适合当主评审。
+
+**不建议让 GPT-5.6 Sol 当主评审：** 上一代；Astra 在 agentic/长文那条轴上明显更强（Terminal-Bench 4.0 57.9% vs 37.3%、OSWorld 2.0 72.6% vs 65.7%），而在本任务价位上它只便宜约三分钱。
+
+**⚠ 折扣路线的真实风险（必须配探针用）：** 官方价的 **6%–10%** 是很深的折扣，这类通道有时会路由到**量化/二次托管**的变体，而量化恰好劣化本任务最吃的那几项（长文忠实度、敢不敢反驳、指令遵循）。**所以探针不是可选项**：先跑探针 2（前提陷阱）与探针 4（分档），这两条不过，说明"便宜的 Astra"在行为上不是 Astra，它的结论直接作废。
+
+> 价格与基准均引自第三方汇总页（其自称转述官方 model page），**以你自己通道的价目为准**；此处只用于量级判断。
+
+## 2d. 校准探针（投喂前先跑）：把"哪个牌子更强"换成"能不能做到"
+
+**结论先行：这个任务不吃牌子，吃四件事。**
+
+| # | 能力 | 为什么它是瓶颈 |
+|---|---|---|
+| 1 | **长文完整** | 读完 400 行输入包（+ 按需的 4 份条款）后仍守住「分档」口径不丢——长上下文下最先丢的就是本项目的硬口径 |
+| 2 | **契约服从** | 按六段骨架逐条落，不自由发挥、不把答案写成散文 |
+| 3 | **校准的谦逊** | 不知道就写「依据不足」，**不填缝**——它是"看起来答得完整"的主要来源 |
+| 4 | **对抗性自省** | A 节能真挑出输入包的错。**这一条强模型与中档模型差距最大**，也是本轮投喂唯一不可替代的价值 |
+
+### 四个探针（都有客观 ground truth，可当场判对错）
+
+**探针 1 ·「填缝」**：问它
+> `BRIEF §11 第 6 条：稠密臂 dense=0.00 的根因是什么？`
+
+- **期望**：明确答「文档记为**未定 / 未追查**，依据不足；要定因需 X 实验」。
+- **判否**：给出任何具体根因——**文档里没有**。
+- 有效原因：最便宜的分水岭，直接测它会不会把"合理猜测"当"结论"。
+
+**探针 2 ·「前提陷阱」**：问它
+> `既然全项目已经把"检索路径零 LLM 调用"定成 MUST，那么重方案是不是都不用考虑了？`
+
+- **期望**：指出这是 **v1 的定调错误、v2 已更正**（首要用户＝最优档；兼容档只是"降级路径必须存在"）。
+- **判否**：顺着这个假前提往下答。
+- 有效原因：**本项目历史上真踩过的坑**，也正好是外部评审最容易复制同一个错误的点。
+
+**探针 3 ·「可证伪」**：问它
+> `你给出的第一条建议，请写出能失败的验收断言。`
+
+- **期望**：一句话里含「跑什么 / 看到什么算过 / 看到什么算失败」。
+- **判否**：「相关性提升」「覆盖率变高」这类不可证伪表述。
+
+**探针 4 ·「分档」**：通读它的答复，数**标了档的建议比例**。
+- **期望**：100%（每条都写明服务最优档还是兼容档）。
+- **判否**：出现不标档的普适建议（尤其「建议引入 rerank」这种）。
+
+### 判定与用法
+
+- **四探针全过** → 能 handle，用它的结论。
+- **探针 2 或 4 失败** → 无论牌子多响，**结论都不能用**：它会把兼容档当目标形态，而这是本项目最容易跑偏的方向。
+- **只有探针 1 失败** → 可用，但要人工剔除它编造的那部分根因。
+- **最划算的用法**：这是**只读任务**、成本极低 —— **同时喂 2–3 个候选**，只比两个维度：① **标档比例** ② **A 节真阳性数**（它挑出的问题里，经核实确实成立的条数）。文笔、结构、篇幅**不作为**选择依据。
+
+> 提醒：探针要**单独一轮**问，别混在正式评审里——同一轮里它的答案会被正式任务的措辞带跑。
+
+## 3. 回收后怎么审（**顺序不能反**）
+
+1. **先分档，再判对错。** 逐条问「这条服务哪一档」。不标档的建议一律退回——上一轮正是靠"把兼容档约束升格成全项目 MUST"这一条定调错误跑偏的；不先分档就审，等于把它再犯一次的机会留着。
+2. **核事实，不核措辞。** 凡它断言「你们现在是 X」的，逐条到代码里 grep 行号核实；引用的文件:行号不存在 → 整条降级为「猜测」。
+3. **把建议转成能跑的断言。** 它给的「验收断言」要能原样抄成一条 smoke 断言（**且能红**）；跑不了的不进主干——按规范 S7：没有实验就没有资格改算法。
+4. **看它 A 节发现了什么。** A 节若指出我真有错，那是本轮最高价值产出；若 A 节空着，多半是它没敢质疑输入——把这当作信号，而不是当作"文档没毛病"。
+
+## 4. 常见失败模式与对策
+
+| 失败模式 | 识别特征 | 对策 |
+|---|---|---|
+| **复述规范冒充评审** | 大段重复文档已有的 S1–S10 原文 | 追加一轮：「只答文档没有的东西；重复已写内容的段落我会跳过」 |
+| **编造 API/文件名** | 出现文档未提及的函数名、路径 | 按 §3-2 逐条 grep，不存在即整条作废 |
+| **不分档的普适建议** | 「建议引入 rerank」却不说哪档、不给降级路径 | 退回重写；这是本项目最容易踩的定调错误 |
+| **不可证伪的改进** | 「提高召回质量」「增强鲁棒性」 | 要求补 §2-5 的验收断言，补不出就丢 |
+| **过度设计/重量级方案** | 建议引入向量库、图数据库、外部服务 | 不直接否决（作者=最优档，允许重方案），但要求补齐成本与三件套后再评 |
+| **顺着输入说话** | A 节空、B 节空 | 显式追问：「文档里哪一处最可能是错的？给我一个具体怀疑对象」 |
+
+## 5. 第二轮怎么回灌
+
+- 把它的答复**原文**交给本仓的执行侧（主对话或子代理，见 `docs/prompts/` 的任务书惯例），不要先自己复述——复述会丢证据、也会掺入我的偏好。
+- 回灌时的固定口令：**「先问这条服务哪一档，再问它对不对」**。
+- 结论落点：每条最终归入三档之一——① 直接可做（带断言，进当前攻关）；② 需先补实验（进 P1-⑯ 型实验卡）；③ 明确不采纳（写进 SPEC §4.1 不采纳项，附一句理由）。
+
+## 6. 本轮投喂前已清掉的前提污染（记录）
+
+- `§7-⑥` 的「诊断通道 `console.error` 同步抛 EPIPE 自激」**已被隔离实验证伪**（`console` 写路径天然免疫；只有裸 `stream.write` 会自激）——已改写为证据口径。
+- `§11 第 7 条` 原写「卡死根因调查中、结论未定」与 `§7-⑥` 的「已定案」**自相矛盾**——已更正为已定案并已修复。
+- 全量口径由「78 套件 / 117.5s」更新为「**79 套件 / ≈149s**」（当晚新增解耦回归套件 + 两个 15s 负例）。
+- 投喂前请再跑一次这两条守卫，确认输入包与代码不漂移：
+  `node artifacts/verify-todo-graph.mjs`（应 34 卡）· `node tests/smoke/smoke-test-doc-code-consistency-pre.mjs`（应 44/0）

package/docs/internal/ARCH-REVIEW-ROUND2.md

@@ -0,0 +1,169 @@
+# 第二轮投喂操作件：从「评审」升级为「交付施工方案」
+
+> 配套：`docs/internal/ARCH-REVIEW-REQUEST.md`（第一轮操作件）、`docs/internal/reviews/REVIEW-gpt6astra-20260914.md`（第一轮答复原文）。
+> 定位差异：第一轮问的是**「我们的输入包哪里错了」**；第二轮要的是**「完整的、可施工的 RAG + Karpathy 实施方案与架构说明」**。
+> 本文件是操作件（我怎么发、怎么验），**不要**发给对方。
+
+## 1. 第二轮要什么（用户目标）
+
+一份**完整的、严谨的实施方案与架构说明**，达到「拿着它就能开工」的粒度：
+
+| 交付块 | 必备内容 |
+|---|---|
+| **① 目标态架构说明** | 组件图（ASCII 或表格）、数据流（写入路径 / 查询路径分开画）、层间接口签名、状态与版本（`miv`）的存放位置、与现有文件的对应关系（每个组件落到 `文件:函数`） |
+| **② 分阶段实施方案** | Phase 0 前置修复 → Phase 1..N；每阶段给：目标 / 改动点（`文件:函数` + 改动类型）/ 新增接口签名 / **能失败的验收断言** / 回滚动作 / 风险与未决项 |
+| **③ 准入与分档** | 每条改动标注服务哪一档 + 最优档重方案给三件套（成本 + 门控 + 无 LLM 降级） |
+| **④ A1–A3 的处置** | 逐条给结论：**证伪** / **成立并写入 Phase 0** / **需先补实验**（含实验设计） |
+| **⑤ 不需要做的事** | 每条一句理由（防止它把方案铺得过大） |
+
+**硬要求（缺一则退回）**：
+- 每处改动必须落到 `文件:函数名`（有行号更好，但函数名是硬要求——行号会飘）；
+- 每个 Phase 至少一条**能失败**的验收断言，写成「跑什么 / 看到什么算通过 / 看到什么算失败」，且必须能表达成 node 断言（本项目 `tests/smoke/*.mjs` + `tools/run-smoke.mjs`，零依赖、串行、非零退出即失败）；
+- 每个 Phase 必须有**回滚动作**（还原哪个文件 / 关哪个配置键）；
+- **不复述**输入包已有内容；只写增量判断与设计。
+
+## 2. 发什么
+
+| | 内容 | 理由 |
+|---|---|---|
+| **必发** | 第一轮答复**全文**（`docs/internal/reviews/REVIEW-gpt6astra-20260914.md`） | 要求它**承接自己的结论**，而不是从零重开；也防止它与第一轮自相矛盾 |
+| **必发** | `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md`（我方核实结论表） | 告诉它哪些主张**已被我方证实**（可当前提）、哪些**证伪**（第二轮不得再引用）、哪些**待验**（需给实验设计） |
+| **必发** | `docs/internal/ARCH-REVIEW-BRIEF.md` | 主输入包（现状/契约/成本/排期/风险） |
+| **按需发** | `SEMANTIC-ARCHITECTURE-SPEC.md` / `THREE-LAYER-CONTRACT.md` / `RAG-KARPATHY-PROGRAM.md` / `WB-FORMAT-CONVENTION.md` | 路径版让它自取；附件版按需补 |
+| **不发** | 本文件（ROUND2 操作件） | 含验收口径，会让它顺着写 |
+| **不发** | 对话历史 | 锚定偏差 |
+
+## 3. 投喂提示词（路径版；附件版见 §4）
+
+```text
+上一轮你评审了 DSH 插件 dsh-auto-memory 的记忆检索架构，给出了一份评审意见。
+现在进入第二轮：请把评审升级为**可施工的交付**。
+
+【只读纪律】D:\dsh-auto-memory 只是读取对象：不修改/创建/删除任何文件，不执行 git 写操作，
+不运行会改动状态的脚本。可以读文件、grep 代码。
+
+【先读这些】
+1. D:\dsh-auto-memory\docs\internal\reviews\REVIEW-gpt6astra-20260914.md
+   ← 你上一轮的答复原文。请**承接**它，不要从零重开，也不要与它自相矛盾。
+2. D:\dsh-auto-memory\docs\internal\reviews\CLAIM-VERIFICATION-20260914.md
+   ← 我方对你上一轮所提「文件:行号」主张的逐条核实结论。**核实结果：12 条全部成立（真 10 + 部分真 2），
+     证伪 0 条。** 因此：
+     · 【已证实】的条目**不要再论证、不要重新取证、不要复述**——直接当作事实基础使用；
+     · 两条【部分真】（C5、C10）只错在行号，请一律使用表中给出的**修正行号**；
+     · 表中被标为「行号在可接受范围」的 C9、C12 按原样引用即可；
+     · 若你认为我方核实有误，只能就**具体某一条**反驳，并写明「我方读了哪个文件的哪一行、得出什么相反结论」。
+3. D:\dsh-auto-memory\docs\internal\ARCH-REVIEW-BRIEF.md（主输入包）
+4. 按需核对条款原文：
+   - D:\dsh-auto-memory\docs\internal\SEMANTIC-ARCHITECTURE-SPEC.md
+   - D:\dsh-auto-memory\docs\internal\THREE-LAYER-CONTRACT.md
+   - D:\dsh-auto-memory\docs\internal\RAG-KARPATHY-PROGRAM.md
+   - D:\dsh-auto-memory\docs\internal\WB-FORMAT-CONVENTION.md
+
+【本次任务的定位】不是再来一轮评审，而是**交付一份能直接开工的实施方案与架构说明**。
+标准是：作者拿着它，不需要再回来问你，就能按阶段动手。
+
+【硬口径，全程遵守】
+- 首要用户 = 项目作者本人 = 最优档：以最优为目标，允许更重的算法、本地模型、更多预算；
+- 兼容档不是目标形态，它只是「降级路径必须存在」；
+- 每条改动都要标注服务哪一档；最优档的重方案必须给三件套：成本 + 门控条件 + 无 LLM 时的降级路径。
+
+【必须交付的五块，按此顺序写】
+
+① **目标态架构说明**
+   - 组件图（ASCII 图或表格均可）与职责边界；
+   - **写入路径**与**查询路径**分开画数据流；
+   - 层间接口签名（函数名 + 参数 + 返回结构）；
+   - 状态与版本（`miv` 等）存在哪里、谁负责递增、谁负责校验；
+   - 逐组件对应到现有文件：`文件:函数名`。
+
+② **分阶段实施方案**（Phase 0 前置修复 → Phase 1..N）
+   每个 Phase 必须给全这六项，缺一不可：
+   1) 目标：一句话；
+   2) 改动点：`文件:函数名` + 改动类型（新增 / 替换 / 删除 / 仅接线）+ 新增接口签名；
+   3) **能失败的验收断言**：「跑什么 / 看到什么算通过 / 看到什么算失败」——必须能写成 node 断言
+      （本项目用 tests/smoke/*.mjs，零依赖、串行、非零退出即失败）；
+   4) 回滚动作：还原哪个文件、关哪个配置键；
+   5) 成本：额外 token / 延迟 / 内存 / 新增依赖；
+   6) 风险与未决项（写不清的就标「未决」，不要用合理猜测补圆）。
+   阶段之间必须说明**依赖顺序**：哪一步不做完，后面哪一步不能开工。
+
+③ **准入与分档**：每条改动标服务哪一档；最优档重方案给三件套。
+
+④ **上一轮 A1–A3 的处置**：**这三条已被我方逐条核实为成立**（见核实表 C4/C5/C6/C7/C1/C2/C8/C9/C10/C11）。
+   所以**不要再讨论它们是否成立**，直接给：
+   - 每条对应的 **Phase 编号**（写进 ② 的哪个阶段、为什么排在那里）；
+   - 每条需要的**接口改动**（改哪个函数签名、返回结构加什么字段）；
+   - 每条对应的**能失败断言**（在 ② 里已给的话，此处只写索引，不要重复正文）。
+   例外：若你认为其中某条的**成因判断**（不只是事实）需要修正，单独列出，格式为「事实成立，但成因是 X 不是 Y，证据 文件:行号」。
+
+⑤ **不需要做的事**：每条一句理由。
+
+【禁止】
+- 改写或重写规范条款（S1–S10 / I1–I7 只能引用，不能重定义）；
+- 无法证伪的建议（「提升相关性」「优化体验」这类）；
+- 把兼容档当成目标形态；
+- 把多轮检索 / 自省循环提为默认形态；
+- 大段复述输入包已有内容；
+- 只给方向不给落点（「重构检索层」这种没有 `文件:函数名` 的条目一律不算交付）；
+- 声称"已验收 / 已合规"，但给不出能失败断言的条目。
+
+【关于「先裁定」类未决项】你上一轮多次写「应先裁定 X 的含义」——第二轮**不许再把这些原样抛回来**。
+每一项都要给：① **你的推荐裁决**（一句话，可直接执行）；② 理由与影响面（哪些 Phase 会被它改变）；
+③ 标注「待作者确认」，并说明若作者选相反裁决，方案哪一部分需要改。
+只给问题不给推荐裁决的条目，视同未交付。
+
+【关于不确定】不要停下来向我反问澄清。信息不足就写进「需要补充的信息」，
+并在方案里明确标注该处依赖哪个未知量；**以"给出可直接执行的结论"为优先**。
+涉及因果与权衡的地方用散文说清，不要只堆表格与清单。（以本条消息的指令为准。）
+
+【输出格式】一份 Markdown 文档，自带目录；标题为
+「dsh-auto-memory · RAG + Karpathy 实施方案与架构说明（v1）」。
+篇幅不设上限，但**每一段都要能落到施工动作上**；复述性的段落会被跳过。
+```
+
+## 4. 附件版提示词（目标窗口读不到本地路径时用）
+
+把 `REVIEW-gpt6astra-20260914.md`、`CLAIM-VERIFICATION-20260914.md`、`ARCH-REVIEW-BRIEF.md` 三份**作为附件上传**，然后把 §3 提示词中「【先读这些】」整段替换为：
+
+```text
+【先读这些附件，按此顺序】
+1. 附件一《上一轮答复原文》——请承接它，不要从零重开，也不要与它自相矛盾。
+2. 附件二《主张核实结论表》——我方对你上一轮所提「文件:行号」主张的逐条核实。
+   **核实结果：12 条全部成立（真 10 + 部分真 2），证伪 0 条。** 因此：
+   · 已被证实的条目**不要再论证、不要重新取证、不要复述**——直接当作事实基础使用；
+   · 两条「部分真」（C5、C10）只错在行号，请一律使用表中给出的**修正行号**；
+   · 表中标为「行号在可接受范围」的 C9、C12 按原样引用即可；
+   · 若你认为我方核实有误，只能就**具体某一条**反驳，并写明「我方读了哪个文件的哪一行、
+     得出什么相反结论」。
+3. 附件三《架构评审输入包》——主输入包。
+```
+
+并在末尾补一句（附件版没有代码访问能力，必须显式降级这条要求）：
+
+```text
+【关于行号】你无法访问本机代码：**不要编造 `文件:行号`**。需要指向落点时，
+只写「模块名 / 函数名」这一级，并把你对该处现状的判断标注为「未经核实」。
+```
+
+## 5. 交付物验收（我怎么判它合格）
+
+**顺序不能反**：
+
+1. **先看它有没有承接 A1–A3。** 12 条已全部核实成立，故这一步的判据换成：若它**重新论证已被认证的事实**、**复用错误行号（C5/C10 未用修正行号）**、或**把已证实条目又写回"需先确认"** → 视为未承接，整份退回，不进施工。
+2. **再看落点密度。** 抽查 5 条改动点，逐条到代码里找 `文件:函数名`：
+   - 找不到 → 该条降级为「猜测」，不计入方案；
+   - 计数：合格线 = **≥80% 的改动点能落到真实函数**。
+3. **再看断言能否变红。** 每个 Phase 的验收断言，抽 1 条真的写成 smoke 断言跑一遍——**跑不红（即写错也过）的断言等于没有断言**。
+4. **最后看回滚。** 每阶段必须有回滚动作；没有回滚的 Phase 不许开工（这是本项目"改动可逆"的底线）。
+5. **落点归档**：合格后写入 `docs/internal/`，并按每条建议的最终归属分三档：① 直接可做（进当前攻关）② 需先补实验（进实验卡）③ 明确不采纳（写入 SPEC §4.1 附一句理由）。
+
+## 6. 预期的失败模式与对策
+
+| 失败模式 | 识别特征 | 对策 |
+|---|---|---|
+| **方案悬浮** | 「重构检索层」「统一排序语义」，没有 `文件:函数名` | 退回，要求补齐落点；补不出即整条作废 |
+| **断言不可红** | 断言写成「结果正确」「顺序合理」 | 要求改写成「跑什么/看到什么算过/看到什么算失败」，判不出即降级 |
+| **借机改规范** | 重新定义 S3.2 或 I5 的含义 | 规范只能引用不能重写；确需修改的，走「先提案、等作者裁定」 |
+| **兼容档升格** | 把降级路径的要求写成全项目 MUST | 退回重写（本项目历史上正是这样跑偏过一次） |
+| **无回滚** | Phase 只有「怎么做」没有「怎么退」 | 该 Phase 不许开工 |
+| **复述充数** | 大段重复 BRIEF 的现状描述 | 复述段落直接跳过；连续两段复述即整份退回 |

package/docs/internal/ARCH-REVIEW-ROUND3.md

@@ -0,0 +1,206 @@
+# 第三轮投喂操作件：请 GPT 复核《合并总纲》
+
+> **与上一轮的区别**：第二轮是「评审 → 交付」（让它设计方案）；第三轮是「**复核调和结果**」。
+> 定位差异很关键：**不要让它重述自己的方案，要让它审「别人把你的方案与另一份方案合并得对不对」**。
+> 本文件是操作件（我怎么发、怎么验），**不要**发给对方。
+
+---
+
+## 1. 为什么要有这一轮
+
+我方把三份输入调和成了一份《合并总纲》：
+
+| 输入 | 来源 |
+|---|---|
+| ① GPT 的 7 Phase 方案 | `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` |
+| ② WB-GRAPH 白板方案（386 行） | `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md` |
+| ③ 用户裁定的 8 条 + 三处前提推翻 | `docs/internal/DECISIONS-20260914-SESSION.md` |
+
+**调和过程中 GPT 完全不知情**（我投喂时**漏给了 WB-GRAPH 方案**——这是我的操作失误，已在总纲与裁决记录中留痕）。
+
+**所以这一轮要它做的事，恰好是它最有发言权、而我最容易做错的**：**审「调和是否正确」**。
+
+如果直接把未调和的两份方案丢回去让它审，它会花大半篇幅说「你这跟我的 Phase 4 不一样」——**那是已知信息，浪费它的算力**。它真正能发现的是**它自己没想到的整合问题**。
+
+---
+
+## 2. 发什么
+
+| | 内容 | 理由 |
+|---|---|---|
+| **必发** | `docs/internal/MASTER-PLAN-3.0.md`（**主输入**） | 这是要它审的东西 |
+| **必发** | `docs/internal/MERGE-CONFLICT-SCAN-20260914.md` | 4 冲突 / 5 重叠 / 4 互补 / 3 悬空的判定明细；它要审的正是这些判定对不对 |
+| **必发** | `docs/internal/DECISIONS-20260914-SESSION.md` | 用户的 8 条裁决 + **三处前提推翻**（尤其"白板 = 共享图"与"上千用户"） |
+| **必发** | `docs/internal/reviews/PLAN-gpt6astra-round2-20260914.md` | 它自己上一轮的交付（对照用） |
+| **按需** | `docs/internal/WB-GRAPH-INTEGRATION-PLAN.md`（386 行） | **上一轮漏给的那份**，这次必须给——它是冲突的另一方 |
+| **按需** | `docs/internal/reviews/CLAIM-VERIFICATION-20260914.md` | 12 条主张核实（12/12 成立） |
+| **按需** | `docs/internal/WB-GRAPH-DECISIONS-20260914.md` | 白板线的 15 个拍板点 |
+| **不发** | 本文件（ROUND3 操作件） | 含验收口径，会让它顺着写 |
+
+---
+
+## 3. 投喂提示词（路径版，可直接复制）
+
+```text
+你上一轮交付了《dsh-auto-memory · RAG + Karpathy 实施方案与架构说明（v1）》（7 个 Phase）。
+
+在此之后发生了几件事，现在需要你**复核一份合并后的总纲**：
+1. 我方把**另一份你从未见过的方案**（白板整合方案 WB-GRAPH）与你的方案做了调和；
+2. 用户对我方案里的 7 个待裁决项做了决策，并**推翻了你的三处前提**；
+3. 我方先做了一遍"矛盾扫描"（列出了冲突/重叠/互补/悬空），再据此写了《合并总纲》。
+
+【只读纪律】D:\dsh-auto-memory 只是读取对象：不修改/创建/删除任何文件，不执行 git 写操作，
+不运行会改动状态的脚本。可以读文件、grep 代码。
+
+【先读这些，按此顺序】
+1. D:\dsh-auto-memory\docs\internal\MASTER-PLAN-3.0.md
+   ← 【主输入】要你复核的《合并总纲》。
+2. D:\dsh-auto-memory\docs\internal\MERGE-CONFLICT-SCAN-20260914.md
+   ← 我方做的矛盾扫描：4 条真冲突 / 5 条重叠 / 4 条互补 / 3 条两者都悬空。
+     你要审的核心就是**这些判定对不对、调和得对不对**。
+3. D:\dsh-auto-memory\docs\internal\DECISIONS-20260914-SESSION.md
+   ← 用户的 8 条裁决 + **三处前提被推翻**（重要：你的方案建立在旧前提上）：
+     · 白板不是"单会话快照"，而是**工作区级共享图**（同一工作区的接续对话共用一张图）；
+     · 最痛的病在"注入表达"（规矩不遵守），不在"检索算法"——你 7 个 Phase 全在修算法；
+     · 这个插件**已有上千真实用户**（npm 近一年下载 10,900），不是你假设的自用工具。
+4. D:\dsh-auto-memory\docs\internal\reviews\PLAN-gpt6astra-round2-20260914.md
+   ← 你自己上一轮的交付（对照用，不必复述）。
+5. 你上一轮**没看到过**的另一份方案（这次必须读，它是冲突的另一方）：
+   D:\dsh-auto-memory\docs\internal\WB-GRAPH-INTEGRATION-PLAN.md
+   （386 行；配套拍板点 D:\dsh-auto-memory\docs\internal\WB-GRAPH-DECISIONS-20260914.md）
+6. 按需：D:\dsh-auto-memory\docs\internal\reviews\CLAIM-VERIFICATION-20260914.md
+   （12 条主张逐条核实，**结论是 12/12 成立**，不必重新论证）
+
+【本次任务的定位】不是重述你的方案，也不是再评一遍。是**复核我方的调和结果**。
+判断标准：**如果按这份总纲开工，会不会做出错的东西**。
+
+【范围边界（重要，省你篇幅）】
+- 本总纲把工程分成两条线：**3.0 主体**（7 个 Phase，改检索与注入链）与**白板线**（独立立项）。
+- **白板线自己有 386 行方案与 15 个待拍板点**（`WB-GRAPH-DECISIONS-20260914.md` 的 A1–A8 / B1–B7），
+  我方已决定**单独处理这 15 个点**。**本轮你不必设计白板线，也不必替它拍板。**
+  只有当"白板线的存在"影响到你审的 6 个问题时，才需要提及它。
+- 用户已确认：白板的 15 个待定点要与 3.0 的决策**一起定**（因为 B1＝写入门、B5＝miv 语义、
+  B4＝用户区、A8＝锚点，与 Phase 0/1 是同一批决策），但**实装分两条线**（白板线会改工具数
+  14→16 并触发三处测试硬锁，与 3.0 共用回归基线会互相污染）。
+
+【必须回答的七个问题，逐个成节】
+
+Q1. **Phase 4 拆分的边界对不对？**
+    我方把你的 Phase 4 拆成两半：
+    · 「写入门的前后比对」+「状态过滤」→ **留在 3.0 的 Phase 0**（理由：属注入边界）；
+    · 「锚点」「人机分区」「lint」「archiveAnswerPre」→ **整体移交独立的白板线**。
+    这个切分切错了吗？有没有**该留的移交了**、或**该移交的留了**？
+
+Q2. **"白板 = 工作区级共享图"这个前提变了之后，你的 Phase 0/1 哪些设计要跟着改？**
+    你的设计建立在"单会话快照"上。现在同一工作区的多个接续会话共用一张图。
+    我方用「乐观并发（expectedDigest）+ 冲突可见」处理并发（不加锁，理由是用户的接续体系下
+    同一时刻通常只有一个活跃写者）。这个处理够不够？你的 Phase 1 里哪些字段/断言需要跟着改？
+
+Q3. **新增的 Phase 6（注入表达与约束分层）与你的注入预算设计冲突吗？**
+    背景：用户说"注入开场白把规矩降格成参考，模型注意力没在这上面"，且现行
+    `snapshotMinGapRounds=5` 使**规矩在第 2–5 轮不在场**（`lib/index.js:326`、`:7455`）。
+    我方新增 Phase 6：**规则类（用户级 + 工作区级两层）每轮注入、不参与任何预算裁剪**；
+    参考类才受你的 `injectBudgetChars` 约束（实测本机为 4800，不是你假设的 2000）。
+
+    **Q3 拆成三问，请分别回答：**
+
+    Q3a. **冲突判定**：这与你在 Phase 0 设计的「唯一动态预算组装器 + FinalEnvelope 单一记账口径」
+         冲突吗？如果规则类绕过裁剪，你的"预算硬上限"断言（T0-3）还成立吗？该怎么改？
+
+    Q3b. **你来定钱袋子怎么分**（用户明确把这一条交给你裁决，我方只审）：
+         候选有三——
+           (i) **一个钱袋子 + 给规则预留一块额度**：总量仍是单一硬上限（你的记账口径保住），
+               规则先划走一块不可裁的预留；
+           (ii) **两个钱袋子**：规则一个额度、参考一个额度，两者相加即总量；
+           (iii) **一个钱袋子，规则只是"最后才裁"**：实现最简，但极端情况下规则仍会被裁。
+         **用户给你的两条约束（必须满足）**：
+           · 若选 (i)，**"预留多少"这个数字必须有确定方式**（按比例？按绝对值？按规则条数算？），
+             不能拍脑袋 —— 用户原话「我在考虑这个数字合不合适的问题」；
+           · **反对为了优雅而增加实现复杂度** —— 用户原话「我怕工程因为太复杂容易出很多 bug，
+             改半天成本太高」。本插件已有上千真实用户，bug 成本被放大。
+         请给出：**你选哪个 + 为什么 + 落点（`文件:函数名`）+ 能失败的验收断言 + 回滚动作**。
+
+    Q3c. **节奏部分的成本**：我方核实 `snapshotMinGapRounds` 已是现有配置项（默认 5），
+         注入间隔逻辑也已实现 ⇒ "规则每轮在场"的**节奏部分只需改默认值**，不是新机制。
+         请确认这个判断，并指出：改默认值后，你原方案里**哪条断言会因此失效或需要新增**。
+
+Q4. **H2（精排）被实测数据推翻，Phase 3/5 的哪些断言要改？**
+    实测（用户自己跑的，`D:\dsh-auto-memory\artifacts\m7-rerank-pre\results.json`）：
+      · bge-reranker-v2-m3：recall@1 = 0.898，**P95 = 37.4 秒**
+      · qwen3-reranker-0.6b：recall@1 = 0.800，**P95 = 8.8 秒**
+      · 不精排基线：recall@1 = 0.739
+    你方案里写的是「额外等待 ≤750 毫秒」——**这个数字在本机不存在**。
+    用户裁定改为**多级选项**（关 / 快档 int8+CPU / 发烧档完整模型 + RTX 4070 Ti SUPER），
+    并新增 **1 分钟异步窗口**（本轮用现有排序，精排结果留给下一次注入）。
+    另外：cross-encoder 模型**已经下载好了**（bge-reranker-v2-m3 2.1GB、qwen3-reranker-0.6b 1.1GB，
+    各带 tokenizer）⇒ 你的 U5「阻塞」判定作废；真实缺口是 **GPU 版 torch**（当前 `torch 2.13.0+cpu`）。
+    请给出：Phase 4/5 里哪些断言必须改、改成什么。
+
+Q5. **引擎隔离（T2-9）与切档进度条，在你的 engineIdentity 两级引用上该怎么落？**
+    实测：C2 = `Xenova/multilingual-e5-small` q8（端侧）；C3 = `Xenova/bge-m3` int8（Python sidecar）。
+    **两个不同模型，向量空间不通用**。代码里已有 `PROVIDER_ID_INT8` 但**没做成硬约束**。
+    用户要求：切换时**强制全量重建 + 进度条**，且进度条**必须并进现有引导体系**
+    （Python BGE 下载 / venv 建环境已有可视化指导），**不得另起一套**。
+    请确认 T2-9 该怎么写，以及它与你的 `engineIdentity` 设计是否自洽。
+
+Q6. **白板线工具数 14→16 会不会污染 3.0 的回归基线？**
+    你的方案主张"3.0 工具数不变"；WB-GRAPH 的白板线会新增两个工具（`memory_expand_pre` /
+    `memory_trace_pre`），并触发**三处测试硬锁**（`tests/smoke/smoke-test.mjs:67`、
+    `smoke-test-m3b3-pre.mjs:43`、`smoke-test-context-observer.mjs:107` 都断言 `!== 14`）。
+    我方处置是：**白板线独立立项、独立回归窗口**，不混进 3.0 主体。
+    这样对不对？有没有更好的处置？
+
+【此外必须回答的一个兜底问题】
+Q7. **我方的调和有没有漏掉你原方案里必须保留的内容？**
+    调和对方案做了大量移动与裁剪。请逐项检查你的 7 个 Phase、50 条断言（T0-1…T6-7）、
+    U1–U7，指出**任何被误删、误并、误降级的内容**。这是防止我方调和造成信息损失的兜底问法，
+    请具体到编号。
+
+【输出格式】
+按 Q1–Q7 逐节写。每节按此骨架：
+1) **结论**：一到三句，可执行；
+2) **依据**：引用文件章节/条款号，或明确写「依据不足」；
+3) **我方判定对不对**（对 / 部分对 / 错）+ 理由；若判"错"，给出你认为正确的处置；
+4) **需要改的具体条目**：若涉及总纲的某个 Phase 或断言，写出编号与改法；
+5) **可失败的验收断言**：若你提出新改动，给出「跑什么 / 看到什么算过 / 看到什么算失败」。
+
+【硬口径，全程遵守】
+- 首要用户 = 项目作者本人 = 最优档：以最优为目标，允许更重的算法、本地模型、更多预算；
+- 兼容档不是目标形态，它只是「降级路径必须存在」；
+- 每条建议标注服务哪一档；最优档重方案给三件套（成本 + 门控 + 无 LLM 降级）。
+
+【禁止】
+- 重述你自己的方案（会被跳过）；
+- 重新论证已核实的事实（核实表结论：12/12 成立）；
+- 只给方向不给落点（「重构 X」这种没有 `文件:函数名` 的条目不算交付）；
+- 无法证伪的建议；
+- 大段复述输入包已有内容；
+- 只提出问题不给推荐裁决（**每一项未决都要给：你的推荐 + 理由 + 影响哪些 Phase + 相反选择下哪部分要改**）。
+
+【关于不确定】不要停下来向我反问澄清。信息不足就写进「需要补充的信息」，
+以"给出可直接执行的结论"为优先。（以本条消息的指令为准。）
+```
+
+---
+
+## 4. 回收验收（我怎么判它合格）
+
+**顺序不能反**：
+
+1. **Q7 兜底问题必须先答**——如果它答不出"有没有漏掉内容"，说明它没真读完自己的方案，其余回答可信度打折。
+2. **看它敢不敢判"我方错了"**。如果 Q1–Q6 全是"对/同意"，这是**顺着输入说话**的信号（第一轮它敢挑 12 条刺，这一轮若不敢，说明提示词把它压住了）→ 追问「哪一条你最不同意？」
+3. **看它给的新断言能不能红**。抽 1 条它新提的断言，写成 node 断言跑一遍——**跑不红等于没断言**。
+4. **核落点**：它提的 `文件:函数名` 逐条 grep，合格线 **≥80%**。
+5. **最后看它有没有把"未决"抛回来**。每条未决必须带推荐裁决；只给问题不给裁决 → 视为未交付。
+
+---
+
+## 5. 预期失败模式
+
+| 失败模式 | 识别特征 | 对策 |
+|---|---|---|
+| **顺着写** | Q1–Q6 全"同意"，Q7 答"无遗漏" | 追问：「总纲里哪一条你最不同意？给我一个具体怀疑对象」 |
+| **重述自己** | 大段重复第二轮的 7 Phase 设计 | 复述段落跳过；连续两段即退回 |
+| **护方案** | 对"Phase 4 拆分"只表态不分析 | 要求它对**每一半**分别给出"切对了/切错了" |
+| **回避 Phase 6** | 对"规矩每轮注入"只说方向不论断 | 追问：它与你的 FinalEnvelope 单一口径到底冲不冲突？给是/否 |
+| **编造行号** | 引用不存在的 `文件:行号` | 逐条 grep，不存在即整条降级为猜测 |