Ordo

Arquitectura

1. Cliente

   POST /jobs con receta + artefactos
2. Ordo

   valida · guarda · rastrea estado
3. Workers n8n

   reclama paso · ejecuta herramienta · registra artefacto
4. Object storage

   artefactos en MinIO / S3
5. Finalizador

   entrega salidas · hook on_exit

Por qué existe

Construí Ordo mientras construía Skyport. n8n era excelente ejecutando pasos e integrando sistemas, pero el pipeline seguía necesitando garantías que n8n no daba: que las entradas de un trabajo fueran válidas antes de correr el primer paso, que las salidas de un paso coincidieran con lo que el siguiente esperaba, que un trabajo fallido dejara un rastro claro de qué se había producido y qué no. Quería algo que se situara sobre la ejecución, siguiera siendo simple y aun así fuera estricto.

El modelo

Una receta es una lista de pasos. Cada paso nombra un tipo de ejecutor, mapea los slots de entrada del ejecutor a referencias de artefacto con namespace (job:<nombre> para entradas del trabajo, step:<id>.<slot> para salidas de paso) y mapea sus slots de salida a nombres de artefacto. Los ejecutores son filas de una tabla step_executor que declaran qué aceptan y producen; la validación de la receta comprueba que cada tipo de paso existe, cada slot está ligado exactamente una vez, cada artefacto referenciado es producible y ningún nombre de artefacto se repite. Los parámetros se declaran en las recetas solo por clave y se suministran por trabajo, así que sus valores nunca afectan a la identidad de una receta.

Los trabajos se crean a partir de una receta más artefactos de entrada concretos, parámetros y declaraciones opcionales de salida. Ordo inserta la cola de pasos, expone el progreso como fracción entre pasos, muestra la última línea de log de cada paso y ejecuta un paso on_exit cuando el grafo principal termina, sea cual sea el resultado. Un max_concurrency por paso limita cuántas instancias de un ejecutor corren a la vez entre todos los trabajos.

Límites y próximos pasos

Ordo no ejecuta pasos, no gestiona infraestructura, no ofrece editor ni mueve archivos. Los workers de n8n reclaman pasos directamente de la base de datos, ejecutan la herramienta, registran artefactos e informan el estado; un workflow finalizador aparte entrega las salidas declaradas a su ruta final de almacenamiento. Ese contrato directo con la base de datos es pragmático, no fundamental, y la hoja de ruta es desacoplarlo tras colas o APIs para que varios backends de ejecución corran en paralelo.

La API es un pequeño servicio TypeScript/Express sobre PostgreSQL con migraciones aplicadas al arrancar, publicado con semantic-release y distribuido como imagen Docker.