# 02-开发计划

## 一、模块依赖表

| 模块 ID | 模块名 | 依赖模块 | 依赖表 |
|---|---|---|---|
| module_mod | 模块管理 | — | `tModule` |
| module_usr | 用户管理 | — | `tUser`、`tStaff`、`tPermissionCategory`、`tUserPermission` |

> 说明：MOD 与 USR 之间无 schema 级外键依赖；按 `module_id` 字母序铺开。USR 业务上的"权限分类"未来可能与 MOD 维护的模块树打通（多对多授权），届时如需新增 FK 再以 V_n migration 引入。

## 二、开发顺序清单（CC 分发权威）

> 本清单由 A5 `downstream-gen` 一次性生成。**每行是一个 REQ**，不是模块。CC 按表格行序从上到下扫描，对每个 REQ 所属模块查 `docs/08 § 二` 的 `MR:` 字段 + GitLab API `state`：`merged` 跳过，其他（`—` / opened / closed / 查不到）选为当前模块；`module-start` 会把该模块的所有 REQ 一次做完。
>
> **约束**：同一模块的所有 REQ 必须**连续排列**。允许打破依赖拓扑（如环依赖、业务必须先做），但必须在「备注」列写明原因。

| # | REQ | 所属模块 | 选中理由 | 备注 |
|---|-----|---------|---------|------|
| 1 | **REQ-MOD-001** | module_mod | 所属模块无依赖，基础模块；同模块第一个 REQ | — |
| 2 | **REQ-MOD-002** | module_mod | 同模块前序 REQ-MOD-001 已在前 | — |
| 3 | **REQ-MOD-003** | module_mod | 同模块前序 REQ-MOD-001/002 已在前 | — |
| 4 | **REQ-MOD-004** | module_mod | 同模块前序 REQ-MOD-001~003 已在前 | — |
| 5 | **REQ-USR-001** | module_usr | 所属模块无依赖；module_mod 已在前 | — |
| 6 | **REQ-USR-002** | module_usr | 同模块前序 REQ-USR-001 已在前 | — |
| 7 | **REQ-USR-003** | module_usr | 同模块前序 REQ-USR-001/002 已在前 | — |
| 8 | **REQ-USR-004** | module_usr | 同模块前序 REQ-USR-001 已在前；登录依赖已存在用户记录 | — |

## 三、关键说明

- **模块顺序**：MOD 与 USR 模块互无 schema 级依赖，按 `module_id` 字母序排（module_mod → module_usr）。任一模块均可作为第一个被开发的模块；本清单选 module_mod 在前以保持稳定的字母序，避免后续追加模块时出现行序漂移。
- **REQ 顺序**：每模块内部按 CRUD + 业务流程的自然依赖排（增 → 改 → 删 → 查；登录置最后，依赖已有用户记录）。无环依赖。
- **基础设施 REQ**：本期未单列基础设施 REQ（鉴权拦截器 / 全局异常处理器 / 统一响应封装等横切组件由 `module_usr` 的 REQ-USR-004 触发首次落地，并复用到其他模块）。
- **数据准备**：REQ-USR-001 实施前需在 `tStaff` / `tPermissionCategory` 中预置基础字典数据（业务运营提供，不在本计划中作为独立 REQ）。