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。