principle-redesign-from-first-principles

Redesign as if the requirement had been a foundational assumption from day one rather than bolting it on. Read all affected files, imagine the from-scratch design, then propagate the change through every reference including types, docs, and examples.

It is a method where you ask what you would have built if the new requirement had been known on day one. The result preserves option value and avoids the patchwork that accumulates when changes are layered onto an existing design.

Redesign when a new requirement conflicts with core assumptions of the current design, such as adding multi-tenancy to a single-tenant system. Patching works for peripheral changes, but foundational shifts need holistic redesign.

No. The method says to think about the redesign holistically but deliver it incrementally. You plan the ideal end state, then migrate toward it in manageable steps.

It requires reading and understanding all affected files, which takes more upfront effort than a quick patch. For trivial or isolated changes, a full redesign may be unnecessary overhead.