Monitoreo de código Claude: espera de permiso de captura y resultados perdidos

El monitoreo de código Claude necesita tres capas, no un panel. Utilice el feed oficial de OpenTelemetry de Claude Code para el consumo y la actividad, los ganchos del ciclo de vida para las esperanzas y los fallos de los terminales, y una verificación del proyecto para el resultado que realmente solicitó. Si omite la tercera capa, una sesión puede tener rastros limpios, llamadas de herramientas exitosas y una respuesta final pulida mientras que el parche esperado, el resultado de prueba o el archivo todavía falta. El defecto razonable es deliberadamente pequeño: exportar métricas y eventos editados, registrar seis eventos del ciclo de vida sin sus cargas útiles de texto libre, luego evaluar el último evento en función de un predicado de finalización específico de la tarea. No recopile las instrucciones o el contenido de las herramientas en bruto simplemente para decidir si una carrera necesita atención. Esta guía construye ese diseño a partir de los esquemas actuales del Código Claude y prueba el orden de decisión en siete sesiones. No asume que una llamada de herramienta sea un progreso, que una pausa sea un fracaso o que Stop signifique que el trabajo está terminado. Comience con tres preguntas diferentes El seguimiento se hace más claro cuando cada señal responde a una pregunta y se le prohíbe responder a las otras dos. Capa Pregunta que puede responder Las señales Lo que no puede probar Telemetría ¿Qué consumió o ejecutó Claude Code? sesiones, solicitudes de API, tokens, costo estimado, resultados de las herramientas, decisiones de las herramientas, duración si el resultado solicitado es correcto Ciclo de vida ¿Por qué esta sesión es silenciosa o termina? Solicitud de permiso, notificación, tarea de fondo, despertamiento programado, parada, turno terminado de la API, final de la sesión si un archivo, prueba o resultado externo es válido El resultado ¿Hizo esta tarea el resultado prometido? hash de archivo, estado de salida de prueba, validación de esquema, respuesta de API, artefacto firmado por qué la sesión esperó o cuánto costó El Documentación oficial de seguimiento del Código Claudio expone métricas a través del protocolo de métricas OTel, eventos a través de registros/eventos y rastros distribuidos opcionales. Las métricas documentadas incluyen el recuento de sesiones, las líneas cambiadas, los compromisos, las solicitudes de extracción, el tiempo activo, los tokens y el costo estimado. Los eventos agregan correlación rápida, resultados de API, resultados de herramientas y decisiones de permisos. Esa es una excelente evidencia para la primera capa. No es un contrato de finalización. La distinción importa en el trabajo ordinario. Un evento de herramienta Write exitoso dice que se ha completado una escritura. No dice que el archivo previsto haya sido escrito en el lugar correcto, que el programa resultante compile, o que el usuario haya solicitado ese archivo. Las curvas de tokens y costos pueden revelar el consumo fuera de control, pero una sesión de bajo costo aún puede detenerse un paso antes del entregable. Añadir pruebas de ciclo de vida con ganchos de código de Claude Claude Codes referencias de ganchos proporciona una segunda capa que se pierde en un panel de control solo para uso. Cuatro eventos son particularmente útiles: PermissionRequest se dispara cuando se está a punto de mostrar un diálogo de permisos. Si se trata del último acontecimiento no resuelto, la sesión está esperando a una persona; no se detiene. Stop dispara cuando el agente principal termina de responder. Las entradas actuales pueden incluir background tasks y session crons , por lo que un giro detenido puede estar esperando una tarea de shell, subagent, tarea de monitoreo, flujo de trabajo, tarea de MCP o despertamiento programado. StopFailure dispara en lugar de Stop cuando un error de API termina el giro. Sus clases de errores documentadas incluyen límite de tasa, sobrecarga, autenticación, facturación, solicitud inválida, modelo faltante, error del servidor y tokens de salida máximos. SessionEnd registra por qué la sesión terminó. Es útil para la limpieza y la auditoría, pero no puede bloquear la terminación. PostToolUse , PostToolUseFailure , Notification y PreCompact añaden contexto útil. Mantenga su semántica estrecha: reciente PostToolUse es evidencia de actividad; repetido PostToolUseFailure es evidencia de problemas de herramienta; PreCompact marca una transición de contexto que vale la pena correlacionar con el comportamiento posterior. Ninguno es un veredicto de salud universal. Para un colector de privacidad mínima, mantenga solo una marca de tiempo, un identificador de sesión hashado localmente, el nombre del evento, el nombre de la herramienta, la clase de error, el tipo de notificación y el recuento de tareas de fondo o despertamientos programados. Omite transcript path , cwd , last assistant message , comandos Bash, entrada de herramienta y texto de notificación a menos que un caso de uso diagnosticado los justifique. Los valores oficiales de OTel soportan la misma restricción. El texto inmediato, el texto de respuesta del asistente, los argumentos de la herramienta, el contenido de entrada/salida de la herramienta y los cuerpos de la API en bruto están desactivados por defecto. Habilitar OTEL LOG RAW API BODIES puede exponer todo el historial de conversaciones; nunca debe ser un interruptor de resolución de problemas casual. Convertir las últimas pruebas en un estado La orden de decisión de abajo es lo suficientemente pequeña como para inspeccionar. Clasifica el último evento para cada sesión, mientras que un verificador externo suministra outcome verified cuando se detiene un giro. La orden es intencional. Una falla de API terminal supera un evento de actividad reciente. Una aprobación no resuelta está esperando, no un tiempo de espera. El trabajo de fondo impide que un evento Stop sea tratado como completado. Sólo después de que se excluyan dichos casos, el verificador decidirá entre complete y outcome missing . El dispositivo de ensayo retenido utiliza siete sesiones y un umbral de ejemplo de 15 minutos: El funcionamiento de la fijación en un sello de tiempo fijo reproduce las siete líneas: Esta es una regla de decisión, no un demonio de producción. El umbral de 15 minutos es incorrecto para un trabajo de dos minutos y incorrecto para una construcción de dos horas. Establezca la actualidad de la cadencia y la duración esperadas del trabajo, y mantenga una ruta uncertain para detectar pruebas faltantes o contradictorias. Definir la finalización fuera de la conversación La única entrada específica de la aplicación del clasificador es outcome verified . Ese bit debe provenir de una verificación determinista siempre que sea posible, no de la búsqueda del mensaje de asistente final para done. Para una tarea de cambio de código, la finalización útil puede requerir todas las siguientes características: 1. los expedientes esperados difieren del compromiso inicial; 2. el comando de ensayo enfocado sale con éxito; 3. los códigos de artefactos generados o el paquete pueden importarse; 4. el resultado permanece dentro del repositorio y el ámbito de aplicación aprobados. Para una tarea de documentación, requiere el archivo de destino, la validación de frontmatter o esquema, todos los caminos locales citados y cualquier verificador de enlaces en el que el repositorio ya confíe. Para una exportación de datos, compruebe el archivo esperado, analiza, valida las columnas requeridas y compara el recuento de filas con el límite de origen. Para un cambio en la API, ejecuta la prueba de contrato en lugar de aceptar una solicitud HTTP que simplemente regrese. El monitor debe almacenar el nombre del verificador, el estado de salida, el tiempo de observación y un resumen del resultado, no una explicación fabricada. Cuando no existe predicado determinista, registra outcome unknown . Un resultado desconocido puede requerir una revisión; no debe volverse saludable en silencio. Alerta sobre la próxima acción segura Siete estados no necesitan siete sonidos de alarma. Envía cada estado a la acción útil más pequeña: El Estado Acción por defecto working No hagas nada waiting human notificar a la persona responsable con la categoría de permiso, sin su aprobación waiting background mostrar la dependencia y su frescura; no reiniciar la sesión failed: exponer la clase de error y la política de retoma limitada outcome missing mostrar el fracaso de la finalización predicar y preservar el trabajo para la inspección stalled revise la accesibilidad y la duración esperada antes de proponer un empuje limitado complete retener pruebas y cerrar el asunto Este enrutamiento evita dos costosos errores. En primer lugar, evita volver a probar a un agente que está correctamente esperando la autoridad. En segundo lugar, evita celebrar una parada de conversación cuando la evidencia del proyecto dice que el resultado está ausente. La recuperación automática requiere límites más estrictos que el monitoreo. Un fallo en el límite de velocidad puede ser retráctil después de una copia de seguridad; un fallo de autenticación generalmente requiere una persona; una solicitud de permiso no debe ser aprobada automáticamente simplemente porque es antigua. Después de cualquier intervención, vuelva a ejecutar el predicado de finalización. Un comando exitoso es evidencia de actividad, no prueba de que la tarea original se recuperó. Aplicar el diseño sin exceso de recogida Un despliegue práctico puede mantenerse incremental: 1. Habilitar la telemetría de código Claude con métricas y eventos, dejando todos los interruptores de registro de contenido apagados. 2. Confirme que claude code.session.count o claude code.user prompt llegue al colector antes de crear alertas. 3. Añadir ganchos locales para PermissionRequest , Stop , StopFailure , Notification , PreCompact y SessionEnd . 4. Normaliza esas cargas útiles de gancho en el sobre mínimo; identificadores de hash localmente y senderos de caída y texto libre. 5. Definir un predicado de finalización determinista para una tarea consecuente. 6. Reproduce eventos sintéticos para cada estado antes de notificar a nadie. 7. Añadir una alerta sólo cuando su propietario y la próxima acción segura son explícitos. La versión del normalizador. Claude Code documenta versiones mínimas para varios campos, y los transcriptores internos no son explícitamente un contrato estable. Prefiere los campos de gancho y OTel que la documentación actual expone; no construya un monitor de larga duración raspando los píxeles terminales o asumiendo que una forma de transcripción privada nunca cambiará. El límite útil para Sidewisp Claude Code ya proporciona fuertes señales crudas. La brecha operativa está convirtiendo esas señales en una decisión de salud restringida: trabajar, esperar, fallar, obsoletarse o perder el resultado prometido, luego mostrar las pruebas y la siguiente medida más segura. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y el sistema de artículos están en vivo, pero los adaptadores de monitoreo de producción Claude Code, la recopilación de agentes y la recuperación generalmente no se envían. El papel previsto es una capa de salud junto con los tiempos de ejecución existentes, no un tiempo de ejecución de reemplazo, un gateway de modelo obligatorio o un fijador autónomo. Si ese límite coincide con la forma en que operas los agentes de codificación, la lista de espera de vista previa privada es el siguiente paso apropiado. Hasta entonces, el patrón de tres capas de esta guía es utilizable por sí solo: telemetría para la actividad, ganchos para el ciclo de vida y controles deterministas para los resultados.