vx dispatch

Despachar un soldier (mission o scout) a un camp aislado.

Uso:
  vx dispatch <prompt> [--kind mission|scout] [--profile <name>] [--model <model>] [--effort <level>]

Una mission cambia código y entrega algo para aterrizar; un scout solo
investiga y reporta (por defecto: mission).

--model y --effort se pasan tal cual al CLI real del harness. En claude (el
valor por defecto): --model haiku, sonnet, opus o fable; --effort low, medium,
high, xhigh o max. En un perfil que selecciona el harness pi: --model es un
provider/id como anthropic/claude-sonnet-5 (se convierte en pi --model) y
--effort es un nivel de thinking, off, minimal, low, medium, high, xhigh o max
(se convierte en pi --thinking, que pi ajusta a lo que el modelo soporta).
vexillum solo valida que el valor tenga la forma correcta para el harness:
nunca elige uno por vos.

--profile <name> busca el modelo y el effort en la tabla de perfiles ('vx
models' la lista: <project>/.vexillum/models.json sobre el
~/.vexillum/models.json opcional sobre los valores por defecto incluidos). Un
--model o --effort explícito sigue ganándole al perfil. Un perfil desconocido
es un error que lista los válidos; "default" selecciona la entrada por defecto
de la tabla. Qué perfil conviene a una tarea lo decidís vos. Ver la skill
vexillum.

Un perfil también puede nombrar, en models.json, el harness (el CLI de agente)
en el que corre su soldier: "claude" (el valor por defecto cuando no nombra
ninguno), "pi" u "opencode". El harness queda registrado en la tarea y 'vx
redispatch' lo conserva. A un soldier de pi se le responde con texto libre
cuando se bloquea (no tiene un selector donde pulsar una tecla), y necesita el
CLI pi en el PATH.

En un perfil que selecciona el harness opencode, --model es un provider/model con
un #variant opcional, como opencode/glm-5.3-flash-free o
anthropic/claude-sonnet-5#high ('opencode models' los lista), y --effort es solo
una etiqueta que se registra en la tarea: nunca se convierte en un variant de
OpenCode, porque los nombres de variant cambian según el modelo. Se manejan
tanto OpenCode 1.x (desde 1.18.29) como 2.x; la versión que hay en el PATH se
detecta al despachar y se registra, y redispatch, prompt y decide siguen
usándola. En 2.x el soldier recibe su propia sesión de OpenCode con ese modelo y
ese variant, creada a través del servicio en segundo plano de OpenCode (que
dispatch levanta, desde un entorno sin OPENCODE_CONFIG, OPENCODE_CONFIG_DIR ni
OPENCODE_CONFIG_CONTENT, cuando no hay ninguno corriendo) y abierta con
opencode --session. Antes, dispatch comprueba el provider, el modelo y el variant
contra lo que OpenCode lista para el camp, y falla nombrando lo que existe
cuando alguno no está. No se escribe nada en el camp ni en el proyecto: el
opencode.json u opencode.jsonc propio, los agentes, el agente por defecto y los
deny de permisos del proyecto se aplican intactos. El id de la sesión queda
registrado en la tarea y redispatch lo reutiliza. A un soldier de opencode se le
responde con texto libre cuando hace una pregunta, y necesita el CLI opencode en
el PATH. Ver 'vx doctor'.

Corre una sesión real e interactiva del harness (Claude Code por defecto, con
--dangerously-skip-permissions; pi no tiene prompts de permisos que saltear y
arranca con --approve para que nunca se detenga a preguntar si confía en el
camp) en un pane de herdr, dentro de un git worktree nuevo, aislado del árbol de
trabajo propio de este proyecto: el soldier tiene acceso total al host bajo
el usuario del sistema operativo que invoca (sin contenedor, chroot ni otro
sandbox); el worktree solo acota dónde caen sus commits, no lo que puede leer,
escribir o exfiltrar en otro lugar de la máquina. Nada llega al historial real
del proyecto hasta que 'vx land' se aprueba explícitamente; nunca despaches
contra un prompt, un repositorio o una máquina donde leer estado sensible del
host sería un problema. Requiere HERDR_WORKSPACE_ID (corré esto desde un pane
administrado por herdr) y que herdr y el CLI del harness (claude, pi u
opencode) estén en el PATH; si falta alguno lo dice y termina antes de crear nada ('vx doctor'
revisa tu configuración).

La tarea registra al commander que la despachó: el proyecto que drena el await
de su hook Stop y su pane de herdr (HERDR_PANE_ID), que se encuentran a partir
del await vivo de ese pane o, si no hay, de dónde trabaja el agente del pane. El
sentinel pone los wakes del soldier en el proyecto propio de ese commander, así
que un commander que trabaja en un repositorio puede despachar en otro y oír
igual cuando el soldier termina. Cuando los dos proyectos difieren, dispatch
advierte, porque status, land, strike y prompt se siguen corriendo desde el
proyecto en el que se despachó el soldier. Fuera de un pane de herdr no se
registra nada y el wake queda en el proyecto propio de la tarea.

Vuelve rápido: envía el prompt y deja de esperar en cuanto ve al soldier
trabajando (o ya asentado), no la tarea completa. Un prompt trivial que se
asienta de inmediato informa su resultado al instante; cualquier otro se deja
corriendo e inicia automáticamente un sentinel (si no hay uno ya vigilando este proyecto) para
registrar su estado final. Ver 'vx sentinel'.