Disler Claude Code Observabilidad de múltiples agentes de Hooks: demostrar la entrega de eventos

La respuesta segura es: no trate un panel accesible o un código de salida de gancho cero como prueba de que el canal de observabilidad de múltiples agentes de ganchos Disler Claude Code está en buen estado. Exija un recibo en cada límite (configuración, entrega HTTP, persistencia SQLite, entrega WebSocket y actualización del navegador) y luego verifique el trabajo fuera de la ruta de monitoreo. Esa distinción es importante porque la arquitectura propia del repositorio es una cadena: agentes Claude → scripts de enlace → HTTP POST → Bun servidor → SQLite → WebSocket → Vue cliente. Un evento brillante en el último cuadro demuestra que un evento cruzó la cadena. Un cuadro silencioso no le indica dónde se detuvo la evidencia y un evento Stop no prueba que el archivo, la prueba, la implementación o la transferencia solicitados existan. Audité el compromiso del repositorio 8a6e5cf y reproduje nueve casos sin contenido. Una regla ingenua que verifica solo el código de salida del proceso de enlace marcado los nueve en verde. La regla de recepción clasificó a los nueve como se esperaba; sólo uno estaba sano. Fijar el repositorio y definir el contrato de evidencia Comience con el código que realmente ejecuta. En el compromiso fijado, .claude/settings.json configura doce grupos de eventos: SessionStart , SessionEnd , UserPromptSubmit , PreToolUse , PostToolUse , PostToolUseFailure , PermissionRequest , Notification , SubagentStart , SubagentStop , Stop y PreCompact . El Claude Code referencia de ganchos actual documenta treinta eventos del ciclo de vida. Ese conjunto más grande incluye señales de falla y de equipo más nuevas, como TaskCreated , TaskCompleted , TeammateIdle , StopFailure y PostToolBatch . La comparación no significa que cada instalación deba capturar los treinta. Significa que "todos los ganchos" es un reclamo versionado: defina los eventos mínimos que requiere su decisión operativa, fije la versión Claude Code y falle la verificación de cobertura cuando la configuración ya no coincida con ese manifiesto. Para un canario de agente único, un mínimo razonable es SessionStart , un par PreToolUse y PostToolUse y Stop . Para una ejecución en equipo, agregue el ciclo de vida del subagente y las señales de tarea o compañero de equipo que expone su versión Claude Code instalada. Un evento faltante es significativo sólo después de establecer que era esperado y configurado. El siguiente límite es el remitente. El send event.py fijado utiliza un tiempo de espera HTTP de cinco segundos. Devuelve False y escribe en stderr cuando falla la solicitud, pero main() no usa ese resultado: sale con el código cero incondicionalmente, por lo que el monitoreo no puede bloquear Claude Code. Ésta es una opción de disponibilidad defendible, pero hace que el código de salida cero sea una señal de actividad en lugar de un recibo de entrega. El servidor proporciona un recibo más sólido. Su ruta POST /events valida los campos obligatorios, inserta el evento, luego devuelve el registro guardado y lo transmite a los clientes WebSocket conectados. Conserve el ID de base de datos devuelto para un canario. Una conexión HTTP sin una identificación guardada no es prueba equivalente. La receta just health del repositorio necesita la misma interpretación. Solicita /health , pero el servidor anclado no tiene una rama de salud dedicada; Los caminos incomparables reciben la respuesta genérica Multi Agent Observability Server con HTTP 200. Eso prueba que el proceso respondió HTTP. No ejerce inserción de eventos, legibilidad SQLite, entrega WebSocket ni una vista actual del navegador. Utilice un contrato explícito: Recibo Evidencia a retener Lo que no prueba Configuración manifiesto de evento anclado y valor de la aplicación fuente que un anzuelo disparó Transporte HTTP 200 más el ID del evento guardado que el navegador lo recibió Persistencia la misma identificación visible en eventos recientes que la vista es actual Presentación WebSocket o volver a conectar la repetición contiene el ID que llegaron todos los eventos requeridos Cobertura Cada evento requerido aparece antes de su fecha límite. ese trabajo tuvo éxito Resultado verificación determinista del entregable previsto que las carreras futuras se mantengan saludables Vuelva a reproducir la auditoría de entrega antes de confiar en la vista Codifiqué esos límites en un dispositivo sin indicaciones, transcripciones, entradas de herramientas, rutas de archivos ni secretos. Ejecútelo con: La repetición produjo: El clasificador usa prioridad. Primero comprueba si un gancho de salida cero realmente llegó al servidor. Luego requiere un recibo de persistencia, verifica si la entrega del navegador está actualizada, valida el manifiesto configurado, expira la evidencia obsoleta, preserva una espera legítima antes de la fecha límite y solo entonces pregunta si existe el resultado deseado. Artículos fijos Clasificación Decisión del operador El remitente sale de cero después de un error POST delivery failed hidden inspeccionar el stderr del remitente y la accesibilidad del servidor HTTP aceptado pero sin identificación guardada persistence unverified no inferir el almacenamiento del transporte SQLite tiene el evento pero WebSocket no dashboard stale Vuelva a conectarse y verifique la reproducción antes de diagnosticar el agente. Los eventos de equipo son obligatorios pero no configurados manifest drift actualizar o limitar el manifiesto anclado El evento configurado nunca llega coverage gap inspeccionar el comparador, el proceso de enlace y la compatibilidad de versiones La dependencia del permiso está antes de su fecha límite waiting encaminar la decisión a su titular; no lo llames estancado Stop llega sin recibo de entrega false complete verificar el resultado externo antes de borrar la ejecución Sólo quedan viejos acontecimientos stale caducar en verde y reportar evidencia como no disponible Cada límite y resultado pasa healthy acepte esta ejecución, no toda la instalación para siempre La sucursal waiting previene una falsa alarma común. Si una solicitud de permiso tiene un propietario designado y una fecha límite vigente, se espera la ausencia de un resultado de herramienta posterior. Vencido el plazo, o cuando no existe propietario, la misma evidencia se convierte en un problema de cobertura o avance. El tiempo y la propiedad cambian el diagnóstico; el recuento de eventos por sí solo no puede hacerlo. La rama false complete evita el error contrario. La referencia oficial de Claude Code define Stop como el final de una respuesta. El repositorio puede mostrar fielmente ese hecho del ciclo de vida. Ninguno de los sistemas afirma que el destino cambió. Una tarea de archivo necesita la ruta esperada y la verificación de contenido; una tarea de código necesita pruebas relevantes; una acción remota necesita un recibo de destino. Mantenga esos controles fuera del transporte del gancho para que el sistema de seguimiento no pueda certificarse. También existe una compensación por la privacidad. El repositorio admite la captura de chat opcional y muestra datos relacionados con las solicitudes. La salud de la entrega tampoco lo requiere. Un canario solo puede usar identificadores opacos como source app , session id , hook event type , marca de tiempo e ID de evento devuelto. Minimiza la envolvente antes de ampliar la observabilidad. Opere un pequeño canario y luego verifique el resultado real. Adopte la auditoría en cinco pasos acotados. 1. Fijar versiones y alcance. Registre la confirmación del repositorio, la versión Claude Code, el identificador de la aplicación fuente y los eventos exactos del ciclo de vida necesarios para su decisión. Revise la referencia oficial de ganchos cuando cambie cualquiera de las versiones. 2. Envíe un canario único. Utilice un identificador de sesión desechable y una carga útil PreToolUse inofensiva. Solicite HTTP 200 y analice el ID del evento guardado devuelto. No utilice el código de salida del gancho solo. 3. Acreditar almacenamiento y presentación. Consulta /events/recent inmediatamente y encuentra esa identificación exacta. Vuelva a conectar el cliente Vue o una prueba WebSocket a /stream y solicite el mismo evento en la repetición inicial o el mensaje en vivo. Mantenga la marca dentro de la ventana de reproducción; el servidor anclado envía 300 filas recientes cuando se abre un WebSocket. 4. Verifique la cobertura y la actualidad. Ejecute una secuencia de ciclo de vida conocida, compare los tipos de eventos observados con el manifiesto fijado y aplique fechas límite por evento. El permiso de propiedad de la ruta espera como en espera. Caducar la evidencia antigua en lugar de mantenerla verde y obsoleta. 5. Verifique el resultado del usuario por separado. Confirme el archivo esperado, el resultado de la prueba, el estado de la tarea o el efecto externo. Un monitor debe informar false complete cuando se cierra el ciclo de vida sin ese recibo. Este proceso tiene límites. Prueba la entrega configurada a través del repositorio fijado; no establece la corrección semántica para cada carga útil. Agregar todos los enlaces disponibles puede aumentar la latencia, el almacenamiento y la exposición de datos confidenciales. Un manifiesto versionado mínimo suele ser más seguro que la recopilación indiscriminada. La coincidencia de nueve casos demuestra la regla de decisión, no la prevalencia de fallas en la producción. Sidewisp se ajusta a este límite como una capa de salud, no como otro tiempo de ejecución Claude Code o un reemplazo del repositorio. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y la demostración interactiva están en vivo, pero no se envían un adaptador de monitoreo de producción Claude Code, un recolector de salud en vivo y un ejecutor de recuperación automatizado. La recuperación sigue siendo una capacidad planificada y sujeta a aprobación; El siguiente paso actual y honesto es unirse a la lista de espera de vista previa privada si este modelo de recibo coincide con su forma de operar con los agentes. Para este repositorio, mantenga la regla compacta: un evento del panel es evidencia de la actividad observada. Declare la ejecución en buen estado solo cuando el manifiesto de evento requerido esté actualizado, el canario tenga recibos de transporte, persistencia y presentación, cualquier espera tenga un propietario y una fecha límite, y el resultado previsto pase su propia verificación determinista.