@a9i5k4/dsh-auto-memory 3.0.1 → 3.1.0

package/docs/internal/reviews/REVIEW-gpt6astra-20260914.md

@@ -1,112 +0,0 @@
-# 架构评审答复 · GPT-6 Astra · 2026-09-14（第一轮）
-
-> 归档说明（2026-09-14 补录）：本文是外部模型对 `docs/internal/ARCH-REVIEW-BRIEF.md` 的第一轮评审答复**原文**。
-> 投喂用提示词见 `docs/internal/ARCH-REVIEW-REQUEST.md` §2b（路径版）。投喂对象自述"仅阅读指定文档与相关代码，未修改文件、未运行测试"。
-> **归档动因**：本会话此前已压缩过一次，该答复当时只存在于对话中；若再压缩即永久丢失，故落盘为唯一持久副本。
-> **待办**：文中所有「文件:行号」主张尚未全部核实——核实结论将作为第二轮投喂的输入材料（真阳性 → 进 Phase 0 / 假阳性 → 第二轮显式反制）。
-
----
-
-结论：保留"最优档优先、push 为主、pull 为辅"的方向，但**目前不能把"三层验收通过、S3/S6 已合规"作为重算法上线的可靠前提**。本次仅阅读指定文档与相关代码，未修改文件、未运行测试；下面的验收均为建议执行项。
-
-## A. 输入包中最值得质疑的前提
-
-**A1｜你怀疑什么：S3"已合规"和"融合序直接作为最终序"不成立。** BRIEF §5.1、SPEC §3 据此把主要改造范围限定在 S1/S2/S4/S5，可能遗漏真正影响检索结果的路径。
-
-**依据：** S3.2 禁止分数空间加权，但 JS 的 [semantic-js-pre.js:60](D:/dsh-auto-memory/lib/semantic-js-pre.js:60) 和 Python 的 [worker_semantic_pre_v1.py:486](D:/dsh-auto-memory/python/worker_semantic_pre_v1.py:486) 都对归一化分数加权；调用分别见 [context-host-pre.js:378](D:/dsh-auto-memory/lib/context-host-pre.js:378)、[worker_semantic_pre_v1.py:907](D:/dsh-auto-memory/python/worker_semantic_pre_v1.py:907)。公共注入层又按原 `score` 排序，见 [activation-inbox-pre.js:255](D:/dsh-auto-memory/lib/activation-inbox-pre.js:255)。因此融合影响入选，却未必决定最终展示顺序；C7 分值降序不能证明融合正确。
-
-**建议怎么核实［两档共用］：** 固定每个召回臂的排名，只改变分数间距，排名融合结果应保持不变；再构造"融合序与原稠密序相反"的候选，贯穿召回、预算裁剪和最终注入检查顺序。任一阶段意外变序即失败。先完成这组零额外 LLM 调用的验证，再把融合结果作为 S2/S4 实验基线。
-
-**A2｜你怀疑什么："增量索引"和"内容寻址块 ID"被赋予了超出实现的含义。** 前者未必减少计算，后者未必支持未变文本块复用；这会使 S1.3 的工期和预期收益失真。
-
-**依据：** L0 在 [l0-index-pre.js:125](D:/dsh-auto-memory/lib/l0-index-pre.js:125) 先对全部摘要调用嵌入，再于该文件 `:138` 选择旧向量；[l0-index-pre.js:219](D:/dsh-auto-memory/lib/l0-index-pre.js:219) 返回的 `recomputed` 是变化计数，不能代表实际编码量。另一方面，[m7_embedding_pre_v1.py:75](D:/dsh-auto-memory/python/m7_embedding_pre_v1.py:75) 的块 ID 包含整个记录的 `recordDigest`；同一记录改变一块，其他块的 ID 也会改变。S1.1 的公式本身没有保证"单块文本不变则缓存命中"。
-
-**建议怎么核实［两档共用］：** 使用记录实际输入条数的嵌入替身，覆盖不变更新、增加记录、修改多块记录末块、前部插入四种情况，同时报告编码条数与块 ID 变化。若只返回漂亮的增量计数、实际仍编码全部摘要，就判失败；S1.3 的首期收益按"记录级失效域"核算，不能预支更细粒度缓存收益。
-
-**A3｜你怀疑什么：C5/C6 全绿没有证明状态、快照和最终预算三个关键边界。** 这直接影响错误记忆能否重新进入上下文，也使成本模型缺乏可靠上限。
-
-**依据：** [C5 测试:127](D:/dsh-auto-memory/tests/smoke/smoke-test-c5-tier-inject-pre.mjs:127) 放入 `superseded` 候选，[同测试:133](D:/dsh-auto-memory/tests/smoke/smoke-test-c5-tier-inject-pre.mjs:133) 却预期三条全部保留，与 I5 相反。命中复用在 [index.js:3894](D:/dsh-auto-memory/lib/index.js:3894) 只检查时间与会话后便与当前来源拼装，没有在该入口核对 I6 的同一 `miv`。预算方面，[tier-layer-inject-pre.js:323](D:/dsh-auto-memory/lib/tier-layer-inject-pre.js:323) 不裁目录和降级行，裁剪后还追加说明；[index.js:3986](D:/dsh-auto-memory/lib/index.js:3986) 封顶的是目录扣账成本，不是已加入的文本长度。这些都是静态代码反证，实际事故发生频率未经核实。
-
-**建议怎么核实［两档共用］：** 直接向实际注入入口提供混合状态候选、先命中后换 `miv` 的时序，以及目录和白板同时接近上限的输入；只有 current 内容保留、三层同版本、最终完整输出不超预算才通过。测试不得预先替被测入口过滤，也不得只检查"出现了裁剪提示"。
-
-## 一、分档边界：BRIEF §3-1／§8.2(b)-1
-
-**1. 结论：** 按用户允许承担的成本和增强授权定义档位，引擎作为档位预设与缓存身份。最优档继续以作者的质量目标为先，LLM 增强独立门控；引擎失效时进入降级，不把用户永久重新归类为兼容用户。
-
-**2. 依据：** BRIEF §2.1、§2.2；S1.2、S9.1–S9.4。文档没有提供"Python 必然代表某个质量水平"的对照证据。
-
-**3. 档位与三件套：** 两档共用，最优档优先；本项是配置与调度安排，重方案单列于第三节。沿用单一检索流程，资源不足时关闭增强；无 LLM 时保留本地处理，嵌入引擎不可用时明确降级为词法。
-
-**4. 成本：** 本项新增 LLM 调用为 0，无须新增常驻模型；配置判断的延迟、内存增量未测。换引擎仍承担 S1.2 要求的重建成本；最终注入 token 另计，不能称整条链"零 token"。
-
-**5. 可失败验收：** 对同一语料分别关闭 LLM、令嵌入引擎不可用、耗尽增强预算，若均保持同一接口、产生可用降级结果及原因则通过，任一情况整链失败或偷偷调用 LLM 即失败。
-
-**6. 契约影响：** 不改变 OR 双引擎和三层接口；若把 S9.3"同一路径"解释为两档执行完全相同的模型调用，则与 S9.2 的可选增强矛盾，应先裁定其含义，不能通过档位专用字段绕过。
-
-## 二、兼容档可验收性：BRIEF §3-2／§8.2(b)-2
-
-**1. 结论：** "存在降级路径"是必要条件，还必须证明这条路径能在有界时间和资源内完成。验收应覆盖首次可用、单轮响应、持续写入后的新鲜度、常驻及峰值内存、磁盘占用，并绑定设备和语料规模。
-
-**2. 依据：** S9.1、S3.3、S5.3，以及 BRIEF §7②③；当前材料不足以给出可信的毫秒或 MB 上限。
-
-**3. 档位与三件套：** 兼容档作为降级保障，两档共用测量方法；无需引入重模型。语义加载或请求超过预先登记的截止时间，就返回词法结果与明确原因；不得等待不可用组件完成才降级。
-
-**4. 成本：** 新增在线 LLM 调用为 0；增加本地计时、资源采样和有界诊断，具体延迟与内存待测，无须新增模型依赖。诊断文字也占注入预算；新鲜度与磁盘回收不能从成本表省略。
-
-**5. 可失败验收：** 在登记的最低设备、语料规模和写入负载上重复冷启动、查询及组件失效实验，全部满足事前登记的时间、内存、磁盘、新鲜度界限且额外 LLM 调用为 0 才通过，超界或未登记界限均不能宣称兼容验收通过。
-
-**6. 契约影响：** 这是 S9.1 的验收落实；同一测试接受不同预算参数，不是为兼容档免除 I4–I7，也不要求它达到最优档相同的召回结果。
-
-## 三、重方案准入：BRIEF §3-3／§8.2(b)-3
-
-**1. 结论：** 保留 S9.2 三件套作为方案准入，再用 S7 对照实验决定是否启用；无需要求降级结果与增强结果相同。最优档可先试验一次 LLM 查询改写，保留原查询召回，不引入检索自省循环。
-
-**2. 依据：** S2.1–S2.4、S7、S9.2；三件套证明成本可控制，不证明收益存在。PROGRAM §6 的 `10/12` 与契约 §4.5 的可达率 `≥0.9` 是不同门，不能互代；同一组 12 题同时满足二者需要至少 `11/12`。
-
-**3. 档位与三件套：** 最优档试验：作者显式开启、费用额度充足且查询属于事前登记的复杂查询集合时触发；建议每次最多一次调用、生成两条改写，不重试，原查询始终保留。超时、错误、超额或无 LLM 时回退本地原查询并标注。
-
-**4. 成本：** 建议试验上限为输入 512、输出 128，即每次最多 640 个额外 LLM token，由作者承担；额外等待上限建议 1.5 秒，二者是待验证的控制值，不是性能预测。检索最多增加两条查询的本地计算；远程方案不新增常驻本地模型，但需服务适配器，内存与取消后资源释放待测。
-
-**5. 可失败验收：** 冻结语料、题集、答案证据及预算，分别运行增强关闭／开启的 S7 A/B/C 对照，只有答案可达率提高、噪声比不升、契约全部通过且故障注入能按时退回原查询才通过，否则不启用。
-
-**6. 契约影响：** 符合 S2.4、S7、S9.2；兼容档调用它会违反 S9.1，因改写失败丢失原查询会违反 S2.4。成本计量或服务能力缺失时，当前只能批准实验设计，不能认定已满足上线门槛。
-
-## 四、数值真值归属：BRIEF §8.2(b)-4
-
-**1. 结论：** 采用"单一数值定义源＋文档数值表生成或校验＋独立行为验收"。设计裁决决定数值含义，定义源记录已批准的默认值、硬上限、单位和关系；运行配置产生有效值，不能让偶然的代码改动自动成为新政策。
-
-**2. 依据：** SPEC §0.2、契约 §4。当前守卫在 [smoke-test-doc-code-consistency-pre.mjs:149](D:/dsh-auto-memory/tests/smoke/smoke-test-doc-code-consistency-pre.mjs:149) 只列七个字段，没有覆盖 `L1/K` 等全部预算关系。
-
-**3. 档位与三件套：** 两档共用；属于确定性配置治理，无 LLM 门控需求。默认值、硬上限和配置后的有效值必须分别展示、分别检查。
-
-**4. 成本：** 在线额外 LLM token 为 0，无新增常驻进程或模型依赖；开发期增加定义整理及生成校验工作，运行期开销未测。集中数字不能替代最终文本长度和真实 token 成本测量。
-
-**5. 可失败验收：** 在隔离副本分别改变数值、单位和文档声明，未同步必须报错；再输入超预算内容，即使所有数值声明一致，最终输出超限也必须失败。
-
-**6. 契约影响：** 不改 I1–I3 或 S5.2；最优档提高可配置总预算不等于获准突破冻结的 `B0/L1/K/B2`。此外，契约 §4.6 的字符估计大于旧估计，并不能单独证明它是真实 tokenizer 的硬上界。
-
-## 五、预算差异与共用契约：BRIEF §8.2(b)-5
-
-**1. 结论：** 固定字段含义、证据身份、序列化规则及降级规则，允许完整条目数量和按需出现的层不同。以完整证据条目为裁剪单位，先预留身份、出处及降级说明，再分配正文；预算不足时明确未输出该证据。
-
-**2. 依据：** S9.3、I1–I7、契约 §1.2／§2.3；Tier-1/Tier-2 本来就按需出现，所以两档输出不逐字相同不构成违约。
-
-**3. 档位与三件套：** 两档共用，最优档通过更多有效预算保留更多证据，兼容档减少数量。无 LLM 时执行同一组装和裁剪规则；不得通过删状态、出处或版本约束节省预算。
-
-**4. 成本：** 新增 LLM 调用为 0；完整元数据会占既有注入额度，组装延迟与内存待测，无新增模型依赖。当前 Tier-2 在 [tier-layer-inject-pre.js:247](D:/dsh-auto-memory/lib/tier-layer-inject-pre.js:247) 取摘录并仅输出 layer、memoryId 和正文，不能把另一条 `expand` 路径的出处能力视为这里已经具备。
-
-**5. 可失败验收：** 对同一快照和查询，使用两档预算及条目边界前后一字符的预算检查最终输出，同一解析规则可读、计数准确、保留证据字段完整且总长合规才通过，残缺正文、缺出处、混版或超限即失败。
-
-**6. 契约影响：** 修复现有 I4/I5/I6/S5.2 缺口；另须先裁定 S5.4"相似度降序"与 S4 独立精排的关系。不能把 RRF 或精排分直接改名为相似度，也不能让展示层重排悄悄撤销精排结果。
-
-## B. 不建议做的事
-
-- **［两档共用］** 不建议以 C7 分数可见或套件全绿替代端到端验收；当前已有测试将违反 I5 的结果视为通过。
-- **［最优档］** 不建议先扩大预算掩盖拼装缺陷，或在排序语义未厘清前叠加 cross-encoder；前者无法控制实际成本，后者无法归因收益。
-- **［两档共用］** 不建议将多轮检索设为默认、混排两引擎向量，或要求降级答案与增强答案完全一致；前两者越过既定边界，后者使增强无法体现价值。
-- **［两档共用］** 不建议直接把白板"重要概念""相关卡片"当确定性 lint 判据；WB §6 未定义识别范围、关系规则和误报标准，目前不能据此判验收通过。
-
-## 需要补充的信息
-
-- 两档实际配置、最低设备、模型版本、语料规模与写入负载；冷启动和单轮延迟分布、常驻／峰值内存、磁盘增长；目标 tokenizer、计费口径及最终注入统计边界。
-- 正式 12 题、答案所在原文块、S7 各策略原始结果；同次请求贯穿 push/pull、融合、决策、缓存及注入的版本和分数记录；白板 lint 的概念、关系和日期阈值定义。缺少这些，不能确认重方案收益、真实资源上限或整条链已满足共用契约。

