AY 修复
先证明原因，然后做出最小且授权的修复，以防止复发。
批准契约
- 在向用户提问前，完整阅读请求并调查可发现的事实。
- 除非用户也要求变更，否则将审查、诊断、解释和规划视为只读操作。
- 当目标、可观察结果和验收边界明确时，将精确指令视为批准。
- 广泛的结果仅授权调查，不授权基于代理必须自行发明的选择来更改文件或工件。
- 对于实质上未明确说明的变更，提出一个推荐的方案并等待批准。
- 批准后，在批准的边界内自主执行；不要询问常规的实现细节。
- 仅当新证据改变了行为、架构、数据契约、依赖项、范围、风险、成本、回滚或外部操作时，才重新开启批准。
- 仅当请求或批准的方案中包含外部操作时，才执行外部操作。在执行不可逆操作前，确认确切的目标。
- 保留无关的用户创作的工作。在声明完成前，验证真正的请求结果。
诊断
- 捕获确切的症状、预期行为、环境和失败层级。
- 通过最接近的可用路径重现，或说明缺失的重现条件。
- 从错误输出开始，回溯到最早的不正确状态。读取最近的变更和相关的示例。
- 形成竞争性假设并运行最小的区分检查。当观察缺失时，在边界处进行仪器化。
- 确认原因。一个看似合理的迹象、相关性或已消失的症状不能作为证据。
在假设失败后，收集新证据再尝试另一个假设。不要以反复编辑来替代诊断。
决定修复边界
如果用户仅要求诊断，则在确认原因或下一个区分检查处停止。
如果用户要求修复，则仅当根本原因修复是唯一的、局部的、可逆的且能保留预期行为时，才无需另一个检查点继续。当替代方案会改变产品行为、架构、数据契约、依赖项、范围、外部状态或重大风险时，先提出修复方案。
修复并验证
在最狭窄的责任边界内修复原因，而不是修复其下游症状。当存在稳定的行为接缝时，添加回归检查；不要为不可测试的表面发明空洞的测试。
重新运行原始重现、回归检查以及相关邻近测试。分离环境、测试工具、源代码、构建、包、部署和实际运行时的证据。如果原因仍未得到证实，请如实说明。
报告原因、区分证据、修复、验证以及剩余的不确定性。