Operator Core

Un opérateur n'« utilise » pas l'IA depuis un site web : il la pilote depuis sa machine, avec accès à ses fichiers, à son git et à son terminal. C'est ça, Claude Code. Avant de l'installer, tu as besoin de trois fondations : un terminal où tu lances des commandes, un éditeur (VS Code) où tu vois et modifies le code, et un gestionnaire de paquets pour installer des outils. Sur macOS, le terminal c'est Terminal.app ou iTerm2 ; sous Windows, utilise WSL2 (Ubuntu), parce que Claude Code et la plupart des outils supposent un environnement de type Unix. N'essaie pas d'opérer depuis PowerShell pur : ça va te coûter deux fois plus cher.

Commence par vérifier ce que tu as déjà. Ouvre Terminal et lance `node --version` puis `git --version`. Si `node` n'existe pas ou est inférieur à v18, installe Node LTS. Sur macOS, la solution propre c'est Homebrew : `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` puis `brew install node git`. Après l'installation de Homebrew, l'installeur affiche DEUX lignes `eval "$(/opt/homebrew/bin/brew shellenv)"` que tu dois ajouter à ton `~/.zprofile` — si tu les sautes, `brew` « disparaît » dès que tu ouvres un nouveau terminal. C'est la première erreur de PATH que tu vas rencontrer, et il vaut mieux la comprendre : le PATH est la liste des dossiers où le shell cherche les commandes ; si l'outil n'est pas dans l'un d'eux, le shell répond `command not found` même si le fichier existe sur le disque.

Installe Claude Code avec `npm install -g @anthropic-ai/claude-code` et vérifie avec `claude --version`. Si npm se plaint d'un problème de permissions (`EACCES`), N'utilise PAS `sudo npm` — ça te laisse des fichiers appartenant à root que tu ne pourras plus supprimer ensuite. La bonne solution est de pointer npm vers un préfixe dans ton home : `npm config set prefix ~/.npm-global` puis ajouter `export PATH=~/.npm-global/bin:$PATH` à ton `~/.zshrc`. Recharge avec `source ~/.zshrc`. Maintenant `claude` démarre et te demande de t'authentifier avec ton compte Anthropic via le navigateur ; ce token est enregistré et tu n'auras plus à le ressaisir.

VS Code est ta fenêtre sur le code, tandis que Claude Code, ce sont tes mains. Installe-le depuis code.visualstudio.com et, à l'intérieur, ouvre la palette de commandes (Cmd+Shift+P) → 'Shell Command: Install code command in PATH'. Ça te donne la commande `code .` pour ouvrir le dossier courant dans VS Code depuis le terminal — le geste que tu feras cent fois par jour. Installe au minimum ces extensions : celle officielle de ton langage, GitLens, et un formateur comme Prettier. Ne gonfle pas l'éditeur avec 40 extensions ; chacune est une surface d'attaque et du bruit.

Le vrai flux de travail est toujours le même, et tu vas l'intérioriser dans ce module. Tu ouvres un terminal, tu navigues vers ton projet avec `cd ~/mon-projet`, tu tapes `claude` pour lancer la session, et dans un autre onglet (ou un panneau divisé de VS Code) tu as l'éditeur ouvert avec `code .`. Claude Code propose des changements, tu les revois dans l'éditeur ou avec `git diff`, et tu les acceptes. Le terminal et l'éditeur ne sont pas en concurrence : le terminal est là où l'action se passe, l'éditeur est là où tu vérifies. Dans MOONKEY LAB, par exemple, une session typique c'est `cd ~/xop && claude` et tu lui demandes de toucher un composant Astro pendant que tu regardes le fichier dans VS Code.

