# Strategy: Direct Fix — 直接修复

> 适用于范围清晰、单文件的简单 bug 修复。Claude 独立完成，不调用外部模型。

## 适用条件
- 复杂度 S（单文件，<30 行变更）
- 错误信息或复现路径明确
- 风险 low 或 medium

---

## 工作流状态机

[phase-state:1-locate]
当前阶段：定位问题代码
Gate: 项目上下文已获取 ✓（由 /ccg Phase 1 完成）
📍 Next: 找到问题代码后进入诊断阶段
[/phase-state:1-locate]

[phase-state:2-diagnose]
当前阶段：诊断根因
Gate: 已找到相关代码 ✓
📍 Next: 确定根因后进入修复阶段
[/phase-state:2-diagnose]

[phase-state:3-fix]
当前阶段：应用修复
Gate: 根因已确定 ✓
📍 Next: 修复完成后进入验证阶段
[/phase-state:3-fix]

[phase-state:4-verify]
当前阶段：验证修复
Gate: 修复已应用 ✓
📍 Next: 验证通过后报告结果，建议提交
[/phase-state:4-verify]

---

## 阶段详情

### Phase 1: 定位 [required]

1. 从用户描述中提取关键信息：
   - 错误消息（如果有）
   - 发生位置（文件、功能、页面）
   - 复现步骤

2. 搜索相关代码：
   - 有错误消息 → `Grep` 搜索错误文本
   - 有文件/函数名 → 直接 `Read` 目标文件
   - 信息不足 → 用 MCP 搜索工具或 `Grep` 按关键词搜索

3. 读取找到的代码文件，理解上下文

### Phase 2: 诊断 [required]

1. 分析代码逻辑，找到 bug 的根因
2. 如果有多个可能原因，按可能性排序
3. 简要说明诊断结果：
   ```
   🔍 诊断
     文件: [path:line]
     根因: [一句话说明]
     修复方案: [一句话说明]
   ```

### Phase 3: 修复

1. 应用最小修复（只改必要的部分）
2. 如果项目有测试 → 运行相关测试
3. 如果没有测试 → 建议但不强制添加

### Phase 4: 验证

1. `git diff` 展示变更
2. 确认修复合理性：
   - 变更范围是否最小？
   - 是否引入新问题？
   - 边界条件是否考虑？
3. 如果修复涉及认证/输入处理/安全相关代码 → `/verify-security` 安全扫描
4. 输出结果：
   ```
   ✅ 修复完成
     变更: [N] 文件，[M] 行
     根因: [简述]
     修复: [简述]
     📍 Next: 可以用 /ccg:commit 提交
   ```

---

## 升级规则

如果在 Phase 1-2 中发现以下情况，建议升级：
- 涉及 3+ 文件 → 升级到 `guided-develop`
- 原因不明，需要深度调试 → 升级到 `debug-investigate`
- 涉及架构问题 → 升级到 `refactor-safely`

告知用户并等待确认后切换策略。

---

## 铁律

- **不可在未读代码的情况下猜测修复方案** — Phase 1 必须实际读取代码
- **最小修复原则** — 只改导致 bug 的部分，不做"顺手重构"
- **不可跳过诊断直接改代码** — 即使"一眼看出问题"，也要经过 Phase 2 确认根因