feat(v2.3): 完成关系表写入闭环

docs/decisions.md

@@ -529,3 +529,17 @@
 - `xiaobao_risk_summaries` 不分区，保持 `version_id` 单行汇总；历史趋势进入分区快照表。
 
 **理由**：把分区键纳入主键和唯一约束是 PostgreSQL 分区表的结构性要求。提前做这件事，可以避免客户数据变大后再重塑主键和外键。固定 HASH 分区避免每个项目/版本单独建分区的维护负担；RANGE 分区只用于天然追加、按时间维护的历史数据。
+
+## 43. V2.3 AppData 写入后非阻塞同步关系表
+
+**问题**：V2.2 已经让版本详情、需求池、与我相关和小宝预警优先读取关系表，但前端保存仍然写 AppData。如果关系表不跟随 AppData 更新，快读路径会逐渐变旧，最后又回落到加载大 JSON 文档，无法解决几十万条需求/任务/用例后的卡顿风险。
+
+**决策**：
+- AppData 继续作为兼容窗口内的写入事实源，`DataService.put()` 先完成乐观锁写入，再触发关系表同步。
+- 同步服务独立为 `AppDataV23SyncService`，复用 V2.2 mapper，不把一次性迁移服务改造成在线写入服务。
+- 当前态表按分区键作用域替换：需求按 `product_id`，版本计划/开发任务/测试用例/BUG 按 `version_id`。
+- 追加型证据表继续 `createMany(skipDuplicates)`，不因当前 AppData 文档缺失而删除历史。
+- 小宝摘要由快照刷新；计划/任务/用例/BUG/活动/工时/加班变更只标记摘要 `dirty=true`，等待下一次规则计算刷新完整内容。
+- 同步失败只记录日志，不阻塞 AppData 保存。慢 API 和慢 Prisma 查询先通过日志监控，后续再接 Prometheus/Grafana。
+
+**理由**：这是从 AppData 兼容写入平滑过渡到领域 CRUD 的中间层。用户保存不能因为派生关系表暂时失败而丢失业务数据；同时，关系表保持跟随更新后，V2.2 快读路径才能真正承受大数据量。把同步服务独立出来，也能让后续领域 CRUD 逐步替换 AppData 时复用同一套映射和小宝 dirty 策略。