plan-designlisted

> **Draft non éprouvé.** Écrit d'après l'état de l'art, pas récolté sur une exécution réelle — > `D-039` demande l'inverse. À confronter au premier usage ; en cas de désaccord, > `docs/methode/journal-frictions.md` prime sur ce fichier. # plan-design Ce skill **gate** : tant que son plan n'est pas écrit, aucun test rouge sur cet incrément n'a de raison d'exister. `CLAUDE.md` l'exige dès qu'un changement crée ou supprime une classe, traverse plusieurs modules, ou implique une découpe non évidente. **L'échelle est celle des objets** (`D-053`) : lesquels naissent, changent ou meurent, et quelles responsabilités ils portent. Les deux échelles voisines ne sont pas la tienne, et empiéter coûte dans les deux sens : - **au-dessus**, le **plan d'architecture** de la spec a tenu le système et le module. Il est d'ensemble et **indicatif** : tu as le droit de t'en écarter au contact du réel, à condition de le dire — ne le rejoue pas, ne le contredis pas en silence ; - **en dessous**, la **test list** de chaque pas tiendra le code, fichier par fichier. Elle s'écrit à la prise du pas, jamais ici. ## 1. Décider si l'étape a lieu `Planning` est **conditionnel** (`tickets.md` §6.2). Relis l'incrément en `Todo` contre les trois critères ci-dessus. - Aucun ne s'applique → saute directement à `In Progress`, écris-le en une phrase dans l'incrément (« pas de plan, changement local à une classe ») pour que le lecteur suivant sache que ce n'est pas un oubli. - Au moins un s'applique