ccgx-workflow 1.0.0

package/templates/commands/debug.md

@@ -0,0 +1,226 @@
+---
+description: '多模型调试（v4.0 manager + debugger 双层 fresh-context）：科学方法 hypothesis 链 + 持久 session + cap 3 升级'
+argument-hint: "<问题描述> [--mode=find_root_cause_only|find_and_fix] [--role=architect|critic|implementer|tester|writer]"
+---
+
+# Debug - 多模型调试（v4.0 重写）
+
+## Role-based routing（v4.1 specialist matrix）
+
+可选 `--role=<name>` 叠加 role 维度路由（debug-session-manager 内 spawn 的 debugger 用 role 选 prompt）：
+
+| Role × Layer  | architect      | critic              | implementer | tester        | writer          |
+| ------------- | -------------- | ------------------- | ----------- | ------------- | --------------- |
+| **backend**   | codex/architect.md | codex/reviewer.md (adversarial) | codex/debugger.md | codex/tester.md | claude  |
+| **frontend**  | gemini/architect.md | gemini/reviewer.md (adversarial) | gemini/debugger.md | gemini/tester.md | gemini/analyzer.md |
+| **fullstack** | codex+gemini/architect.md | both reviewer.md (adversarial) | runner 决 | runner 决 | claude |
+
+**未传 --role 时按 v4.0 manager + debugger 双层流程**（debugger.md 默认 implementer 角色）——完全兼容。`--role=critic` 触发"反向假设"调试（强制构造反证），适合定位概率性 bug。详见 `src/utils/specialist-router.ts`。
+
+---
+
+**v4.0 重大变更**：从单次双模型并行调用 → **manager + debugger 双层 fresh-context** 模式。
+
+主线（你）只 spawn `debug-session-manager` 一次，manager 在隔离 context 内跑完整 hypothesis 多轮循环，最终返回 ≤ 200 token 的紧凑摘要。**主线 context 不再被多轮调试 transcript 污染**——这是 GSD ROI #3 (`02-subagent-matrix.md` Section 2.6) 的核心模式。
+
+## 使用方法
+
+```bash
+/ccg:debug <问题描述>                          # 默认 find_and_fix 模式
+/ccg:debug <问题描述> --mode=find_root_cause_only  # 仅找根因，不修
+/ccg:debug <问题描述> --mode=find_and_fix         # 找根因 + 应用修复 + 跑验证
+```
+
+---
+
+## 你的角色
+
+你是**调试启动器**，**不**直接做调试。你的工作就 3 步：
+
+1. 解析参数 → 提取 `symptoms` + `mode` + 生成 `slug`
+2. **Spawn 一次** `debug-session-manager`（fresh context）
+3. 接收 manager 返回的紧凑摘要，向用户呈现
+
+主线**不读** manager 的中间 transcript——所有 hypothesis 链 / evidence / fix 应用都在 manager 隔离 context 完成。session 文件 `.context/debug/<slug>.md` 用户可事后审计。
+
+---
+
+## 执行工作流
+
+### 阶段 0：参数解析
+
+**问题描述**：$ARGUMENTS
+
+1. 从 $ARGUMENTS 提取核心症状（错误信息 / 复现步骤 / 期望行为）
+2. 解析 `--mode` 参数：
+   - `find_root_cause_only` — 仅找根因，找到立即返回
+   - `find_and_fix`（**默认**）— 找根因 + 应用修复 + 跑测试验证
+3. 生成 `slug`：从症状提取 3-5 个 kebab-case 关键词（如 `login-csrf-cookie` / `react-strict-double-init`）
+4. 用 Bash `pwd`（Unix）或 `cd`（Windows CMD）拿到工作目录绝对路径，**禁止**从 `$HOME` 推断
+
+### 阶段 1：（可选）Prompt 增强
+
+如症状描述模糊（如"登录有 bug"），按 `/ccg:enhance` 逻辑补全为结构化输入：
+- 错误信息全文
+- 复现步骤
+- 期望行为 vs 实际行为
+- 已尝试的修复
+
+如已结构化则跳过。
+
+### 阶段 2：Spawn debug-session-manager
+
+**关键**：**只 spawn 一次**。manager 内部多轮循环 + 调度 debugger，主线不参与。
+
+```
+Agent({
+  subagent_type: "debug-session-manager",
+  prompt: <见下方 prompt 模板>
+})
+```
+
+**Prompt 模板**：
+
+```
+你是 debug-session-manager。完整执行多轮 hypothesis 循环，最终返回 ≤ 200 token 紧凑摘要。
+
+## 输入
+
+slug: <生成的 slug>
+mode: <find_root_cause_only | find_and_fix>
+workdir: <pwd 输出>
+symptoms: |
+  <增强后的症状描述全文>
+
+## 工作要求
+
+1. 在 .context/debug/<slug>.md 维护持久 hypothesis 链
+2. 每个 hypothesis 必须 falsifiable（有可观察的 fail 条件，不接受"代码可能有 bug"空话）
+3. spawn debugger subagent 提出 / 验证 hypothesis
+4. cap 3 hypothesis refuted → CHECKPOINT_REACHED 升级
+5. find_root_cause_only 模式：找到 confirmed hypothesis 立即返回 ROOT_CAUSE_FOUND
+6. find_and_fix 模式：找到 root cause → 应用 fix → 跑测试验证 → DEBUG_COMPLETE
+7. 不修改 .ccg/roadmap.md / .ccg-research/
+
+## 摘要格式（严格三选一）
+
+ROOT_CAUSE_FOUND:
+  STATUS: ROOT_CAUSE_FOUND
+  SLUG: <slug>
+  ROOT_CAUSE: <一句话>
+  SUGGESTED_FIX: <一段建议>
+
+DEBUG_COMPLETE:
+  STATUS: DEBUG_COMPLETE
+  SLUG: <slug>
+  ROOT_CAUSE: <一句话>
+  FIX_APPLIED: <修了哪个文件做了什么>
+  VERIFICATION: <跑了什么测试，结果如何>
+
+CHECKPOINT_REACHED:
+  STATUS: CHECKPOINT_REACHED
+  SLUG: <slug>
+  HYPOTHESES_TRIED: <数字>
+  REASON: <为什么放弃 + 建议用户怎么介入>
+```
+
+### 阶段 3：解析摘要 + 向用户呈现
+
+manager 返回后，解析 `STATUS:` 第一行决定显示模板：
+
+#### STATUS=ROOT_CAUSE_FOUND
+
+```markdown
+## 🎯 找到根因（未修）
+
+**SLUG**: <slug>
+**根因**: <root_cause>
+**建议修复**:
+<suggested_fix>
+
+📁 完整调试记录: `.context/debug/<slug>.md`
+
+---
+
+是否要应用修复？
+1. 应用修复（再跑 `/ccg:debug "<原症状>" --mode=find_and_fix`）
+2. 仅记录，手动修复
+3. 继续调查（提供新线索）
+```
+
+用 `AskUserQuestion` 询问。
+
+#### STATUS=DEBUG_COMPLETE
+
+```markdown
+## ✅ 调试完成
+
+**SLUG**: <slug>
+**根因**: <root_cause>
+**已应用修复**: <fix_applied>
+**验证**: <verification>
+
+📁 完整调试记录: `.context/debug/<slug>.md`
+
+建议跑回归测试确认无副作用。
+```
+
+#### STATUS=CHECKPOINT_REACHED
+
+```markdown
+## ⚠️ 调试达到检查点（cap 3 hypothesis 失败）
+
+**SLUG**: <slug>
+**已尝试 hypothesis 数**: <hypotheses_tried>
+**原因**: <reason>
+
+📁 完整调试记录（含已 refuted 假设链）: `.context/debug/<slug>.md`
+
+---
+
+manager 的 3 轮 hypothesis 都被证伪。这通常意味着：
+- 假设方向不对（试试切换 mode 或换角度描述症状）
+- 缺关键证据（提供更多日志 / 复现步骤）
+- bug 在 manager 看不到的地方（环境 / 第三方依赖）
+
+下一步选项：
+1. 继续手动调试（参考 session.md 已 refuted 链，避免重复）
+2. 切换 mode（find_root_cause_only ↔ find_and_fix）
+3. 提供新症状信息后重启 `/ccg:debug`
+4. 终止
+```
+
+用 `AskUserQuestion` 询问。
+
+---
+
+## 关键规则
+
+1. **只 spawn manager 一次**：禁止主线自己跑多轮 hypothesis 循环（违反 fresh-context 隔离的 GSD ROI #3 设计）
+2. **不读 manager transcript**：主线只读返回的 ≤ 200 token 摘要 + （用户需要时）`.context/debug/<slug>.md` 文件
+3. **mode 默认 find_and_fix**：与 v3.0 行为一致（用户期待修好），仅在 `--mode=find_root_cause_only` 时仅找根因
+4. **cap 3 = 升级**：CCG 全体系硬规约，manager 不会偷偷继续；主线尊重 CHECKPOINT_REACHED 不重 spawn
+5. **session 文件持久**：中断恢复 / 用户审计的唯一通道
+6. **科学方法守门**：每个 hypothesis 必须 falsifiable（manager 会拒收 debugger 给的空话）
+
+---
+
+## 与 v3.0 的差异
+
+| 维度 | v3.0（已废） | v4.0（当前） |
+|------|-------------|-------------|
+| 调用模式 | 双模型并行单次诊断 | manager + debugger 双层 fresh-context |
+| 多轮 | ❌ 没有（一次性） | ✅ hypothesis 链，cap 3 |
+| 持久 session | ❌ 没有 | ✅ `.context/debug/<slug>.md` |
+| 科学方法 | ❌ 接受空泛假设 | ✅ falsifiable_test 强制 |
+| 主线 context 占用 | 高（吃两条诊断 stdout） | 极低（≤ 200 token 摘要） |
+| 修复模式 | 用户手动 | mode=find_and_fix 自动应用 + 验证 |
+| 中断恢复 | ❌ 无 | ✅ session 文件持久 |
+
+---
+
+## 工程参考
+
+- 子 agent 协议：`templates/commands/agents/debug-session-manager.md` + `templates/commands/agents/debugger.md`
+- helper schema / 决策树：`src/utils/debug-session.ts`
+- 移植来源：GSD `gsd-debug-session-manager` + `gsd-debugger`（`.ccg-research/02-subagent-matrix.md` Section 2.6）

