ccg-workflow 1.0.0

package/templates/commands/backend.md

@@ -0,0 +1,81 @@
+---
+description: 后端/逻辑/算法任务，自动路由到配置的后端模型进行原型生成和审计
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/backend <LOGIC_TASK_DESCRIPTION>`
+
+## 上下文
+- Backend/logic task to implement: $ARGUMENTS
+- This command routes to your configured backend models.
+- Default authority for algorithms, APIs, and business logic.
+
+## 配置
+**首先读取 `~/.ccg/config.toml` 获取模型路由配置**:
+```toml
+[routing.backend]
+models = ["codex", "gemini"]  # 用户配置的后端模型列表
+primary = "codex"              # 主模型
+strategy = "parallel"          # 路由策略: parallel | fallback | round-robin
+```
+
+## 你的角色
+You are the **Backend Orchestrator** specializing in server-side logic. You coordinate:
+1. **ace-tool** – for retrieving existing backend code and architecture
+2. **Configured Backend Models** – for generating logic, algorithms, and API implementations
+3. **Claude (Self)** – for refactoring prototypes into production code
+
+## 流程
+
+### Step 1: 读取配置
+1. Read `~/.ccg/config.toml` to get backend model configuration
+2. Identify which models to use based on `routing.backend.models`
+3. If config doesn't exist, default to `codex`
+
+### Step 2: 上下文检索
+1. Call `mcp__ace-tool__search_context` to understand existing architecture
+2. Identify API patterns, data models, services, and dependencies
+
+### Step 3: 模型原型生成
+
+**根据配置的 strategy 执行**:
+- **parallel**: 同时调用所有配置的后端模型，综合结果
+- **fallback**: 调用主模型，失败则调用次模型
+- **round-robin**: 轮询调用
+
+遍历 `routing.backend.models`，为每个模型发送调用：
+- **Codex**: 使用 `architect` 角色
+- **Gemini**: 使用 `analyzer` 角色（Gemini 无专门后端角色）
+- 输出: `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 proper error handling and security
+
+### Step 5: 审计
+
+Call configured backend model(s) to review the final implementation:
+- 使用 `reviewer` 角色
+- 审查内容: security, performance, error handling
+- 输出: `Review comments only`
+
+## 输出格式
+1. **Configuration** – models and strategy being used
+2. **Architecture Analysis** – existing patterns and dependencies
+3. **Model Prototype(s)** – raw prototypes from configured models
+4. **Refined Implementation** – production-ready backend code
+5. **Audit Feedback** – security and performance review
+
+## 注意事项
+- Codex excels at complex logic and debugging
+- Codex uses read-only sandbox by default
+- 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/bugfix.md

