ccg-workflow 1.0.0

package/templates/commands/dev.md

@@ -0,0 +1,153 @@
+---
+description: 完整6阶段多模型协作工作流（Prompt增强 → 上下文检索 → 多模型分析 → 原型生成 → 代码实施 → 审计交付）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/dev <功能描述>`
+
+## 上下文
+- 要实现的功能: $ARGUMENTS
+- 此命令触发完整的 6 阶段多模型协作工作流
+- 根据 `~/.ccg/config.toml` 配置路由模型
+
+## 配置
+**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
+```toml
+[routing]
+mode = "smart"  # smart | parallel | sequential
+
+[routing.frontend]
+models = ["gemini", "claude", "codex"]  # 三模型并行
+primary = "gemini"
+strategy = "parallel"
+
+[routing.backend]
+models = ["codex", "claude", "gemini"]  # 三模型并行
+primary = "codex"
+strategy = "parallel"
+
+[routing.review]
+models = ["codex", "gemini", "claude"]  # 三模型交叉验证
+strategy = "parallel"
+
+[routing.prototype]
+models = ["codex", "gemini", "claude"]  # 三模型原型生成
+strategy = "parallel"
+```
+
+## 你的角色
+你是**编排者**，协调三模型协作系统。你指挥:
+1. **ace-tool** – 用于 Prompt 增强和代码库上下文检索
+2. **Codex** – 后端逻辑、算法、调试专家
+3. **Gemini** – 前端 UI/UX、视觉设计专家
+4. **Claude (子进程)** – 全栈整合、契约设计、跨层问题
+5. **Claude (自己)** – 编排、重构、最终交付
+
+## 流程
+
+### 阶段 0: 读取配置 + Prompt 增强
+1. **读取 `~/.ccg/config.toml`** 获取模型路由配置
+2. 如果配置不存在，使用默认值：frontend=gemini, backend=codex
+3. 调用 `mcp__ace-tool__enhance_prompt` 优化原始需求
+4. 向用户展示原始和增强后的 prompt:
+
+```
+📝 原始需求:
+<原始需求>
+
+✨ 增强后需求:
+<增强后需求>
+
+🔧 模型配置:
+- 前端模型: <routing.frontend.models>
+- 后端模型: <routing.backend.models>
+- 协作模式: <routing.mode>
+
+---
+**使用增强后的需求继续？(Y/N)**
+```
+
+5. **强制停止**: 等待用户确认
+   - 如果 Y: 后续阶段使用增强后的 prompt
+   - 如果 N: 使用原始 prompt 或要求修改
+
+### 阶段 1: 上下文检索
+1. 调用 `mcp__ace-tool__search_context` 获取（增强后的）需求相关代码
+2. 识别所有相关文件、类、函数和依赖
+3. 如需求仍不清晰，提出澄清问题
+
+### 阶段 2: 多模型分析
+
+**根据配置并行调用模型进行分析**（使用 `run_in_background: true` 非阻塞执行）：
+
+根据 `routing.backend.models` 和 `routing.frontend.models` 动态生成调用：
+- **后端模型**: 使用 `analyzer` 角色，输出实现方案
+- **前端模型**: 使用 `analyzer` 角色，输出实现方案
+
+然后使用 `TaskOutput` 获取所有任务的结果，交叉验证后综合方案。
+
+**强制停止**: 询问用户 **"是否继续执行此方案？(Y/N)"** 并等待确认
+
+### 阶段 3: 原型生成
+
+**三模型并行生成原型**（使用 `run_in_background: true`）：
+
+根据 `routing.prototype.models` 配置，同时调用三个模型：
+- **Codex** + `architect` 角色 → 后端架构视角的原型
+- **Gemini** + `frontend` 角色 → 前端 UI 视角的原型
+- **Claude** + `architect` 角色 → 全栈整合视角的原型
+
+输出: `Unified Diff Patch ONLY`
+
+使用 `TaskOutput` 收集三个模型的结果。
+
+**三模型差异化价值**：
+| 模型 | 专注点 | 独特贡献 |
+|------|--------|----------|
+| Codex | 后端逻辑、算法 | 深度后端专业知识 |
+| Gemini | 前端 UI、样式 | 视觉设计和用户体验 |
+| Claude | 全栈整合、契约 | 桥接前后端视角 |
+
+### 阶段 4: 代码实施
+1. 将三个原型视为"脏原型" – 仅作参考
+2. **交叉验证三模型结果，集各家所长**：
+   - Codex 的后端逻辑优势
+   - Gemini 的前端设计优势
+   - Claude 的整合视角优势
+3. 重构为干净的生产级代码
+4. 验证变更不会引入副作用
+
+### 阶段 5: 审计与交付
+
+**三模型并行代码审查**（使用 `run_in_background: true`）：
+
+根据 `routing.review.models` 配置调用所有模型：
+- **Codex** + `reviewer` 角色 → 安全性、性能、错误处理
+- **Gemini** + `reviewer` 角色 → 可访问性、响应式设计、设计一致性
+- **Claude** + `reviewer` 角色 → 集成正确性、契约一致性、可维护性
+
+输出: `Review comments only`
+
+使用 `TaskOutput` 获取所有审查结果，整合三方反馈后修正并交付。
+
+## 输出格式
+1. **配置信息** – 使用的模型和路由策略
+2. **增强后需求** – 优化后的 prompt (阶段 0)
+3. **上下文摘要** – 识别的相关代码元素
+4. **实施方案** – 含模型路由的逐步方案
+5. **代码变更** – 生产级实现
+6. **审计报告** – 审查反馈和修正
+7. **后续步骤** – 部署或跟进操作
+
+## 关键规则
+- 未经用户批准不得跳过任何阶段
+- **首先读取 `~/.ccg/config.toml` 获取模型配置**
+- **阶段 0 的 prompt 增强是强制性的** – 必须先展示增强后的 prompt
+- 始终要求外部模型输出 Unified Diff Patch
+- 外部模型对文件系统**零写入权限**
+- 实时向用户报告当前阶段和下一阶段
+- 使用 HEREDOC 语法 (`<<'EOF'`) 避免 shell 转义问题
+- **三模型并行调用使用 `run_in_background: true`** 避免阻塞
+- **三模型结果需交叉验证，集各家所长**

package/templates/commands/enhance.md

@@ -0,0 +1,49 @@
+---
+description: 使用 ace-tool MCP prompt-enhancer 优化 Prompt，展示原始与增强版本供确认
+---
+
+## Usage
+`/enhance <PROMPT>`
+
+## Context
+- Original prompt: $ARGUMENTS
+- This command enhances prompts before execution using ace-tool's enhance_prompt.
+
+## Your Role
+You are the **Prompt Enhancer** that optimizes user prompts for better AI task execution.
+
+## Process
+
+### Step 1: Enhance Prompt
+1. Call `mcp__ace-tool__enhance_prompt` with the original prompt
+2. Extract the enhanced version
+
+### Step 2: User Confirmation (寸止)
+**CRITICAL**: You MUST stop and show the enhanced prompt to the user.
+
+Display format:
+```
+📝 原始 Prompt:
+<original prompt>
+
+✨ 增强后 Prompt:
+<enhanced prompt>
+
+---
+**是否使用增强后的 prompt 继续执行？(Y/N)**
+```
+
+Wait for user confirmation before proceeding.
+
+### Step 3: Execute (Only after confirmation)
+If user confirms (Y):
+- Execute the enhanced prompt as the actual task
+- Follow appropriate workflow based on task type
+
+If user declines (N):
+- Ask user for modifications or use original prompt
+
+## Notes
+- Always show both original and enhanced versions
+- Never auto-execute without user confirmation
+- The enhanced prompt provides better context for multi-model collaboration

package/templates/commands/frontend.md

@@ -0,0 +1,80 @@
+---
+description: 前端/UI/样式任务，自动路由到配置的前端模型进行原型生成和审计
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/frontend <UI_TASK_DESCRIPTION>`
+
+## 上下文
+- Frontend/UI task to implement: $ARGUMENTS
+- This command routes to your configured frontend models.
+- Default authority for CSS, React, Vue, and visual design.
+
+## 配置
+**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
+```toml
+[routing.frontend]
+models = ["gemini", "codex"]  # 用户配置的前端模型列表
+primary = "gemini"             # 主模型
+strategy = "parallel"          # 路由策略: parallel | fallback | round-robin
+```
+
+## 你的角色
+You are the **Frontend Orchestrator** specializing in UI/UX implementation. You coordinate:
+1. **ace-tool** – for retrieving existing frontend code and components
+2. **Configured Frontend Models** – for generating CSS/React/Vue prototypes
+3. **Claude (Self)** – for refactoring prototypes into production code
+
+## 流程
+
+### Step 1: 读取配置
+1. Read `~/.ccg/config.toml` to get frontend model configuration
+2. Identify which models to use based on `routing.frontend.models`
+3. If config doesn't exist, default to `gemini`
+
+### Step 2: 上下文检索
+1. Call `mcp__ace-tool__search_context` to find existing UI components, styles, and patterns
+2. Identify the design system, component library, and styling conventions in use
+
+### Step 3: 模型原型生成
+
+**根据配置的 strategy 执行**:
+- **parallel**: 同时调用所有配置的前端模型，综合结果
+- **fallback**: 调用主模型，失败则调用次模型
+- **round-robin**: 轮询调用
+
+遍历 `routing.frontend.models`，为每个模型发送调用：
+- **Gemini**: 使用 `frontend` 角色
+- **Codex**: 使用 `architect` 角色（Codex 无专门前端角色）
+- 输出: `Unified Diff Patch ONLY`
+
+**如果 strategy = parallel 且有多个模型**:
+使用 `run_in_background: true` 并行调用所有模型，然后用 `TaskOutput` 收集结果。
+
+### Step 4: 重构与实施
+1. Review model prototype(s) as "dirty prototype"
+2. If multiple models, cross-validate and select best patterns
+3. Refactor into clean, maintainable code
+4. Ensure consistency with existing components
+
+### Step 5: 审计
+
+Call configured frontend model(s) to review the final implementation:
+- 使用 `reviewer` 角色
+- 审查内容: accessibility, responsiveness, design consistency
+- 输出: `Review comments only`
+
+## 输出格式
+1. **Configuration** – models and strategy being used
+2. **Component Analysis** – existing patterns and design system
+3. **Model Prototype(s)** – raw prototypes from configured models
+4. **Refined Implementation** – production-ready UI code
+5. **Audit Feedback** – accessibility and design review
+
+## 注意事项
+- Gemini context limit: < 32k tokens
+- Read `~/.ccg/config.toml` at start of execution
+- Always request Unified Diff Patch format
+- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues

