Health Checks

El sistema de verificación de health. Los liveness probes, los correctness checks, los performance checks y las alertas.

Propósito

Esta página documenta los health checks del lab: los liveness probes, los correctness checks, los performance checks y la alerting policy.

Los health checks son parte de la cadencia operacional (Operations) y del runbook (Runbook).

Categorías

Los health checks del lab se dividen en tres categorías:

Categoría	Pregunta que responde
Liveness	¿El componente está up?
Correctness	¿El componente se está comportando correctamente?
Performance	¿El componente está cumpliendo sus targets de performance?

Un fallo en cualquier categoría es un hallazgo. La severidad depende de la categoría y del componente.

Correctness checks

Los correctness checks verifican que el componente se está comportando correctamente, no solo que está up.

Correctness del Coordinator

Check	Esperado
El memory layer es legible	Leer `MEMORY.md` devuelve el contenido esperado.
El skill loader activa un skill conocido	Activar `browser-automation` devuelve el skill.
El session store acepta una sesión nueva	Se crea y lista una sesión nueva.
El routing al Research Worker funciona	Una research request se dispatcha y devuelve un resultado.

Correctness del Research Worker

Check	Esperado
La inicialización de misión funciona	Se crea una misión nueva en la raíz de research.
La fase F0 corre y produce `task.json`	El artefacto se escribe y valida.
La fase F1 corre y produce `candidates.json`	El artefacto se escribe y valida.
El orquestador puede reanudar una misión pausada	Se carga el estado y corre la siguiente fase.

Correctness del Media Agent

Check	Esperado
El device discovery funciona (cuando hay devices)	Se devuelve una device list no vacía.
Una playback request se acepta	El agent devuelve un resultado sin error.
El media backend selector escoge el backend correcto	El backend seleccionado matchea las reglas.

Correctness del Web Agent

Check	Esperado
Se puede abrir una URL	La página carga y se devuelve un snapshot.
Se puede rellenar un formulario fillable	Los campos del form se rellenan y el form se puede submitir.
Un snapshot devuelve elementos accionables	El snapshot tiene al menos un elemento clickable.

Correctness del Coding Assistant

Check	Esperado
Una task simple produce código	El sub-agent devuelve código que pasa los tests.
La review rechaza código malo	Se rechaza un código con un bug claro.
La integración coloca los ficheros en la ubicación correcta	Los ficheros están en las rutas esperadas del proyecto.

Performance checks

Los performance checks verifican que el componente cumple sus targets de performance.

Performance del Coordinator

Check	Target
`duration_ms.p50`	< 5,000 ms
`duration_ms.p95`	< 15,000 ms
`duration_ms.p99`	< 30,000 ms
Tokens por request (avg)	< 5,000
Uso de memoria	< 2 GB
Uso de CPU (por request)	< 50% de un core (avg)

Performance del Research Worker

Check	Target
Duración de misión (típica)	< 5 minutos
`F1_candidates.duration_ms.p50`	< 30,000 ms
`F2_reviews.duration_ms.p50`	< 30,000 ms
`F4_price.duration_ms.p50`	< 30,000 ms
`F6_report.duration_ms.p50`	< 5,000 ms
Uso de memoria	< 1 GB

Performance del Media Agent

Check	Target
Inicio de reproducción	< 5,000 ms
Selección de backend	< 100 ms
Device discovery (cached)	< 50 ms
Device discovery (cold)	< 5,000 ms

Performance del Web Agent

Check	Target
`act.duration_ms.p50`	< 1,000 ms
`snapshot.duration_ms.p50`	< 2,000 ms

Los health checks se pueden correr individualmente (como en los probes de arriba) o como un script. El lab tiene un script en {workspace-root}/ops/cheatsheets/health-check.sh que corre todos los checks en orden y produce un report.

El output del script es un documento JSON con una entrada por check:

{
  "timestamp": "2026-06-10T20:00:00Z",
  "checks": [
    {"name": "coordinator.liveness", "status": "ok", "duration_ms": 12},
    {"name": "scout.liveness", "status": "ok", "duration_ms": 8},
    {"name": "browser.liveness", "status": "ok", "duration_ms": 5},
    {"name": "media-lab.liveness", "status": "ok", "duration_ms": 23},
    {"name": "research.correctness.f1", "status": "ok", "duration_ms": 4123}
  ]
}

El report se escribe a {workspace-root}/logs/health-check-<timestamp>.json.

Alerting

El lab no tiene un sistema de alerting. El operator es el sistema de alerting.

El operator comprueba los health checks:

Diario. Durante los daily checks.
On heartbeat. Si el heartbeat probe detecta un issue.
On user request. Cuando el usuario pregunta "¿está todo OK?".

Cuando un check falla, el operator sigue el procedimiento de runbook relevante. El runbook está en Runbook.

Failure modes

Failure	Severidad	Acción
Coordinator gateway está caído	Critical	Aplicar Worker recovery.
Scout gateway está caído	High	Aplicar Worker recovery.
Browser CDP está detached	High	Aplicar Browser CDP target detached.
Media Lab Server está caído	Medium	Aplicar Media Lab Server not responding.
Model quota exhausted	High	Aplicar Model quota exhausted.
Token pool exhausted	High	Aplicar Token pool: all tokens exhausted.
Misión stuck en estado no-terminal	High	Reanudar o cancelar la misión.
Memory layer no es escribible	Critical	Investigar los permisos del filesystem.
Audit log creciendo demasiado rápido	Low	Aplicar la retention policy.

El failure catalog completo está en Catálogo de fallos.

Propósito

Categorías

Liveness probes

Coordinator gateway

Scout gateway

Browser CDP

Media Lab Server

Coding sub-agent