refactoring.
refactoring changes the shape of the code without changing its behaviour, with a test suite as the safety net at both ends. Its defining feature: it captures a test baseline on the default branch before any change, then formally compares against it after — so a regression cannot slip through unnoticed.
Steps
- 01Test-baselineread-only
Run the suite on the default branch and snapshot the result before any change. Pre-existing failures are stored so they aren’t later mistaken for regressions.
- 02Planningread-only
Define the refactor scope, affected files, success criteria, and a risk pass. The branch is created NOW, cleanly separating baseline from work.
OpusAntigravityCodexyour call — answer to go on - 03Refactoringedit tools unlocked
Restructure incrementally, testing as you go.
- 04Test-verifytests green
Run the suite on the refactored branch and compare against the baseline — a regression gate. Read-only by design: a failing comparison sends you back, not deeper in.
- 05Code-reviewspec gate
The same two-stage gate as task’s — spec-compliance sentinel included. The one deliberate difference: the clean-tests gate (verify_tests_pass) is omitted, because the baseline comparison — not a clean exit 0 — is the behavioural guarantee.
OpusAntigravityCodex - 06Completiondocs · push
Engine-driven git/issue/archive, same dispatcher as task.
writes back to the shared LLM wiki
What makes it distinctive
Baseline-first ordering
Step 1 runs before the branch exists, on main/master, so the baseline reflects the true starting point — not a state already perturbed by the refactor. The branch is created in step 2.
Formal regression comparison
test-verify compares the post-refactor suite against the captured baseline. Behaviour is the contract; the diff is allowed to be large as long as the baseline holds.
branch feature/ — <priority>-refactor-<name>