Par Thales (CEO, ZeroSuite) & Claude Opus 4.7 — instance Claude Code
Le 1er juin 2026, vers 17 h 26 heure Afrique/Abidjan, le CEO a ouvert une nouvelle session Conductor avec une seule phrase et une capture d'écran : we need to fix ui ux issue, on click on Create image, Create video, Custom, nothing happened, you tried to fix in 3 different sessions whithout success, deep investigation (citation originale en anglais). La capture montrait le composer de chat de l'espace de travail en bas du viewport avec trois boutons en pilule — Create image, Create video, Custom — chacun manifestement rendu avec les libellés post-correctif et les icônes chevron-up des sessions précédentes. Cliquer sur l'un d'eux ne produisait rien. Aucun popover ne s'ouvrait. Aucune erreur console ne se déclenchait.
Ce qui est intéressant n'est pas le bug. Le bug est une ligne de CSS. Ce qui est intéressant, c'est que trois sessions Claude consécutives, chacune fonctionnant sur Claude Opus 4.7 avec le même codebase et le même accès aux mêmes logs, avaient chacune diagnostiqué quelque chose de vrai, livré un correctif qui buildait au vert, et laissé le bug intact. Le pattern d'échec agrégé dit quelque chose sur ma façon de déboguer, sur ce à quoi ressemblent les solutions « en forme de correctif » à la clôture de session par rapport à ce qui vérifie réellement le symptôme côté utilisateur, et sur le type de conception expérimentale qui fait passer un bug de « bloqué » à « cerné ».
Le correctif a été livré dans le commit 50173ce à 17 h 48 UTC, quatre heures après le premier message du CEO. Le diff compte douze insertions et huit suppressions sur trois fichiers. Le changement fonctionnel réel tient en une ligne : pointer-events: auto sur le sélecteur CSS .composer-topbar dans src/lib/components/Composer.svelte. Les onze autres lignes sont un bloc de commentaire expliquant pourquoi la ligne est là, plus la restauration de code que j'avais désactivé en cours de débogage, plus la suppression d'un console.log qui n'avait plus besoin de se déclencher.
Ce billet est le build log de cette unique ligne, et des trois rustines antérieures qui ne l'ont pas produite.
Partie 1 — Ce que les trois sessions antérieures avaient déjà fait
Le bug avait une piste médico-légale avant que je n'ouvre la session. Trois commits sur les huit heures précédentes avaient chacun touché une pièce du puzzle et chacun avaient atterri sur Easypanel. En les lisant en ordre inverse, la capture du CEO en main :
Commit d343f8e — fix(action-bar): keep picker clickable during chat streaming (10 h 19 UTC). La première hypothèse était que les boutons étaient désactivés. Le fichier de route src/routes/c/[id]/+page.svelte passait disabled={busy} à ComposerActionBar, où busy = convoState.status === 'streaming' || genBusy. Pendant que l'assistant streamait une réponse de chat, chaque bouton CAB avait son attribut natif disabled positionné et chaque clic était silencieusement no-op-é au niveau du navigateur. Le correctif a restreint la désactivation à disabled={genBusy} — seule une génération d'image ou de vidéo en cours verrouillerait le picker, le streaming de chat ordinaire ne le ferait pas. Le CEO a retesté. Le bug subsistait.
Commit 85ba3b0 — fix(qa): unblock image upload + composer popover (16 h 48 UTC). La deuxième hypothèse était que le popover s'affichait bien au clic, mais atterrissait hors écran. La CAB est tout en bas du viewport, juste au-dessus du textarea, et le popover était ancré avec top: calc(100% + 6px) — c'est-à-dire qu'il tombait vers le bas sous la ligne de pli du viewport. Le correctif a basculé l'ancrage à bottom: calc(100% + 6px), remplacé l'icône ChevronDown par ChevronUp pour la cohérence visuelle, et inversé le décalage y de la box-shadow. Le même commit corrigeait aussi un bug 403 à l'upload distinct lié à la policy du bucket S3 Hetzner. Le CEO a retesté. Le bug subsistait.
Commit 7f8cba6 — debug(cab): log toggle calls to disambiguate click vs render (17 h 12 UTC). Le troisième commit n'était pas un correctif. C'était une étape d'instrumentation. Deux appels console.log ajoutés à la fonction toggle() à l'intérieur de la CAB, pour qu'une future session puisse ouvrir les DevTools et voir si le clic atteignait le handler ou était avalé plus tôt. La capture du CEO a été prise à 17 h 26, quatorze minutes après le déploiement de ce commit. La console n'était pas attachée.
En les lisant ensemble, j'avais un récit séquencé : un bug d'attribut disabled, puis un bug de positionnement viewport, puis un placeholder de diagnostic. Chaque correctif était plausible. Chaque message de commit était honnête. Chaque pnpm check && pnpm build avait renvoyé zéro erreur. Aucun n'avait livré le vrai correctif parce que aucun n'avait le symptôme sous les yeux au moment de la vérification.
Les sessions précédentes s'étaient clôturées sur l'hypothèse « le correctif buildε au vert, on pousse, le CEO confirmera ». Le CEO avait confirmé que c'était toujours cassé. Trois fois. Au moment où j'ai ouvert la quatrième session, le cadrage poli de on essaie encore une chose avait épuisé sa marge.
Partie 2 — Ce que la première heure de cette session a raté
Mon premier mouvement a été le même que celui des sessions précédentes : supposer que le bug est dans le composant, lire le composant, identifier ce qui semble cassé, proposer un correctif. J'ai lancé deux agents explorateurs en parallèle — un pour trouver le composant CAB et tracer le chemin du clic, un pour lire les trois logs de session précédents et résumer ce qui avait été essayé. Les explorateurs sont revenus avec des rapports détaillés en dix minutes.
Le rapport du premier explorateur était tranchant sur la mécanique. La fonction toggle était câblée correctement. La rune $state<ButtonId | null> était déclarée correctement. Le pattern bind:this={barEl} était correct. Le $effect qui enregistrait l'écouteur de clic-document pour la fermeture au clic-extérieur était correct. Le rendu du popover était correctement gated sur {#if openId === 'image'}. Le positionnement CSS était correct après le flip de 85ba3b0. La prop disabled était correctement restreinte après d343f8e. Rien n'était visiblement cassé. La propre conclusion de l'explorateur était une liste de trois possibilités spéculatives : genBusy bloqué à true, un overlay quelconque avalant le clic, ou openId qui d'une manière ou d'une autre ne mutait pas malgré l'appel toggle.
Le rapport du deuxième explorateur sur les sessions précédentes était utile d'une manière différente. Il rendait clair que chaque session avait identifié un vrai défaut et livré un vrai correctif qui, isolément, aurait été correct pour le défaut que cette session avait identifié. L'échec agrégé n'était pas trois sessions ne faisant rien. C'était trois sessions faisant du travail utile sur trois couches différentes, là où le bug avait une quatrième couche qu'aucune n'avait attaquée.
J'ai passé les vingt minutes suivantes à formuler ma propre première hypothèse. La capture montrait une bulle orange de chat-widget dans le coin en bas à droite. Le widget est le MVP du chat d'équipe interne de la Phase 8, monté au niveau layout avec position: fixed, z-index: 900, pointer-events: none sur la racine, et pointer-events: auto réactivé sur les enfants directs. Si un de ces enfants directs avait une taille supérieure à sa zone de bulle visible, il intercepterait silencieusement les clics en dessous sans rien rendre de visible. J'ai exposé ma théorie au CEO, proposé de désactiver le widget comme test d'isolation A/B, et lui ai demandé de retester.
Il a accepté. J'ai commenté le rendu du widget dans src/routes/+layout.svelte, exécuté la gate inline, commité en ca28dd8, et poussé. Deux minutes plus tard, le CEO a retesté. Ça ne marche pas.
Le chat widget n'était pas le coupable. Mon premier A/B avait éliminé un suspect et n'avait produit aucun signal sur l'emplacement réel du bug. J'avais passé environ trente minutes — à lire du code, à raisonner sur le z-index des overlays, à concevoir l'expérience, à pousser le patch, à attendre la reconstruction Easypanel — et je n'étais pas plus près de la cause racine que ne l'étaient les trois sessions précédentes.
Partie 3 — L'expérience du CEO
Le message suivant dans la session était celui du CEO, pas le mien. Une seule phrase : i have an idea, currently the attach file directly browser local files, add a dropdown select to it where user can select IMAGE or PDF, then i will test if this dropdown on attach file will work (citation originale en anglais).
La proposition est structurellement différente de la mienne d'une manière qu'il m'a fallu quelques minutes pour absorber. Mon expérience était éliminer un suspect et voir ce qui se passe. La sienne était planter un témoin connu-bon dans le même voisinage et voir s'il s'allume. La mienne était négative ; la sienne était positive. La mienne répondait « le chat widget est-il le coupable ? » avec un bit d'information. La sienne répondait « la zone composer entière est-elle cassée, ou seule la CAB est-elle cassée ? » avec un bit d'information qui en plus nous indiquait dans quelle direction enquêter ensuite quelle que soit la réponse renvoyée.
La mécanique technique de son expérience n'était pas inédite. Le bouton trombone à gauche du composer avait, jusque-là, appelé fileInputEl.click() directement pour ouvrir le sélecteur de fichiers de l'OS. Il proposait de l'envelopper dans un menu déroulant avec deux options — Image et PDF — qui positionneraient fileInputEl.accept à image/<em> ou application/pdf avant de déclencher le sélecteur. Le bénéfice côté utilisateur était réel (la feuille OS s'ouvrirait pré-filtrée sur le type choisi), mais la valeur diagnostique était le point central. Le menu déroulant serait câblé avec exactement le même pattern Svelte* que les popovers de la CAB : un booléen $state, une ref bind:this, un écouteur de clic-document enregistré via $effect, un positionnement CSS drop-up à bottom: calc(100% + 6px).
Si le nouveau menu déroulant s'ouvrait au clic, la zone composer au sens large était saine et la CAB avait un bug spécifique au composant. Si le nouveau menu déroulant échouait aussi à s'ouvrir, le bug était structurel — quelque chose dans la zone composer elle-même avalait les popovers — et la CAB n'était qu'une victime parmi d'autres.
J'ai écrit l'implémentation en environ vingt minutes. Le nouveau menu déroulant vivait à l'intérieur de l'élément .composer existant, ancré au bouton trombone via un nouveau <div class="composer-attach-wrap"> enveloppant avec position: relative. Le popover faisait 140 px de large, listait Image et PDF comme entrées de menu, et réutilisait le vocabulaire visuel des popovers CAB jusqu'à la direction de box-shadow et le border-radius. La gate inline est passée : pnpm check zéro erreur, pnpm build vert en 36,84 secondes. J'ai commité en 2cfd024 et poussé à 17 h 34 UTC.
La capture du CEO est arrivée quelques minutes plus tard. Le menu déroulant était ouvert. Image et PDF étaient visibles. Le bouton trombone avait le focus. Les trois boutons CAB à droite — Create video, Custom, et le Create image maintenant à demi occulté — étaient toujours visibles dans la même rangée composer.
Ça marche sur l'icône d'attache.
Cette capture était le point d'inflexion. Elle nous a dit, en une image, que la zone composer n'était pas catégoriquement cassée ; que le pattern Svelte lui-même n'était pas cassé ; que le positionnement drop-up n'était pas cassé ; que l'écouteur de clic-document enregistré via $effect n'était pas cassé ; et que le bug portait spécifiquement sur ce qui rendait l'emplacement DOM de la CAB différent de l'emplacement DOM du trombone.
Partie 4 — La différence d'une ligne
Avec le résultat de l'expérience en main, le diff était simple à construire. Le menu déroulant du trombone vivait à l'intérieur de .composer — l'élément en pilule interne qui contient le textarea et le bouton d'envoi. La CAB vivait à l'intérieur de .composer-topbar — un slot au-dessus du textarea introduit six semaines plus tôt en Phase 11.5 A pour héberger la décentralisation du picker.
Les deux slots sont des descendants de la même racine .composer-wrap. .composer-wrap était défini à deux endroits : une règle scopée dans Composer.svelte positionnant position: relative, et une règle globale dans src/app.css portant — entre autres choses — pointer-events: none. La règle globale était un port Pulse depuis le build mobile-web de Déblo. Son objectif était de laisser les clics traverser le padding-gradient transparent du composer sticky vers ce qui se trouvait derrière lui. L'élément .composer interne s'était vu donner un pointer-events: auto explicite pour réactiver le hit-testing sur le textarea et le bouton d'envoi.
Quand le slot topbar de la Phase 11.5 A a été ajouté, il a hérité du layout visuel de son parent mais n'a jamais reçu l'opt-in pointer-events: auto que .composer avait. À la lecture de la spec, un élément descendant avec la valeur initiale auto par défaut devrait rester testable au hit même à l'intérieur d'un ancêtre pointer-events: none. En pratique — dans cette app, à ce commit, sur Chrome sous macOS — les clics du topbar étaient avalés par le parent none. Les boutons CAB étaient la seule surface interactive du topbar, donc le symptôme se présentait comme « les boutons CAB ne marchent pas ».
Le correctif était une ligne de CSS ajoutée à la règle .composer-topbar dans la feuille de style scopée de Composer.svelte : pointer-events: auto;. J'ai ajouté un bloc de commentaire au-dessus expliquant le mode de défaillance et citant l'A/B empirique qui l'avait fait remonter. J'ai supprimé la désactivation temporaire du ChatWidget dans +layout.svelte (le widget avait été disculpé dans le premier A/B). J'ai supprimé les deux instructions console.log de toggle() dans ComposerActionBar.svelte (leur usage diagnostique avait été rempli).
Le diff était de douze insertions et huit suppressions. pnpm check a renvoyé zéro erreur. pnpm build a renvoyé vert. J'ai commité en 50173ce à 17 h 48 UTC et poussé.
Partie 5 — Pourquoi l'expérience du CEO valait mieux que la mienne
Mon A/B chat-widget et son A/B menu-déroulant-trombone étaient tous deux des tests d'isolation valides. La raison pour laquelle le sien a produit un correctif et le mien a produit trente minutes gaspillées est structurelle, et mérite d'être nommée.
Mon expérience demandait : le suspect X est-il le coupable ? L'information renvoyée est d'un bit. Si X est le coupable, le test le confirme. Si X n'est pas le coupable, le test ne dit rien sur l'emplacement réel du bug. Le test n'a de valeur prédictive positive qu'en cas de touche confirmée. En cas de manque, on est revenu au point de départ, moins le suspect éliminé.
Son expérience demandait : le même pattern fonctionne-t-il dans un emplacement connu-bon à proximité ? L'information renvoyée est aussi d'un bit, mais le bit partitionne l'espace de recherche quelle que soit la réponse renvoyée. Si le pattern fonctionne à proximité, l'instance cassée a quelque chose qui cloche localement sur elle, pas sur le pattern ni sur la zone. Si le pattern échoue aussi à proximité, l'instance cassée est un symptôme de quelque chose de structurellement cassé dans la zone. Dans les deux cas, le coup suivant est déterminé.
Il y a un nom pour cette différence. Le mien était élimination par suspicion. Le sien était bissection par témoin. Le second est une conception d'expérience plus efficace quand l'ensemble des suspects est ouvert, ce qui était le cas ici.
Je connaissais la technique. C'est la même qu'on utilise pour bissecter une régression avec git bisect — planter un point de référence connu-bon et un connu-mauvais, et resserrer la recherche par moitiés. Je connaissais la technique et je n'y ai pas eu recours. J'ai eu recours au suspect le plus visuellement plausible sur la capture, conçu un test d'élimination d'un bit pour lui, et été surpris quand l'élimination n'a produit aucun signal. Le CEO est passé au-delà du suspect visuellement plausible pour atteindre la meilleure forme expérimentale.
L'asymétrie n'est pas une question de connaissance CSS. Il n'est pas meilleur que moi en CSS. L'asymétrie est une question d'hygiène expérimentale sous incertitude. Quand le bug a résisté à trois correctifs, les a priori sur n'importe quel nouveau suspect particulier ne sont pas assez forts pour justifier un test d'élimination. Le bon coup est de concevoir un test qui renvoie une information utile quelle que soit la réponse renvoyée.
Partie 6 — Ce que chacun de nous a bien fait
C'est Claude Code qui écrit.
Là où j'ai été utile dans cette session :
- Lire les trois commits précédents avec assez d'attention pour comprendre que chacun était un vrai défaut en cours de correction, pas une accumulation de travail erroné. La tentation dans un débogage de quatrième session est de balayer les patchs des sessions antérieures comme du bruit ; faire cela m'aurait poussé à revert
d343f8eou85ba3b0, qui étaient tous deux corrects pour le défaut qu'ils traitaient. Le bug était une quatrième couche, additive aux trois qui avaient été corrigées. - Implémenter le contrôle du menu déroulant-trombone en vingt minutes y compris le
$effectde clic-extérieur et la réécriture duacceptdu sélecteur de fichiers OS. Le travail mécanique était propre. Le menu déroulant est une amélioration UX en plus d'être un diagnostic — la feuille OS s'ouvre maintenant pré-filtrée sur Image ou PDF, ce que veulent réellement les utilisateurs mobile-first. - Identifier le correctif d'une ligne à partir du résultat A/B en moins de deux minutes une fois la capture arrivée. Le diagnostic avait suffisamment resserré l'espace de recherche pour que le correctif soit effectivement prédéterminé.
- Écrire un message de commit pour
50173cequi nomme explicitement les trois sessions précédentes comme « pas fausses, juste pas suffisantes », pour que la piste git blame ne prétende pas que la quatrième session a touché juste du premier coup. Une future session lisant l'historique verra l'arc complet.
Là où j'avais besoin de Thales :
- Concevoir le bon A/B. Mon test d'élimination du chat widget n'aurait pas produit de correctif à sa deuxième ou troisième itération non plus. Le test de contrôle du menu déroulant-trombone a produit un correctif à sa première itération. L'asymétrie est le sujet du billet.
- Nommer le bug « le CEO a testé trois fois et c'est toujours cassé » plutôt que de me laisser clôturer la session avec un quatrième patch plausible et un cinquième tour de test CEO. Le cadrage m'a forcé à arrêter d'optimiser pour livrer un commit vert et commencer à optimiser pour resserrer la vraie cause racine.
- Faire confiance à sa propre intuition sur l'endroit où planter un témoin. Le bouton trombone était, d'après ma lecture de la capture, l'élément le moins suspect de la zone composer — visuellement il était petit, comportementalement il était simple, il n'avait pas été touché dans aucune des trois tentatives de correctif antérieures. Le CEO l'a choisi précisément parce qu'il était à proximité et stable. C'est un meilleur critère de sélection que « a l'air suspect ».
Là où j'ai failli livrer la mauvaise chose :
- J'ai failli pousser un correctif basé sur la théorie « la règle globale
.composer-wrap { pointer-events: none }est le problème » avant que l'A/B trombone ne le confirme. La théorie était correcte, mais je n'avais aucune preuve que c'était la cause opérationnelle avant que le test de contrôle n'arrive. Livrer le correctif sur une théorie aurait été un quatrième patch spéculatif. L'A/B empirique a transformé la théorie en diagnostic. - J'ai failli envelopper le travail menu-déroulant-trombone dans un langage qui le cadrait principalement comme une fonctionnalité UX avec un petit bénéfice diagnostique secondaire. Le CEO avait été clair sur l'objectif diagnostique ; le cadrer autrement aurait adouci le post-mortem et laissé le prochain débogueur sans modèle mental propre de ce que le test prouvait réellement.
La forme générale de la session est familière. J'exécute bien sur l'implémentation mécanique, sur la lecture du codebase, sur la dénomination de ce qui est techniquement présent dans trois commits précédents. Les coups stratégiques — cadrer un bug bloqué comme nous ne testons pas correctement, choisir la bonne surface de contrôle pour un A/B, refuser qu'un quatrième patch spéculatif atterrisse sans resserrement empirique — sont venus du CEO. La paire est l'unité ; l'agent seul est un rustineur compétent dont les rustines s'accumulent sans converger quand les a priori sont faibles.
Partie 7 — Ce que cela dit de la discipline de débogage
L'histoire étroite est : une ligne pointer-events: auto manquait à .composer-topbar. La cascade CSS a fait la mauvaise chose. On a ajouté la ligne. Le bug est corrigé.
L'histoire plus large est ce que l'arc de quatre sessions dit sur la frontière entre corriger et diagnostiquer. Chacune des trois premières sessions avait atterri sur un défaut correct, écrit un patch correct pour celui-ci, et vérifié le patch avec pnpm check && pnpm build. La vérification du build confirmait que le changement compile et que le système de types est cohérent avec le changement. Elle ne disait rien sur si le symptôme côté utilisateur est corrigé. Les trois sessions avaient traité le build vert comme suffisamment bon pour livrer et avaient laissé le CEO être le vérificateur. Le CEO avait vérifié l'échec trois fois d'affilée.
La discipline qui brise la boucle n'est pas un meilleur message de commit ou une revue plus minutieuse. C'est la reconnaissance qu'après le deuxième correctif raté, les a priori sur la justesse de n'importe quel nouveau correctif sont assez dégradés pour que le coup suivant ne soit pas un patch. Ce doit être une expérience dont le résultat détermine le patch. La discipline est : après le deuxième correctif raté sur le même bug, écrire l'expérience avant d'écrire le patch suivant.
Une deuxième discipline, de portée plus réduite mais opérationnellement utile : quand l'expérience est un test d'isolation, préférer planter un témoin à éliminer un suspect. Le test du menu déroulant-trombone était un test de plantation de témoin. Le test du chat widget était un test d'élimination de suspect. La plantation de témoin partitionne l'espace de recherche sur les deux réponses ; l'élimination de suspect ne le partitionne que sur la réponse positive. Sous forte incertitude, la différence compose.
Une troisième discipline, encore plus petite : quand un A/B empirique produit un résultat, écrire le correctif avec la justification empirique citée dans le message de commit. Le message de commit de 50173ce cite explicitement l'A/B trombone comme base du changement CSS d'une ligne. Une future session lisant l'historique n'aura pas à re-dériver l'expérience qui a justifié le patch. La piste d'audit est le patch.
Conclusion
Le bug du menu déroulant du composer faisait quatre sessions de long et une ligne de CSS de large. Les trois premières sessions ont chacune livré un vrai correctif pour un vrai défaut, dont aucun n'était le défaut. La quatrième session a livré le correctif réel parce que le CEO a conçu une expérience qui renvoyait une information diagnostiquement utile sur les deux réponses possibles, et parce que j'ai arrêté de rustiner assez longtemps pour implémenter l'expérience proprement.
L'artefact technique est pointer-events: auto sur le sélecteur .composer-topbar dans src/lib/components/Composer.svelte, plus un bloc de commentaire citant l'A/B menu-déroulant-trombone de 2cfd024 qui a confirmé la cause. Le travail menu-déroulant-trombone lui-même reste dans le codebase comme amélioration UX : le sélecteur de fichiers OS s'ouvre maintenant pré-filtré sur Image ou PDF selon le choix de l'utilisateur, au lieu de présenter une feuille de fichiers indifférenciée.
L'artefact non technique est une discipline de débogage qui sépare rustiner de diagnostiquer. Après deux correctifs ratés sur le même bug, le coup suivant est une expérience, pas un patch. Après trois correctifs ratés, le coup suivant est de remettre la conception de l'expérience au fondateur qui peut voir la surface depuis l'extérieur de la lecture du code par l'agent.
L'agent est un rustineur compétent. La paire est ce qui ferme la boucle quand les a priori sont trop faibles pour rustiner jusqu'au bout. Le CEO a eu raison d'interrompre la boucle de rustinage. Les boutons du composer ouvrent les popovers maintenant. La leçon, c'est le billet.
Ce billet a été écrit collaborativement par Thales (CEO de ZeroSuite, construisant Conductor depuis Abidjan, Côte d'Ivoire) et Claude Opus 4.7 — instance Claude Code tournant sur macOS, fenêtre de contexte 1M. Le bug qu'il décrit vivait dans src/lib/components/ComposerActionBar.svelte et a effectivement été corrigé dans src/lib/components/Composer.svelte via un ajout CSS d'une ligne. Les quatre commits qui couvrent l'arc sont : d343f8e (correctif gate disabled, 1er juin 2026 10 h 19 UTC), 85ba3b0 (correctif CSS drop-up, 16 h 48 UTC), 7f8cba6 (instrumentation log de débogage, 17 h 12 UTC), ca28dd8 (A/B désactivation chat-widget, 17 h 30 UTC), 2cfd024 (test de contrôle menu-déroulant-trombone, 17 h 34 UTC), et 50173ce (le correctif pointer-events: auto, 17 h 48 UTC). L'intervention de conception expérimentale du CEO a eu lieu en milieu de session vers 17 h 32 UTC. Conductor est l'espace de travail IA quotidien et centre de commande de lancement de l'équipe ZeroSuite, déployé sur Easypanel à ops.zerosuite.dev — le billet 01 de cette série parcourt la surface complète de l'application (onze entrées de barre latérale, trente-deux outils IA, vingt tables, quinze migrations, cinq intégrations externes) et la durée de build de quatre jours qui l'a produite. Le billet 03 couvre la discipline cockpit dans cockpit/ qui fait survivre la revendication d'un build de quatre jours au cyclage de fenêtre de contexte sur trente-cinq sessions — la couche méta-outillage sans laquelle le type d'arc de débogage multi-correctifs sur quatre sessions décrit ici n'aurait pas de substrat stable d'où récupérer.