Disler Claude Code Hooks Observabilité multi-agents : prouver la livraison d'événements

La réponse sûre est la suivante : ne considérez pas un tableau de bord accessible ou un code de sortie sans hook comme une preuve que le pipeline d'observabilité multi agents hooks Claude Code de Disler est sain. Exigez un reçu à chaque limite (configuration, livraison HTTP, persistance SQLite, livraison WebSocket et fraîcheur du navigateur), puis vérifiez le travail en dehors du chemin de surveillance. Cette distinction est importante car l'architecture propre du référentiel est une chaîne : agents Claude → scripts hook → HTTP POST → serveur Bun → SQLite → WebSocket → client Vue. Un événement marquant dans la dernière case prouve qu'un événement a traversé la chaîne. Une zone silencieuse ne vous indique pas où la preuve s'est arrêtée, et un événement Stop ne prouve pas que le fichier, le test, le déploiement ou le transfert demandé existe. J'ai audité la validation du référentiel 8a6e5cf et rejoué neuf cas sans contenu. Une règle naïve qui vérifie uniquement le code de sortie du processus de hook marqué tous les neuf en vert. La règle de réception a classé les neuf comme prévu ; un seul était en bonne santé. Épinglez le référentiel et définissez le contrat de preuve Commencez par le code que vous exécutez réellement. Au commit épinglé, .claude/settings.json configure douze groupes d'événements : SessionStart , SessionEnd , UserPromptSubmit , PreToolUse , PostToolUse , PostToolUseFailure , PermissionRequest , Notification , SubagentStart , SubagentStop , Stop et PreCompact . Le courantRéférence des crochets Claude Codedocumente trente événements du cycle de vie. Cet ensemble plus large comprend des signaux d'équipe et d'échec plus récents tels que TaskCreated , TaskCompleted , TeammateIdle , StopFailure et PostToolBatch . La comparaison ne signifie pas que chaque installation doit capturer les trente. Cela signifie que « tous les hooks » est une revendication versionnée : définissez les événements minimaux requis par votre décision d'exploitation, épinglez la version Claude Code et échouez à la vérification de la couverture lorsque la configuration ne correspond plus à ce manifeste. Pour un canari à agent unique, un minimum raisonnable est SessionStart , une paire PreToolUse et PostToolUse et Stop . Pour une exécution en équipe, ajoutez le cycle de vie du sous agent et les signaux de tâche ou de coéquipier exposés par votre version Claude Code installée. Un événement manquant n'est significatif qu'une fois que vous avez établi qu'il était attendu et configuré. La prochaine limite est l’expéditeur. L'épinglé send event.py utilise un délai d'attente HTTP de cinq secondes. Il renvoie False et écrit dans stderr lorsque la requête échoue, mais main() n'utilise pas ce résultat : il se termine sans condition avec le code zéro, de sorte que la surveillance ne peut pas bloquer Claude Code. Il s’agit d’un choix de disponibilité défendable, mais cela fait du code de sortie zéro un signal d’activité plutôt qu’un accusé de réception. Le serveur fournit un reçu plus solide. C'est POST /events path valide les champs obligatoires, insère l'événement, puis renvoie l'enregistrement enregistré et le diffuse aux clients WebSocket connectés. Conservez l'ID de base de données renvoyé pour un canari. Une connexion HTTP sans ID enregistré ne constitue pas une preuve équivalente. La recette just health du référentiel nécessite la même interprétation. Il demande /health , mais le serveur épinglé n'a pas de branche de santé dédiée ; les chemins sans correspondance reçoivent la réponse générique Multi Agent Observability Server avec HTTP 200. Cela prouve que le processus a répondu à HTTP. Il n'exerce pas l'insertion d'événements, la lisibilité de SQLite, la livraison de WebSocket ou une vue actuelle du navigateur. Utilisez un contrat explicite : Reçu Preuve à conserver Ce que cela ne prouve pas Configuration Manifeste d'événement épinglé et valeur de l'application source qu'un crochet a tiré Transport HTTP 200 plus l'ID d'événement enregistré que le navigateur l'a reçu Persistance le même identifiant visible dans les événements récents que la vue est actuelle Présentation WebSocket ou la relecture de reconnexion contient l'ID que tous les événements requis sont arrivés Couverture chaque événement requis apparaît avant sa date limite ce travail a réussi Résultat contrôle déterministe du livrable prévu que les futures courses restent en bonne santé Rejouez l'audit de livraison avant de faire confiance à la vue J'ai codé ces limites dans un appareil sans invites, transcriptions, entrées d'outils, chemins de fichiers ou secrets. Exécutez le avec : La rediffusion produit : Le classificateur utilise la priorité. Il vérifie d’abord si un hook de sortie zéro a réellement atteint le serveur. Il requiert ensuite un reçu de persistance, vérifie si la livraison du navigateur est à jour, valide le manifeste configuré, expire les preuves périmées, conserve une attente légitime avant sa date limite et demande ensuite seulement si le résultat escompté existe. Fixation Classification Décision de l'opérateur L'expéditeur quitte zéro après l'échec du POST delivery failed hidden inspecter le stderr de l'expéditeur et l'accessibilité du serveur HTTP accepté mais aucun identifiant enregistré persistence unverified ne pas déduire le stockage du transport SQLite a l'événement mais pas WebSocket dashboard stale reconnectez vous et vérifiez la relecture avant de diagnostiquer l'agent Les événements d'équipe sont obligatoires mais non configurés manifest drift mettre à jour ou affiner le manifeste épinglé L'événement configuré n'arrive jamais coverage gap inspecter le matcher, le processus de hook et la compatibilité des versions La dépendance aux autorisations est avant sa date limite waiting acheminer la décision vers son propriétaire ; ne l'appelle pas coincé Stop arrive sans reçu de livrable false complete vérifier le résultat externe avant d'effacer l'analyse Il ne reste que les événements anciens stale expirer en vert et signaler les preuves comme indisponibles Chaque frontière et résultat passe healthy acceptez cette exécution, pas l'installation entière pour toujours La branche waiting évite les fausses alarmes courantes. Si une demande d'autorisation a un propriétaire nommé et un délai non expiré, l'absence de résultat ultérieur de l'outil est attendue. Passé le délai, ou lorsqu'il n'existe aucun propriétaire, la même preuve devient un problème de couverture ou de progression. Le temps et la propriété changent le diagnostic ; le décompte des événements à lui seul ne peut pas le faire. La branche false complete évite l’erreur inverse. La référence officielle de Claude Code définit Stop comme la fin d'une réponse. Le référentiel peut afficher fidèlement ce fait du cycle de vie. Aucun des deux systèmes ne prétend que la destination a changé. Une tâche de fichier nécessite la vérification du chemin et du contenu attendus ; une tâche de code nécessite des tests pertinents ; une action à distance nécessite un reçu de destination. Conservez ces contrôles en dehors du transport du crochet afin que le système de surveillance ne puisse pas se certifier. Il existe également un compromis en matière de confidentialité. Le référentiel prend en charge la capture de chat facultative et affiche les données liées aux invites. La santé de livraison n’exige pas non plus. Un canari ne peut utiliser que des identifiants opaques tels que source app , session id , hook event type , l'horodatage et l'ID d'événement renvoyé. Réduisez l’enveloppe avant d’étendre l’observabilité. Faites fonctionner un petit canari, puis vérifiez le résultat réel Adoptez l’audit en cinq étapes délimitées. 1. Épinglez les versions et la portée. Enregistrez la validation du référentiel, la version Claude Code, l'identifiant de l'application source et les événements exacts du cycle de vie requis pour votre décision. Consultez la référence officielle des hooks lorsque l’une ou l’autre version change. 2. Envoyez un canari unique. Utilisez un identifiant de session jetable et une charge utile PreToolUse inoffensive. Exigez HTTP 200 et analysez l’ID d’événement enregistré renvoyé. N'utilisez pas le code de sortie du hook seul. 3. Prouvez le stockage et la présentation. Interrogez immédiatement /events/recent et trouvez cet identifiant exact. Reconnectez le client Vue ou un test WebSocket à /stream et exigez le même événement dans la rediffusion initiale ou le message en direct. Conservez le chèque à l'intérieur de la fenêtre de relecture ; le serveur épinglé envoie 300 lignes récentes lorsqu'un WebSocket s'ouvre. 4. Vérifiez la couverture et la fraîcheur. Exécutez une séquence de cycle de vie connue, comparez les types d'événements observés avec le manifeste épinglé et appliquez des délais par événement. L'autorisation appartenant à la route attend. Faites expirer les anciennes preuves au lieu de conserver le vert obsolète. 5. Vérifiez le résultat de l'utilisateur séparément. Affirmez le fichier attendu, le résultat du test, l'état de la tâche ou l'effet externe. Un moniteur doit signaler false complete lorsque le cycle de vie se termine sans ce reçu. Ce processus a des limites. Il teste la livraison configurée via le référentiel épinglé ; il n'établit pas l'exactitude sémantique pour chaque charge utile. L’ajout de tous les hooks disponibles peut augmenter la latence, le stockage et l’exposition des données sensibles. Un manifeste minimal et versionné est généralement plus sûr qu’une collecte aveugle. Le montage de neuf cas démontre la règle de décision, et non la prévalence des échecs de production. Sidewisp correspond à cette limite en tant que couche de santé, et non en tant qu'autre environnement d'exécution Claude Code ou remplacement du référentiel. Sidewisp est actuellement en préversion privée. Le site public et la démonstration interactive sont en direct, mais un adaptateur de surveillance Claude Code de production, un collecteur d'intégrité en direct et un exécuteur de récupération automatisé ne sont pas livrés. La récupération reste une capacité planifiée et limitée à l’approbation ; la prochaine étape honnête actuelle consiste à rejoindre la liste d'attente de l'aperçu privé si ce modèle de reçu correspond à la façon dont vous exploitez les agents. Pour ce référentiel, gardez la règle compacte : un événement de tableau de bord est une preuve de l'activité observée. Déclarez l'exécution saine uniquement lorsque le manifeste d'événement requis est à jour, que le canari dispose des reçus de transport, de persistance et de présentation, que toute attente a un propriétaire et une date limite et que le résultat attendu passe son propre contrôle déterministe.