package/templates/commands/enhance.md

@@ -0,0 +1,64 @@
+---
+description: 内置 Prompt 增强，将模糊需求转化为结构化任务描述
+---
+
+## Usage
+`/ccg:enhance <PROMPT>`
+
+## Context
+- Original prompt: $ARGUMENTS
+
+## Your Role
+You are the **Prompt Enhancer** - 将模糊的用户输入转化为清晰、可执行的任务描述。
+
+## Process
+
+### Step 1: 分析原始 Prompt
+
+分析用户输入，识别：
+- **意图**：用户想要完成什么？
+- **缺失信息**：哪些关键细节没有说明？
+- **隐含假设**：用户可能默认但未明说的内容
+- **上下文线索**：从对话历史和项目结构中提取相关信息
+
+### Step 2: 增强 Prompt
+
+基于分析结果，生成增强版 Prompt，包含：
+
+1. **明确的目标**：具体要实现什么
+2. **技术约束**：语言、框架、依赖等
+3. **范围边界**：做什么、不做什么
+4. **验收标准**：如何判断完成
+5. **相关上下文**：涉及的文件、模块、API 等
+
+### Step 3: 展示对比
+
+以下格式展示：
+
+```
+📝 原始 Prompt:
+<用户原始输入>
+
+✨ 增强后 Prompt:
+<增强版本>
+
+---
+是否使用增强版本？(Y/n)
+```
+
+### Step 4: 执行
+
+- 用户确认 → 使用增强版执行任务
+- 用户拒绝 → 使用原始 Prompt 执行
+- 用户修改 → 根据反馈调整后执行
+
+## 增强原则
+
+- **补全而非改变**：保留用户原意，只补充缺失信息
+- **具体而非泛化**：用具体的文件名、函数名、技术栈替代模糊描述
+- **简洁而非冗长**：增强后的 Prompt 应该精炼，不堆砌无用信息
+- **可执行而非描述**：输出应该是可以直接执行的任务，不是需求文档
+
+## Notes
+- 自动检测语言（中文输入 → 中文输出）
+- 也可通过在消息末尾添加 `-enhance` 或 `-Enhancer` 触发

