aqorin
Tesis en validación Rev 2026-09-29 Plataforma darwin-arm64 Paquete @aqorin/cli 0.2.0 Licencia MIT

Un workflow.Cualquier agente.

Aqorin es una capa de orquestación independiente del runtime para agentes de código. Defines una vez cómo se especifica, implementa, valida y revisa el trabajo. OpenCode, Pi, Codex, Claude Code o jcode lo ejecutan. Tu configuración sigue siendo tuya.

npm i -g @aqorin/cli
Ayuda a darle forma ↓

Se pronuncia “A-cor-in”. Un experimento construido en público: esta página cuenta la idea y hacia dónde va.

Centralita · asignación
workflow● sin cambios
feature@1
specify → implement
→ validate → review
ningún runtime dentro
asignaciónpor rol
Pulsa un rol y después un runtime.mezclar runtimes = objetivo · TV5
§01El problemaref · docs/01-product-vision

Tu proceso vive en la configuración de un solo agente.

Cada agente de código trae sus propios agentes, comandos, skills, hooks y modelo de permisos. Escribe un workflow real —especificar, implementar, revisar, corregir— y solo existirá en un runtime, sostenido por un prompt que le pide al modelo que se acuerde.

RuntimeDónde vive tu workflowSi cambias de runtime
OpenCodeopencode.json.opencode/reescribirlo
Pi~/.pi/agent/reescribirlo
Codex~/.codex/config.tomlAGENTS.mdreescribirlo
Claude Code.claude/settings.json.claude/skills/CLAUDE.mdreescribirlo
aqorinworkflow+ asignación+ tareacambias una línea: el runtime

Aqorin está diseñado para no sustituir nunca esos ficheros: proyecta su propio overlay, con espacio de nombres propio, a su lado.

§02Cómo funcionaref · docs/30-architecture · docs/33-execution-state

Aqorin manda en la semántica. Los runtimes, en la ejecución.

El Orchestration Engine custodia el Run —su estado, sus políticas, su evidencia— como un log de eventos append-only. Los adapters convierten cada paso en lo que el runtime hace de forma nativa. Cuando un paso intenta atajar, quien dice que no es el reducer, no un prompt.

Enclavamiento · un Run, paso a pasoruntime: codex
Transición legal
Validación superada
Revisión independiente
Presupuesto 0/3
Run ilustrativo. La guarda es real: required_validations_passed en el reducer del core.ilustrativo

Rol ≠ Runtime ≠ Modelo

Tres conceptos independientes: ningún rol canónico implica un runtime o un modelo. Hoy un Run asigna el mismo runtime y el mismo modelo a todos los roles; asignarlos por rol dentro de un mismo Run es justo lo que prueba TV5.

§03Innegociablesref · docs/02-product-principles

Reglas para el engine, no reglas que el modelo debería recordar.

Son las reglas de diseño sobre las que se construye Aqorin. Algunas ya se aplican en código; el resto es lo que el track de validación está construyendo y probando.

01

No toca tu configuración

Aqorin proyecta un overlay aislado, con espacio de nombres propio, junto a tus ficheros. Agentes, comandos, skills, MCP y ajustes nunca se sobrescriben ni se borran.

Dónde vive
Configuration Overlay · adapter
02

Conservas tu UX nativa

Sigue usando opencode, pi o codex igual que hoy. Aqorin es opcional, tarea a tarea.

Dónde vive
Por construcción · un CLI aparte
03

Invariantes en código

Orden de fases, presupuestos, revisión obligatoria, puertas de aprobación y transiciones legales son cosa de un reducer, no de un system prompt.

Dónde vive
Reducer · packages/core
04

El estado es del Run

Una sesión del runtime es un intento, no el Run. Los eventos son durables: si el runtime se cae, lo ocurrido no se pierde.

Dónde vive
Event store
05

Garantías honestas

Cada permiso lleva etiqueta: nativo del runtime, aplicado por Aqorin, sandbox del SO, externo… o no aplicable. Nada se eleva en silencio.

Dónde vive
La guía de permisos de cada adapter
06

Sin mínimo común denominador

Usa de forma nativa la mejor primitiva de cada runtime, emula con seguridad, degrada de forma visible… o se niega a ejecutar. No se quitan funciones por simetría.

Dónde vive
Negociación de capacidades · engine
Señales · negociación de capacidadescuatro respuestas, ninguna en silencio
Capacidad
Native
Emulated
Degraded
Rejected
revisión independiente
native
emulated
degraded
rejected
reanudar sesión
native
emulated
degraded
rejected
proyección de skills
native
emulated
degraded
rejected
sandbox de ficheros
native
emulated
degraded
rejected
selección de MCP
native
emulated
degraded
rejected
Ciclo ilustrativo. Las respuestas reales por runtime están en la guía y la matriz de versiones de cada adapter.ilustrativo
§04Hacia dónde varef · docs/exits/README.md · ADR-0046

La tesis se está probando. Este es el camino.

Aqorin solo merece la pena si puedes definir una vez un workflow independiente del runtime y Aqorin lo ejecuta de forma durable con distintos runtimes y modelos —mezclados en un mismo Run— sin casos especiales en el workflow. Antes de hacer crecer el producto, un Thesis Validation Track prueba exactamente eso.

Salidas · Thesis Validation Trackdarwin-arm64 · opencode · pi · codex
VíaDestinoEstado
Línea base de realidad
Paridad entre runtimes
Validación determinista
Ruta de ejecución unificada
Workflows del usuario
Run multi-runtime y multi-modelo
Recuperación y replanificación
Benchmark de la tesis → revisión

Notas de campo · TV1 paridad2026-09-29

En construcción

Se midió el workflow actual en OpenCode, Pi y Codex con la misma tarea. Todavía no está donde tiene que estar: lo que falta está en el código compartido de Aqorin, no en los runtimes.

Lo siguiente: que Aqorin ejecute él mismo la validación y, después, una única ruta de ejecución para todos los runtimes. Para eso es el resto del track.

Existe hoy

  • Core durable de Runs y eventos
  • Cinco Runtime Adapters
  • Workflow feature integrado, en vivo una vez por runtime, por separado, en macOS arm64
  • @aqorin/cli 0.2.0 en npm, MIT, por detrás de main

Lo siguiente

  • Workflows definidos por el usuario
  • Runtimes y modelos mezclados en un Run
  • Validación ejecutada por el propio Aqorin
  • Más plataformas además de macOS arm64
§05Ayuda a darle formaref · x.com/JuancaRodicio

¿Usas más de un agente de código? Hablemos.

Esta página existe para poner la idea delante de desarrolladores mientras todavía puede cambiar. Las respuestas más útiles son las incómodas.

¿Qué workflow definirías una vez y no volverías a reescribir por agente?

¿Mezclarías runtimes en una misma tarea? Implementar con uno y revisar con otro.

¿Dónde pondrías la frontera entre lo que aplica el engine y lo que decide el modelo?

¿Qué te haría confiar en un orquestador que trabaja junto a tu repo y tus credenciales?

Responde en X →@JuancaRodicio
diario de desarrollo y preguntas abiertas