lfe-improve-architecturelisted

# LFE Improve Architecture ## Position in Pipeline - **Phase**: 5 (Hygiene sub-pipeline, Step 2) - **Persona**: Architect - **Trigger**: Scheduled every 5 sessions (tracked in `pipeline_status.md`) ## Vocabulary Use these terms exactly; keep "component," "service," "API," and "boundary" out of architectural suggestions. See [LANGUAGE.md](./LANGUAGE.md) for full definitions. - **Module** — anything with an interface and an implementation - **Interface** — everything a caller must know to use the module - **Implementation** — the code inside - **Depth** — leverage at the interface: a lot of behavior behind a small interface - **Seam** — where an interface lives; a place behavior can be altered without editing in place - **Adapter** — a concrete thing satisfying an interface at a seam - **Leverage** — what callers get from depth - **Locality** — what maintainers get from depth ## Key Principles - **Deletion test**: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep. - **The interface is the test surface.** - **One adapter = hypothetical seam. Two adapters = real seam.** ## Process ### 1. Explore Read the project's domain glossary (`CONTEXT.md`) and any ADRs first. Then walk the codebase organically and note friction: - Where does understanding one concept require bouncing between many small modules? - Where are modules **shallow** — interface nearly as complex as the implementatio