package/templates/commands/execute.md

@@ -0,0 +1,380 @@
+---
+description: '多模型协作执行 - 根据计划获取原型 → Claude 重构实施 → 多模型审计交付'
+context_budget: orchestrator-15
+subagent_freshness: required
+---
+
+# Execute - 多模型协作执行
+
+$ARGUMENTS
+
+---
+
+## 核心协议
+
+- **语言协议**：与工具/模型交互用**英语**，与用户交互用**中文**
+- **代码主权**：外部模型对文件系统**零写入权限**，所有修改由 Claude 执行
+- **脏原型重构**：将外部模型的 Unified Diff 视为"脏原型"，必须重构为生产级代码
+- **止损机制**：当前阶段输出通过验证前，不进入下一阶段
+- **前置条件**：仅在用户对 `/ccg:plan` 输出明确回复 "Y" 后执行（如缺失，必须先二次确认）
+
+---
+
+## 调用通道路由（v4.1 Phase 20，CCG codeagent 退役）
+
+CCG v4.1 把 6 核心命令的"双模型并行"通道从 `Bash(codeagent-wrapper)` **默认切换**为 plugin spawn。判定流程：
+
+1. **优先 plugin spawn 路径**（默认）：用户已装 `codex@openai-codex` 和 `gemini@google-gemini` plugin → 用 `Agent(subagent_type="codex:codex-rescue")` + `Agent(subagent_type="gemini:gemini-rescue")` 并行 spawn，主线只接 plugin 自家 ≤200 token 摘要。
+2. **降级 codeagent-wrapper 路径**（v4.0 BC fallback）：plugin 未装 → fallback 到 `Bash(~/.claude/bin/codeagent-wrapper ...)`，与 v4.0 行为完全一致。
+
+**判断方法**：preflight 用 `Bash` 跑 `ls ~/.claude/plugins/ 2>/dev/null | grep -E '^(codex|gemini)@'`；两个 plugin 独立判定。
+
+**单一真相源**：`src/utils/plugin-detection.ts`（导出 `detectPlugin` / `detectPluginAvailability` / `bothPluginsInstalled`）。
+
+⚠️ Execute 命令在主线 context 内，**允许**调 `Agent(...)`——与 subagent "引擎层禁止嵌套 spawn" 约束不冲突。
+
+---
+
+## 多模型调用规范
+
+**工作目录**：
+- `{{WORKDIR}}`：**必须通过 Bash 执行 `pwd`（Unix）或 `cd`（Windows CMD）获取当前工作目录的绝对路径**，禁止从 `$HOME` 或环境变量推断
+- 如果用户通过 `/add-dir` 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
+- 如果无法确定，用 `AskUserQuestion` 询问用户选择目标工作区
+
+**调用语法**（v4.1 Phase 20 双通道）：
+
+**通道 A — plugin spawn（默认，原型生成）**：
+
+```
+Agent({
+  subagent_type: "<codex:codex-rescue|gemini:gemini-rescue>",
+  description: "Execute prototype: <backend|frontend>",
+  prompt: `ROLE_FILE: <角色提示词路径>
+
+<TASK>
+需求：<任务描述>
+上下文：<计划内容 + 目标文件>
+</TASK>
+
+OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
+Return ≤200 token structured summary (plugin-native protocol).
+`
+})
+```
+
+> Plugin 上下文不需要 `resume <SESSION_ID>` —— plugin advisor 自己管理跨调用 session（用 `description` 区分阶段即可）。
+
+**通道 B — codeagent-wrapper fallback**（plugin 未装时降级，并行用 `run_in_background: true`）：
+
+```
+# 复用会话调用（推荐）- 原型生成（Implementation Prototype）
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend <{{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}}> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"{{WORKDIR}}\" <<'EOF'
+ROLE_FILE: <角色提示词路径>
+<TASK>
+需求：<任务描述>
+上下文：<计划内容 + 目标文件>
+</TASK>
+OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
+EOF",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "简短描述"
+})
+
+# 新会话调用 - 原型生成（Implementation Prototype）
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend <{{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}}> {{GEMINI_MODEL_FLAG}}- \"{{WORKDIR}}\" <<'EOF'
+ROLE_FILE: <角色提示词路径>
+<TASK>
+需求：<任务描述>
+上下文：<计划内容 + 目标文件>
+</TASK>
+OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications.
+EOF",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "简短描述"
+})
+```
+
+**审计调用语法**（Code Review / Audit）：
+
+```
+Bash({
+  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend <{{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}}> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"{{WORKDIR}}\" <<'EOF'
+ROLE_FILE: <角色提示词路径>
+<TASK>
+Scope: Audit the final code changes.
+Inputs:
+- The applied patch (git diff / final unified diff)
+- The touched files (relevant excerpts if needed)
+Constraints:
+- Do NOT modify any files.
+- Do NOT output tool commands that assume filesystem access.
+</TASK>
+OUTPUT:
+1) A prioritized list of issues (severity, file, rationale)
+2) Concrete fixes; if code changes are needed, include a Unified Diff Patch in a fenced code block.
+EOF",
+  run_in_background: true,
+  timeout: 3600000,
+  description: "简短描述"
+})
+```
+
+**角色提示词**：
+
+| 阶段 | 后端 | 前端 |
+|------|-------|--------|
+| 实施 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/architect.md` | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/frontend.md` |
+| 审查 | `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md` | `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md` |
+
+**会话复用**：如果 `/ccg:plan` 提供了 SESSION_ID，使用 `resume <SESSION_ID>` 复用上下文。
+
+**事件驱动等待（v4.5.2 起）**：spawn 后主线说明 task-id 然后 **turn end**，引擎自动 `<task-notification>` 触发新 turn 处理结果。**不调 TaskOutput**。
+
+⛔ **禁止**：调 `TaskOutput({block: true, timeout: 600000})` 旧 freeze poll 模式 / Kill task。
+
+⚠️ **失败处理**：notification status=failed / exit ≠ 0 / parse 失败 → v1.7.87 标准 2-retry / 5s / 3-attempts；3 次全失败才降级单模型。
+
+---
+
+## 执行工作流
+
+**执行任务**：$ARGUMENTS
+
+### 📖 Phase 0：读取计划
+
+`[模式：准备]`
+
+1. **识别输入类型**：
+   - 计划文件路径（如 `.claude/plan/xxx.md`）
+   - 直接的任务描述
+
+2. **读取计划内容**：
+   - 若提供了计划文件路径，读取并解析
+   - 提取：任务类型、实施步骤、关键文件、SESSION_ID
+
+3. **执行前确认**：
+   - 若输入为"直接任务描述"或计划中缺失 `SESSION_ID` / 关键文件：先向用户确认补全信息
+   - 若无法确认用户是否已对计划回复 "Y"：必须二次询问确认后再进入下一阶段
+
+4. **任务类型判断**：
+
+   | 任务类型 | 判断依据 | 路由 |
+   |----------|----------|------|
+   | **前端** | 页面、组件、UI、样式、布局 | {{FRONTEND_PRIMARY}} |
+   | **后端** | API、接口、数据库、逻辑、算法 | {{BACKEND_PRIMARY}} |
+   | **全栈** | 同时包含前后端 | {{BACKEND_PRIMARY}} ∥ {{FRONTEND_PRIMARY}} 并行 |
+
+---
+
+### 🔍 Phase 1：上下文快速检索
+
+`[模式：检索]`
+
+**⚠️ 必须使用 MCP 工具快速检索上下文，禁止手动逐个读取文件**
+
+根据计划中的"关键文件"列表，调用 `{{MCP_SEARCH_TOOL}}` 检索相关代码：
+
+```
+{{MCP_SEARCH_TOOL}}({
+  query: "<基于计划内容构建的语义查询，包含关键文件、模块、函数名>",
+  project_root_path: "{{WORKDIR}}"
+})
+```
+
+**检索策略**：
+- 从计划的"关键文件"表格提取目标路径
+- 构建语义查询覆盖：入口文件、依赖模块、相关类型定义
+- 若检索结果不足，可追加 1-2 次递归检索
+- **禁止**使用 Bash + find/ls 手动探索项目结构
+
+**检索完成后**：
+- 整理检索到的代码片段
+- 确认已获取实施所需的完整上下文
+- 进入 Phase 3
+
+---
+
+### 🎨 Phase 3：原型获取
+
+`[模式：原型]`
+
+**根据任务类型路由**：
+
+#### Route A: 前端/UI/样式 → {{FRONTEND_PRIMARY}}
+
+**限制**：上下文 < 32k tokens
+
+1. 调用 {{FRONTEND_PRIMARY}}（使用 `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/frontend.md`）
+2. 输入：计划内容 + 检索到的上下文 + 目标文件
+3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
+4. **{{FRONTEND_PRIMARY}} 是前端设计的权威，其 CSS/React/Vue 原型为最终视觉基准**
+5. ⚠️ **警告**：忽略前端模型对后端逻辑的建议
+6. 若计划包含 `FRONTEND_SESSION`：优先 `resume <FRONTEND_SESSION>`
+
+#### Route B: 后端/逻辑/算法 → {{BACKEND_PRIMARY}}
+
+1. 调用 {{BACKEND_PRIMARY}}（使用 `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/architect.md`）
+2. 输入：计划内容 + 检索到的上下文 + 目标文件
+3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.`
+4. **{{BACKEND_PRIMARY}} 是后端逻辑的权威，利用其逻辑运算与 Debug 能力**
+5. 若计划包含 `BACKEND_SESSION`：优先 `resume <BACKEND_SESSION>`
+
+#### Route C: 全栈 → 并行调用
+
+1. **并行调用**（`run_in_background: true`）：
+   - {{FRONTEND_PRIMARY}}：处理前端部分
+   - {{BACKEND_PRIMARY}}：处理后端部分
+2. 用 `TaskOutput` 等待两个模型的完整结果
+3. 各自使用计划中对应的 `SESSION_ID` 进行 `resume`（若缺失则创建新会话）
+
+**务必遵循上方 `多模型调用规范` 的 `重要` 指示**
+
+---
+
+### ⚡ Phase 4：编码实施
+
+`[模式：实施]`
+
+**Claude 作为代码主权者执行以下步骤**：
+
+1. **读取 Diff**：解析外部模型返回的 Unified Diff Patch
+
+2. **思维沙箱**：
+   - 模拟应用 Diff 到目标文件
+   - 检查逻辑一致性
+   - 识别潜在冲突或副作用
+
+3. **重构清理**：
+   - 将"脏原型"重构为**高可读、高可维护性、企业发布级代码**
+   - 去除冗余代码
+   - 确保符合项目现有代码规范
+   - **非必要不生成注释与文档**，代码自解释
+
+4. **最小作用域**：
+   - 变更仅限需求范围
+   - **强制审查**变更是否引入副作用
+   - 做针对性修正
+
+5. **应用变更**：
+   - 使用 Edit/Write 工具执行实际修改
+   - **仅修改必要的代码**，严禁影响用户现有的其他功能
+6. **自检验证**（强烈建议）：
+   - 运行项目既有的 lint / typecheck / tests（优先最小相关范围）
+   - 若失败：优先修复回归，再继续进入 Phase 5
+
+---
+
+### ✅ Phase 5：审计与交付
+
+`[模式：审计]`
+
+#### 5.1 自动审计
+
+**变更生效后，强制立即并行调用** {{BACKEND_PRIMARY}} 和 {{FRONTEND_PRIMARY}} 进行 Code Review：
+
+1. **{{BACKEND_PRIMARY}} 审查**（`run_in_background: true`）：
+   - ROLE_FILE: `~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/reviewer.md`
+   - 输入：变更的 Diff + 目标文件
+   - 关注：安全性、性能、错误处理、逻辑正确性
+
+2. **{{FRONTEND_PRIMARY}} 审查**（`run_in_background: true`）：
+   - ROLE_FILE: `~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/reviewer.md`
+   - 输入：变更的 Diff + 目标文件
+   - 关注：可访问性、设计一致性、用户体验
+
+用 `TaskOutput` 等待两个模型的完整审查结果。优先复用 Phase 3 的会话（`resume <SESSION_ID>`）以保持上下文一致。
+
+#### 5.2 整合修复
+
+1. 综合 {{BACKEND_PRIMARY}} + {{FRONTEND_PRIMARY}} 的审查意见
+2. 按信任规则权衡：后端以 {{BACKEND_PRIMARY}} 为准，前端以 {{FRONTEND_PRIMARY}} 为准
+3. 执行必要的修复
+4. 修复后按需重复 Phase 5.1（直到风险可接受）
+
+#### 5.3 写入 phase-scoped SUMMARY.md（v4.0 Phase 2 状态机）
+
+**强制**：每完成一个 plan 后，写 `.context/<phase>/SUMMARY.md` 让上层 orchestrator（autonomous / team-exec）只读 frontmatter（< 200 tokens / phase）就能决策推进，避免接整段 builder stdout 污染主线 context。
+
+`<phase>` = 计划文件主名（如 `user-auth.md` → `user-auth`），与 `/ccg:plan` 写 CONTEXT.md 的目录约定一致。
+
+**SUMMARY.md frontmatter 必含字段（机器可读契约）**：
+
+```yaml
+---
+phase: user-auth
+plan: .claude/plan/user-auth.md
+provides: [<本 phase 产出的能力或模块名>]
+affects: [<受影响的文件/模块>]
+key_files: [<本 phase 实际改动的关键文件>]
+completed: true
+completed_at: <ISO8601 时间>
+notes: <一行收尾说明，可省略>
+---
+```
+
+字段语义：
+- `provides` — 下游 phase 可引用的输出（API/模块/契约）
+- `affects` — 横向耦合面，给 orchestrator 做依赖图用
+- `key_files` — 真正落盘的产物文件路径
+- `completed` — `true` 表示 acceptance 全过；`false` 表示 partial（需要主线接手）
+
+由 Claude 用 Write 工具直接落盘 `<WORKDIR>/.context/<phase>/SUMMARY.md`。目录不存在自动创建。**外部模型不写**——这是主线的契约边界。
+
+#### 5.4 交付确认
+
+审计通过且 SUMMARY.md 写入后，向用户报告：
+
+```markdown
+## ✅ 执行完成
+
+### 变更摘要
+| 文件 | 操作 | 说明 |
+|------|------|------|
+| path/to/file.ts | 修改 | 描述 |
+
+### 审计结果
+- {{BACKEND_PRIMARY}}：<通过/发现 N 个问题>
+- {{FRONTEND_PRIMARY}}：<通过/发现 N 个问题>
+
+### Phase 状态
+- `.context/<phase>/SUMMARY.md` 已写入（completed: true / false）
+
+### 后续建议
+1. [ ] <建议的测试步骤>
+2. [ ] <建议的验证步骤>
+```
+
+---
+
+## 关键规则
+
+1. **代码主权** – 所有文件修改由 Claude 执行，外部模型零写入权限
+2. **脏原型重构** – 外部模型的输出视为草稿，必须重构
+3. **信任规则** – 后端以 {{BACKEND_PRIMARY}} 为准，前端以 {{FRONTEND_PRIMARY}} 为准
+4. **最小变更** – 仅修改必要的代码，不引入副作用
+5. **强制审计** – 变更后必须进行多模型 Code Review
+
+---
+
+## 使用方法
+
+```bash
+# 执行计划文件
+/ccg:execute .claude/plan/功能名.md
+
+# 直接执行任务（适用于已在上下文中讨论过的计划）
+/ccg:execute 根据之前的计划实施用户认证功能
+```
+
+---
+
+## 与 /ccg:plan 的关系
+
+1. `/ccg:plan` 生成计划 + SESSION_ID
+2. 用户确认 "Y" 后
+3. `/ccg:execute` 读取计划，复用 SESSION_ID，执行实施