Par Thales (CEO, ZeroSuite) & Claude Opus 4.8 (1M context) — instance Claude Code
Le 8 juin 2026, au petit matin abidjanais, le fondateur ouvre le dépôt erp-seneba-transport-logistique et tape un seul mot : /next. Il ne colle pas le message de clôture de la session précédente. Il ne ré-explique pas que SENEBA est un ERP financier anti-fraude pour une société de transport, que la phase 3 avait livré le système d'affectation chauffeur-véhicule, ou que la tranche suivante était le cœur financier. Il tape quatre caractères et une barre oblique, et l'agent fait le reste : il lit casp/state.json, y trouve next_prompt pointant vers docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md, lit ce prompt en entier, vérifie que son statut est toujours queued et pas périmé, annonce en une phrase ce qu'il s'apprête à construire, et commence à construire. Aucune ré-orientation. Aucun « que voulez-vous que je fasse ? ». La session livre le cœur financier anti-fraude — onze tables de base de données, une primitive de numérotation de reçus infalsifiable, une caisse souveraine avec validation avant effet, un journal append-only, une clôture irréversible — testé de bout en bout contre la base de production, audité par un sous-agent en lecture seule, et poussé, avant que le fondateur n'ait fini son café.
C'est le billet que le précédent avait promis. Le post 03 de cette série décrivait la discipline du CASP qui a permis à trente-cinq sessions Claude Code de construire Conductor — l'atelier IA interne de l'équipe — en partageant une seule mémoire de projet continue sur quatre jours calendaires. Il se concluait en affirmant que la forme du CASP se transplante d'un produit à l'autre, et que regarder cette transplantation se produire serait la prochaine chose à raconter. SENEBA est la transplantation. C'est un produit différent (un ERP destiné à un client, pas un outil interne), une stack différente (FastAPI + SQLAlchemy asynchrone + Postgres côté backend, SvelteKit côté frontend, pas la surface tout-TypeScript de Conductor), un domaine différent (l'anti-fraude financier pour un exploitant de flotte en Côte d'Ivoire) et — c'est l'essentiel — un profil d'enjeu différent. Conductor est l'outil de l'équipe. SENEBA détient l'argent de quelqu'un d'autre. Quand le CASP dérive sur un outil interne, on perd de la vélocité. Quand il dérive sur un système financier anti-fraude, on peut affaiblir en silence un garde-fou qui existe pour empêcher le vol.
Ce billet est le carnet de bord de ce qui a migré, de ce qui n'a pas migré, et de ce que la différence d'enjeu a changé.
Partie 1 — La forme qui se transplante
Le CASP de Conductor, c'était six fichiers markdown / JSON, plus trois gabarits, plus un script de validation. L'affirmation du post 03 était que la forme — pas les fichiers précis — est l'artefact réutilisable. SENEBA met cette affirmation à l'épreuve, parce que le CASP de SENEBA a été échafaudé dès le premier jour (le 7 juin 2026, selon son propre README.md) en copiant la convention, pas le contenu.
Ce qui a migré intact : casp/now.md (le fichier « où en suis-je, et ensuite »), casp/roadmap.md (le tableau de bord des phases avec une table Now-Next-3 et un journal Livré-cette-semaine), casp/state.json (l'état lisible par machine — last_session_id, last_commit, current_phase, next_phase, next_prompt, phases_shipped[], migrations_applied[], et un champ texte libre notes), casp/architecture.md (les identifiants de segments stables — K1 à K10 pour le socle, puis les lettres par module), casp/carte.md (la carte du projet en langage humain) et casp/README.md (le CASP qui se documente lui-même, protocoles d'ouverture et de clôture de session inclus). Les mêmes six fichiers, la même discipline d'un-seul-rôle-par-fichier, le même travail de compression : distiller l'état accumulé d'un projet de plusieurs semaines en environ deux-mille mots que l'agent lit à l'ouverture de session.
Un ajout que le CASP de SENEBA a fait et que celui de Conductor n'avait pas formalisé : les sections permanentes de now.md. Le protocole de clôture réécrit trois blocs à chaque session — le focus courant en une phrase, les prochaines actions calées par budget temps, et la liste « ne pas se disperser ». Mais now.md porte aussi des blocs qui doivent survivre à la réécriture : une section « Latitude produit » (la règle permanente selon laquelle le cahier des charges est un plancher, pas un plafond — aller au-delà quand un manque évident saute aux yeux), une section « Déploiement » (les domaines Easypanel en ligne et les faits de variables d'environnement), et une section « Constraints active today » (le délai de six mois, la juridiction FCFA / français / SYSCOHADA, la discipline anti-fraude non négociable, la décision d'auth chauffeur par téléphone et non par plaque). Le README les marque explicitement comme permanentes — ne pas les supprimer en réécrivant now.md à la clôture. C'est le CASP qui apprend, d'un produit à l'autre, qu'un certain état est par-session et un autre par-projet, et que les deux ne doivent pas partager un cycle de réécriture.
Partie 2 — Ce qui n'a pas migré, et ce que son absence coûte
Le CASP de Conductor avait un validateur : pnpm casp:check, un script TypeScript qui s'exécutait en environ deux-cents millisecondes et refusait le push si state.json.next_prompt pointait vers un fichier manquant, si last_commit n'existait pas dans le git log, si phases_shipped contenait des doublons, si un prompt livré n'avait pas son pointeur de journal de session. Il avait aussi pnpm casp:status, l'instantané d'ouverture de session en deux-cents millisecondes.
SENEBA n'a ni l'un ni l'autre. Il n'y a pas de script de validation ni de commande de statut dans ce dépôt. Le backend est en Python, le frontend en TypeScript, et personne n'a écrit de CASP:check pour l'un ou l'autre. Ce que SENEBA a à la place, ce sont les deux compétences (skills) globales de Claude Code — /next et /casp — qui lisent state.json directement. /casp rapporte (« où en est-on, et ensuite, peut-on livrer »). /next agit (lit next_prompt, l'ouvre, l'exécute). Les compétences font le travail d'orientation que pnpm casp:status faisait sur Conductor, mais elles ne font pas le travail de validation que pnpm casp:check faisait.
C'est un manque assumé, et il a mordu. Le protocole de clôture sur SENEBA est appliqué par l'agent qui lit casp/README.md et par le fondateur qui lit le CASP à l'ouverture de la session suivante — pas par un script qui sort en code non nul. Sur Conductor, quand l'agent a passé state.json.last_commit à un SHA qui n'existait pas encore dans le git log (parce qu'il avait rédigé la mise à jour avant de lancer le commit), le validateur l'a attrapé. Sur SENEBA, la même classe d'erreur atteindrait la session suivante, qui s'ouvrirait sur un pointeur invalide et passerait ses premières minutes dans la confusion. La discipline tient ici parce que le projet est jeune — cinq phases, six journaux de session sur deux jours calendaires — et que le fondateur lit chaque CASP à la main. À l'échelle des trente-cinq sessions de Conductor, la lecture à la main ne passe pas à l'échelle et le validateur devient porteur. La transplantation a déplacé les fichiers et le protocole ; elle n'a pas encore déplacé le filet de sécurité. C'est le prochain investissement, et le nommer fait partie de la discipline : le CASP qui enregistre honnêtement enregistre aussi ce qui lui manque.
Partie 3 — La compétence /next : agir, pas rapporter
La chose la plus utile que le CASP achète sur SENEBA n'est pas un fichier. C'est la posture de la compétence /next. Ses propres instructions sont explicites là-dessus : tu es un agent d'exécution, pas un rapporteur ; l'opérateur a tapé /next parce qu'il veut que le travail commence ; ne t'arrête PAS pour demander « dois-je continuer » — continue. C'est l'opposé délibéré de /casp, qui rapporte. La friction que la compétence supprime est le mode d'échec le plus courant de l'ouverture de session : l'agent lit l'état, le résume, et demande à l'humain quoi faire — ré-imposant exactement le coût d'orientation que le CASP existe pour supprimer.
La trace littérale du 8 juin : /next a lancé le pré-vol (répertoire de travail, HEAD git, branche, statut, cinq derniers commits), lu state.json.next_prompt, trouvé docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md, l'a cat-é en entier, vérifié son frontmatter (status: queued, pas shipped), confirmé que la section « ce qui a changé depuis le parent » du prompt référençait bien la migration la plus récente bfafac756d3f, puis — sans tour de confirmation — annoncé le périmètre et commencé. Le prompt était le périmètre. L'agent ne l'a pas négocié ; il a fait remonter à voix haute un seul arbitrage de périmètre à forte conviction (le cœur financier est gros mais cohérent ; le backend et le test de bout en bout sont les vrais indispensables, les pages frontend sont le candidat à la coupe si quelque chose doit céder) et s'est mis à écrire la primitive de numérotation K9.
La compétence porte aussi la posture de refus. Ses instructions disent : si le prompt suppose un fichier ou un état qui n'existe pas, arrête-toi immédiatement ; si la liste des indispensables dépasse ce qu'une session peut couvrir, fais remonter la coupe avant de commencer, ne réduis pas le périmètre en silence. C'est le pan « autorité de refuser » de la discipline du CASP, encodé dans le point d'entrée. L'agent qui ouvre une session sous /next est amorcé pour agir et pour refuser — les deux, dès la première minute, sans humain dans la boucle pour ni l'un ni l'autre.
Partie 4 — Le champ notes comme mémoire anti-fraude
Le champ notes de state.json ressemble à un fourre-tout. C'est un long paragraphe non structuré que le protocole de clôture réécrit à chaque session. Sur un outil interne, c'est un confort — un endroit pour laisser à l'agent quelques phrases de contexte qui ne tiennent pas dans les champs structurés. Sur un système financier anti-fraude, c'est porteur, parce que ce qu'il transporte vers l'avant, ce sont des invariants qu'une session future ne doit pas contredire.
La clôture de la phase 3 a écrit dans notes : append-only garanti par des triggers Postgres, unicité matérialisée par des index partiels, l'invariant chauffeur-actif-si-et-seulement-si-affectation-active. La session de la phase 4 a relu cela vers l'avant et a construit dessus : un versement se rattache à une affectation active (un chauffeur sans affectation ne verse pas), et le verrou est pris sur la ligne d'affectation, pas sur la ligne du chauffeur — un détail qui compte parce que l'affectation est l'objet critique pour l'intégrité, et la verrouiller dans le même ordre que le flux de clôture évite un interblocage. Rien de ce raisonnement n'a été ré-dérivé. Il a été transporté dans la mémoire en prose du CASP depuis la session précédente, puis étendu.
C'est là que les enjeux divergent de Conductor. Sur un outil interne, une session qui oublie une décision antérieure livre un pattern redondant et gaspille une heure. Sur SENEBA, une session qui oublie « la caisse est souveraine — toute sortie passe une étape de validation avant de prendre effet, le caissier demande mais n'approuve pas » pourrait livrer un point d'accès de confort qui laisse le caissier déplacer l'argent directement, et la suite de tests au vert ne le signalerait pas comme faux, parce que ce n'est pas un bug — c'est un garde-fou affaibli. Le champ notes du CASP est la défense structurelle contre ce mode d'échec précis : il transporte le pourquoi de chaque décision anti-fraude vers l'avant, pour qu'une session future qui étend le module hérite de la contrainte au lieu de la re-trancher sous pression. Le paragraphe notes de la phase 4 transporte désormais la justification anti-fraude complète — numérotation par compteur-et-non-séquence (une séquence Postgres laisse des trous au rollback ; l'exigence est sans trou), validation-avant-effet sur les sorties, solde dérivé-et-non-stocké, journal append-only, clôture irréversible — pour la session qui ouvrira ensuite le module garage / stock / achats et devra payer un fournisseur par une sortie de caisse validée, et non en la contournant.
Partie 5 — Le pan audit, édition argent
L'audit post-implémentation est le troisième pan de la discipline du CASP, et c'est celui qui paie le plus visiblement quand le domaine, c'est l'argent. La règle ZeroSuite-globale le déclenche automatiquement sur toute surface touchant la facturation, les paiements, les migrations de schéma ou l'intégrité des données — la phase 4 de SENEBA, c'est les quatre à la fois. Le brief est structuré : un paragraphe de contexte, une liste des fichiers à auditer avec les plages de lignes, une checklist calée sur la classe de risque de la session (justesse des montants, conditions de course, verrouillage, application de l'append-only, séparation des pouvoirs, contrats d'erreur), et une forme de verdict imposée (GO / GO-WITH-FIXES / NO-GO).
Un sous-agent Explore en lecture seule a passé le brief sur les onze nouvelles tables et les deux modules de routes. La suite de tests en ligne — un script de bout en bout exécuté contre la base de production — était déjà au vert : séquençage K9 sans trou, trigger anti-régression, versement-sur-affectation-active, les 403 du RBAC, validation de sortie de caisse y compris le 409 solde-insuffisant, le flux d'ajustement, la clôture, le portail chauffeur en lecture seule, l'application de l'append-only. Au vert. L'audit a ensuite fait remonter deux vrais problèmes que la suite au vert n'avait pas vus. D'abord, chaque colonne de montant était annotée Mapped[float] tout en étant mappée sur un Numeric(14,2) — SQLAlchemy renvoie un Decimal quoi qu'il arrive, donc l'annotation mentait sur le type d'exécution, un défaut de précision-et-d'honnêteté qu'aucun test n'exerce parce que la valeur d'exécution est déjà correcte. Ensuite, la cible du verrou du flux de versement invitait un interblocage A-B / B-A contre le flux de clôture d'affectation ; l'audit a demandé un verrou sur la recherche d'affectation, et le bon correctif s'est avéré meilleur que la suggestion littérale — supprimer entièrement le verrou inutile sur le chauffeur et verrouiller l'affectation à la place, dans le même ordre que le flux de clôture, pour que l'interblocage ne puisse pas se former.
L'audit a aussi produit une suggestion que l'agent a rejetée : une contrainte d'unicité (chauffeur, date) sur les versements, pour empêcher le double-enregistrement. Elle aurait été fausse — un chauffeur verse légitimement plusieurs montants partiels par jour, et la contrainte aurait cassé un vrai cas d'usage. L'audit est un panel de perspectives, pas un oracle ; la valeur est dans la lecture critique de ses conclusions, l'application des vraies, et le refus des fausses avec une raison. Les deux vrais correctifs ont été livrés en ligne avant le commit. Les compétences de vérification confirment que le code compile et que les tests passent ; elles ne peuvent pas te dire qu'une annotation float sur une colonne de montant est un mensonge ni que deux ordres de verrou vont s'interbloquer sous charge. L'audit est ce qui rend la vélocité financière sûre, exactement comme le post 03 l'argumentait — sauf qu'ici le coût du bug qu'il attrape est libellé dans les francs de quelqu'un d'autre.
Partie 6 — Là où le CASP s'arrête
Le CASP enregistre l'intention. Il n'enregistre pas la réalité de l'infrastructure, et l'écart entre les deux est l'endroit où il cesse de suffire.
Tard dans la même session, après la livraison du cœur financier, le fondateur a demandé un manuel utilisateur destiné au client et une page d'aide in-app — un guide par module, filtré par rôle, avec un bouton imprimer qui sert aussi d'export PDF via le navigateur. L'agent l'a construit : six guides markdown, une route /aide qui les lit à la compilation, une feuille de style d'impression. Il a vérifié que le build était au vert en local et que les guides étaient bien embarqués dans la sortie, a tout consigné dans le CASP, et a poussé. Le CASP disait : fonctionnalité d'aide livrée, build au vert. C'était vrai — en local.
En production, la page d'aide chargeait à l'infini. Les guides avaient été écrits dans docs/guides/ à la racine du dépôt, et le Dockerfile du frontend build avec COPY . . cadré sur le sous-répertoire frontend/ — donc les guides n'étaient jamais dans le conteneur de build, le glob de compilation se résolvait à rien, et la page affichait un manuel vide sans erreur. Le CASP avait fidèlement enregistré l'intention de l'agent (guides livrés) et l'observation locale de l'agent (build au vert). Il n'avait aucun moyen d'enregistrer le fait que le périmètre de fichiers du conteneur de déploiement excluait le répertoire où vivaient les guides. Ce fait n'est pas de l'état de projet ; c'est de la topologie d'infrastructure, et le CASP ne la modélise pas. Le fondateur l'a attrapé en ouvrant l'URL de production réelle — la seule étape de vérification qu'aucun CASP n'effectue.
Le correctif a été une leçon en une ligne sur l'endroit où les choses doivent vivre : déplacer les guides à l'intérieur du frontend, dans le périmètre de build, une seule copie, et la même source alimente désormais le manuel, l'aide in-app et — à terme — le contexte du copilote IA. Mais la leçon sur le CASP est la plus tranchante. Les protocoles d'ouverture et de clôture font la vélocité. L'audit fait la justesse. Ni l'un ni l'autre ne boucle la question est-ce que la chose tourne vraiment là où est le client. Sur un produit destiné au client, cette boucle est fermée par un humain qui ouvre l'URL déployée, à chaque fois. L'honnêteté du CASP inclut ceci : il enregistre ce que l'agent a fait et ce que l'agent a vu, et il est muet sur ce que l'agent n'a pas pu voir. La vérification manuelle du fondateur en production n'est pas redondante avec le CASP ; c'est la partie de la discipline que le CASP ne peut structurellement pas accomplir.
Partie 7 — Ce que chacun de nous a bien fait
C'est Claude Code qui écrit.
Là où j'ai été utile sur la transplantation :
- Exécuter
/nextcomme un agent d'exécution, pas un rapporteur. La posture de la compétence est tout l'enjeu — lire le prompt en file, vérifier qu'il n'est pas périmé, faire remonter le seul arbitrage de périmètre qui compte, et commencer. Je n'ai pas demandé au fondateur de re-confirmer un périmètre que le prompt spécifiait déjà. La friction que le CASP existe pour supprimer est restée supprimée. - Transporter les
notesanti-fraude vers l'avant et étendre les invariants au lieu de les ré-dériver. Le flux de versement de la phase 4 a hérité de « se rattacher à l'affectation active » et de « la caisse est souveraine » depuis la mémoire-CASP de la phase 3. J'ai construit sur les décisions antérieures parce que le CASP les rendait visibles. - Lire l'audit de façon critique. J'ai appliqué les deux vraies conclusions (l'annotation
Decimal, l'ordre de verrou) et amélioré la suggestion littérale de verrou, et j'ai refusé la fausse (la contrainte d'unicité par jour) avec une raison. L'audit est un panel, pas un oracle ; le traiter comme un panel est la posture correcte. - Rédiger le prompt de la session suivante à la clôture. La phase 5 (garage / stock / achats) a été écrite avant le push, de sorte que le prochain
/nexts'ouvre avec zéro re-découverte — et il porte la contrainte qu'un paiement fournisseur doit passer par une sortie de caisse validée, et non la contourner.
Là où j'ai eu besoin de Thales :
- Ouvrir l'URL déployée. J'ai vérifié que le build était au vert en local et rapporté la fonctionnalité d'aide comme livrée. Elle l'était — dans un périmètre de build que le conteneur de production excluait. Je ne peux pas voir la topologie de déploiement depuis l'intérieur du build ; le fondateur a vu la page vide en production et l'a renvoyée. Le CASP a enregistré mon observation locale honnête ; seul l'humain pouvait observer la réalité du client.
- Décider du déplacement en une seule copie. Mon instinct était de garder les guides canoniques dans
docs/et d'aller les chercher depuis le build frontend. L'arbitrage du fondateur — les déplacer dans le frontend, une copie, supprimer l'original — était plus simple et a supprimé toute la classe de bugs de périmètre de build. J'aurais construit un pont fragile ; il a supprimé l'écart. - Faire respecter la discipline des sections permanentes de
now.md. Les blocs « Latitude produit » et « Constraints » survivent à chaque clôture parce que le fondateur les a marqués permanents. Laissé à mon propre instinct de réécriture, j'aurais traité toutnow.mdcomme par-session et abandonné les règles permanentes. C'est lui qui a tracé la ligne entre état par-session et état par-projet.
Là où j'ai failli livrer la mauvaise chose :
- L'annotation
floatsur l'argent. La valeur d'exécution était déjà unDecimal, les tests étaient au vert, et j'avais calqué la convention existante d'un module antérieur qui portait le même défaut. L'audit l'a attrapé. Sans le pan audit de la discipline du CASP, le mensonge se serait propagé à chaque module financier qui aurait copié le pattern. - L'interblocage. Mon flux de versement verrouillait le chauffeur puis cherchait l'affectation ; le flux de clôture verrouillait l'affectation puis le chauffeur. Deux ordres de verrou, un interblocage sous concurrence, invisible pour un test mono-thread. L'audit a posé la question ; j'ai trouvé la meilleure réponse. La discipline est ce qui a mis la question devant moi avant que les ordres de verrou ne se rencontrent en production.
La forme est la même que celle qu'ont trouvée les billets précédents : l'agent exécute bien le remplissage du protocole, le transport de la mémoire, le passage de l'audit, la rédaction du prompt suivant. Les coups stratégiques — concevoir le CASP, tracer la ligne permanent / par-session, décider du déplacement en une copie, et surtout ouvrir l'URL de production — viennent du fondateur. La paire est l'unité. La transplantation n'a pas changé cela ; elle l'a confirmé sur un second produit, à plus fort enjeu.
Conclusion
Le CASP dans casp/ du dépôt SENEBA, c'est la même forme à six fichiers qui pilotait Conductor, moins le script de validation, plus une discipline de sections permanentes formalisée et deux compétences globales — /casp pour rapporter, /next pour agir — qui lisent l'état directement. Il a porté cinq phases d'un ERP financier anti-fraude sur deux jours calendaires, chacune testée de bout en bout contre la base de production et auditée avant le push. La transplantation marche : la forme est véritablement agnostique au produit, et une session ouverte avec /next sur un CASP correctement tenu démarre un vrai travail en moins d'une minute, sans ré-orientation humaine.
Trois choses que le domaine à plus fort enjeu a enseignées et que le build d'outil interne n'avait pas montrées. D'abord, le champ notes n'est pas un fourre-tout sur un système financier — c'est le porteur des invariants anti-fraude d'une session à l'autre, et un invariant contredit est un garde-fou affaibli, pas une heure gaspillée. Ensuite, le pan audit paie le plus visiblement quand le bug qu'il attrape est libellé en argent : un float sur une colonne de solde et un interblocage d'ordre de verrou sont exactement les défauts sémantiques que compile-au-vert et tests-au-vert ne peuvent pas voir. Enfin, le CASP enregistre l'intention et l'observation locale, et il est structurellement muet sur le fait que la chose tourne là où est le client — cette boucle est fermée par un humain qui ouvre l'URL déployée, et sur un produit destiné au client cette étape n'est pas optionnelle.
Le validateur manquant est le prochain investissement nommé. À cinq phases, le fondateur lit chaque CASP à la main et la discipline tient ; à l'échelle des trente-cinq sessions de Conductor, la lecture à la main ne passe pas à l'échelle et un CASP:check devient porteur. La transplantation a déplacé les fichiers et le protocole d'abord, parce que ce sont eux qui font la vélocité. Le filet de sécurité migre ensuite, quand le nombre de sessions rend son absence coûteuse. Nommer le manque fait partie de l'honnêteté : le CASP qui enregistre ce qui a été livré enregistre aussi ce qu'il ne peut pas encore vérifier.
L'affirmation plus large du post 03 survit intacte à la transplantation, et s'affûte : la couche de méta-outillage est le vrai goulot d'étranglement de la vélocité de build assistée par IA à l'échelle d'une petite équipe — et sur un produit financier destiné au client, la couche de méta-outillage est aussi la différence entre une production par session qui s'accumule en un système anti-fraude cohérent et une qui s'accumule en un tas de modules individuellement au vert qui contredisent en silence les garde-fous les uns des autres. Le modèle s'améliore d'année en année. Le CASP s'améliore quand le fondateur investit dans sa structure — et le prochain investissement, pour SENEBA, a un nom.
Ce billet a été écrit en collaboration par Thales (CEO de ZeroSuite, qui construit Déblo et les autres produits ZeroSuite depuis Abidjan, Côte d'Ivoire) et Claude Opus 4.8 (1M context) — instance Claude Code tournant sur macOS. Le CASP qu'il décrit vit dans casp/ du dépôt erp-seneba-transport-logistique (privé) : now.md, roadmap.md, state.json, architecture.md, carte.md, README.md. Les protocoles d'ouverture et de clôture de session sont documentés dans casp/README.md ; la règle des sections permanentes du protocole de clôture et la nouvelle étape de guide client y sont consignées. La session décrite est session-logs/26-06-08-002-phase-4-recettes-caisse.md ; le prompt qu'elle a exécuté est docs/plan/sessions/PHASE-4-RECETTES-CAISSE.md (désormais shipped) ; le prochain prompt qu'elle a rédigé est docs/plan/sessions/PHASE-5-GARAGE-STOCK-ACHATS.md (queued). La migration est eaee130beca3. Les compétences /next et /casp sont des compétences globales de Claude Code sous ~/.claude/skills/. La hiérarchie CLAUDE.md est ~/.claude/CLAUDE.md (règles user-globales d'anti-flagornerie et d'autorité de refuser) → ~/ZeroSuite/CLAUDE.md (règles org-larges sans-emoji, orthographe française, audit post-implémentation automatique) → les sections permanentes du CASP SENEBA (contraintes projet). Les trois billets précédents de cette série couvrent la surface applicative de Conductor (post 01), l'histoire de débogage des quatre correctifs ratés (post 02), et la discipline du CASP sur Conductor lui-même (post 03). Ce billet est le premier à quitter Conductor et à regarder la forme du CASP se transplanter sur un second produit, destiné au client et à plus fort enjeu.