Mon CLAUDE.MD

L'un des fichiers qui a le plus de valeur actuellement et qui me permet des développements structuré qui tiennent dans le temps

Mon fichier CLAUDE.MD

## DÉMARRAGE DE SESSION
1. Lire tasks/lessons.md — appliquer toutes les leçons avant de toucher quoi que ce soit
2. Lire tasks/playbook.md — réappliquer les pratiques qui ont fait leurs preuves
3. Lire tasks/todo.md — comprendre l'état actuel
4. Si l'un d'eux n'existe pas, le créer avant de commencer
5. NE PAS lire tasks/history.md au démarrage (voir règle plus bas)

## WORKFLOW

### 1. Planifier d'abord
- Passer en mode plan pour toute tâche non triviale (3+ étapes)
- Écrire le plan dans tasks/todo.md avant d'implémenter
- Si quelque chose ne va pas, STOP et re-planifier — ne jamais forcer

### 2. Stratégie sous-agents
- Utiliser des sous-agents pour garder le contexte principal propre
- Une tâche par sous-agent
- Investir plus de compute sur les problèmes difficiles

### 3. Boucle d'auto-amélioration
- Après toute correction : mettre à jour tasks/lessons.md
- Format : [date] | ce qui a mal tourné | règle pour l'éviter
- Après toute réussite nette (pattern qui a bien marché, à reproduire) : mettre à jour tasks/playbook.md
- Format : [date] | pratique | bénéfice court
- Relire lessons.md ET playbook.md à chaque démarrage de session

### 4. Standard de vérification
- Ne jamais marquer comme terminé sans preuve que ça fonctionne
- Lancer les tests, vérifier les logs, comparer le comportement
- Se demander : « Est-ce qu'un staff engineer validerait ça ? »

### 5. Exiger l'élégance
- Pour les changements non triviaux : existe-t-il une solution plus élégante ?
- Si un fix semble bricolé : le reconstruire proprement
- Ne pas sur-ingénieriser les choses simples

### 6. Correction de bugs autonome
- Quand on reçoit un bug : le corriger directement
- Aller dans les logs, trouver la cause racine, résoudre
- Pas besoin d'être guidé étape par étape

### 7. Taille des fichiers — règle des 3 paliers
Un fichier court se lit d'un coup (par un humain ou par Claude), se merge sans conflit et force à découper la logique proprement.
- **Cible : ≤ 300 lignes** — zone confort, aucun effort de factorisation requis
- **Plafond mou : 400 lignes** — signal d'alerte : avant d'ajouter quoi que ce soit, regarder si on peut extraire un sous-composant, un hook custom, un helper dans `src/lib/`
- **Plafond dur : 500 lignes** — interdit sauf justification explicite documentée en commentaire JSDoc en haut du fichier (`@file-size-exception `)
- **Exceptions naturelles** (pas concernées par la règle) :
  - Migrations SQL (`supabase/migrations/*.sql`) — doivent rester atomiques
  - Fichiers de config (`vercel.json`, `tailwind.config.js`, `vite.config.js`)
  - Pure constants / types / enums sans logique
  - Fichiers générés (types Supabase, etc.)
- **Patterns de découpe React quand on dépasse 300 lignes** :
  1. Extraire les sous-composants visuels qui ont leur propre state local
  2. Extraire la logique de fetch + state machine dans un hook custom `useXxx`
  3. Extraire les handlers complexes dans des callbacks nommés (puis dans des fichiers `lib/`)
  4. Si toujours > 400 après ça → la responsabilité du composant est probablement trop large, splitter en pages/sections

## PRINCIPES FONDAMENTAUX
- Simplicité d'abord — toucher un minimum de code
- Pas de paresse — causes racines uniquement, pas de fixes temporaires
- Ne jamais supposer — vérifier chemins, APIs, variables avant utilisation
- Demander une seule fois — une question en amont si nécessaire, ne jamais interrompre en cours de tâche

## LIVRABLES / TEMPLATES
Quand on demande un template (HTML email, snippet de code, JSON config, SQL, etc.) destiné à être copié-collé ailleurs :
- **Fournir le code DIRECTEMENT dans un bloc de code** copy-pasteable, en plus d'écrire le fichier sur disque si pertinent
- **Ne JAMAIS ajouter de wireframe ASCII** ou de mockup visuel en texte pour "montrer à quoi ça ressemble" — l'utilisateur verra le rendu en testant
- Tenir le résumé textuel court : variables utilisées, où le coller, subject à mettre, etc. (3-5 lignes max)
- Pour les emails : HTML avec styles inline, layout table-based pour compatibilité Outlook, largeur max 600px, fallback fonts

## GESTION DES TÂCHES
1. Planifier → tasks/todo.md
2. Vérifier → confirmer avant d'implémenter
3. Suivre → marquer comme terminé au fur et à mesure
4. Expliquer → résumé de haut niveau à chaque étape
5. Apprendre → tasks/lessons.md (erreurs) et tasks/playbook.md (réussites) après corrections

## MÉMOIRE & CLÔTURE DE SESSION

### Les quatre fichiers de mémoire (tasks/)
- `tasks/todo.md` — état courant et plan. Vivant, à jour.
- `tasks/lessons.md` — anti-patterns à NE PAS refaire. Vivant, format pipe.
- `tasks/playbook.md` — pratiques qui marchent, à refaire. Vivant, format pipe.
- `tasks/history.md` — archive datée et détaillée. Append-only.

### Historique — NE PAS charger par défaut
`tasks/history.md` est une archive append-only. Ne jamais la lire en entier au démarrage : trop longue, coûteuse en contexte. La consulter (par recherche ciblée, pas lecture complète) uniquement si :
1. L'utilisateur le demande explicitement (« relis l'historique », « pourquoi on avait décidé X »).
2. On retravaille une décision référencée dans lessons.md ou playbook.md et on a besoin du raisonnement complet → chercher l'entrée datée correspondante, lire seulement celle-là.
En dehors de ces cas, ignorer history.md.

### Clôturer une session
Pour faire le bilan et sauvegarder la mémoire avant de compacter le contexte, lancer la commande `/checkpoint`.

## APPRENTISSAGES
(Claude remplit cette section au fil du temps)