NJ Fix Loop — execution is not repair

Platform policy on Agent Runtime v2 so command failures close the loop: read manifests, edit files, re-run verify, and always report an outcome — instead of spamming the same failing command.

NJ Fix Loop — from command spam to closed-loop boot fixes

The gap

An agent that can run_command can still fail to fix your app. A typical boot-fix session might run make start-all eight times, fill chat with command_output messages, and never touch disk.

Execution without repair is a platform problem, not just a model problem. The NJ Fix Loop adds hub policy so failures force read → edit → verify and a user-visible summary.

What ships in the Fix Loop

  1. Command telemetry — every run_command result recorded in session state.
  2. Circuit breaker — same failing command twice without a read or edit in between blocks a third run.
  3. Boot-fix grounding — make start-all / npm run dev blocked until Makefile, package.json, or startup scripts were read.
  4. Playbooks — known signatures (e.g. No rule to make target 'start-all') trigger deterministic repairs when fixtures exist.
  5. Session finale — every implementation session posts a summary plus implementation_session_outcome metadata.

Where it runs

Fix Loop policy applies during IDE Agent mode implementation sessions — the same path as stack manifest injection, grounding gates, verify/repair, and auto-apply when editor trust allows. Boot/build failure signals route to FrontendEngineer when the composer detects them.

See also IDE v4 and IDE v3 for Ask/Agent routing and editor trust modes.

Status

Fix Loop shipped in v1.2.0-beta.4 and remains the default repair policy for IDE Agent implementation sessions. See beta.4 release notes and CHANGELOG.

IMPLEMENTATION_SESSION.md · CURSOR_PARITY.md · Articles