Flujos de trabajo

Lee las automatizaciones de flujos de trabajo de una instalación: los flujos de trabajo, el grafo completo de un flujo de trabajo, los tipos de nodo que puede usar un grafo y las plantillas seleccionadas. Lee node_types antes de crear o editar un grafo para que cada tipo y parámetro sea válido en la instalación.

Acciones:

• list: Mostrar los flujos de trabajo. Cada flujo de trabajo con si está en vivo, su versión publicada, el número de ejecuciones, la última ejecución y sus nodos (id, name, type). No se enumeran los flujos de trabajo de marca ni de organización.
• get: Obtener un flujo de trabajo. El grafo completo del borrador (nodos, conexiones, notas, configuración) y meta: active, publishedVersionId y, una vez publicado, publishedWorkflow, el grafo que está en vivo ahora. Solo flujos de trabajo de esta instalación. Requiere workflowId.
• node_types: Tipos de nodo. Entradas de la paleta con type, label, category, outputs (ramas) e inputSchema, los parámetros que se deben completar. available es false, con el motivo, cuando a la instalación le falta un módulo que el nodo necesita. Las herramientas MCP aparecen como nodos mcp...
• templates: Plantillas. Puntos de partida para automatizaciones comunes, con risk y riskNote (qué sale mal si se publica sin cuidado), tipos de nodo, módulos necesarios, disponibilidad en esta instalación y un grafo de vista previa. Convierte una en un grafo con workflow_definitions_write instantiate_template.

Crea, edita, publica, detiene y elimina las automatizaciones de flujos de trabajo de una instalación. Ciclo de creación: lee node_types con workflow_definitions_read, crea el grafo (o parte de instantiate_template), créalo como borrador, pruébalo con workflow_runs_write test (simulado) y luego publícalo. Las ediciones de un borrador nunca cambian lo que está en vivo hasta que se publica.

Acciones:

• create: Crear un flujo de trabajo. Guarda un borrador nuevo e inactivo a partir de un grafo completo con al menos un nodo; name es "Untitled workflow" de forma predeterminada. Los problemas de validación se devuelven en errors con detalles del nodo. Requiere nodes.
• update: Guardar el borrador. Reemplaza todo el borrador: envía todos los nodos y conexiones, no solo los cambios. Lo que está en vivo sigue ejecutándose hasta que publiques. Los problemas de validación se devuelven en errors con detalles del nodo. Requiere workflowId, nodes.
• patch_meta: Cambiar el nombre. Cambia solo el nombre o la descripción; el grafo y lo que está en vivo se mantienen igual. changed es false cuando ambos ya coinciden. Requiere workflowId.
• duplicate: Duplicar. Copia un flujo de trabajo en un borrador nuevo llamado " (copy)" con IDs de nodo nuevos, nunca publicado ni activo. El original no se modifica. Requiere workflowId.
• delete: Eliminar. Elimina el flujo de trabajo definitivamente: borrador, versiones publicadas, historial de ejecuciones y enrutamiento de desencadenadores. set_active false lo detiene, pero lo conserva; discard_draft solo restablece las ediciones del borrador. Requiere workflowId. Pide confirmación.
• discard_draft: Descartar las ediciones del borrador. Restablece el borrador a la última versión publicada y descarta las ediciones hechas desde entonces. La versión en vivo nunca se ve afectada; requiere una versión publicada. Requiere workflowId. Pide confirmación.
• publish: Publicar. Valida el borrador, lo guarda como la versión en vivo y activa el flujo de trabajo, de modo que sus desencadenadores se activan y sus acciones se ejecutan de verdad. Las ejecuciones en curso terminan con la versión anterior. Si hubiera que reprogramar pasos Delay en espera, el resultado tiene el código WAIT_RETARGET_CONFIRMATION_REQUIRED e impacts: vuelve a llamar con confirmWaitRetargets y esos impacts. Requiere workflowId. Pide confirmación.
• set_active: Activar o desactivar. active true vuelve a activar un flujo de trabajo publicado. active false lo detiene: los desencadenadores dejan de activarse y los pasos Delay pendientes se cancelan para que nunca terminen. No se elimina nada. Pide confirmación antes, a menos que ya esté en ese estado. Requiere workflowId, active. Puede pedir confirmación.
• instantiate_template: Grafo a partir de una plantilla. Convierte una plantilla en un grafo listo para create: { name, description, nodes, connections } con IDs de nodo nuevos. Las plantillas dejan en blanco a propósito los destinatarios, las puertas y las horas; complétalos primero. No guarda nada. Requiere templateId.
• generate: Generar un grafo. Crea un grafo a partir de una instrucción en lenguaje natural con la IA de la instalación y devuelve { name, description, nodes, connections } usando solo tipos de nodo válidos. Pasa workflow para revisar uno; se devuelve el grafo revisado completo. No guarda nada, pero gasta los créditos de IA de la instalación. Requiere prompt. Pide confirmación.

El historial de ejecuciones de un flujo de trabajo, de la más reciente a la más antigua, y una ejecución paso a paso. Úsalo para comprobar si se ejecutó una automatización, seguir una ejecución iniciada con workflow_runs_write o encontrar qué nodo falló y por qué.

Acciones:

• list: Mostrar las ejecuciones. Cada ejecución con status, mode (live o test), efectos secundarios, desencadenador, quién la inició, horas, número de pasos, el nodo en el que espera y cualquier error. Requiere workflowId.
• get: Obtener una ejecución. El estado de la ejecución más cada paso en orden, con la entrada, la salida, la nota y el error de cada nodo. Las ejecuciones son asíncronas: una con pasos Delay espera hasta que vence su continuación. Requiere workflowId, executionId.

Inicia, prueba, cancela y vuelve a reproducir ejecuciones de flujos de trabajo. Es preferible usar test, que ejecuta el borrador con efectos secundarios simulados; run ejecuta el flujo de trabajo publicado de verdad. Las ejecuciones son asíncronas: síguelas con workflow_runs_read get.

Acciones:

• run: Ejecutar ahora. Ejecuta el flujo de trabajo publicado desde su desencadenador manual (custom.manualTrigger), con efectos secundarios reales. Los desencadenadores programados, de webhook y de eventos se activan por sí solos. Devuelve el executionId de la ejecución y su primer estado. Requiere workflowId. Pide confirmación.
• test: Probar el borrador. Ejecuta el borrador guardado sin publicarlo, registrado como ejecución de prueba. Los efectos secundarios se simulan de forma predeterminada: no se envía ni se cambia nada, y cada nodo informa lo que habría hecho. sideEffects live pide confirmación antes. Requiere workflowId. Puede pedir confirmación.
• cancel: Cancelar una ejecución en espera. Cancela una ejecución que espera en un paso Delay: sus esperas pendientes se cierran y los pasos posteriores nunca se ejecutan. Las ejecuciones terminadas y las que están a mitad de un paso no se pueden cancelar. Requiere workflowId, executionId. Pide confirmación.
• retry: Volver a reproducir una ejecución. Vuelve a reproducir una ejecución terminada a partir de su entrada de desencadenador registrada, vinculada mediante retryOf. published (predeterminado) vuelve a ejecutar de verdad la versión que usó y pide confirmación antes; draft-test ejecuta el borrador actual de forma simulada, la opción adecuada mientras corriges un error. Requiere workflowId, executionId. Puede pedir confirmación.