La arquitectura detrás de ActionFlows

ActionFlows es primero un sistema de flujos. La interfaz es un lienzo. Debajo hay un grafo dirigido, una pasada de validación, un motor de ejecución que lanza las ejecuciones como trabajos y varias superficies de producto que comparten ese núcleo.

Esto es un vistazo a cómo se encuentran esas piezas. No es un volcado de nombres internos de clases.

El grafo es la fuente de referencia

Un ActionFlow es un grafo dirigido de nodos y aristas. Los nodos guardan la configuración de modelos, herramientas o control. Las aristas definen el flujo de datos. El editor, el validador y el motor de ejecución ven la misma estructura, así que el dibujo del lienzo es lo que se va a ejecutar.

Validación antes de ejecutar

Antes de arrancar una ejecución, se valida el grafo. Entradas que faltan, aristas rotas y formas incompatibles fallan pronto. Sale más barato que un fallo silencioso a mitad de trabajo, y deja los errores explicables.

Las ejecuciones son trabajo de primer nivel

Una ejecución es una pasada del grafo. Registra el avance y el resultado para comparar intentos y arreglar un nodo concreto. Sin ejecuciones, el lienzo es un diagrama. Con ellas, es un sistema en marcha.

Registro de proveedores

Modelos e integraciones se alcanzan por un registro compartido, no por rutas de proveedor clavadas. El lienzo pregunta qué existe y enruta el trabajo. Pueden aparecer modelos y herramientas nuevos sin cambiar el modelo del grafo.

Un núcleo, varias puertas

El playground, las plantillas, la API REST, el SDK y los controles de organización se apoyan en el mismo núcleo de flujo. Un compañero puede disparar un flujo que otra persona diseñó a la vista. El modelo mental se mantiene: componer un recorrido, ejecutarlo, revisar el resultado.

Organizaciones y créditos

El trabajo vive en organizaciones para separar proyectos y acceso. Los créditos hacen visible el uso entre ejecuciones. Aquí la arquitectura es el grafo y el límite de quién puede ejecutarlo.

Qué afinamos

• Un grafo al que se pueda señalar.
• Validación antes de que empiece el trabajo.
• Ejecuciones que se puedan abrir después.
• Proveedores que se puedan cambiar.
• El mismo núcleo detrás del editor, la API y el SDK.