feat: 引入前端整体阶段（FE skills + coding-start 阶段分发）

后端模块全部 merged 后进入前端整体阶段（1 个 MR）。 - 入口：coding-start 由模块循环器升级为阶段分发器，按 docs/08 §二/§三 + GitLab state 路由到 module-start 或 frontend-start - 前端 skill：新增 frontend-start + fe-feature-brainstorm/plan/tdd/verify/review 共 6 个 skill；fe-code-reviewer agent 做 7 维 review - 前端门禁：prototype/ 至少 1 个 *.html mockup；FE 清单由 AI 扫 prototype + docs/01 + docs/05 自主推导写入 docs/08 §三，无人工审阅断点 - 后端 skill 阶段化：feature-brainstorm/plan/tdd 加「阶段范围（后端）」标记；feature-tdd 增 frontend/ 路径硬护栏；module-start/test-gate/module-report/mr-create 接受 phase 参数（backend/frontend） - 模板同步：CLAUDE-template / docs-08-initial / docs-06-static / docs-02 / mr-description / coding-start banner 更新含前端段落 - README：21→27 skill / 1→2 agent / 35→44 模板；A5 章节 docs/06 §五改为 §三

feat: 引入前端整体阶段（FE skills + coding-start 阶段分发）
后端模块全部 merged 后进入前端整体阶段（1 个 MR）。 - 入口：coding-start 由模块循环器升级为阶段分发器，按 docs/08 §二/§三 + GitLab state 路由到 module-start 或 frontend-start - 前端 skill：新增 frontend-start + fe-feature-brainstorm/plan/tdd/verify/review 共 6 个 skill；fe-code-reviewer agent 做 7 维 review - 前端门禁：prototype/ 至少 1 个 *.html mockup；FE 清单由 AI 扫 prototype + docs/01 + docs/05 自主推导写入 docs/08 §三，无人工审阅断点 - 后端 skill 阶段化：feature-brainstorm/plan/tdd 加「阶段范围（后端）」标记；feature-tdd 增 frontend/ 路径硬护栏；module-start/test-gate/module-report/mr-create 接受 phase 参数（backend/frontend） - 模板同步：CLAUDE-template / docs-08-initial / docs-06-static / docs-02 / mr-description / coding-start banner 更新含前端段落 - README：21→27 skill / 1→2 agent / 35→44 模板；A5 章节 docs/06 §五改为 §三
zichun
1 parent af69f223
Showing 31 changed files with 1045 additions and 228 deletions
README.md
agents/fe-code-reviewer.md
skills/coding/fe-feature-brainstorm/SKILL.md
skills/coding/fe-feature-brainstorm/templates/fe-feature-spec-template.md
skills/coding/fe-feature-plan/SKILL.md
skills/coding/fe-feature-plan/templates/fe-feature-plan-template.md
skills/coding/fe-feature-review/SKILL.md
skills/coding/fe-feature-review/templates/commit-message-template.md
skills/coding/fe-feature-review/templates/fe-feature-review-template.md
skills/coding/fe-feature-tdd/SKILL.md
skills/coding/fe-feature-tdd/templates/commit-message-template.md
skills/coding/fe-feature-verify/SKILL.md
skills/coding/fe-feature-verify/templates/fe-feature-verify-evidence-template.md
skills/coding/feature-brainstorm/SKILL.md
skills/coding/feature-plan/SKILL.md
skills/coding/feature-tdd/SKILL.md
skills/coding/frontend-start/SKILL.md
skills/coding/frontend-start/templates/frontend-start-banner-template.md
skills/coding/module-report/SKILL.md
skills/coding/module-start/SKILL.md
@@ -2,7 +2,7 @@
 Claude Code 插件：ERP / 后端管理系统全流程开发框架。
-把"从零到 N 个模块上线"的整个流程固化成 **21 个 skill + 1 个 agent + 2 个 hook + 35 份模板**，让 CC 在 schema 演化用 Flyway migration、需求可追溯、人工审核可控的前提下推进编码。
+把"从零到 N 个模块上线 + 前端整体阶段"的整个流程固化成 **27 个 skill + 2 个 agent + 2 个 hook + 44 份模板**，让 CC 在 schema 演化用 Flyway migration、需求可追溯、人工审核可控的前提下推进编码。后端按模块循环依次提交 MR，所有后端 merged 后进入前端整体阶段（以项目根 `prototype/` 静态 HTML mockup 为页面权威）。
 ## 这个插件做什么
@@ -19,13 +19,23 @@ Claude Code 插件：ERP / 后端管理系统全流程开发框架。
                           ↓
    A4 初始化 DB（docs/03 → V1 migration → 自动 apply 到本地 MySQL）
                           ↓
-   A5 生成下游文档（docs/02 / docs/05 / docs/06 § 五 / docs/10）
+   A5 生成下游文档（docs/02 / docs/05 / docs/06 § 三 / docs/10）
                           ↓
                   用户显式 /erp-workflow:coding-start
-🔁 阶段 B：编码（按模块循环，入口 /erp-workflow:coding-start）
-   功能循环：Brainstorm → Plan → TDD → Verify → Review
-   模块循环：本地测试闸门 → 写模块报告 → 创建 GitLab MR → ⏸ 用户 Approve+Merge → 下次 coding-start 自动扫描 MR 状态为 merged → 下一模块
+🔁 阶段 B：编码（入口 /erp-workflow:coding-start）
+
+   B-后端（按模块循环）
+     功能循环：Brainstorm → Plan → TDD → Verify → Review
+     模块循环：本地测试闸门 → 写模块报告 → 创建 GitLab MR → ⏸ 用户 Approve+Merge → 下次 coding-start 自动扫描 MR 状态为 merged → 下一模块
+
+   ↓ 后端全部 merged 后
+
+   B-前端（整体阶段，1 个 MR）
+     入口门禁：检查项目根 prototype/ 至少含 1 个 *.html mockup（缺失则 AskUserQuestion 提示用户补齐）
+     FE 拆分：AI 自主推导功能清单（业务功能粒度，与 HTML 文件数无关）写入 docs/08 § 三；已有则加载——无人工审阅断点（人工只在 MR Approve+Merge 处介入）
+     FE 循环（每个 FE-NN）：fe-feature-brainstorm → -plan → -tdd → -verify → -review
+     收尾：test-gate(phase=frontend) → module-report(phase=frontend) → mr-create（分支 frontend-phase）→ ⏸ 用户 Approve+Merge → 全部完成
 ⚙️ 后台守门：占位符未填 / 中断触发 / 跨模块改动未记录
 ```
@@ -52,22 +62,33 @@ Claude Code 插件：ERP / 后端管理系统全流程开发框架。
    > 两个审阅断点的处理方式一致：A1 / A3 完成时 skill 已自动勾选 `docs/08-模块任务管理.md § 一` 该阶段的全部子项 + 顶层；审阅是隐式的——你看完 REQ 卡片 / docs/03 后直接重新运行 `/plan-start`，下次入口就会派发到下一阶段。如果审阅时发现需要修订，直接编辑 docs/01 / docs/03 即可，不依赖 docs/08 的勾选状态。
-3. **Coding 阶段入口**（模块循环）：
+3. **Coding 阶段入口**（后端模块循环 → 前端整体阶段）：
    ```
    /erp-workflow:coding-start
    ```
-   Plan 全部完成后由你显式触发。**按 `docs/02 § 二` REQ 开发顺序清单**扫描，决定当前模块：
-   对每个 REQ 所属模块查询 `docs/08` 的 `MR:` 字段，必要时调 GitLab API 取 `state`：
-   - `MR: —` → 该模块是当前模块（未建过 MR）
-   - `MR: !<iid>` 且 API `state == merged` → 模块已完成，跳过
-   - `MR: !<iid>` 且 API `state ∈ {opened, closed}` → 该模块是当前模块
-   - `MR: !<iid>` 但 API HTTP 非 200 / 查不到 / state 非法 → **停下报错**让用户排查 token / API URL / project ID / iid（绝不静默假设未 merged）
+   Plan 全部完成后由你显式触发。`coding-start` 是阶段分发权威——每次入口都重新扫描 docs/08 § 二/§ 三 + GitLab API state，按当前进度决定派发：
+
+   **路由规则（coding-start 真值表，只做分发）**：
+
+   | `backend_done` | `frontend_done` | coding-start 派发 |
+   |---|---|---|
+   | `false` | 任意 | `module-start`（写后端） |
+   | `true` | `false` | `frontend-start`（写前端） |
+   | `true` | `true` | 打印"所有阶段已完成"，停下 |
-   之后**自动探测远程默认分支** → `git checkout <默认分支>` + `git pull --ff-only` 同步远程 → 派发到 `module-start`。
+   GitLab API HTTP 非 200 / 查不到 / state 非法 → 停下报错（绝不静默假设未 merged）。
-   **`docs/08 § 二` 每模块占一行 bullet**，完成信号由 MR merged state 判定；即使用户提前触发 coding-start，未 merged 的模块仍会被选中，不会跳过。
+   **后端阶段（module-start 内，单一职责）**：
+   - 切到 `module-<id>` 分支，跑功能循环（feature-brainstorm → ... → feature-review）→ 全 approve → test-gate → module-report → mr-create → ⏸ 人工 Approve+Merge → 用户重跑 coding-start，coding-start 再次路由
-4. **中途恢复**：任何时候运行对应入口命令——根据 Plan § 一 checkbox 和 § 二 各模块 MR state 跳到当前该做的事。
+   **前端阶段（frontend-start 内，自带前置门禁）**：
+   - 步骤 1：prototype/ 门禁（≥ 1 个 *.html，缺失则 AskUserQuestion 提示用户补齐 → 停下）
+   - 步骤 2：准备 FE 清单（无审阅断点）。§ 三 占位则 AI 扫 prototype + docs/01 + docs/05 自主推导 FE 业务功能清单写入 § 三（每个 FE 标注关联 REQ + 关联原型；FE 数与 HTML 文件数无关）；§ 三 已有则直接加载
+   - 步骤 4-8：MR state 判定 → 切 `frontend-phase` 分支 → 跑 fe-feature 循环（fe-feature-brainstorm → ... → fe-feature-review，专用 `fe-code-reviewer` agent 做 7 维 review）→ 全 approve → test-gate(frontend) → module-report(frontend) → mr-create（docs/08 § 三 整体 MR）→ ⏸ 人工 Approve+Merge
+
+   `docs/08 § 二` 每后端模块占一行 bullet，`§ 三` 是前端阶段整体段，完成信号统一由 MR merged state 判定。
+
+4. **中途恢复**：任何时候运行对应入口命令——根据 Plan § 一 checkbox、§ 二 各后端模块 MR state、§ 三 前端整体 MR state 跳到当前该做的事。
 ## 目录结构
@@ -80,10 +101,11 @@ erp-workflow-plugin/
 │   ├── hooks.json                   # hook 注册表（2 个 hook）
 │   └── scripts/*.sh                 # 2 个 hook 脚本
 ├── agents/
-│   └── superpower-code-reviewer.md  # code-reviewer agent（feature-review 调用）
+│   ├── superpower-code-reviewer.md  # 后端 code-reviewer agent（feature-review 调用）
+│   └── fe-code-reviewer.md          # 前端专用 reviewer（fe-feature-review 调用，硬编码 7 维 review）
 └── skills/
     ├── plan/                        # 阶段 A：6 个一次性规划 skill
-    ├── coding/                      # 阶段 B：9 个模块/功能循环 skill
+    ├── coding/                      # 阶段 B：15 个 skill = 9 个后端模块/功能循环 + frontend-start + 5 个 fe-feature-*
     ├── crosscut/                    # 横切：2 个入口 + 1 中断守门 + 1 留痕 skill
     └── internal/                    # superpowers 本地 fork：2 个无门 brainstorming / writing-plans
 ```
@@ -95,7 +117,7 @@ erp-workflow-plugin/
 | 拒绝 no-verify | `deny-no-verify.sh` | PreToolUse / Bash | CC 尝试 `git push --no-verify` | 硬拦截，强制 `.githooks/pre-push` 生效 |
 | 跨模块改动留痕 | `log-cross-module.sh` | PostToolUse / Edit \| Write | 当前处于 `module-*` 分支 且 编辑目标路径落在 `docs/08 § 二` 中**非当前模块**的 path 范围内（无论目标模块 MR 是否已 merged） | 把改动追加为 `TBD(CC 补)` 存根到 `<current_module>-cross-module.md`；通过 `additionalContext` 软提示 CC 调 `cross-module-log` skill **自主推断**补「原因 / 影响评估」两列。即时性由 CC 自己决定；**最迟在 `module-report` § ⑦ 硬闸门处**（TBD 未清空会阻断模块完成报告），保证模块完成前所有 TBD 必被 CC 填实 |
-## Skill 清单（21 个）
+## Skill 清单（27 个）
 ### Plan 阶段（6 个，`skills/plan/`）
