用途：在测试失败原因不明、构建报错、行为与预期不符、此前修复无效，或忍不住“先随便试一下”时，按此协议排查问题，尤其适用于压力大、多次修复失败或尚未完全理解问题的情形。
核心原则：在完成根因调查之前不做任何修复。
主要阶段： 一、根因调查。完整阅读错误信息、警告与调用栈，记录确切文件路径、行号、输入和错误码；尝试稳定复现并明确步骤；检查出问题前不久的改动，包括 git diff、近期编辑、配置、环境和依赖变化；症状出现在栈深处时反向追溯错误值或错误状态来源，修源头而非症状；对跨边界（CLI 到工具到服务、UI 到处理器到存储）的故障，逐层检查输入输出与配置环境传递，必要时加最小诊断日志定位首个出错的层。 二、模式分析。先弄清“正确”是什么样：在同一代码库找可用的类似代码，完整对照参考模式，列出所有有意义的差异，检查依赖、假设、设置与所需上下文，不因差异小而忽略。 三、假设与验证。一次只用一个假设，明确写出“我认为 X 是根因，因为 Y”，做最小改动或探测来验证；失败则重新提出假设，而不是叠加更多猜测；仍不理解就如实说明并询问用户。 四、实现。先构造尽量小的可复现失败用例，实施一个针对根因的修复，验证问题已解决并检查是否引入回归。
三次修复规则：若三次修复均失败，应停下质疑架构，未经与用户讨论不得尝试第四次。架构问题的迹象包括每次修复都在别处暴露新问题、修复需要意外的大规模重构、同类缺陷在不同位置反复出现。
危险信号：出现“先快速修一下，之后再看”“试着改改 X”“我大概知道是什么”“一次修几处”“跳过这个失败测试”“再来最后一次”等想法时，应回到第一阶段。
交还用户的时机：认真调查后根因仍不明、可能的修复超出已批准范围、缺少必需依赖或环境、已有三次修复失败，或需要就权衡、风险、测试策略做判断时。
限制：资料未提供安装命令、平台支持、收费价格或版本信息，这些暂未提供。