Qué corregir y cómo

Los sobres antiguos no desaparecen porque el código cambie. La migración correcta tiene cuatro pasos: lo nuevo se escribe ya con el formato bueno; cada sobre lleva su versión en un campo, y se abre según ese campo; lo antiguo se re-cifra en lotes y se marca; y se pone una fecha de retiro de la lectura vieja. Lo que no se hace es decidir la versión por intento y error, porque eso reabre el hallazgo de la sala anterior.

Lee plan-de-migracion.txt con esa lista delante.

El alcance se mide en registros, no en impresiones. La tabla de hallazgos dice a cuántos afecta cada uno. Para ordenar el trabajo, el alcance es solo un criterio —también cuenta la facilidad de explotar y el coste de arreglarlo—, pero es el que se lee directamente.

El inventario separa los sobres por almacén. El plan de migración se dimensiona con el total de los que siguen en la versión sin etiqueta: es el número de lotes y de horas de ventana que habrá que pedir, y el dato que se informa a quien aprueba el trabajo.

Un hallazgo no está corregido porque el código cambió, sino porque hay una prueba que falla con el código viejo y pasa con el nuevo. Para los hallazgos de este módulo, la prueba que lo demuestra altera un sobre ya sellado y exige que se rechace sin entregar texto; y otra, que cifra dos veces el mismo dato y exige que los nonces difieran.

Una migración sin fecha de retiro se vuelve permanente: la lectura de la versión vieja se queda «por si acaso» y con ella el riesgo. El plan fija el día en que esa lectura se apaga, y con él se agenda el último lote de re-cifrado.