deepenlisted

# Deepen Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. Aim: testability + the next reader's ability to navigate. > Adapted from mattpocock/skills `improve-codebase-architecture` (MIT). Vocabulary is Ousterhout-derived. > **Letter = spirit.** If a rule blocks you from reaching the goal it was > written for, the rule is wrong, not the goal. Don't look for a wording > loophole — ask what the rule is protecting, and protect that. ## Weaknesses and when NOT to use - **Not for green-field code.** Architectural friction only manifests when there are callers, tests, and history. On a blank slate, just write the first version. - **Not for one-off bug fixes.** `/diagnose` owns the bug loop; if a bug surfaces architectural pain, `/diagnose` Phase 6 hands off here. - **Doesn't refactor for you.** Output is candidates + (optional) interface designs. Actually executing the refactor is downstream (manual / `mattpocock:tdd` / goal feature). - **Vocabulary is opinionated.** Module / Interface / Seam / Adapter (not "component" / "service" / "API" / "boundary"). Stick to it — drift defeats the point. Full glossary in `references/architecture-language.md`. ## How to do it wrong vs right ### Module depth ❌ **Wrong:** Extract every pure function into its own file "for testability"; tests are easy to write but bugs hide in how the functions compose at the callers. No **locality**. ✅ **Right:** Group functions th