Vérifie tout l'environnement avec un test décisif avant de considérer le module comme bouclé. Crée un dossier `mkdir ~/lab-01 && cd ~/lab-01`, initialise git avec `git init`, lance `claude`, et demande-lui de créer un `hola.txt` avec ton nom. Sors de Claude, exécute `cat hola.txt` pour confirmer que le fichier existe bien sur le disque, et `code .` pour le voir dans l'éditeur. Si les quatre étapes fonctionnent (le terminal navigue, claude démarre et écrit, le fichier apparaît, VS Code l'ouvre), ton environnement est opérationnel. Note dans un mémo personnel les versions exactes que tu as installées : quand quelque chose cassera dans un mois, cette note te fera gagner un après-midi.

CLAUDE.md est un fichier texte à la racine de ton projet que Claude Code lit automatiquement au démarrage de chaque session. Ce n'est pas de la documentation pour humains (même si ça sert aussi à ça) : c'est le contexte que l'IA charge avant de faire quoi que ce soit. Si ton `package.json` dit React mais que tu utilises Astro, ou si tu as une règle du type « n'ajoute jamais de dépendance sans la justifier », c'est dans ce fichier que ça vit. L'IA ne devine pas ton jugement ; tu le lui écris une fois et elle le réutilise pour toujours.

L'erreur du débutant, c'est d'écrire un CLAUDE.md générique (« c'est un projet web, applique les bonnes pratiques »). Ça n'apporte rien, parce que l'IA suppose déjà les bonnes pratiques. La valeur est dans le SPÉCIFIQUE et le NON-ÉVIDENT : quel stack tu utilises VRAIMENT (pas celui qui en a l'air), quelles tables de ta base appartiennent à un autre projet et qu'elle ne doit pas toucher, quel pattern d'i18n tu suis, ce qui se traduit et ce qui ne se traduit pas. Regarde le vrai CLAUDE.md de MOONKEY LAB : il a une section '⚠️ La DB Supabase est PARTAGÉE avec XHUB IRON' qui liste les tables interdites (`iron_*`, `world_*`) et celles autorisées (`profiles, progress, feedback, leads, proofs`). Cette seule ligne empêche l'IA d'effacer les données d'un autre produit. C'est exactement le type de connaissance que toi seul possèdes et que le fichier capture.

Structure un CLAUDE.md efficace en sections claires avec des titres Markdown. Celles qui comptent : (1) Vision — une phrase sur ce qu'est le projet. (2) Stack RÉEL — versions et outils exacts, en marquant là où la réalité diffère des apparences. (3) Modèle de sécurité ou de données — qui peut toucher à quoi. (4) Conventions — noms, structure des dossiers, typographie, tout ce qui a des règles. (5) Ton — comment doit sonner le texte qu'elle génère. (6) Règles de coût — ce qu'il ne faut PAS faire. Dans MOONKEY, cette dernière section dit littéralement 'Ne pas ajouter de dépendances sans justification. Pas de JS là où HTML/CSS suffit.' — des interdits concrets, pas des conseils vagues.

La règle d'or est : chaque ligne de CLAUDE.md doit changer une décision. Si une phrase ne modifie pas ce que l'IA ferait par défaut, supprime-la. « Écris du code propre » ne change rien. « Les hrefs doivent être locale-aware : utilise localizedPath(/route, locale), jamais /route brut (ça casse sous le préfixe de langue) » change chaque lien qu'elle génère. La seconde est de l'or ; la première est du remplissage. Un CLAUDE.md de 80 lignes denses vaut plus qu'un de 300 lignes d'évidences, et consomme moins de contexte à chaque session.

CLAUDE.md est un document vivant, pas un acte fondateur. Chaque fois que l'IA fait quelque chose de mal de façon systématique — elle ajoute une dépendance dont tu ne voulais pas, utilise le mauvais pattern d'i18n, traduit un terme de marque qui ne se traduit pas — c'est un défaut du fichier, pas de l'IA. Reviens et ajoute la règle. Avec le temps, le fichier devient le distillat de toutes les corrections que tu as faites. En pratique, une bonne session se termine par « ajoute ça à CLAUDE.md pour que ça ne se reproduise plus ». Garde aussi ce qui touche à ta machine et tes préférences personnelles hors du CLAUDE.md du dépôt (ça va dans la mémoire utilisateur ou dans un CLAUDE.local.md non versionné) : celui du dépôt est partagé par l'équipe.

Pour l'écrire, ne pars pas d'un modèle vierge. Lance `claude` dans ton projet et demande-lui : « Parcours la structure du dépôt, lis package.json et les fichiers de config, et propose un brouillon de CLAUDE.md qui capture le stack réel et les conventions que tu détectes. » L'IA est excellente pour lire ton propre code et le résumer. Ensuite c'est TOI qui corriges : tu ajoutes les interdits qu'elle ne peut pas connaître (les tables d'un autre projet, les termes qui ne se traduisent pas, les décisions métier) et tu effaces le générique. Ce cycle — l'IA propose à partir du code, toi tu injectes la connaissance qui n'existe que dans ta tête — produit un fichier honnête en vingt minutes.

