El incidente: el informe perfecto que está mal

El informe del 13 de agosto dice que ese día se cerró una incidencia. El fichero de incidencias dice otra cosa:

id,opened_at,status,last_response_at,closed_at
inc_4,2026-08-11T07:00:00Z,closed,2026-08-13T10:00:00Z,2026-08-13T10:05:00Z
inc_5,2026-08-13T06:00:00Z,closed,2026-08-13T11:00:00Z,2026-08-13T11:05:00Z

Las dos se cerraron el 13, como indica closed_at. El agente contó las incidencias cerradas que se habían abierto el 13, mirando opened_at, y de esas solo hay una: inc_5.

El texto del informe es correcto, profesional y seguro de sí mismo. La cifra está mal.

Por qué el revisor dio PASS

El mismo proceso calculó la cifra, construyó el valor esperado con el que compararla y se revisó a sí mismo. Si la función que cuenta usa opened_at, el valor esperado que sale de esa misma función también usa opened_at. Todo coincide porque el error es compartido.

Vas a ver este patrón en todo el módulo: una comprobación que comparte el código, los datos o los supuestos de lo que comprueba no aporta ninguna evidencia nueva.

Reprodúcelo

En la carpeta del proyecto:

npm run starter

Deberías ver esto:

{
  claimed: { incidentsClosed: 1, rule: 'opened_at', selfReview: 'PASS' },
  actualClosed: 2,
  contradictionVisible: true,
  publishable: false
}

claimed es lo que afirma el agente: una incidencia cerrada, contada con la regla opened_at, y su revisión propia en PASS. Abre starter/run.ts: el PASS sale de comparar la cifra con lo que devuelve la misma función que la calculó, así que no puede dar otra cosa. actualClosed es el recuento correcto, hecho por closed_at.

La contradicción solo aparece porque alguien recalculó desde la fuente. Si el script no la encontrara, terminaría con error: el fallo está ahí a propósito.

En el caso completo (lo tienes en material/caso-opspulse.md) el mismo agente también aceptó una fecha que no existe en el calendario, modificó un CSV para que la tabla cuadrara y no distinguía entre el tiempo que dedica una persona y el tiempo de reloj.

Lo que debería exigir Operaciones

Pedirle al agente «más cuidado» no cambia nada que se pueda comprobar. Lo que sí cambia algo es exigir:

1. Cifras recalculables desde las fuentes autoritativas, que son los tres CSV y nunca el borrador del agente.
2. Una definición exacta de cada métrica. «Cerradas hoy» se cuenta por closed_at.
3. Evidencia de que los CSV no cambiaron, por ejemplo una huella (un hash) de cada fichero tomada antes y después.
4. Publicación separada del borrador. Lo que escribe el agente es un borrador; lo que lee Operaciones lo crea otro proceso después de validarlo.
5. Un revisor que no comparta la implementación defectuosa, que recalcule desde la fuente con su propio código.

Cada punto de esta lista va a acabar asignado a una capa del harness.

Mide antes de mejorar

Para saber si el harness aporta algo necesitas una línea base (el baseline): cómo funciona el flujo hoy, sin cambios. Sobre los mismos casos, mide cinco cosas:

• Tarea bien resuelta (task success): el informe es correcto y se puede publicar.
• Exactitud: cuántas cifras coinciden con el recálculo.
• Tiempo: el de reloj y el de las personas que intervienen.
• Coste: el consumo del modelo, si lo puedes observar.
• Supervisión: cuántas veces tuvo que intervenir alguien.

«El agente terminó» no aparece en la lista porque no dice nada sobre si el informe es correcto. Es justo lo que afirmaba el agente de OpsPulse.