用途：适用于任何技术问题，包括测试失败、生产缺陷、异常行为、性能问题、构建失败和集成问题；在时间紧迫、看似只需一处快速修改、已多次尝试修复或问题尚未理解时尤其适用。
核心原则：未完成根因调查前不得提出修复，症状级修补视为失败。
四个阶段（须依次完成）：一、根因调查：先保存完整错误输出再重试，完整阅读堆栈信息，稳定复现，检查近期变更（大范围回归可用 git bisect，先写一行复现脚本，再执行 git bisect start、git bisect bad、git bisect good <sha>、git bisect run <reproducer>），在多组件系统中于各组件边界加插桩日志，并沿调用栈向上追溯数据流。二、模式分析：寻找同类可运行示例，完整阅读参考实现，列出全部差异并理解依赖。三、假设与验证：写出单一明确假设，做最小改动单变量验证，未验证通过则重新提出假设。四、实现：先写失败测试，再实施单点修复，最后验证测试通过且未破坏其他测试。
若修复尝试达三次以上失败，应停止并质疑架构，与人类协作者讨论；同时提供红旗信号与常见借口对照表，并附 root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md 等配套技术文档，以及 tdd-mutation、verification-before-completion 等相关技能。
限制：资料未提供具体价格、平台支持范围或安装步骤信息，暂未提供。