Un prompt n'est pas une question : c'est une consigne de travail. Quand tu demandes à un collègue compétent de faire quelque chose, tu ne dis pas « répare le login » ; tu dis « le magic-link de Supabase ne redirige pas après authentification, regarde le callback dans src/lib/supabase.ts, le problème vient probablement de l'URL de redirect dans la config ». Tu lui donnes un rôle implicite, du contexte, un focus et une hypothèse. Un bon prompt fait pareil, mais de façon explicite. Les quatre piliers sont : RÔLE (qui l'IA doit être : « tu es un ingénieur Postgres qui relit du RLS »), CONTEXTE (ce qu'elle doit savoir : le stack, le fichier, la contrainte), STRUCTURE (comment tu veux la sortie : « renvoie seulement le SQL, sans explication » ou « liste 3 options avec leurs compromis »), et INTENTION (l'objectif réel derrière la demande, pas juste l'étape).

Le RÔLE n'est pas du théâtre : il change quelle connaissance l'IA active et quel standard elle applique. « Relis ce code » produit une revue molle. « Tu es un auditeur de sécurité adversarial : ton travail est de réfuter l'affirmation selon laquelle ce RLS est sûr, cherche le chemin d'escalade » produit une analyse complètement différente, parce que tu lui as donné une posture. Dans XCAP, les prompts de research portent le rôle de « l'analyste qui ne se ment pas à lui-même » précisément parce que le biais par défaut d'un modèle est de complaire ; le rôle le contrebalance.

La STRUCTURE de sortie est ce qui te fait gagner le plus de temps et ce qu'on oublie le plus. Si tu ne précises pas le format, l'IA en choisit un, et c'est souvent de la prose longue que tu dois élaguer. Dis exactement ce que tu veux : « Renvoie un unique bloc de SQL prêt à coller, sans commentaires ni explication. » Ou « Réponds avec un tableau à trois colonnes : option, avantage, risque. » Ou « Donne-moi le diff, pas le fichier complet. » Dans MOONKEY, où le ton est « clair, direct, sans fumée ni emojis », un prompt de génération de copy inclut cette contrainte de format mot pour mot, parce que sinon l'IA y glisse des fioritures que tu effaces ensuite à la main.

L'INTENTION, c'est le pourquoi, et elle débloque des solutions que tu n'avais pas demandées. Si tu dis « ajoute un index à cette colonne », l'IA l'ajoute. Si tu dis « cette requête met 2 secondes sur la page compte et je veux la faire descendre sous 200 ms ; l'index est ma première idée mais reste ouverte aux alternatives », elle pourrait te dire que le vrai problème est un N+1 et que l'index ne sert à rien. Quand tu donnes l'intention, l'IA peut remettre en question ta solution proposée et en offrir une meilleure. Quand tu ne donnes que l'ordre, elle exécute à l'aveugle.

Un arsenal est une collection versionnée de ces prompts, organisée par tâche, que tu réutilises. Ne repars pas de zéro à chaque fois : aie un prompt d'« audit de sécurité de RLS », un de « génère du copy dans la voix de la marque », un de « refactorise ce composant en préservant le comportement », un d'« écris le message de commit à partir du diff ». Range-les dans un fichier `prompts.md` dans ton projet ou dans un mémo. MOONKEY LAB a une page entière, `/prompts`, dédiée à ça, parce qu'un arsenal est un actif : chaque prompt affiné est du travail que tu ne refais pas. Paramètre les prompts avec des trous `[FICHIER]`, `[CONTRAINTE]` que tu remplis au moment de les utiliser.

Itère le prompt, pas la sortie. Quand un résultat est mauvais, le réflexe du débutant est de corriger la réponse à la main. Le réflexe de l'opérateur est de se demander « qu'est-ce qui a manqué au prompt » et de corriger le prompt. Si l'IA a utilisé des tabulations et que tu veux des espaces, n'édite pas le fichier : ajoute « indentation avec 2 espaces » au prompt et enregistre-le ainsi pour toujours. Chaque correction que tu mets dans le modèle est une correction que tu ne refais plus. Avec le temps, tes prompts d'arsenal deviennent chirurgicaux et les résultats sortent bons du premier coup — c'est ça l'objectif : arrêter d'itérer.

Git résout un seul problème, mais c'est le plus important : pouvoir revenir à n'importe quel état antérieur de ton projet. Chaque fois que tu fais un `commit`, tu figes une photo du projet à laquelle tu peux toujours revenir. Ça change ta psychologie de travail : quand tu sais que le dernier bon état est sauvegardé, tu laisses l'IA faire des changements agressifs sans peur, parce que le pire qui puisse arriver c'est `git restore` et tu reviens en arrière. Un opérateur sans Git travaille avec la peur ; avec Git, il travaille vite. Le flux minimal est : `git status` pour voir ce qui a changé, `git add -p` pour relire et choisir les changements morceau par morceau, `git commit -m 'message'` pour figer, et `git log --oneline` pour voir ton historique.

Le cycle quotidien c'est voir-relire-figer. Après une session de Claude Code, ne crois JAMAIS que le changement est correct : exécute `git diff` et lis exactement ce qu'elle a touché. C'est là que tu découvres si l'IA a changé quelque chose qu'elle ne devait pas, effacé une ligne par mégarde ou ajouté une dépendance. `git diff` est ton outil de revue numéro un et tu l'utilises à chaque session. Ce n'est que quand le diff te convainc que tu fais `git add` et `git commit`. Cette habitude — lire le diff avant d'accepter — c'est ce qui sépare un opérateur de quelqu'un qui copie-colle à l'aveugle.

Les commits doivent être atomiques : un commit, un changement logique, avec un message qui explique le POURQUOI, pas le quoi. « Répare le login » est mauvais (qu'est-ce qu'il avait ?). « Corrige le redirect du magic-link : l'URL de callback n'incluait pas la locale et cassait sous /en/ » est bon : dans six mois, ce message te dit pourquoi tu as touché ce fichier. Claude Code est excellent pour écrire des messages de commit à partir du diff — demande-lui « écris un message de commit pour ces changements en expliquant le pourquoi » et c'est souvent parfait. Mais relis : parfois il décrit le quoi et tu dois lui demander le pourquoi.

Les branches (`branches`) sont des univers parallèles pour expérimenter sans toucher à ce qui marche. La branche principale (`main`) est ta version stable. Quand tu vas tester quelque chose de risqué — une grosse refactorisation, une nouvelle feature — tu crées une branche avec `git checkout -b mon-experience`, tu travailles là, et si ça marche tu la fusionnes ; si ça rate, tu la supprimes et `main` n'en sait rien. Règle pratique d'opérateur : ne travaille jamais directement sur `main` pour des changements non triviaux. Crée une branche. Dans MOONKEY LAB, chaque changement de sécurité ou de RLS va dans sa branche et n'est fusionné que quand `get_advisors` donne le feu vert.

GitHub, c'est Git dans le cloud : ta sauvegarde distante et l'endroit d'où ton projet est déployé. Tu connectes ton dépôt local avec `git remote add origin git@github.com:utilisateur/repo.git` et tu pousses avec `git push`. À partir de là, `git push` après chaque bonne session sauvegarde ton travail hors de ta machine — si ton disque meurt, ton projet survit. En plus, des plateformes comme Cloudflare Pages (qui déploie MOONKEY LAB depuis `garciafradepablo-pixel/xop`) observent ton dépôt GitHub et publient automatiquement chaque push sur `main`. Ainsi Git n'est pas que du versioning : c'est le moteur de ton déploiement, que tu verras au module suivant. Pour parler à GitHub depuis le terminal, installe le CLI `gh` et authentifie-toi avec `gh auth login`.

Un `.gitignore` est aussi important que les commits : il liste les fichiers que Git doit IGNORER. Y vont `node_modules/` (réinstallé depuis package.json, pas versionné), les fichiers `.env` (secrets — ne pousse JAMAIS de clés sur GitHub), et les artefacts de build. Pousser un `.env` avec une clé dans un dépôt public est l'un des incidents de sécurité les plus courants au monde, et une fois la clé poussée, même si tu effaces le commit, elle reste dans l'historique : il faut la révoquer. C'est pour ça que le `.gitignore` se configure AVANT le premier commit. Demande à Claude Code « génère un .gitignore pour un projet Astro avec Supabase » et vérifie qu'il inclut bien `.env` et `node_modules`.

L'automatisation commence dans le petit : une commande que tu répètes devient un script. Si chaque fois que tu finis tu tapes `npm run build && git add -A && git commit -m wip && git push`, c'est un script `deploy.sh` de quatre lignes que tu exécutes avec `./deploy.sh`. Le principe est : ce que tu fais plus de trois fois, tu l'enregistres. Demande à Claude Code « crée un script bash qui fait build, commit avec timestamp et push, et qui s'arrête si le build échoue » — le `&&` entre les commandes garantit déjà que si l'une échoue, les suivantes ne tournent pas, ce qui est exactement ce que tu veux dans un déploiement.

Le déploiement moderne d'un site statique est presque gratuit à monter et s'appelle déploiement continu. Des plateformes comme Cloudflare Pages observent ton dépôt GitHub : chaque fois que tu fais `git push` sur `main`, elles clonent ton dépôt, exécutent ta commande de build (`npm run build` pour Astro), et publient le résultat sur une vraie URL. MOONKEY LAB fonctionne exactement comme ça : `git push` sur le dépôt `garciafradepablo-pixel/xop` et quelques secondes plus tard les changements sont sur `moonkeylab.pages.dev`. Tu ne montes pas de fichiers par FTP, tu ne touches pas à un serveur : ton unique geste de déploiement, c'est `git push`. Ça relie le module sur Git à celui-ci : Git ne fait pas que versionner, c'est le déclencheur du déploiement.

Configurer le déploiement continu est un processus à faire une seule fois. Tu connectes ton compte Cloudflare (ou Vercel, ou Netlify) à GitHub, tu choisis le dépôt, et tu déclares deux choses : la commande de build (`npm run build`) et le dossier de sortie (`dist` pour Astro). Cloudflare enregistre cette config et à partir de là chaque push déclenche un build. Si le build échoue, il NE publie PAS — ton site précédent reste vivant. C'est une énorme propriété de sécurité : un commit cassé ne fait pas tomber ton site, il ne se déploie simplement pas et te prévient. Tu verras le log du build dans le panneau de Cloudflare ; quand quelque chose échoue au déploiement mais marche en local, ce log est la première chose que tu lis.

Les variables d'environnement sont le pont entre ton déploiement et tes secrets, et c'est ici que ça croise la sécurité. Ton code a besoin de l'URL de Supabase et de l'anon key, mais elles ne vont PAS écrites en dur dans le dépôt (tu l'as vu au module sur Git). En local elles vivent dans un `.env` ; au déploiement tu les mets dans le panneau de Cloudflare comme variables d'environnement, et la plateforme les injecte dans le build. Distinction critique que tu apprendras à fond dans Ops & Security : l'anon key de Supabase PEUT vivre côté client (elle est protégée par RLS), mais une service-role key JAMAIS — celle-là donnerait un accès total en contournant toute la sécurité. Savoir quelle clé va où est une compétence d'opérateur.

Le niveau suivant, c'est automatiser des tâches récurrentes qui ne dépendent pas d'un push : des choses qui doivent tourner selon un horaire. Ce sont les tâches planifiées (cron). Dans XCAP, par exemple, il y a des 'autopilot ticks' — des boucles qui tournent périodiquement pour ingérer des données de marché et mettre à jour le ledger de Market Memory sans que personne n'appuie sur un bouton. L'idée générale : tu définis une commande et un horaire (« chaque jour à 6h00 », « toutes les 15 minutes »), et la plateforme l'exécute seule. Pour un site statique, ça vit généralement dans des fonctions serverless (Cloudflare Workers) ou dans des cron jobs. La clé d'opérateur, c'est que la boucle soit honnête et idempotente : que tourner deux fois ne duplique pas les données, et qu'elle accumule de l'apprentissage au lieu du bruit — exactement la discipline du 'capital invariant' de XCAP, où l'état ne change que sur des événements réels, pas à chaque tick.

Automatiser sans observabilité est dangereux : un système qui tourne seul et échoue en silence est pire qu'un système manuel. Pour chaque automatisation, aie un moyen de savoir si ça a marché. Le build de Cloudflare t'envoie un email s'il échoue. Une tâche cron doit logger son résultat quelque part que tu relis. La règle : n'automatise jamais quelque chose que tu ne peux pas vérifier ensuite. Commence toujours par une version qui tourne et te prévient, et ce n'est que quand tu lui fais confiance que tu la laisses tourner vraiment seule. Un déploiement automatique sans relire le log la première fois, c'est comme on publie un site cassé en production sans s'en apercevoir.

La différence fondamentale n'est pas de modèle, elle est de paradigme. ChatGPT est une conversation : tu écris, l'IA répond du texte, et tu copies ce texte dans ton projet à la main. Le contexte vit dans le fil, et quand le fil devient trop long ou que tu le fermes, ce contexte s'évapore. Claude Code est un opérateur : il vit dans ton terminal, lit et écrit tes fichiers directement, exécute des commandes, fait des commits. Le contexte ne vit pas dans une conversation éphémère — il vit dans CLAUDE.md et dans ton dépôt, qui sont permanents et versionnés. Migrer, c'est déplacer ta connaissance d'un endroit qui s'efface vers un endroit qui persiste.

Commence par auditer quel contexte précieux est prisonnier dans ChatGPT. Il y a probablement des fils où tu as défini le stack d'un projet, des décisions d'architecture, des conventions de style, des prompts qui ont bien marché. Tout ça est un actif qui, pour l'instant, n'existe que dans des fils. La première étape de la migration, c'est de l'extraire : parcours tes conversations importantes et sors-en les décisions durables (pas le chat complet, les conclusions). « On utilise Astro, pas React, pour X », « le ton est direct sans emojis », « la DB est partagée avec un autre projet et ces tables sont intouchables ». C'est exactement le matériau d'un CLAUDE.md.

Le cœur de la migration, c'est de construire le CLAUDE.md à partir de ce contexte extrait. Ce que dans ChatGPT tu devais répéter au début de chaque fil (« rappelle-toi que j'utilise Astro et Supabase et que le ton est... »), dans Claude Code tu l'écris une fois dans CLAUDE.md et il se charge tout seul à chaque session, pour toujours. Ça connecte directement au module OC-02 : la migration n'est rien d'autre que verser le contexte dispersé de tes fils dans le fichier de mémoire persistante. Un bon exercice est de demander à ChatGPT lui-même : « résume toutes les décisions techniques et les conventions de ce fil sous forme de bullets pour un fichier de contexte » — et d'utiliser cette sortie comme brouillon.

Change aussi ta façon de demander les choses. Dans ChatGPT tu demandes « écris-moi le code pour X » et tu reçois un bloc que tu colles. Dans Claude Code tu demandes « crée le fichier src/lib/x.ts qui fait X, en suivant les conventions de CLAUDE.md, et montre-moi le diff » — l'IA crée le fichier à sa place, tu relis le diff avec git, et tu fais un commit. Le geste de copier-coller disparaît. Ça demande de désapprendre une habitude : cesser de traiter l'IA comme un générateur de texte et commencer à la traiter comme un collaborateur qui agit sur ton projet. Au début, c'est dur de croire qu'elle touchera les bons fichiers ; c'est pour ça que `git diff` et les commits du module OC-04 sont ton filet de sécurité.

Bien migrer signifie monter le système complet, pas juste changer d'outil. Le système d'un opérateur c'est : un dépôt avec git, un CLAUDE.md avec le contexte, un .gitignore qui protège les secrets, un arsenal de prompts dans un prompts.md, et le déploiement continu branché. Quand tu as ces cinq éléments, tu as cessé d'« utiliser une IA » et tu as monté une opération. Chacun des modules précédents d'Operator Core était une pièce ; ce module les assemble en faisant migrer un vrai projet du chaos des fils de ChatGPT vers ce système documenté. Le résultat, c'est que n'importe quelle nouvelle session — la tienne ou celle d'un collaborateur — démarre avec tout le contexte chargé.

La valeur que tu sentiras tout de suite, c'est la continuité. Dans ChatGPT, reprendre un projet après une semaine signifie relire des fils et te rappeler où tu en étais. Dans le système migré, tu ouvres le terminal, `cd` vers le projet, `claude`, et l'IA connaît déjà le stack, les conventions et les interdits parce qu'ils sont dans CLAUDE.md ; toi tu vois où tu en étais dans `git log`. Le projet se documente lui-même. Cette continuité est ce qui permet d'opérer plusieurs projets à la fois sans qu'ils se mélangent — comme il le faut quand tu mènes XNLAB, XHUB, XCAP, Espejo et cette école en parallèle : chacun avec son CLAUDE.md, son dépôt et son contexte isolé, tous opérés avec le même flux.

La vérification n'est PAS du testing automatisé, et elle ne concerne PAS que la sécurité. C'est la discipline générale de prouver qu'un changement se comporte comme tu l'attends AVANT de le publier. Elle a quatre niveaux qui s'appliquent dans l'ordre et tu n'as presque jamais besoin des quatre : (1) est-ce que ça compile / démarre sans erreur ? (2) est-ce que le diff dit ce que tu croyais demander ? (3) est-ce que le comportement observable a changé comme prévu ? (4) est-ce que tu as cassé quelque chose qui marchait avant (régression) ?

Le niveau pas cher et obligatoire : LIRE LE DIFF. Avant d'accepter quoi que ce soit, `git diff` (ou le panneau de diff de l'éditeur). Claude Code est excellent pour décrire ce qu'il a fait et médiocre pour avouer ce qu'il a fait en plus : un fichier que tu n'avais pas demandé de toucher, un `console.log` oublié, une dépendance ajoutée, un bloc effacé « au passage ». Si le diff touche plus que ce que ta phrase demandait, c'est un signal, pas un hasard. Règle : n'accepte jamais un changement dont tu ne comprends pas le diff ligne par ligne.

