fixbugs

name	fixbugs
description	批量验证并修复 bug 清单，完整执行 验证→修复→构建→提交 管线
metadata	{"short-description":"批量修复 bug 完整管线"}

批量修复 bug 管线。必须实施实际代码修复，禁止止步于计划、分析或验证文档。

流程

1. 收集 Bug 清单

• 从用户消息、粘贴的列表或指定文件中提取 bug 条目
• 每个 bug 应包含：描述、相关文件/模块、严重程度（如有）
• 清单不明确时（复现步骤、期望行为、运行参数等），先向用户确认，禁止猜测。

2. 逐一验证（先分诊后修复）

对每个 bug：

1. 读取相关源码，确认 bug 是否真实存在
2. 如果 bug 不存在或已修复，标记为 已排除 并说明原因
3. 如果 bug 确认存在，标记为 已确认 并简要说明根因（专业代码库要仔细核实 bug 位置）

输出一份简短的分诊摘要表（确认 / 排除），然后立即开始修复。不要停在分析或报告阶段。

3. 分批实施修复

将已确认的 bug 按模块/文件分批，每批不超过 5 个，确保构建验证颗粒度合理。

对每批：

1. 实施代码修复——偏好最小上游修复，而不是下游绕行；单行修改足够时不要过度工程化
2. 格式化修改的文件（排除 vendor/）：

   git diff --name-only --diff-filter=d HEAD | grep -E '\.(h|cpp)$' | grep -v '^vendor/' | xargs -r "C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/Llvm/bin/clang-format.exe" -i
   

3. 构建验证：执行 build skill 的 Editor 构建
4. 如果构建失败，立即修复编译错误再继续
5. 提交该批次：git commit 格式为 fix(<模块>): <简述>

4. 输出修复报告

全部完成后输出摘要：

Bug	状态	修复说明	提交
#1	已修复	...	abc1234
#2	已排除	非 bug，逻辑正确	—

纪律条款

• 禁止止步于规划。 分诊摘要产出后必须立即进入修复阶段。
• 禁止止步于验证 / 分析文档。 必须实施实际代码修复。
• 遇到不确定信息必须向用户提问（复现步骤、期望行为、运行参数等），禁止猜测或脑补。
• 偏好最小上游修复，避免下游绕行；优先定位并修正根因而不是症状。
• 保留或加强测试；未经用户明确许可禁止删除或弱化测试。必要时为回归加新测试，但保持实现最小。
• 修复完成后如果有单元测试，运行测试确认无回归。