docs(路线图): 合并V2.5阶段基线

docs/decisions.md

@@ -578,3 +578,33 @@
 - 分区键进入每次领域写入，能维持 V2.2 分区表设计的查询边界。
 - AppData fallback 让迁移可回滚、可兼容旧数据，但不再制造长期双事实源。
 - RBAC/配置表会影响权限模型和管理流程，单独成阶段更安全；V2.4.5 只收口当前高频业务写入，避免为了“全收口”临时设计不稳的权限 schema。
+
+## 45. V2 后端关系化采用八阶段交付链路
+
+**问题**：V2.1/V2.2/V2.3 已经分别解决了服务端持久化、关系表快读和 AppData 写入后同步关系表。后续如果只写“AppData 退场、权限审计、性能增强、企业能力、生产稳定”这些大方向，容易出现三个偏差：V2.4 写领域 CRUD 时没有提前埋权限和审计，V2.5 把 AppData 当成可直接删除的旧表，V2.6 才发现分页、索引和查询边界没有在 API 设计期处理。
+
+**决策**：
+- V2.1：AppData 服务端持久化，先把业务数据从浏览器 localStorage 迁到服务端。
+- V2.2：关系表 + 分区 + 快读 API，优先支撑版本详情、需求池、工作台和小宝预警等读热点。
+- V2.3：AppData 写入后同步关系表，兼容期内保证快读数据跟随更新。
+- V2.4：领域 CRUD 主写迁移。每个领域 API 从第一版就必须带资源作用域、当前用户、`actorId`、基础审计事件入口、分页、索引和分区键查询边界。
+- V2.5：AppData 分阶段退场 + RBAC/审计/一致性收口。退场顺序固定为“禁写 → 双读核对 → 移除 fallback → 只读归档/导出 → 后续删表”。
+- V2.6：大数据性能增强 + 小宝预警后台化。在关系表主源稳定后做压测、慢查询治理、缓存/摘要、后台任务、幂等、锁和失败重试。
+- V2.7：企业级协作能力 + 管理治理，补通知、协同、组织治理、管理视图和企业级配置。
+- V2.8：生产硬化稳定版 + 运维闭环。生产部署基线已存在，V2.8 聚焦备份恢复演练、发布 smoke test、监控告警、日志检索、迁移回滚和运维手册。
+
+**理由**：这条链路保持了从低风险兼容到强一致主源的顺序。权限/审计必须随领域 CRUD 进入代码路径，否则后补会重写接口边界；AppData 退场必须有闸门和回滚价值，不能直接删除；性能基础要从 V2.4 的 API 设计开始，V2.6 只做规模化增强和后台化能力。这样每个阶段都有清晰验收物，也能避免长期双主源、无审计写入和大数据查询返工。
+
+## 46. 业务主数据源切换到 PostgreSQL 领域关系表
+
+**问题**：AppData JSONB 文档表解决了浏览器 localStorage 丢数据问题，但如果继续把 `app_data.value` 当长期主数据源，会带来三个风险：整份 JSON 写入难以做字段级事务和权限校验，大数据量下筛选/分页/统计仍要依赖派生同步，线上排查时容易出现 AppData 与关系表不一致。
+
+**决策**：
+- PostgreSQL 领域关系表是后续业务主数据源，AppData 只保留为迁移、回填、兼容读取和审计排查入口。
+- 新增业务模块不得新增 AppData key 作为主存储；必须先设计关系表、Prisma model、领域 CRUD API 和必要的索引/分区键。
+- 现有 AppData key 按领域逐步迁移：先补关系表写 API，再让前端 store 写领域 API，最后移除对应 `saveServerData/loadServerData` 主路径。
+- V2.2 快读失败时的 AppData fallback 只能作为迁移期兜底，不能通过硬编码 `usingV22=false` 长期绕开关系表。
+- 删除或停用 JSON 文档前必须完成数据备份、迁移计数核对、抽样校验和回滚预案。
+- 一次性同步脚本可以存在，但必须作为运维迁移工具管理，不能依赖提交 `.env` 或手工修改源码开关。
+
+**理由**：系统未来要承载大量需求、任务、测试用例、Bug、活动和风险数据。关系表才能提供可验证的约束、事务、索引、分页、权限和审计能力。AppData 是低风险迁移桥，不是最终架构；继续扩大 JSON 主存储会把数据一致性和性能问题推迟到更难修的阶段。