Monitorização do código Claude: espera de permissão de captura e resultados perdidos

O controlo do código Claude precisa de três camadas, não de um painel. Utilize o feed oficial de OpenTelemetry do Claude Code para consumo e atividade, ganchos do ciclo de vida para espera e falhas de terminal, e uma verificação de propriedade do projeto para o resultado realmente solicitado. Se omitir a terceira camada, uma sessão pode ter vestígios limpos, chamadas de ferramentas bem sucedidas e uma resposta final polida enquanto o patch esperado, resultado do teste ou arquivo ainda falta. O padrão razoável é deliberadamente pequeno: exportar métricas e eventos editados, registrar seis eventos do ciclo de vida sem suas cargas úteis de texto livre, em seguida, avaliar o último evento em relação a um predicado de conclusão específica da tarefa. Não coletar informações ou conteúdo bruto de ferramentas apenas para decidir se uma corrida precisa de atenção. Este guia constrói esse projeto a partir dos atuais esquemas do Código Claude e testa a ordem de decisão em sete sessões. Não assume que uma chamada de ferramenta seja progresso, que uma pausa seja falha ou que o Stop signifique que o trabalho está concluído. Comece com três perguntas diferentes. A monitorização torna se mais clara quando cada sinal responde a uma pergunta e é proibido responder às outras duas. Capa Pergunta que ele pode responder Sinais O que não pode provar Telemetria O que é que o Claude Code consumiu ou executou? sessões, solicitações de API, tokens, custo estimado, resultados das ferramentas, decisões sobre as ferramentas, duração se o resultado solicitado é correto Ciclo de vida Porque é que esta sessão é silenciosa ou termina? Solicitação de permissão, notificação, tarefa de fundo, despertamento programado, parada, curva terminada pela API, fim da sessão se um arquivo, teste ou resultado externo é válido Resultados Será que essa tarefa produziu o resultado prometido? hash de arquivo, estado de saída de teste, validação de esquema, resposta da API, artefato assinado Por que a sessão esperou ou quanto custou O Documentação oficial de controlo do Código Claude expõe métricas através do protocolo de métricas OTel, eventos através de registros/eventos e traços opcionais distribuídos. As métricas documentadas incluem contagem de sessões, linhas alteradas, compromissos, solicitações de retirada, tempo ativo, tokens e custo estimado. Os eventos adicionam correlação rápida, resultados da API, resultados da ferramenta e decisões de permissão. Isso é uma excelente evidência para a primeira camada. Não é um contrato de conclusão. A distinção importa no trabalho comum. Um evento de ferramenta Write bem sucedido diz que uma escrita foi concluída. Não diz que o arquivo pretendido foi escrito no local certo, que o programa resultante compila, ou que o usuário pediu esse arquivo. As curvas de tokens e custos podem revelar o consumo fugitivo, mas uma sessão de baixo custo ainda pode parar um passo antes do entregue. Adicionar evidências do ciclo de vida com ganchos Claude Code O Claude Codes Anéis de referência fornece uma segunda camada que um painel de controle de uso exclusivo perde. Quatro eventos são particularmente úteis: PermissionRequest dispara quando um diálogo de permissão está prestes a ser mostrado. Se for o mais recente acontecimento não resolvido, a sessão está à espera de uma pessoa; não está paralisada. O Stop dispara quando o agente principal terminar de responder. A entrada atual pode incluir background tasks e session crons , de modo que uma curva parada pode ainda estar esperando uma tarefa de shell, subagente, tarefa de monitor, fluxo de trabalho, tarefa MCP ou despertar programado. StopFailure dispara em vez de Stop quando um erro da API termina a curva. Suas classes de erros documentadas incluem limite de taxa, sobrecarga, autenticação, faturamento, solicitação inválida, modelo faltante, erro do servidor e tokens de saída máximos. O SessionEnd registra o motivo do encerramento da sessão. É útil para a limpeza e auditoria, mas não pode bloquear a terminação. PostToolUse , PostToolUseFailure , Notification e PreCompact adicionam contexto útil. Mantenha sua semântica estreita: o recente PostToolUse é evidência de atividade; repetido PostToolUseFailure é evidência de problemas com as ferramentas; PreCompact marca uma transição contextual que vale a pena correlacionar com o comportamento posterior. Nenhuma é um veredicto universal de saúde. Para um coletor de privacidade mínimo, retém apenas um timestamp, um identificador de sessão hashado localmente, nome do evento, nome da ferramenta, classe de erro, tipo de notificação e contagens de tarefas de fundo ou despertares programados. Ometer transcript path , cwd , last assistant message , comandos Bash, entrada de ferramenta e texto de notificação, a menos que um caso de uso diagnosticado os justifique. Os padrões oficiais do OTel suportam a mesma restrição. O texto rápido, o texto de resposta assistente, os argumentos das ferramentas, o conteúdo de entrada/saída das ferramentas e os corpos de API crus são desativados por padrão. Ativando o OTEL LOG RAW API BODIES pode expor todo o histórico de conversação; nunca deve ser um interruptor de solução de problemas casual. Transformar as últimas evidências em um estado A ordem de decisão abaixo é pequena o suficiente para inspecionar. Ele classifica o último evento para cada sessão, enquanto um verificador externo fornece outcome verified quando uma volta para. A ordem é intencional. Uma falha da API terminal ultrapassa um evento de atividade recente. Uma aprovação não resolvida está à espera, não um prazo. O trabalho de fundo impede que um evento Stop seja tratado como concluído. Só após a exclusão desses casos é que o verificador decide entre o complete e o outcome missing . O dispositivo de ensaio mantido utiliza sete sessões e um limiar de exemplo de 15 minutos: A execução do aparelho num tempo fixo reproduz todas as sete linhas: Esta é uma regra de decisão, não um demônio de produção. O limiar de 15 minutos é errado para um trabalho de dois minutos e errado para uma construção de duas horas. Estabelecer a frescura da cadência e da duração esperadas do trabalho, em seguida, manter um caminho uncertain para evidências faltantes ou contraditórias. Defina a conclusão fora da conversa A única entrada específica do classificador é a outcome verified . Esse bit deve vir de uma verificação determinista sempre que possível, não da pesquisa da mensagem de assistente final para done. Para uma tarefa de mudança de código, a conclusão útil pode exigir todas as seguintes: 1. Os arquivos esperados diferem do compromisso inicial; 2. O comando de ensaio focado sai com êxito; 3. Os decodificadores de artefatos gerados ou o pacote podem ser importados; 4. O resultado permanece dentro do repositório e do âmbito de aplicação aprovados. Para uma tarefa de documentação, exija o arquivo de destino, a validação de frontmatter ou esquema, todos os caminhos locais citados e qualquer verificador de links que o repositório já confia. Para uma exportação de dados, verifique o arquivo esperado, analise o, valide as colunas necessárias e compare as contagens de filas com o limite de origem. Para uma alteração da API, executar o teste de contrato em vez de aceitar uma solicitação HTTP que simplesmente retornou. O monitor deve armazenar o nome do verificador, o estado de saída, o tempo de observação e um resumo do resultado, não uma explicação fabricada. Quando não existir predicado determinista, registar outcome unknown . Um resultado desconhecido pode exigir revisão; não deve ficar saudável silenciosamente. Alerta sobre a próxima ação segura Sete estados não precisam de sete alarmes. Rotear cada estado para a menor ação útil: Estado Ação por defeito working Não faça nada. waiting human notificar a pessoa responsável com a categoria de permissão, sem aprová la waiting background mostrar a dependência e a sua frescura; não reiniciar a sessão failed: Expor a classe de erro e a política de retomada limitada outcome missing Mostrar o prefácio de conclusão falhado e preservar o trabalho para inspeção stalled Verificar novamente a disponibilidade e a duração prevista antes de propor um empurrão limitado complete reter provas e fechar a questão Este roteamento evita dois erros caros. Em primeiro lugar, evita tentar novamente um agente que está esperando corretamente a autoridade. Em segundo lugar, evita celebrar uma paragem de conversa quando a evidência do projeto diz que o resultado está ausente. A recuperação automática requer limites mais rígidos do que o monitoramento. Uma falha de limite de taxa pode ser retribuída após um backup; uma falha de autenticação geralmente requer uma pessoa; uma solicitação de permissão não deve ser aprovada automaticamente apenas porque é antiga. Após qualquer intervenção, reencaminhe o predicado de conclusão. Um comando bem sucedido é prova de atividade, não prova de que a tarefa original se recuperou. Aplicar o desenho sem coletar demais Uma implantação prática pode permanecer incremental: 1. Habilitar a telemetria do código Claude com métricas e eventos, deixando todos os interruptores de registro de conteúdo desligados. 2. Confirme que o claude code.session.count ou o claude code.user prompt chegam ao coletor antes da construção de alertas. 3. Adicionar ganchos locais para PermissionRequest , Stop , StopFailure , Notification , PreCompact e SessionEnd . 4. Normalize essas cargas úteis de gancho no envelope mínimo; identificadores de hash localmente e caminhos de lançamento e texto livre. 5. Defina um predicado de conclusão determinista para uma tarefa consequente. 6. Reproduzir eventos sintéticos para cada estado antes de notificar alguém. 7. Adicionar um alerta somente quando o seu proprietário e a próxima ação segura são explícitos. A versão do normalizer. O Código Claude documenta versões mínimas para vários campos, e as transcrições internas não são explicitamente um contrato estável. Prefira os campos de gancho e OTel que a documentação atual expõe; não construa um monitor de longa duração raspando pixels terminais ou assumindo que uma forma de transcrição privada nunca mudará. O limite útil para o Sidewisp Claude Code já fornece fortes sinais brutos. A lacuna operacional está a transformar esses sinais numa decisão de saúde restringida: trabalhar, esperar, falhar, ficar obsoleto ou perder o seu resultado prometidoem seguida, mostrar as evidências e a próxima ação mais segura. A Sidewisp está atualmente em prévia privada. Seu site público e sistema de artigos estão ao vivo, mas os adaptadores de monitoramento Claude Code de produção, coleta de agentes e recuperação geralmente não são enviados. O papel pretendido é uma camada de saúde ao lado dos tempos de execução existentes, e não um tempo de execução de substituição, um gateway de modelo obrigatório ou um fixador autônomo. Se esse limite coincidir com a forma como você opera agentes de codificação, a lista de espera de pré visualização privada é o próximo passo apropriado. Até então, o padrão de três camadas deste guia é utilizável por si só: telemetria para a actividade, ganchos para o ciclo de vida e verificações deterministas para os resultados.