feat(v2.4): 完成领域主写迁移

docs/architecture.md

@@ -33,8 +33,8 @@ Requirement          Version               TestCase
 | 前端 | Next.js 14 (App Router) | TypeScript + 客户端组件为主 |
 | UI | Tailwind CSS + Shadcn/ui | 紧凑信息密度、现代风格 |
 | 状态 | Zustand | 每个领域一个 store |
-| 持久化 | PostgreSQL AppData + 关系表快读/同步（V2.3） | AppData 仍是兼容窗口内主写入；V2.2/V2.3 关系表用于热路径快读和写后同步 |
-| 后端 | NestJS + Prisma + PostgreSQL（V2.3） | Product/Requirement 有领域 CRUD；其他领域仍在从 AppData 向领域 API 迁移 |
+| 持久化 | PostgreSQL 关系表领域主写 + AppData 兼容兜底（V2.4） | 高增长领域直接写关系表；AppData 仅用于历史兼容、迁移兜底和少量配置项 |
+| 后端 | NestJS + Prisma + PostgreSQL（V2.4） | Product/Project/Version/Requirement/VersionPlan/DevTask/TestCase/Bug/Member/TaskCategory/TaskWorklog/Overtime/WorkActivity 均有领域 CRUD |
 | AI | Anthropic SDK（V3 远景） | 健康度/风险预警/排期建议 |
 
 ## 模块结构
@@ -114,21 +114,26 @@ DevTask 没有"已完成"状态，"已提测"就是终态——开发交付完
 
 ## 数据持久化
 
-**当前 V2.3 分层：** AppData 兼容写入 + 关系表快读/同步
+**当前 V2.4 分层：** 领域 CRUD 主写 + AppData 兼容/迁移兜底
 
-兼容写入层仍使用通用服务端文档表 `app_data`：
+领域主写层已经覆盖主要业务实体：
+- 根数据：Product、Project、Version 直接写领域 API，`products-overview` 只作为兼容读取/兜底。
+- 需求池：Requirement 直接按 `productId` 分区键写 `requirements`，列表/search/filter/sort 使用服务端分页。
+- 版本详情：VersionPlan、DevTask、TestCase、Bug 直接按 `versionId` 分区键写关系表，并继续标脏 Xiaobao 摘要和写入工作活动证据。
+- 字典/成员/证据：Member 写 `users` 的成员身份字段；TaskCategory 写 `task_categories`；TaskWorklog、OvertimeRecord、WorkActivity 保持追加/证据型关系表写入。
+
+兼容层仍保留通用服务端文档表 `app_data`：
 - 后端：`apps/server/src/modules/data/` 提供 `GET/PUT /api/v1/data/:key`
 - 数据库：Prisma `AppData` 模型，表名 `app_data`，`key` 为主键，`value` 为 JSONB
 - 一致性：`GET` 返回 `updatedAt` 派生的 `version`；前端保存时带上最近读取的 `version`，后端用 `key + updatedAt` 原子更新，版本不匹配返回 `409 APP_DATA_CONFLICT`
-- 前端：各 Zustand store 保持现有数据形状，通过 `apps/web/lib/server-data.ts` 读写服务端
-- 覆盖范围：产品/项目/版本树、需求池、调研/产品方案/UI 计划、开发任务、测试用例、Bug、成员/角色/部门、任务类型、任务工时日志、加班记录
+- 前端：各 Zustand store 保持现有 UI 数据形状，优先调用 `apps/web/lib/domain-api.ts`；领域 API 不可用时才通过 `apps/web/lib/server-data.ts` 读取或回退保存 AppData。
+- 仍留在 AppData 兼容配置中的内容：部门、角色、密码规则、加班原因等尚未拆出独立 RBAC/配置表的低频配置。
 - 浏览器仅保留登录会话（`ftb_auth_session` / `ftb_auth_persist`），不再作为业务数据主存储
 
-关系表层已经包含 V2.2/V2.3 能力：
+关系表层包含 V2.2-V2.4 能力：
 - V2.2：高增长业务表使用分区表，并提供版本详情、需求池、工作台和小宝预警的快读 API。
 - V2.3：AppData 保存成功后触发关系表同步，让快读路径保持新鲜；同步失败只记日志，不阻塞用户保存。
-
-尚未完成的是 V2.4 领域 CRUD 迁移：Project、Version、VersionPlan、DevTask、TestCase、Bug、Member、TaskCategory、TaskWorklog、Overtime 等主写入仍未完整切到领域 API。迁移前不要恢复业务 localStorage 缓存，避免线上部署后出现多端数据分叉。
+- V2.4：领域 CRUD 成为主写入路径，AppData 写桥保留给历史数据和回滚兜底。不要恢复业务 localStorage 缓存，避免线上部署后出现多端数据分叉。
 
 ## 生产部署层（2026-07-01）
 
@@ -286,8 +291,9 @@ The server also has lightweight observability for this phase: a global API timin
 
 Current source-of-truth boundary:
 
-- Product and Requirement have domain CRUD modules.
-- Project, Version, VersionPlan, DevTask, TestCase, Bug, Member, TaskCategory, TaskWorklog, Overtime, and WorkActivity relation models exist for V2.2/V2.3 mapping and fast reads, but their frontend write paths still mostly go through AppData stores.
-- `products-overview` remains the primary document for the product/project/version tree until Project and Version write APIs replace it.
-- V2.2 read APIs and V2.3 relation sync are compatibility infrastructure, not proof that every relation model already has a public CRUD API.
-- `packages/shared` still contains early Requirement/Task status enums. Before switching frontend writes to domain APIs, align shared enums with the current workflow statuses in this document.
+- Product, Project, Version, Requirement, VersionPlan, DevTask, TestCase, Bug, Member, TaskCategory, TaskWorklog, OvertimeRecord, and WorkActivity now have public domain CRUD/write APIs.
+- Frontend stores use domain APIs as the primary mutation path. AppData reads and saves remain only as compatibility fallback while old deployments or partially migrated data are drained.
+- `products-overview` is no longer the product/project/version tree source of truth; it remains a compatibility document for fallback reads and rollback.
+- V2.2 read APIs and V2.3 relation sync remain compatibility infrastructure for fast reads, historical AppData imports, and rollback. They are no longer the main proof of data freshness for domains that now write relation tables directly.
+- `packages/shared` status contracts have been aligned with the current workflow statuses before the V2.4 write switch.
+- Conservative V2.4.5 boundary: Member identity fields are stored on `users`; departments, roles, password rules, and overtime reasons remain AppData compatibility/config until a dedicated RBAC/config schema phase.