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](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 c...