prendre-un-paslisted

# Prendre un pas > **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. La conception a déjà eu lieu : le plan de design de l'incrément a posé les frontières, la carte du pas dit où il s'arrête. Ici, les mains, pas la tête — ce skill n'invente rien, il **exécute**. Le standard non négociable, le régime TDD, la frontière testé/non-testé et les conventions de modélisation sont déjà dans `CLAUDE.md`, chargé par ailleurs : ne pas les répéter, seulement les tenir. ## 1. Avant le premier test - Lire la carte en entier : le pas, le pourquoi à cette place, le piège local s'il existe. - Créer, ou reprendre, la branche `pas/<identifiant>-slug` depuis la branche de la story. - Le pas touche-t-il un objet déjà modélisé, ou en nomme-t-il un nouveau ? Si oui, relire la section concernée de `docs/design/architecture.md` — et le vocabulaire §3 de `docs/design/schemas.md` s'il s'agit de définition vs exécution — juste ce qui nomme ce que le pas va toucher, pas le document entier. Sinon, rien à y chercher. **Fin de l'étape** : si la carte ne suffit pas à travailler sans la conversation — un « jusqu'où » reste ouvert — ne pas deviner. Noter la friction dans `docs/methode/journal-frictions.md` et reposer la carte plutôt que combler en silence. ## 2. Écrire la test list — à la prise, jamais avant Une lign