Verificación y reverificación, la versión que vuelve

Un ticket de remediación se cierra con evidencia: la versión leída del archivo en el servidor después del cambio, no la palabra de quien lo hizo. Cuando hay cientos de aplicaciones, los tickets sin evidencia son un riesgo silencioso: parecen cerrados, entran en la cifra de avance y, si el cambio no se hizo, nadie se entera.

Abre tickets.csv y corte-2026-11-16.csv. Busca el ticket cerrado sin evidencia y mira la versión que había en el servidor dos días después.

La reverificación no es repetir la revisión de los mismos servidores: es mirar también los que antes no existían. Un servidor nuevo, creado para dar más capacidad, parte de una imagen base. Si esa imagen no se actualizó, nace con la versión vulnerable aunque todos los demás ya estén corregidos.

Compara los dos cortes: busca el servidor del segundo que no aparecía en el primero y que además tiene una versión afectada.

Otra forma de volver atrás es la restauración. Si un servidor falla y se recupera desde una copia de respaldo anterior al parche, el parche se pierde con la copia. No es un error de nadie: es una consecuencia de la recuperación que el programa debería anticipar.

Cruza los dos cortes y origen-de-servidores.csv. La aplicación que cambió de una versión corregida a una afectada es la que sufrió una regresión.

La cifra de la reverificación es la del corte, no la de los tickets: cuántos servidores muestran hoy una versión afectada. Para decidir qué cuenta como afectada hay que usar el aviso vigente, no el original. La regla 1 del leeme.txt recuerda el rango de la revisión 2.

El equipo pregunta si la reverificación es necesaria cuando todos los tickets están cerrados con evidencia. La respuesta está en lo que acaba de pasar: dos de los problemas del segundo corte no se debían a un ticket mal cerrado, sino a hechos posteriores al cierre.