architecture-refactoring-strategylisted

# Architecture Refactoring Strategy Use when improving architecture needs staged code change rather than a one-shot rewrite. ## Inputs Gather current architecture map, hot paths, structure metrics, runtime topology, ownership topology, target quality attribute, constraints, tests, production signals, failure history, ADRs, and architecture principles. For architecture-significant structural changes, require a baseline before code edits: dirty-tree state, observed boundary evidence, pre-refactor probe or explicit reason it was skipped, representative change/runtime scenario, and the focused skills used from the router. ## Patterns Use the smallest safe pattern: - characterization tests before moving behavior; - branch by abstraction behind stable interface; - strangler fig for extracting flows; - anti-corruption layer for old model or external API coupling; - facade/adapter to stabilize callers; - parallel run, shadow read, dual write for data migration risk; - feature flag or compatibility window for reversibility; - expand-contract migration for schema/API changes. ## Multi-Objective Frame For every refactor name: - primary quality attribute to improve; - secondary attributes that must not regress; - accepted tradeoff and threshold; - evidence signal before and after each slice. Do not recommend a pattern without the measurable quality attribute it improves. ## Slicing Prefer one validated slice at a time: user flow, bounded-context seam, data ownership edge, de