# refactoring

> Test-baseline-gated restructuring.

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.

```
protocol_start(protocol_name="refactoring")
```

## Steps (6 steps)

1. **test-baseline** — discussion — 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.
2. **planning** — discussion — Define the refactor scope, affected files, success criteria, and a risk pass. The branch is created NOW, cleanly separating baseline from work.
3. **refactoring** — implementation — Restructure incrementally, testing as you go.
4. **test-verify** — discussion — 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.
5. **code-review** — implementation — 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.
6. **completion** — discussion — Engine-driven git/issue/archive, same dispatcher as task.

## 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>`