Workflows

Un workflow es una receta JSON que encadena herramientas de varios kits para obtener un resultado completo: un nivel de blockout iluminado, un Blueprint de puerta con timeline, un guardia que patrulla con navmesh y behavior tree, un landscape con foliage. Una sola llamada (edit.run_workflow) o un solo prompt MCP construye todo; la lista verify del propio workflow vuelve a leer el resultado y comprueba campos concretos, y una ejecución atómica revierte todos los pasos cuando uno falla. El plugin incluye una biblioteca de 19 workflows en Resources/Workflows/; un proyecto puede añadir o reemplazar workflows en <Project>/Saved/UEAMCP/Workflows/.

Llamar a un workflow

Objetivo	Llamada
Listar (con la disponibilidad en este motor)	edit.list_workflows {category?} o MCP prompts/list
Leer el JSON y la lista de pasos como texto	edit.get_workflow {id} o MCP prompts/get {name:id, arguments}
Comprobación estática con tus argumentos	edit.validate_workflow {id, arguments}
Previsualizar los pasos resueltos	edit.run_workflow {id, arguments, dryRun:true}
Construirlo	edit.run_workflow {id, arguments} (atómico por defecto; añade _preview:"auto" para obtener una imagen final)
Eliminar lo que construyó	edit.run_workflow {id, arguments, runCleanup:true} de inmediato, o llama tú mismo a los pasos de cleanup que muestra edit.get_workflow

• arguments es un mapa de strings ({"prefix":"Arena"}); el type declarado los convierte (number, integer, boolean, array, object). argumentsJson acepta en su lugar un objeto JSON. Todos los argumentos integrados tienen un valor predeterminado, así que {id} por sí solo siempre funciona.
• La respuesta lista cada paso con ok, el argsJson resuelto, el resultJson compacto y error; failedStep, succeeded, verified, rolledBack, resolvedArguments, changedAssets/changedActors resumen la ejecución.
• Los clientes sin automatización de herramientas pueden usar el prompt MCP: su texto indica el objetivo, los argumentos con sus valores resueltos y las llamadas exactas en orden, incluidos verify y cleanup.

Semántica de rollback y verify

1. edit.run_workflow valida primero (las herramientas existen y están disponibles aquí, los nombres de los argumentos coinciden con los schemas, los argumentos obligatorios están presentes, las referencias ${...} se resuelven y se cumplen minEngine y requiresPlugins). Cualquier problema rechaza la ejecución antes de que cambie nada.
2. Con atomic:true (predeterminado) crea el checkpoint workflow:<id>, ejecuta los pasos en orden y se detiene en el primer paso que falle o en el primer expect que no se cumpla. El checkpoint se revierte (rolledBack:true, informe rollback): todo lo que se puede deshacer desaparece. Los archivos de assets ya escritos en disco y las escrituras en la configuración del proyecto (gameplay tags, save slots) no se pueden deshacer; los workflows que hacen esto lo indican y su cleanup los elimina explícitamente.
3. Cuando todos los pasos terminan bien se ejecutan las llamadas de verify; cada una debe tener éxito y coincidir con su expect. verified:false no revierte nada (el resultado existe, pero no es lo que prometía la receta).
4. Una ejecución correcta conserva el checkpoint, de modo que edit.checkpoint_rollback {name:"workflow:<id>"} la deshace más adelante mientras el historial de deshacer siga intacto.
5. Una ejecución atómica se niega a empezar mientras haya una transacción del editor abierta (edit.begin_transaction).

La biblioteca integrada

El contenido del nivel va a la carpeta del outliner UEAMCP/<id> (argumento levelFolder) con etiquetas prefijadas por prefix; el contenido de assets va a /Game/UEAMCP/<id con los puntos cambiados por guiones bajos> (argumento folder). cleanup elimina exactamente los actores de esa carpeta y esa carpeta de contenido, además de todo lo demás que haya creado el workflow (landscape, instancias de foliage, save slot, gameplay tags, miembros del Level Blueprint).

