完善 AGENTS 编排流程与阶段规则

补充 plan→backend→frontend→reviewer→qa→commit 六阶段流转、交接物与并行规则。

AGENTS.md

@@ -110,11 +110,62 @@ E2E loop = plan → issues(csv) → 方案批准 → implement → test → revi
 - **工具**：仅限 PostgreSQL MCP 只读查询（参考 `docs/mcp-tools.md`）
 - **禁止**：不得执行 INSERT/UPDATE/DELETE，不得修改任何文件
 
-### 并行与派工规则
+### 编排流程
+
+主 agent（orchestrator）自动按以下阶段流转，人类只需给需求、批准方案、验收结果。
+
+```
+阶段 1: plan（主 agent 执行）
+  输入：人类的需求描述
+  输出：实现方案 + Issue CSV 草稿
+  交接物：方案文本 + CSV 文件路径
+  → 等待人类批准后进入阶段 2
+
+阶段 2: backend（启动 backend worker 子 agent）
+  触发条件：Issue CSV 的 Files 包含 server/ 路径
+  输入：已批准的方案 + Issue CSV + 相关代码上下文
+  输出：server/ 代码变更 + 单测 + post-check 通过
+  交接物：变更文件列表 + 测试结果 + API 契约描述
+  跳过条件：Files 不含 server/ → 直接进阶段 3
+
+阶段 3: frontend（启动 frontend worker 子 agent）
+  触发条件：Issue CSV 的 Files 包含 client/ 路径
+  输入：已批准的方案 + Issue CSV + 后端 API 契约（来自阶段 2 交接物）
+  输出：client/ 代码变更 + typecheck + build 通过
+  交接物：变更文件列表 + 构建结果
+  跳过条件：Files 不含 client/ → 直接进阶段 4
+
+阶段 4: reviewer（按需，启动 reviewer 子 agent）
+  触发条件：Issue 涉及权限模型、状态机、workflow、数据迁移、审批规则
+  输入：完整 diff + Issue CSV + 方案
+  输出：review 意见（不修改代码）
+  跳过条件：不涉及上述领域 → 直接进阶段 5
+  注意：高风险改动在实现后立即 review，不等 QA 跑完再回头，避免 reviewer 提意见后返工再重跑 QA
+
+阶段 5: qa（启动 qa worker 子 agent）
+  触发条件：存在 Dev_Status=DONE 且 Regression_Status≠DONE 的条目
+  输入：Issue CSV + Test_Method + 变更文件列表 + reviewer 意见（如有）
+  输出：逐条验证结果 + CSV 状态回填
+  交接物：回归报告 + 更新后的 CSV
+
+阶段 6: commit（主 agent 执行）
+  输入：所有阶段的验证结果
+  输出：git commit + CSV 最终状态回填
+  → 报告给人类，等待下一个需求
+```
+
+### 编排规则
+- 主 agent 负责阶段流转判断，不需要人类手动切换角色
+- 每个子 agent 启动时，主 agent 传入该角色的约束（作用域、禁止项、post-check）和本次任务的具体上下文
+- 子 agent 完成后，主 agent 检查交接物是否齐全，再决定进入下一阶段还是回退修复
+- 如果子 agent 的 post-check 失败，主 agent 在同一角色内重试修复，不跳到下一阶段
+- 单个 Issue 若 plan→implement→test 强依赖同一上下文（如调试跨前后端 bug），不拆子 agent，留在主会话
+
+### 并行规则
 - 最多并行 2 个实现 worker（backend + frontend），第 3 个只能是 qa 或只读研究
 - 跨前后端 Issue：先 backend 定 API/数据契约 → 再 frontend 接入
-- 单个 Issue 若 plan→implement→test 强依赖同一上下文，不拆 agent，留在主会话
 - QA 可与下一轮 plan 并行
+- 并行仅在多个 Issue 互不依赖且文件无交叉时启用
 
 ### Test_Method 内容要求
 Issue CSV 的 `Test_Method` 字段必须包含：