Automatización que destruye evidencia

La evidencia no dura igual toda. La memoria volátil y las conexiones abiertas desaparecen al apagar o reiniciar; los registros locales duran hasta que se sobrescriben; el disco dura hasta que se reimagina. Se capturan de la más frágil a la más duradera, y antes de cualquier paso que borre.

Un flujo automático debe respetar ese orden por diseño. Cada paso que destruye algo necesita, antes de él, un paso que guarde una copia y que compruebe que la copia existe. Un paso de copia que falla sin que el flujo se entere es peor que no tenerlo: da la falsa seguridad de que se guardó.

En PB-11 hay pasos que destruyen algo y pasos que necesitan algo. El defecto aparece cuando un paso destructivo va antes que uno que dependía de lo destruido. Se encuentra leyendo las dos columnas en el orden de ejecución.

Abre el laboratorio y revisa pasos_pb11.

Una automatización destructiva rara vez falla con ruido. Lo normal es que el paso siguiente tropiece con lo que ya no está, deje un error en el registro y el flujo continúe, porque nadie le dijo que debía detenerse. Ese error es la huella del orden equivocado.

Compara ejecucion_pb11 con lo que cada paso necesita y busca el que falló.

El mismo problema aparece sin ningún paso explícito: una purga automática de cuarentena que elimina el mensaje original cierto número de días después de guardarlo. Si el caso lo pide más tarde, no existe. El mensaje original tiene valor probatorio: sus cabeceras y el adjunto no se reconstruyen desde una captura de pantalla.

Lee retencion_de_correo. Calcula el día de la purga (guardado más los días indicados) y cuántos días pasaron hasta que el caso lo pidió.

Hay dos caminos para arreglar estos flujos: ajustar el orden y la retención, o poner a una persona a vigilar cada ejecución. El primero es de diseño y se mantiene; el segundo depende de que alguien esté despierto a las dos de la madrugada.