package/docs/internal/reviews/ROUND3-REVIEW-INTEGRATION-20260914.md

@@ -1,230 +0,0 @@
-# 第三轮复核的整合与核实（2026-09-14 深夜）
-
-> **用途**：GPT 对《合并总纲 v1》的复核答复，逐条核实 + 采纳/驳回 + 落成总纲 v2 的修订清单。
-> **核实方式**：凡涉及代码现状的，一律**打开文件读当前字节**（不采信转述）；凡属设计判断的，标注为"采纳/部分采纳/保留意见"。
-> **性质**：本文是**修订记录**，不是新方案。总纲 v2 由 `MASTER-PLAN-3.0.md` + 本文共同构成。
-
----
-
-## 0. 总评
-
-GPT 的复核**质量高于第一轮**：它没有顺着写，而是**指出了我方调和的具体错误**，且每条都给了落点与断言。它给出的总裁决是：
-
-> 「分线实施、优先处理规则表达、精排改为可选异步，方向成立；**总纲还不能原样作为施工依据**。」
-
-**这个否决是成立的**，理由见 §2（我方三处实质错误）。它给出的开工顺序已经可以执行（§5）。
-
----
-
-## 1. 逐条核实：GPT 对代码现状的指控
-
-| # | GPT 的主张 | 我方核实结果 | 判定 |
-|---|---|---|---|
-| V1 | `memory-writer-pre.js:235` 的 `_queue` 提供**实例内**串行化 | 读文件确认：`:235 _queue(filePath, job)`，按 `path.resolve(filePath)` 分键排队 ✓ | **真** |
-| V2 | `replace` 在队列内部检查 `expectedDigest`，见同文件 `:344` | 读文件确认：`:343 /** 整篇替换(§9);同文件串行。 */`、`:344 replace(filePath, replacement, opts = {})`、`:345 return this._queue(filePath, async () => {` ✓ | **真** |
-| V3 | `atomicReplace` 的文件替换**不是**"比较 digest 并替换"的原子 CAS | 读文件确认：`:199 export async function atomicReplace(target, data, fsApi = fsDefault)` —— **签名里没有 expectedDigest 参数**，只做原子写，不做比较 ✓ | **真** |
-| V4 | `index.js:1444`：已保存配置**覆盖**默认值 | 读文件确认：`:1444 this.config = { ...DEFAULT_CONFIG, ...(parsed && ...) }` ✓ | **真** |
-| V5 | `index.js:7455`：`Number(value) \|\| 5` 会把 **`0` 回退到 `5`** | 读文件确认：`:7455 const gap = Math.max(0, Number(engine.config.snapshotMinGapRounds) \|\| 5)` ✓ —— 且本机配置实测 `snapshotMinGapRounds = 5` | **真** |
-| V6 | 明确写"**单对话进度快照**"的是 **WB 原方案 §1**，不是 GPT 自己 | 读文件确认：`WB-GRAPH-INTEGRATION-PLAN.md:42`「白板是**单对话进度快照**，dsh-graph 七阶段…」✓ | **真，且我方归因错误** |
-
-**结论：V1–V6 全部成立，零误报。** 这六条里 **V6 是对我方的直接纠错**（见 §2.1）。
-
----
-
-## 2. 我方三处实质错误（必须改）
-
-### 2.1 错误一：把"单会话快照"这个前提**错误归因给了 GPT**
-
-- **我方在矛盾扫描 §2 冲突 1 写**：「GPT 的 Phase 4 通篇假设白板是**当前会话**的进度快照，写入签名里没有会话身份概念」。
-- **事实**：GPT 自己的方案里 `SnapshotRef` 带 **`workspaceKey`**，`writePlanSnapshot(projectDir, content, …)` 收的是 **projectDir** —— **它本来就是按工作区定位的**。写"单对话进度快照"的是 **`WB-GRAPH-INTEGRATION-PLAN.md:42`**（你自己的方案）。
-- **影响**：共享图裁决**结论不变**（用户裁定仍然有效），但**理由要改**：不是"GPT 假设错了"，而是**两份方案对"持久数据 vs 会话执行态"的分工没讲清**。
-- **处置**：矛盾扫描 §2 冲突 1 的归因作废；改为"应**调整持久数据与会话执行态的分工**，而不是推倒原快照模型"（GPT 原话）。
-
-### 2.2 错误二：把"账本判据"整体套给了白板
-
-- **我方在总纲 §4 Phase 0 写**：「格式判据采纳 WB-GRAPH 的完整判据表（**H1–H4 硬 / S1–S4 软**）」。
-- **事实**：`WB-GRAPH-INTEGRATION-PLAN.md` §2.2 里 **H1–H4/S1–S4 是"交接账本（kind=handoff）"的判据**；**白板 PLAN 另有 P-H1/P-H2/P-S1**（且刻意保持最弱，因 PLAN 是自由全貌文档，节名不固定）。
-- **处置**：总纲 Phase 0 须写成"账本用 H1–H4/S1–S4，PLAN 用 P-H1/P-H2/P-S1 + 卡片完整性 + 用户区保护"。
-
-### 2.3 错误三：规则真源**自相矛盾**（`MEMORY.md` vs 新增 `RULES.md`）
-
-- **裁决记录 §8.3 写**：用户级规则＝**现有 `~/.dsh/memory/MEMORY.md`**。
-- **总纲 Phase 6 写**：用户级 **`~/.dsh/memory/RULES.md`**（新增文件）。
-- **事实**：同一件事在两份文档里给了**两个不同的真源**。这是调和时新引入的矛盾，GPT 抓到了。
-- **处置（采纳 GPT 建议）**：**本版保留既有用户级记忆中"类型化规则"为唯一真源**；若将来生成 `RULES.md`，**只作单向派生视图**，不做双向维护。若将来真要改用独立真源，必须补**迁移、去重、旧模式读取、回滚**四类测试。
-
----
-
-## 3. 采纳的设计修正（总纲 v2 的修订清单）
-
-### 3.1 Q1（Phase 4 拆分）—— 部分采纳，边界重划
-
-| GPT 的修正 | 处置 |
-|---|---|
-| **写入门不是注入边界本身**：写入门阻止**破坏源数据**；状态过滤阻止**不应使用的数据进入上下文**。可同阶段交付，但不能混成一个检查 | **采纳**。总纲 Phase 0 须把两者列为**两个独立检查** |
-| **H1–H4/S1–S4 不能整体套给 PLAN** | **采纳**（见 §2.2） |
-| **`archiveAnswerPre` 不以图遍历为必要前提**：「必须等 `memory_expand_pre` 才有意义」的因果不成立；保存、幂等和普通 recall 回流可先验收 | **采纳**。总纲 §5 该行作废 |
-| **边界应为：3.0 拥有共同提交与保护入口，白板线拥有白板格式及其适配器** | **采纳**。这是比"移交/保留"更准的切法 |
-| **§7"白板待定点不阻塞 3.0 主体"过于笼统** | **采纳**。改为：**不阻塞其他主体工作，但阻塞依赖这些定义的白板写入保护验收** |
-| 新落点：`memory-mutation-pre.js:validateMutationBoundaryPre` 接收规范化投影（`beforeIds/afterIds/protectedRegions/changes`），**不自行解释图格式**；格式由 `wb-contract-pre.js:parseWhiteboardPre` 提供 | **采纳**。关键点：**格式只维护一份** |
-| `criteriaGate=false` / 骨架 fail-soft **不得**跳过丢卡、用户区、版本、状态保护 | **采纳**。写进总纲 §6 交付纪律 |
-| 新增断言 **T0-8B**（三条写入路径都不能绕过保护）、**T0-8C**（关质量门后仍拒绝丢卡）、**T4-4**（投影/快照/目录同一身份映射） | **采纳** |
-
-### 3.2 Q2（并发）—— 采纳"需要原子提交边界"
-
-**GPT 的核心纠正**：两个写者都先读 D、都通过比较、再分别写 A 和 B ⇒ **后写者仍会覆盖前写者**；「通常只有一个活跃窗口」**不能证明这个时序不存在**。
-
-- 我方原写法"乐观并发 + 冲突可见，**不加锁**"**不完整**。
-- **修正**：**保留现有短提交队列**（`_queue` 即实例内串行化），所有窗口通过**同一工作区的写入 owner** 提交；`expectedDigest` **必须在该提交边界内检查**（代码里 `replace` 已在队列内部检查 ✓）。**不引入长期编辑锁、不按会话分片。**
-- **并发范围**：3.0 支持**多窗口经同一宿主提交**；**多宿主同目录**通过 U2 单独认证。若作者要求多进程直接写同一文件，则**必须**增加跨进程原子提交或单写者路由 —— 「不加锁」方案给不了这个保证。
-- 提交接口补来源身份：`{workspaceKey, boardId, txId, expectedDigest, expectedStateVersion, actor:{sessionId,contSeq,kind}, writes, stateChanges}`，其中 **`boardId` 在工作区内稳定、不含当前会话号**。
-- **会话隔离与图共享要分开**：共享数据按工作区缓存；**激活、冷却、精排任务、已交付标记仍按会话隔离**。
-- **`Cue(session)` 是节点来源，不能自动成为"只允许检索当前会话内容"的硬过滤**。
-- **`done/passed/archived` 不能塞进 `current/superseded/retracted`** —— 任务进度、判据确认、记忆有效状态**分别表示**。
-- 新增断言：**T1-7B**（A 的激活包不能出现在 B）、**T1-7C**（旧接续窗口的迟到写入不能覆盖新图）。
-
-### 3.3 Q3（预算）—— 采纳分项账本 + 选 (ii)
-
-**Q3a**：与"唯一组装器、统一记账"**不冲突**；与原来的"**全部**动态文本不超过 `injectBudgetChars`"**冲突** ⇒ **T0-3 必须改**。
-**采纳**：`FinalEnvelope` 改为**分项账本**（仍由同一个 `composeMemoryEnvelopePre` 生成）：
-
-```
-chars: { rules, memoryReferences, otherDynamic, total }
-limits: { memoryReferences, otherDynamic }
-```
-
-- 标题、分隔符、降级说明**必须归入某个分项**，不允许未计费尾巴。
-- **规则"不参与裁剪"不等于"永久注入"** —— 规则被撤回后应消失。
-- 修订 **T0-3 / T7-2 / T6-5**：规则完整性逐字比较；两个参考分项分别不超限；总计等于最终序列化长度。
-
-**Q3b**：用户把裁决交给 GPT，**GPT 选 (ii)：规则与参考分开预算，但只保留一个组装器、一本账**。
-**采纳**，理由（GPT 给）：(iii) 允许裁规则违背已定要求；(i) 固定总额遇到规则本身超总额时仍须拒绝或裁剪，还引入预留不足/借用/回收；(ii) 只需完整规则段加两个有界参考段再求和，**不需要新增调度或分配框架**（直接回应了用户"怕复杂出 bug"的顾虑）。
-
-**关键设计**（正面回答了用户"预留数字合不合适"）：
-
-```
-R  = 本轮完整规则段实际字符数（含其标题与边界）   ← 不设魔数，由实际内容决定
-Bm = injectBudgetChars（本机 4800）
-Bo = otherDynamicBudgetChars
-memoryReferencesChars <= Bm
-otherDynamicChars     <= Bo
-totalChars = R + memoryReferencesChars + otherDynamicChars
-```
-
-- **`Bo` 新增为独立配置；未配置时以当前 `Bm` 作为派生初值**，不另设魔数，不覆盖已有配置。
-- **明确代价**：**不再承诺"插件全部动态内容有一个与规则规模无关的固定字符上限"**。规则越长，用户输入成本越高 —— **不能用换记账写法掩盖它**。
-- **物理容量边界**：若完整规则 + 请求必需内容超过宿主上下文容量 ⇒ **拒绝发送并显示明确容量错误，保留原规则**，让用户整理；**不能静默裁规则**。
-- 真实 token 判断依赖 U6/U7；**尚未具备时不得宣称已保证模型 token 上限**。
-- **成本措辞收紧**：不改"成本极小"——**规则数量没有实测前不填写**。
-
-**Q3c**：**只能部分确认**"只需改默认值"。
-
-| 我方原判断 | GPT 的修正 | 核实 |
-|---|---|---|
-| 节奏部分只需把默认值 5 改为 1 | **新装且未保存配置时**可以；**已有用户的已保存配置会覆盖默认值**（`index.js:1444`） | **真** |
-| — | **`0` 无法表达**：`Number(value) \|\| 5` 把 0 回退到 5（`:7455`）⇒ 需**修正零值解析**，区分合法零值与缺失/非法值 | **真** |
-| — | 旧节流分支**提前返回时可能跳过本轮动态快照**（`:7483`）⇒ 须"**先提供规则段，再对参考内容应用 gap**" | 需采纳 |
-| 我方总纲 T7-1 断言"每轮注入文本中规则都在" | **改测"最终请求 messages"** —— 局部注入块的存在不等于模型真收到了 | **采纳**（这正是"源码接线守卫 ≠ 行为断言"的又一变体） |
-| T7-6 断言前缀字节稳定 ⇒ 缓存友好 | **只能证明字节稳定**；不能证明完整请求的缓存命中，**更不能证明按 1/10 计费** | **采纳，措辞收紧** |
-
-**同时 GPT 也收敛了我的一个过强结论**：不能把"部分轮次不追加新快照"直接等同于"本轮 messages 完全没有旧规则" —— 后者需要 **U6 的实际消息证据**。目标应表述为：**每个实际请求具备当前有效规则，且更新、撤回后不继续使用旧版本**。
-
-### 3.4 Q4（精排）—— 采纳，且修正我方两处夸大
-
-**我方两处必须改的**：
-
-| 我方原写法 | 事实 | 修正 |
-|---|---|---|
-| 把 bge（50 对/题）与 qwen（10 题 × 10 对）的 P95 **并列展示** | **候选规模不同，不可直接比较速度或全量质量** | 拆表标注候选规模；qwen 是**小样本探针** |
-| "cross-encoder 模型已下载 ⇒ U5 阻塞解除" | **已下载模型 ≠ int8 快档产物与运行性能已就绪** | U5 拆成：模型资产 ✓ / GPU torch ✗ / 快档量化产物 ✗ |
-| "T5-5 费用门按新预算重算" | **T5-5 是生成式改写（H1）的费用门**，不应因 H2 变慢而重算 | **保留 H1 费用门**；本地精排**另设资源门 T5-5R** |
-| — | RSS 峰值实测 **3.84GB（bge）/ 4.95GB（qwen）** | 旧 2048MiB 建议上限**不能沿用** |
-
-**采纳的核心机制修正**：**一分钟必须定义为"有界的后台结果窗口"，不能解释成"下一轮无条件使用上一轮结果"**。新增：
-
-```
-enqueueRerankPre({originRequestKey, inputKey, queuedAt, expiresAt, candidates})
-takeReusableRerankPre({requestKey, inputKey, now})
-invalidateReranksPre({sessionId, workspaceKey, reason})
-```
-
-`inputKey` 至少含：`workspace + scope + session + 查询输入摘要 + miv + 候选ID及正文摘要 + embeddingIdentity + rerankerIdentity + 处理版本`。
-
-**规则**：一分钟从**入队时**开始（含排队与计算），**到期不续命**；本轮立即用现有排序；后台完成**只进有界结果缓存**，不改本轮 envelope、不再次 emit；下一请求**重新生成 requestKey**，仅 `inputKey` 完全匹配才复用，且**重跑当轮状态/fv2/冷却/预算检查**；会话关闭、接续换会话、查询或 `miv` 改变即不复用；**没有下一轮就过期，不主动制造模型请求**。
-
-**运行隔离**：精排用**独立、懒加载的 worker 角色**，复用既有 sidecar 传输；**不能把几十秒的同步计算塞进同时承担稠密查询与索引服务的 worker**。一期**全机最多一个精排任务**，忙时继续粗排。
-
-**断言修订**：T3-2（按选定 `ordering` 验证，异步时不再断言 RRF 顺序）、T3-6（后台完成不能创建第二个主激活）、T5-1/T5-3/T5-4/T5-5/T5-6、T6-2/T6-3（前台返回与后台完成分开测）、T6-6（关闭增强后旧任务完成不得重启用）；新增 **T5-3R / T5-4R / T5-5R / T5-6R**（含"零次实际复用时不得把离线收益写成异步注入收益"）。
-
-### 3.5 Q5（引擎隔离）—— 采纳，并收回我方"成本为零"
-
-| GPT 的修正 | 处置 |
-|---|---|
-| 单个 `PROVIDER_ID_INT8` **不足以**标识模型内容/tokenizer/预处理；两层缓存都只凭 `chunkId` 或裸输入哈希读取，**仍会串用向量** | **采纳**。引擎身份须含：模型/权重摘要、tokenizer 版本、精度格式、维度、池化、归一化、输入处理版本 |
-| **模型下载完成 ≠ 当前引擎索引完成**；向导须区分 `assetsReady` 与 `indexReady` | **采纳** |
-| **T2-9 拆四个子断言**：T2-9a（e5→BGE→e5 每次都完整重建，旧缓存存在也不能跳过）、T2-9b（A 未完成又发 B，A 迟到不得发布 B 的 ready）、T2-9c（编码中暂停/失败/重启，进度来自实际完成量、manifest 发布前不得显示完成）、T2-9d（任一失败词法仍可用且原因可见） | **采纳** |
-| 我方写"**成本为零**" | **改**为"**身份比较开销小；全量重建成本由本机承担**" |
-| `ensureDeps({gpu:true})` 装的是 `onnxruntime-gpu`，**不等于 GPU torch 已可供精排使用**；向导须分别探测"嵌入／精排CPU／精排CUDA"，不能用一个 `depsOk` 冒充全部就绪 | **采纳** |
-| 新增 `beginEngineSwitchPre / getEngineSwitchStatusPre / cancelEngineSwitchPre`，状态由 `createIndexSyncHostPre` 持有 | **采纳** |
-| 保存后才启动切换（不能下拉框未保存就重建）；进度**只能有一个真实所有者** | **采纳**（正面回应了用户"进度条不要和引导耦合"的顾虑） |
-
-### 3.6 Q6（工具数）—— 采纳，且修正我方分类
-
-- **我方矛盾扫描把"工具数"列为"真冲突"，同一节又写"不真冲突"** —— 自相矛盾，GPT 指出。
-- **修正分类**：属**集成与版本边界**，不是真冲突。
-- **采纳处置**：**同一套测试中明确两种能力集合**（白板工具关闭 14 / 启用 16）；三个套件验证**精确名称集合、无重复、schema 及可调用性**，**数量作为派生检查**。
-- **关键**：测试预期须来自**已批准的公共工具清单**，**不能从被测注册结果自动生成**（否则自证正确）。
-- **Phase 6 的 `kind` 参数即使不增工具数也改 schema** ⇒ 必须保留旧调用兼容测试（`memory_log_pre({note,date})` 仍有效）。
-- **独立立项 + 回归窗口是对的，但不能代替最终集成回归**。
-
-### 3.7 Q7（遗漏）—— 采纳，四处"不能靠沿用解决"
-
-GPT 指出调和的主要损失不是"整章被删"，而是**"沿用"掩盖了编号归属变化、接口前提变化和回滚矛盾**。四处必须处理：
-
-| # | 问题 | 处置 |
-|---|---|---|
-| **1** | **Phase 6 并非整体无依赖** | **采纳拆分**：**6A 表达 + 既有节奏接线**（紧随 P0）；**6B 分类持久化、规则修改撤回、跨窗口失效**（接在 P1 上）。"不必等检索算法，但不能绕过状态提交" |
-| **2** | **T7-4 关键词强制升级不可原样实现** | **采纳，且这是对我方提案的纠正**。反例：`"文档写着必须重启"`、`"曾经要求必须 X 但已取消"` 也会命中。改为：**只有明确规则来源才进规则层；普通资料命中关键词只产生「待确认候选」，不自动取得不可裁地位**。若选无条件升级，必须接受规则膨胀、旧规则复活、引用内容被当指令的误报 |
-| **3** | **规则真源漂移** | 见 §2.3 |
-| **4** | **新旧开关不能撤掉共同保护** | **采纳**：「共同状态、版本、用户区和提交保护放在分支外；旧算法仍可选」；`criteriaGate=false` 与"硬失败仍照写"**不得成为共同保护的旁路**；写入保护故障回**只读**，不回到覆盖丢卡的旧写法 |
-
-**新增断言**：T7-4 修订（引文/历史描述/已撤回规则即使含"必须"也不得自动升级）、**T7-7 行为验收**（除检查规则在最终请求内，还要检查**可机械判断的执行结果**是否满足规则 —— 仅引导语不同不能判"遵守问题已解决"）、T6-6 扩展（新旧模式分别提交丢卡/撤回/旧版本/用户区改动，共同保护均须生效）、**规则迁移断言**、**原文能力补钉**（`readVerifiedMemoryChunkPre` 须核对 UTF-8 区间、行号、digest —— 原 50 条里缺少直接的块保真断言）。
-
----
-
-## 4. 原 50 条断言与 U1–U7 的完整去向
-
-GPT 给出了**逐条去向表**（50 条 + 7 项 U），我方**全部采纳**，不在此重复（见其原文）。三条元规则必须记牢：
-
-1. **"保留"表示仍须施工和验收，不表示已通过。**
-2. **T0-8 与 T1-7 是迁移或扩展，不应把同一个保障重复计数。**
-3. **新 Phase 编号与旧 T 编号分开记录** —— 避免把 `phase6` 测试文件误认成规则层测试。
-
----
-
-## 5. 采纳后的开工顺序（GPT 给出，我方认可）
-
-```
-P0 与白板最小适配边界  →  P6A  →  P1 与 P6B  →  P2  →  P3  →  P4  →  P5
-        （完整白板线独立推进，在"共同接口"与"最终集成回归"两处汇合）
-```
-
-**与总纲 v1 的两处差别**：
-- v1 把 Phase 6 整体排在 Phase 0 之后；**v2 拆成 6A（紧随 P0）/ 6B（接在 P1 上）** —— 因为 6B 的分类持久化**不能绕过状态提交**。
-- v1 把白板线整体排在外面；**v2 要求 P0 与"白板最小适配边界"同时做** —— 因为写入门要保护卡片集合与用户区，**没有适配器就是"接口接上了但保护失效"**。
-
----
-
-## 6. 未采纳 / 保留意见
-
-**暂无驳回项。** GPT 本轮的全部修正均在核实后成立或属设计判断上的更优选择。
-
-**唯一需要用户裁决的一处**：§3.3 的 Q3b，GPT 选 (ii) 并给出 `Bo` 派生初值方案。用户此前说"偏向 GPT 决定、我方审" —— 我方审核结论：**通过**。理由：它同时满足用户两条约束（预留数字由实际内容决定，不设魔数；不新增调度/分配框架），且明确说出了代价（不再承诺固定总量上限）。
-
----
-
-## 7. 本次核实的方法纪律（留痕）
-
-- 凡 GPT 断言"代码现状"，**一律打开文件读当前字节**，不采信转述（V1–V6 六条全部实读验证）。
-- 凡我方判定与它冲突，**先假定我方错**，再去找反证 —— 本轮正是这样发现 §2.1 的归因错误。
-- 凡"看起来合理"的设计修正，**不因它合理就跳过核实**（如 §3.3 的 `0` 回退问题，实读 `:7455` 确认）。