用途
fix 是一个面向缺陷诊断与修复的技能，核心目标是通过根因分析定位问题，并在修复后进行验证。它适用于已经存在具体问题信号的场景，例如明确的失败行为、运行时错误、测试回归，或可复现的缺陷报告。
适用范围门控
在开始之前，必须确认以下条件全部成立：
- 存在具体问题信号：已识别清晰的失败行为、错误或回归，且有足够证据（日志、堆栈跟踪、失败测试或可复现步骤）开始诊断。
- 修复路径可能局限：问题看起来局限在较小范围，不预期跨系统重新设计或迁移，架构风险低到中等，无需基础性改动，也不预期分阶段发布或特性开关策略。
- 验证路径直接：复现和修复后检查可在实际范围内运行，成功标准可直接验证。
如果任一条件不满足，应升级到 brainstorm 或 write-plan。
硬性停止与升级条件
出现以下任一情况时，应立即停止并切换到规划：
- 经过聚焦调查后根因仍不明确。
- 修复需要横切架构或数据模型变更。
- 范围扩展为大型重构或多模块迁移。
- 涉及安全或合规敏感行为。
- 验证发现广泛回归，需要分阶段缓解。
- 多次修复尝试失败，未能收敛到根因。
升级动作：停止所有实施活动，并输出以下确切消息：
"This fix exceeds safe single-pass debugging limits. Ask, Recommend brainstorm or write-plan first to define phased diagnosis, implementation, and risk controls."
工作流程
第 1 步：接收与上下文梳理
理解所报告的缺陷，并定义明确的预期行为。收集或确认最小缺陷报告字段：标题、预期行为、实际行为、复现步骤、证据（日志、跟踪、截图、失败测试输出）、环境（分支/操作系统/运行时/版本，如相关）、影响/严重程度。
只加载与缺陷相关的项目上下文：如果存在 docs/SUMMARY.md，先阅读它；只加载任务相关的详细文档；优先参考 Code Standard 文档以了解实现约定。如果文档与代码或用户意图冲突，在广泛改动前使用可用的输入/提问工具。
第 2 步：复现与诊断
一致地复现问题；定位失败点（文件/函数/行范围/子系统）；追踪控制流与数据流以识别根因；形成修复假设并确认其能解释观察到的行为。
指南：阅读周边代码，而不仅是失败行；优先根因修正而非症状修补；仅在需要时添加临时诊断，用后移除。
第 3 步：判断小修还是大修
在编码前对工作进行分类：
小修（继续使用本技能）——多数条件成立：根因清晰且已验证；改动面窄（通常几个文件）；回归风险有限且可快速测试。
较大或有风险的修复（升级到 brainstorm 或 write-plan）——任一条件成立：根因不确定；多个子系统必须一起改动；需要迁移、发布排序或广泛重构；风险无法在单次处理中合理控制。
如果是较大修复，遵循硬性停止与升级条件。
第 4 步：实施（小修路径）
陈述简短的 1-3 条实施计划；应用解决根因的最小针对性改动；严格保持范围，避免无关重构；在适用时添加或更新回归测试。
第 5 步：验证
按递增范围运行验证：针对改动行为/模块的聚焦检查；邻近回归检查；按需运行相关项目检查（lint/typecheck/tests/build）。
只有满足以下条件，修复才算完成：复现不再失败；预期行为得到确认；未引入关键回归。如果验证表明影响更广，升级到 brainstorm 或 write-plan。
第 6 步：完成与报告
提供简洁的完成报告，包含：根因、改动内容、为何此修复有效、执行的验证及结果、残余风险/后续事项。如果行为或文档相关规则发生变化，更新最小相关文档。如果架构发生变化，本应已升级。
规则
- 关键上下文缺失时不要猜测。
- 始终优先根因修复。
- 保持影响范围最小。
- 未经验证不得标记完成。
- 当范围或风险超出本技能时，尽早升级。
可选缺陷报告模板
当报告不完整时使用：
标题：
预期行为：
实际行为：
复现步骤：
错误日志/堆栈跟踪：
环境：
影响/严重程度：
附加上下文：