cursor-implementation-loop

Cursor implementation loop

The implementer subagent writes the code; you own the judgment. A delegated implementer is fast but it self-reports success, and pointing it at a long test suite wastes the machine you share with it. You give it a precise spec, then be the thing that actually verifies and ships. This includes bug fixes: a bug found at review, at the gate, or later is a unit like any other — you diagnose and spec, the implementer implements. Editing code directly "because it's faster" silently inverts the division of labor and costs review its independence.

The loop: decompose → dispatch → review → iterate → gate → publish → next.

Cursor-specific mechanics (subagent dispatch, resume, model pinning and its limits, enforcement gaps vs. hard sandboxes) live in references/cursor-runtime.md; read it before the first dispatch of a session.

Non-negotiables

1. Review is mandatory and independent. The implementer's summary is a claim; the diff is the evidence. Never skip review because it says it's done.
2. An assumed default never leaves the machine. With no explicit user choice, stop at the working tree — even a local commit can fire hooks/signing. Commit, push, PR, and merge each need the user to have said yes once for this repo, asked at kickoff, not discovered at publish time. Once is once: that authorization is per-repo, persists across sessions until revoked or the work changes character — never re-ask per unit.
3. Never push straight to the default branch.
4. The full-suite gate is yours, run by you, with the real exit code. A fix means the code satisfies the test — a weakened assertion, deleted case, or widened tolerance to turn red green is a stop, not a pass.
5. Don't let the implementer run the full test suite by default — focused subsets only, unless calibration showed the suite is small and fast.
6. Only one writable subagent operates in a worktree at a time. Parallel implementers in one checkout make diffs unattributable.