fix-review

name	fix-review
description	修复 Code Review 发现的问题，支持按严重级别分级处理（block/all/discuss），架构视角修复而非补丁式 Patch。当需要处理 /code-review 报告中的问题时使用。
argument-hint	<block|all|discuss> [#PR-N | @文件路径 | 留空用当前上下文]
model	opus

Fix Review — Code Review 问题修复

处理 /code-review 输出的问题报告。核心原则：验证先行 + 全局修复策略 + 禁止逐个打补丁。

---

Step 0：解析参数

修复模式（第一个 token）：

参数	修复范围	说明
block	仅 🔴 问题	阻塞合并的必须修复项（默认）
all	🔴 + 🟡	阻塞问题 + 建议改进
discuss	架构讨论项	interview 模式讨论方案，不直接改代码

报告来源（剩余部分）：

格式	说明
#PR-<number>	从 GitHub PR review comments 获取
@<文件路径>	从指定文件读取
留空	从当前对话上下文查找

---

Step 1：定位审查报告

1. 根据报告来源定位：

   • #PR-N：gh api repos/{owner}/{repo}/pulls/N/comments 获取 PR comments
   • @<path>：直接读取文件
   • 留空：查找当前对话中 /code-review 的输出
   • 均未找到 → 请求用户提供报告或运行 /code-review

2. 解析报告结构（对应 /code-review 输出格式）：

   • 🔴 必须修复：编号 + 文件:行号 + 问题描述 + 修复建议
   • 🟡 建议改进：同上
   • 🟢 值得肯定：无需处理
   • 测试覆盖评估：可能含需补充的测试用例

3. 根据修复模式筛选目标问题集合。

---

Step 2：进入 Plan 模式

使用 EnterPlanMode。所有验证和方案设计在 Plan 模式内完成，审批后才可编码。

---

Step 3：验证问题真实性（对每个问题必做）

Code Review 可能误判，修复不存在的问题比不修复真实问题更危险。

3.1 读取原始代码

读取报告指出的文件和行号的完整上下文（至少前后 30 行）。跨模块问题须追踪完整调用链。

3.2 验证清单

• 问题代码是否存在？（可能已被其他改动修复）
• 问题描述是否准确？（代码实际行为是否如报告所述）
• 问题是否有真实影响？（bug/性能退化/维护困难等）
• 建议方案是否最优？（还是有更好的全局方案）
• 问题归属？（本项目 / 协议问题 / 上游依赖）

3.3 验证结论

结论	后续行动
✅ 确认存在	进入 Step 4 修复
⚠️ 部分成立	修正范围后进入 Step 4
❌ 误判	跳过，报告中说明
🔄 已修复	跳过，报告中确认
🔼 上游问题	输出 Bug Report，不修改上游

输出验证摘要（每个问题一行），等待用户确认后继续。

---

Step 4：设计修复策略（针对确认的问题）

禁止逐个问题打补丁，必须先建立全局修复视图。

4.1 问题归类与关联分析

• 同文件合并：一次修改中统一解决
• 同模块归组：优先一起处理
• 因果关系：某些问题可能是其他问题的症状
• 修改顺序：先底层（协议/DTO）→ 中间层（服务/工具）→ 上层（测试/UI）

4.2 方案设计原则

• 根因修复：不做 patch，修正问题根源
• 最小侵入：不引入新的架构债务
• 全局一致：搜索类似场景的既有实现作为参考
• 副作用评估：列出修改可能影响的其他文件
• 协议兼容：涉及协议类型的修改需对照协议规范确认

项目特有架构原则参见 {baseDir}/resources/<project>.md。

4.3 输出修复计划

按 Group 归组输出，含关联影响和修改文件清单。使用 ExitPlanMode 提交计划等待审批。

---

Step 5：执行修复（审批后）

5.1 修改前

• 读取待修改文件的完整内容（不只看 diff）
• 搜索项目中类似实现作为风格参考
• Grep 确认没有遗漏的关联引用

5.2 修改执行

项目特有编码规范和验证命令参见 {baseDir}/resources/<project>.md。

5.3 修改后立即验证

每组修改完成后运行项目对应的验证命令。验证失败须修复后重新验证，不可跳过。

---

Step 6：讨论模式（仅 discuss 参数）

不执行代码修改，进入 interview 模式：

1. 逐条讨论架构决策项，提出 2-3 个方案 + trade-off 分析
2. 使用 AskUserQuestion 与用户深入讨论
3. 达成共识后：需要改代码 → 按 Step 4-5 执行；暂不修改 → 记录决策理由
4. 涉及协议变更 → 引导走 /add-feature 协议先行流程

---

Step 7：输出修复总结

## 验证结果

| 编号 | 问题 | 验证结论 |
|------|------|---------|
| 🔴1 | xxx | ✅ 已修复 |
| 🔴2 | xxx | ❌ 误判跳过 |

## 修改文件清单

| 文件 | 修改类型 | 关联问题 |
|------|---------|---------|

## 验证状态

- [ ] lint / 类型检查通过
- [ ] 涉及模块的测试通过
- [ ] 全量测试通过

## 备注

- [误判说明] [协议兼容性确认] [上游 Bug Report] [遗留讨论项]

---

反模式（严格禁止）

• 不验证就修复 — 不确认问题是否真实存在就改代码
• 逐个打补丁 — 不做全局分析，头痛医头脚痛医脚
• 为修复而修复 — 问题不存在也硬改交差
• 引入新问题 — 修复过程中引入新的类型错误/硬编码/分层违规
• 忽略关联影响 — 改了底层不更新下游引用
• 跳过验证 — 改完不运行 lint/typecheck/test
• discuss 模式直接改代码 — 讨论项需要共识，不能擅自决定