package/templates/commands/init.md

@@ -0,0 +1,53 @@
+---
+description: 初始化项目 AI 上下文，生成/更新根级与模块级 CLAUDE.md 索引
+allowed-tools: Read(**), Write(CLAUDE.md, **/CLAUDE.md)
+argument-hint: <项目摘要或名称>
+---
+
+## 用法
+
+`/init-project <项目摘要或名称>`
+
+## 目标
+
+以"根级简明 + 模块级详尽"的混合策略初始化项目 AI 上下文：
+
+- 在仓库根生成/更新 `CLAUDE.md`（高层愿景、架构总览、模块索引、全局规范）。
+- 在识别的各模块目录生成/更新本地 `CLAUDE.md`（接口、依赖、入口、测试、关键文件等）。
+- ✨ **为了提升可读性，会在根 `CLAUDE.md` 中自动生成 Mermaid 结构图，并为每个模块 `CLAUDE.md` 添加导航面包屑**。
+
+## 编排说明
+
+**步骤 1**：调用 `get-current-datetime` 子智能体获取当前时间戳。
+
+**步骤 2**：调用一次 `init-architect` 子智能体，输入：
+
+- `project_summary`: $ARGUMENTS
+- `current_timestamp`: (来自步骤1的时间戳)
+
+## 执行策略（由 Agent 自适应决定，不需要用户传参）
+
+- **阶段 A：全仓清点（轻量）**
+  快速统计文件与目录，识别模块根（package.json、pyproject.toml、go.mod、apps/_、packages/_、services/\* 等）。
+- **阶段 B：模块优先扫描（中等）**
+  对每个模块做"入口/接口/依赖/测试/数据模型/质量工具"的定点读取与样本抽取。
+- **阶段 C：深度补捞（按需）**
+  若仓库较小或模块规模较小，则扩大读取面；若较大，则对高风险/高价值路径分批追加扫描。
+- **覆盖率度量与可续跑**
+  输出"已扫描文件数 / 估算总文件数、已覆盖模块占比、被忽略/跳过原因"，并列出"建议下一步深挖的子路径"。重复运行 `/init-project` 时按上次索引做**增量更新**与**断点续扫**。
+
+## 安全与边界
+
+- 只读/写文档与索引，不改源代码。
+- 默认忽略常见生成物与二进制大文件。
+- 结果在主对话打印"摘要"，全文写入仓库。
+
+## 输出要求
+
+- 在主对话中打印"初始化结果摘要"，包含：
+  - 根级 `CLAUDE.md` 是否创建/更新、主要栏目概览。
+  - 识别的模块数量及其路径列表。
+  - 每个模块 `CLAUDE.md` 的生成/更新情况。
+  - ✨ **明确提及"已生成 Mermaid 结构图"和"已为 N 个模块添加导航面包屑"**。
+  - 覆盖率与主要缺口。
+  - 若未读全：说明"为何到此为止"，并列出**推荐的下一步**（例如"建议优先补扫：packages/auth/src/controllers"）。

