@a9i5k4/dsh-auto-memory 3.0.0 → 3.1.0

package/docs/internal/MERGE-CONFLICT-SCAN-20260914.md

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

package/docs/internal/NEXT-VERSION-TODO.md

@@ -1,95 +0,0 @@
-# 下一版待改（用户 2026-09-10 19:0x 指定）
-
-> 来源：用户实机观察 —— 「自动接续又触发了，而且确实才刚过半，太浪费；你现在依靠那个 max output 来算，但官方压缩也是等到上下文真正占到 80% 才开始；新窗口依旧没有按正确序号排序。接续流程我已经关掉了，只要记着下一版怎么改就行。」
-> 状态：**✅ 三项已于 v2.5.0（2026-09-13）落地**：①分母=官方声明窗口（reserve 退出分母，新增预测性硬墙 estTokens+reserve>判定窗）②cont-seq.json 持久计数器（全局单调/失败回滚/标题扫描兜底，smoke-test-contseq-pre.mjs）③docs/prompts/RELEASE-AGENT.md 等四份任务书 + RELEASE-PROCESS.md 角色分工。`autoContinueEnabled` 出厂默认仍为 false，是否翻回待用户实机验证后定夺。
-
----
-
-## 改点 1 · 水位判据口径：不要把「预留输出」当成分母
-
-### 现状（取证到行）
-| 位置 | 事实 |
-| --- | --- |
-| `lib/index.js:1884-1886` | `win = sessModel.contextWindow`（官方声明窗口，本机 deepseek-flash = 1,048,576） |
-| `lib/index.js:1899` | `reserve = sessModel.maxTokens`（该路由预留输出，实测 384,000） |
-| `lib/index.js:1900` | `effectiveWin = (reserve > 0 && reserve < win*0.9) ? win - reserve : win` → 本机 **664,576** |
-| `lib/index.js:1967` | `waterLevelRing = estTokens / win`（声明窗口口径） |
-| `lib/index.js:1971` | `waterLevelWall = max(0, hardWin − reserve)`（距硬墙余量） |
-| 触发判据 | 走**可用额度口径**（`estTokens / effectiveWin`）：实测阈值落在 ≈46 万 token，而**官方压缩要等到约 80% ≈ 83.9 万**才动手 → **早触发约 45%** |
-
-### 根因
-把「单次请求的最大可用额度」（`win − reserve`）当成了水位分母。它确实是**单请求硬失败**的边界，但不是**官方压缩**的坐标系 —— 于是水位数被系统性放大，接续在"刚过半"时就触发。
-
-### 下一版改法（两条线并行，别只改一半）
-1. **正常接续触发线与官方压缩同坐标系**：分母改用**官方声明窗口 `win`**（或 provider 自报硬限 `hardWin`，取能得到的最小可信值），阈值默认 **0.75–0.78**（略早于官方 0.80，好在压缩丢细节之前完成一次干净交接）。
-2. **保留硬墙保护，但降级为"真会失败才触发"**：仅当 `estTokens + reserve > min(win, hardWin)`（下一次请求就会被拒）时才硬触发。**不要把 reserve 从分母里扣掉** —— reserve 只用于"距硬墙余量"展示与这条硬判据。
-3. **展示与判据解耦**：面板继续显示双口径（本会话水位 / 官方小圈读数 / 距硬墙余量），但**触发只认第 1 条的坐标**；`CONTEXT_WINDOW_EXCEEDED` 与 compaction 事件继续作硬触发（不变）。
-4. 迁移注意：老配置里已落盘的 `autoContinueThreshold`（0.75）在新坐标系下语义等价于"窗口的 75% ≈ 78.6 万"，正好落在合理位置；**不需要强制迁移**，但要在设置页 hint 里改口径说明（"按官方窗口计，官方在 80% 压缩"）。
-
-### 验收
-- 本机 deepseek-flash 路由：阈值 0.75 时，触发点 ≈ 78.6 万 token（而非 46 万）；`waterLevelRing` 与触发比例**同分母**。
-- 单请求硬失败保护仍在：构造一条 `estTokens + reserve > win` 的场景，应走硬触发而不是等到比例线。
-- 回归：`water-window-pre` / `water-hard-trigger` / `autocont-host` / `water-step` 四个套件全绿（含新增"不得把 reserve 计入分母"的反向锁）。
-
----
-
-## 改点 2 · 接续序号（新窗口没按正确序号）
-
-### 现状（取证到行）
-| 位置 | 事实 |
-| --- | --- |
-| `lib/index.js:2646-2648` | `contSeq = (handoff 目录里 /^prev-session-.*\.md$/ 的文件数) + 1` |
-| `lib/index.js:2533` | 转写包落盘名：`prev-session-<sid8>-<stamp>.md` |
-| `lib/index.js:2182-2187` | 宿主兜底路径补的 `sc.rename({sessionId, title: '接续 #' + contSeq + ' · ' + wsBase})`（2026-09-10 才补，此前只有浏览器路径有） |
-
-### 疑似根因（下版按序排除）
-1. **计数来源不稳**：序号来自**文件枚举**，而包是"接续时/之后"才落盘的 → 落盘失败、被清理、或写到**别的工作区的 handoffDir**（`p.handoffDir` 是按工作区解析的）时，计数不递增或**跨工作区重复**。
-2. **取数时机**：`contSeq` 在 `buildContinueCarry` 里算，若该次 carry 复用了缓存/旧 pack，`contSeq` 可能为空 → `if (d.contSeq ...)` 不成立 → **不 rename**，标题退回自动生成的"接续上一会话的任务。材料已…"（此现象早前出现过一次）。
-3. **路径覆盖不全**：三条入口（面板一键接续 / 宿主兜底接续 / 重启后接续）是否都拿到了 `contSeq` 并成功 rename，需逐一核对 diag 日志。
-
-### 下一版改法
-1. **序号改持久计数器**：`handoff/cont-seq.json`（键 = workspaceId，值 = 已发出的最大序号），取数即 `++`；若文件缺失则回退为"从现有 `接续 #N` 标题/`prev-session-*` 包名里解析最大值 + 1"（兼容老数据）。
-2. **rename 兜底**：把 `contSeq` 为空的情况改为"用持久计数器兜底值"而不是跳过；rename 失败写 diag（现状只有 catch 里一条 diag，需确认两条入口都写）。
-3. **会话列表排序依据**：若侧栏排序仍不按序号，检查是否需要在 rename 后同步排序字段（sequence/title 排序键），不要只改标题。
-4. **落盘顺序**：确认"写包 → 算序号"还是"算序号 → 写包"，把序号分配与包落盘做成**同一次事务的顺序**（先分配序号、再写包、失败回滚计数器）。
-
-### 验收
-- 连续接续 3 次：标题依次为 `接续 #N`、`#N+1`、`#N+2`；换到另一个工作区接续**不重复**已有序号。
-- 三条入口各测一次，diag 里都能看到 rename 成功记录。
-- 新增 smoke：计数器持久化 + 跨工作区不重复 + 包落盘失败时不跳号。
-
----
-
-## 关联现状（改这两个点之前要知道）
-
-- 用户**已手动关闭自动接续**（`autoContinueEnabled = false`）以免浪费 token；改完需用户自行开启并重启 dsh web 验证。
-- `v2.4.1` 已含「已接续闩锁」（`~/.dsh/memory/auto-continue-done.json`），本次"又触发"是在**该闩锁之前就已 arm 的会话**上发生的，不代表闩锁失效；下版验证时要区分"闩锁没拦住"与"口径太早"。
-- 相关 diag：`~/.dsh/dsh-auto-memory-pre-diagnose.log`（`auto-continue armed / deferred / deadline reached / rejected at edge / host-executed` 全在这条线上）。
-
----
-
-## 改点 3 · 固定流程外包给子代理（主对话只做决策）
-
-> 用户 2026-09-10 提出：「这种固定流程（尤其是已经多次固化成 skill 的），比如发版本，不应该由主对话来处理，主对话太耗上下文了，应该丢给一个 sub agent，思考强度不用特别高。他做完了或者出错了就扔回主对话，让主对话决定怎么解决。」
-
-### 目标形态
-- **主对话只做三件事**：①开闸前确认前置门（脏树范围核实 + 全量回归结果）②收到回报后判定放行/中止 ③失败时决定处置方向。**不逐步执行流程**。
-- **子代理执行**：按检查表全跑，**出错即停**，回报一个结构化结论：
-  `{ ok, version, pre_sha, rel_sha, tag, npm_latest, failed_step, error_tail(≤20 行) }`
-- **凭据不进提示词**：子代理自行从 `--D--dsh_debug--/MEMORY.md` 读（该处明确「只存本地，严禁写入任何会上传 GitHub/npm 的文件」）。
-
-### 落地形态（下版做）
-1. **`docs/prompts/RELEASE-AGENT.md`** —— 给子代理的完整任务书：照 `docs/internal/RELEASE-PROCESS.md` 逐条展开 + 回报格式 + 出错即停规则 + 禁止事项（无 PAT 不得 push、未过闸门不得发布、除版本标识与 CHANGELOG 外不得改文件）。
-2. **`RELEASE-PROCESS.md` 顶部加「角色分工」段**：主对话=决策者 / 子代理=执行者，并写明「主对话不得逐步执行本清单」。
-3. **同类流程一并外包**：全量回归、docs 双语对账、子代理痕迹巡检，各写一份任务书（`docs/prompts/*-AGENT.md`）。
-
-### 已知约束（先记下来，免得下版踩）
-- **当前工具面无法给 `subagent` 指定思考强度**：`subagent` 只接受 `description/prompt/run_in_background`，`workflow` 的 `agent()` 会**显式拒绝** `effort`/`agentType`。要真压到 low/off 只有两条路：①在 DSH 侧给该路由/预设配默认推理强度；②**由插件自己 spawn** —— 插件已有 `subagentReasoningEffort: off|low|high|max`，经 `ctx.subagents.start({ agentOptions })` 下发。
-- **子代理看不到主对话**：任务书必须自包含（路径、命令、判据、回报格式全写死）。
-- **不得并发**：同一工作区的写盘流程（尤其发版）必须串行。
-- 子代理同样受「不重启宿主」约束：需要重启才生效的事只能回报给用户，不能自己动手。
-
-### 验收
-- 主对话跑一次发版：其上下文增量只含「开闸判断 + 子代理回报 + 三处复核」三块；
-- 故意造一次失败（如抽掉 CHANGELOG 的 `## [<ver>]` 小节）：子代理回报 `failed_step=5.05` 且 `error_tail` 含闸门原文，主对话据此给处置；
-- 子代理输出里不出现凭据明文（除命令行本身；不落盘、不入 git）。

