Forum

vx forum permite a los agentes mostrarte algo más rico que texto de terminal.

forum: revisar en tu navegadorCopiar enlace

vx forum .vexillum/forum/plan.html

Los agentes escriben sus artifacts en .vexillum/forum/ dentro del proyecto. vx init agrega un .vexillum/.gitignore que mantiene esa carpeta fuera de git; cualquier ruta que pases por la línea de comandos sigue funcionando.

Sirve un archivo HTML que escribió el agente a tu navegador y le lleva tu feedback de vuelta. Un servidor local por usuario corre en 127.0.0.1 y se detiene solo cuando no hay nada conectado. Podés chatear, encolar mensajes, completar formularios de decisión y anotar elementos, y mandarlo todo al agente. Un diagrama Mermaid se convierte en una pizarra editable.

Del lado del agente:

Las sesiones se identifican por la ruta absoluta del archivo. forum viene dentro del binario: sin Node, sin npx, sin red.

El servidor se queda quietoCopiar enlace

El servidor intenta no moverse ni desaparecer debajo de una pestaña abierta:

• Mismo puerto. Registra el puerto que ocupó en ~/.vexillum/forum/last-port y lo prefiere en el siguiente arranque (esperando unos segundos a que el servidor anterior lo libere), así que una pestaña abierta sigue funcionando. Solo si otro proceso sigue ocupando ese puerto cae a uno libre y registra ese.
• No se reemplaza un servidor en uso. Después de actualizar vexillum, un servidor en marcha puede ser de un build más viejo. El build nuevo lo reemplaza solo cuando no tiene sesión abierta, ni pestaña conectada, ni poll esperando. Si no, el nuevo vx lo reutiliza cuando su protocolo es compatible, y se detiene con un error que dice qué hacer cuando no lo es (terminar o cerrar las sesiones y las pestañas, o correr vx forum stop). Un servidor demasiado viejo para informar su actividad se reutiliza, nunca se detiene.
• Las pestañas se recuperan solas. Cuando el servidor sí se reinicia, una pestaña abierta muestra un banner de reconexión y reintenta sola contra la misma dirección. Las sesiones, los mensajes encolados y la transcripción se restauran desde disco, y el enlace de la sesión sigue funcionando.

El listener y el inboxCopiar enlace

Un proceso chico en segundo plano sostiene el poll bloqueante de cada sesión, así que no muere cuando el agente se ocupa: vx forum listen (oculto; vx forum <file> lo arranca si no está corriendo, uno por usuario, protegido por un pid lock). Es código común, sin ningún modelo detrás, así que solo puede reenviar. Por cada prompt que mandás desde una sesión abierta dentro de un proyecto de vexillum:

1. escribe el prompt, con todos sus campos y las rutas de las imágenes adjuntas, en el inbox durable del proyecto (forum-inbox/<session>/<uid>.json, un archivo atómico por prompt, así que un crash o una reentrega nunca pierde ni duplica uno),
2. registra un forum wake, uno por sesión sin importar cuántos mensajes llegaron,
3. publica una línea fija en el panel ("Received. Forwarded to the commander, who will answer here.") que no cuenta como respuesta,
4. y recién entonces confirma al servidor.

Al commander lo despiertan de la misma manera que para los soldiers (el Stop hook en Claude Code, la extensión de wake en Pi, el sentinel publicando en la sesión a través de la API de OpenCode; ver Sentinel), con una línea como forum session <file>: 2 new messages (ended: false). Run vx forum inbox. Corre vx forum inbox, que imprime los prompts sin leer en el formato de salida del poll (con tamaño acotado, adjuntos solo por ruta, como datos), actúa, responde con vx forum reply <file> --reply "..." y confirma con vx forum inbox --ack <uid>.... Un prompt se vuelve a mostrar hasta que se confirma, así que un commander reiniciado no pierde nada. Send & End reenvía los prompts finales con ended: true; solo eso autoriza al commander a implementar.

El listener le dice al navegador si hay un commander (si no, "no se conoce ninguna sesión de commander para el proyecto"). Un commander cuenta cuando su Stop hook tiene un vx sentinel await vivo, o cuando el registro de commanders del proyecto tiene una entrada viva. vx dispatch y vx forum <file> anotan el pane de herdr donde se escribieron (HERDR_PANE_ID) bajo el harness que herdr reporta para él, una entrada por harness, así que un commander en Pi u OpenCode, que no tiene Stop hook, igual se encuentra. Una entrada está viva mientras herdr agent get siga respondiendo por su pane con el mismo harness trabajando dentro del proyecto; si herdr renumera sus panes, el pane se busca de nuevo por directorio, y si no aparece la entrada cuenta como ausente. Un commander con un Stop hook vivo se comporta exactamente como antes.

Una sesión abierta fuera de cualquier proyecto no tiene commander al que despertar: el listener la deja sin entregar y vx forum poll sigue funcionando para ella como antes. El listener termina solo cuando no hay ninguna sesión abierta o se fueron todas las ventanas de revisión, y vx forum stop lo detiene primero.

Varias sesiones a la vezCopiar enlace

Cada sesión con poll necesita un listener, y un poll muere cuando entrega feedback, cuando vence su tarea en segundo plano o cuando el agente está ocupado. Con varias sesiones abiertas, algunas pueden quedar sin nadie escuchando. vx forum poll --all lo resuelve con un solo listener para todas:

• Cubre cada sesión abierta (las sesiones que se abren mientras espera se suman), así que todos los paneles muestran al agente escuchando.
• Cada llamada entrega el feedback de una sola sesión, la que más espera, e imprime su session y su file para que el agente sepa qué artefacto editar. other_sessions_pending indica cuántas más están esperando; la siguiente llamada las entrega.
• --reply-to <file> nombra la sesión a la que responde un --reply.
• Una sesión que termina mientras espera se informa una sola vez como ended. no_sessions significa que no hay ninguna abierta. browser_disconnected significa que todas las ventanas de revisión se fueron.

vx forum poll <file> sigue funcionando para una sola sesión.

Un poll que muere nunca pierde feedbackCopiar enlace

Un poll no consume el feedback por devolverlo. Los prompts quedan en el servidor hasta que el comando confirma que los imprimió. Si el poll fue matado, venció o perdió su salida en el medio, volver a correr poll entrega los mismos prompts otra vez, marcados redelivered: true, con los mismos uid y antes que cualquier cosa más nueva, para que el agente se salte lo que ya aplicó. Esto sobrevive a un reinicio del servidor.

Qué dice el panel sobre tu agenteCopiar enlace

Después de apretar Send to Agent, el overlay Agent is working on your feedback se queda hasta que el commander responde de verdad (un vx forum reply), el artefacto cambia, o apretás Stop waiting. La línea "Received" del listener y que vuelva a hacer poll no lo sacan.

El playbook del agente es la skill forum, que instala vx init (el texto completo está en Skill: forum).