Refactoring Protocol

Principle: CHANGE STRUCTURE, NOT BEHAVIOR.

If behavior changes, it's NOT refactoring -- it's a feature or bugfix.

When to Refactor

Refactor When	Do NOT When
Code works but hard to understand	Code doesn't work yet
Duplicated code	No tests exist
Long methods (> 50 lines)	Under time pressure
Deep nesting (> 3 levels)	"Just because"

Safety Protocol

Tests MUST exist before refactoring
Tests MUST pass before each change
Only small steps (one change at a time)
Run tests AFTER each change
Commit AFTER each green test

Workflow

1. VERIFY   -> All tests pass
2. IDENTIFY -> What to refactor
3. PREPLAN  -> Check file size limits (standard-file-size-limits rule)
4. PLAN     -> Small steps
5. EXECUTE  -> One step
6. TEST     -> Tests after step
7. COMMIT   -> Commit if green
8. REPEAT   -> Next step

Common Patterns

Code Smell	Refactoring
Long Method (> 50 lines)	Extract Method
Duplicate Code	Extract Method/Class
Long Parameter List (> 4)	Parameter Object
Deep Nesting (> 3 levels)	Guard Clauses
Magic Numbers	Extract Constant

Anti-patterns (FORBIDDEN)

Big Bang: rewriting entire module at once
No Tests: refactoring without test coverage
Mixed Changes: "while I'm here, let me fix this bug too"
Premature Abstraction: abstraction for code used once

Golden Rules

TESTS FIRST -- no tests, no refactoring
SMALL STEPS -- one change at a time
TEST OFTEN -- after every change
COMMIT OFTEN -- after every green test
BEHAVIOR UNCHANGED -- same inputs -> same outputs