Suivi du code Claude: attentes d'autorisation de capture et résultats manquants

La surveillance du code Claude a besoin de trois couches, pas d'un tableau de bord. Utilisez le flux OpenTelemetry officiel de Claude Code pour la consommation et l'activité, les crochets du cycle de vie pour les attentes et les pannes du terminal, et une vérification du résultat que vous avez réellement demandé. Si vous omettez la troisième couche, une session peut avoir des traces propres, des appels d'outils réussis et une réponse finale polissée alors que le correctif attendu, le résultat du test ou le fichier manquent toujours. Le défaut raisonnable est délibérément faible: exporter des mesures et des événements édités, enregistrer six événements de cycle de vie sans leur charge utile de texte libre, puis évaluer le dernier événement par rapport à une prédication d'achèvement spécifique à la tâche. Ne recueillez pas d'invitations ou de contenu de l'outil brut simplement pour décider si une course a besoin d'attention. Ce guide construit cette conception à partir des schémas actuels du Code Claude et teste l'ordre de décision par rapport à sept sessions. Il n'assume pas qu'un appel à l'outil est un progrès, qu'une pause est un échec ou que Stop signifie que le travail est terminé. Commencez par trois questions différentes. La surveillance devient plus claire lorsque chaque signal répond à une question et qu'il est interdit de répondre aux deux autres. Couche Une question à laquelle il peut répondre Les signaux Ce qu'il ne peut pas prouver Télémétrie Qu'a consommé ou exécuté Claude Code ? séances, demandes d'API, jetons, coût estimé, résultats de l'outil, décisions relatives à l'outil, durée si le résultat demandé est correct Cycle de vie Pourquoi cette séance est elle silencieuse ou se termine t elle ? demande d'autorisation, notification, tâche d'arrière plan, réveil programmé, arrêt, tour de fin d'API, fin de session si un fichier, un test ou un résultat externe est valide Le résultat Cette tâche a t elle produit le résultat promis? hash du fichier, état de sortie du test, validation du schéma, réponse API, artefact signé pourquoi la séance a attendu ou combien cela a coûté Le documentation officielle de surveillance du code Claude expose les métriques par le protocole OTel métriques, les événements par des journaux/événements et les traces distribuées facultatives. Les mesures documentées comprennent le nombre de sessions, les lignes modifiées, les engagements, les demandes de retrait, le temps actif, les jetons et le coût estimé. Les événements ajoutent une corrélation rapide, des résultats API, des résultats des outils et des décisions d'autorisation. C'est une excellente preuve pour la première couche. Il ne s'agit pas d'un contrat d'achèvement. La distinction est importante dans le travail ordinaire. Un événement d'outil Write réussi indique que la rédaction est terminée. Il ne dit pas que le fichier prévu a été écrit à l'endroit approprié, que le programme qui en résulte compile, ou que l'utilisateur a demandé ce fichier. Les courbes de jetons et de coûts peuvent révéler une consommation fuyante, mais une session à faible coût peut toujours s'arrêter un pas avant le livrable. Ajouter des preuves de cycle de vie avec des crochets Claude Code Claude Codes les crochets de référence fournit une deuxième couche qui manque à un tableau de bord uniquement destiné à l'utilisation. Quatre événements sont particulièrement utiles: PermissionRequest est activé lorsque le dialogue d'autorisation est sur le point d'être affiché. Si c'est le dernier événement non résolu, la session attend une personne; elle n'est pas bloquée. Stop tire quand l'agent principal finit de répondre. Les entrées actuelles peuvent inclure background tasks et session crons , de sorte qu'un virage arrêté peut toujours être en attente d'une tâche de coquille, de subagent, de tâche de moniteur, de flux de travail, de tâche MCP ou de réveil programmé. StopFailure prend feu au lieu de Stop lorsqu'une erreur API termine le tour. Ses classes d'erreur documentées comprennent la limite de taux, la surcharge, l'authentification, la facturation, la demande invalide, le modèle manquant, l'erreur du serveur et les jetons de sortie maximaux. SessionEnd enregistre la raison pour laquelle la séance a pris fin. Il est utile pour le nettoyage et l'audit, mais il ne peut pas bloquer la résiliation. PostToolUse , PostToolUseFailure , Notification et PreCompact ajoutent un contexte utile. Gardez leur sémantique étroite: le PostToolUse récent est une preuve d'activité; le PostToolUseFailure répété est une preuve de problèmes d'outil; le PreCompact marque une transition contextuelle qui vaut la peine d'être corrélatée avec un comportement ultérieur. Aucune n'est un verdict universel. Pour un collecteur de confidentialité minimal, conservez uniquement un timestamp, un identifiant de session haché localement, le nom de l'événement, le nom de l'outil, la classe d'erreur, le type de notification et le nombre de tâches de fond ou de réveils programmés. Éliminer transcript path , cwd , last assistant message , commandes Bash, entrée de l'outil et texte de notification, à moins qu'un cas d'utilisation diagnostiqué ne les justifie. Les paramètres officiels OTel prennent en charge la même restriction. Le texte instantané, le texte d'assistance à la réponse, les arguments des outils, le contenu d'entrée/sortie des outils et les corps d'API brutes sont désactivés par défaut. L'activation de OTEL LOG RAW API BODIES peut exposer l'historique complet de la conversation; il ne devrait jamais être un interrupteur de dépannage occasionnel. Transformer les dernières preuves en un état L'ordre de décision ci dessous est assez petit pour inspecter. Il classe le dernier événement pour chaque session, tandis qu'un vérificateur externe fournit outcome verified lorsqu'un tour s'arrête. L'ordre est intentionnel. Une défaillance de l'API du terminal dépasse un événement d'activité récent. Une approbation non résolue attend, pas un délai. Le travail de fond empêche un événement Stop d'être traité comme terminé. Ce n'est qu'après l'exclusion de ces cas que le vérificateur décide entre complete et outcome missing . Le dispositif d'essai conservé utilise sept séances et un seuil d'exemple de 15 minutes: L'exécution de l'appareil à un timestamp fixe reproduit les sept lignes: C'est une règle de décision, pas un démon de production. Le seuil de 15 minutes est mauvais pour un travail de deux minutes et mauvais pour une construction de deux heures. Définir la fraîcheur de la cadence et de la durée attendues du travail, puis conserver une trajectoire uncertain pour les preuves manquantes ou contradictoires. Définir l'achèvement en dehors de la conversation La seule entrée spécifique à l'application du classifiateur est outcome verified . Ce bit devrait provenir d'une vérification déterministique chaque fois que possible, pas de la recherche du message d'assistant final pour done. Pour une tâche de modification de code, une réalisation utile peut nécessiter: 1. les dossiers attendus diffèrent de l'engagement initial; 2. la commande d'essai ciblée sort avec succès; 3. les décodes des artefacts générés ou l'emballage peuvent être importés; 4. le résultat reste dans le référentiel et le champ d'application approuvés. Pour effectuer une tâche de documentation, vous devez utiliser le fichier de destination, la validation de frontmatter ou de schéma, tous les chemins locaux cités et tout vérificateur de liens dont le référentiel a déjà confiance. Pour une exportation de données, vérifiez le fichier attendu, analysez le, validez les colonnes requises et comparez le nombre de lignes avec la limite source. Pour un changement d'API, exécutez le test du contrat plutôt que d'accepter une demande HTTP qui est simplement retournée. Le moniteur doit stocker le nom du vérificateur, l'état de sortie, le temps d'observation et un résumé du résultat, et non une explication fabriquée. Lorsqu'aucun prédicat déterministe n'existe, enregistrez outcome unknown . Un résultat inconnu peut demander une révision; il ne doit pas devenir sain en silence. Alerte sur la prochaine action sûre Sept États n'ont pas besoin de sept alarmes. Route chaque état à la plus petite action utile: État Action par défaut working Ne fais rien waiting human notifier à la personne responsable la catégorie de permis sans l'approuver waiting background montrer la dépendance et sa fraîcheur; ne pas redémarrer la séance failed: exposer la classe d'erreur et la politique de réessayer limitée outcome missing montrer les résultats négatifs et préserver le travail à l'inspection stalled vérifier la disponibilité et la durée attendues avant de proposer une poussée limitée complete conserver les preuves et fermer le dossier Ce routage empêche deux erreurs coûteuses. Premièrement, il évite de réessayer un agent qui attend correctement l'autorité. Deuxièmement, il évite de célébrer un arrêt de conversation lorsque les preuves du projet disent que le résultat est absent. La récupération automatisée nécessite des limites plus strictes que la surveillance. Une défaillance de la limite de taux peut être réinitialisée après une sauvegarde; une défaillance d'authentification nécessite généralement une personne; une demande d'autorisation ne doit pas être approuvée automatiquement simplement parce qu'elle est ancienne. Après toute intervention, redémarrer le prédicat de finition. Un commandement réussi est la preuve d'une activité, pas la preuve que la tâche initiale s'est rétablie. Appliquer la conception sans trop collecter Un déploiement pratique peut rester progressif: 1. Activer la télémétrie Claude Code avec des mesures et des événements, en laissant tous les interrupteurs de l'enregistrement de contenu désactivés. 2. Confirmez que claude code.session.count ou claude code.user prompt atteint le collectionneur avant de construire des alertes. 3. Ajouter des crochets locaux pour PermissionRequest , Stop , StopFailure , Notification , PreCompact et SessionEnd . 4. Normaliser ces charges utiles de crochet dans l'enveloppe minimale; identifiants de hachage localement et les chemins de dépôt et texte libre. 5. Définir un prédicat d'achèvement déterministe pour une tâche conséquente. 6. Répétez les événements synthétiques pour chaque État avant d'en informer quiconque. 7. Ajoutez une alerte uniquement lorsque son propriétaire et la prochaine action sûre sont explicites. La version du normalisateur. Claude Code documente des versions minimales pour plusieurs champs, et les transcriptions internes ne sont pas explicitement un contrat stable. Préférer les champs crochet et OTel exposés par la documentation actuelle; ne construisez pas un moniteur à longue durée de vie en grattant les pixels terminaux ou en supposant qu'une forme de transcription privée ne changera jamais. La limite utile pour le Sidewisp Claude Code fournit déjà de forts signaux bruts. L'écart opérationnel transforme ces signaux en une décision de santé restreinte: fonctionner, attendre, échouer, périmer ou manquer de son résultat promis, puis montrer les preuves et la prochaine étape la plus sûre. Sidewisp est actuellement en préversion privée. Son site public et son système d'articles sont en direct, mais les adaptateurs de surveillance Claude Code de production, la collecte des agents et la récupération ne sont généralement pas expédiés. Le rôle prévu est une couche de santé à côté des temps d'exécution existants, et non un temps d'exécution de remplacement, une passerelle de modèle obligatoire ou un fixateur autonome. Si cette limite correspond à la façon dont vous opérez avec des agents de codage, la liste d'attente d'aperçu privé est la prochaine étape appropriée. Jusqu'alors, le modèle à trois couches de ce guide est utilisable par lui même: télémétrie pour l'activité, crochets pour le cycle de vie et vérifications déterministes pour les résultats.