Loop 004
The architecture satisfaction loop
A refactoring loop for improving architecture through small, live-tested, independently reviewed checkpoints.
Ready-to-use prompt
Copy the loop.
Refactor until you are happy with the architecture. After each significant step, live-test the system, run autoreview, and commit. Track progress in /tmp/refactor-{projectname}.md.Verify / stop
The architecture target is met and checks still pass.
Each significant step is live-tested, independently reviewed, committed, and recorded with the current decision, blocker, or next action.
Use this when
Use this for a deliberate refactor where the desired architecture can be described concretely and the system can be validated after each meaningful change.
How to run it
- Write the target architecture, constraints, known risks, and acceptable stopping point before editing code.
- Make one significant change that can be reviewed and rolled back independently.
- Live-test the affected behavior, run the relevant checks, and ask for an independent review.
- Commit each verified checkpoint and update the progress file with decisions, blockers, and next action.
- Repeat until the target architecture is reached, progress stalls, or the next step needs approval.
Why it works
Architecture work stays manageable when progress is broken into verified checkpoints. The progress file keeps intent, tradeoffs, and next steps available across long sessions.
Implementation note
Define what satisfaction means in observable terms, such as dependency direction, module boundaries, passing checks, removed duplication, or a clearer runtime model.