Breaking Refactor

Replace the old design with one canonical design. Treat incompatibility as an explicit engineering decision, not as permission to skip safety, evidence, data handling, or validation.

Establish the Refactor Contract

Before editing, identify:

• the design flaw or constraint the refactor must remove;
• the owned scope and every consumer expected to change;
• the contracts that may break: code APIs, types, storage, serialized data, events, routes, configuration, CLI, tests, fixtures, and documentation;
• the behavior that must remain unchanged;
• the intended cutover and validation commands.

Proceed without another question when the repository and request establish these facts. Stop and request direction when a consumer is outside the authorized scope, production data may be destroyed, an external contract has no coordinated cutover, or the target design depends on a material product decision.

Do not equate “no backward compatibility” with “no migration.” Allow one-time schema or data conversion needed for a safe cutover. Do not keep a permanent runtime compatibility path unless the user changes the refactor contract.

Workflow