principle-redesign-from-first-principles

Redesign the affected system as if the requirement had existed from day one instead of bolting it on. Read all affected files, reason about the ideal from-scratch design, then propagate the change through types, docs, and examples while delivering incrementally.

It means asking what you would build from scratch if the new requirement had been known on day one, then reshaping the existing design to match that coherent vision rather than layering patches onto the current structure.

Redesign when a new requirement cuts across the existing design's assumptions, such as adding multi-tenancy or changing core data models. Patching works for localized changes, but cross-cutting requirements benefit from holistic redesign to preserve option value.

Think about the redesign holistically first, then deliver it incrementally. Propagate changes through every reference including types, documentation, examples, and rationale sections in small, reviewable steps.

It requires reading and understanding all affected files, which costs more upfront effort than a quick patch. For trivially scoped changes that do not touch core design assumptions, a full redesign may be unnecessary overhead.