用途：这是一套面向代码缺陷的根因排查协议，核心原则是必须先找到根因再提修复，仅治症状视为失败。
主要能力与用法：分为四个阶段。第一阶段根因调查：完整读报错与堆栈、稳定复现问题、检查最近变更（diff、依赖、配置），在多组件系统中于各组件边界加诊断埋点取证。第二阶段模式分析：找同类可用代码作参照，逐项列出差异并理解依赖。第三阶段假设与测试：一次只形成一个明确假设，做最小改动验证，通过才进入下一阶段，否则另立新假设而非叠加修复。第四阶段实现：先写最小失败测试，再实现单点修复，验证通过并回归其他测试。
调用方式：说“Use systematic-debugging on <symptom>”，并一次性提供完整报错或堆栈、复现步骤或失败命令及预期与实际行为、最近的变更信息。它也可作为 problem-handling 中诊断阶段（A2，确认为技术代码缺陷时）运行，无需单独调用；若问题尚未确认为代码缺陷，应先回到 problem-handling。
适用场景：测试失败、线上Bug、意外行为、性能问题、构建失败、集成问题；尤其在时间压力大、看似“只改一处就够”、已多次尝试修复无效、未完全理解问题时不跳过。
限制与边界：不适用于功能需求、UX/设计意见、产品优先级判断、已记录的正常行为，或尚无任何可观测性（无法复现、无法埋点、无日志）的情况。后者应记录调查内容、补充监控并交回，不做猜测式修复。若修复三次以上仍失败，应停下与人对架构进行质疑，而非继续打补丁。相关技巧包括 root-cause-tracing.md、defense-in-depth.md、condition-based-waiting.md，位于同目录。