dsh-auto-memory · 待办排期图
自上而下 = 时间顺序 · 依赖用「依赖」标签标注 · 虚线框是留给新待办的空位
待拍板
P0（先做，工程落地）
P1（紧接/并行）
P2（待拍板）
明确推后
待入池（你加的）
3.0 主轨（快刀斩乱麻 · 2026-09-14 定）：本轮只做底层——① 会话检索解锁 ② 三层补全 + 验收门 ③ 分级精确检索 ④ 记忆纠错与索引稳定（块级缓存 / supersede / 防抖）⑤ 验收判据换代 ⑥ 三层量化实验 ⑦ 语义框架审计。
其余一律封存到 3.1：接续开关、模型选择、日历、手机端指引、procedural 重构、白板 combine、界面 / 文档 / 分发。用户没反馈大问题 → 线上不动，攒成 3.0 一次发。
⚡ 2026-09-14 深夜更新：施工蓝本已定版（总纲 v2）
外部评审走完三轮（GPT-6 Astra），产出：《合并总纲 3.0》v2 + 矛盾扫描 + 第三轮复核整合。
本页已按 v2 重写：开工顺序、每阶段六项、15 个拍板点、调研与 combine 的怎么做，全部在图里。
开工顺序（v2 已改，替代旧的"只做底层"粗排）：
P0 与白板最小适配边界 → P6A → P1 与 P6B → P2 → P3 → P4 → P5
与 v1 的三处关键差别（务必先读）：
① Phase 6 拆成 6A / 6B：6A（注入措辞 + 节奏）紧随 P0；6B（规则分类持久化）必须接在 P1 上——它不能绕过状态提交。
② P0 必须和白板最小适配边界同时做：没有适配器，写入门就是"接口接上了但保护失效"。
③ 白板线的 15 个拍板点不再"等做完底层"：它们与 P0/P1 是同一批决策（B1＝写入门、B5＝miv 语义、B4＝用户区、A8＝锚点），决策一起定、实装分两条线。
本次会话新发现的三件事（两份方案都没覆盖）：
· 最痛的病在"注入表达"不在"检索算法"——注入开场白写着「只是背景事实与规则参考」（lib/index.js:463），把规矩降格成建议；且 snapshotMinGapRounds=5 让规矩在第 2–5 轮不在场。→ 新增 Phase 6。
· 已有上千真实用户——npm 近一年下载 10,900、近一周 2,935、66 个版本。→ 兼容档必须真做；「新旧并存可回退」从稳妥变必需。
· 精排实测比方案假设慢 20–50 倍——bge P95 37.4 秒 / qwen 8.8 秒（方案写的是 ≤750ms）。→ 改为多级档位 + 1 分钟异步窗口。