02-开发计划

一、模块依赖表

模块 ID	模块名	依赖模块	依赖表
module_usr	用户管理	—	tUser, tEmployee, tPermission, tUserPermission, tCompany

二、开发顺序清单（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	所属模块无依赖，基础模块；本 REQ 创建用户主记录，是后续修改 / 查询 / 登录的前置	—
2	REQ-USR-002	module_usr	依赖 REQ-USR-001 已在前（修改基于已存在的用户记录）	—
3	REQ-USR-003	module_usr	依赖 REQ-USR-001 已在前（查询基于已存在的用户记录）	—
4	REQ-USR-004	module_usr	依赖 REQ-USR-001 已在前（登录校验已存在的用户名 + 密码）；同模块尾位以承接前 3 个的用户数据	—

后端模块全部 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）。

三、关键说明

• 模块粒度合 MR：本项目当前只有一个后端模块 module_usr，4 个 REQ 在同一分支（如 module-usr）里依次实现，最后合 1 个 MR。
• REQ 实现顺序：在同模块内允许 CC 根据实际依赖局部调整（如先做骨架接口再做业务规则），但完成后所有 4 个 REQ 的子项必须勾选并通过 feature-review，否则 test-gate 不放行。
• 种子数据：tEmployee / tPermission / tCompany 三张字典表在 REQ-USR-001 实现前需要少量种子（通过 Flyway R__seed.sql 或集成测试 @Sql 注入），便于 REQ-USR-001 的"员工名/版本/权限组"下拉测试。具体种子内容由 feature-tdd 落到测试 fixture，不进 V_n migration。
• 登录失败锁定：REQ-USR-004 的"连续失败阈值"与"锁定时长"由 application.yml 配置项 app.security.max-login-fail / app.security.lock-minutes 注入，默认 5 / 30。