package/docs/internal/OFFICIAL-DISCUSSION-DRAFT.md

@@ -1,80 +0,0 @@
-# 官方反馈定稿（子代理报告路由）
-
-> 目标仓库:`deepseek-ai/deepseek-harness`(Discussions · 分类 **General**)
-> 发帖入口:https://github.com/deepseek-ai/deepseek-harness/discussions/new?category=general
-> 说明:第三方插件 dsh-auto-memory 为**非官方**项目,帖内已按社区规则标注。
-
----
-
-## 标题
-
-```
-[Bug Report] 会话接续后，后台子代理的完成报告仍投递给旧会话；父会话不在册时通知被静默丢弃
-```
-
-## 正文
-
-```markdown
-## 环境
-- `@deepseek-ai/dsh` **0.1.5-rc.1**，Windows 11，web profile
-- preset：`standard`（`agent.cordis.yml` 里 `backgroundMode: continuable`，所以后台子代理默认走 continuable 路径）
-- 场景：用第三方插件（非官方，我自己维护的 dsh-auto-memory）实现**会话接续**——上下文水位到阈值时新建会话 B、把交接材料注入 B，旧会话 A 仍然 live。
-
-## 现象
-1. 会话 A 派出的后台子代理结束后，报告落在 **A** 里；接续出来的会话 **B 收不到**任何东西——用户在 B 里等结果，永远等不到。
-2. 更严重：如果 A 已经被 dispose，这条报告**彻底消失**——没有任何日志、告警或替代投递，表现为“子代理跑了但什么都没回来”。
-
-## 最小复现
-1. 在会话 A 里让 agent 起一个后台子代理（`subagent` 工具，默认 `run_in_background`）
-2. 在子代理结束**之前**，把工作搬到会话 B（接续、或手工直接开新会话继续都一样）
-3. 子代理结束后回到 A：报告在 A；B 里什么都没有
-4. 若先关掉 A 再等子代理结束：两边都收不到，也没有任何提示
-
-## 代码定位（0.1.5-rc.1，`@deepseek-ai/dsh-subagent/lib/index.js`）
-- **运行时绑定**：`activation.parentSession = parent.id`（:1087-1098）在 spawn / cold-resume 时写死为**字符串**；durable 侧 `SessionHeader.parentSession` 也是 readonly（`dsh-session/lib/types/types.d.ts:71`）。
-- **结算投递**：`notifySettlement()`（:1244-1259）
-  \`\`\`js
-  const parent = this.ctx.agents.get(activation.parentSession)
-  if (parent === void 0) return                       // ← 静默丢弃，无日志
-  const message = createSettlementMessage(activation.childId, terminal)
-  this.sendWaking(parent, message, parent.status === "idle" ? "queue" : "steer")
-  \`\`\`
-- **契约里没有 re-parent**：`SubagentRuntime` 的公开方法是 `start / startContinuable / sendMessage / interrupt / listChildren / listDescendants / remoteExportList / prompt / interruptByParent / drainContinuableChildren / drainContinuableDescendants / registerProvider / getProvider / list`，**没有 transfer / reassign / attach / rebind**。
-- **新会话接不过去**：`sendMessage` → coldResume → `authorizeLineage` 直接抛 `UNAUTHORIZED`（“belongs to another parent session”）。
-- **查询侧同父过滤**：`listChildren(newSessionId)` 查不到旧子代理（:2073 按 `record.header.parentSession === parentSessionId` 过滤），只有拿旧 id 才查得到。
-
-## 影响
-- 任何“会话迁移 / 接续 / 交接”类工作流（插件或人工）都会丢上下文；上下文满得越快，这个操作越常规（我们这边 30 分钟一满）。
-- 静默丢弃让问题不可见：没有日志行可查，用户只能看到“子代理没回话”。
-- 长跑子代理尤其致命：它们往往正是最需要投递结果的那批。
-
-## 建议（任意一条都能覆盖）
-1. 给一个**显式的转发口子**：例如 `subagents.reassign(childId, newParentSessionId)`，或在 `notifySettlement` 前提供可挂载的 hook，让宿主/插件把结算通知投到指定会话；
-2. 或至少把“父不在册”从静默 `return` 改为**可见**：`logger.warn` 一行，并考虑把 `lastAssistantMessage` 落到子会话持久文件、在 catalog 里标出来；
-3. 或让 `listChildren` / `remoteExportList` 支持按**根会话树 / 工作区**查询（现在只有“直系父 id”这一条路），这样接续后的新会话至少能自己发现并读取还在外面跑的子代理。
-
-## 我们目前的绕过方案（仅供参考，不要求官方照做）
-- 接续前用旧会话 id 调 `listChildren`，把未完成子代理清单写进交接材料；
-- 插件旁听 `subagent/end` / `session/event`，收到结算通知就把文本**复制**投给新会话（`agents.get(newId)` → `followup` / `inject`）。
-- 局限：这只是“复制”，旧会话仍会收到原件；而且依赖旧会话在结算时仍 live，否则连复制都没有素材。
-
-（我是 dsh-auto-memory 插件作者，上面提到的插件是**第三方、非官方**项目。）
-```
-
----
-
-## 微信群短文案（约 200 字，可直接粘）
-
-```
-【DSH 0.1.5-rc.1 · Bug 反馈】子代理完成报告在会话接续后会投错窗口
-
-现象：会话 A 派出的后台子代理结束后，报告落在 A；用新会话 B 接着干活时 B 什么都收不到。
-更麻烦的是，如果 A 已关闭，报告会**静默消失**（无日志无告警），看起来就像“子代理跑了但没回话”。
-定位到 dsh-subagent 的 notifySettlement：父会话 id 在 spawn 时写死，结束时按它现查注册表，查不到直接 return。
-插件的落点：dsh-subagent/lib/index.js:1244-1259（静默丢弃在 :1249）。
-
-已在官方 Discussions 提了详细报告（含最小复现、代码定位与三条建议）：
-<在此粘贴讨论链接>
-
-希望官方能给一个结算通知的转发/重定向口子，或至少让“父会话不在册”这件事可见。
-```