Cómo crear un manifest de ejecución para que un workflow sepa exactamente qué falta antes de cerrarse

Un manifest de ejecución define por adelantado qué artefactos y efectos deberían existir cuando un workflow termina correctamente. En vez de esperar al final y preguntar de memoria qué faltó, el run crea una lista estructurada: archivo vivo, backup, correo, PDF, fila de auditoría, hashes, IDs y estados requeridos. Cada elemento declara si es bloqueante, cómo se verifica y qué dependencia tiene. El manifest funciona como contrato de cierre. Si un componente falta, el sistema sabe exactamente qué fase sigue pendiente y puede reanudarla sin reinterpretar toda la intención original.

El manifest debería separar artefactos producidos, efectos externos y evidencia de verificación. Un archivo JSON generado localmente es un artefacto; reemplazar el archivo vivo es un efecto; volver a descargarlo y confirmar hash es evidencia. Mezclar los tres crea falsos cierres porque el sistema confunde “tengo bytes correctos” con “el usuario ya los está consumiendo”. Para cada requisito, usa campos como expected, observed, verifiedAt, checksum, resourceId y blocking. Esa estructura permite que humanos y automatizaciones compartan la misma definición de completitud. El punto operativo es que manifest de ejecución no debería quedar como una intuición del equipo: conviene convertirlo en una regla visible, registrable y comprobable después de cada ejecución.

Las dependencias hacen posible recuperar solo lo que falta. Un backup puede depender de vivo verificado; el correo de éxito puede depender de backup y publicación; un PDF puede ser no bloqueante. Si el manifest marca cada relación, el recuperador recorre únicamente nodos incompletos cuyo prerequisito ya está satisfecho. No necesita regenerar contenido porque falló Gmail. Tampoco debería enviar correo si la publicación no está demostrada. Este patrón reduce duplicados y evita que una etapa tardía empuje al sistema a repetir decisiones editoriales que ya fueron cerradas y validadas.

El contrato debe incluir invariantes que no cambian entre ejecuciones. FileIds, cantidad esperada de items, schema, nombres únicos y política de idempotencia pueden formar parte del manifest. Después el run añade valores variables como hash, fecha y IDs generados. La verificación compara ambos grupos. Si aparece un FileId diferente o un item extra, el run no debería corregir silenciosamente la expectativa; debe fallar y explicar la divergencia. Un manifest sirve precisamente para impedir que la definición de “correcto” se adapte retroactivamente a lo que terminó ocurriendo.

También es útil guardar una versión compacta del manifest junto al estado del run. Un operador puede abrirlo y responder en segundos qué existe, qué falta, cuál fue el último hash verificado y qué acción es segura. Las herramientas de recuperación pueden usar la misma estructura para continuar. Esto disminuye dependencia de logs narrativos, que suelen ser extensos y ambiguos. El log explica la historia; el manifest describe el estado deseado y observado. Ambos son útiles, pero cumplen funciones diferentes y no deberían sustituirse mutuamente.

Un manifest de ejecución convierte “terminó” en una afirmación verificable y portable. El workflow sabe qué prometió producir antes de empezar y conserva evidencia de cada requisito al cerrar. Cuando algo falla, la recuperación deja de improvisar y puede completar únicamente el hueco. Este patrón es especialmente valioso en agentes que generan varios artefactos y atraviesan conectores distintos. Cuantos más pasos externos existen, más peligrosa es una definición informal de éxito. El manifest crea una frontera estable entre lo que el sistema intentó hacer y lo que puede demostrar que realmente quedó hecho.

Cierre operativo. Cuando un workflow promete varios resultados, la definición de done debería existir como datos antes de la ejecución y no como una conclusión narrativa al final. En la práctica, conviene separa artefacto, efecto y evidencia y declara dependencias y requisitos bloqueantes antes de ampliar el workflow.