Refactor in tested checkpoints
Reshape the architecture in small, independently reviewed steps — live-test, commit a checkpoint, and log progress each pass.
Use this when
Use this for a deliberate architectural refactor where the destination can be stated in concrete terms and the current system can be tested after each meaningful change.
How it runs
- Write down the architectural target, constraints, and current risks before editing code.
- Make one significant, reviewable change at a time.
- Live-test the affected behavior and run an independent review after each significant step.
- Commit each verified checkpoint and update the temporary progress file with decisions, blockers, and the next action.
Done when
✓ The architecture is satisfactory and checks pass. Live-test, autoreview, and commit each significant step.
Why it works
Small verified checkpoints reduce refactor risk and preserve rollback points. The progress file keeps the goal and decisions available across long sessions or handoffs.
Implementation note
Define what satisfactory means before starting, such as module boundaries, dependency direction, passing tests, and acceptable performance. A subjective stop condition can otherwise run indefinitely.
More testing loops
Stabilize flaky tests for good
Measure the flakiness, fix one root cause at a time, and stop after a defined streak of stable full-suite runs.
Build a todo CLI app with tests
Ralph autonomously builds a todo CLI application with comprehensive test coverage over multiple iterations until complete.
Kill flaky tests
Run your test suite repeatedly, collect every intermittent failure, and fix or quarantine flaky tests until you get five consecutive green runs.