缺陷修复闭环

把"这个缺陷修好了没有"变成一个有复现、有失败测试、有最小改动、有验证证据、有回归范围的结论。本 skill 处理的是原因已经明确的缺陷——已经知道大概错在哪、要修什么，缺的是把修复过程做扎实、做可核查。

先确定任务边界

• 原因未知就不要走这条路。 只知道"某接口偶发 500"、还没定位到具体代码或数据问题，先走 systematic-debugging 做根因定位；原因明确之后回到本 skill 做修复与验证。
• 线上正在出故障时，先止血与分级（incident-response），止血完成后按正常缺陷流程修复。
• 本 skill 只做与该缺陷相关的修改。不顺手重构、不格式化文件、不升级依赖、不改无关配置，除非用户明确同意扩大范围。
• 涉及数据库结构或存量数据时，修复方案要遵守 database-migration 的分阶段口径，不在缺陷修复里夹带一次性破坏性变更。

修复路径

1. 收敛描述、定级、锁范围。 把"偶尔会报错"这类模糊描述收敛成可复现条件：环境、数据、入口、操作序列、期望结果与实际结果。按影响面、严重度、紧急度、是否阻塞主流程、有无数据错误定级，据此决定处理优先级。同时明确这次修什么、不修什么。分级维度与范围锁定判据见 references/defect-triage.md。
2. 先复现，再动手。 用上一步的条件把缺陷复现出来，并把复现固定成一个失败测试（或等价的、可重复执行的最小复现证据：一段脚本、一条查询、一次可重放的操作序列）。先有失败测试，再改代码。
   • 失败测试的价值不在于"符合流程"，而在于它同时给出了缺陷的判据（失败长什么样）与修复的验收条件（通过意味着什么）。
   • 确实无法写成自动化测试时，也要留下可重复执行的最小复现证据，并在记录里写明为什么不能自动化。
   • 复现不了时不要硬猜着改代码，走第 6 步的"未复现"路径。
3. 定位到最小修改点，做最小改动。
   • 只改与缺陷相关的最小范围：一个判断条件、一处边界、一个空值分支、一处配置。
   • 不做顺手的重构、不做格式化、不升级依赖、不改无关命名。这些改动会把修复的验证边界搅浑，让评审无法判断"是修复起作用还是重构起作用"，也会放大回归风险。
   • 需要扩大范围时先向用户确认：说明为什么最小改动做不到、扩大后会多影响哪些代码、需要补哪些回归。
   • 修改点要能一句话说清"改了哪一行、为什么这一行能消除缺陷"。
4. 推导回归范围。 不要用"跑一遍全量测试就行"代替推导——全量测试跑不出的东西（时序、并发、权限、数据迁移相关行为）恰恰最容易漏。
   • 从影响面出发列出：受影响的调用方、共享工具或公共方法、边界条件与空值、并发与时序、权限与多租户、数据迁移与兼容、以及仓库里与缺陷相关的既有用例。
   • 逐项决定"要跑什么、为什么"，能落到具体用例就写具体用例名。清单与做法见 references/fix-and-regression.md。
5. 给出验证证据。 修复后要有能证明缺陷已消失的证据，并按缺陷影响面选择层次（单元 → 组件 → 端到端，影响面小的不必强求端到端，影响主流程的必须端到端）：
   • 失败测试从红变绿的前后对照（修复前失败输出 + 修复后通过输出）。
   • 原始复现步骤的前后对照（修复前能复现、修复后不能复现）。
   • 关键日志或查询结果的前后差异。
   • 明确说明无法验证的部分：哪些环境拿不到、哪些场景没法构造、哪些结论只是推断。
6. 区分"缺陷已修复"与"未复现"。 复现不出来时，如实标注为未复现：给出已尝试的复现条件与环境、下一步要收集什么证据（更完整的日志、用户环境信息、数据快照、监控数据窗口）、以及建议的观察期。未复现不等于已修复，不得当成修好了关闭。
7. 写修复记录、核对关闭条件。 用 assets/defect-fix-record-template.md 落记录，最后逐项核对关闭条件。

硬性禁止

• 禁止为了让测试通过而删、跳过、禁用或弱化测试：禁止删除测试用例，不改 skip/ignore/xfail 标记，不缩小断言范围，不把断言改宽以掩盖缺陷（例如把精确比对改成"不为空"、把超时阈值调大以绕开问题）。
• 禁止在修复里顺手扩大范围：重构、格式化、依赖升级、无关清理都先确认。
• 禁止用"重跑一次通过了"当作缺陷已修复的证据：不稳定通过不是修复。
• 不得声称未运行的测试已通过。 只报告真正执行过的命令与真实输出；未运行的沿用"未运行"标注。

交付内容

用简洁中文给出：

1. 缺陷与分级：编号、级别、影响面、处理优先级。
2. 复现条件与失败测试：如何复现、失败测试在哪个文件、修复前的失败长什么样。
3. 根因结论与置信度：结论是什么、依据是什么、置信度（确证 / 高度可能 / 推断）。
4. 最小改动：改了哪些文件与行为，以及刻意没做的事（明确列出被排除的重构与清理）。
5. 回归范围与结果：列出的范围、实际跑了什么、结果如何。
6. 验证证据：测试与复现步骤的前后对照、日志差异、无法验证的部分。
7. 关闭条件核对：逐项打勾，写出结论（可关闭 / 不可关闭 + 缺什么）。
8. 遗留风险与后续项：未覆盖的场景、需要单独立项的技术债。

关闭条件

缺陷可以关闭，当且仅当：

• 验证通过：失败测试已转为通过，或有等价的、可重复执行的复现证据证明缺陷不再出现。
• 回归通过：影响面推导出的回归范围已全部执行且通过。
• 无相关新增失败：没有因为这次修复引入与缺陷相关的新失败；无关的既有失败要单独说明，不能算作本次修复的锅。
• 修复记录完整：编号、级别、复现条件、根因与置信度、最小改动、回归范围、验证证据、未验证项、关闭条件核对齐全。

任一项不满足都写"不可关闭"并说明缺什么，不要用"基本没问题"这类表述代替结论。不夸大：只报告真正执行过的验证，未复现与未验证的项如实标注，不用"应该已修复"代替结论。

与相邻 skill 的边界

• 原因未知的故障排查与根因定位：systematic-debugging。原因未知走它，原因明确走本技能。
• 线上故障现场止血与严重度分级：incident-response。止血后回到本 skill 做修复闭环。
• 设计或补单元测试、用例清单设计：code-testing。本 skill 只写针对该缺陷的失败测试，不做测试体系设计。
• 代码质量与安全深度审查：code-review-deep-zh。
• 行为保持的重构：behavior-preserving-refactor。修复中想顺手重构时，那件事属于它，且要先确认。
• 发布准备与准出检查：release-readiness。本 skill 的修复结果可以作为发布材料的一部分，但不代替准出结论。