principle-redesign-from-first-principles

Read all affected files to understand the current design, then ask what you would build from scratch with the new requirement included. Propagate the change through every reference, including types, docs, and examples, and deliver the redesign incrementally.

It is a method where you treat a new requirement as if it had been a foundational assumption from day one, re-deriving the design cleanly instead of bolting changes onto the existing structure. This preserves option value and avoids patchwork architectures.

Redesign when a new requirement cuts across the core assumptions of the current design, such as data models or API contracts. Patching is acceptable for peripheral changes, but foundational shifts benefit from a clean re-derivation.

Think through the complete redesign first so the end state is coherent, then split it into incremental deliverables. Each increment should move the codebase toward the target design while keeping the system working.

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