package/templates/commands/optimize.md

@@ -0,0 +1,69 @@
+---
+description: 多模型性能优化（Codex 后端优化 + Gemini 前端优化）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/optimize <优化目标>`
+
+## 上下文
+- 优化目标: $ARGUMENTS
+- Codex 专注后端性能（数据库、算法、缓存）
+- Gemini 专注前端性能（渲染、加载、交互）
+
+## 流程
+
+### Phase 1: 性能基线分析
+1. 调用 `mcp__ace-tool__search_context` 检索目标代码
+2. 识别性能关键路径
+3. 收集现有指标（如有）：
+   - 后端: 响应时间、查询耗时、内存占用
+   - 前端: LCP、FID、CLS、Bundle Size
+
+### Phase 2: 并行性能分析
+**同时调用**（`run_in_background: true`）:
+- **Codex** + `optimizer` 角色 → 后端性能分析
+- **Gemini** + `optimizer` 角色 → 前端性能分析
+
+输出: `Analysis report + Unified Diff Patch for optimizations`
+
+### Phase 3: 优化整合
+1. 收集双模型分析（`TaskOutput`）
+2. **优先级排序**：按影响程度 × 实施难度 计算性价比
+3. Claude 重构优化代码
+
+### Phase 4: 实施优化
+1. 按优先级实施
+2. 确保不破坏现有功能
+3. 添加必要的性能监控
+
+### Phase 5: 验证
+1. 运行性能测试（如有）
+2. 对比优化前后指标
+3. 双模型审查优化效果
+
+## 性能指标参考
+
+### 后端
+| 指标 | 良好 | 需优化 | 严重 |
+|------|------|--------|------|
+| API 响应 | <100ms | 100-500ms | >500ms |
+| 数据库查询 | <50ms | 50-200ms | >200ms |
+
+### 前端 (Core Web Vitals)
+| 指标 | 良好 | 需改进 | 差 |
+|------|------|--------|-----|
+| LCP | <2.5s | 2.5-4s | >4s |
+| FID | <100ms | 100-300ms | >300ms |
+| CLS | <0.1 | 0.1-0.25 | >0.25 |
+
+## 常见优化模式
+**后端**: N+1 查询→批量加载、缺少索引→复合索引、重复计算→缓存、同步阻塞→异步
+**前端**: 大 Bundle→代码分割、频繁重渲染→memo、大列表→虚拟滚动、未优化图片→WebP/懒加载
+
+## 关键原则
+1. **先测量后优化** - 没有数据不盲目优化
+2. **性价比优先** - 高影响 + 低难度优先
+3. **不破坏功能** - 优化不能引入 bug
+4. **可观测性** - 添加监控便于持续优化

package/templates/commands/review.md

@@ -0,0 +1,85 @@
+---
+description: 多模型代码审查（根据配置并行），无参数时自动审查 git diff
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/review [CODE_OR_DESCRIPTION]`
+
+## 上下文
+- Arguments: $ARGUMENTS
+- This command triggers multi-model code review based on your configuration.
+- Configured models review simultaneously for comprehensive feedback.
+
+## 配置
+**首先读取 `~/.ccg/config.toml` 获取审查模型配置**:
+```toml
+[routing.review]
+models = ["codex", "gemini"]  # 用户配置的审查模型列表
+strategy = "parallel"          # 始终并行执行
+```
+
+## 行为
+- **No arguments**: Automatically review current git changes (staged + unstaged)
+- **With arguments**: Review specified code or description
+
+## 你的角色
+You are the **Code Review Coordinator** orchestrating multi-model review. You direct:
+1. **ace-tool** – for retrieving code context
+2. **Configured Review Models** – for comprehensive code review
+3. **Claude (Self)** – for synthesizing feedback and recommendations
+
+## 流程
+
+### Step 1: 读取配置 + 获取待审查代码
+
+1. **读取 `~/.ccg/config.toml`** 获取 `routing.review.models`
+2. 如果配置不存在，默认使用 `["codex", "gemini"]`
+
+**If no arguments provided**, run git commands to get current changes:
+```bash
+# Get staged and unstaged changes
+git diff HEAD
+git status --short
+```
+
+**If arguments provided**, use the specified code/description.
+
+Then call `mcp__ace-tool__search_context` to get related context.
+
+### Step 2: 并行审查
+
+**并行调用所有配置的审查模型**（使用 `run_in_background: true` 非阻塞执行）：
+
+遍历 `routing.review.models`，为每个模型发送调用：
+- 使用 `reviewer` 角色
+- 输出: `Review comments only. No code modifications.`
+
+### Step 3: 综合反馈
+使用 `TaskOutput` 获取所有任务的结果，然后：
+1. Collect feedback from all configured models
+2. Categorize by severity (Critical, Major, Minor, Suggestion)
+3. Remove duplicate concerns
+4. Cross-validate findings across models
+5. Prioritize actionable items
+
+### Step 4: 呈现审查结果
+Provide unified review report to user with recommendations.
+
+## 输出格式
+1. **Configuration** – models used for review
+2. **Review Summary** – overall assessment
+3. **Critical Issues** – must fix before merge
+4. **Major Issues** – should fix
+5. **Minor Issues** – nice to fix
+6. **Suggestions** – optional improvements
+7. **Recommended Actions** – prioritized fix list
+
+## 注意事项
+- **首先读取 `~/.ccg/config.toml` 获取审查模型配置**
+- **No arguments** = auto-review git changes (`git diff HEAD`)
+- **With arguments** = review specified content
+- **Use `run_in_background: true` for parallel execution** to avoid blocking
+- 多模型结果交叉验证，综合反馈
+- Use HEREDOC syntax (`<<'EOF'`) to avoid shell escaping issues

