improve-architecture

# improve-architecture Invest in the shape of the system a little at a time rather than paying for a rewrite later. This skill diagnoses and proposes; it does not rewrite on its own. ## Method 1. **Map first.** Get the current shape before judging it - entry points, modules, data flow, who calls whom. Reuse `module-map` for the one-screen view; do not skip to opinions. 2. **Find the strain.** Look for the load-bearing problems, not style nits: - God modules that everything imports and nothing can change safely. - Leaky boundaries - a module reaching into another's internals instead of its surface. - Duplicated logic that drifts (the same rule implemented three ways). - Wrong seams - the code is split where it does not bend and fused where it does. - Cyclic dependencies. - A shape that fights the domain (see `domain-modeling` - boundaries in code should track boundaries in the language). 3. **Propose the smallest move.** For each problem, the least change that relieves it: extract a boundary, collapse a duplicate, invert a dependency, move a seam. Prefer a sequence of safe steps over one big cut. 4. **Rank by leverage.** Order the moves by pain relieved over effort. Say which are safe now and which need a test net first (pair with `tdd`). 5. **Record the big calls.** For a structural change a future reader would question, write a decision record in `docs/decisions/NNNN-slug.md`: context, choice, alternatives rejected, wh...