« Ça a l'air de marcher » est un mensonge confortable à trois visages. Visage 1 : ça a démarré sans erreur → tu confonds 'ça ne crashe pas' avec 'ça fait la bonne chose'. Visage 2 : je l'ai testé une fois avec le cas heureux → tu n'as pas testé l'input vide, le doublon, l'utilisateur sans permission. Visage 3 : l'IA m'a dit qu'elle l'avait vérifié → l'IA n'a rien exécuté, elle a prédit du texte. L'antidote est toujours le même : observer le comportement réel de tes propres yeux, ne pas accepter le rapport de celui qui a fait le changement (ni humain ni IA).

Smoke test = le chemin le plus court qui démontre que la pièce centrale respire. Ce n'est pas une couverture totale ; c'est les 20 % de tests qui attrapent 80 % des désastres. Pour un site web : lance `npm run dev`, ouvre la route que tu as touchée, fais l'action principale, regarde que ce qui est attendu se produit. Pour un script : lance-le avec un input connu et compare la sortie avec ce que tu SAIS qu'elle doit donner. Tu définis le smoke test AVANT de demander le changement, pas après, pour ne pas te tromper toi-même en ajustant le test au résultat.

Assertion plutôt qu'observation : ne regarde pas l'écran en cherchant une confirmation, définis à l'avance l'affirmation falsifiable. Mauvais : « voyons voir si ça charge bien ». Bon : « en envoyant le formulaire sans email, l'erreur 'email requis' doit apparaître et AUCUNE ligne ne doit être insérée dans `leads` ». Une bonne vérification peut s'écrire comme une phrase qui serait clairement fausse si le changement avait échoué. Si tu ne peux pas écrire cette phrase, tu ne sais pas ce que tu vérifies.