package/templates/commands/rollback.md

@@ -0,0 +1,90 @@
+---
+description: 交互式回滚 Git 分支到历史版本；列分支、列版本、二次确认后执行 reset / revert
+allowed-tools: Read(**), Exec(git fetch, git branch, git tag, git log, git reflog, git checkout, git reset, git revert, git switch), Write()
+argument-hint: [--branch <branch>] [--target <rev>] [--mode reset|revert] [--depth <n>] [--dry-run] [--yes]
+# examples:
+#   - /git-rollback                # 全交互模式，dry‑run
+#   - /git-rollback --branch dev   # 直接选 dev，其他交互
+#   - /git-rollback --branch dev --target v1.2.0 --mode reset --yes
+---
+
+# Claude Command: Git Rollback
+
+**目的**：安全、可视地将指定分支回滚到旧版本。
+默认处于 **只读预览 (`--dry-run`)**；真正执行需加 `--yes` 或在交互中确认。
+
+---
+
+## Usage
+
+```bash
+# 纯交互：列出分支 → 选分支 → 列最近 20 个版本 → 选目标 → 选择 reset 或 revert → 二次确认
+/git-rollback
+
+# 指定分支，其他交互
+/git-rollback --branch feature/calculator
+
+# 指定分支与目标 commit，并用 hard‑reset 一键执行（危险）
+/git-rollback --branch main --target 1a2b3c4d --mode reset --yes
+
+# 只想生成 revert 提交（非破坏式回滚），预览即可
+/git-rollback --branch release/v2.1 --target v2.0.5 --mode revert --dry-run
+```
+
+### Options
+
+| 选项                   | 说明                                                                               |
+| ---------------------- | ---------------------------------------------------------------------------------- |
+| `--branch <branch>`    | 要回滚的分支；缺省时交互选择。                                                     |
+| `--target <rev>`       | 目标版本（commit Hash、Tag、reflog 引用都行）；缺省时交互选择近 `--depth` 条记录。 |
+| `--mode reset\|revert` | `reset`：硬回滚历史；`revert`：生成反向提交保持历史完整。默认询问。                |
+| `--depth <n>`          | 在交互模式下列出最近 n 个版本（默认 20）。                                         |
+| `--dry-run`            | **默认开启**，只预览即将执行的命令。                                               |
+| `--yes`                | 跳过所有确认直接执行，适合 CI/CD 脚本。                                            |
+
+---
+
+## 交互流程
+
+1. **同步远端** → `git fetch --all --prune`
+2. **列分支** → `git branch -a`（本地＋远端，过滤受保护分支）
+3. **选分支** → 用户输入或传参
+4. **列版本** → `git log --oneline -n <depth>` + `git tag --merged` + `git reflog -n <depth>`
+5. **选目标** → 用户输入 commit hash / tag
+6. **选模式** → `reset` 或 `revert`
+7. **最终确认** （除非 `--yes`）
+8. **执行回滚**
+   - `reset`：`git switch <branch> && git reset --hard <target>`
+   - `revert`：`git switch <branch> && git revert --no-edit <target>..HEAD`
+9. **推送建议** → 提示是否 `git push --force-with-lease`（reset）或普通 `git push`（revert）
+
+---
+
+## 安全护栏
+
+- **备份**：执行前自动在 reflog 中记录当前 HEAD，可用 `git switch -c backup/<timestamp>` 恢复。
+- **保护分支**：如检测到 `main` / `master` / `production` 等受保护分支且开启 `reset` 模式，将要求额外确认。
+- **--dry-run 默认开启**：防止误操作。
+- **--force 禁止**：不提供 `--force`；如需强推，请手动输入 `git push --force-with-lease`。
+
+---
+
+## 适用场景示例
+
+| 场景                                            | 调用示例                                                         |
+| ----------------------------------------------- | ---------------------------------------------------------------- |
+| 热修补丁上线后发现 bug，需要回到 Tag `v1.2.0`   | `/git-rollback --branch release/v1 --target v1.2.0 --mode reset` |
+| 运维同事误推了 debug 日志提交，需要生成反向提交 | `/git-rollback --branch main --target 3f2e7c9 --mode revert`     |
+| 调研历史 bug，引导新人浏览分支历史              | `/git-rollback` （全交互，dry‑run）                              |
+
+---
+
+## 注意
+
+1. **reset vs revert**
+   - **reset** 会改变历史，需要强推并可能影响其他协作者，谨慎使用。
+   - **revert** 更安全，生成新提交保留历史，但会增加一次记录。
+2. **嵌入式仓库** 常有大体积二进制文件；回滚前请确保 LFS/子模块状态一致。
+3. 若仓库启用了 CI 强制校验，回滚后可能自动触发流水线；确认管控策略以免误部署旧版本。
+
+---

