Todo issue tracker que voce ja usou segue o mesmo padrao. Existe um servico na nuvem. Ele tem uma interface web. Alguem constroi um CLI que conversa com a API na nuvem. O CLI e cidadao de segunda classe: mais lento, menos capaz, sempre uma versao de API atrasado.

Agora inverta essa arquitetura. Comece pelo CLI. Faca ele escrever em um banco de dados local. Faca o banco de dados ter controle de versao, com a mesma semantica de branching e merging que voce usa no codigo fonte. Depois coloque um app desktop nativo por cima que le os mesmos arquivos do banco de dados diretamente, sem API no meio.

Isso e o que beads e Beadbox fazem. E o motivo dessa arquitetura existir sao os agentes de IA.

O problema: agentes nao clicam em botoes

Se voce esta coordenando uma frota de agentes de IA (geradores de codigo, revisores, testadores, deployadores), precisa que eles criem issues, atualizem status e leiam filas de trabalho. Eles nao conseguem se autenticar no Jira. Nao conseguem navegar na interface do Linear. Eles precisam de um CLI que escreva em um banco de dados local, rapido, com zero dependencias de rede.

beads e esse CLI. E um issue tracker open-source e Git-native projetado exatamente para esse workflow. O comando bd cria, atualiza, lista e fecha issues. Cada escrita vai para um banco de dados Dolt local dentro do diretorio .beads/ do seu repositorio.

Os numeros importam aqui. bd create leva aproximadamente 15ms. bd list em 10.000 issues retorna em cerca de 200ms. Esses benchmarks vem da suite de testes do beads. Quando agentes estao processando itens de trabalho em loops rapidos, milissegundos por operacao determinam se seu issue tracker acompanha ou se torna o gargalo.

Por que Dolt e nao SQLite?

Dolt e um banco de dados SQL que implementa semantica Git. Cada escrita e um commit. Voce tem dolt diff para ver o que mudou entre dois pontos. Tem dolt log para historico de auditoria completo. Tem dolt branch e dolt merge com o mesmo modelo mental que voce ja usa no codigo.

Para issue tracking, isso significa que o historico do seu projeto tem duas trilhas de auditoria paralelas: git log para mudancas de codigo, dolt log para mudancas de issues. Voce pode responder perguntas como "como estava o banco de issues quando tagueamos v2.1.0?" fazendo checkout desse ponto no historico do Dolt. Voce pode criar uma branch do seu banco de issues para experimentar uma reorganizacao, depois mergear de volta ou descartar.

beads removeu suporte a SQLite na v0.9.0 e apostou tudo no Dolt. A semantica de controle de versao nao e um diferencial; e a fundacao. Quando vinte agentes estao escrevendo no mesmo banco de issues, voce quer a capacidade de fazer diff, branch e merge nesses dados com a mesma confianca que tem no seu controle de codigo fonte.

Colaboracao opcional funciona pelo DoltHub. Faca push do seu banco de issues para um remote, pull das mudancas dos colegas. Mesmo workflow de push/pull do Git, aplicado a dados estruturados.

A camada visual: Beadbox

Agentes prosperam com CLIs. Humanos nao, pelo menos nao quando precisam da visao geral. Grafos de dependencia, arvores de progresso de epics, cadeias de issues bloqueados: sao problemas espaciais que um terminal nao consegue renderizar bem.

Beadbox e uma aplicacao desktop nativa construida com Tauri (nao Electron) que le o mesmo diretorio .beads/ em que o CLI escreve. Nao tem etapa de importacao, processo de sincronizacao nem camada de API. A interface monitora o sistema de arquivos via fs.watch(), detecta mudancas no banco de dados Dolt e transmite atualizacoes por um WebSocket local. Quando um agente roda bd update BEAD-42 --status in_progress, o badge de status muda no Beadbox em milissegundos.

Veja como o workflow funciona na pratica:

# Um agente cria um issue
bd create --title "Migrate auth to OIDC" --type task --priority 1

# Outro agente reivindica
bd update BEAD-42 --claim --actor agent-3

# Um humano abre o Beadbox e ve o quadro completo:
# grafos de dependencia, arvores de epics, filtro por status/prioridade/responsavel
# Sem comandos necessarios. So olhe.

# O agente finaliza e marca para revisao
bd update BEAD-42 --status ready_for_qa

# Beadbox atualiza em tempo real. O agente de QA pega.

Agentes escrevem pela CLI. Humanos leem pela GUI. Ambos operam no mesmo banco de dados Dolt local. Sem reconciliacao, sem caches obsoletos, sem "deixa eu atualizar."

Beadbox roda em macOS, Linux e Windows. Suporta multiplos workspaces, entao voce pode trocar entre projetos sem reiniciar.

O que "local-first" realmente significa

O termo e usado demais. Veja o que significa concretamente para beads e Beadbox:

Sem conta. Voce nao se cadastra em nada. Instale o CLI, instale o app, aponte para um diretorio. Pronto.

Sem dependencia de nuvem. Tudo roda no seu sistema de arquivos. Seus dados nunca saem da sua maquina a menos que voce explicitamente faca dolt push para um remote. A internet caiu? Nada muda. Voce continua trabalhando.

Sem servidor. Nao tem daemon para gerenciar, nao tem container Docker para rodar. O banco de dados Dolt e um diretorio de arquivos. O CLI le e escreve nesses arquivos. O Beadbox monitora esses arquivos.

Colaboracao opcional. Quando voce quiser compartilhar, faca push para o DoltHub. Seus colegas fazem pull. Conflitos de merge em dados de issues se resolvem da mesma forma que no codigo. Mas isso e opt-in, nao obrigatorio.

Compare com as alternativas. Jira precisa de um servidor (ou Atlassian Cloud). Linear precisa de uma conta e conexao com internet. GitHub Issues precisa de um repositorio nos servidores do GitHub. Ate opcoes self-hosted como Gitea exigem rodar um servico web.

beads precisa de um diretorio. Beadbox precisa desse mesmo diretorio e um duplo clique.

Para quem e isso

Se voce roda agentes de IA que precisam se coordenar por uma fila de trabalho compartilhada, e quer que humanos monitorem e direcionem esse trabalho visualmente, essa stack foi construida para o seu workflow.

Se voce gerencia projetos solo e quer issue tracking versionado que viva junto ao seu codigo, sem conta na nuvem, essa stack tambem funciona.

Se voce precisa do modelo de permissoes enterprise do Jira ou da edicao colaborativa em tempo real do Linear em um time distribuido, essa nao e a ferramenta certa. beads e local-first por design. Isso e uma escolha, nao uma falha.

Comecando

Instale o CLI beads em github.com/steveyegge/beads, depois instale o Beadbox:

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

Inicialize um banco de dados beads em qualquer projeto:

cd your-project
bd init

Abra o Beadbox, aponte para o diretorio e voce esta olhando para seu quadro de issues. Sem cadastro. Sem assistente de configuracao. Sem modal "conecte sua conta do GitHub".

Beadbox e gratuito durante o beta.