refactor(data): 收口关系表运行时数据源

- 移除已迁移业务 AppData 运行时 fallback，改走领域 API 和关系表快读
- 补齐需求产品负责人、版本计划任务 JSON 和成员 username 回填迁移
- 统一治理字典入口，并补充 AI provider、数据源契约和领域服务测试

Co-Authored-By: Codex GPT-5 <codex@openai.com>

docs/decisions.md

@@ -442,7 +442,7 @@
 - AI 解读自动触发，不提供人工“AI 解读”按钮。缓存签名必须覆盖趋势、原因、静默风险、日报/活动证据、风险信号和置信度，避免复用过期解读。
 - 快照保存需要节流：同版本同日普通变化 10 分钟内不重复保存；风险等级变化、风险分变化达到阈值、关键 Bug/失败用例/阻塞/静默风险变化或预测日期明显变化时立即保存。
 - AI 解读需要 cooldown：同版本最近 6 小时内已有解读时不重复请求；如果风险等级升级，则允许绕过 cooldown。
-- AI 只写入 `xiaobao-risk-insights` 缓存，不修改 Version、DevTask、TestCase、Bug、Requirement 或 Member。
+- AI 只写入 `xiaobao_risk_insights` 关系表缓存，不修改 Version、DevTask、TestCase、Bug、Requirement 或 Member；历史 `xiaobao-risk-insights` AppData 只保留归档/迁移价值。
 
 **理由**：规则结果可测试、可追溯、可复盘；AI 文案提升可读性，但不能替代系统事实判断。趋势、静默风险和置信度能弥补“当前风险等级”过于静态的问题。
 
@@ -569,14 +569,15 @@
 - 需求池列表/search/filter/sort 走服务端分页，避免加载全量 AppData 文档。
 - 版本详情实体按 `versionId` 分区键写入；Requirement 按 `productId` 分区键写入；追加型证据表保留追加语义，不从 AppData 快照反向删除历史。
 - `/workspace` 和 `/xiaobao-warning` 继续走关系表聚合/快读。领域写成功后通过工作活动和小宝 dirty 标记维持证据链。
-- AppData 保留为兼容读取、失败回退、历史迁移和少量配置承载，不再作为已迁移领域的事实源。
-- 成员迁移采用保守边界：`users` 存成员身份字段；部门、角色、密码规则暂不在本阶段发明完整 RBAC 表，仍作为 AppData 兼容配置。
+- AppData 在 V2.4 迁移窗口保留为兼容读取、失败回退、历史迁移和少量配置承载，不再作为已迁移领域的事实源。
+- 当前 V2.5+ 收口后，正常业务 UI 不再把 AppData 作为失败回退；已迁移业务 store 运行时不读写 `products-overview`、`requirements`、`version-plans`、`dev-tasks`、`test-cases`、`bugs`、`task-categories`、`task-worklogs` 和 `work-activities`。
+- 成员迁移采用保守边界：`users` 存成员身份字段；部门、角色、密码规则暂不在本阶段发明完整 RBAC 表，仍作为 AppData 配置。`members` AppData 不再作为成员身份来源，也不再写入当前成员数组。
 - 加班原因同样暂留 AppData 配置；加班记录本身写 `overtime_records`。
 
 **理由**：
 - 领域 CRUD 直接写关系表后，读写路径对齐，分页、筛选、聚合和风险预警不再依赖 AppData 同步是否及时。
 - 分区键进入每次领域写入，能维持 V2.2 分区表设计的查询边界。
-- AppData fallback 让迁移可回滚、可兼容旧数据，但不再制造长期双事实源。
+- 迁移期 AppData fallback 让迁移可回滚、可兼容旧数据；当前收口后必须移除正常业务运行时 fallback，避免继续制造双事实源。
 - RBAC/配置表会影响权限模型和管理流程，单独成阶段更安全；V2.4.5 只收口当前高频业务写入，避免为了“全收口”临时设计不稳的权限 schema。
 
 ## 45. V2 后端关系化采用八阶段交付链路
@@ -614,13 +615,14 @@
 **问题**：V2.4 已经把主要领域写入迁到关系表，但 AppData 里仍保存历史 JSON、旧部署 fallback 和少量尚未领域化的配置形状。如果直接删除 `app_data` 或移除 `/data/:key`，会失去回滚、迁移核对和历史排查依据；如果继续允许写入，又会把双事实源问题拖进 V2.6。
 
 **决策**：
-- 每个 AppData key 明确进入 `write_frozen` 或 `read_only_archive`，由 `AppDataRetirementService` 集中配置替代 API 和说明。
+- 每个 AppData key 由 `AppDataRetirementService` 集中声明退场状态、替代 API 和说明；已迁移业务 key 进入 `write_frozen` 或 `read_only_archive`，`members` 仅作为部门、角色、密码规则的临时配置文档保持 `active`，`overtime` 仅作为加班原因配置文档保持 `active`。
+- 正常业务前端不得从 AppData 读取已迁移业务 key；成员身份读取走 `/api/v1/members`，加班记录读取走 `/api/v1/overtime`。
 - 冻结 key 的 `PUT /api/v1/data/:key` 返回 `409 APP_DATA_WRITE_FROZEN`；`GET` 继续可用，用于历史读取、归档导出和人工核对。
 - Product/Project/Version/Requirement/VersionPlan/DevTask/TestCase/Bug/Member/TaskCategory/TaskWorklog/Overtime/WorkActivity 等领域 mutation 全部使用 `@ProtectedMutation()`，同一个装饰器组合权限、资源作用域和审计写入。
 - `audit_events` 采用 append-only 模型，按 `created_at` 分区；敏感字段由 AuditService 脱敏，查询接口需要 `audit:view`。
 - 一致性校验同时提供 `GET /api/v1/consistency` 和 `pnpm consistency:v25`，检查 counts、分区键、孤儿引用和审计覆盖。历史数据缺少审计事件只作为 warning，不把迁移前事实误判为当前写路径错误。
 - 当前 server auth context 先用 `x-ftb-user-*` 头作为稳定 adapter，前端从现有登录会话补齐这些头；正式 JWT/NextAuth 服务端验证留给后续认证治理阶段。
