Refactoring

Improve the design of working code without changing what the system does.

Context

Refactoring keeps implementation quality from decaying between releases. It is not cleanup for its own sake. In Prodcraft, refactoring is justified when reviews, tech-debt evidence, or repeated implementation friction show that the current structure is increasing future cost or risk.

The constraint is strict: externally observable behavior must stay stable. If behavior changes, the work is feature development or defect fixing, not refactoring.

Inputs

• source-code -- The current implementation that needs structural improvement.
• test-suite -- The safety net that proves behavior has not changed.
• review-report -- Concrete findings from review that identify structural problems worth fixing.
• tech-debt-registry -- Evidence that the refactor addresses recurring cost rather than personal preference.

Process