Voce cria um epic com 15 subtarefas. Distribui entre alguns agentes ou colegas. Dois dias depois, alguem pergunta: "Como esta a reescrita da autenticacao?"

Voce roda bd show bb-r4f. Isso retorna o epic em si. Titulo, descricao, prioridade. Nao diz quantos filhos estao completos. Entao voce roda bd list --parent bb-r4f. Recebe uma lista plana de IDs e titulos. Para ver o status de cada um, voce faz pipe por jq ou roda bd show em cada filho individualmente. Alguns desses filhos tem suas proprias subtarefas. Agora voce esta tres niveis abaixo, reconstruindo uma arvore na sua cabeca a partir da saida do terminal.

Isso funciona quando um epic tem tres filhos. Desmorona com dez. E se voce esta coordenando agentes de IA que criam subtarefas, registram bloqueadores e fecham issues em sucessao rapida, a saida da CLI fica obsoleta entre o momento em que voce roda o comando e o momento em que termina de ler.

O problema nao e o beads. O CLI beads e excelente para gerenciamento de issues estruturado e scriptavel. O problema e que progresso hierarquico e um conceito visual, e terminais renderizam texto em linhas.

Como uma arvore de epics aparece no Beadbox

Abra o Beadbox, clique em um epic e voce ve seus filhos em uma arvore colapsavel. Cada filho mostra um badge de status (open, in_progress, ready_for_qa, closed), um indicador de prioridade e o responsavel. O epic em si exibe uma barra de progresso: "9 de 14 completos (64%)." Esse numero atualiza conforme os filhos sao fechados.

Expanda um filho que e tambem um epic e voce ve suas subtarefas aninhadas abaixo. O progresso do pai agrega de todos os descendentes, nao apenas dos filhos diretos. Um epic de tres niveis com 40 issues no total entre engenharia, QA e documentacao mostra a porcentagem real de conclusao no topo, contabilizando cada no folha na arvore.

Issues bloqueados recebem um tratamento visual distinto. Se bb-m3q depende de bb-k7p e bb-k7p ainda esta aberto, o badge de bloqueado aparece ao lado do status de bb-m3q. Voce nao precisa rodar bd dep list para descobrir o gargalo. Ele esta visivel na arvore, no nivel onde importa.

Compare com o workflow da CLI. Para responder "o que esta bloqueando o progresso do epic de autenticacao", voce rodaria:

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(", "))"'

Esse pipeline e perfeitamente valido. Retorna a resposta certa. Mas voce precisa escreve-lo, lembrar das flags e re-executa-lo toda vez que quiser uma atualizacao. No Beadbox, a mesma informacao esta sempre visivel na arvore. Sem consulta necessaria.

Atualizacoes em tempo real: a arvore muda enquanto voce assiste

Aqui e onde o modelo visual mostra seu valor. Quando um agente roda bd update bb-k7p --status=closed no terminal, o Beadbox capta a mudanca no sistema de arquivos em milissegundos. O servidor WebSocket detecta a escrita no diretorio .beads/, transmite a mudanca e a UI React re-renderiza.

Na arvore de epics, isso aparece assim: bb-k7p troca de um badge laranja "in_progress" para um badge verde "closed". A barra de progresso do epic pai avanca de 64% para 71%. E bb-m3q, que estava bloqueado por bb-k7p, perde seu indicador de bloqueio e aparece como trabalho disponivel.

Tudo isso acontece sem voce rodar um comando ou clicar em um botao de refresh. Se voce esta supervisionando uma frota de agentes trabalhando em um epic de release, voce assiste a arvore preencher conforme tarefas sao concluidas. Gargalos aparecem no momento em que se formam porque badges de bloqueio surgem em tempo real. Sub-arvores paradas (grupos de issues que param de mudar de status) se tornam visualmente obvias apos alguns minutos de inatividade contra um fundo de progresso constante em outros lugares.

O mecanismo subjacente e direto. Beadbox roda um servidor WebSocket que chama fs.watch() no seu diretorio .beads/. Cada escrita no banco de dados dispara um broadcast. O hook do lado do cliente recebe o sinal e re-busca a server action relevante. Sem intervalo de polling, sem refresh manual. A latencia do comando CLI ate a atualizacao na UI e tipicamente inferior a um segundo.

Navegacao keyboard-first

Beadbox e um app desktop para desenvolvedores, e se comporta como tal. j e k movem pela lista de issues (estilo vim). Enter abre o issue selecionado no painel de detalhes. / foca na barra de busca. Escape fecha o que estiver aberto. Setas expandem e colapsam nos da arvore de epics.

Voce pode fazer triagem de todo um backlog sem tocar no mouse. Descer a lista com j, abrir um issue para ler sua descricao, pressionar Escape para fechar, ir para o proximo. Se encontrar algo que precisa de mudanca de status, voce vai para o terminal para mutacoes (bd update). Beadbox e uma interface focada em leitura por design. A CLI cuida das escritas. A GUI cuida da compreensao.

Essa divisao e intencional. Uma GUI que tenta substituir a CLI para escritas acaba construindo formularios para cada combinacao possivel de flags. Uma GUI que foca em leitura e navegacao pode otimizar para aquilo em que terminais sao piores: mostrar dados hierarquicos e com referencias cruzadas em um relance.

Multiplos projetos, uma janela

Se voce trabalha em mais de um codebase, cada um com seu proprio banco de dados .beads/, o seletor de workspace do Beadbox resolve isso. Um dropdown no cabecalho lista cada workspace detectado. Clique em um (ou encontre o workspace com a busca /) e toda a visualizacao recarrega a partir do banco de dados daquele projeto. Filtros e posicao de scroll persistem por workspace, entao voltar nao perde seu lugar.

A deteccao e automatica. Beadbox busca workspaces registrados na configuracao do bd e diretorios contendo bancos de dados .beads/. Adicione um novo projeto, inicialize beads nele, e na proxima vez que abrir o Beadbox ele aparece no dropdown. Sem importacao, sem tela de configuracao.

Para desenvolvedores que mantem varios servicos, ou para times onde cada agente trabalha em um repositorio separado, isso transforma o Beadbox em um painel unico para todos os projetos ativos. A alternativa sao multiplas janelas de terminal, cada uma rodando bd list contra um --db path diferente.

O que isso substitui

Beadbox nao substitui a CLI. Se voce scriptar seus workflows, fizer pipe de bd list por jq, ou tiver agentes que criam e fecham issues programaticamente, tudo continua funcionando sem mudancas. Beadbox le o mesmo banco de dados em que seus scripts escrevem.

O que ele substitui e a sobrecarga mental de reconstruir o estado do projeto a partir de saida de texto plano. As perguntas que o Beadbox responde com um olhar, e que a CLI so responde por consultas compostas:

Qual o progresso real deste epic?
O que esta bloqueado agora, e por que?
Quais subtarefas nao foram tocadas em horas?
Os agentes estao progredindo ou pararam?

Essas sao perguntas visuais. Merecem respostas visuais.

Comecando

Beadbox e gratuito durante o beta. Instale com Homebrew:

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

Se voce ja usa beads, o Beadbox detecta seus workspaces .beads/ ao iniciar. Sem importacao, sem conta. Abra o app, expanda um epic e veja onde seu projeto realmente esta.

Roda em macOS, Linux e Windows.