@@ -106,59 +128,102 @@ erp-workflow-plugin/
 | A2 | `skeleton-gen` | • 生成架构文档：docs/04 § 一+ / docs/06 / docs/07 / docs/09<br>• 生成工具脚本：scripts/*.sh、.githooks/pre-push、.env.local<br>• 创建 `sql/migrations/` 空目录（Flyway 准备）<br>• 合并 .gitignore（逐行判重） | `plan-start` |
 | A3 | `db-design-gen` | • 从 docs/01 REQ 卡片正向设计 `docs/03-数据库设计文档.md`（schema SSoT）<br>• 回填 REQ 卡片依赖表（`TBD(A3 自动补)` → 实际表名）<br>• **停下**等人工审阅 docs/03，审阅完毕用 `/plan-start` 恢复续进 A4 | A2 |
 | A4 | `db-init` | • LLM 解析 docs/03 → `sql/migrations/V1__initial_schema.sql`（DDL only）<br>• **5 维度全量校验** DDL ↔ docs/03（表名 / 列名+列序 / 类型+nullable+默认值 / 索引名 / FK 名），fail-closed<br>• 验证 MySQL 连接<br>• 调 `scripts/setup-test-db.sh` 复用三层防护（与 B 阶段 test.sh 共用）→ DROP+CREATE 空库<br>• apply V1 + `SHOW TABLES` 行数自检 | A3 |
-| A5 | `downstream-gen` | • 一次性生成 docs/02 / docs/05 / docs/06 § 五 / docs/10<br>• 回填 REQ 卡片依赖接口（`TBD(A5 自动补)` → 实际 endpoint）<br>• 追加模块清单到 docs/08 § 二<br>• 最终占位符扫描（TBD 自动补 + `【人工填写：】` QA 循环）<br>• 打印 Plan 完成横幅并**停下**（不自动进 B） | A4 |
+| A5 | `downstream-gen` | • 一次性生成 docs/02 / docs/05 / docs/06 § 三 / docs/10<br>• 回填 REQ 卡片依赖接口（`TBD(A5 自动补)` → 实际 endpoint）<br>• 追加模块清单到 docs/08 § 二<br>• 最终占位符扫描（TBD 自动补 + `【人工填写：】` QA 循环）<br>• 打印 Plan 完成横幅并**停下**（不自动进 B） | A4 |
-### Coding 阶段（9 个，`skills/coding/`）
+### Coding 阶段（15 个，`skills/coding/`）
 **触发与顺序**（`coding-start` 是唯一由用户手动触发的入口，下面所有 skill 都由 skill 链自动调用）：
 ```
-/erp-workflow:coding-start          ← 用户每次手动触发
+/erp-workflow:coding-start          ← 用户每次手动触发；阶段分发器（只做分发）
+        │
+        │  ① Plan 完成校验（docs/08 § 一 A0~A5）
+        │  ② 后端完成性检查（§ 二 + GitLab state）
+        │     ├ 未完成 → 立即派发 module-start，结束
+        │     └ 已完成 → 继续 ③
+        │  ③ 前端完成性检查（§ 三 整体 MR + state）
+        │     ├ 已完成 → 打印"所有阶段已完成"，结束
+        │     └ 未完成 → 派发 frontend-start，结束
+        │
+        ├─ 后端未完成                       → 派发 module-start（写后端）
+        │       │
+        │       │ 切 module-<id> 分支，对每个未完成 REQ：
+        │       │   feature-brainstorm → -plan → -tdd → -verify → -review
+        │       │
+        │       │ review approve → 回 module-start（下一 REQ）
+        │       │ request-changes (<5) → fix → 回 feature-verify
+        │       │ request-changes (=5) → 停下（升级给人）
+        │       │
+        │       │ 本模块所有 REQ approve：
+        │       │   test-gate(phase=backend) → module-report → mr-create
+        │       │   （docs/08 § 二 写 MR iid）
+        │       │
+        │       └─ ⏸ 停下等人工 Approve + Merge
+        │          （合并后用户重跑 coding-start → coding-start 再次路由）
         │
-        │  扫描 docs/02 REQ 序 + docs/08 MR 字段 + GitLab API state 判定当前模块：
-        │  - 所有模块都 merged → 打印"所有模块已完成"
-        │  - 找到第一个非 merged 模块 → 派发
-        │  派发前自动探测远程默认分支（main / master），git checkout + git pull --ff-only 同步远程 base
+        ├─ 后端完成 & 前端完成              → 打印"所有阶段已完成"，停下
         │
-        └─→ module-start（幂等可重入，切 module-<id> 分支）
-                  │
-                  │ 对每个未完成 REQ，按序串链：
-                  │ feature-brainstorm → -plan → -tdd → -verify → -review
-                  │
-                  │ review approve              → 回 module-start（推进下一 REQ）
-                  │ review request-changes (<5) → fix commit → 回 feature-verify 重新执行
-                  │ review request-changes (=5) → 停下（升级给人）
-                  │
-                  │ 模块全部 REQ approve →
-                  │   test-gate（commit test-gate.md）
-                  │   → module-report（commit 模块报告 + cross-module log）
-                  │   → mr-create（worktree clean 校验 → push 代码+evidence → 创建 MR
-                  │       → 追 MR URL 到报告 + commit → 写 MR iid 到 docs/08 + commit
-                  │       → 再 push）
-                  │
-                  └─ ⏸ 停下等人工 Approve + Merge
-                     （人工合并后再次运行 coding-start，扫描到 state=merged 自动跳过
-                      → pull 默认分支 → 推进下一模块）
+        └─ 后端完成 & 前端未完成            → 派发 frontend-start（写前端）
+              │
+              │ frontend-start 自带前置门禁（coding-start 不做）：
+              │   ① prototype/ 门禁（≥ 1 个 *.html，缺失则 AskUserQuestion）
+              │   ② 准备 FE 清单（无审阅断点）：
+              │      § 三 已有 FE bullet → 加载
+              │      § 三 仅占位 → AI 推导写入
+              │   ③ 切 frontend-phase 分支
+              │
+                          │
+                          │ 准备 FE 清单（无审阅断点）：
+                          │   § 三 占位 → 扫 prototype + docs/01 + docs/05
+                          │     → AI 自主推导 FE 业务功能清单写入 § 三
+                          │     （含 fe_id / 功能名 / 关联 REQ / 关联原型）
+                          │   § 三 已有 FE bullet → 直接加载
+                          │
+                          │ 切 frontend-phase 分支
+                          │ FE 是业务功能粒度（与 HTML 文件数无关，
+                          │ 一个 HTML 可拆多个 FE / 多 HTML 可合一个 FE）
+                          │
+                          │ 对每个未完成 FE：
+                          │   fe-feature-brainstorm → -plan → -tdd → -verify → -review
+                          │   （review 委托 fe-code-reviewer agent，硬编码 7 维 checklist）
+                          │
+                          │ review approve → 回 frontend-start（下一 FE）
+                          │ request-changes (<5) → fix → 回 fe-feature-verify
+                          │ request-changes (=5) → 停下
+                          │
+                          │ 全部 FE approve：
+                          │   test-gate(phase=frontend)（vitest + playwright，子会话跑）
+                          │   → module-report(phase=frontend)
+                          │   → mr-create（docs/08 § 三 整体 MR）
+                          │
+                          └─ ⏸ 停下等人工 Approve + Merge
+                             （合并后再跑 coding-start → "所有阶段已完成"）
 ```
 | Skill | 做什么 | 谁触发它 |
 |---|---|---|
-| `module-start` | 定位当前模块（docs/02 REQ 序）+ 切换或创建 `module-<id>` 分支 + 扫描 `docs/superpowers/reviews/*.md` 的 `verdict=approve` 计算已完成 REQ + 推进第一个未完成 REQ 的功能循环。全部完成 → `test-gate`。**幂等可重入**（中途断开后重新运行会自动跳过已 approve 的 REQ） | `coding-start` 派发；`feature-review` approve 后回调 |
+| `module-start` | **后端模块循环单一职责**（不感知前端阶段）。切 `module-<id>` 分支，扫 `docs/superpowers/reviews/*.md` 的 `verdict=approve` 计算已完成 REQ，推进第一个未完成 REQ；本模块全 approve → `test-gate`。**幂等可重入** | `coding-start` 派发（仅当后端有未 merged 模块时）；`feature-review` approve 后回调 |
 | `feature-brainstorm` | 功能循环步骤 1：交互 brainstorm → 生成 `docs/superpowers/specs/*.md` | `module-start` 推进 REQ 时调用 |
 | `feature-plan` | 功能循环步骤 2：spec → 任务级 plan（文件路径 + API 签名 + 测试意图 + 完成判据，代码由 TDD 阶段产出），输出 `docs/superpowers/plans/*.md` | `feature-brainstorm` 链式调用 |
-| `feature-tdd` | 功能循环步骤 3：红绿循环（写失败测试 → 实现 → 子会话验证通过 → commit 到 `module-<id>` 分支） | `feature-plan` 链式调用 |
+| `feature-tdd` | 功能循环步骤 3：红绿循环（写失败测试 → 实现 → 子会话验证通过 → commit 到 `module-<id>` 分支）；路径硬护栏：`impl_file` 落 `frontend/` 前缀 → 硬停（UI 推迟到前端阶段） | `feature-plan` 链式调用 |
 | `feature-verify` | 功能循环步骤 4：将全量测试派发到子会话执行一次，用模板渲染 evidence | `feature-tdd` 链式调用；`feature-review` 在 request-changes 修复后重新调用 |
 | `feature-review` | 功能循环步骤 5：AI 自审，写 `docs/superpowers/reviews/*.md`。approve → 回 `module-start`；request-changes → 逐项 Edit + fix commit → 回 `feature-verify` 重新执行（最多 5 轮，第 5 轮仍 request-changes 则停下） | `feature-verify` 链式调用 |
-| `test-gate` | MR 前硬闸门：子会话执行 `scripts/test.sh`（脚本内部 drop+create 空库、Flyway apply `sql/migrations/V*.sql`、再执行测试）；通过 → 写 `<module_id>-test-gate.md` 并 `git add + commit`（evidence 提交到 module 分支）；失败停下 | `module-start` 在本模块所有 REQ approve 后调用 |
-| `module-report` | 中断检查 → 生成 12 节模块完成报告 `docs/superpowers/module-reports/<date>-<module_id>.md` → `git add + commit`（报告 + cross-module log 提交到 module 分支，mr-create 的 worktree clean 前置条件依赖此步） | `test-gate` 链式调用 |
-| `mr-create` | 中断检查 → 验证当前分支 = `module-<id>` 且 `git status --porcelain` worktree 干净 → `git push` 推代码与全部 evidence → 用 curl 调 GitLab REST API 创建 MR（模块报告嵌入 MR 描述）→ 追加 MR URL 到报告并 commit → 把 docs/08 该模块的 `MR: —` 回写为 `MR: !<iid>` 并 commit → 再次 push；**停下等人工 Approve+Merge**。完成由 MR state 判定 | `module-report` 链式调用 |
+| `test-gate` | MR 前硬闸门。按当前分支推 phase：`module-*` → 跑 `scripts/test.sh`（drop+create 空库、Flyway apply、测试）；`frontend-phase` → 跑 vitest + playwright（命令取自 docs/04 § 零）。通过 → 写 `<phase_id>-test-gate.md` 并 commit 到当前分支；失败停下 | `module-start`（后端 REQ 全 approve 后）/ `frontend-start`（FE 全 approve 后） |
+| `module-report` | 中断检查 → 生成 12 节完成报告 `docs/superpowers/module-reports/<date>-<phase_id>.md`（前端阶段 § ④/§ ⑥ 写 N/A）→ commit 到当前分支（后端：module-* 分支；前端：frontend-phase 分支） | `test-gate` 链式调用 |
+| `mr-create` | 中断检查 → 验证当前分支 = `module-<id>` 或 `frontend-phase` 且 `git status --porcelain` worktree 干净 → `git push` 推代码与全部 evidence → 用 curl 调 GitLab REST API 创建 MR（完成报告嵌入 MR 描述）→ 追加 MR URL 到报告并 commit → 把 docs/08 § 二 该模块的 `MR: —`（后端） / § 三 `整体 MR: —`（前端） 回写为 `!<iid>` 并 commit → 再次 push；**停下等人工 Approve+Merge**。完成由 MR state 判定 | `module-report` 链式调用 |
+| `frontend-start` | 写前端阶段单一职责。步骤 1 自带 prototype/ 门禁（≥ 1 个 *.html，缺失则 AskUserQuestion）。步骤 2 准备 FE 清单（无审阅断点）：§ 三 占位则 AI 自主推导写入；§ 三 已有则加载。后续切 `frontend-phase` 分支 + 计算未完成 FE + 推进第一个 FE 的 fe-feature 循环；全 approve → `test-gate(phase=frontend)` | `coding-start` 派发（仅当 `backend_done=true && frontend_done=false`）；`fe-feature-review` approve 后回调 |
+| `fe-feature-brainstorm` | 前端功能循环步骤 1：基于 FE 关联的 `associated_prototypes[]` + `associated_reqs[]` + docs/05 + docs/06 § 二 + docs/04 § 零前端 → spec | `frontend-start` 推进 FE 时调用，传 `{ fe_id, name, associated_reqs[], associated_prototypes[] }` |
+| `fe-feature-plan` | 前端功能循环步骤 2：spec → 任务级计划（组件/路由/hook/API client，`impl_file` 必须 `frontend/` 前缀） | `fe-feature-brainstorm` 链式调用 |
+| `fe-feature-tdd` | 前端功能循环步骤 3：jsdom 组件测试 + Playwright E2E（E2E 派子会话）；commit trailer `REQ_ID: FE-NN`；路径硬护栏 `frontend/` | `fe-feature-plan` 链式调用 |
+| `fe-feature-verify` | 前端功能循环步骤 4：派子会话跑 vitest + playwright，按模板渲染证据 | `fe-feature-tdd` 链式调用；`fe-feature-review` request-changes 修复后重调 |
+| `fe-feature-review` | 前端功能循环步骤 5：委托 `fe-code-reviewer` agent 做 7 维 review。approve → 回 `frontend-start`；request-changes 5 轮上限 | `fe-feature-verify` 链式调用 |
 ### Crosscut（4 个，`skills/crosscut/`）
 | Skill | 作用 | 流程中谁调用 |
 |---|---|---|
 | `plan-start` | **A 阶段入口**。读取 docs/08 § 一 找第一个未勾 A 子项 → 派发对应 A skill；A 全部完成时提示运行 coding-start | **用户手动**运行 `/erp-workflow:plan-start` |
-| `coding-start` | **B 阶段入口**。先验证 Plan 已完成；**按 `docs/02 § 二` REQ 序扫描**，对每个 REQ 所属模块查询 `MR:` 字段 + GitLab API `state`：`merged` 跳过；`—`/opened/closed 选为当前模块；查不到则停下报错。派发前自动探测远程默认分支（main / master），`git checkout + git pull --ff-only` 同步远程 base，然后调用 `module-start` | **用户手动**运行 `/erp-workflow:coding-start` |
+| `coding-start` | **B 阶段入口 + 阶段分发器（只做分发）**。① 验证 Plan 已完成（docs/08 § 一 A0~A5 全勾选）② 后端完成性检查（§ 二 + GitLab state）③ 前端完成性检查（§ 三 整体 MR）④ 真值表派发：`backend=false` → `module-start`；`backend=true & frontend=false` → `frontend-start`；都 done → "全部完成"。前端阶段的 prototype/ 门禁由 `frontend-start` 自带，不在此处 | **用户手动**运行 `/erp-workflow:coding-start` |
 | `interrupt-check` | 检查 CLAUDE.md 的 3 项中断清单；触发则追加 Blocker 到计划文件并停下 | 功能循环各步骤和生成重要制品前自动调用 |
 | `cross-module-log` | 给 `log-cross-module.sh` 追加的跨模块改动存根批量补「原因 / 影响评估」 | `module-report` § ⑦ 硬验收时一次性调用（CC 编辑中途不主动调）；`module-start` 初始化日志文件时也会用其模板 |
@@ -171,11 +236,12 @@ erp-workflow-plugin/
 | `superpower-brainstorming` | `superpowers:brainstorming` 5.0.7 | `<HARD-GATE>` 整块、Anti-Pattern 段、Checklist 里 Visual Companion / approve-design / review-spec 三项、User Review Gate、Visual Companion 整节、终点 `invoke writing-plans` |
 | `superpower-writing-plans` | `superpowers:writing-plans` 5.0.7 | Execution Handoff 整节（"Which approach?" 问询）、"Complete code in every step" 硬要求（改为"API 签名 + 测试意图"粒度，完整代码留给 TDD） |
-## Agent 清单（1 个）
+## Agent 清单（2 个）
 | Agent | 源 | 用途 | 谁调用 |
 |---|---|---|---|
-| `superpower-code-reviewer` | `superpowers:code-reviewer` 5.0.7 agent，仅改 name | 对 REQ diff 做 AI 自审，产出 `must_fix[]` / `nice_to_have[]` / `gaps` | `feature-review` 步骤 1：`Agent(subagent_type=superpower-code-reviewer)` |
+| `superpower-code-reviewer` | `superpowers:code-reviewer` 5.0.7 agent，仅改 name | 对后端 REQ diff 做 AI 自审，产出 `must_fix[]` / `nice_to_have[]` / `gaps` | `feature-review` 步骤 1：`Agent(subagent_type=superpower-code-reviewer)` |
+| `fe-code-reviewer` | 自写（前端专用） | 对前端 FE-NN diff 做 7 维 AI 自审：prototype 一致性 / Design Tokens / 无障碍 / 响应式 / 业务校验前端复刻 / API 一致性 / 状态机覆盖。明确禁止给后端建议 | `fe-feature-review` 步骤 1：`Agent(subagent_type=fe-code-reviewer)` |
 ## Banners 清单（7 份，`bash cat` 直接输出，绕开 LLM 复读）
@@ -193,7 +259,7 @@ step 0 流程图被抽到独立 `.txt` 文件,SKILL.md 步骤 0 改为 `bash cat
 **字节对齐保证**:每个文件 17 行,每行 visible width = 58 cell(内宽 56 + 2 个 `│` 边框)。改动需重新校准。
-## Templates 清单（37 份）
+## Templates 清单（44 份）
 | 所属 Skill | 模板文件 | 用途 |
 |---|---|---|
@@ -204,7 +270,7 @@ step 0 流程图被抽到独立 `.txt` 文件,SKILL.md 步骤 0 改为 `bash cat
 | scope-lock | `req-card-template.md` | 单张 REQ-XXX-NNN 卡片骨架（6 个 `{{...}}` 占位符由 CC 替换；输入 / 输出 各含一句简述 + N 张示例字段表，模板原样复制由人工编辑） |
 | scope-lock | `_module-template.md` | 模块子目录的 `_module.md` 模块头（4 行：模块代码-名 / 简述 / 依赖模块 TBD / 涉及表 TBD） |
 | skeleton-gen | `docs-04-skeleton-template.md` | docs/04 § 一+ 编码规范大纲（HTML 注释引导 LLM） |
-| skeleton-gen | `docs-06-static-template.md` | docs/06 § 一~四 UI 模式大纲 |
+| skeleton-gen | `docs-06-static-template.md` | docs/06 § 一~二 大纲（通用交互 + Design Tokens；布局以 prototype/ 为权威） |
 | skeleton-gen | `docs-07-env-template.md` | docs/07 环境配置大纲 |
 | skeleton-gen | `docs-09-structure-template.md` | docs/09 目录结构大纲 |
 | skeleton-gen | `scripts-setup-test-db-template.sh` | 运行时 drop + create 空库脚本（0 槽位）；schema apply 交给 Flyway |
@@ -217,7 +283,7 @@ step 0 流程图被抽到独立 `.txt` 文件,SKILL.md 步骤 0 改为 `bash cat
 | downstream-gen | `docs-02-template.md` | docs/02 开发计划 |
 | downstream-gen | `docs-05-header-template.md` | docs/05 API 契约头部 |
 | downstream-gen | `docs-05-endpoint-template.md` | docs/05 单接口小节 |
-| downstream-gen | `docs-06-module-pagelist-template.md` | docs/06 § 五 单模块页面清单 |
+| downstream-gen | `docs-06-module-pagelist-template.md` | docs/06 § 三 单模块页面清单 |
 | downstream-gen | `docs-08-module-row-template.md` | docs/08 § 二 单模块 bullet 行 |
 | downstream-gen | `docs-10-header-template.md` | docs/10 验收清单（项目级 SOP，零槽位 + 引用指针） |
 | module-start | `module-start-banner-template.md` | 模块启动横幅 |
@@ -233,6 +299,13 @@ step 0 流程图被抽到独立 `.txt` 文件,SKILL.md 步骤 0 改为 `bash cat
 | interrupt-check | `interrupt-block-template.md` | Blocker 节追加模板 |
 | cross-module-log | `cross-module-log-template.md` | cross-module 日志头（由 hook log-cross-module.sh 在首次跨模块改动时渲染创建；skill 自身不再读取） |
 | cross-module-log | `cross-module-log-row-template.md` | 单条改动行模板 |
+| frontend-start | `frontend-start-banner-template.md` | 前端阶段启动横幅 |
+| fe-feature-brainstorm | `fe-feature-spec-template.md` | 前端功能规格结构（组件树 / 状态机 / API / 业务校验复刻 / token 引用） |
+| fe-feature-plan | `fe-feature-plan-template.md` | 前端功能计划结构（组件 / 路由 / hook / API client，`impl_file` 必须 `frontend/`） |
+| fe-feature-tdd | `commit-message-template.md` | 前端 TDD commit 信息（与后端共用格式，但 `req_id` = FE-NN） |
+| fe-feature-verify | `fe-feature-verify-evidence-template.md` | 前端验证证据（vitest + playwright 双段） |
+| fe-feature-review | `fe-feature-review-template.md` | 前端自审报告结构（含 7 维核查表） |
+| fe-feature-review | `commit-message-template.md` | 前端 review fix commit 信息 |
 **流程使用情况**：所有模板都被对应 skill 的 `SKILL.md` 引用，没有孤儿模板。
+---
+name: fe-code-reviewer
+description: |
+  Use this agent when fe-feature-review delegates a frontend code review for a single FE-NN business feature (which may span multiple prototype HTML files / regions). Specializes in React/Vue components, styling, accessibility, prototype fidelity, and Design Tokens. Does NOT review SQL/migration/controller/service — those are the backend reviewer's domain.
+model: inherit
+---
+
+You are a Senior Frontend Code Reviewer with deep expertise in component architecture, accessibility, design systems, and visual fidelity to design mockups. Your role is to review frontend code changes for a single FE-NN business feature (which may span multiple prototype HTML files or regions) against its associated prototypes, specification, and the project's design tokens.
+
+**Strict scope rules**:
+
+- Review ONLY frontend code (under `frontend/` or the project's frontend root per `docs/09-项目目录结构.md`).
+- Do NOT propose SQL, migration, controller, service, repository, transaction, or DTO suggestions. If the diff contains backend files, flag this as a path violation and return `request-changes` with a single must-fix entry pointing the reviewee back to `feature-tdd` (backend phase).
+- Do NOT recommend backend architectural changes; the backend phase is already merged.
+
+When reviewing, you will evaluate the following 7 dimensions in order. For each dimension, classify findings as Critical (must fix) / Important (should fix) / Suggestions (nice to have).
+
+## 1. Prototype 一致性
+
+- Compare the rendered DOM structure (inferred from JSX/template) against the FE's `associated_prototypes` (listed in the spec header). One FE may span multiple prototype files or specific regions (anchored like `prototype/dashboard.html#metrics-section`).
+- For each associated prototype / region, check: top navigation placement, grid columns, primary action button position, key region layout (header / filters / table / pagination).
+- Allowed: implementation differences (class naming, component library syntax, framework idioms).
+- Not allowed: structural deviation (e.g., moving the primary action from top-right to bottom-center, dropping a filter region the prototype shows).
+
+## 2. Design Tokens
+
+- All color values MUST use `var(--color-*)` per `docs/06 § 二`.
+- Hard-coded hex / rgb values → `request-changes` with file:line.
+- New tokens introduced in code without registration in `docs/06 § 二` and `tokens.css` → `request-changes`.
+
+## 3. 无障碍 (Accessibility)
+
+- Form controls have `<label>` or `aria-label`.
+- Interactive elements are keyboard reachable (correct tab order, Enter/Space triggers).
+- Dangerous operations (delete / irreversible) have a confirmation dialog.
+- Sufficient color contrast for text (best-effort; flag obvious failures).
+
+## 4. 响应式 (Responsive)
+
+- At the minimum resolution declared in `docs/06 § 一通用交互规则`, no horizontal scrollbar.
+- Critical operations do not depend on hover-only interactions (must work on touch).
+
+## 5. 业务校验前端复刻
+
+- Cross-reference the spec's "业务规则前端复刻" section.
+- Each business rule listed in the spec must be implemented as form-level validation (not only relying on backend errors).
+- Error messages must match backend semantics or convey equivalent meaning.
+
+## 6. API 调用一致性
+
+- Endpoints and request/response field names must match `docs/05-API接口契约.md`.
+- API calls must go through the project's unified API client; raw `fetch` / `axios` with hand-built URLs → `request-changes`.
+
+## 7. 状态机覆盖
+
+- The 5 states from the spec (loading / empty / error / 正常 / 提交中) must each be handled in code.
+- Missing state handling → `request-changes` for the specific state.
+
+## Output format
+
+Return a structured review with:
+
+- `verdict`: `approve` or `request-changes`
+- `must_fix[]`: each item with `severity` (critical/important), `file`, `line`, `issue`, `suggestion`
+- `nice_to_have[]`: lighter suggestions
+- `dimensions{}`: per-dimension status (`pass` / `fail`) and brief notes for the 7 dimensions
+- `gaps`: test coverage or scope gaps
+
+Be thorough but actionable. Always explain WHY a finding matters (e.g., "hard-coded hex breaks the token rotation in dark mode"). When you approve, briefly acknowledge what was done well before closing.
+---
+name: fe-feature-brainstorm
+description: 前端功能循环第 1 步。针对单个 FE-NN 页面（prototype/*.html）做交互式头脑风暴，产出前端功能规格到 docs/superpowers/specs/。
+user-invocable: false
+allowed-tools: Read Write Skill Glob Grep
+---
+
+**所有输出必须使用中文。**
+
+# fe-feature-brainstorm
+
+## 阶段范围（前端）
+
+本 skill 服务于**前端阶段**。产出范围限定为：组件树 / 页面状态机 / 交互流程 / API 调用 / Design Tokens 引用 / 业务校验前端复刻。**不涉及** SQL / migration / controller / service / DTO（这些已在后端阶段完成）。
+
+一个 FE 是**业务功能**粒度，可能关联多个 prototype 文件区域和多个 REQ。
+
+## 执行步骤
+
+1. 确定本次 FE 上下文（由 `frontend-start` 派发时传入 `{ fe_id, name, associated_reqs[], associated_prototypes[] }`），收集证据：
+   - **页面骨架**：Read 所有 `associated_prototypes[]`（如 `prototype/dashboard.html` + `prototype/dashboard.html#metrics-section`；含 anchor 时聚焦相应区域），作为本 FE 涉及页面的布局权威
+   - **业务规则**：Read 所有 `associated_reqs[]` 对应的 `docs/01-需求清单/<module>/<REQ-id>.md`，提取业务校验规则、acceptance、UI 描述
+   - **API 契约**：Read `docs/05-API接口契约.md`，按 `associated_reqs[]` 过滤出本 FE 消费的端点
+   - **Design Tokens**：Read `docs/06-UI交互规范.md § 二`，作为色值/状态色的引用源
+   - **前端组件库**：Read `docs/04-技术规范.md § 零` 找 `frontend.ui_lib`（如 Ant Design / Element Plus），决定组件选型
+
+2. 委托 `superpowers:brainstorming`，把上述上下文 + 落盘路径 `docs/superpowers/specs/<YYYY-MM-DD>-<fe_id>.md` 作为 caller-provided path 传入。caller-provided 上下文显式标注：
+
+   > 本次为前端阶段头脑风暴。关注组件树、页面状态机、交互流程、API 调用一致性、Design Tokens 引用、业务校验前端复刻。**不要**讨论 SQL / migration / controller / service / DTO。本 FE 关联的 REQ 与原型清单见上下文中 `associated_reqs` / `associated_prototypes`。
+
+   文件已存在 → 征求用户确认后覆盖。
+
+3. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-spec-template.md` 渲染头脑风暴输出，写入推导路径。规格至少含：
+   - 关联 REQ + 关联原型（来自 frontend-start 派发的入参）
+   - 组件树（多个 prototype 文件 / 区域则按页面分块；推导自 prototype DOM）
+   - 页面状态机（loading / empty / error / 正常 / 表单提交中 至少 5 态；多页则按页列出）
+   - 消费的后端端点（与 docs/05 对齐，按本 FE 的 `associated_reqs[]` 过滤）
+   - 业务规则前端复刻清单（逐条，每条标注：规则描述 / 触发时机 / 报错文案 / 来源 REQ）
+   - Design Tokens 引用清单（本 FE 用到的 var(--color-*) 名称）
+
+4. **验证**：所有顶级节非空；**全文不得出现** `TBD`、`@todo`、`controller`、`SQL`、`service`、`migration` 字样——前者代表 spec 未完成，后五者属于后端范畴不应出现。命中 → 修正后重渲染。
+
+5. 输出 `fe-feature-brainstorm: <fe_id> → <path>`，立即调用 `Skill(fe-feature-plan)`。
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/fe-feature-spec-template.md`
+- 委托：`superpowers:brainstorming`（本插件 `skills/internal/superpower-brainstorming/`）
+- 上游：`frontend-start`（每个未完成 FE 派发到此）
+- 下游：`fe-feature-plan`
+# 前端功能规格 — {{fe_id}} {{name}}
+
+> 关联 REQ：{{associated_reqs}}
+> 关联原型：{{associated_prototypes}}
+> 日期：{{date}}
+
+## 一、功能概述
+
+{{feature_overview}}
+
+## 二、组件树
+
+<!-- 基于关联原型的 DOM 结构推导。多页则按页面分块；每层缩进表示嵌套关系。 -->
+
+```
+{{component_tree}}
+```
+
+## 三、页面状态机
+
+| # | 状态 | 触发条件 | 视觉表现 | 用户可执行操作 |
+|---|------|---------|---------|--------------|
+{{state_machine_rows}}
+
+至少包含：loading / empty / error / 正常 / 提交中 五态。
+
+## 四、消费的后端端点
+
+| # | 方法 | 路径 | 触发时机 | 关联 REQ |
+|---|------|------|---------|---------|
+{{endpoint_rows}}
+
+## 五、业务规则前端复刻清单
+
+| # | 规则描述 | 触发时机 | 报错文案 | 来源 REQ |
+|---|---------|---------|---------|---------|
+{{validation_rows}}
+
+> **要求**：每条规则必须在前端 form-level 校验中复刻，不仅依赖后端报错。文案与后端语义一致。
+
+## 六、Design Tokens 引用清单
+
+<!-- 列出本页面用到的 token 变量名（不写 hex），如 var(--color-primary) / var(--color-bg-card)。来源见 docs/06 § 二。 -->
+
+```
+{{token_list}}
+```
+
+## 七、交互流程关键路径
+
+{{interaction_flow}}
+
+## 八、备注与开放问题
+
+{{open_questions}}
+---
+name: fe-feature-plan
+description: 前端功能循环第 2 步。将 FE 规格转化为任务级实现计划（每任务 2-5 分钟，含组件路径、props 契约、测试意图），输出到 docs/superpowers/plans/。
+user-invocable: false
+allowed-tools: Read Write Grep Skill
+---
+
+**所有输出必须使用中文。**
+
+# fe-feature-plan
+
+## 阶段范围（前端）
+
+把当前 FE 的规格转成任务级实现计划，委托 `superpowers:writing-plans` 起草。任务粒度限定为：**组件文件 / 路由配置 / store hook / API client 包装函数**。**不允许**生成涉及后端文件（controller / service / repository / SQL）的任务。
+
+## 执行步骤
+
+1. 收集输入：
+   - 当前 FE 的规格文件 `docs/superpowers/specs/<YYYY-MM-DD>-<fe_id>.md`（不存在则报错）
+   - `docs/04-技术规范.md § 一前端架构`（路由 / 状态库 / 组件目录约定 / 测试栈）
+   - `docs/09-项目目录结构.md § 前端目录结构`（文件落盘位置规范）
+   - 相关代码指针（待修改的现有前端文件，通过 grep 在 `frontend/` 下定位）
+
+2. 委托 `superpowers:writing-plans`，把上下文 + 落盘路径 `docs/superpowers/plans/<YYYY-MM-DD>-<fe_id>.md` 作为 caller-provided path 传入。caller-provided 上下文显式标注：
+
+   > 本次为前端阶段任务计划。任务粒度 = 组件 / 路由 / hook / API client。每个任务必须含：`test_file::test_name` + `impl_file` + 完成判据。`impl_file` 必须落在 `frontend/` 目录下（具体根路径见 docs/09 § 前端目录结构）。每个任务标注"测试先行类型" = jsdom 组件测试 OR Playwright E2E。
+
+3. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-plan-template.md` 渲染输出，写入推导路径。
+
+4. **验证**：
+   - 每个任务必须含 `test_file::test_name`、`impl_file`、完成标准
+   - **每个任务的 `impl_file` 路径必须以 `frontend/` 开头**（或 docs/09 声明的前端根目录），命中 `backend/` / `sql/` / `scripts/` → 修正后重渲染
+   - 全文不得出现 `TBD` / `【人工填写：...】`——查不到值用 `AskUserQuestion` 问用户
+
+5. 输出 `fe-feature-plan: <fe_id> → <path>`，立即调用 `Skill(fe-feature-tdd)`。
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/fe-feature-plan-template.md`
+- 委托：`superpowers:writing-plans`（本插件 `skills/internal/superpower-writing-plans/`）
+- 上游：`fe-feature-brainstorm`
+- 下游：`fe-feature-tdd`
+# 前端功能计划 — {{fe_id}} {{name}}
+
+> 规格：docs/superpowers/specs/{{date}}-{{fe_id}}.md
+> 关联原型：{{associated_prototypes}}
+> 关联 REQ：{{associated_reqs}}
+> 日期：{{date}}
+
+## 一、依赖与前置条件
+
+- 前置 FE：{{prerequisite_fes}}
+- 共享组件：{{shared_components}}
+- 路由配置文件：{{router_file}}
+
+## 二、任务清单
+
+每行一个任务，2-5 分钟可完成。`test_file::test_name` 先行写失败测试，`impl_file` 写最小实现使其通过。
+
+| # | 任务 | 测试先行类型 | test_file::test_name | impl_file | 完成判据 |
+|---|------|-------------|---------------------|-----------|---------|
+{{task_rows}}
+
+> **路径约束**：所有 `impl_file` 必须以 `frontend/`（或 docs/09 声明的前端根目录）开头。
+> **测试先行类型**：`jsdom`（组件单测，vitest/jest）或 `e2e`（Playwright）。
+
+## 三、组件 props 契约
+
+| 组件 | props | 类型 | 必填 | 说明 |
+|------|-------|------|------|------|
+{{props_rows}}
+
+## 四、状态管理
+
+<!-- store hook 名 / 持有的 state 字段 / 暴露的 actions。如本 FE 不引入新 store，写"复用 <既有 store>"。 -->
+
+{{state_management}}
+
+## 五、API client 包装
+
+| 函数名 | HTTP 方法 | 路径 | 入参 | 返回 |
+|--------|----------|------|------|------|
+{{api_client_rows}}
+
+> 函数实现必须基于项目统一 API client（见 docs/04 § 一），不允许直接 `fetch` / `axios` 拼路径。
+
+## 六、风险与回退
+
+{{risks}}
+---
+name: fe-feature-review
+description: 前端功能循环第 5 步。AI 自审 FE 的 diff（专用前端 reviewer），approve 则回 frontend-start；request-changes 则自修复 + 重 verify，循环上限 5 轮。
+user-invocable: false
+allowed-tools: Read Write Edit Skill Agent Bash(git add *) Bash(git commit *)
+---
+
+**所有输出必须使用中文。**
+
+# fe-feature-review
+
+委托 `fe-code-reviewer` agent（前端专用 reviewer，不复用 superpower-code-reviewer）对当前 FE 引入的代码改动做 AI 自审。`approve` 回 frontend-start 推进下一 FE；`request-changes` 自修复 must-fix 并重新 verify，最多 5 轮。
+
+## 执行步骤
+
+1. 派发 `Agent(subagent_type=fe-code-reviewer)`，把本 FE 引入的代码 diff、规格（`docs/superpowers/specs/<date>-<fe_id>.md`）、本 FE 关联的所有 prototype 文件（spec 顶部的 `关联原型` 列表）作为输入。
+
+2. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-review-template.md` 渲染审阅报告，写入 `docs/superpowers/reviews/<YYYY-MM-DD>-<fe_id>.md`。`verdict` 取 `approve` 或 `request-changes`。
+
+3. 按 `verdict` 分派：
+
+   **approve**
+   - `Edit docs/08-模块任务管理.md § 三`，把本 FE 下 `- [ ] <fe_id> ...` 改为 `- [x] <fe_id> ...`（仅 FE 级可视化；前端阶段完成仍以 `整体 MR:` + GitLab API state 为准）
+   - 输出 `fe-feature-review: <fe_id> round <N> 通过`，调用 `Skill(frontend-start)` 推进下一 FE 或进入 test-gate(phase=frontend)
+
+   **request-changes（round < 5）**
+   - 逐项编辑 `must_fix[]` 指向的代码文件
+   - 按 `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md` 格式 commit：`fix(<scope>): 修复 review round <N> must-fix REQ_ID: <fe_id>`
+   - 调用 `Skill(fe-feature-verify)` 重新验证；verify 通过后会再次链回本 skill，round `<N+1>` 重审
+
+   **request-changes（round == 5）**
+   - 停止并打印摘要，升级给用户手工介入；不再自动修复，不回调 frontend-start
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/fe-feature-review-template.md`
+- `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md`
+- 委托：`fe-code-reviewer` agent（本插件 `agents/fe-code-reviewer.md`，前端专用，硬编码 7 维 review checklist）
+- 上游：`fe-feature-verify`
+- 下游：`frontend-start`（approve）/ `fe-feature-verify`（request-changes 时重验）
+{{type}}({{scope}}): {{subject}} {{req_id}}
+---
+fe_id: {{fe_id}}
+date: {{date}}
+round: {{round}}
+reviewer: fe-code-reviewer
+---
+
+# Review: {{fe_id}} — round {{round}}
+
+## 结论
+{{verdict}}  （approve / request-changes）
+
+## Must-fix
+{{#each must_fix}}
+- [{{severity}}] {{file}}:{{line}} — {{issue}}（建议：{{suggestion}}）
+{{/each}}
+
+## Nice-to-have
+{{#each nice_to_have}}
+- {{file}}:{{line}} — {{suggestion}}
+{{/each}}
+
+## 维度核查（fe-code-reviewer 7 维）
+
+| # | 维度 | 状态 | 备注 |
+|---|------|------|------|
+| 1 | prototype 一致性 | {{dim_prototype}} | {{dim_prototype_note}} |
+| 2 | Design Tokens | {{dim_tokens}} | {{dim_tokens_note}} |
+| 3 | 无障碍 | {{dim_a11y}} | {{dim_a11y_note}} |
+| 4 | 响应式 | {{dim_responsive}} | {{dim_responsive_note}} |
+| 5 | 业务校验前端复刻 | {{dim_validation}} | {{dim_validation_note}} |
+| 6 | API 调用一致性 | {{dim_api}} | {{dim_api_note}} |
+| 7 | 状态机覆盖 | {{dim_state}} | {{dim_state_note}} |
+
+## 反例 / 测试覆盖缺口
+
+{{gaps}}
+---
+name: fe-feature-tdd
+description: 前端功能循环第 3 步。按 plan 逐任务做 TDD（失败测试 → 实现 → 通过 → commit），组件测试用 jsdom，E2E 派子会话跑 Playwright。
+user-invocable: false
+allowed-tools: Read Write Edit Agent Skill Bash(git add *) Bash(git commit *)
+---
+
+**所有输出必须使用中文。**
+
+# fe-feature-tdd
+
+按 plan 文件逐任务做 TDD：写失败测试 → 写最小实现 → 确认通过 → commit。**所有测试运行强制派发到 Agent 子会话**，主会话只接收 JSON 结果。
+
+## 路径护栏（前端阶段）
+
+- 任务的 `impl_file` 路径若**不以** `frontend/`（或项目实际前端根目录，从 `docs/09-项目目录结构.md § 前端目录结构` 取）开头 → 硬停并打印：`fe-feature-tdd 不允许写非前端文件：<impl_file>。前端阶段任务的 impl_file 必须落在前端目录下。`
+- 命中 `backend/` / `sql/` / `scripts/` → 同上硬停
+- 不允许在主会话直接 `pnpm playwright` / `pnpm test` / `pnpm e2e`，必须派发子会话
+
+## 执行步骤
+
+1. 加载计划文件 `docs/superpowers/plans/<YYYY-MM-DD>-<fe_id>.md`。
+
+2. 从 `docs/04-技术规范.md § 零 frontend` 取测试栈：
+   - `frontend.unit_test_runner`：vitest / jest（默认 vitest）
+   - `frontend.e2e_runner`：playwright（默认 playwright）
+   - `frontend.test_command` / `frontend.e2e_command`：执行命令（缺失则用 `pnpm test:ci` / `pnpm e2e:ci`）
+
+3. 按顺序处理每个任务：
+
+   a. 在 `test_file::test_name` 处写**失败**测试：
+      - `测试先行类型 = jsdom`：在 jsdom 环境下用 vitest/jest 写组件单测（render + 断言 DOM / 交互后状态变化）
+      - `测试先行类型 = e2e`：在 `frontend/e2e/` 写 Playwright 测试（headless）
+
+   b. 派发 Agent 子会话（general-purpose）运行该测试，子会话只返回 `{command, exit_code, failing_assertion}` JSON，确认失败。
+
+   c. 在 `impl_file` 处写**最小**实现使测试通过。**严格遵守**：
+      - 路径必须以 `frontend/`（或 docs/09 声明的前端根）开头（违反 → 硬停，见护栏）
+      - 色值用 `var(--color-*)`（来自 spec § 六），不硬编码 hex
+      - 业务校验按 spec § 五 在 form-level 复刻
+
+   d. 再次派发子会话确认通过。
+
+   e. 同一测试 >10 次修复仍失败 → 调用 `Skill(interrupt-check)`（中断 #1：测试反复失败）。
+
+   f. 按 `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md` 格式 commit：
+      - `scope` = 任务模块（如组件名 `dashboard` / `user-form`）
+      - `subject` ≤ 50 字符
+      - 必含 trailer `REQ_ID: <fe_id>`（如 `REQ_ID: FE-01`）
+
+4. 全部任务完成 → 调用 `Skill(fe-feature-verify)`。
+
+## 护栏
+
+- **绝不**在主会话直接跑 `pnpm test` / `pnpm e2e` / `pnpm playwright`，必须通过子会话
+- **绝不**在 `impl_file` 中写非 `frontend/` 路径（路径护栏会硬停）
+- 每次 commit 必须含 `REQ_ID: FE-NN` trailer；不混合无关改动到同一 commit
+- 不硬编码颜色 hex；token 引用必须对齐 spec § 六
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/commit-message-template.md`
+- 守门：`interrupt-check`（仅在步骤 3.e 触发，条件 1）
+- 上游：`fe-feature-plan`
+- 下游：`fe-feature-verify`
+{{type}}({{scope}}): {{subject}} {{req_id}}
+---
+name: fe-feature-verify
+description: 前端功能循环第 4 步。把 FE 的组件测试 + E2E 派发到子会话执行，按模板渲染证据。无证据不声称完成。
+user-invocable: false
+allowed-tools: Skill Read Agent
+---
+
+**所有输出必须使用中文。**
+
+# fe-feature-verify
+
+把当前 FE 的测试派发到 Agent 子会话执行，按模板把结构化结果渲染成证据。**主会话从不直接跑测试**，也不自由编写证据。
+
+## 执行步骤
+
+1. 从 plan 文件确定本 FE 的测试目标：
+   - 单测目标：plan § 二中所有 `测试先行类型 = jsdom` 的 test_file 列表 → 拼成 vitest/jest 过滤模式
+   - E2E 目标：所有 `测试先行类型 = e2e` 的 test_file 列表 → 拼成 Playwright spec 过滤模式
+
+2. 派发 Agent 子会话（general-purpose）依次运行两个目标，子会话只返回结构化 JSON（不输出描述文字）：
+
+   ```json
+   {
+     "unit": {
+       "command": "<vitest/jest 命令>",
+       "exit_code": <int>,
+       "passed": <int>,
+       "failed": <int>,
+       "failed_list": ["<test>", ...],
+       "stdout_excerpt": "<最后 30 行或最相关的失败片段>"
+     },
+     "e2e": {
+       "command": "<playwright 命令>",
+       "exit_code": <int>,
+       "passed": <int>,
+       "failed": <int>,
+       "failed_list": ["<spec>", ...],
+       "stdout_excerpt": "<最后 30 行或最相关的失败片段>"
+     }
+   }
+   ```
+
+   命令从 `docs/04-技术规范.md § 零 frontend.test_command` / `frontend.e2e_command` 取，缺失则用默认 `pnpm test:ci` / `pnpm e2e:ci`。
+
+3. 按 `${CLAUDE_SKILL_DIR}/templates/fe-feature-verify-evidence-template.md` 渲染证据并打印到会话。
+
+4. **任一目标 `exit_code != 0` 或 `failed > 0`** → 停止，不进入 review。
+
+5. 全部通过 → 调用 `Skill(fe-feature-review)`。
+
+## 护栏
+
+- **绝不**在主会话直接跑测试，必须通过子会话
+- **绝不**自由编写证据正文，必须从模板渲染
+- 不要把原始 stdout 全文塞进主会话（`stdout_excerpt` ≤ 30 行）
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/fe-feature-verify-evidence-template.md`
+- 上游：`fe-feature-tdd`
+- 下游：`fe-feature-review`
+## Verify evidence — {{fe_id}}
+
+### 单元测试（jsdom）
+
+- 命令: `{{unit.command}}`
+- 子会话: {{unit.subagent_id}}
+- 退出码: {{unit.exit_code}}
+- 通过用例数: {{unit.passed}}
+- 失败用例数: {{unit.failed}}
+- 失败列表: {{unit.failed_list}}
+
+关键 stdout 片段 (≤30 行):
+
+```
+{{unit.stdout_excerpt}}
+```
+
+### E2E 测试（Playwright）
+
+- 命令: `{{e2e.command}}`
+- 子会话: {{e2e.subagent_id}}
+- 退出码: {{e2e.exit_code}}
+- 通过用例数: {{e2e.passed}}
+- 失败用例数: {{e2e.failed}}
+- 失败列表: {{e2e.failed_list}}
+
+关键 stdout 片段 (≤30 行):
+
+```
+{{e2e.stdout_excerpt}}
+```
+
+结论: {{conclusion}}  （pass = 两段都 pass / fail = 任一 fail）
@@ -9,6 +9,10 @@ allowed-tools: Read Write Skill Bash(mysql *)
 # feature-brainstorm
+## 阶段范围（后端）
+
+本 skill 服务于**后端阶段**。产出范围限定为 controller / service / repository / DTO / 校验 / SQL migration / REST 契约。读 docs/01 REQ 卡片时**忽略 UI 描述**（输入控件类型、按钮位置、列表布局等），但**校验规则、业务规则**仍要落到后端 DTO + service。UI 实现统一推迟到前端阶段（fe-feature-*）。
+
 针对单个 REQ，委托 `superpower-brainstorming` 做交互式头脑风暴，把输出按规格模板渲染，产出单页功能规格。
 ## 执行步骤
@@ -9,6 +9,10 @@ allowed-tools: Read Write Grep Skill
 # feature-plan
+## 阶段范围（后端）
+
+本 skill 服务于**后端阶段**。任务粒度限定为后端模块文件：controller / service / repository / DTO / 校验 / SQL migration。**禁止**生成 `frontend/` 路径下的实现任务——UI 实现统一推迟到前端阶段（fe-feature-*）。
+
 把当前 REQ 的功能规格转成任务级实现计划，委托 `superpower-writing-plans` 起草，按计划模板渲染落盘。
 ## 执行步骤
@@ -33,6 +33,7 @@ allowed-tools: Read Write Edit Agent Skill Bash(git add *) Bash(git commit *)
 - **绝不**在主会话直接跑 `mvn test` / `pnpm test` / `scripts/test.sh`，必须通过子会话
 - **绝不**在主会话直接 `mysql -e "ALTER ..."`；业务 schema 改动一律走 `sql/migrations/V*.sql` 文件（只读查询 / 临时调试除外）
 - 每次 commit 必须含 `REQ-XXX-NNN` 标签；不混合无关改动到同一 commit
+- **后端阶段路径硬护栏**：任务表里的 `impl_file` 路径以 `frontend/` 开头 → 硬停并打印 `feature-tdd 后端阶段不允许写前端代码：<impl_file>。请检查 plan 任务定义；UI 推迟到前端阶段（fe-feature-*）`，不再继续 TDD 循环
 ## 参考
+---
+name: frontend-start
+description: 前端阶段循环入口。AI 自主推导 FE 业务功能清单写入 docs/08 § 三（已有则加载），定位未完成 FE 派发 fe-feature-brainstorm 或 test-gate（前端阶段）。幂等可重入。
+user-invocable: false
+allowed-tools: Read Write Edit Skill Glob Grep AskUserQuestion Bash(git branch *) Bash(git checkout *) Bash(git rev-parse *) Bash(git pull *) Bash(git status *) Bash(git symbolic-ref *) Bash(curl *) Bash(jq *) Bash(find *) Bash(ls *)
+---
+
+**所有输出必须使用中文。**
+
+# frontend-start
+
+## 执行步骤
+
+### 步骤 1：检查 prototype
+
+项目根 `prototype/` 至少含 1 个 `*.html` → 通过，进入步骤 2；缺失 → 用 `AskUserQuestion` 让用户补齐 prototype 后重跑入口，停止。
+
+### 步骤 2：准备 FE 清单
+
+读 docs/08 § 三 "功能:" 项：
+
+- 已有 `- [ ] FE-NN ...` 或 `- [x] FE-NN ...` 行 → **加载**：逐行解析得 `fe_list[]`，每项 `{ fe_id, name, status, associated_reqs[], associated_prototypes[] }`。行格式不符 → 硬停打印问题行
+- 仅有 HTML 注释占位（无 FE bullet）→ **推导**：
+  1. 读 `prototype/**/*.html` + `docs/01-需求清单/**/*.md` + `docs/05-API接口契约.md`
+  2. 以**业务功能**为单位拆分（同流程多屏可合 1 FE；一 HTML 多功能可拆多 FE；无 UI 的 REQ 不产生 FE）。每个 FE：`{ fe_id: FE-NN, name, associated_reqs[], associated_prototypes[] }`，prototype 路径可带 anchor 区分文件内多区域
+  3. **写入 § 三 "功能:" 项**（替换占位 HTML 注释），行格式：
+
+     ```
+     - [ ] FE-NN 功能名 ｜ 关联 REQ：REQ-A, REQ-B ｜ 关联原型：prototype/<file>.html
+     ```
+
+     保留 `- 整体 MR: —` 不动；写入后解析得 `fe_list[]`，继续步骤 3
+
+### 步骤 3：检查前端 MR 状态
+
+读 § 三 `整体 MR:` 调 GitLab API：
+
+- `merged` → 打印"前端阶段已完成"并停（冗余保护，正常由 coding-start 拦掉）
+- 其它（`—` / opened / closed）→ 进入步骤 4
+- API 异常 → 硬停 + 诊断
+
+### 步骤 4：切到 frontend-phase 分支
+
+目标分支 `frontend-phase`，分支管理逻辑同 module-start 步骤 3：已在 → 继续；存在 → checkout；不存在 → 切默认分支 fast-forward 后 `git checkout -b frontend-phase`。任何错误硬停 + 诊断，不自动 stash / 覆盖。
+
+### 步骤 5：识别已完成的 FE
+
+扫 `docs/superpowers/reviews/<日期>-FE-*.md`，`verdict: approve` 的收入 `done_fes[]`。每次进入重新计算，不缓存。
+
+### 步骤 6：报告进度
+
+按 `${CLAUDE_SKILL_DIR}/templates/frontend-start-banner-template.md` 渲染：当前分支 + prototype HTML 数 + FE 进度（done / total）+ 下一 FE。
+
+### 步骤 7：进入下一环节
+
+- 存在未完成 FE → `Skill(fe-feature-brainstorm)`，参数 `{ fe_id, name, associated_reqs[], associated_prototypes[] }`
+- 全 FE 完成 → `Skill(test-gate)` 带 `phase=frontend`
+
+## 参考
+
+- `${CLAUDE_SKILL_DIR}/templates/frontend-start-banner-template.md`
+- `docs/08-模块任务管理.md § 三`（前端阶段元数据：整体 MR + FE 清单）
+- `prototype/`（HTML mockup，FE 拆分粒度与文件数无关）
+- `docs/superpowers/reviews/*-FE-*.md`（verdict=approve 即完成）
+- 上游：`coding-start`（步骤 4 派发，仅当后端完成 + 前端未完成）；`fe-feature-review` approve 后回调
+- 下游：`fe-feature-brainstorm`（每 FE）/ `test-gate`（phase=frontend，全完成时）
+- 前置门禁：本 skill 步骤 1 自承（coding-start 不做）
+## 前端阶段（frontend-phase）
+
+- 分支：frontend-phase
+- 整体 MR：{{overall_mr}}
+- FE 进度（`x` = 已完成 review approve；FE 是业务功能粒度，与 prototype/ HTML 文件数无关）：
+{{#each fes}}
+  - [{{status}}] {{fe_id}} {{name}} ｜ 关联 REQ：{{reqs}} ｜ 关联原型：{{prototypes}}
+{{/each}}
+- 下一步：{{next_action}}
 ---
 name: module-report
-description: 本地测试闸门通过后，生成标准化 12 节模块完成报告并 commit 到 module 分支供 MR 嵌入。
+description: 本地测试闸门通过后，生成标准化 12 节完成报告（后端模块 OR 前端阶段）并 commit 到当前分支供 MR 嵌入。
 user-invocable: false
-allowed-tools: Read Write Glob Grep Skill Bash(git diff *) Bash(git log *) Bash(git add *) Bash(git commit *)
+allowed-tools: Read Write Glob Grep Skill Bash(git diff *) Bash(git log *) Bash(git add *) Bash(git commit *) Bash(git branch *)
 ---
 **所有输出必须使用中文。**
 # module-report
-`test-gate` 绿色后渲染 12 节模块完成报告，commit 到 module 分支供 MR 嵌入。**只读摘要，不读 diff 正文进上下文**。
+`test-gate` 绿色后渲染 12 节完成报告，commit 到当前分支供 MR 嵌入。**只读摘要，不读 diff 正文进上下文**。
+
+按当前分支自动推断 `phase`：
+
+- `module-<id>` → `phase=backend`，`phase_id=<id>`
+- `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`
+- 其它分支 → 硬停
 ## 执行步骤
-1. 验证上游 `test-gate` 已绿；红色则停。
+### 步骤 0：推断 phase 与上下文
+
+从 `git branch --show-current` 取分支名，按上述规则推出 `phase` 与 `phase_id`。
+
+1. 验证上游 `test-gate` 已绿（读 `docs/superpowers/module-reports/<phase_id>-test-gate.md`）；红色则停。
+
 2. 收集输入（核心约束：取 git 摘要而非 diff 正文）：
-   - § ③ 文件变更：用 `git diff --stat` / `--name-status` / `git log --oneline` 摘要（区间：module 分支起点 → HEAD）
-   - § ② / § ⑨：直接 Read `docs/superpowers/{specs,plans,reviews}/<日期>-<本模块的 REQ>.md`（小文件可全读）
-   - § ⑤：Read `docs/superpowers/module-reports/<module_id>-test-gate.md`
+
+   **后端阶段 (phase=backend)**：
+   - § ③ 文件变更：`git diff --stat` / `--name-status` / `git log --oneline`（区间：module 分支起点 → HEAD）
+   - § ② / § ⑨：Read `docs/superpowers/{specs,plans,reviews}/<日期>-<本模块的 REQ>.md`
+   - § ⑤：Read `docs/superpowers/module-reports/<phase_id>-test-gate.md`
    - § ⑥ Migration：`git diff --name-only --diff-filter=A -- 'sql/migrations/V*.sql'` 列新增 migration，每个 Read 第一行作说明
-   - § ⑦ 跨模块改动：Read `docs/superpowers/module-reports/<module_id>-cross-module.md`（如存在）
+   - § ⑦ 跨模块改动：Read `docs/superpowers/module-reports/<phase_id>-cross-module.md`（如存在）
    - § ④ 读写的表：用 grep 定位涉 SQL 的文件后按需读片段，**不全量读 docs/03**
+
+   **前端阶段 (phase=frontend)**：
+   - § ① 模块信息：`module_id` 填 `frontend-phase`，`module_name` 填 `前端阶段（整体）`
+   - § ② 改为"FE 完成清单"：扫 `docs/superpowers/{specs,plans,reviews}/<日期>-FE-*.md`，按 FE-NN 顺序列出
+   - § ③ 文件变更：`git diff --stat` 区间 `frontend-phase` 分支起点 → HEAD
+   - § ④ 数据库使用表：填 `N/A（前端阶段）`
+   - § ⑤：Read `docs/superpowers/module-reports/frontend-phase-test-gate.md`
+   - § ⑥ Migration：填 `N/A（前端阶段）`
+   - § ⑦：填 `N/A（前端阶段不涉及跨模块代码改动；token 漂移见 § ⑧）`
+   - § ⑧ 偏离清单：除常规偏离外，额外审查"实际渲染 DOM 与各 FE 关联原型主结构的差异"，逐 FE 列出（关联原型清单见每个 FE 的 spec）
+   - § ⑪ 下一模块预览：填"上线/部署后续步骤"
+
 3. 按 `${CLAUDE_SKILL_DIR}/templates/module-report-template.md` 渲染 12 节。
+
 4. **硬验证**：
-   - § ⑦：跨模块日志中任何 `TBD(CC 补)` 或敷衍填充 → 调用 `Skill(cross-module-log)` 一次性批量补齐，补完回本步骤重验（**整模块周期内唯一补 TBD 的时机**）
-   - § ⑧：必须列举所有偏离规格之处；若无，写"无偏离"
-5. 写入 `docs/superpowers/module-reports/<YYYY-MM-DD>-<module_id>.md`，连同跨模块日志（如存在）一起 commit 到 module 分支：
+   - § ⑦（仅 backend）：跨模块日志中任何 `TBD(CC 补)` 或敷衍填充 → 调用 `Skill(cross-module-log)` 一次性批量补齐，补完回本步骤重验（**整模块周期内唯一补 TBD 的时机**）
+   - § ⑧：必须列举所有偏离之处；若无，写"无偏离"
+
+5. 写入 `docs/superpowers/module-reports/<YYYY-MM-DD>-<phase_id>.md`，连同跨模块日志（如存在）一起 commit 到当前分支：
    ```bash
-   git add docs/superpowers/module-reports/<YYYY-MM-DD>-<module_id>.md
-   [ -f docs/superpowers/module-reports/<module_id>-cross-module.md ] && \
-     git add docs/superpowers/module-reports/<module_id>-cross-module.md
-   git commit -m "docs(<module_id>): add module completion report + cross-module log"
+   git add docs/superpowers/module-reports/<YYYY-MM-DD>-<phase_id>.md
+   [ -f docs/superpowers/module-reports/<phase_id>-cross-module.md ] && \
+     git add docs/superpowers/module-reports/<phase_id>-cross-module.md
+   git commit -m "docs(<phase_id>): add completion report + cross-module log"
    ```
    commit 是必需的——`mr-create` 的 worktree-clean 前置条件依赖此步。
+
 6. 调用 `Skill(mr-create)` 推送并创建 MR。
 ## 参考
-- `${CLAUDE_SKILL_DIR}/templates/module-report-template.md`（12 节）
+- `${CLAUDE_SKILL_DIR}/templates/module-report-template.md`（12 节，后端 + 前端共用）
 - 上游：`test-gate`（绿色时派发）
-- 下游：`mr-create`
+- 下游：`mr-create`（phase 由当前分支推断）
 ---
 name: module-start
-description: 模块循环入口。定位当前模块与未完成 REQ，派发到 feature-brainstorm（每个 REQ 一次）或 test-gate（本模块全部完成）。幂等可重入。
+description: 后端模块循环入口。定位当前未 merged 模块与未完成 REQ，派发 feature-brainstorm 或 test-gate；幂等可重入。阶段路由由 coding-start 负责，本 skill 不感知前端阶段。
 user-invocable: false
 allowed-tools: Read Write Skill Glob Grep Bash(git branch *) Bash(git checkout *) Bash(git rev-parse *) Bash(git pull *) Bash(git status *) Bash(git symbolic-ref *) Bash(curl *) Bash(jq *)
 ---
@@ -9,13 +9,17 @@ allowed-tools: Read Write Skill Glob Grep Bash(git branch *) Bash(git checkout *
 # module-start
+## 职责说明
+
+本 skill 单一职责：推进**后端模块循环**。`coding-start` 已在派发前确认存在未 merged 后端模块；本 skill 不再做"后端是否全完"的判定，也不感知前端阶段。
+
 ## 执行步骤
 ### 步骤 1：定位当前模块与本模块 REQ 列表
 按 `docs/02 § 二 开发顺序清单` 的 REQ 顺序扫描，找到第一个所属模块尚未 merged 的模块作为 `current_module`，并抽取本模块 REQ 序列。
-模块状态判定（`MR:` 字段 × GitLab API state 三种组合的语义和应对动作）参见 `CLAUDE.md § ✅ 模块完成判定规则 § 模块状态语义`。
+模块状态判定（`MR:` 字段 × GitLab API state 三种组合的语义和应对动作）参见 `CLAUDE.md § ✅ 阶段完成判定规则 § 状态语义`。
 找到 `current_module` 后，从 docs/02 § 二 的 REQ 列表里取出所有 `module_id == current_module` 的项，按原序得 `req_list[]`（A5 约束保证同模块 REQ 连续）。模块名、需求卡目录等其它字段由后续步骤按需从 `docs/08 § 二` 或 `docs/01-需求清单/` 取，不在本步骤预读。
@@ -25,9 +29,12 @@ allowed-tools: Read Write Skill Glob Grep Bash(git branch *) Bash(git checkout *
 - API 异常（HTTP 非 2xx / 找不到 MR / state 非合法值）一律硬停，**禁止静默假设未 merged**，向用户打印诊断信息，引导核查上述凭据与 docs/08 的 iid
 - 任何文件读取或解析失败 → 打印错误并停止
-### 步骤 2：所有模块都完成时结束
+### 步骤 2：找不到未 merged 后端模块的处理
+
+如果步骤 1 没找到任何未 merged 的后端模块——理论上不应触达此分支（`coding-start` 步骤 3 已确认存在未 merged 模块才会派发到本 skill），属于异常调用：
-如果步骤 1 没找到任何未 merged 的模块（即整个项目已做完），打印"所有模块已完成"提示用户，结束流程，不再进入后续步骤。
+- 打印诊断："`module-start` 未发现未 merged 后端模块。请通过 `/erp-workflow:coding-start` 入口重新驱动——coding-start 会按 docs/08 § 二/§ 三 自动路由到正确阶段（后端 / 前端 / 全部完成）。"
+- 结束本 skill，不派发下游
 ### 步骤 3：确保处于模块分支
@@ -57,7 +64,10 @@ allowed-tools: Read Write Skill Glob Grep Bash(git branch *) Bash(git checkout *
 ## 参考
 - `docs/02-开发计划.md § 二 开发顺序清单`（分发权威）
-- `docs/08-模块任务管理.md § 二`（模块元数据，含 `MR:` 字段；完成判定以 MR state 为准）
+- `docs/08-模块任务管理.md § 二`（后端模块元数据，含 `MR:` 字段；完成判定以 MR state 为准）
 - `docs/superpowers/reviews/*.md`（REQ 级进度事实——verdict=approve 即完成）
 - `${CLAUDE_SKILL_DIR}/templates/module-start-banner-template.md`
-- 下游：`feature-brainstorm`（每个 REQ）/ `test-gate`（本模块完成）
+- 下游：
+  - `feature-brainstorm`（每个未完成 REQ）
+  - `test-gate`（本模块全部 REQ approve 后；phase=backend 由分支推断）
+- 上游：`coding-start`（步骤 3 派发到此；后端模块全 merged 时不会派发到此）
 ---
 name: mr-create
-description: 模块报告完成后，把 module 分支推到远程并创建 GitLab MR，把 MR iid 回写 docs/08 + URL 回写报告 § ⑫，停下等人工 Approve + Merge。
+description: 完成报告生成后，把当前分支（module-* 后端 / frontend-phase 前端）推到远程并创建 GitLab MR，把 MR iid 回写 docs/08（§ 二 模块行 / § 三 整体 MR）+ URL 回写报告 § ⑫，停下等人工 Approve + Merge。
 user-invocable: false
 allowed-tools: Read Edit Bash(git *) Bash(bash *)
 ---
@@ -11,15 +11,19 @@ allowed-tools: Read Edit Bash(git *) Bash(bash *)
 ## 前置条件
-- `module-report` 已生成报告并 commit 到 module 分支
-- `test-gate` 绿色，test-gate.md 已 commit 到 module 分支
-- 当前分支 = `module-<module_id>`（由 `module-start` 步骤 3 切入）
+- `module-report` 已生成报告并 commit 到当前分支
+- `test-gate` 绿色，test-gate.md 已 commit 到当前分支
+- 当前分支 = `module-<module_id>` 或 `frontend-phase`（由 `module-start` 步骤 3 / `frontend-start` 步骤 4 切入）
 ## 执行步骤
-### 步骤 1：验证当前分支
+### 步骤 1：验证当前分支并推断 phase
-`git branch --show-current` 必须匹配 `module-*`，否则停下报错（不自动建分支——分支职责在 `module-start` 步骤 3）。从分支名取 `module_id` = 去掉 `module-` 前缀。
+`git branch --show-current`：
+
+- 匹配 `module-*` → `phase=backend`，`phase_id=` 去掉 `module-` 前缀
+- 等于 `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`
+- 其它 → 停下报错（不自动建分支——分支职责在上游 `module-start` / `frontend-start`）
 ### 步骤 2：验证 worktree 干净
@@ -46,10 +50,10 @@ allowed-tools: Read Edit Bash(git *) Bash(bash *)
 ### 步骤 4：调脚本创建（或复用）MR
 ```bash
-bash "${CLAUDE_SKILL_DIR}/scripts/create-mr.sh" <module_id> <current_branch> <YYYY-MM-DD>
+bash "${CLAUDE_SKILL_DIR}/scripts/create-mr.sh" <phase_id> <current_branch> <YYYY-MM-DD>
 ```
-脚本内部完成：加载 `.env.local` → 探测目标分支 → 从 docs/08 取 `module_name` 与 test-gate.md 取结论 → 渲染 description → 查已有 opened MR → 否则创建新 MR。
+`<phase_id>` = 后端模块 id（如 `module_sys`）或前端常量 `frontend-phase`。脚本内部完成：加载 `.env.local` → 探测目标分支 → 取 `module_name`（后端从 docs/08 § 二，前端使用常量"前端阶段（整体）"）→ test-gate.md 取结论 → 渲染 description → 查已有 opened MR → 否则创建新 MR。
 输出（stdout）：单行 `<MR_IID> <MR_URL>`，由本步骤捕获供后续步骤使用。失败时脚本写诊断到 stderr 并 exit 1，本 skill 停下。
@@ -57,20 +61,23 @@ bash &quot;${CLAUDE_SKILL_DIR}/scripts/create-mr.sh&quot; &lt;module_id&gt; &lt;current_branch&gt; &lt;YY
 **先于步骤 6 执行**——若步骤 6 失败，重跑时步骤 4 脚本能识别已有 MR + docs/08 已含 IID，状态一致。
-`Edit docs/08-模块任务管理.md`：把当前模块的 `  - MR: —` 改为 `  - MR: !<MR_IID>`。
+`Edit docs/08-模块任务管理.md`：
+
+- **phase=backend**：在 § 二 中找到当前模块的 `  - MR: —` 改为 `  - MR: !<MR_IID>`
+- **phase=frontend**：在 § 三 中找到 `- 整体 MR: —` 改为 `- 整体 MR: !<MR_IID>`
 ```bash
 git add docs/08-模块任务管理.md
-git commit -m "chore(<module_id>): record MR !<MR_IID> in docs/08"
+git commit -m "chore(<phase_id>): record MR !<MR_IID> in docs/08"
 ```
-### 步骤 6：追加 MR URL 到模块报告 § ⑫ 并 commit
+### 步骤 6：追加 MR URL 到完成报告 § ⑫ 并 commit
-`Edit docs/superpowers/module-reports/<date>-<module_id>.md` 的 § ⑫，把 `{{mr_url}}` 替换为 `<MR_URL>`（已替换则追加一行）。
+`Edit docs/superpowers/module-reports/<date>-<phase_id>.md` 的 § ⑫，把 `{{mr_url}}` 替换为 `<MR_URL>`（已替换则追加一行）。
 ```bash
-git add docs/superpowers/module-reports/<date>-<module_id>.md
-git commit -m "docs(<module_id>): record MR !<MR_IID> link in module report"
+git add docs/superpowers/module-reports/<date>-<phase_id>.md
+git commit -m "docs(<phase_id>): record MR !<MR_IID> link in completion report"
 ```
 ### 步骤 7：再次 push 同步新 commits
@@ -81,11 +88,14 @@ git commit -m &quot;docs(&lt;module_id&gt;): record MR !&lt;MR_IID&gt; link in module report&quot;
 ### 步骤 8：打印 MR URL，停下等 Approve + Merge
-向会话打印 `<MR_URL>`，结束本 skill。用户在 GitLab merge 后再运行 `/erp-workflow:coding-start`，入口扫描到 `state=merged` 后自动推进下一模块。
+向会话打印 `<MR_URL>`，结束本 skill。
+
+- **phase=backend**：用户在 GitLab merge 后再运行 `/erp-workflow:coding-start`；coding-start 重新做后端完成性检查，未完则推进下一模块，全 merged 则路由到 `frontend-start`（frontend-start 自带 prototype/ 门禁）
+- **phase=frontend**：用户在 GitLab merge 后再运行 `/erp-workflow:coding-start`，扫描到 § 三 整体 MR `state=merged` → 打印"所有阶段已完成"
 ## 参考
-- `${CLAUDE_SKILL_DIR}/scripts/create-mr.sh`（步骤 4 主流程脚本）
+- `${CLAUDE_SKILL_DIR}/scripts/create-mr.sh`（步骤 4 主流程脚本，按 phase_id 自动选 backend / frontend 行为）
 - `${CLAUDE_SKILL_DIR}/templates/mr-title-template.md`
 - `${CLAUDE_SKILL_DIR}/templates/mr-description-template.md`
 - 上游：`module-report`
@@ -2,7 +2,9 @@
 # create-mr.sh — mr-create 主流程：渲染 description、查已有 MR / 创建新 MR
 #
 # 用法：
-#   bash create-mr.sh <module_id> <current_branch> <date>
+#   bash create-mr.sh <phase_id> <current_branch> <date>
+#
+#   <phase_id> = 后端模块 id（如 module_sys）或前端常量 "frontend-phase"
 #
 # 输出（stdout，单行，由调用方读取）：
 #   <MR_IID> <MR_URL>
@@ -10,13 +12,14 @@
 # 失败：诊断写 stderr，exit 1。
 #
 # 设计要点：
-# - 模块报告整文只经 sed + awk 管道流入 description 与 GitLab API（curl --rawfile），
+# - 报告整文只经 sed + awk 管道流入 description 与 GitLab API（curl --rawfile），
 #   全程不进 LLM 上下文。
 # - 幂等：同一 source_branch 已有 opened MR 时，复用其 iid/url，不再创建。
+# - phase 自动：phase_id == "frontend-phase" 时跳过 docs/08 § 二 lookup，使用常量名。
 set -euo pipefail
-MODULE_ID="${1:?usage: create-mr.sh <module_id> <current_branch> <date>}"
+MODULE_ID="${1:?usage: create-mr.sh <phase_id> <current_branch> <date>}"
 CURRENT_BRANCH="${2:?missing current_branch}"
 DATE="${3:?missing date (YYYY-MM-DD)}"
@@ -28,7 +31,7 @@ TITLE_TPL=&quot;$TPL_DIR/mr-title-template.md&quot;
 REPORT="docs/superpowers/module-reports/${DATE}-${MODULE_ID}.md"
 TEST_GATE="docs/superpowers/module-reports/${MODULE_ID}-test-gate.md"
-[ -f "$REPORT" ]    || { echo "[create-mr] ⚠️ 模块报告不存在: $REPORT" >&2; exit 1; }
+[ -f "$REPORT" ]    || { echo "[create-mr] ⚠️ 完成报告不存在: $REPORT" >&2; exit 1; }
 [ -f "$TEST_GATE" ] || { echo "[create-mr] ⚠️ test-gate evidence 不存在: $TEST_GATE" >&2; exit 1; }
 # 1. 加载凭据
@@ -44,11 +47,16 @@ TARGET_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2&gt;/dev/null | sed &#39;s|r
 [ -n "$TARGET_BRANCH" ] || TARGET_BRANCH=$(git branch -r --format='%(refname:short)' | grep -E '^origin/(main|master)$' | head -1 | sed 's|^origin/||' || true)
 [ -n "$TARGET_BRANCH" ] || { echo "[create-mr] ⚠️ 无法探测默认分支（origin/main 或 origin/master）" >&2; exit 1; }
-# 3. 从 docs/08 § 二 提取 module_name
-MODULE_NAME=$(awk -v mid="$MODULE_ID" '
-  $0 ~ "^- "mid" " { sub("^- "mid" ", ""); print; exit }
-' docs/08-模块任务管理.md)
-[ -n "$MODULE_NAME" ] || { echo "[create-mr] ⚠️ docs/08 § 二 找不到模块 $MODULE_ID" >&2; exit 1; }
+# 3. 取 module_name
+if [ "$MODULE_ID" = "frontend-phase" ]; then
+  MODULE_NAME="前端阶段（整体）"
+else
+  # 从 docs/08 § 二 提取后端模块 module_name
+  MODULE_NAME=$(awk -v mid="$MODULE_ID" '
+    $0 ~ "^- "mid" " { sub("^- "mid" ", ""); print; exit }
+  ' docs/08-模块任务管理.md)
+  [ -n "$MODULE_NAME" ] || { echo "[create-mr] ⚠️ docs/08 § 二 找不到模块 $MODULE_ID" >&2; exit 1; }
+fi
 # 4. 从 test-gate evidence 提取 conclusion + subagent_id
 TEST_SUBAGENT_ID=$(awk '/^- 子会话: / { sub("^- 子会话: ", ""); print; exit }' "$TEST_GATE")
-## 模块完成报告
+## 完成报告
 见 `docs/superpowers/module-reports/{{date}}-{{module_id}}.md`（本 MR 仓库内完整贴入下方）。
@@ -10,9 +10,9 @@
 ## 本地闸门证据
-- test.sh: {{test_gate_conclusion}}（subagent: {{test_subagent_id}}）
+- 测试: {{test_gate_conclusion}}（subagent: {{test_subagent_id}}）
 ## 审核入口
-- 本 MR = 模块 `{{module_id}}` 的唯一人工介入点
-- Approve + Merge 后，下次用户运行 `/erp-workflow:coding-start` 时入口会自动扫描到 GitLab API `state=merged`，探测默认分支后 `git pull --ff-only` 同步并推进下一模块
+- 本 MR = `{{module_id}}` 的唯一人工介入点（后端模块 / 前端阶段共用）
+- Approve + Merge 后，下次用户运行 `/erp-workflow:coding-start` 时入口会自动扫描 GitLab API `state=merged`，探测默认分支后 `git pull --ff-only` 同步并推进下一模块（后端阶段）或宣告全部完成（前端阶段）
 ---
 name: test-gate
-description: MR 创建前的硬闸门。子会话跑 scripts/test.sh 全量测试，绿则进入 module-report，红则停下并按失败类型引导用户。
+description: MR 创建前的硬闸门。后端阶段子会话跑 scripts/test.sh，前端阶段跑前端测试命令；绿则进入 module-report，红则停下并按失败类型引导用户。
 user-invocable: false
-allowed-tools: Read Write Skill Agent Bash(git add *) Bash(git commit *)
+allowed-tools: Read Write Skill Agent Bash(git add *) Bash(git commit *) Bash(git branch *)
 ---
 **所有输出必须使用中文。**
 # test-gate
-模块所有 REQ 完成后的硬闸门：子会话跑 `./scripts/test.sh`（含本模块新增 + 已合并模块回归），按模板渲染证据并 commit 到 module 分支。绿色继续，红色停下，按失败类型给用户恢复路径。
+模块（后端阶段）或整个前端阶段所有功能完成后的硬闸门。按当前分支自动推断 `phase`：
+
+- `module-*` 分支 → `phase=backend`：子会话跑 `./scripts/test.sh`（含本模块新增 + 已合并模块回归）
+- `frontend-phase` 分支 → `phase=frontend`：子会话跑前端测试命令（vitest + playwright）
+
+按模板渲染证据并 commit 到当前分支。绿色继续，红色停下。
 ## 执行步骤
-1. 派发 Agent 子会话（general-purpose）运行 `./scripts/test.sh`，子会话只返回结构化 JSON（不输出描述文字）：
+### 步骤 0：推断 phase 与目标命令
+
+`git branch --show-current`：
+
+- `module-<id>` → `phase=backend`，`phase_id=<id>`，`command=./scripts/test.sh`
+- `frontend-phase` → `phase=frontend`，`phase_id=frontend-phase`；命令从 `docs/04-技术规范.md § 零 frontend.test_command` / `frontend.e2e_command` 拼接（缺失则 `pnpm test:ci && pnpm e2e:ci`）
+- 其它分支 → 硬停打印 `test-gate 仅在 module-* 或 frontend-phase 分支可调用，当前 <branch>`
+
+1. 派发 Agent 子会话（general-purpose）运行上述 `command`，子会话只返回结构化 JSON（不输出描述文字）：
    ```json
    {
-     "command": "./scripts/test.sh",
+     "command": "<command>",
      "exit_code": <int>,
      "passed": <int>,
      "failed": <int>,
      "stdout_excerpt": "<最后 30 行，含 FAIL 摘要>"
    }
    ```
-2. 按 `${CLAUDE_SKILL_DIR}/templates/test-gate-result-template.md` 渲染证据，写入 `docs/superpowers/module-reports/<module_id>-test-gate.md`。
-3. Commit evidence 到 module 分支（保证证据随 MR 合并进默认分支可审计）：
+2. 按 `${CLAUDE_SKILL_DIR}/templates/test-gate-result-template.md` 渲染证据，写入 `docs/superpowers/module-reports/<phase_id>-test-gate.md`（后端：`<module_id>-test-gate.md`；前端：`frontend-phase-test-gate.md`）。
+3. Commit evidence 到当前分支（保证证据随 MR 合并进默认分支可审计）：
    ```bash
-   git add docs/superpowers/module-reports/<module_id>-test-gate.md
-   git commit -m "chore(<module_id>): add local test-gate evidence"
+   git add docs/superpowers/module-reports/<phase_id>-test-gate.md
+   git commit -m "chore(<phase_id>): add local test-gate evidence"
    ```
 4. **`exit_code = 0`** → 调用 `Skill(module-report)`。
 5. **失败** → 打印以下横幅并停止，不调用下游 skill；不自动重试、不自动修复（失败分类需人工判断）：
    ```
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    [test-gate] ⚠️ 未通过
+    [test-gate] ⚠️ 未通过 (phase=<phase>)
     失败清单: <子会话 JSON 的 failed 摘要>
-    详细证据: docs/superpowers/module-reports/<module_id>-test-gate.md
+    详细证据: docs/superpowers/module-reports/<phase_id>-test-gate.md
     按失败类型选恢复路径：
     ① 测试脆弱（偶发 flakey）→ 重跑 /erp-workflow:coding-start
-       （module-start 幂等：reviews 已全 approve 会跳过功能循环，直接重跑本闸门）
-    ② 真有回归（某 REQ 破坏其它 REQ 或已合并模块）
-       → rm docs/superpowers/reviews/*-<REQ-id>.md
-       → 重跑 /erp-workflow:coding-start（module-start 视该 REQ 未完成，重走功能循环）
-    ③ 环境/依赖问题（DB 连不上 / 外部 API 失败 / 证书失效）
+       （module-start / frontend-start 幂等：reviews 已全 approve 会跳过功能循环，直接重跑本闸门）
+    ② 真有回归
+       后端：rm docs/superpowers/reviews/*-<REQ-id>.md
+            → 重跑 /erp-workflow:coding-start（module-start 视该 REQ 未完成，重走功能循环）
+       前端：rm docs/superpowers/reviews/*-FE-<NN>.md
+            → 重跑 /erp-workflow:coding-start（frontend-start 视该 FE 未完成，重走功能循环）
+    ③ 环境/依赖问题（DB 连不上 / 外部 API 失败 / 证书失效 / Playwright 浏览器未装）
        → Skill(interrupt-check) 追加 Blocker 到任一 plan 文件 → 修复环境 → 重跑
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    ```
 ## 护栏
-- **绝不**在主会话直接执行 `./scripts/test.sh`，必须通过子会话
+- **绝不**在主会话直接执行 `./scripts/test.sh` / `pnpm test` / `pnpm e2e`，必须通过子会话
 - **绝不**通过 `git push --no-verify` 绕过（hook `deny-no-verify.sh` 会硬拦）
 ## 参考
 - `${CLAUDE_SKILL_DIR}/templates/test-gate-result-template.md`
-- 上游：`module-start`（本模块 REQ 全 approve 后派发到此）
-- 下游：`module-report`（绿色时）
+- 上游：`module-start`（后端阶段 REQ 全 approve 后派发到此）；`frontend-start`（前端阶段 FE 全 approve 后派发到此）
+- 下游：`module-report`（绿色时；后端 + 前端共用，phase 由当前分支推断）
 ---
 name: coding-start
-description: B 阶段（Coding）入口。验证 Plan 已完成后派发到 module-start；模块定位、分支管理与远程同步全部由 module-start 负责。
+description: B 阶段（Coding）入口与阶段分发器。验证 Plan 完成后做后端 + 前端的完成性检查，每段检查后立即派发：后端未完成 → module-start（写后端）；后端已完成 + 前端未完成 → frontend-start（写前端）；都完成 → 全部完成。本 skill 只做分发，不做 prototype/ 门禁。
 user-invocable: true
-allowed-tools: Skill Read Glob Grep Bash(cat *)
+allowed-tools: Skill Read Glob Grep Bash(cat *) Bash(curl *) Bash(jq *)
 ---
 **所有输出必须使用中文。**
-B 阶段（Coding）的入口分发器。
+B 阶段（Coding）的入口分发器。**`module-start` 写后端，`frontend-start` 写前端**——coding-start 在每次入口时按"先后端、再前端"的次序检查并立即派发。本 skill **只做分发，不做 prototype/ 门禁**——前端阶段的前置检查由 `frontend-start` 内部承担。
+
+`module-start` 与 `frontend-start` 互不感知对方。
 ## 执行步骤
 ### 步骤 0：打印 B 阶段整体流程图
-每次入口都先展示总图，再做后续校验和派发：
-
 ```bash
 cat "${CLAUDE_PLUGIN_ROOT}/skills/crosscut/coding-start/banners/flow-overview.txt"
 ```
 ### 步骤 1：确认 docs/08 存在
-检查 `docs/08-模块任务管理.md`存在。
+检查 `docs/08-模块任务管理.md` 存在。
 - 不存在 → 打印"⚠️ 项目尚未初始化，请先运行 `/erp-workflow:plan-start`"并停下。
 ### 步骤 2：Plan 完成性检查
@@ -31,13 +31,30 @@ cat &quot;${CLAUDE_PLUGIN_ROOT}/skills/crosscut/coding-start/banners/flow-overview.tx
 - 任一未勾选 → 提示用户先运行 `/erp-workflow:plan-start` 完成 A 阶段，并停下
 - 全部勾选 → 进入步骤 3
-### 步骤 3：派发到 module-start
+### 步骤 3：后端完成性检查 + 派发
+
+读 `docs/08 § 二`，对每个后端模块的 `MR:` 字段：
+
+- **任一模块 `MR: —` 或 state ∈ {`opened`, `closed`}** → 后端未完成，打印 `[coding-start] 后端未完成 → 派发 module-start（写后端）`，立即用 Skill 工具调用 module-start，本 skill 结束，不进入步骤 4。
+
+- **所有模块 `MR: !<iid>` 且 state == `merged`**（用API检查）→ 后端已完成，进入步骤 4。
+
+### 步骤 4：前端完成性检查 + 派发
+
+读 `docs/08 § 三 整体 MR:` 字段：
+
+- **`MR: !<iid>` 且 state == `merged`**（用API检查）→ 前端已完成，打印 `所有阶段已完成（后端模块 + 前端阶段均已 merged）`，结束本 skill。
-打印一句 `[coding-start] → invoke module-start` 后立即用 `Skill` 工具调用 `module-start`。当前模块的定位、MR 状态、分支管理与 REQ 列表全部由 `module-start` 自行处理。
+- **`MR: —` 或 state ∈ {`opened`, `closed`}** → 前端未完成，打印 `[coding-start] 后端已完成、前端未完成 → 派发 frontend-start（写前端）`，立即用 Skill 工具调用 frontend-start，本 skill 结束。
 ## 参考
-- `docs/08-模块任务管理.md § 一`（A0~A5 进度勾选，本 skill 步骤 2 读取）
-- `module-start`（下游：模块定位 + REQ 列表 + 推进）
+- `docs/08-模块任务管理.md § 一`（A0~A5 进度勾选，步骤 2 读取）
+- `docs/08-模块任务管理.md § 二`（后端模块元数据 + MR 字段，步骤 3 读取）
+- `docs/08-模块任务管理.md § 三`（前端阶段整体 MR，步骤 4 读取）
+- `.env.local`（GitLab API 凭据，步骤 3 / 4 读取）
+- 下游：
+  - `module-start`（写后端：步骤 3 派发）
+  - `frontend-start`（写前端：步骤 4 派发）
 - `plan-start`（姊妹入口，A 阶段）
 - `CLAUDE.md`（项目指令）
 ┌────────────────────────────────────────────────────────┐
-│  🛠️   阶段 B：编码（按模块循环）                        │
+│  🛠️   阶段 B：编码（后端模块循环 → 前端整体阶段）      │
 │                                                        │
-│      coding-start                                      │
-│        （Plan 完成校验）                               │
-│          ↓                                             │
-│      module-start                                      │
-│        （定位当前模块 + 推进未完成 REQ）               │
-│          ↓                                             │
-│      ┌─ 功能循环（每个 REQ）─────────────┐             │
-│      │  feature-brainstorm               │             │
-│      │      ↓                            │             │
-│      │  feature-plan                     │             │
-│      │      ↓                            │             │
-│      │  feature-tdd                      │             │
-│      │      ↓                            │             │
-│      │  feature-verify                   │             │
-│      │      ↓                            │             │
-│      │  feature-review                   │             │
-│      │   ├ approve         → 回 module-start           │
-│      │   └ request-changes ↺ 重跑 verify               │
-│      │           （自修复 ≤5 轮）                      │
-│      └────────────────────────────────────┘            │
-│          ↓ （本模块所有 REQ approve）                  │
-│      test-gate （子会话跑 ./scripts/test.sh）          │
-│          ↓                                             │
-│      module-report （生成 12 节模块完成报告）          │
-│          ↓                                             │
-│      mr-create （push + 创建 GitLab MR）               │
-│          ↓                                             │
-│      停下，等待人工 Approve + Merge                     │
-│          ↺ 用户重跑 coding-start                       │
-│          ╰──→ 回到 module-start（下一模块）            │
+│      coding-start （只做分发）                         │
+│        ① Plan 完成校验（docs/08 § 一 A0~A5）           │
+│        ② 后端完成性检查（§ 二 + GitLab state）         │
+│            ├ 未完成 → 立即派发 module-start，结束      │
+│            └ 已完成 → 继续 ③                           │
+│        ③ 前端完成性检查（§ 三 整体 MR + state）        │
+│            ├ 已完成 → 打印"全部完成"，结束             │
+│            └ 未完成 → 派发 frontend-start，结束        │
+│                                                        │
+│   ┌────┴───────────────────────┐                       │
+│   ▼ 写后端                     ▼ 写前端                │
+│                                                        │
+│  module-start                  frontend-start          │
+│   切 module-<id> 分支           ① 检查 prototype        │
+│                                   缺失 → AskUserQuestion│
+│                                ② 准备 FE 清单           │
+│                                  § 三 已有 → 加载       │
+│                                  § 三 占位 → AI 推导写入│
+│                                  （无审阅断点）         │
+│                                ③ 切 frontend-phase 分支 │
+│                                                        │
+│  ┌─ 后端功能循环（每 REQ）────────┐                    │
+│  │  feature-brainstorm            │                    │
+│  │      ↓                         │                    │
+│  │  feature-plan                  │                    │
+│  │      ↓                         │                    │
+│  │  feature-tdd（路径硬护栏）     │                    │
+│  │      ↓                         │                    │
+│  │  feature-verify                │                    │
+│  │      ↓                         │                    │
+│  │  feature-review                │                    │
+│  │   ├ approve → 回 module-start  │                    │
+│  │   └ request-changes ↺ ≤5 轮    │                    │
+│  └────────────────────────────────┘                    │
+│      ↓ 本模块所有 REQ approve                          │
+│  test-gate（phase=backend）                            │
+│      ↓                                                 │
+│  module-report → mr-create                             │
+│      ↓ 停下，等人工 Approve + Merge                    │
+│      ↺ 用户重跑 coding-start → coding-start 再分发     │
+│                                                        │
+│  ┌─ 前端功能循环（每 FE-NN）─────┐                     │
+│  │  fe-feature-brainstorm        │                     │
+│  │      ↓                        │                     │
+│  │  fe-feature-plan              │                     │
+│  │      ↓                        │                     │
+│  │  fe-feature-tdd（jsdom + E2E）│                     │
+│  │      ↓                        │                     │
+│  │  fe-feature-verify            │                     │
+│  │      ↓                        │                     │
+│  │  fe-feature-review            │                     │
+│  │   （fe-code-reviewer agent）  │                     │
+│  │   ├ approve → 回 frontend-start                     │
+│  │   └ request-changes ↺ ≤5 轮   │                     │
+│  └───────────────────────────────┘                     │
+│      ↓ 全部 FE approve                                 │
+│  test-gate（phase=frontend）                           │
+│      ↓                                                 │
+│  module-report → mr-create                             │
+│        （分支 frontend-phase，docs/08 § 三 整体 MR）   │
+│      ↓ 停下，等人工 Approve + Merge                    │
+│      ↺ 用户重跑 coding-start → 全部完成                │
 └────────────────────────────────────────────────────────┘
 ---
 name: downstream-gen
-description: A5 ä¸‹æ¸¸æ–‡æ¡£ç”Ÿæˆâ€”â€”åŸºäºŽ docs/01 å’Œ docs/03 æŽ¨å¯¼ï¼Œä¸€æ¬¡æ€§ç”Ÿæˆ docs/02 + docs/05 + docs/06 Â§ äº” + docs/10ï¼Œå›žå¡« REQ å¡ç‰‡ä¾èµ–æŽ¥å£ï¼ŒæŠŠæ¨¡å—æ¸…å•è¿½åŠ åˆ° docs/08 Â§ äºŒã€‚
+description: A5 ä¸‹æ¸¸æ–‡æ¡£ç”Ÿæˆâ€”â€”åŸºäºŽ docs/01 å’Œ docs/03 æŽ¨å¯¼ï¼Œä¸€æ¬¡æ€§ç”Ÿæˆ docs/02 + docs/05 + docs/06 Â§ ä¸‰ + docs/10ï¼Œå›žå¡« REQ å¡ç‰‡ä¾èµ–æŽ¥å£ï¼ŒæŠŠæ¨¡å—æ¸…å•è¿½åŠ åˆ° docs/08 Â§ äºŒã€‚
 user-invocable: false
 allowed-tools: Read Write Edit Glob Grep Skill AskUserQuestion Bash(cat *) Bash(cp *)
 ---
@@ -60,10 +60,10 @@ cat &quot;${CLAUDE_PLUGIN_ROOT}/skills/plan/downstream-gen/banners/flow.txt&quot;
 ### C. docs/06 â€” é¡µé¢æ¸…å•
-å¯¹æ¯ä¸ªæœ‰å‰ç«¯é¡µé¢çš„æ¨¡å—ï¼šè¯»å–å¹¶å¡«å…… `${CLAUDE_SKILL_DIR}/templates/docs-06-module-pagelist-template.md`ï¼Œè¿½åŠ åˆ° `docs/06-UIäº¤äº’è§„èŒƒ.md` Â§ äº”ã€‚
+å¯¹æ¯ä¸ªæœ‰å‰ç«¯é¡µé¢çš„æ¨¡å—ï¼šè¯»å–å¹¶å¡«å…… `${CLAUDE_SKILL_DIR}/templates/docs-06-module-pagelist-template.md`ï¼Œè¿½åŠ åˆ° `docs/06-UIäº¤äº’è§„èŒƒ.md` Â§ ä¸‰ã€‚
 å®ŒæˆåŽï¼Œç”¨ `Edit` åœ¨ `docs/08-æ¨¡å—ä»»åŠ¡ç®¡ç†.md` ä¸å‹¾é€‰ï¼š
-- `  - [ ] docs/06 Â§ äº” é¡µé¢æ¸…å•å·²å¡«å…¥`
+- `  - [ ] docs/06 Â§ ä¸‰ é¡µé¢æ¸…å•å·²å¡«å…¥`
 ### D. docs/08 â€” è¿½åŠ æ¨¡å—æ¸…å•
@@ -151,7 +151,7 @@ cp &quot;${CLAUDE_SKILL_DIR}/templates/docs-10-header-template.md&quot; docs/10-éªŒæ”¶æ£€æ
 - `${CLAUDE_SKILL_DIR}/templates/docs-02-template.md`
 - `${CLAUDE_SKILL_DIR}/templates/docs-05-header-template.md`
 - `${CLAUDE_SKILL_DIR}/templates/docs-05-endpoint-template.md`
-- `${CLAUDE_SKILL_DIR}/templates/docs-06-module-pagelist-template.md`
+- `${CLAUDE_SKILL_DIR}/templates/docs-06-module-pagelist-template.md`ï¼ˆè¿½åŠ åˆ° docs/06 Â§ ä¸‰ï¼‰
 - `${CLAUDE_SKILL_DIR}/templates/docs-08-module-row-template.md`ï¼ˆæ¨¡å— bullet è¡Œæ¨¡æ¿ï¼‰
 - `${CLAUDE_SKILL_DIR}/templates/docs-10-header-template.md`
 - `${CLAUDE_SKILL_DIR}/scripts/derive-gitlab.sh`ï¼ˆ**ç”¨æˆ·å¯é€‰è¾…åŠ©**ï¼šåœ¨ add origin ä¹‹åŽæ‰‹åŠ¨è·‘ä¸€æ¬¡ï¼Œè‡ªåŠ¨æ´¾ç”Ÿ GITLAB_PROJECT_ID / GITLAB_API_URL å†™å…¥ .env.localï¼‰
@@ -20,5 +20,7 @@
 | {{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}}
@@ -13,32 +13,61 @@
 ---
-## 🔄 B 阶段开发流程（模块循环 + 功能循环）
+## 🔄 B 阶段开发流程（后端模块循环 → 前端整体阶段）
-两层嵌套循环**全部固化到 skills**。入口：`/erp-workflow:coding-start`。
+B 阶段分两段，**全部固化到 skills**。入口：`/erp-workflow:coding-start`。
-- **模块循环（外）**：`module-start` → `test-gate` → `module-report` → `mr-create` → 人工 Approve MR → 下一模块
+### 阶段路由（coding-start 内，只做分发）
+
+`coding-start` 每次入口做两段完成性检查后真值表派发：
+
+- 后端完成性检查 → `backend_done`（扫 docs/08 § 二 + GitLab state）
+- 前端完成性检查 → `frontend_done`（扫 docs/08 § 三 整体 MR + state）
+
+| `backend_done` | `frontend_done` | 派发 |
+|---|---|---|
+| `false` | 任意 | `module-start`（写后端） |
+| `true` | `false` | `frontend-start`（写前端） |
+| `true` | `true` | "所有阶段已完成" |
+
+前端阶段前置（prototype/ 门禁）由 `frontend-start` 自带，不在 coding-start。`module-start` 与 `frontend-start` **互不感知对方**。
+
+### 后端阶段（每模块一个 MR）
+
+- **模块循环（外）**：`module-start` → `test-gate(phase=backend)` → `module-report` → `mr-create` → 人工 Approve MR → 用户重跑 coding-start → coding-start 再次路由
 - **功能循环（内，每 REQ-XXX-NNN 一遍）**：`feature-brainstorm` → `feature-plan` → `feature-tdd` → `feature-verify` → `feature-review`
+- 后端阶段任务严格落在 `backend/` 路径下；docs/01 REQ 卡片的 UI 描述在此阶段忽略，UI 推迟到前端阶段。
+
+### 前端阶段（整体一个 MR，所有后端模块 merged 后启动）
+
+- **FE 清单（AI 自主推导，无审阅断点）**：`frontend-start` 进入时扫 prototype + docs/01 + docs/05 → AI 自主推导 FE 业务功能清单写入 `docs/08 § 三`（已有则加载）。**FE 是业务功能粒度，与 prototype HTML 文件数无关**——一个 HTML 可拆多个 FE，多个 HTML 也可合成一个 FE。FE 清单的合理性由 fe-feature-review / mr-create 在整体 MR 提交时一并校核（人工只在 MR Approve+Merge 处介入）。
+- **FE 循环（外）**：`frontend-start` → fe-feature 循环 → `test-gate(phase=frontend)` → `module-report(phase=frontend)` → `mr-create`（分支 `frontend-phase`，docs/08 § 三 整体 MR）。
+- **FE 功能循环（内，每个 FE-NN 一遍）**：`fe-feature-brainstorm` → `fe-feature-plan` → `fe-feature-tdd` → `fe-feature-verify` → `fe-feature-review`（专用 `fe-code-reviewer` agent，硬编码 7 维 review checklist）
+- 前端阶段任务严格落在 `frontend/` 路径下；布局以 `prototype/` 为权威。
-MR 前测试闸门： 
-   - `test-gate`（子会话跑 `scripts/test.sh` 全量——本模块所有 REQ + 已完成模块回归）；
-   - `.githooks/pre-push` 兜底
-   - `git push --no-verify` 被 `deny-no-verify.sh` 硬拦。
+### MR 前测试闸门
+
+- `test-gate`：后端阶段子会话跑 `scripts/test.sh`（含本模块新增 + 已合并模块回归）；前端阶段子会话跑 vitest + playwright。
+- `.githooks/pre-push` 兜底；`git push --no-verify` 被 `deny-no-verify.sh` 硬拦。
 ---
-## ✅ 模块完成判定规则
+## ✅ 阶段完成判定规则
+
+`docs/08-模块任务管理.md` 分两段：
+- `§ 二`：后端模块元数据表（每个模块一行 bullet，记录依赖 / 路径 / MR iid / 功能子项）
+- `§ 三`：前端阶段元数据（整体 MR + FE 子项清单，由 `frontend-start` 在所有后端模块 merged 后填入）
-`docs/08-模块任务管理.md § 二` 是**模块元数据表**——每个模块记录依赖 / 路径 / MR iid / 功能（REQ）子项清单。**模块完成由 `MR:` 字段 + `GitLab API state=merged` 判定**；功能子项勾选只作可视化进度，不参与模块完成判定。
+**阶段完成判定**统一以 `MR:` 字段（§ 二 各模块） / `整体 MR:` 字段（§ 三）+ `GitLab API state=merged` 判定；子项勾选只作可视化进度，不参与完成判定。
-### 规则定义
+### 后端模块格式
-每个模块在 docs/08 § 二 中长这样：
+每个后端模块在 docs/08 § 二 中长这样：
 ```markdown
 - module_0 系统管理
   - 依赖: —
-  - 路径: backend/module/sys/, frontend/pages/sys/
+  - 路径: backend/module/sys/
   - MR: —
   - 功能:
     - [ ] REQ-SYS-001 用户登录
@@ -46,16 +75,30 @@ MR 前测试闸门：
 ```
 - `MR:` 字段由 `mr-create` 在创建 MR 时从 `—` 改为 `!<iid>`。
-- 每个 `REQ-*` 子项由 `feature-review` 在 `verdict=approve` 时自动勾选为 `[x]`
-- 子项全部勾选不等于模块完成，模块完成判定仍以 `MR:` + GitLab API state 为准。
+- 每个 `REQ-*` 子项由 `feature-review` 在 `verdict=approve` 时自动勾选为 `[x]`。
+- 路径限定为后端目录（如 `backend/module/sys/`）；前端代码不在此阶段产生。
+
+### 前端阶段格式（§ 三）
+
+```markdown
+- 整体 MR: —
+- 功能:
+  - [ ] FE-01 用户登录与注册 ｜ 关联 REQ：REQ-SYS-001, REQ-SYS-002 ｜ 关联原型：prototype/auth.html
+  - [ ] FE-02 仪表盘总览 ｜ 关联 REQ：REQ-DASH-001 ｜ 关联原型：prototype/dashboard.html
+```
+
+- `整体 MR:` 字段由 `mr-create` 在创建前端 MR 时从 `—` 改为 `!<iid>`。
+- "功能:" 列表由 `frontend-start` 进入时由 AI 自主推导写入（无人工审阅断点）。FE 是业务功能粒度，与 prototype HTML 文件数无关；合理性由 fe-feature-review / 整体 MR 时统一校核。
+- 每个 `FE-NN` 子项由 `fe-feature-review` 在 `verdict=approve` 时自动勾选为 `[x]`。
+- 进入前端阶段前 `frontend-start` 步骤 1 自带 prototype/ 门禁，强制检查项目根 `prototype/` 至少含 1 个 `*.html` mockup。
-### 模块状态语义
+### 状态语义（后端模块 + 前端阶段共用）
 | `MR:` 字段 | `GitLab API state` | 含义 | 你（Claude Code）的行为 |
 |---|---|---|---|
-| `—` | — | 模块未开始（未创建 MR） | ✅ 开始本模块开发 |
-| `!<iid>` | `opened` / `closed` | 模块开发中 / 打回 | ✅ 继续推进该模块 |
-| `!<iid>` | `merged` | 模块**已完成** | 🟢 进入下一未完成模块 |
+| `—` | — | 该阶段未开始（未创建 MR） | ✅ 开始该阶段开发 |
+| `!<iid>` | `opened` / `closed` | 阶段开发中 / 打回 | ✅ 继续推进该阶段 |
+| `!<iid>` | `merged` | 阶段**已完成** | 🟢 后端：进入下一未完成模块；后端全完 → 前端阶段；前端 merged → 全部完成 |
 ### 模块完成报告
@@ -90,7 +133,7 @@ MR 前测试闸门：
 ### 你禁止做的 🚫
 1. **主会话直接 `mysql -e` 跑业务 DDL**（只读查询 / 临时本地调试除外）——业务 schema 必须走 `sql/migrations/V_n__*.sql`，详见下方 Schema 演化规约
-2. **手动 Edit `docs/08 § 二` 的 `MR:` 字段**，必须要由 `mr-create` 自动回写
+2. **手动 Edit `docs/08 § 二/§ 三` 的 `MR:` / `整体 MR:` 字段**，必须要由 `mr-create` 自动回写
 ### Schema 演化规约（Flyway migration）
@@ -36,21 +36,35 @@
 - [ ] A5 下游文档生成 — downstream-gen
   - [ ] docs/02 开发计划已生成
   - [ ] docs/05 API 契约已生成
-  - [ ] docs/06 § 五 页面清单已填入
+  - [ ] docs/06 § 三 页面清单已填入
   - [ ] docs/10 验收清单已生成
   - [ ] 下方模块列表已填入
   - [ ] REQ 卡片依赖接口已回填
-## 二、Coding 阶段（按模块循环）
+## 二、Coding 阶段（后端模块循环）
-（A5 填入后，每行一个模块。每个模块的 `MR:` 字段在 `—` 和 `!<iid>` 之间变化，完成由 GitLab API `state=merged` 判定。`coding-start` 每次按 docs/02 REQ 序扫每模块的 MR state 决定派发。）
+（A5 填入后，每行一个后端模块。每个模块的 `MR:` 字段在 `—` 和 `!<iid>` 之间变化，完成由 GitLab API `state=merged` 判定。`coding-start` 每次按 docs/02 REQ 序扫每模块的 MR state 决定派发。后端模块全部 merged 后自动进入 § 三 前端阶段。）
 <!-- 模块格式示例（由 A5 downstream-gen 追加；功能子项由 feature-review 在 approve 时勾选）：
 - module_0 系统管理
   - 依赖: —
-  - 路径: backend/module/sys/, frontend/pages/sys/
+  - 路径: backend/module/sys/
   - MR: —
   - 功能:
     - [ ] REQ-SYS-001 用户登录
     - [ ] REQ-SYS-002 用户注册
 -->
+
+## 三、Coding 阶段（前端整体）
+
+（`frontend-start` 进入时扫 prototype/ + docs/01 + docs/05 → AI 自主推导 FE 业务功能清单写到下方"功能:"项（无人工审阅断点；合理性由整体 MR 时统一校核）。已有清单则直接加载。整个前端阶段 1 个 MR，分支 `frontend-phase`。）
+
+- 整体 MR: —
+- 功能:
+  <!-- AI 进入时按以下行格式写入（每行 1 个 FE，可关联多个 REQ / 多份原型）：
+  - [ ] FE-NN 功能名 ｜ 关联 REQ：REQ-A, REQ-B ｜ 关联原型：prototype/<file>.html, prototype/<other>.html
+
+  示例：
+  - [ ] FE-01 用户登录与注册 ｜ 关联 REQ：REQ-SYS-001, REQ-SYS-002 ｜ 关联原型：prototype/auth.html
+  - [ ] FE-02 仪表盘总览 ｜ 关联 REQ：REQ-DASH-001 ｜ 关联原型：prototype/dashboard.html
+  -->
 <!--
-本文件是 docs/06-UI交互规范.md 的 § 一~四 大纲（§ 五由 downstream-gen 追加）。
+本文件是 docs/06-UI交互规范.md 的 § 一~二 大纲（§ 三由 downstream-gen 追加）。
 skeleton-gen 读取 docs/04 § 零 和 docs/01 index，按下述大纲生成项目专属内容。
-UI 细节（布局参数、颜色、组件选型）来自 § 零 前端 UI 组件库。
+布局/页面骨架以项目根的 prototype/ 静态 HTML mockup 为权威，本文件仅承载跨页面通用规则与 Design Tokens。
 -->
 # 06-UI交互规范
-## 一、整体布局
+> 本项目所有页面布局以项目根 `prototype/` 目录下的静态 HTML mockup 为权威。前端阶段（fe-feature-*）实现时直接以 prototype/ HTML 推导组件树与样式。本文件仅承载跨页面通用规则与 Design Tokens。
-### 1.1 页面框架
-<!-- 基于 § 零 UI 组件库（如 Ant Design Layout）描述整体骨架：Header / Sider / Content。 -->
+## 一、通用交互规则
-### 1.2 布局参数
-<!-- 表格形式：Header 高度 / Sidebar 宽度 / 内边距 / 最小分辨率，给出默认值。 -->
-
-## 二、标准页面类型
-<!-- 根据 docs/01 index 的模块索引推断业务可能出现的页面类型（通常列表/表单/详情/树形 4 类，根据项目裁剪）。 -->
-
-### 2.1 列表页
-<!-- 顶部操作区 + 搜索栏 + 表格 + 分页，关键组件选型。 -->
-
-### 2.2 表单页
-<!-- Drawer 还是独立页；校验时机；提交按钮位置。 -->
-
-### 2.3 详情页
-<!-- Descriptions + Tabs 的组合方式。 -->
-
-### 2.4 树形管理页
-<!-- 如项目有组织架构/权限树/分类树才生成此节，否则删除。 -->
-
-## 三、通用交互规则
-
-### 3.1 操作反馈
+### 1.1 操作反馈
 <!-- 成功/失败消息；危险操作二次确认；长耗时按钮 loading 态。 -->
-### 3.2 数据展示
+### 1.2 数据展示
 <!-- 空状态 / 加载 / 异常 的统一组件与文案。 -->
-### 3.3 权限控制（前端）
+### 1.3 权限控制（前端）
 <!-- 菜单级 / 按钮级 / 路由级的控制方式，关联后端 RBAC。 -->
-## 四、Design Tokens
+## 二、Design Tokens
 <!-- 所有色值统一以 CSS 变量定义于 src/styles/tokens.css；命名规范见 docs/04 § 2.5。 -->
-### 4.1 全局调色板
+### 2.1 全局调色板
 <!-- 与 § 零 UI 库主题对齐：列名 = 语义 / 变量名 / 默认值 / 用途。
      至少含：主色/成功/警告/错误/主文字/次文字/边框/背景。 -->
-### 4.2 组件级状态色
+### 2.2 组件级状态色
 <!-- 场景 × 状态映射表：列名 = 序号 / 组件 / 编辑bg / 只读bg / 悬浮bg / 编辑fg / 只读fg / 悬浮fg / 备注。
      单元格写 token 名（var(--color-xxx) 形式），不写 hex；"—" 表示该状态不适用。
      表后追加「Token 默认值」表，列出每个 --color-xxx 在 tokens.css 的默认值。 -->
-### 4.3 引用约定
+### 2.3 引用约定
 <!-- 一句话三条：
      - 组件样式只用 var(--color-xxx)，禁止硬编码
-     - 新增 token 须先登记到 § 4.1/4.2 再补 tokens.css
+     - 新增 token 须先登记到 § 2.1/2.2 再补 tokens.css
      - 修改色值只改 tokens.css 一处，不允许组件覆盖 -->
-## 五、页面清单
+## 三、页面清单
 （由 `downstream-gen` 按模块追加段落）