Creas una épica con 15 subtareas. Las asignas entre un puñado de agentes o compañeros de equipo. Dos días después, alguien pregunta: "Qué tan avanzada está la reescritura del auth?"

Ejecutas bd show bb-r4f. Eso te da la épica en sí. Título, descripción, prioridad. No te dice cuántos hijos están completos. Así que ejecutas bd list --parent bb-r4f. Obtienes una lista plana de IDs y títulos. Para ver el estado de cada uno, pasas por jq o ejecutas bd show en cada hijo individualmente. Algunos de esos hijos tienen sus propias subtareas. Ahora estás tres niveles de profundidad, reconstruyendo un árbol en tu cabeza desde la salida de terminal.

Esto funciona cuando una épica tiene tres hijos. Se desmorona con diez. Y si estás coordinando agentes de IA que crean subtareas, reportan bloqueadores y cierran issues en rápida sucesión, la salida de la CLI se vuelve obsoleta entre el momento en que ejecutas el comando y el momento en que terminas de leerlo.

El problema no es beads. El CLI de beads es excelente para gestión de issues estructurada y scriptable. El problema es que el progreso jerárquico es un concepto visual, y las terminales renderizan texto en filas.

Cómo se ve un árbol de épica en Beadbox

Abre Beadbox, haz clic en una épica, y ves sus hijos en un árbol colapsable. Cada hijo muestra un badge de estado (open, in_progress, ready_for_qa, closed), un indicador de prioridad y el asignado. La épica misma muestra una barra de progreso: "9 de 14 completos (64%)." Ese número se actualiza cuando los hijos se cierran.

Expande un hijo que a su vez es una épica y ves sus subtareas anidadas debajo. El progreso del padre agrega de todos los descendientes, no solo de los hijos directos. Una épica de tres niveles con 40 issues totales entre ingeniería, QA y documentación te muestra el porcentaje real de completitud arriba, contando cada nodo hoja del árbol.

Los issues bloqueados obtienen un tratamiento visual distinto. Si bb-m3q depende de bb-k7p y bb-k7p aún está abierto, el badge de bloqueado aparece junto al estado de bb-m3q. No necesitas ejecutar bd dep list para descubrir el cuello de botella. Es visible en el árbol, al nivel donde importa.

Compara esto con el workflow de CLI. Para responder "qué está bloqueando el progreso de la épica de auth," ejecutarías:

bd list --parent bb-r4f --status=open --json | \
  jq -r '.[].id' | \
  xargs -I{} bd show {} --json 2>/dev/null | \
  jq -r 'select(.blocked_by | length > 0) | "\(.id) blocked by \(.blocked_by | join(", "))"'

Ese es un pipeline perfectamente válido. Retorna la respuesta correcta. Pero tienes que escribirlo, recordar los flags, y re-ejecutarlo cada vez que quieras una actualización. En Beadbox, la misma información siempre está visible en el árbol. Sin consulta requerida.

Actualizaciones en tiempo real: el árbol cambia mientras lo observas

Aquí es donde el modelo visual demuestra su valor. Cuando un agente ejecuta bd update bb-k7p --status=closed en una terminal, Beadbox capta el cambio en el sistema de archivos en milisegundos. El servidor WebSocket detecta la escritura en el directorio .beads/, difunde el cambio, y la UI React re-renderiza.

En el árbol de épica, eso se ve así: bb-k7p pasa de un badge naranja "in_progress" a un badge verde "closed". La barra de progreso de la épica padre sube de 64% a 71%. Y bb-m3q, que estaba bloqueado por bb-k7p, pierde su indicador de bloqueado y aparece como trabajo disponible.

