Creas un epic con 15 subtareas. Las asignas a un punado de agentes o companeros de equipo. Dos dias despues, alguien pregunta: "Como va la reescritura de autenticacion?"

Ejecutas bd show bb-r4f. Eso te da el epic en si. Titulo, descripcion, prioridad. No te dice cuantos hijos estan completos. Asi que ejecutas bd list --parent bb-r4f. Obtienes una lista plana de IDs y titulos. Para ver el estado de cada uno, lo pasas por jq o ejecutas bd show en cada hijo individualmente. Algunos de esos hijos tienen sus propias subtareas. Ahora estas tres niveles de profundidad, reconstruyendo un arbol en tu cabeza a partir del output de la terminal.

Esto funciona cuando un epic tiene tres hijos. Se desmorona con diez. Y si estas coordinando agentes de IA que crean subtareas, registran bloqueadores y cierran issues en rapida sucesion, el output del CLI queda obsoleto entre el momento en que ejecutas el comando y terminas de leerlo.

El problema no es beads. El CLI de beads es excelente para la gestion de issues estructurada y scriptable. El problema es que el progreso jerarquico es un concepto visual, y las terminales renderizan texto en filas.

Como se ve un arbol de epic en Beadbox

Abre Beadbox, haz clic en un epic y veras sus hijos en un arbol colapsable. Cada hijo muestra un badge de estado (open, in_progress, ready_for_qa, closed), un indicador de prioridad y el asignado. El epic en si muestra una barra de progreso: "9 de 14 completos (64%)." Ese numero se actualiza a medida que los hijos se cierran.

Expande un hijo que a su vez es un epic y veras sus subtareas anidadas debajo. El progreso del padre se agrega de todos los descendientes, no solo de los hijos directos. Un epic de tres niveles con 40 issues totales entre ingenieria, QA y documentacion te muestra el porcentaje real de finalizacion en la parte superior, contando cada nodo hoja del arbol.

Los issues bloqueados reciben un tratamiento visual distinto. Si bb-m3q depende de bb-k7p y bb-k7p aun esta 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 arbol, al nivel donde importa.

Compara esto con el flujo de trabajo del CLI. Para responder "que esta bloqueando el progreso del epic de autenticacion," ejecutarias:

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 valido. Devuelve la respuesta correcta. Pero tienes que escribirlo, recordar los flags y re-ejecutarlo cada vez que quieras una actualizacion. En Beadbox, la misma informacion siempre esta visible en el arbol. Sin consulta necesaria.

Actualizaciones en tiempo real: el arbol cambia mientras lo miras

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

En el arbol de epic, eso se ve asi: bb-k7p cambia de un badge naranja "in_progress" a un badge verde "closed". La barra de progreso del epic padre pasa del 64% al 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 ni hagas clic en un boton de actualizar. Si estas supervisando una flota de agentes trabajando en un epic de release, observas como el arbol se llena a medida que las tareas se completan. Los cuellos de botella aparecen en el momento en que se forman porque los badges de bloqueo aparecen en tiempo real. Los subarboles estancados (grupos de issues que dejan de cambiar de estado) se vuelven visualmente obvios despues de unos minutos de inactividad contra un fondo de progreso constante en otros lugares.

El mecanismo subyacente es directo. Beadbox ejecuta un servidor WebSocket que llama a fs.watch() en tu directorio .beads/. Cada escritura en la base de datos dispara una transmision. El hook del lado del cliente recibe la senal y re-obtiene la server action relevante. Sin intervalo de polling, sin actualizacion manual. La latencia desde el comando CLI hasta la actualizacion de la interfaz es tipicamente menor a un segundo.

Navegacion con teclado primero

Beadbox es una app de escritorio para desarrolladores, y se comporta como tal. j y k mueven a traves de la lista de issues (estilo vim). Enter abre el issue seleccionado en el panel de detalle. / enfoca la barra de busqueda. Escape cierra lo que tengas abierto. Las flechas expanden y colapsan nodos del arbol de epic.

Puedes hacer triage de todo un backlog sin tocar el raton. Baja por la lista con j, abre un issue para leer su descripcion, presiona Escape para cerrar, ve al siguiente. Si detectas algo que necesita un cambio de estado, bajas a la terminal para las mutaciones (bd update). Beadbox es una interfaz de lectura intensiva por diseno. El CLI maneja las escrituras. La GUI maneja la comprension.

Esta division es intencional. Una GUI que intenta reemplazar al CLI para escrituras termina construyendo formularios para cada combinacion posible de flags. Una GUI que se enfoca en lectura y navegacion puede optimizarse para aquello en lo que las terminales son peores: mostrar datos jerarquicos y con referencias cruzadas de un vistazo.

Multiples proyectos, una ventana

Si trabajas en mas de un codebase, cada uno con su propia base de datos .beads/, el selector de workspace de Beadbox lo maneja. Un menu desplegable en el header lista cada workspace detectado. Haz clic en uno (o encuentra el workspace con la busqueda /), y toda la vista se recarga desde la base de datos de ese proyecto. Los filtros y la posicion de scroll persisten por workspace, asi que volver atras no pierde tu lugar.

La deteccion es automatica. Beadbox busca workspaces registrados en la configuracion de bd y directorios que contengan bases de datos .beads/. Agrega un nuevo proyecto, inicializa beads en el, y la proxima vez que abras Beadbox aparece en el menu desplegable. Sin importacion, sin pantalla de configuracion.

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

Lo que esto reemplaza

Beadbox no reemplaza al CLI. Si scripteas tus flujos de trabajo, pasas bd list por jq, o tienes agentes que crean y cierran issues programaticamente, todo eso sigue funcionando sin cambios. Beadbox lee la misma base de datos en la que escriben tus scripts.

Lo que reemplaza es la carga mental de reconstruir el estado del proyecto a partir de output de texto plano. Las preguntas que Beadbox responde de un vistazo, y que el CLI responde solo a traves de consultas compuestas:

Como va realmente este epic?
Que esta bloqueado ahora mismo, y por que?
Que subtareas no se han tocado en horas?
Estan los agentes avanzando, o se han estancado?

Estas son preguntas visuales. Merecen respuestas visuales.

Primeros pasos

Beadbox es gratis durante la beta. Instala con Homebrew:

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

Si ya usas beads, Beadbox detecta tus workspaces .beads/ al iniciar. Sin importacion, sin cuenta. Abre la app, expande un epic y ve donde realmente esta tu proyecto.

Funciona en macOS, Linux y Windows.