docs(gap): 本地验收记录 —— 行级零差异,全口码改回 legacy

docs/design/gap-set-based-rewrite-plan.md

@@ -244,3 +244,28 @@ WHERE cardinality(COALESCE(rem.remaining_teeth, ARRAY[]::text[])) > 0
 只能走 per-row SubPlan(本地实测:裸写 `NOT EXISTS` 会变成 Anti Join,`CASE` 包住则是 SubPlan)。
 本地两者差距只有 13%(库小全热),生产是否放大**未验**。
 在 TS 侧按 `rule.wholeMouth` 分叉生成 SQL(而不是靠 SQL 的 CASE)是零风险的第一步,值得单独试。
+
+---
+
+## 10. 实施记录 · 本地验收(2026-08-30)
+
+分支 `perf/gap-set-based`。默认仍走 legacy(`PAC_GAP_VARIANT` 未设),集合式靠环境变量切换。
+
+### 与方案的两处偏离(都已改回)
+- 曾把全口码(K05/K07)也统一进 `gap_cand` 形态 —— **实测慢 2~3 倍**
+  (ortho 1309→4439ms ×0.29;perio 1388→3065ms ×0.45),已按 §8 改回原样走 legacy。
+  `buildGapSetBased` 对 `rule.wholeMouth` 直接 `return null`。
+
+### 本地验收结果(30K 患者库)
+| 项 | 结果 |
+|---|---|
+| 单元测试 | 102 套 / 1859 测试全绿(含新增 `gap-setbased-parity.spec.ts` 69 例) |
+| SQL 层对拍 | 11 个子场景**逐 (患者×信号×牙位) 零差异**,行数逐个相同 |
+| 端到端对拍 | `plan_reasons` 39,182 条**行级 diff = 0**(含 priority_score) |
+| 幂等 | 两版互相复跑都 `plansCreated=0 plansClosed=0` |
+| 场景段耗时 | legacy 34.2s → setbased 29.2s(×1.17) |
+
+⚠️ 本地库小且全热、去重比低,**×1.17 不作为收益判据** —— 以测试机 585K 患者的实测为准。
+
+### 对拍工具自检
+`--self`(legacy 对 legacy)先跑过,零差异 —— 证明工具本身不会把相同当不同。