vx doctor

Informar sobre la salud del entorno de vexillum. Solo lectura.

La herramienta en la que corre el commander es la que doctor exige. Un proyecto
inicializado registra sus harnesses de commander en .vexillum/config.json
('vx init --commander', claude por defecto); el binario de cada uno es
obligatorio y los demás solo advierten. Para un commander claude doctor también
revisa el hook Stop y el import en CLAUDE.md que se describen más abajo, que un
proyecto sin commander claude no necesita.

Además de las herramientas que maneja vexillum, para un proyecto inicializado
doctor informa el estado del bloque de vexillum en AGENTS.md o CLAUDE.md
(absent, current, stale, drifted o malformed), si CLAUDE.md importa AGENTS.md
cuando el bloque está en AGENTS.md, cada skill first-party (instalada y al día,
stale, editada a mano o faltante), si los perfiles de modelo de models.json son
válidos, y si el modo yolo está activado (el commander aterriza una mission
terminada sin preguntar).

Cuando un perfil de modelo selecciona el harness pi, o hay un binario pi en el
PATH, doctor también informa sobre Pi: el binario, su versión y si la
integración de herdr para pi está instalada ('herdr integration install pi').
Solo advierten; una configuración sin Pi no ve ninguna de estas líneas.

Lo mismo vale para OpenCode, cuando un perfil selecciona el harness opencode o
hay un binario opencode en el PATH: el binario, su versión (1.x desde 1.18.29, o
2.x; cualquier otra es una advertencia), una advertencia cuando una instalación
1.x más vieja tapa a una 2.x en el PATH (nombra las dos), y si la integración de
herdr para opencode está instalada y al día ('herdr integration install
opencode').

Para un commander pi doctor revisa, en lugar del hook Stop, que
.pi/extensions/vexillum-wake.ts esté y sea igual a la copia que lleva este
binario (current, stale o editada a mano), que .pi/settings.json liste
../.claude/skills para que Pi vea las skills, si a Pi se le dijo que confíe en
la carpeta (lee ~/.pi/agent/trust.json y nunca lo escribe; sin respuesta
guardada advierte que Pi va a preguntar una vez), y que el await de la
extensión encuentre un binario vx desde el entorno en el que corre doctor. Solo
advierten.

Cuando opencode es uno de los commanders del proyecto, doctor también revisa
cómo lo va a despertar el sentinel, desde afuera, a través de la API HTTP V2 de
OpenCode: si el commander se registró (su pane sigue vivo), si el servicio de
fondo responde 'GET /api/info' en este entorno (se consulta antes con 'opencode
service status', así que doctor nunca arranca uno; OpenCode 1.x no tiene esa API
y es una advertencia), y si el bloque de vexillum está en un archivo que
OpenCode lee (un bloque en CLAUDE.md se ignora cuando existe un AGENTS.md).
Doctor no le manda ningún prompt a la ruta del wake. Los chequeos de la API usan
el HOME y los directorios XDG_* de este shell, que el sentinel debe compartir.

También revisa el hook Stop del sentinel, el que despierta al commander cuando
un soldier termina: si está registrado en .claude/settings.json, si su comando
encuentra un binario vx al correr desde un entorno vacío (solo HOME y
PATH=/usr/bin:/bin, como lo tiene el shell de un hook que nunca leyó tu
perfil), y si hay un sentinel corriendo. Un hook que no puede encontrar vx es
una advertencia que nombra la solución; nunca hace fallar a doctor.

Una advertencia también nombra el caso de dos commanders vivos en un proyecto
(el registro de commanders los conoce, por ejemplo Claude Code y Pi): comparten
una sola cola de wakes y un wake llega solo al primero que lo pide, así que
mantené un commander por proyecto.

Doctor también advierte sobre todo proyecto, de cualquier repositorio, cuya cola
de wakes tenga wakes de más de un minuto que nada va a entregar: ningún 'vx
sentinel await' vivo ahí ni commander registrado vivo. El commander que despachó
esos soldiers puede vivir en otro proyecto, o llevar más de los 55 minutos del
await sin turno. No se pierde nada: los wakes esperan al próximo turno de un
commander en ese proyecto.

La línea del sentinel advierte, y nunca falla, cuando hay más de un proceso
sentinel vivo (competirían por las mismas tareas), cuando el sentinel vivo es
de una versión distinta a la de este binario, o cuando el binario desde el que
arrancó fue reemplazado en disco desde entonces (un rebuild informa la misma
versión, "dev"). Cada advertencia nombra el pid que hay que detener; el
siguiente vx dispatch, prompt o await del sentinel arranca entonces uno al
día.

Uso:
  vx doctor