architecture-refactoring-pathslisted

# Architecture Refactoring Paths ## Purpose Sequence an agreed architectural change into compatible, testable checkpoints. Establish the current and target contract rather than selecting a pattern from fashion. Incremental delivery limits exposure when coexistence and recovery are explicit; it is not automatically safer than a bounded, rehearsed cutover. The useful target is that an architectural refactor can be paused at documented checkpoints without leaving correctness dependent on completing the next step. Some migrations have an intentionally atomic cutover; make its recovery procedure, compatibility window and irreversible point explicit. ## The shape of every path here ```text 1. Characterise pin current behaviour with tests at the level that will survive the change (usually the use case). 2. Introduce add the new structure BESIDE the old. Nothing is removed yet; both work. 3. Route one case move a single, low-risk case to the new path. Ship. 4. Widen move cases one at a time, each shipped separately. 5. Contract remove the old structure when nothing uses it. 6. Simplify only now, remove the scaffolding that supported the coexistence. ``` This is a planning shape, not a fixed release count. A deploy rollback works only while the old implementation can interpret current data and see every authoritative write. ## Workflow These paths are planning pseudocod