@@ -0,0 +1,55 @@
+---
+description: 质量门控修复（双模型交叉验证，90%+ 通过）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/bugfix <bug描述>`
+
+## 上下文
+- Bug 描述: $ARGUMENTS
+- 使用双模型交叉验证确保修复质量
+- 质量门控：90%+ 评分才能通过，最多 3 轮迭代
+
+## 流程
+
+### Phase 1: Bug 分析
+1. 调用 `mcp__ace-tool__search_context` 检索相关代码
+2. 分析 bug 类型：前端/后端/全栈
+3. 收集复现步骤、错误日志、预期行为
+
+### Phase 2: 双模型诊断
+**并行调用**（`run_in_background: true`）:
+- **Codex** + `architect` 角色 → 后端分析
+- **Gemini** + `frontend` 角色 → 前端分析
+
+输出: `Unified Diff Patch for the fix`
+
+### Phase 3: 修复整合
+1. 收集双模型的修复方案（`TaskOutput`）
+2. 综合分析：识别共同点、合并互补修复、选择最优方案
+3. Claude 重构为生产级代码
+
+### Phase 4: 实施修复
+应用修复代码，记录变更内容
+
+### Phase 5: 质量门控验证
+**并行调用** Codex + Gemini + `reviewer` 角色验证
+
+### Phase 6: 质量门控决策
+```
+综合评分 = (Codex 评分 + Gemini 评分) / 2
+```
+
+| 综合评分 | 结果 | 动作 |
+|----------|------|------|
+| ≥ 90% | ✅ PASS | 完成修复，可提交 |
+| 70-89% | ⚠️ ITERATE | 返回 Phase 3，携带反馈 |
+| 3轮后 < 90% | ❌ FAIL | 需人工介入 |
+
+## 关键原则
+1. **双模型交叉验证** - 避免单一视角的盲区
+2. **量化质量评估** - 使用评分制而非主观判断
+3. **迭代改进** - 每轮携带具体反馈
+4. **止损机制** - 最多 3 轮，防止无限循环

package/templates/commands/clean-branches.md

@@ -0,0 +1,102 @@
+---
+description: 安全查找并清理已合并或过期的 Git 分支，支持 dry-run 模式与自定义基准/保护分支
+allowed-tools: Read(**), Exec(git fetch, git config, git branch, git remote, git push, git for-each-ref, git log), Write()
+argument-hint: [--base <branch>] [--stale <days>] [--remote] [--force] [--dry-run] [--yes]
+# examples:
+#   - /git-cleanBranches --dry-run
+#   - /git-cleanBranches --base release/v2.1 --stale 90
+#   - /git-cleanBranches --remote --yes
+---
+
+# Claude Command: Clean Branches
+
+该命令**安全地**识别并清理**已合并**或**长期未更新 (stale)** 的 Git 分支。
+默认以**只读预览 (`--dry-run`)** 模式运行，需明确指令才会执行删除操作。
+
+---
+
+## Usage
+
+```bash
+# [最安全] 预览将要清理的分支，不执行任何删除
+/git-cleanBranches --dry-run
+
+# 清理已合并到 main 且超过 90 天未动的本地分支 (需逐一确认)
+/git-cleanBranches --stale 90
+
+# 清理已合并到 release/v2.1 的本地与远程分支 (自动确认)
+/git-cleanBranches --base release/v2.1 --remote --yes
+
+# [危险] 强制删除一个未合并的本地分支
+/git-cleanBranches --force outdated-feature
+```
+
+### Options
+
+- `--base <branch>`：指定清理的基准分支（默认为仓库的 `main`/`master`）。
+- `--stale <days>`：清理超过指定天数未提交的分支（默认不启用）。
+- `--remote`：同时清理远程已合并/过期的分支。
+- `--dry-run`：**默认行为**。仅列出将要删除的分支，不执行任何操作。
+- `--yes`：跳过逐一确认的步骤，直接删除所有已识别的分支（适合 CI/CD）。
+- `--force`：使用 `-D` 强制删除本地分支（即使未合并）。
+
+---
+
+## What This Command Does
+
+1. **配置与安全预检**
+   - **更新信息**：自动执行 `git fetch --all --prune`，确保分支状态最新。
+   - **读取保护分支**：从 Git 配置读取不应被清理的分支列表（见下文“Configuration”）。
+   - **确定基准**：使用 `--base` 参数或自动识别的 `main`/`master` 作为比较基准。
+
+2. **分析识别（Find）**
+   - **已合并分支**：找出已完全合并到 `--base` 的本地（及远程，如加 `--remote`）分支。
+   - **过期分支**：如指定 `--stale <days>`，找出最后一次提交在 N 天前的分支。
+   - **排除保护分支**：从待清理列表中移除所有已配置的保护分支。
+
+3. **报告预览（Report）**
+   - 清晰列出“将要删除的已合并分支”与“将要删除的过期分支”。
+   - 若无 `--yes` 参数，**命令到此结束**，等待用户确认后再次执行（不带 `--dry-run`）。
+
+4. **执行清理（Execute）**
+   - **仅在不带 `--dry-run` 且用户确认后**（或带 `--yes`）执行。
+   - 逐一删除已识别的分支，除非用户在交互式确认中选择跳过。
+   - 本地用 `git branch -d <branch>`；远程用 `git push origin --delete <branch>`。
+   - 若指定 `--force`，本地删除会改用 `git branch -D <branch>`。
+
+---
+
+## Configuration (一次配置，永久生效)
+
+为防止误删重要分支（如 `develop`, `release/*`），请在仓库的 Git 配置中添加保护规则。命令会自动读取。
+
+```bash
+# 保护 develop 分支
+git config --add branch.cleanup.protected develop
+
+# 保护所有 release/ 开头的分支 (通配符)
+git config --add branch.cleanup.protected 'release/*'
+
+# 查看所有已配置的保护分支
+git config --get-all branch.cleanup.protected
+```
+
+---
+
+## Best Practices for Embedded Devs
+
+- **优先 `--dry-run`**：养成先预览再执行的习惯。
+- **活用 `--base`**：维护长期 `release` 分支时，用它来清理已合并到该 release 的 `feature` 或 `hotfix` 分支。
+- **谨慎 `--force`**：除非你百分百确定某个未合并分支是无用功，否则不要强制删除。
+- **团队协作**：在清理共享的远程分支前，先在团队频道通知一声。
+- **定期运行**：每月或每季度运行一次，保持仓库清爽。
+
+---
+
+## Why This Version Is Better
+
+- ✅ **更安全**：默认只读预览，且有可配置的保护分支列表。
+- ✅ **更灵活**：支持自定义基准分支，完美适配 `release` / `develop` 工作流。
+- ✅ **更兼容**：避免了在不同系统上行为不一的 `date -d` 等命令。
+- ✅ **更直观**：将复杂的 16 步清单，浓缩成一个带安全选项的、可直接执行的命令。
+- ✅ **风格一致**：与 `/commit` 命令共享相似的参数设计与文档结构。

package/templates/commands/code.md

@@ -0,0 +1,169 @@
+---
+description: 三模型代码生成（Codex + Gemini + Claude 并行原型，集各家所长）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/code <功能描述>`
+
+## 上下文
+- 功能描述: $ARGUMENTS
+- **三模型并行生成原型**，编排者集各家所长
+- 生成的原型经 Claude (编排者) 重构为生产级代码
+
+## 工作流程
+
+### Phase 1: 需求分析
+
+1. 调用 `mcp__ace-tool__search_context` 检索：
+   - 相关模块和文件结构
+   - 现有代码模式和风格
+   - 依赖和接口定义
+2. 分析任务类型：
+   - **前端**: UI 组件、样式、用户交互
+   - **后端**: API、业务逻辑、数据库操作
+   - **全栈**: 同时涉及前后端
+
+### Phase 2: 三模型并行原型生成
+
+**同时调用三个模型**（`run_in_background: true`）：
+
+1. **Codex** + `architect` 角色 → 后端架构视角
+2. **Gemini** + `frontend` 角色 → 前端 UI 视角
+3. **Claude** + `architect` 角色 → 全栈整合视角
+
+输出: `Unified Diff Patch ONLY`
+
+**三模型差异化价值**：
+| 模型 | 专注点 | 独特贡献 |
+|------|--------|----------|
+| Codex | 后端逻辑、算法、API | 深度后端专业知识 |
+| Gemini | 前端 UI、样式、交互 | 视觉设计和用户体验 |
+| Claude | 全栈整合、契约设计 | 桥接前后端视角 |
+
+定义清晰的接口契约：
+```
+API Contract:
+- Endpoint: POST /api/xxx
+- Request: { field1: string, field2: number }
+- Response: { data: T, error?: string }
+```
+
+### Phase 3: 原型整合
+
+1. 收集三个模型输出（使用 `TaskOutput`）
+2. 将 Unified Diff 视为"脏原型"
+3. **交叉验证，集各家所长**：
+   - Codex 的后端逻辑和 API 设计
+   - Gemini 的前端组件和 UI 交互
+   - Claude 的整合视角和契约一致性
+4. Claude (编排者) 重构：
+   - 统一代码风格
+   - 确保前后端接口一致
+   - 优化实现细节
+   - 移除冗余代码
+
+### Phase 4: 代码实施
+
+1. 应用重构后的代码
+2. 确保不破坏现有功能
+3. 验证编译/类型检查通过
+
+### Phase 5: 三模型审查
+
+**并行启动审查**（`run_in_background: true`）：
+- **Codex** + `reviewer` 角色 → 安全性、性能、错误处理
+- **Gemini** + `reviewer` 角色 → 可访问性、响应式、设计一致性
+- **Claude** + `reviewer` 角色 → 集成正确性、契约一致性
+- 输出: `Review comments with specific line references`
+
+### Phase 6: 修正与交付
+
+1. 综合三模型审查意见
+2. 修正发现的问题
+3. 最终交付
+
+## 输出格式
+
+```
+## 🚀 Code: <功能描述>
+
+### Phase 1: 需求分析
+- 任务类型: [前端/后端/全栈]
+- 相关文件: <文件列表>
+- 现有模式: <识别的模式>
+
+### Phase 2: 代码生成
+#### Codex 原型 (后端视角)
+<Unified Diff 摘要>
+
+#### Gemini 原型 (前端视角)
+<Unified Diff 摘要>
+
+#### Claude 原型 (全栈视角)
+<Unified Diff 摘要>
+
+### Phase 3: 整合重构
+<重构说明>
+
+### Phase 4: 实施
+<变更文件列表>
+
+### Phase 5: 审查
+#### Codex 审查 (安全/性能)
+- <审查意见 1>
+- <审查意见 2>
+
+#### Gemini 审查 (可访问性/设计)
+- <审查意见 1>
+- <审查意见 2>
+
+#### Claude 审查 (集成/契约)
+- <审查意见 1>
+- <审查意见 2>
+
+### Phase 6: 交付
+✅ 实施完成
+- 新增文件: X
+- 修改文件: Y
+- 代码行数: +N / -M
+```
+
+## 任务类型检测
+
+| 关键词 | 类型 | 路由 |
+|--------|------|------|
+| component, UI, style, CSS, React, Vue | 前端 | Gemini |
+| API, endpoint, database, auth, backend | 后端 | Codex |
+| full-stack, 全栈, 页面+接口 | 全栈 | 并行 |
+
+## 代码质量标准
+
+### 前端代码 (Gemini 专注)
+- [ ] TypeScript 类型完整
+- [ ] 响应式设计
+- [ ] 无障碍属性
+- [ ] 加载/错误状态
+- [ ] 遵循设计系统
+
+### 后端代码 (Codex 专注)
+- [ ] 输入验证
+- [ ] 错误处理
+- [ ] 安全检查
+- [ ] 查询优化
+- [ ] API 一致性
+
+### 全栈整合 (Claude 专注)
+- [ ] 前后端接口一致
+- [ ] 类型定义共享
+- [ ] 错误码统一
+- [ ] 契约文档完整
+
+## 关键原则
+
+1. **三模型并行** - 同时获取三个视角的原型
+2. **集各家所长** - 交叉验证，取最优方案
+3. **接口优先** - 先定义 API 契约
+4. **编排者重构** - 原型需要 Claude (编排者) 整合
+5. **三重审查** - 代码必须经过三模型审查

package/templates/commands/commit.md

@@ -0,0 +1,158 @@
+---
+description: 仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过）
+allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG)
+argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope <scope>] [--type <type>]
+# examples:
+#   - /git-commit                           # 分析当前改动，生成提交信息
+#   - /git-commit --all                     # 暂存所有改动并提交
+#   - /git-commit --no-verify               # 跳过 Git 钩子检查
+#   - /git-commit --emoji                   # 在提交信息中包含 emoji
+#   - /git-commit --scope ui --type feat    # 指定作用域和类型
+#   - /git-commit --amend --signoff         # 修补上次提交并签名
+---
+
+# Claude Command: Commit (Git-only)
+
+该命令在**不依赖任何包管理器/构建工具**的前提下，仅通过 **Git**：
+
+- 读取改动（staged/unstaged）
+- 判断是否需要**拆分为多次提交**
+- 为每个提交生成 **Conventional Commits** 风格的信息（可选 emoji）
+- 按需执行 `git add` 与 `git commit`（默认运行本地 Git 钩子；可 `--no-verify` 跳过）
+
+---
+
+## Usage
+
+```bash
+/git-commit
+/git-commit --no-verify
+/git-commit --emoji
+/git-commit --all --signoff
+/git-commit --amend
+/git-commit --scope ui --type feat --emoji
+```
+
+### Options
+
+- `--no-verify`：跳过本地 Git 钩子（`pre-commit`/`commit-msg` 等）。
+- `--all`：当暂存区为空时，自动 `git add -A` 将所有改动纳入本次提交。
+- `--amend`：在不创建新提交的情况下**修补**上一次提交（保持提交作者与时间，除非本地 Git 配置另有指定）。
+- `--signoff`：附加 `Signed-off-by` 行（遵循 DCO 流程时使用）。
+- `--emoji`：在提交信息中包含 emoji 前缀（省略则使用纯文本）。
+- `--scope <scope>`：指定提交作用域（如 `ui`、`docs`、`api`），写入消息头部。
+- `--type <type>`：强制提交类型（如 `feat`、`fix`、`docs` 等），覆盖自动判断。
+
+> 注：如框架不支持交互式确认，可在 front-matter 中开启 `confirm: true` 以避免误操作。
+
+---
+
+## What This Command Does
+
+1. **仓库/分支校验**
+   - 通过 `git rev-parse --is-inside-work-tree` 判断是否位于 Git 仓库。
+   - 读取当前分支/HEAD 状态；如处于 rebase/merge 冲突状态，先提示处理冲突后再继续。
+
+2. **改动检测**
+   - 用 `git status --porcelain` 与 `git diff` 获取已暂存与未暂存的改动。
+   - 若已暂存文件为 0：
+     - 若传入 `--all` → 执行 `git add -A`。
+     - 否则提示你选择：继续仅分析未暂存改动并给出**建议**，或取消命令后手动分组暂存。
+
+3. **拆分建议（Split Heuristics）**
+   - 按**关注点**、**文件模式**、**改动类型**聚类（示例：源代码 vs 文档、测试；不同目录/包；新增 vs 删除）。
+   - 若检测到**多组独立变更**或 diff 规模过大（如 > 300 行 / 跨多个顶级目录），建议拆分提交，并给出每一组的 pathspec（便于后续执行 `git add <paths>`）。
+
+4. **提交信息生成（Conventional 规范，可选 Emoji）**
+   - 自动推断 `type`（`feat`/`fix`/`docs`/`refactor`/`test`/`chore`/`perf`/`style`/`ci`/`revert` …）与可选 `scope`。
+   - 生成消息头：`[<emoji>] <type>(<scope>)?: <subject>`（首行 ≤ 72 字符，祈使语气，仅在使用 `--emoji` 时包含 emoji）。
+   - 生成消息体：要点列表（动机、实现要点、影响范围、BREAKING CHANGE 如有）。
+   - 根据 Git 历史提交的主要语言选择提交信息语言。优先检查最近提交主题（例如 `git log -n 50 --pretty=%s`）判断中文/英文；若无法判断，则回退到仓库主要语言或英文。
+   - 将草稿写入 `.git/COMMIT_EDITMSG`，并用于 `git commit`。
+
+5. **执行提交**
+   - 单提交场景：`git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG`
+   - 多提交场景（如接受拆分建议）：按分组给出 `git add <paths> && git commit ...` 的明确指令；若允许执行则逐一完成。
+
+6. **安全回滚**
+   - 如误暂存，可用 `git restore --staged <paths>` 撤回暂存（命令会给出指令，不修改文件内容）。
+
+---
+
+## Best Practices for Commits
+
+- **Atomic commits**：一次提交只做一件事，便于回溯与审阅。
+- **先分组再提交**：按目录/模块/功能点拆分。
+- **清晰主题**：首行 ≤ 72 字符，祈使语气（如 “add… / fix…”）。
+- **正文含上下文**：说明动机、方案、影响范围、风险与后续工作。
+- **遵循 Conventional Commits**：`<type>(<scope>): <subject>`。
+
+---
+
+## Type 与 Emoji 映射（使用 --emoji 时）
+
+- ✨ `feat`：新增功能
+- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
+- 📝 `docs`：文档与注释
+- 🎨 `style`：风格/格式（不改语义）
+- ♻️ `refactor`：重构（不新增功能、不修缺陷）
+- ⚡️ `perf`：性能优化
+- ✅ `test`：新增/修复测试、快照
+- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
+- 👷 `ci`：CI/CD 配置与脚本
+- ⏪️ `revert`：回滚提交
+- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）
+
+> 若传入 `--type`/`--scope`，将**覆盖**自动推断。
+> 仅在指定 `--emoji` 标志时才会包含 emoji。
+
+---
+
+## Guidelines for Splitting Commits
+
+1. **不同关注点**：互不相关的功能/模块改动应拆分。
+2. **不同类型**：不要将 `feat`、`fix`、`refactor` 混在同一提交。
+3. **文件模式**：源代码 vs 文档/测试/配置分组提交。
+4. **规模阈值**：超大 diff（示例：>300 行或跨多个顶级目录）建议拆分。
+5. **可回滚性**：确保每个提交可独立回退。
+
+---
+
+## Examples
+
+**Good (使用 --emoji)**
+
+- ✨ feat(ui): add user authentication flow
+- 🐛 fix(api): handle token refresh race condition
+- 📝 docs: update API usage examples
+- ♻️ refactor(core): extract retry logic into helper
+- ✅ test: add unit tests for rate limiter
+- 🔧 chore: update git hooks and repository settings
+- ⏪️ revert: revert "feat(core): introduce streaming API"
+
+**Good (不使用 --emoji)**
+
+- feat(ui): add user authentication flow
+- fix(api): handle token refresh race condition
+- docs: update API usage examples
+- refactor(core): extract retry logic into helper
+- test: add unit tests for rate limiter
+- chore: update git hooks and repository settings
+- revert: revert "feat(core): introduce streaming API"
+
+**Split Example**
+
+- `feat(types): add new type defs for payment method`
+- `docs: update API docs for new types`
+- `test: add unit tests for payment types`
+- `fix: address linter warnings in new files` ←（如你的仓库有钩子报错）
+
+---
+
+## Important Notes
+
+- **仅使用 Git**：不调用任何包管理器/构建命令（无 `pnpm`/`npm`/`yarn` 等）。
+- **尊重钩子**：默认执行本地 Git 钩子；使用 `--no-verify` 可跳过。
+- **不改源码内容**：命令只读写 `.git/COMMIT_EDITMSG` 与暂存区；不会直接编辑工作区文件。
+- **安全提示**：在 rebase/merge 冲突、detached HEAD 等状态下会先提示处理/确认再继续。
+- **可审可控**：如开启 `confirm: true`，每个实际 `git add`/`git commit` 步骤都会进行二次确认。

package/templates/commands/debug.md

@@ -0,0 +1,104 @@
+---
+description: UltraThink 多模型调试（Codex 后端诊断 + Gemini 前端诊断）
+---
+
+> 调用语法见 `_config.md`
+
+## 用法
+`/debug <问题描述>`
+
+## 上下文
+- 问题描述: $ARGUMENTS
+- 使用 ace-tool 检索相关代码上下文
+- Codex 专注后端/逻辑问题，Gemini 专注前端/UI问题
+
+## 流程
+
+### Phase 1: 上下文检索
+
+1. 调用 `mcp__ace-tool__search_context` 检索相关代码
+2. 收集错误日志、堆栈信息、复现步骤
+3. 识别问题涉及的模块（前端/后端/全栈）
+
+### Phase 2: 并行诊断
+
+**同时启动两个后台任务**（`run_in_background: true`）：
+
+- **Codex** + `debugger` 角色 → 后端诊断
+- **Gemini** + `debugger` 角色 → 前端诊断
+- 输出: `Structured diagnostic report. No code modifications.`
+
+### Phase 3: 假设整合
+
+1. 收集两个模型的诊断报告（使用 `TaskOutput`）
+2. 交叉验证：识别重叠和互补的假设
+3. **UltraThink 综合**：
+   - 整合所有假设，按可能性排序
+   - 筛选出 **Top 1-2 最可能原因**
+   - 设计验证策略
+
+### Phase 4: 用户确认（Hard Stop）
+
+输出格式：
+```
+## 🔍 诊断结果
+
+### Codex 分析（后端视角）
+<Codex 诊断摘要>
+
+### Gemini 分析（前端视角）
+<Gemini 诊断摘要>
+
+### 综合诊断
+**最可能原因**：<具体诊断>
+**证据**：<支持证据>
+**验证方案**：<如何确认>
+
+---
+**确认后我将执行修复。是否继续？(Y/N)**
+```
+
+⚠️ **必须等待用户确认后才能进入 Phase 5**
+
+### Phase 5: 修复与验证
+
+1. 根据确认的诊断实施修复
+2. 修复完成后，**并行调用** Codex + Gemini + `reviewer` 角色审查修复
+3. 综合审查意见，确认问题解决
+
+## 输出格式
+
+```
+## Phase 1: 上下文检索
+- 检索到 X 个相关文件
+- 问题类型: [前端/后端/全栈]
+
+## Phase 2: 并行诊断
+### Codex 诊断
+<诊断内容>
+
+### Gemini 诊断
+<诊断内容>
+
+## Phase 3: 综合分析
+### Top 假设
+1. [最可能原因] - 可能性: High
+2. [次可能原因] - 可能性: Medium
+
+### 验证策略
+- [具体验证步骤]
+
+## Phase 4: 确认
+**是否按此诊断进行修复？(Y/N)**
+
+## Phase 5: 修复验证（用户确认后）
+- 修复内容: <具体修改>
+- 双模型审查: <审查结果>
+```
+
+## 关键原则
+
+1. **不假设，先验证** - 所有假设需要证据支持
+2. **并行诊断** - 充分利用双模型的不同视角
+3. **用户确认** - 修复前必须获得确认
+4. **交叉审查** - 修复后双模型验证