Régression : le nouveau changement casse souvent l'ancien. La question qui sépare le senior du junior n'est pas « est-ce que ma feature marche ? » mais « qu'est-ce qui marchait avant que mon changement aurait pu casser ? ». Dans cette école, toucher à `galaxy.ts` peut casser le mapa SVG et toutes les pages de constellation, parce qu'ils sont générés depuis le même fichier. Avant de publier, liste mentalement quelles AUTRES choses dépendent de ce que tu as touché et vérifie-en au moins une.

Comment utiliser Claude Code COMME vérificateur, sans lui déléguer le jugement : demande-lui d'exécuter la vraie commande (`npm run build`, le test, le script) et de te coller la SORTIE brute, pas son résumé. « Lance le build et colle-moi la sortie complète » est vérifiable ; « est-ce que le build marche ? » invite à l'hallucination complaisante. L'IA vérifie en exécutant et en montrant des preuves ; toi tu vérifies en lisant ces preuves. Jamais l'inverse.

Vérification proportionnelle au risque (toute vérification ne coûte pas pareil). Changer un texte de copy : lire le diff suffit. Toucher au RLS, à un trigger de Postgres ou au flux de paiement : build + smoke + régression + relire les advisors. L'opérateur mûr calibre l'effort de vérification au coût de l'erreur, il ne vérifie pas tout pareil ni ne fait confiance à tout pareil.

