dev-loop

Dev Loop

Take one coding task from "asked" to "verifiably done, clean, committed, and proposed as a PR" through a short feedback loop you can defend. The point is not autonomy — it is a loop with a real acceptance gate, a quality bar, and named stopping conditions, so the work ends in a green build or an honest "blocked", never in a confident claim that isn't true.

Treat this like the project's own evidence ethic: no claim of done without a receipt you can re-run. A passing test you executed is a receipt. "It should pass" is not.

The contract (read once, then hold it the whole loop)

• Isolate the work in a git worktree so the main checkout is never disturbed and the diff stays clean (next section).
• Keep a resumable plan on disk and check it off as you go, so an interrupted run picks up where it left off instead of starting over.
• Define done before you act. Write the Definition of Done as an observable, reproducible checklist first. If you cannot state the command whose exit code decides "done", you are not ready to act — go back and make the goal checkable.
• Clear the quality bar, not just the test. Done means clean code and sound logic too — see references/quality-bar.md. A green test over sloppy code is not done.
• One bounded change per cycle. Smallest reversible step toward the DoD, then verify.
• Re-read fresh state before consequential actions. Don't ship against stale code.
• Preserve unrelated work. Keep the diff surgical. Never "clean up" code the task didn't ask about.
• Never report an error, a skipped step, or an exhausted budget as success. A red test is red. Say so, with the output.
• Stop on a named terminal state, not on vibes (see Terminal states).

Work in an isolated worktree

Run the whole loop in a dedicated git worktree, not the main checkout. This keeps unrelated uncommitted work safe, keeps your diff clean, and lets a run be abandoned without leaving a mess. Create it from the branch you'll ship: