Disler Claude Code Ganchos a observabilidade multiagente: comprove a entrega do evento

A resposta segura é: não trate um painel acessível ou um código de saída de gancho zero como prova de que o pipeline de observabilidade multiagente de ganchos Disler Claude Code está íntegro. Exija um recibo em cada limite – configuração, HTTP entrega, SQLite persistência, WebSocket entrega e atualização do navegador – e verifique o trabalho fora do caminho de monitoramento. Essa distinção é importante porque a própria arquitetura do repositório é uma cadeia: agentes Claude → scripts de gancho → HTTP POST → Bun servidor → SQLite → WebSocket → Vue cliente. Um evento brilhante na última caixa prova que um evento atravessou a cadeia. Uma caixa silenciosa não informa onde a evidência parou e um evento Stop não prova que o arquivo, teste, implantação ou transferência solicitado existe. Auditei o commit do repositório 8a6e5cf e reproduzi nove casos sem conteúdo. Uma regra ingênua que verifica apenas o código de saída do processo de gancho marcou todos os nove em verde. A regra de recebimento classificou todos os nove como esperado; apenas um era saudável. Fixe o repositório e defina o contrato de evidência Comece com o código que você realmente executa. No commit fixado, .claude/settings.json configura doze grupos de eventos: SessionStart , SessionEnd , UserPromptSubmit , PreToolUse , PostToolUse , PostToolUseFailure , PermissionRequest , Notification , SubagentStart , SubagentStop , Stop e PreCompact . O atual Claude Code referência de ganchos documenta trinta eventos do ciclo de vida. Esse conjunto maior inclui sinais de equipe e falha mais recentes, como TaskCreated , TaskCompleted , TeammateIdle , StopFailure e PostToolBatch . A comparação não significa que cada instalação deva capturar todos os trinta. Isso significa que “todos os ganchos” é uma reivindicação versionada: defina os eventos mínimos que sua decisão operacional exige, fixe a versão Claude Code e falhe na verificação de cobertura quando a configuração não corresponder mais a esse manifesto. Para um canário de agente único, um mínimo razoável é SessionStart , um par PreToolUse e PostToolUse e Stop . Para uma execução em equipe, adicione o ciclo de vida do subagente e os sinais de tarefa ou colega de equipe que sua versão Claude Code instalada expõe. Um evento ausente só será significativo depois que você estabelecer que ele era esperado e configurado. O próximo limite é o remetente. O send event.py fixado usa um tempo limite HTTP de cinco segundos. Ele retorna False e grava em stderr quando a solicitação falha, mas main() não usa esse resultado: ele sai com código zero incondicionalmente para que o monitoramento não possa bloquear Claude Code. Essa é uma escolha defensável de disponibilidade, mas torna o código de saída zero um sinal de atividade em vez de um recibo de entrega. O servidor fornece um recibo mais forte. Seu caminho POST /events valida os campos obrigatórios, insere o evento, retorna o registro salvo e o transmite para clientes WebSocket conectados. Retenha o ID do banco de dados retornado para um canário. Uma conexão HTTP sem um ID salvo não é uma evidência equivalente. A receita just health do repositório precisa da mesma interpretação. Solicita /health , mas o servidor fixado não possui branch de saúde dedicado; caminhos incomparáveis ​​recebem a resposta genérica Multi Agent Observability Server com HTTP 200. Isso prova que o processo foi respondido HTTP. Não exerce inserção de eventos, SQLite legibilidade, WebSocket entrega ou visualização atual do navegador. Use um contrato explícito: Recibo Evidências para reter O que isso não prova Configuração manifesto de evento fixado e valor do aplicativo de origem que um gancho disparou Transporte HTTP 200 mais o ID do evento salvo que o navegador o recebeu Persistência o mesmo ID visível em eventos recentes que a visualização é atual Apresentação WebSocket ou reconectar o replay contém o ID que todos os eventos necessários chegaram Cobertura cada evento obrigatório aparece antes do prazo esse trabalho deu certo Resultado verificação determinística da entrega pretendida que as corridas futuras permaneçam saudáveis Repita a auditoria de entrega antes de confiar na visualização Codifiquei esses limites em um dispositivo sem prompts, transcrições, entradas de ferramentas, caminhos de arquivos ou segredos. Execute o com: A repetição produziu: O classificador usa precedência. Ele primeiro verifica se um gancho de saída zero realmente atingiu o servidor. Em seguida, ele exige um recebimento de persistência, verifica se a entrega do navegador está atualizada, valida o manifesto configurado, expira a evidência obsoleta, preserva uma espera legítima antes do prazo e só então pergunta se o resultado pretendido existe. Calendário Classificação Decisão do operador Remetente sai do zero após falha POST delivery failed hidden inspecionar o stderr do remetente e a acessibilidade do servidor HTTP aceito, mas sem ID salvo persistence unverified não inferir o armazenamento do transporte SQLite tem o evento, mas WebSocket não dashboard stale reconecte e verifique a reprodução antes de diagnosticar o agente Os eventos da equipe são obrigatórios, mas não configurados manifest drift atualizar ou restringir o manifesto fixado O evento configurado nunca chega coverage gap inspecionar matcher, processo de gancho e compatibilidade de versão A dependência da permissão está antes do prazo waiting encaminhar a decisão ao seu proprietário; não chame isso de preso Stop chega sem recibo de entrega false complete verifique o resultado externo antes de cancelar a execução Apenas eventos antigos permanecem stale expirar em verde e relatar evidências como indisponíveis Cada limite e resultado passa healthy aceite esta execução, não toda a instalação para sempre O ramal waiting evita um alarme falso comum. Se uma solicitação de permissão tiver um proprietário nomeado e um prazo não expirado, é esperada a ausência de um resultado posterior da ferramenta. Findo o prazo, ou quando não existe titular, a mesma evidência torna se um problema de cobertura ou de andamento. O tempo e a propriedade mudam o diagnóstico; a contagem de eventos por si só não pode. O ramo false complete evita o erro oposto. A referência oficial de Claude Code define Stop como o final de uma resposta. O repositório pode exibir fielmente esse fato do ciclo de vida. Nenhum dos sistemas afirma que o destino mudou. Uma tarefa de arquivo precisa do caminho esperado e da verificação de conteúdo; uma tarefa de código precisa de testes relevantes; uma ação remota precisa de um recibo de destino. Mantenha essas verificações fora do transporte do gancho para que o sistema de monitoramento não possa se certificar. Há também uma compensação de privacidade. O repositório oferece suporte à captura opcional de bate papo e exibe dados relacionados ao prompt. A saúde da entrega também não exige. Um canário pode usar apenas identificadores opacos, como source app , session id , hook event type , carimbo de data/hora e ID de evento retornado. Minimize o envelope antes de expandir a observabilidade. Opere um pequeno canário e verifique o resultado real Faça a auditoria em cinco etapas limitadas. 1. Fixar versões e escopo. Registre o commit do repositório, a versão Claude Code, o identificador do aplicativo de origem e os eventos exatos do ciclo de vida necessários para sua decisão. Revise a referência oficial dos ganchos quando uma das versões for alterada. 2. Envie um canário exclusivo. Use um identificador de sessão descartável e uma carga útil PreToolUse inofensiva. Exija HTTP 200 e analise o ID do evento salvo retornado. Não use apenas o código de saída do gancho. 3. Prove armazenamento e apresentação. Consulte /events/recent imediatamente e encontre o ID exato. Reconecte o cliente Vue ou um teste WebSocket a /stream e exija o mesmo evento no replay inicial ou mensagem ao vivo. Mantenha o cheque dentro da janela de replay; o servidor fixado envia 300 linhas recentes quando um WebSocket é aberto. 4. Verifique a cobertura e a atualização. Execute uma sequência de ciclo de vida conhecida, compare os tipos de eventos observados com o manifesto fixado e aplique prazos por evento. A permissão de propriedade da rota aguarda como espera. Expire evidências antigas em vez de manter o verde obsoleto. 5. Verifique o resultado do usuário separadamente. Afirme o arquivo esperado, o resultado do teste, o estado da tarefa ou o efeito externo. Um monitor deve relatar false complete quando o ciclo de vida termina sem esse recibo. Este processo tem limites. Ele testa a entrega configurada por meio do repositório fixado; ele não estabelece correção semântica para cada carga útil. Adicionar todos os ganchos disponíveis pode aumentar a latência, o armazenamento e a exposição de dados confidenciais. Um manifesto mínimo com versão geralmente é mais seguro do que a coleta indiscriminada. O cenário de nove casos demonstra a regra de decisão, não a prevalência de falhas na produção. Sidewisp se enquadra nesse limite como uma camada de saúde, não como outro tempo de execução Claude Code ou um substituto para o repositório. A Sidewisp está atualmente em prévia privada. O site público e a demonstração interativa são ao vivo, mas um adaptador de monitoramento de produção Claude Code, um coletor de integridade ao vivo e um executor de recuperação automatizado não são enviados. A recuperação continua a ser uma capacidade planeada e sujeita a aprovação; a próxima etapa honesta é ingressar na lista de espera de visualização privada se esse modelo de recibo corresponder à forma como você opera os agentes. Para este repositório, mantenha a regra compacta: um evento do painel é uma evidência da atividade observada. Declare a execução íntegra somente quando o manifesto do evento necessário for atual, o canário tiver recibos de transporte, persistência e apresentação, qualquer espera tiver um proprietário e um prazo e o resultado pretendido passar em sua própria verificação determinística.