Saltar a contenido

Fleet Dispatch

Requiere un servidor RaiSE

Esta funcionalidad se comunica con un servidor RaiSE en vez de funcionar solo en local. Levanta uno con la guía self-hosted (en inglés), o apunta la CLI a un despliegue existente.

Fleet dispatch es el sistema de RaiSE para paralelizar la ejecución de stories. Lee el grafo de dependencias de tus stories — específicamente los links blockedBy de tu backlog — resuelve qué stories pueden ejecutarse concurrentemente y las despacha a agentes o worktrees disponibles.

¿Por Qué Fleet?

El ciclo de vida de story por defecto es secuencial: una story a la vez, un agente, un worktree. Este es el punto de partida correcto — es simple y predecible. Pero los epics grandes tienen stories independientes que no dependen entre sí. Ejecutarlas secuencialmente desperdicia tiempo.

Fleet hace que la estructura de dependencias sea explícita y ejecutable. Las stories independientes corren en paralelo. Las stories con bloqueos esperan a que sus dependencias se resuelvan. El resultado es el mismo rastro de gobernanza que el trabajo secuencial, entregado más rápido.

Cómo Funciona

Fleet opera en tres pasos:

1. Leer el DAG

Fleet consulta a tu backlog adapter los links blockedBy de las stories. Estos links definen el grafo de dependencias: que la Story B esté bloqueada por la Story A significa que la Story A debe completarse antes de que la Story B pueda empezar.

Story A ──► Story B ──► Story D
Story C ──────────────► Story D

En este grafo, A y C son independientes y pueden correr en paralelo. B está bloqueada por A. D está bloqueada por B y por C.

2. Resolver el Trabajo Elegible para Paralelismo

Fleet calcula qué stories tienen todos sus bloqueos resueltos (o no tienen bloqueos). Estas son las stories "despachables" en este momento — las que pueden arrancar inmediatamente.

En cada ciclo de despacho, este cálculo se reejecuta. Cuando A se completa, B se vuelve despachable. Cuando B y C se completan, D se vuelve despachable.

3. Despachar a Agentes

Cada story despachable se asigna a un agente y (opcionalmente) a un worktree. El agente recibe la configuración del pipeline de la story y ejecuta el ciclo de vida completo — design, plan, implement, review — sin intervención humana en los gates no-HITL.

Fleet dispatcher
  ├── Agent 1 → Story A (worktree-epic-a)
  └── Agent 2 → Story C (worktree-epic-b)

(A completes)
  └── Agent 1 → Story B (same worktree)

(B and C complete)
  └── Agent 1 → Story D

Integración con Misiones y Worktrees

Fleet tiene scope de misión. Despachas fleet para una misión, y opera sobre los epics vinculados a esa misión. La misión proporciona el contexto de objetivos que cada agente carga al inicio de la sesión.

Los worktrees son las unidades de aislamiento para el trabajo despachado por fleet. Fleet crea o reutiliza worktrees por asignación de agente. Cada worktree está vinculado al mismo work item, de modo que el contexto es consistente entre todos los agentes paralelos.

Ver Worktrees para cómo funciona la vinculación de worktrees.

Herramientas MCP

Fleet expone sus operaciones a través del servidor MCP rai-workspace. Estas herramientas no están registradas por defecto — ver Estado Experimental más abajo.

Herramienta MCP Propósito
fleet_dispatch Iniciar el despacho de fleet para una misión o epic
fleet_status Mostrar el estado de despacho actual y las asignaciones de agentes
fleet_approve Aprobar un gate HITL en todos los agentes en ejecución
fleet_signal Enviar una señal a uno o a todos los agentes en ejecución

Estado Experimental

Fleet dispatch es una funcionalidad en evolución. La resolución del DAG y el pipeline de agente único son estables. El despacho paralelo multi-agente con coordinación de worktrees en vivo está en desarrollo activo. Espera que la superficie de API y el comportamiento cambien en releases menores.

Como fleet está fuera del alcance distribuido del release actual, se entrega presente pero oculto:

  • CLI: fleet está oculto en rai --help. Los comandos siguen funcionando cuando se invocan por nombre — rai fleet --help, rai fleet dispatch ....
  • MCP: las cuatro herramientas fleet_* se registran solo cuando RAISE_EXPERIMENTAL tiene un valor truthy (1, true, yes, on). Sin ella nunca llegan a la lista de herramientas del cliente. El opt-in aplica solo a stdio local; nunca expone las herramientas por HTTP.

Definir la variable en tu shell no es suficiente. Las herramientas se registran en tiempo de importación dentro del servidor MCP — un proceso separado y de larga vida que hereda su entorno de la configuración de arranque de tu cliente, no del shell donde ejecutas rai. La variable tiene que llegar a ese proceso:

// .mcp.json
{
  "mcpServers": {
    "rai-workspace": {
      "command": "/path/to/.venv-mcp/bin/rai-mcp-pipeline",
      "env": { "RAISE_EXPERIMENTAL": "1" }
    }
  }
}

Luego reinicia el cliente para que el servidor se relance con ella. Un servidor en ejecución no recogerá la variable, y ningún comando rai puede decirte si lo hizo — el CLI y el servidor MCP no comparten entorno.

Nada se elimina de la distribución — esto es ocultación, para que lo que anuncia una instalación fresca coincida con lo que el release realmente promete.

Consulta la Referencia CLI: fleet para el conjunto de comandos estables actual.

Próximos Pasos