Escaneo dinámico en preproducción

Preproducción existe para que el escaneo pueda equivocarse sin consecuencias: llenar formularios con basura, crear cientos de solicitudes, cambiar datos de contacto. Eso solo es cierto si se cumplen dos condiciones. La primera, paridad: misma versión del código, mismas dependencias y la misma configuración que irá a producción, para que lo que se encuentre valga allí. La segunda, aislamiento: datos sintéticos e integraciones de salida (correo, mensajes, pagos) apuntando a simuladores, para que nada de lo que haga el escáner salga del entorno.

Cuando falla la paridad, el informe trae alertas que en producción no existen o se pierde alguna que sí existe. Cuando falla el aislamiento, el escaneo afecta a personas reales, aunque el servidor diga «pre».

Abre el laboratorio y lee paridad-entornos.txt y alertas-pre.txt. Delante de cada entorno hay una capa distinta, y esas capas no ponen las mismas cabeceras. Una alerta causada por esa diferencia no es un fallo del código que va a producción; tampoco se tira sin más: se anota por qué no aplica y con qué evidencia.

Lee integraciones-pre.txt y efectos-del-escaneo.txt. El escaneo cambió datos de contacto decenas de veces, y cada cambio dispara un aviso al asociado. En un entorno aislado ese aviso termina en un simulador.

Un escaneo activo deja rastro: solicitudes, mensajes y cambios hechos por el escáner. Se limpian al terminar, con la lista de lo que creó, para que la próxima prueba (o el próximo equipo que use preproducción) no tropiece con cientos de registros basura. El correo del sumidero se vacía aparte; los mensajes entregados ya no se pueden recoger.

Cuando desarrollo diga que corrigió el reflejo de la búsqueda de oficinas y la protección de los formularios, hay que comprobarlo. Un escaneo completo de toda la noche no es la forma: tarda, vuelve a ensuciar preproducción y mezcla el resultado con todo lo demás.