02-开发计划.md 2.2 KB

02-开发计划

一、模块依赖表

模块 ID 模块名 依赖模块 依赖表
module_mod 模块管理 tModule
module_usr 用户管理 tUsertStafftPermissionCategorytUserPermission

二、开发顺序清单(CC 分发权威)

本清单由 A5 downstream-gen 一次性生成。每行是一个 REQ,不是模块。CC 按表格行序从上到下扫描,对每个 REQ 所属模块查 docs/08 § 二MR: 字段 + GitLab API statemerged 跳过,其他( / opened / closed / 查不到)选为当前模块;module-start 会把该模块的所有 REQ 一次做完。

约束:同一模块的所有 REQ 必须连续排列。允许打破依赖拓扑(如环依赖、业务必须先做),但必须在「备注」列写明原因。

# REQ 所属模块 选中理由 备注
1 REQ-MOD-001 module_mod 所属模块无依赖,基础模块;新增是 CRUD 起点
2 REQ-MOD-002 module_mod 同模块内依赖 REQ-MOD-001 的写入数据
3 REQ-MOD-003 module_mod 同模块内依赖 REQ-MOD-001 的写入数据
4 REQ-MOD-004 module_mod 同模块只读,放最后便于覆盖前 3 个 REQ 写入的数据
5 REQ-USR-001 module_usr 所属模块无依赖;用户新增是用户域 CRUD 起点
6 REQ-USR-002 module_usr 同模块内依赖 REQ-USR-001 的写入数据
7 REQ-USR-003 module_usr 同模块只读,放在写操作之后,便于覆盖测试数据
8 REQ-USR-004 module_usr 登录依赖 REQ-USR-001 创建的账号;放本模块末尾

三、关键说明

  • 模块顺序按字母序(MOD → USR),两模块无相互依赖,顺序可调。
  • USR 模块「涉及表」中的 tStaff / tPermissionCategory 仅作为下拉数据源被 REQ-USR-001/002 读取;本期未拆出独立 REQ,由 USR 模块内的种子数据脚本(B 阶段任意 REQ 的 spec 中确定)填充。
  • 软删除(bDeleted)字段已在 V1 schema 中预置,所有「删除 / 查询」类 REQ 默认按 bDeleted = 0 过滤。