Disler Claude Code Hooks Osservabilità multi-agente: dimostrazione della consegna degli eventi

La risposta sicura è: non considerare una dashboard raggiungibile o un codice di uscita con zero hook come prova che la pipeline di osservabilità multi agente di Disler hooks sia integra. Richiedi una ricevuta a ogni limite (configurazione, consegna HTTP, persistenza SQLite, consegna WebSocket e aggiornamento del browser), quindi verifica il lavoro al di fuori del percorso di monitoraggio. Questa distinzione è importante perché l'architettura del repository è una catena: agenti Claude → script hook → POST HTTP → server Bun → SQLite → WebSocket → client Vue. Un evento luminoso nell'ultima casella dimostra che un evento ha attraversato la catena. Una quiet box non dice dove si sono fermate le prove e un evento Stop non dimostra che il file, il test, la distribuzione o il trasferimento richiesti esista. Ho controllato il commit del repository 8a6e5cf e ho riprodotto nove casi privi di contenuto. Una regola ingenua che controlla solo il codice di uscita del processo di hook, li ha contrassegnati tutti e nove in verde. La regola di ricezione li classificava tutti e nove come previsto; solo uno era sano. Blocca il repository e definisci il contratto di prova Inizia con il codice effettivamente eseguito. Al commit bloccato, .claude/settings.json configura dodici gruppi di eventi: SessionStart , SessionEnd , UserPromptSubmit , PreToolUse , PostToolUse , PostToolUseFailure , PermissionRequest , Notification , SubagentStart , SubagentStop , Stop e PreCompact . Il correnteRiferimento ganci Claude Codedocumenta trenta eventi del ciclo di vita. Questo set più ampio include segnali di squadra e di errore più recenti come TaskCreated , TaskCompleted , TeammateIdle , StopFailure e PostToolBatch . Il confronto non significa che ogni installazione dovrebbe catturarli tutti e trenta. Significa che "tutti gli hook" è un'affermazione con versione: definisci gli eventi minimi richiesti dalla tua decisione operativa, aggiungi la versione Claude Code e fallisci il controllo di copertura quando la configurazione non corrisponde più a quel manifest. Per un canary ad agente singolo, un minimo ragionevole è SessionStart , uno PreToolUse e PostToolUse accoppiati e Stop . Per un'esecuzione in team, aggiungi il ciclo di vita del subagente e i segnali dell'attività o del compagno di squadra esposti dalla versione Claude Code installata. Un evento mancante ha significato solo dopo aver stabilito che era previsto e configurato. Il limite successivo è il mittente. L'appuntato send event.py utilizza un timeout HTTP di cinque secondi. Restituisce False e scrive su stderr quando la richiesta fallisce, ma main() non utilizza quel risultato: esce con codice zero incondizionatamente, quindi il monitoraggio non può bloccare Claude Code. Si tratta di una scelta di disponibilità difendibile, ma rende il codice di uscita zero un segnale di attività piuttosto che una conferma di consegna. Il server fornisce una ricevuta più forte. Suo POST /events il percorso convalida i campi richiesti, inserisce l'evento, quindi restituisce il record salvato e lo trasmette ai client WebSocket connessi. Conserva l'ID del database restituito per un canary. Una connessione HTTP senza un ID salvato non costituisce una prova equivalente. La ricetta just health del repository necessita della stessa interpretazione. Richiede /health , ma il server bloccato non ha un ramo di integrità dedicato; i percorsi senza corrispondenza ricevono la risposta Multi Agent Observability Server generica con HTTP 200. Ciò dimostra che il processo ha risposto a HTTP. Non influisce sull'inserimento di eventi, sulla leggibilità di SQLite, sulla consegna di WebSocket o sulla visualizzazione corrente del browser. Utilizzare un contratto esplicito: Ricevuta Prove da conservare Ciò che non dimostra Configurazione manifesto dell'evento bloccato e valore dell'app di origine che un gancio ha sparato Trasporto HTTP 200 più l'ID evento salvato che il browser lo ha ricevuto Persistenza lo stesso ID visibile negli eventi recenti che la vista è attuale Presentazione WebSocket o la riproduzione di riconnessione contiene l'ID che tutti gli eventi richiesti siano arrivati Copertura ogni evento richiesto appare prima della sua scadenza quel lavoro è riuscito Risultato controllo deterministico del deliverable previsto che le corse future rimangano sane Riproduci il controllo della consegna prima di considerare attendibile la vista Ho codificato questi confini in un dispositivo senza istruzioni, trascrizioni, input di strumenti, percorsi di file o segreti. Eseguilo con: La replica ha prodotto: Il classificatore utilizza la precedenza. Innanzitutto controlla se un hook exit zero ha effettivamente raggiunto il server. Quindi richiede una ricevuta di persistenza, controlla se la consegna del browser è aggiornata, convalida il manifest configurato, fa scadere le prove obsolete, preserva un'attesa legittima prima della scadenza e solo allora chiede se esiste il risultato previsto. Apparecchio Classificazione Decisione dell'operatore Il mittente esce da zero dopo il POST non riuscito delivery failed hidden controllare lo stderr del mittente e la raggiungibilità del server HTTP accettato ma nessun ID salvato persistence unverified non dedurre lo stoccaggio dal trasporto SQLite ha l'evento ma WebSocket no dashboard stale riconnettersi e verificare la riproduzione prima di diagnosticare l'agente Gli eventi del team sono obbligatori ma non configurati manifest drift aggiornare o restringere il manifest bloccato L'evento configurato non arriva mai coverage gap ispezionare il matcher, il processo di hook e la compatibilità della versione La dipendenza dall'autorizzazione è precedente alla scadenza waiting indirizzare la decisione al suo proprietario; non chiamatelo bloccato Stop arriva senza ricevuta di consegna false complete verificare il risultato esterno prima di cancellare la corsa Rimangono solo vecchi eventi stale scadono in verde e segnalano le prove come non disponibili Ogni confine e risultato passa healthy accettare questa esecuzione, non l'intera installazione per sempre Il ramo waiting impedisce un falso allarme comune. Se una richiesta di autorizzazione ha un proprietario nominato e una scadenza non scaduta, è prevista l'assenza di un risultato successivo dello strumento. Dopo la scadenza, o quando non esiste alcun proprietario, la stessa prova diventa un problema di copertura o di avanzamento. Il tempo e la proprietà cambiano la diagnosi; il conteggio degli eventi da solo non può. Il ramo false complete impedisce l'errore opposto. Il riferimento ufficiale di Claude Code definisce Stop come la fine di una risposta. Il repository può mostrare fedelmente questo fatto del ciclo di vita. Nessuno dei due sistemi afferma che la destinazione è cambiata. Un'attività file richiede il percorso previsto e il controllo del contenuto; un'attività di codice necessita di test pertinenti; un'azione remota necessita di una ricevuta di destinazione. Mantenere tali controlli fuori dal trasporto con gancio in modo che il sistema di monitoraggio non possa certificarsi. C’è anche un compromesso sulla privacy. Il repository supporta l'acquisizione di chat opzionale e visualizza i dati relativi ai prompt. Nemmeno l'integrità della consegna lo richiede. Un canary può utilizzare solo identificatori opachi come source app , session id , hook event type , timestamp e ID evento restituito. Ridurre al minimo l'inviluppo prima di espandere l'osservabilità. Aziona un piccolo canarino, poi verifica il reale risultato Adottare l'audit in cinque passaggi delimitati. 1. Aggiungi versioni e ambito. Registra il commit del repository, la versione Claude Code, l'identificatore dell'app di origine e gli esatti eventi del ciclo di vita richiesti per la tua decisione. Rivedi il riferimento ufficiale agli hook quando una delle due versioni cambia. 2. Invia un canary univoco. Utilizza un identificatore di sessione usa e getta e un payload PreToolUse innocuo. Richiede HTTP 200 e analizza l'ID evento salvato restituito. Non utilizzare solo il codice di uscita del gancio. 3. Dimostra l'archiviazione e la presentazione. Interroga immediatamente /events/recent e trova l'ID esatto. Ricollegare il client Vue o uno WebSocket di prova a /stream e richiedere lo stesso evento nella riproduzione iniziale o nel messaggio live. Mantieni il controllo all'interno della finestra di replay; il server bloccato invia 300 righe recenti quando si apre un WebSocket. 4. Verifica copertura e aggiornamento. Esegui una sequenza nota del ciclo di vita, confronta i tipi di eventi osservati con il manifest bloccato e applica scadenze per evento. L'autorizzazione di proprietà del percorso attende come in attesa. Fai scadere le vecchie prove invece di mantenere il verde stantio. 5. Verifica il risultato dell'utente separatamente. Dichiara il file previsto, il risultato del test, lo stato dell'attività o l'effetto esterno. Un monitor dovrebbe segnalare false complete quando il ciclo di vita si chiude senza quella ricevuta. Questo processo ha dei limiti. Testa la consegna configurata attraverso il repository bloccato; non stabilisce la correttezza semantica per ogni carico utile. L'aggiunta di ogni hook disponibile può aumentare la latenza, l'archiviazione e l'esposizione dei dati sensibili. Un manifest minimo e con versione è solitamente più sicuro della raccolta indiscriminata. L'incontro in nove casi dimostra la regola decisionale, non la prevalenza di fallimenti nella produzione. Sidewisp si adatta a questo limite come livello di integrità, non come un altro runtime Claude Code o come sostituto del repository. Sidewisp è attualmente in anteprima privata. Il sito pubblico e la dimostrazione interattiva sono attivi, ma non vengono spediti un adattatore di monitoraggio Claude Code di produzione, un raccoglitore dell'integrità in tempo reale e un esecutore di ripristino automatizzato. Il recupero rimane una capacità pianificata e soggetta ad approvazione; l'onesto passo successivo attuale è unirsi alla lista d'attesa per l'anteprima privata se questo modello di ricevuta corrisponde al modo in cui gestisci gli agenti. Per questo repository, mantieni la regola compatta: un evento del dashboard è la prova dell'attività osservata. Dichiarare l'esecuzione sana solo quando il manifesto dell'evento richiesto è aggiornato, il canary dispone di ricevute di trasporto, persistenza e presentazione, qualsiasi attesa ha un proprietario e una scadenza e il risultato previsto supera il proprio controllo deterministico.