Les signaux de dégradation du contexte, dans l'ordre d'apparition : (1) l'IA te repose une question à laquelle tu as déjà répondu ; (2) elle réimplémente du code qui existait déjà ou défait un changement convenu ; (3) ses réponses deviennent génériques, perdent les noms concrets de ton projet ; (4) elle édite le mauvais fichier ou invente des chemins. Dès que tu vois le signal 1-2, tu es en zone rouge. N'attends pas le signal 4 : là, tu nettoies déjà un désastre, tu n'avances plus.

La bonne intuition est contre-intuitive : quand la session déraille, s'arrêter et redémarrer est PLUS RAPIDE qu'insister. Se battre contre un contexte saturé, c'est des intérêts composés négatifs : chaque tour ajoute du bruit au bruit. La question n'est pas « comment lui expliquer mieux ? » mais « est-ce que ce contexte m'aide encore ou est-ce qu'il me gêne déjà ? ». S'il gêne, le remède n'est pas un meilleur prompt, c'est un nouveau contexte.

Le handoff : comment redémarrer SANS perdre l'état. Avant de fermer une session déraillée, demande le résumé de passation : « Résume dans un bloc ce qu'on essayait de faire, quelles décisions on a prises, quels fichiers on a touchés, ce qui reste en suspens et quelle est la prochaine étape concrète ». Ce bloc est ton état portable. Nouvelle session → tu colles le résumé → Claude Code démarre avec un contexte frais et la mémoire de l'essentiel, sans traîner le bruit. Le handoff transforme un redémarrage à perte totale en un redémarrage à coût quasi nul.

