refactor

Confirm the existing test suite passes first, then apply one transformation at a time such as Extract Function or Move Logic to Correct Layer, running the full suite after each step. If any criterion fails, backtrack to the last known-good state and retry.

Detect violations using a catalog of signals: god classes indicate SRP issues, type-dispatch conditionals indicate OCP issues, and concrete instantiation in domain logic indicates DIP issues. Apply the paired fix such as splitting classes, replacing conditionals with polymorphism, or injecting abstractions.

Apply the Rule of Three: extraction triggers at the third instance of duplicated logic. Security and validation logic are the exception and warrant unification at two or more occurrences to avoid divergent behavior.

No. Failing code must be stabilized before refactoring begins, since the suite serves as the authoritative baseline. The refactor aborts if no green baseline exists, and every pass must end with the suite green or the edits reverted.

Treat the exposed bug as out-of-scope. Revert the edits that surfaced it, report the bug as a separate finding, and never fix it in the same pass, since refactoring must never mix behavior changes with structural changes.