# 02-开发计划

## 一、模块依赖表

| 模块 ID | 模块名 | 依赖模块 | 依赖表 |
|---|---|---|---|
| module_usr | 用户管理 | — | `sys_user`, `sys_employee`, `sys_department`, `sys_company`, `sys_permission_category`, `sys_user_permission_category` |

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

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

| # | REQ | 所属模块 | 选中理由 | 备注 |
|---|-----|---------|---------|------|
| 1 | **REQ-USR-001** | module_usr | 所属模块无依赖，登录是后续接口鉴权的基础 | — |
| 2 | **REQ-USR-002** | module_usr | 同模块，无前置 REQ 依赖；用户创建是 003/004 的数据源 | — |
| 3 | **REQ-USR-003** | module_usr | 同模块，逻辑上依赖 REQ-USR-002 已在前（修改基于已存在用户） | — |
| 4 | **REQ-USR-004** | module_usr | 同模块，无前置 REQ 依赖；列表查询用 002/003 产生的数据更易自测 | — |

> **后端模块全部 merged 后**：用户重跑 `/erp-workflow:coding-start` → coding-start 检测到 `backend_done=true && frontend_done=false` → 派发 `frontend-start`。`frontend-start` 步骤 1 自带 prototype/ 门禁（≥ 1 个 `*.html` mockup，缺失则 AskUserQuestion 提示用户补齐）。前端阶段以业务功能（不是 HTML 文件数）为粒度拆分 FE，每个 FE 跑一次 feature 循环（fe-feature-*），最后整个阶段合 1 个 MR（分支 `frontend-phase`，记录在 `docs/08 § 三 整体 MR`）。

## 三、关键说明

- 当前仅有 1 个业务模块 `module_usr`，无跨模块依赖，模块级 DAG 退化为单节点，无环。
- REQ 内部依赖只有 003 → 002 一条边，按数字序天然满足，无需破环。
- `sys_employee` / `sys_department` / `sys_company` / `sys_permission_category` 4 张参考字典已由 V1 建好但本模块**只读使用**，初始化数据由 B 阶段开发时通过 V2/V3 seed migration 或测试 fixture 补全（不在当前 4 个 REQ 范围内）。
- 后端阶段所有任务限定在 `backend/module/usr/` 路径下；前端实现推迟到 `frontend-start` 派发的前端阶段，按 `prototype/*.html` 拆 FE。