# 02-开发计划

## 一、模块依赖表

| 模块 ID | 模块名 | 依赖模块 | 依赖表 |
|---|---|---|---|
{{#each modules}}
| {{id}} | {{name}} | {{deps}} | {{tables}} |
{{/each}}

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

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

| # | REQ | 所属模块 | 选中理由 | 备注 |
|---|-----|---------|---------|------|
{{#each req_order}}
| {{index}} | **{{req_id}}** | {{module_id}} | {{rationale}} | {{note}} |
{{/each}}

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

## 三、关键说明
{{notes}}