Cada issue tracker que você já usou segue o mesmo padrão. Há um serviço cloud. Tem uma interface web. Alguém constrói um CLI que fala com a API do cloud. O CLI é um cidadão de segunda classe: mais lento, menos capaz, sempre uma versão de API atrasado.

Agora inverta essa arquitetura. Comece pelo CLI. Faça-o escrever em um banco de dados local. Faça o banco ter controle de versão, com a mesma semântica de branching e merging que você usa no código fonte. Depois coloque uma app de desktop nativa por cima que leia os mesmos arquivos do banco diretamente, sem API no caminho.

É isso que beads e Beadbox fazem. E a razão pela qual essa arquitetura existe são os agentes IA.

O problema: agentes não conseguem clicar em botões

Se você coordena uma frota de agentes IA (geradores de código, revisores, testadores, deployers), precisa que eles criem issues, atualizem status e leiam filas de trabalho. Eles não conseguem se autenticar no Jira. Não conseguem navegar na UI do Linear. Precisam de um CLI que escreva em um banco de dados local, rápido, com zero dependências de rede.

beads é esse CLI. É um issue tracker open-source, Git-native, projetado exatamente para este workflow. O comando bd cria, atualiza, lista e fecha issues. Cada escrita cai em um banco de dados local Dolt dentro do diretório .beads/ do seu repositório.

Os números importam aqui. bd create leva aproximadamente 15 ms. bd list através de 10.000 issues retorna em cerca de 200 ms. Esses benchmarks vêm da suite de testes do beads. Quando agentes processam itens de trabalho em loops apertados, os milissegundos por operação determinam se seu issue tracker acompanha ou se torna o gargalo.

Por que Dolt, não SQLite?

Dolt é um banco de dados SQL que implementa semântica Git. Cada escrita é um commit. Você tem dolt diff para ver o que mudou entre dois pontos. Tem dolt log para histórico de auditoria completo. Tem dolt branch e dolt merge com o mesmo modelo mental que já usa no código.

Para issue tracking, isso significa que o histórico do seu projeto tem duas trilhas de auditoria paralelas: git log para mudanças de código, dolt log para mudanças de issues. Você pode responder perguntas como "como era o banco de issues quando tageamos v2.1.0?" fazendo checkout desse ponto no histórico do Dolt. Pode fazer branch no seu banco de issues para experimentar uma reorganização, depois mergear ou descartar.

beads removeu o suporte a SQLite na v0.9.0 e apostou tudo no Dolt. A semântica de controle de versão não é um bônus; é o alicerce. Quando vinte agentes escrevem no mesmo banco de issues, você quer a capacidade de fazer diff, branch e merge nesses dados com a mesma confiança que tem no seu controle de código fonte.

A colaboração opcional funciona via DoltHub. Faça push do seu banco de issues para um remoto, seus colegas fazem pull. O mesmo workflow push/pull do Git, aplicado a dados estruturados.

A camada visual: Beadbox

Agentes prosperam com CLIs. Humanos não, pelo menos não quando precisam da visão geral. Grafos de dependências, árvores de progresso de épicas, cadeias de issues bloqueados: são problemas espaciais que um terminal não consegue renderizar bem.

Beadbox é uma aplicação de desktop nativa construída com Tauri (não Electron) que lê o mesmo diretório .beads/ no qual o CLI escreve. Sem passo de importação, sem processo de sincronização, sem camada de API. A GUI monitora o sistema de arquivos via fs.watch(), detecta mudanças no banco Dolt e transmite atualizações por um WebSocket local. Quando um agente executa bd update BEAD-42 --status in_progress, o badge de status muda no Beadbox em milissegundos.

Assim se parece o workflow na prática:

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

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

# Um humano abre o Beadbox e vê o quadro completo:
# grafos de dependências, árvores épicas, filtros por status/prioridade/responsável
# Sem comandos. Apenas olhar.

# O agente termina e marca para revisão
bd update BEAD-42 --status ready_for_qa

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

Agentes escrevem pelo CLI. Humanos leem pela GUI. Ambos operam no mesmo banco Dolt local. Sem reconciliação, sem caches desatualizados, sem "deixa eu atualizar."

Beadbox roda em macOS, Linux e Windows. Suporta múltiplos workspaces, então você pode trocar entre projetos sem reiniciar.

O que "local-first" realmente significa

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

Sem conta. Você não se registra em nada. Instale o CLI, instale a app, aponte para um diretório. Pronto.

Sem dependência de nuvem. Tudo roda no seu sistema de arquivos. Seus dados nunca saem da sua máquina a menos que você explicitamente faça dolt push para um remoto. A internet caiu? Nada muda. Você continua trabalhando.

Sem servidor. Não há daemon para gerenciar, não há container Docker para rodar. O banco Dolt é um diretório de arquivos. O CLI lê e escreve nesses arquivos. Beadbox monitora esses arquivos.

Colaboração opcional. Quando você quer compartilhar, faça push para o DoltHub. Seus colegas fazem pull. Conflitos de merge em dados de issues se resolvem da mesma forma que no código. Mas é opt-in, não obrigatório.

Compare com as alternativas. Jira precisa de um servidor (ou Atlassian Cloud). Linear precisa de conta e conexão com a internet. GitHub Issues precisa de um repositório nos servidores do GitHub. Mesmo opções self-hosted como Gitea exigem rodar um serviço web.

beads precisa de um diretório. Beadbox precisa desse mesmo diretório e um duplo clique.

Para quem é isso

Se você roda agentes IA que precisam se coordenar através de uma fila de trabalho compartilhada, e quer que humanos monitorem e direcionem esse trabalho visualmente, este stack foi construído para seu workflow.

Se você gerencia projetos solo e quer issue tracking com controle de versão que viva junto ao seu código, sem conta cloud, este stack também funciona.

Se você precisa do modelo de permissões enterprise do Jira ou da edição colaborativa em tempo real do Linear com equipe distribuída, esta não é a ferramenta certa. beads é local-first por design. É um tradeoff, não um descuido.

Começar

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

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

Inicialize um banco beads em qualquer projeto:

cd your-project
bd init

Abra o Beadbox, aponte para o diretório, e você está vendo seu quadro de issues. Sem cadastro. Sem wizard de configuração. Sem modal de "conecte sua conta do GitHub."

Beadbox é gratuito durante a beta.