Todo eso sucede sin que ejecutes un comando o hagas clic en un botón de refresh. Si estás supervisando una flota de agentes trabajando en una épica de release, observas el árbol llenarse mientras las tareas se completan. Los cuellos de botella emergen en el momento en que se forman porque los badges de bloqueado aparecen en tiempo real. Los subárboles estancados (clusters de issues que dejan de cambiar de estado) se vuelven visualmente obvios después de unos minutos de inactividad contra un fondo de progreso constante en otras partes.

El mecanismo subyacente es directo. Beadbox ejecuta un servidor WebSocket que llama a fs.watch() en tu directorio .beads/. Cada escritura de base de datos dispara una difusión. El hook del lado del cliente recibe la señal y re-obtiene la server action relevante. Sin intervalo de polling, sin refresh manual. La latencia desde el comando CLI hasta la actualización de UI es típicamente menor a un segundo.

Navegación keyboard-first

Beadbox es una app de escritorio para desarrolladores, y se comporta como tal. j y k se mueven por la lista de issues (estilo vim). Enter abre el issue seleccionado en el panel de detalle. / enfoca la barra de búsqueda. Escape cierra lo que tengas abierto. Las teclas de flecha expanden y colapsan nodos del árbol de épica.

Puedes hacer triaje de un backlog entero sin tocar el ratón. Baja por la lista con j, abre un issue para leer su descripción, presiona Escape para cerrar, pasa al siguiente. Si encuentras algo que necesita un cambio de estado, bajas a la terminal para mutaciones (bd update). Beadbox es una interfaz pesada en lectura por diseño. El CLI maneja escrituras. El GUI maneja comprensión.

Esta separación es intencional. Un GUI que intenta reemplazar el CLI para escrituras termina construyendo formularios para cada combinación posible de flags. Un GUI que se enfoca en lectura y navegación puede optimizar para lo que las terminales hacen peor: mostrar datos jerárquicos y con referencias cruzadas de un vistazo.

Múltiples proyectos, una ventana

Si trabajas en más de un codebase, cada uno con su propia base de datos .beads/, el selector de workspace de Beadbox lo maneja. Un dropdown en el header lista cada workspace detectado. Haz clic en uno (o encuentra el workspace con la búsqueda /), y toda la vista se recarga desde la base de datos de ese proyecto. Los filtros y la posición de scroll persisten por workspace, así que cambiar de vuelta no pierde tu lugar.

La detección es automática. Beadbox escanea workspaces registrados en la configuración de bd y directorios que contienen bases de datos .beads/. Agrega un nuevo proyecto, inicializa beads en él, y la próxima vez que abras Beadbox aparece en el dropdown. Sin importación, sin pantalla de configuración.

Para desarrolladores que mantienen varios servicios, o para equipos donde cada agente trabaja en un repositorio separado, esto convierte a Beadbox en un panel único a través de todos los proyectos activos. La alternativa es múltiples ventanas de terminal, cada una ejecutando bd list contra un path --db diferente.

Lo que esto reemplaza

Beadbox no reemplaza el CLI. Si scripteas tus workflows, pasas bd list por jq, o tienes agentes que crean y cierran issues programáticamente, todo eso sigue funcionando igual. Beadbox lee la misma base de datos en la que tus scripts escriben.

Lo que reemplaza es el overhead mental de reconstruir el estado del proyecto desde salida de texto plano. Las preguntas que Beadbox responde de un vistazo, y que el CLI responde solo a través de consultas compuestas:

Qué tan avanzada está esta épica, realmente?
Qué está bloqueado ahora mismo, y por qué?
Cuáles subtareas no se han tocado en horas?
Los agentes están progresando, o se estancaron?

Son preguntas visuales. Merecen respuestas visuales.

Para empezar

Beadbox es gratuito durante el beta. Instala con Homebrew:

brew tap beadbox/cask && brew install --cask beadbox

Si ya usas beads, Beadbox detecta tus workspaces .beads/ al iniciar. Sin importación, sin cuenta. Abre el app, expande una épica, y ve dónde está realmente tu proyecto.

Corre en macOS, Linux y Windows.