Entra tu petición. Sale un pull request fusionado.

1. EntradapeticiónLa petición llega como un issue de GitHub, un mensaje de chat por MCP o un webhook, y sigue siendo la fuente de verdad de todo lo que viene después.
2. ScoutplanEl scout lee el repositorio y el hilo en una máquina que tiene el código, y luego escribe un plan, o se detiene como bloqueada o rechazada y explica por qué. Por defecto, un plan que inició tu agente va directo a las máquinas sin pasar por el triaje.
3. Triajetrabajo ejecutableCada petición que llega, de un issue, un tracker, una alerta, tu propio agente o las rondas del propio scout, se juzga con tu propia clave: se dirige a un carril, se descarta con un motivo o vuelve a quien la pidió con una pregunta. Nada desaparece en silencio.
4. Asignadorse toma, no se empujaEl trabajo se toma, nunca se empuja: una máquina libre reclama la siguiente tarea lista. Dos tareas del mismo repositorio que tocan los mismos archivos se esperan entre sí, salvo que una tarea esté marcada como segura para correr junto a otras.
5. WorkerPRTu agente IA escribe el código en tu propia máquina, con tus propias claves, y abre un pull request por tarea. Git lo controla el arnés, no el modelo.
6. CI + revisorciclo de arregloCada push lanza el CI, el revisor juzga lo que es nuevo desde su última revisión, y el worker arregla y vuelve a hacer push hasta que los checks están en verde.
7. Carril de mergemergeLa fusión es una decisión de máquinas: los checks obligatorios, los hallazgos sin resolver y los rechazos de política se pesan antes de pulsar el botón. Si quieres un carril humano, lo mantienes.
8. Tu despliegueproducciónTu propio pipeline publica la fusión, igual que hoy. Nosotros nunca desplegamos tu software.

Cada transición queda registradaLos rechazos de política y las escalaciones se reproducen con una política nueva, sin volver a ejecutar