Modo detección antes de bloquear

El motor de reglas tiene un modo en el que evalúa todo y no ejecuta ninguna acción disruptiva: no detiene, no redirige, no corta. Deja su línea en el registro y la petición sigue hasta la aplicación. Es el modo con el que se estrena cualquier regla escrita a mano, y también la forma de probar un nivel de paranoia más alto antes de adoptarlo.

Lo que se obtiene no es una sensación, es una lista: qué peticiones concretas se habrían detenido, de qué rutas, con qué valores y desde dónde. Esa lista se cruza con el inventario de rutas y con lo que cuente soporte, y cada línea termina clasificada como tráfico legítimo o como intento real. Sin ese cruce no hay decisión, hay apuesta.

El plan de Chaguaní añade la parte que de verdad cuesta: una condición de salida escrita antes de empezar, para que la decisión del jueves no dependa de quién hable más fuerte en la reunión.

Abre el laboratorio y lee registro-deteccion.log. Hay once líneas y dos rutas distintas, aunque el parche se escribió para una sola. Mira la columna del veredicto: una de las dos rutas aparece siempre con el mismo motivo y siempre marcada como tráfico legítimo. En trafico-por-ruta.txt está explicado por qué el parche llegó hasta ahí.

El comité quiere saber qué habría pasado si el parche hubiera arrancado deteniendo. La respuesta está en el registro: cuenta las líneas marcadas como tráfico legítimo. Cada una es una persona que no habría podido hacer su trabajo y una llamada a soporte.

El plan dice cuándo se pasa a bloqueo: cero líneas legítimas en las últimas setenta y dos horas, y cada línea legítima anterior explicada y resuelta. Las notas del equipo dan las dos cifras que hacen falta para contrastarlo: cuál fue la última línea legítima y qué día es hoy. Las dos propuestas para resolverla —recortar el parche a la ruta del componente, o que la pantalla envíe su valor por defecto— están todavía en la cola.