Gobernanza · El registro de grietas (fallas de instrumento)
Una grieta es una falla del instrumento de medición, no del producto. Es la peor clase de bug porque contamina hacia atrás: todo lo que mediste con el instrumento roto queda bajo sospecha, incluidas decisiones ya tomadas.
El formato de una entrada
- Instrumento: qué medidor falló, exactamente.
- Detectada: cuándo y por quién.
- Alcance retroactivo: desde cuándo miente — qué lecturas/decisiones contamina.
- Fix: qué se cambió.
- Probe que lo ve rechazar Y aceptar: cómo se demuestra que el fix discrimina (Test de rechazo).
Grieta ≠ incidente: un incidente es algo que salió mal una vez; una grieta redefine qué sabías. Por eso van en un registro propio, publicado — el registro de fallas es un activo, no ropa sucia.
Dos grietas reales, completas
G5 — el pixel contaba al propio equipo. view.js sumaba una vista por cada carga, sin sesión y sin cookie (por diseño: honesto, sin fingerprint) y por lo tanto sin forma de distinguir a la propia célula verificando en vivo contra producción. Alcance retroactivo: los números que 8 sesiones usaron para concluir "el tráfico es el cuello de botella" no tienen garantía de ser humanos, y —el detalle que más duele— no son corregibles hacia atrás: el almacén agrega por día y no guarda un registro por hit con user-agent, así que la contaminación no se puede cuantificar ni restar. Fix: filtro de tráfico propio con fecha de corte, que el reporte publica como filtroInternoDesde en vez de fingir continuidad — se escribe una sola vez, en la primera vista externa posterior al filtro [testeado: view.js:57 y report.js:109-112]. Sigue parcialmente cerrada: el filtro existe, la serie vieja no se recupera.
G6 — el cero estructural. clicks a etsy: 0 publicado en el mismo formato que los ceros reales… cuando 0 de 59 páginas de la landing tenían link a Etsy. Imposible ≠ no ocurrió. Fix en dos capas: el link real se agregó, Y el probe ahora chequea automáticamente "¿existe una página capaz de disparar este contador?".
Lo que hace a esta entrada un buen ejemplo no es el fix sino la evidencia: el probe ya discriminó en las dos direcciones dentro del mismo día. Vio rojo con 0 de 59 páginas enlazando a Etsy, y se apagó solo al llegar a 26 de 59, medido sobre producción a las 21:09 UTC, no leído de un reporte [testeado: tablero_probe.py / build_data.py]. Un detector que sólo se lo vio aceptar no prueba nada (Test de rechazo); a éste se lo vio hacer las dos cosas antes de que se le creyera el número. Cerrada el mismo día que se instrumentó.
Cómo se encuentra una grieta (patrón medido)
Casi ninguna se encontró buscándola: salieron de diffear el mismo hecho contra una segunda fuente. El caso más limpio del proyecto: el registro operativo decía PAUSA TOTAL mientras el planificador del sistema nunca había sido descargado y seguía publicando — cinco corridas con hora exacta en su propio log ese mismo día [testeado: launchctl + queue.log, medido 2026-08-30]. Ninguna de las dos fuentes era mentirosa; la grieta vivía en creerle a una sola.
La pausa es un estado medible, no una declaración. Apagar algo produce una línea en un registro; que esté apagado produce una lectura del sistema. Si tu checklist dice "pausado" y nadie corrió el comando que lo confirma, no medisite nada: escribiste una intención. Vale para crones, colas, campañas y para cualquier cosa que "quedó en pausa" — el estado de reposo necesita probe igual que el estado activo, y es el que nadie instrumenta porque no produce errores.
Cuando el terreno obvio está saturado, auditar el instrumento que todos citan paga más que otra pasada sobre el contenido.