-- Xiaobao risk snapshots/insights 的 AppData key 进入 `read_only_archive`，关系表写入和后台化归 V2.6；`xiaobao-warning-views` 读状态 API 归 V2.7。
+- Xiaobao risk snapshots/insights 的 AppData key 进入 `read_only_archive`，正常前端运行时不得读写；关系表写入和后台化归 V2.6。`xiaobao-warning-views` 同样只保留归档价值，当前前端已读状态在专用 API 落地前仅作为浏览器本地 UI 状态。
 
 **理由**：冻结写入能立即切断新的双主源风险，同时保留旧 JSON 的审计和回滚价值。把权限和审计合并到领域 mutation 装饰器，可以确保后续新增写接口默认带服务端 guard 和 audit event。审计覆盖对历史数据只告警，避免为了“补齐历史审计”伪造事件。auth header adapter 给 V2.5 一个可测试的服务端权限边界，但不把它包装成最终安全方案，后续 JWT/企业 RBAC 可以替换 adapter 而不改领域 controller 合同。
 
@@ -683,15 +685,14 @@
 
 ## 52. V2.7 协作治理先落稳定适配器，不硬编码临时权限
 
-**问题**：V2.7 需要通知、评论、项目成员治理、管理驾驶舱和治理字典。如果各 V2.7 模块直接写临时权限判断和审计插入，就会绕开 V2.5 已落地的服务端权限、审计和资源作用域边界，后续认证治理也会再次返工。
+**问题**：V2.7 需要通知、评论、项目成员治理和管理驾驶舱。如果各 V2.7 模块直接写临时权限判断和审计插入，就会绕开 V2.5 已落地的服务端权限、审计和资源作用域边界，后续认证治理也会再次返工。
 
 **决策**：
-- 新增 `RbacService` 作为项目角色与全局权限断言适配器，Owner/Admin/Member/Viewer 的层级判断和 `management:view` / `governance:manage` 等全局权限入口集中在此处。
+- 新增 `RbacService` 作为项目角色与全局权限断言适配器，Owner/Admin/Member/Viewer 的层级判断和 `management:view` 等全局权限入口集中在此处。
 - 新增 `AuditService` 作为审计写入适配器，业务模块只提交 `actorId/action/resource/before/after`。
 - 通知事件类型固定为 `assignment / mention / risk_alert / overdue_item`，跨模块通过这些稳定语义发通知。
 - 通用评论使用 `entityType + entityId + entityVersionId` 的多态引用，不给每个业务表单独建评论表。
 - 管理驾驶舱只读关系表和 `xiaobao_risk_summaries`，不回读 AppData。
-- 治理字典使用软删除或使用中禁止硬删，变更必须写审计。
 
 **理由**：适配器把协作治理模块的权限和审计接入点收束在一层，既能复用 V2.5 的服务端控制面，也给后续 JWT/NextAuth 和企业级角色体系留下替换点。稳定事件名和多态评论引用能避免后续模块继续扩散 ad-hoc 字段。
 
@@ -716,3 +717,17 @@
 - 权限红线：Analysis Agent 只能查询当前用户已有权限的数据，自然语言不能扩大范围；无权限时拒绝或返回授权范围内的空结果。
 
 **理由**：Semantic Layer 和 Metric Catalog 能把自然语言、业务口径和数据库字段解耦；metric version 和 result snapshot 能支撑历史分析复现；Analysis Plan Processor 保证 AI proposal 不直接变成系统执行；统一 ChartSpec 和 MetricResult 让 ECharts 只是当前 renderer，而不是长期数据契约。这样第一版可以靠固定模板稳定交付，后续又能通过确定性组合和受控 AI Planning 扩展能力。
+
+## 54. 任务类型与需求池字典统一进入治理设置
+
+**问题**：需求池类型/来源/支持端、开发任务类型和测试用例任务类型都属于可复用业务字典。如果分别在需求池、版本详情和治理设置维护，会出现多个入口、口径不一致和使用中 ID 难以追踪的问题。
+
+**决策**：
+- 恢复 `/admin/governance` 作为统一治理设置入口，由 `governance:manage` 控制。
+- 治理设置统一维护四类字典：`task_category`、`requirement_type`、`requirement_platform`、`requirement_source`。
+- 开发任务类型和测试用例任务类型继续落在 `task_categories`，但通过治理设置入口统一维护。
+- 需求池类型、来源和支持端优先读写 `/api/v1/governance/dictionaries`，不再通过需求池本地管理抽屉维护。
+- 后端治理列表运行时不再从旧 `requirements` AppData 回填字典。需求池字典以 `governance_dictionaries` 为准；任务类型为空时只种内置默认 `task_categories`，历史 AppData 回填只能作为显式迁移工具执行。
+- Business Analysis Agent 可以读取需求类型/来源作为分析维度，但不负责修改字典。
+
+**理由**：这些字典会被需求池、版本执行任务、测试用例和 AI 分析共同消费，放在治理设置能形成单一维护入口。运行时不再读取 AppData 回填字典，可以避免部署后旧 JSON 把关系表配置反向污染；历史兼容由迁移工具承担，而不是页面访问时隐式发生。