deepen — make modules deep

Behavior is sacred: tests green before AND after. Every change shrinks an interface or hides a decision — deepen, don't churn.

A deep module hides a lot behind a small interface; a shallow one's interface costs as much to use as writing the code yourself. Complexity = dependencies + obscurity, and it compounds. Deepen spends spare usage paying that down before it becomes a §B. Run it when the build is green & you have budget to drain — not under deadline.

WHEN TO DEEPEN

• Build is green, tests pass, & you have token budget spare.
• A module's interface feels as complex as its implementation (shallow smell).
• The same change keeps touching many files (change amplification).
• User explicitly asks to improve design quality.

⊥ run mid-feature or under pressure. Deepen is the deliberate pass, not the reflex.