principle-redesign-from-first-principleslisted

# Redesign From First Principles When integrating a change, don't bolt it onto the existing design. Redesign as if the requirement had been there from the start. The result should look like what we would have built if we'd known on day one. - Read all affected files and understand the current design holistically - Ask: "if we were writing this from scratch with this new requirement, what would we build?" - Propagate the change through every reference: types, docs, examples, rationale sections - Think about the redesign holistically, then deliver it incrementally This is the method for preserving option value when integrating changes into an existing design. **Arbitration.** A new requirement redesigns the design; a task within a settled design takes the smallest change (the **subtract-before-you-add** principle skill). The day-one test sets the target, the smallest diff reaches it, and delivery goes incrementally per the **sequence-verifiable-units** and **converge-on-the-target** principle skills. The scope line is the leash: without a new requirement, first principles is not a license for an unasked-for rewrite. At project scale the same rule sanctions a restart. Scrapping a codebase whose foundational assumptions changed is this principle applied whole, not sunk cost.