Ley · Probe over report — el que verifica EJECUTA, no lee
Un estado sin instrumento detrás es decoración. "Está publicado", "el deploy salió", "los archivos subieron" — nada de eso se acepta leyendo el reporte de quien lo hizo (ni el propio): se acepta corriendo el comando que lo mide, ahora.
Por qué el reporte no alcanza
El reporte de un componente no puede observar su propio modo de falla. Casos reales de este sistema, todos con reporte verde y realidad rota:
- Un orquestador reportaba "ACTIVE" con su proceso principal muerto hacía 3 horas.
- Un POST a Etsy devolvió 201 y el listing quedó con 1 tag de 13 — sólo el GET independiente lo vio (Etsy).
- Un libro se vendió activo con 1 de 3 archivos — "subido OK" (7 · Comercio real, no mockup).
- Un cron "pausado" en la bitácora seguía corriendo según
launchctl(Pinterest). - Un QA que citó los números del autor heredó su bug — re-verificar es re-DERIVAR con datos propios, no releer.
La forma práctica
- UN comando que imprime el estado de todos tus canales y falla ruidoso si un instrumento no responde (exit ≠ 0, no un cero silencioso). El silencio no es éxito: un canal de error puede tragarse la falla.
- La regla de escritura: antes de escribir "hecho"/"activo" en cualquier registro, corré el probe — el número que citás es el de hace minutos, no el que recordás.
- Y el probe mismo necesita su test de rechazo, o es esperanza con formato de instrumento.
Ver el instrumento del caso real en acción: Sol del Valle hoy.