用途：当构建、编译、打包、类型检查、lint 或聚焦测试失败，且原因属于机械性错误（类型错误、缺失导入、签名不匹配、打包配置等）时，让智能体自行把检查命令驱动到通过。核心原则是检查命令才是裁判，绿色等于退出码 0，而不是“看起来修好了”。
主要能力：锁定检查命令后循环执行“运行检查→读取首个错误→做最小修复→重跑”，每轮只做一处针对性修改并重跑一次，逐轮报告进度，例如 round 3/10 — 4 errors left (was 7) — fixed missing await in db.ts:42。默认尝试上限为 10 次，达到上限即停止并交回人工。
使用方式：先确定检查命令（依次查看用户指令、CI 配置、package.json scripts、Makefile、justfile 或构建工具约定），原样运行一次确认基线失败，并设定 MAX_ATTEMPTS。之后每轮使用同一命令、同一参数，读取退出码而非从日志文字推断，定位首个错误的 file:line 并只改相关行。
适用场景：tsc、cargo build、go build、npm run build、vite build 等非零退出；提交前想让类型检查或 lint 变绿；聚焦测试失败且每个失败都有明确修法；本地复现 CI 的构建或类型检查失败。
限制：不适用于尚不知道检查命令、需要真正逻辑排查的 bug（应改用 debug-hypothesis）、需要产品/设计决策的修复，或构建已经通过的情况。禁止用 @ts-ignore、any、删除测试、|| true 等方式压制错误来伪造通过；若错误未变、来回震荡或错误数不下降，应提前停止并交回人工。达到上限或提前停止时，需报告命令、最终退出码、剩余错误、每轮尝试及卡住原因的假设。