feat(v2.2): 建立分区关系表和AppData迁移预演

docs/decisions.md

@@ -516,3 +516,16 @@
 - 人工新建任务表单继续使用任务类型字典作为可选项，但这个字典会随着 AI 草案采纳自动扩展。
 
 **理由**：人工表单的任务类型是录入辅助，不应该成为 AI 拆解边界。但任务类型字典也不能被单个原型的业务对象污染。`taskTypeName` 只承载可复用分类，具体功能点放在 `title` 和 `description`；采纳时有门槛地补字典，让后续筛选、统计和人工创建复用真正稳定的类型，同时避免 AI 直接写数据库 `categoryId`。
+## 42. V2.2 高增长业务表从一开始采用分区表
+
+**问题**：需求池、开发任务、测试用例、BUG、工作活动和小宝快照会按年持续增长。若先用普通表，后续再切分区表，不只是搬旧数据，还会牵动主键、唯一约束、外键、迁移窗口和回滚方案。
+
+**决策**：
+- `requirements` 按 `product_id` 做固定 HASH 分区，主键为 `(id, product_id)`。
+- `dev_tasks` / `test_cases` / `bugs` 按 `version_id` 做固定 HASH 分区，主键为 `(id, version_id)`。
+- `work_activities` / `task_worklogs` / `overtime_records` / `xiaobao_risk_snapshots` / `xiaobao_risk_insights` / `ai_logs` 按 `created_at` 做 RANGE 分区并保留 default partition。
+- 所有分区表主键和业务唯一约束必须包含分区键，例如 `(version_id, code)`。
+- 引用分区表时优先使用复合外键，例如 `(requirement_id, requirement_product_id)`、`(test_case_id, test_case_version_id)`；多态活动记录使用逻辑外键。
+- `xiaobao_risk_summaries` 不分区，保持 `version_id` 单行汇总；历史趋势进入分区快照表。
+
+**理由**：把分区键纳入主键和唯一约束是 PostgreSQL 分区表的结构性要求。提前做这件事，可以避免客户数据变大后再重塑主键和外键。固定 HASH 分区避免每个项目/版本单独建分区的维护负担；RANGE 分区只用于天然追加、按时间维护的历史数据。