Codebase Design (vocabulaire modules profonds)
Skill de vocabulaire, pas de process : elle impose sept termes exacts (module, interface, implémentation, profondeur, seam, adaptateur, levier, localité) et interdit les synonymes flous comme composant, service, API ou frontière. Sa thèse : un bon module est profond, beaucoup de comportement derrière une petite interface, posée sur un seam propre et testable à travers cette interface. Elle fournit le test de suppression (si supprimer le module fait disparaître la complexité, c'était un tuyau) et la règle un adaptateur égale seam hypothétique, deux adaptateurs égale seam réel. /tdd et /improve-codebase-architecture parlent cette langue.
Forces
- Sept termes exacts avec leurs synonymes interdits, donc toi et l'agent parlez enfin de la même chose
- Le test de suppression donne un critère opérationnel là où profondeur reste d'habitude une intuition
- Sépare le placement du seam de ce qui va derrière : deux décisions de design distinctes, traitées comme telles
- Section framings rejetés : elle dit ce qu'elle refuse et pourquoi, rare dans une doc de design
Limites
- Ne produit rien de tangible : sans /improve-codebase-architecture pour trouver les candidats, tu as un lexique et rien à en faire
- Impose un vocabulaire qui entre en conflit avec celui de ton équipe si elle dit déjà service ou boundary
- Deux références externes (DEEPENING.md, DESIGN-IT-TWICE.md) que tu dois lire pour la partie la plus opérationnelle
Pour qui
- Devs qui refactorent une zone et n'arrivent pas à dire pourquoi la nouvelle version est meilleure
- Tech leads qui veulent une langue partagée pour les revues de design, humains et agents inclus
- Codebases où chaque module expose vingt méthodes et où les tests passent sous l'interface