用途：修复失败的确定性检查。采用有界循环，最多 3 次自主尝试；该上限也由工作流（maestro.config.yaml → fix_loop.max_attempts）通过回退计数器强制执行，无论在工作流中还是独立运行都需遵守。
安全限制：绝不运行破坏性命令（rm -rf、force-push、DROP/TRUNCATE），也不写入生产配置或密钥。没有自动拦截机制，使用者自身是最后防线，该规则在任何环境下都成立。升级触发条件是硬性停止点。
外部技能（provision——调试方法）：读取 skills.config.yaml → shared.external.debug（默认 systematic-debugging，来自 Superpowers 包，或 none）。若已设置，使用其四阶段根因方法，不要“修复”尚未理解的问题。无论采用何种方法，都必须：复现失败、找到根因、预测修复、确认结果。若为 none，则按包内同样的纪律执行。
每次尝试：复现——引用确切的失败命令及其真实错误输出；诊断——找到根因（阅读代码/堆栈跟踪），区分真实缺陷与不稳定测试或环境问题，在改动代码前说明原因；最小修复——只编辑与该根因相关的文件，不做大范围重构，不做无关的顺手改动；重新运行失败检查并记录结果；若通过，运行完整验证（/verify），若出现新失败，计为一次尝试。
修复前先分类：不稳定测试——修复测试的确定性（等待/选择器/种子），而非产品，且绝不削弱断言；环境问题（服务宕机、端口、缺少依赖）——修复环境或上报，不通过改代码强行变绿；真实缺陷——修复代码并添加回归测试，该测试在修复前失败、修复后通过；规格/契约歧义——停止并询问，不要臆造行为。
遇到以下情况停止并询问人类：需要数据库迁移但未获批准；API 契约将改变；认证/权限行为改变；需要升级依赖；生产配置变更；同一错误在 3 次尝试后仍存在；存在多种有效设计；修复会削弱测试或安全控制。
完成定义：要么目标检查与完整 /verify 通过，且为根因修复（真实缺陷附带回归测试）；要么升级上报，附上确切命令、根因、更改的文件、已用尝试次数和剩余风险。升级是成功，不是失败。