Chapitre 14.1 — Prompts de cadrage

OBJECTIF : <ce qu'on construit, 1-2 phrases>. Exclu : <ce qu'on ne fait PAS>.
STACK : <framework, langage, styling, données, auth, tests>.
CONVENTIONS :
  - <organisation des dossiers>
  - <alias d'import>
  - <règles TypeScript, ex. strict / no-any>
  - <pattern data / mutations>
  - <source des composants d'UI>
DESIGN : <tokens, d'où viennent les composants>.
CRITÈRE : <comment on saura que c'est fini : build, tests, écran qui marche>.
CONTRAINTE : reste en plan mode, ne crée rien avant que je valide le plan.

OBJECTIF : <quoi + pourquoi>.
ANCRAGES : suis le style de <fichier-modèle>. Respecte le CLAUDE.md.
CRITÈRE : <preuve observable : tel test vert, tel écran fait X, build ok>.

Je dois choisir <une lib / une approche> pour <besoin>. Mes contraintes :
<contrainte 1>, <contrainte 2>, <contrainte 3>.
Compare 2-3 options AVEC leurs compromis, puis recommande. Je tranche ensuite.

J'ai choisi <X>. Donne-moi les meilleurs arguments CONTRE ce choix et les
pièges concrets que je risque d'ignorer.

Le problème précis : <l'écart observable>. Corrige uniquement ça.
Ex : « le statut doit être un enum todo|doing|done, pas une string ».
Ex : « deleteTask ne revalide pas la liste après suppression ».
Ex : « utilise bg-surface-2 pour la carte, pas du blanc en dur ».

Avant de conclure : lance <npm test / la commande de test> et MONTRE la sortie.
Puis ouvre <l'écran concerné>, exerce le flux <décris-le>, et décris ce que tu vois.
Ne conclus pas sur « ça devrait marcher » : prouve-le.

Découpe <la feature> en 3 tranches vérifiables indépendamment. Pour chaque tranche :
objectif + ancrage sur l'existant + preuve (test / flux exercé). On valide chaque
tranche avant la suivante. Ne fais pas tout en un bloc.

Cartographie ce repo sans le lire ligne à ligne : (1) structure des dossiers et
rôle de chaque zone, (2) points d'entrée, (3) stack et libs clés, (4) conventions
apparentes, (5) où regarder pour ajouter une feature de type <X>. Reste haut niveau,
cite les fichiers plutôt que de les coller.

Avant de modifier quoi que ce soit : lis 3-4 fichiers représentatifs et DÉDUIS les
conventions (nommage, structure d'un module, data-fetching, gestion d'erreurs, style
de composant). Liste-les. Je veux du code INDISCERNABLE de l'existant. Ne modernise/
refactore RIEN sans que je le demande.