Ta mémoire persistante vit sur le disque, pas dans la fenêtre. Ce qui compte vraiment ne doit pas vivre seulement dans le chat : ça vit dans `CLAUDE.md` (décisions de projet, conventions, ce qu'il ne faut PAS toucher) et dans des fichiers de notes du dépôt. Une nouvelle session qui lit ton `CLAUDE.md` connaît déjà l'essentiel. Règle : si tu vas avoir besoin d'une décision demain, ne la laisse pas dans le chat — écris-la dans `CLAUDE.md`. La fenêtre de contexte est de la RAM volatile ; le dépôt est ton disque.

Prévention : des sessions courtes et à focus unique battent le marathon. Une session = un objectif délimité. « Répare la vérification du RLS » est une bonne session ; « refactorise tout le backend » est un marathon qui va se dégrader à mi-chemin. Quand une tâche est grosse, tu la découpes en sessions indépendantes avec handoff entre elles, tu ne la fourres pas entière dans une fenêtre qui ne tient pas le coup.

Délégation à des sous-agents : parallélisme et isolation du contexte. Un sous-agent est une session fille avec sa PROPRE fenêtre de contexte, à qui tu donnes une tâche délimitée et un livrable défini. Deux gains : (1) travail parallèle — un sous-agent audite la sécurité pendant qu'un autre écrit des tests ; (2) isolation — le sous-agent brûle son contexte à explorer un fichier énorme et te renvoie seulement le résumé, sans contaminer ta session principale. Tu délègues ce qui est volumineux à explorer mais compact à rapporter.

Comment écrire un bon mandat de sous-agent : comme si le sous-agent n'avait aucune mémoire de ta conversation — parce qu'il n'en a aucune. Chemins absolus, contexte autosuffisant, et un livrable explicite (« renvoie-moi X »). Un mandat vague à un sous-agent est pire que de ne pas déléguer : tu dépenses une fenêtre entière pour recevoir des bêtises génériques. Le sous-agent brille sur les tâches à frontière claire, pas sur « aide-moi avec ça ».

Reprendre le fil quand Claude Code se perd en cours de tâche : ne continue pas à pousser. Arrête-toi, demande-lui de te dire avec SES mots ce qu'il croit être en train de faire et pourquoi. Si sa version ne coïncide pas avec la tienne, la dérive est là — corrige-la explicitement ou fais un handoff vers une session propre. La pire option est celle du débutant : donner plus d'instructions par-dessus un modèle qui a déjà mal compris, en empilant des corrections sur un malentendu de base.