vx forum

Abrir un artefacto HTML local para revisión visual y recoger el feedback del usuario.

Uso:
  vx forum <html-file> [--no-open] [--reopen] [--port <n>]
  vx forum poll <html-file> [--reply <text> | --reply-file <path|->] [--timeout <duration>]
  vx forum poll --all [--reply-to <html-file> (--reply <text> | --reply-file <path|->)] [--timeout <duration>]
  vx forum inbox [--ack <uid>...]
  vx forum reply <html-file> (--reply <text> | --reply-file <path|->)
  vx forum end <html-file>
  vx forum stop

forum <html-file> abre (o retoma) la sesión de revisión de ese archivo y vuelve
de inmediato, imprimiendo la URL de la sesión y el siguiente paso; un servidor
local por usuario sigue corriendo en segundo plano en 127.0.0.1 y se detiene
solo cuando no hay nada conectado. El artefacto recibe window.forum.queuePrompt
y window.forum.sendQueuedPrompts, y el usuario puede chatear, encolar mensajes
y enviarlos al agente desde el navegador. Un diagrama Mermaid escrito como
<div class="mermaid">...</div> se convierte en una pizarra editable. Las
sesiones se identifican por la ruta absoluta del archivo.

  --no-open   no abre el navegador
  --reopen    reabre una sesión que el usuario terminó desde el navegador
              (solo cuando el usuario pidió más revisión)
  --port      puerto donde enlazar si el servidor todavía no está corriendo

forum poll bloquea hasta que el usuario envía feedback, termina la sesión, o
deja el navegador desconectado más allá de un período de gracia (status
browser_disconnected; la sesión se puede retomar). El feedback entregado se
consume. --reply muestra la respuesta en markdown del agente en el panel de
conversación del navegador antes de volver a esperar; --reply-file la lee de
un archivo (- es stdin). --timeout devuelve el status timeout si no llega nada
a tiempo. Correlo de nuevo después de cada respuesta. Ver la skill forum para el formato
exacto de la salida.

forum poll --all escucha todas las sesiones abiertas a la vez, así que un solo
poll cubre varias ventanas de revisión. Cada llamada entrega el feedback de una
sesión (la que lleva más tiempo esperando) y la nombra en la salida (session y
file); other_sessions_pending dice cuántas más están esperando, y la siguiente
llamada las entrega. Una sesión que termina mientras espera se informa una vez
como ended, y no_sessions significa que no hay nada abierto. Las sesiones que
se abren mientras espera se suman. --reply-to nombra la sesión a la que
responde un --reply, ya que el poll en sí no tiene archivo.

La entrega se confirma, no se supone: un poll toma en lease sus prompts y el
comando los confirma una vez que se escribió su salida. Si un poll muere antes,
volver a correr poll entrega otra vez los mismos prompts, marcados como
redelivered, así que no se pierde nada; salteá cualquier uid que ya hayas
aplicado.

forum <html-file> corrido dentro de un proyecto de vexillum también registra
ese proyecto como el dueño de la sesión y se asegura de que el listener de
forum esté corriendo. El listener es un proceso pequeño en segundo plano (sin
modelo, sin nada que pueda decidir) que sostiene el poll por vos: cada prompt
que envía el usuario se escribe en el inbox durable del proyecto, el hook Stop
despierta al commander con una línea "forum session <file>: N new messages", y
el navegador muestra la ronda como retransmitida (con el tiempo transcurrido, y
una nota cuando no se conoce ninguna sesión del commander) hasta que haya una
respuesta real, un cambio del artefacto o el Stop waiting del usuario. Una
sesión abierta fuera de cualquier proyecto no tiene commander al que despertar:
el listener la deja en paz, y forum poll funciona para ella como antes. El
listener sale solo cuando no hay ninguna sesión abierta o todas las ventanas de
revisión desaparecieron.

forum inbox imprime los prompts sin leer de este proyecto (correlo desde el
proyecto) en el formato de salida del poll, acotado en tamaño, con los
adjuntos solo por ruta. No marca nada como leído: forum inbox --ack <uid>...
confirma los uids que manejaste (los que se imprimieron), y un prompt sin
confirmar se muestra de nuevo. forum reply publica la respuesta en markdown del
agente (--reply, o --reply-file; - es stdin) en el panel de revisión y responde
la ronda sin bloquear, así que un commander que no hace poll puede responder.

forum end termina la sesión como el agente (un forum <html-file> a secas la
reabre después). forum stop detiene el listener y el servidor en segundo plano.