Modos de simulación (dry-run) para acciones de agentes: mostrar el plan antes del cambio

Objetivo

Permitir que un agente, y la persona que lo supervisa, vean exactamente qué haría una acción que cambia el estado antes de que la haga, usando la misma ruta de código que aplicará después el cambio.

Requisitos previos

Herramientas que separan la planificación de la aplicación, o que pueden envolverse para conseguirlo. Las herramientas consolidadas muestran las formas posibles: rsync --dry-run realiza una ejecución de prueba sin aplicar ningún cambio; terraform plan sin -out crea lo que la documentación llama un plan especulativo, una descripción del efecto sin intención de aplicarlo, mientras que -out=FILE guarda un plan que apply puede ejecutar más tarde; kubectl apply --dry-run=client solo imprime el objeto que se enviaría, y --dry-run=server envía la solicitud sin persistir el recurso; la documentación de la API de Kubernetes describe el modo dry-run como la evaluación de una solicitud a través de las fases habituales (cadena de admisión, validación, conflictos de fusión) hasta el punto de persistir los objetos en el almacenamiento, con la garantía de que no se produce ningún otro efecto secundario.

Pasos

1. Añadir un parámetro dry_run a cada herramienta que escriba, elimine, envíe o publique, y convertirlo en el valor por defecto documentado para la primera llamada de una sesión. La descripción de la herramienta indica que el resultado de una simulación es un plan, no un efecto.
2. Devolver el plan con la misma estructura que el resultado real, más un marcador ("applied": false), con objetos concretos: las rutas de archivo y los fragmentos (hunks), los identificadores de registro y los campos que cambiarían, los destinatarios, los recuentos. «Se actualizarían algunas filas» no es un plan.
3. Preferir las simulaciones en el lado del servidor cuando el sistema de destino las ofrezca; un plan del lado del cliente no puede ver permisos, cuotas, reglas de validación ni cambios concurrentes.
4. Exigir el plan antes del cambio: el anfitrión rechaza una llamada real cuyos argumentos no se hayan enviado antes como simulación en la misma sesión, o encamina el plan a una revisión humana para las acciones por encima de un umbral.
5. Aplicar con los mismos argumentos y, después, comparar el resultado real con el plan y mostrar las diferencias al agente y en el registro; una discrepancia significa que el estado cambió entre el plan y la aplicación, o que la lógica del plan es errónea.
6. Registrar el plan y el resultado juntos, de modo que una revisión pueda ver qué se predijo y qué ocurrió.

Resultado esperado

Toda acción irreversible va precedida de una declaración concreta y revisable de su efecto, y la desviación entre ambas se detecta en lugar de descubrirse más tarde.

Límites y base de verificación

Una simulación demuestra lo que haría la herramienta, no lo que harán otros sistemas en respuesta (webhooks, disparadores, trabajos posteriores). No protege frente a un plan que es correcto pero no deseado; para eso están las puertas de aprobación y las acciones reversibles. El orden de los pasos es una propuesta; no se afirma ninguna reducción de la tasa de fallos.

Precondiciones en la aplicación, planes por umbral

Un plan y una aplicación son dos llamadas con un intervalo en el que el estado puede cambiar, así que una simulación obligatoria antes de cada escritura no demuestra nada sobre el momento de la aplicación y duplica las llamadas para las escrituras de bajo riesgo. Cuando el destino lo permita, conviene exigir una precondición sobre la propia aplicación: If-Match con un ETag, el resourceVersion de Kubernetes, un número de versión de documento, o un plan de Terraform guardado que apply rechace cuando el estado haya cambiado. La escritura falla entonces de forma atómica cuando el mundo ha cambiado, y la comparación posterior pasa a ser una verificación de la herramienta en lugar de la única defensa. Conviene reservar el plan obligatorio para las acciones sin vuelta atrás (enviar, publicar, eliminar sin copia) y para las acciones masivas por encima de un umbral de tamaño; para el resto, la simulación permanece disponible a petición.