| name | x-fix |
| description | Bug 修复执行 skill。分三种入口：
1. 用户直接报告 Bug → 定位根因 → 修复 → 产出 fix-report-*.md 或 fix-note-*.md（无需 CR 报告）
2. 有 x-cr 的 CR 报告 → 按报告逐条修复 → 回写同一份 `reports/cr/cr-report-*.md` 主档并产出修复记录
3. 有 x-verify / x-qa-gate fail 报告 → 按发现清单一次批量修复，产出逐条处置表，交回 gate 增量复审
触发方式："x-fix"、"修一下这个 bug"、"这个功能坏了"、
"按 CR 报告修复"、"把 CR 问题修了"。
|
x-fix 修复执行框架
模式判断（第一步必做）
按输入来源选择模式：
- 有 x-verify / x-qa-gate fail 报告（包含
verify-report-*.md，或 RC/R1/R2/R3 reviewer mini-report 发现清单）→ 加载 references/qa-gate-fix-mode.md
- 有 x-cr CR 报告（用户在指令中提供了
reports/cr/cr-report-*.md 路径，或提到"按 CR 报告"、"CR 问题"）→ 加载 references/cr-fix-mode.md
- 用户直接描述 bug 或问题现象 → 加载
references/bug-fix-mode.md
修复报告模板（模式 1 产出物）
所有修复完成后，必须在 reports/fix/ 产出报告或修补单：
reports/fix/fix-report-YYYYMMDD-HHmmss.md：CR 驱动、跨文件、需要完整闭环的修复reports/fix/fix-note-YYYYMMDD-HHmmss.md：人工发现的单点小修补
# [Bug 名称] 修复报告
> 修复时间：YYYY-MM-DD HH:mm
> 修复人：Claude (x-fix)
## Bug 描述
[用户描述的问题现象]
## 根因分析
[定位到的根本原因]
## 修复方案
[具体如何修复]
## 修改文件
| 文件 | 修改内容 |
|------|----------|
| `src/xxx.ts` | [描述改动] |
## 测试验证
[验证方式：无/本地测试/用例说明]
报告路径统一写入 reports/fix/，文件类型由修复范围决定。
如果是单点人工修补，优先写 fix-note-YYYYMMDD-HHmmss.md；如果是完整 bug 修复或 CR 驱动修复，优先写 fix-report-YYYYMMDD-HHmmss.md。
CR 报告修复（模式 2）输出
执行完 references/cr-fix-mode.md 的流程后，在对话中输出：
✅ 修复完成
- 已修复：X 条
- 无需修复（误报）：X 条
- 已跳过（P3）：X 条
- 修改文件：X 个（列出文件路径）
输出末尾追加：📄 报告已更新：<完整文件路径>
x-cr / x-qa-gate 边界
- x-cr 报告来自手动软件正确性调查，x-fix 按
references/cr-fix-mode.md 修复并回写同一份 reports/cr/cr-report-*.md。
- x-verify / x-qa-gate 报告来自自动门禁，x-fix 按
references/qa-gate-fix-mode.md 一次批量修复本轮发现清单，修完交回触发 gate 做增量复审。
- 当前自动门禁链路是
x-dev -> x-verify -> x-qa-gate -> x-fix。
- README
risk: Q0/Q1 在 verify 通过后交付；Q2 进入 RC；Q3 进入 R1→R2→R3。
- 手动正确性调查和 CR 复查由用户明确触发 x-cr。
单次修复的边界约束
- 不跨任务：一次 x-fix 调用只处理当前任务的问题，不得修复其他任务范围内的代码
- 不扩大修改：不得"顺便"重构其他代码、改无关风格、补其他任务的遗漏
- 不吞错：修复中遇到文件不存在、行号完全错位等异常 → 在报告中标记
➖无需修复 并继续下一条，不允许静默跳过
Gate 回流：批量修 + 增量复审
x-fix 不只服务于 bug 报告与 cr-report，也接收来自 x-verify / x-qa-gate reviewer（RC/R1/R2/R3）的 fail 触发。执行结构是一次批量修完本轮全部发现，交回 gate 做增量复审；x-fix 不再自行判定回流目标（旧"回 R1"规则已废除，增量复审与熔断逻辑见 skills/x-qa-gate/SKILL.md「增量复审」）。
批量修协议
- 输入 = reviewer mini-report 的完整发现清单（F1..Fn）或 verify 报告的全部 fail 命令。
- 按严重度处置：P0 全修；P1 逐条修复或写豁免理由；P2 只登记不修。
- 每修一个 P0 必须留一条可复跑反例（单元/集成测试断言或 verify 脚本步骤），防止回归。
- 修完自跑受影响验证（相关测试 + dev-report 命令中受影响条目），不许带着红灯交回复审。
- 产出逐条处置表（见下），控制权交回主 agent 触发增量复审。
fix-attempts 3 轮共享上限
fix-counter 文件协议（与 x-verify / x-qa-gate 共享）：
- 路径：
dev-pipeline/tasks/<task>/reports/.fix-counter
- 格式：单行 ASCII 整数 + 行尾换行（如
2\n）
- 语义：批量修轮数（一轮 = 一份发现清单的整体修复），不按问题条数计
- 读取：
c=$(cat reports/.fix-counter)；不存在则视为 0
- 递增（x-fix 的责任）：进入本轮批量修前
echo $((c+1)) > reports/.fix-counter（先 +1 再修，避免崩溃后死循环）
- counter >= 3 → 不进 fix，直接生成
reports/fix-blocked-report.md 列出积压问题，要求用户决策（继续 / 修改需求 / 放弃）
- 重置（x-qa-gate 在 Gate ② 最终 pass 后做）：
echo 0 > reports/.fix-counter
fix 报告路径与处置表
| 触发节点 | fix 报告路径 |
|---|
| x-verify fail | reports/fix/fix-verify-YYYYMMDD-HHmmss.md |
| Gate ② reviewer fail（RC/R1/R2/R3） | reports/fix/fix-gate-r<轮次>-YYYYMMDD-HHmmss.md |
报告核心是逐条处置表：
| # | 严重度 | 处置 | 说明 | 反例/验证 |
|---|--------|------|------|-----------|
| F1 | P0 | ✅ 已修 | 扩展 SQLSTATE 分类 | `cargo test -p x classify_` 新增断言 |
| F2 | P1 | ➖ 豁免 | 理由：... | — |
| F3 | P2 | 📝 登记 | 不修 | — |
旧路径 reports/fix/fix-report-*.md 与 fix-note-*.md 仍保留，只用于直接 bug fix 模式（用户报告 bug 走原流程）。
子模式
详见 references/qa-gate-fix-mode.md，定义 verify-fix / gate-fix 两种子模式的输入识别与特殊规则。