Los 19 workflows cubren: un blockout iluminado y un ciclo de día y noche (level.*), un blockout básico (actor.*), un material PBR a partir de una carpeta de texturas y una biblioteca maestra basada en parámetros (material.*), un menú principal y una barra de salud en el HUD (umg.*), una puerta interactiva y un objeto recogible (bp.*), controles de personaje (input.*), un guardia que patrulla con EQS/Behavior Tree (ai.*), un efecto de impacto de Niagara (niagara.*), una toma orbital de Sequencer (sequencer.*), un terreno con foliage (landscape.*), un bosque procedural con PCG (pcg.*), ambiente sonoro (audio.*), configuración de save game (save.*), un área de pruebas de física (physics.*) y una habilidad básica de Gameplay Ability System (gas.*). Cada uno declara sus propios argumentos con valores predeterminados razonables y los kits que utiliza; la lista completa, con los argumentos y el contenido exacto que genera cada uno, está en Docs/guides/workflows.md, en el repositorio del plugin.

El contenido del motor que usa la biblioteca existe tanto en 4.27 como en 5.x: /Engine/BasicShapes/{Cube,Cone,Cylinder}, /Engine/EditorSounds/Notifications/CompileSuccess, /Engine/EngineMaterials/DefaultPhysicalMaterial y la plantilla de Niagara RadialBurst. Un workflow cuyos requisitos no cumple el editor se lista con available:false y el motivo, y edit.run_workflow lo rechaza.

Escribir un workflow del proyecto

Guarda <Project>/Saved/UEAMCP/Workflows/<id con los puntos cambiados por guiones bajos>.json; se detecta en la siguiente llamada (sin reiniciar). Un archivo del proyecto con el id de un workflow incluido lo reemplaza.

Reglas que mantienen un workflow fiable (la biblioteca incluida las cumple todas):

• Sustitución. ${arg} lee un argumento; ${stepId.path} lee la respuesta de un paso anterior (${floor.actor.label}, ${fx.handles.0.id}, ${forest.edges.length}). Un string que es exactamente un token conserva el tipo JSON del valor (los números siguen siendo números); los tokens dentro de un string más largo se insertan como texto.
• Expect. Las claves son rutas de la respuesta (a.b, list.0.name, list.length); los valores se comparan con una tolerancia numérica de 1e-4, sin distinguir mayúsculas en los strings; "*" significa presente y no vacío.
• Nombres, no suposiciones. Cada argumento y campo de respuesta debe existir en el schema de la herramienta. Descúbrelos con edit.search_tools, edit.get_tool_schema o, en el repositorio del plugin, python Tools/check_workflows.py . --catalog bp..
• Requisitos. Si algún paso usa una herramienta limitada por MinEngine o RequiresPlugin, declara el mismo minEngine / requiresPlugins en el workflow.
• Sin esperas. Los pasos se ejecutan en el game thread: usa herramientas que terminen de forma síncrona y nunca herramientas OffThread (nav.wait_build, pcg.wait_generation); deja el trabajo asíncrono para una llamada directa después de la ejecución.
• Cleanup. Pon el contenido del nivel en una carpeta del outliner y elimínala con actor.delete_by_filter {folder, _confirm:true}; pon los assets en una carpeta de contenido y elimínala con asset.delete_folder {folder, _confirm:true}; elimina explícitamente los efectos secundarios que no se pueden deshacer.

Comprobaciones

• python Tools/check_workflows.py . — comprobación estática de todos los workflows incluidos frente a los headers de las herramientas (nombres, argumentos obligatorios, rutas de respuesta usadas en expect y ${step...}, orden de los pasos, requisitos, confirmaciones de riesgo, id = nombre del archivo).
• python Tools/workflow_smoke.py --project <smoke project> --tag 58 — contra un editor en ejecución: prompts, checkpoints, lotes atómicos, previsualizaciones y, después, para cada workflow validate -> dry run -> ejecución atómica -> verify -> cleanup.