jianf
3adb5a7018
docs+test: README 计数漂移根治 + MIG3 进 check + MIG4 崩溃窗口核实
README 计数漂移（你指出的）
- README.md 的 checkpoint 计数写的是 8/8，实际 9/9（现已 10/10）
- 证据块只列了 V1/V2/V3/V3b/V4/V5 六条，漏了 V3b† / V3c / A5†
- 改为**粘贴真实输出**，并加一段说明「本节曾两次因手抄而漂移」
- 新增自动校验（test/phase-b-g-static.test.js）：比对 README 声称的
checkpoint 数与 scripts/checkpoints.js 里 `await checkpoint('` 的个数，
以及粘入的 "N/N checkpoints passed"。实测变异：把 10 改成 11 → not ok 6
MIG3 进 check（你的建议，采纳）
理由同意：check 是给人看的证据链，而「存量库能不能用」最该被看见；
将来谁改 open()/migrate()，看 check 的人比看 test 的人多。
新增 checkpoint MIG3：手工构造 phase-A 形库（含旧 centroid 表）→
opened → 两表列齐 → 旧块可读且 FTS 命中 → putBlock 成功 →
saveCentroid/loadCentroid 成功。现 10/10。
边角情况（你让我自己判断）——查了，结论与你的推测不同，据实记：
崩溃窗口（rename 成功但 user_version 未写入）**不可达**，
但原因不是我一开始写的那个。我最初注释说「因为 DDL 先跑会重建
graph_centroid」，写完后按纪律去验证，把 open() 里 migrate/DDL 顺序
对调，全量测试**仍然全绿** —— 说明那个解释是错的。
真正原因：pragma_table_info 对不存在的表返回零行，
所以 centroidColumns.length === 0，整个 rename 分支在重试时直接被跳过，
根本不会第二次 RENAME，与 DDL 顺序无关。
已按事实改正 lib/store.js 的注释，并把这个「我写错又验掉」的过程留在
注释里（否则下一个人会照抄错误解释）。新增 MIG4 钉住该恢复路径：
构造「旧表已改名、新表未建、版本未盖戳」的状态 → open 不抛错 →
重建可用 → 旧表行数不变。
验证
- npm test 84/84（83 + README 漂移守卫）
- npm run check 10/10（+MIG3）
- 提交前连跑 3 次 test + 3 次 check，6 次全绿
- 变异全部在 /tmp 干净副本上执行
D 组可以开工。
2026-10-30 10:26:38 +08:00
..
2026-10-30 10:26:38 +08:00
2026-10-30 09:44:42 +08:00