Les signaux de complétion de Claude Code ne cessent de changer. Voici comment nous suivons

MadoHub a besoin de savoir à l'instant où un agent termine un tour — c'est le bord qui déclenche le routage, fait passer un tile de working à done, et indique à un agent connecté qu'il est sûr de récupérer la sortie. Pendant un moment, notre réponse à « comment savoir que Claude Code a fini » était une correspondance de chaîne littérale. Ça marchait, jusqu'à ce que Claude Code livre une release avec un mot différent dedans, et ça a cessé de marcher. C'est l'histoire de ce qui l'a remplacé, et pourquoi le remplaçant n'est même pas la vraie correction.

Le problème ou l'insight

La liste de mots qui s'est périmée à l'heure prévue

Claude Code imprime une bannière d'une ligne quand il termine un tour : quelque chose comme ✽ Worked for 2m 30s. La toute première version de notre détecteur matchait deux verbes spécifiques de cette bannière — Sautéed et Cogitated — parce que c'étaient les mots que Claude Code imprimait à l'époque. La détection était un contrôle de mot-clé : vois le mot, démarre la minuterie d'inactivité, déclenche la route.

Ça a tenu exactement aussi longtemps que Claude Code a continué à utiliser ces deux mots. Ce n'est plus le cas. Le verbe est tiré d'un ensemble rotatif et fantaisiste — Worked, Churned, Sautéed, Cogitated, et d'autres — qui change entre les releases, apparemment comme un peu de personnalité du CLI. Chaque fois que la liste de mots changeait, notre pattern match cessait silencieusement de se déclencher, et chaque tile qui l'utilisait arrêtait de détecter les complétions jusqu'à ce que quelqu'un remarque et ajoute le nouveau mot.

Poursuivre une cible mouvante en l'énumérant est un jeu perdant. La correction, c'était d'arrêter de se soucier du mot.

Matcher la forme, pas le mot

Toute bannière de complétion a la même structure quel que soit le verbe livré cette semaine : un glyphe de spinner en début de ligne, un verbe au passé capitalisé, le littéral for, et une durée. Quel que soit le verbe livré à la prochaine release, tant qu'il s'inscrit dans cette forme, la détection continue de marcher sans modification de code. L'exigence du glyphe compte parce que la sortie du terminal est pleine de prose qui s'inscrit dans « verbe + for + durée » sans signifier que le tour est fini — une boucle de retry imprimant Retried for 3s, une étape de build loguant Waited for 5s. Exiger le glyphe en début de ligne, et ces fausses correspondances disparaissent.

Comment MadoHub gère ça

Le match de bannière est une accélération, pas le verdict

Ce match de bannière n'est pas le moyen principal par lequel MadoHub décide qu'un agent Claude Code a fini — c'est une accélération. Le signal autoritatif vient d'un watcher backend qui lit directement la transcription de session de Claude Code : il regarde le dernier message écrit dans le log, et si c'est un message d'assistant sans appel d'outil en attente, l'agent a fini ; si c'est un message utilisateur, un message de progression, ou un message d'assistant en plein appel d'outil, l'agent travaille encore. Ce verdict est étiqueté pour que le reste de l'application puisse distinguer un fait basé sur transcription d'une supposition de screen-scrape.

Le match de bannière n'existe que pour réduire la latence de ce watcher dans le cas courant où vous fixez le terminal et voulez que le tile bascule à l'apparition de la bannière, plutôt que d'attendre que le watcher rattrape son retard.

Pourquoi un match manqué va, mais pas un faux

Entre un match trop strict et un match trop lâche, MadoHub penche strict — un arbitrage délibéré qui mérite d'être détaillé. Un match de bannière manqué est inoffensif : le watcher rapporte quand même l'arrêt réel peu après. Un faux match de bannière n'est pas inoffensif, parce qu'il peut déclencher le routage dans un tile en plein tour. MadoHub fait donc de la défense en profondeur par-dessus le match d'écran : si un verdict « done » issu de l'écran apparaît alors qu'un verdict live du watcher dit que l'agent travaille encore, MadoHub droppé le verdict écran plutôt que d'agir dessus — la parole du watcher sur la complétion est finale.

Conseils pratiques

• Si vous surveillez un tile Claude Code et voulez prédire quand une route se déclenchera, ne mémorisez pas le verbe de cette semaine. Ce sera un autre dans quelques releases. Apprenez la forme à la place : glyphe, verbe au passé capitalisé, for, durée, le tout sur une ligne. C'est la partie du signal que Claude Code ne va pas cesser d'imprimer, même s'il continue de changer le mot au milieu.
• Si l'état d'un tile semble jamais faux, trustez le watcher, pas l'écran. MadoHub le fait — la transcription est le signal qu'il truste réellement, et le match de bannière n'est là que pour rendre le cas courant plus vif. Si vous voyez un tile basculer à « done » puis rebasculer, c'est le watcher corrigeant un match de bannière trop zélé, pas un bug.
• N'écrivez pas votre propre routage qui dépend d'un verbe spécifique. Si vous construisez des Flows ou des connexions qui s'appuient sur les complétions Claude Code, reposez-vous sur l'état de MadoHub (working / done / failed) plutôt que de matcher le texte de bannière vous-même — sinon la prochaine release de Claude Code cassera silencieusement votre setup comme notre premier détecteur a cassé.
• Attendez un bref décalage, pas des flips instantanés, quand le chemin watcher est occupé. Le match de bannière rend le cas courant instantané, mais sur une machine chargée le watcher est la garantie toujours correcte, et il peut prendre un moment. Une seconde ou deux de décalage est normal ; un tile qui ne bascule jamais ne l'est pas.

Cela remplace la version raccourcie de ce conseil dans notre post d'astuces Claude Code — celui-ci vous disait de surveiller la forme et de passer ; celui-ci est l'explication complète de pourquoi cette forme est la bonne à surveiller, et pourquoi, en dessous, la transcription de session est le signal que MadoHub truste réellement.

Documentation associée

• Détection d'agents
• Routage d'agents
• Mission Control