package/templates/commands/test.md

@@ -0,0 +1,53 @@
+---
+description: 多模型测试生成（Codex 后端测试 + Gemini 前端测试）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/test <测试目标>`
+
+## 上下文
+- 测试目标: $ARGUMENTS
+- Codex 生成后端测试，Gemini 生成前端测试
+
+## 流程
+
+### Phase 1: 测试分析
+1. 调用 `mcp__ace-tool__search_context` 检索：
+   - 目标代码的完整实现
+   - 现有测试文件和测试框架
+   - 项目测试配置（jest.config, pytest.ini 等）
+2. 识别代码类型：前端组件 / 后端逻辑 / 全栈
+3. 评估当前测试覆盖率和缺口
+
+### Phase 2: 智能路由测试生成
+| 代码类型 | 路由 | 角色 |
+|---------|------|------|
+| 后端 | Codex | `tester` |
+| 前端 | Gemini | `tester` |
+| 全栈 | 并行执行 | 两者 |
+
+输出: `Unified Diff Patch for test files ONLY`
+
+### Phase 3: 测试整合
+1. 收集模型输出（`TaskOutput`）
+2. Claude 重构：统一风格、确保命名一致、优化结构、移除冗余
+
+### Phase 4: 测试验证
+1. 运行生成的测试
+2. 检查通过率
+3. 如有失败，分析原因并修复
+
+## 测试策略金字塔
+```
+    /\      E2E (10%)
+   /--\     Integration (20%)
+  /----\    Unit (70%)
+```
+
+## 关键原则
+1. **测试行为，不测试实现** - 关注输入输出
+2. **智能路由** - 后端测试用 Codex，前端测试用 Gemini
+3. **复用现有模式** - 遵循项目已有的测试风格
+4. **覆盖优先级** - 先覆盖关键路径和高风险代码