solid-principleslisted

Use SOLID to diagnose, not to decorate. Each principle names a specific way designs rot under change; the skill is recognizing the rot early and making the smallest cut that stops it. The failure mode of SOLID is applying it as ceremony - an interface for every class, a factory for every constructor - which produces the same unmaintainability it was meant to prevent, with more files. Every abstraction this skill recommends must be justified by a change pressure that actually exists in this codebase, not one imagined. ## Step 1: Find the change pressure Before judging any structure, learn what actually changes here: - `git log --oneline --follow` on the files in question: what has forced edits, and do unrelated reasons keep touching the same file? - Where have bugs clustered? A class that breaks every time a neighbour changes is telling you where the coupling is. - What does the team add regularly (new payment providers, new report types, new integrations)? That axis deserves an extension point; axes that never vary do not. SOLID violations only matter along axes that change. A "god class" that has been stable for two years is a lower priority than a small class edited weekly by three features. ## Step 2: Diagnose against each principle For each, the smell, the test, and the minimal fix - in the codebase's own idiom (modules and functions count; none of this requires classes). **S - Single responsibility.** A unit should have one reason to change. - *Smell:* commits tou