Alternativas ao Linear: por que o issue tracking local-first é mais rápido do que você imagina

Profundidade de integração Git: além de vincular commits a issues

A maioria dos issue trackers trata a integração com Git como uma caixa de seleção: mencione um ID de issue em uma mensagem de commit e um link aparece no issue. É útil mas superficial.

Beadbox é construído sobre o beads, um issue tracker onde a semântica Git é a camada de armazenamento, não uma integração adicionada. O Dolt, o banco de dados por baixo, implementa o modelo de dados em árvore de Merkle do Git para dados estruturados. Cada mudança de issue é um commit. Cada commit tem um pai. Você obtém dolt diff, dolt log e dolt merge no seu histórico de issues com a mesma semântica que usa no código.

O que isso significa na prática:

Seu histórico de issues é auditável. O próprio banco é um grafo de commits. Você pode fazer diff entre dois pontos no tempo e ver exatamente quais campos mudaram em quais issues. Isso não é uma "feature de log de auditoria" adicionada por cima. O formato de armazenamento é a trilha de auditoria.

Branches funcionam em issues, não só em código. Dolt suporta branches nativamente. Você pode fazer branch no seu banco de issues para experimentar uma reorganização, depois mergear ou descartar.

Sincronização é push/pull, não chamadas de API. Colaboração multimáquina funciona como git push e git pull. Sem tokens de API, sem webhooks, sem fluxos OAuth. Aponte seu remote Dolt para um servidor (ou DoltHub) e faça push. A outra máquina faz pull.

Uma nota sobre conflitos: Dolt usa three-way merge, igual ao Git. Se duas pessoas editam campos diferentes no mesmo issue, o merge se resolve automaticamente. Se duas pessoas editam o mesmo campo no mesmo issue, você obtém um conflito que requer resolução manual pelo CLI do Dolt (dolt conflicts resolve). Beadbox ainda não tem UI de resolução de conflitos; você lida com conflitos no nível dolt. Na prática, conflitos são raros quando cada pessoa (ou agente) trabalha em issues distintos, que é o padrão típico. Mas se sua equipe edita frequentemente os mesmos issues de forma concorrente, este é um ponto de fricção que vale conhecer. A documentação de merge do Dolt cobre o workflow de resolução em detalhe.

Renderização nativa: por que incluímos Node.js dentro do Tauri

Linear roda em uma aba do navegador. Jira, Asana e todos os outros trackers SaaS também. Abas de navegador competem por memória, são suspensas pelo SO e renderizam através de um compositor que adiciona frames de latência.

Beadbox roda como uma aplicação de desktop nativa construída com Tauri. Apps Tauri são tipicamente pequenas (o runtime do Tauri em si são poucos megabytes) porque usam o WebView nativo do SO ao invés de incluir Chromium. Nosso bundle é maior que apps Tauri típicas com aproximadamente 160 MB, e é um tradeoff deliberado que vale explicar.

84 MB disso é um runtime Node.js embutido. Usamos uma arquitetura sidecar: Tauri lança um servidor Next.js como processo filho, que cuida de server-side rendering, server actions e a camada WebSocket para atualizações em tempo real. O WebView do Tauri aponta para esse servidor local. Escolhemos isso ao invés de um backend puro em Rust porque o ecossistema Next.js nos dá React Server Components, server actions e velocidade de iteração rápida na camada de UI. O custo é o tamanho do bundle. Uma app Electron equivalente pesaria 400 MB+. Uma app pura Rust + Tauri pesaria menos de 10 MB mas teria levado 3x mais tempo para construir e perderia o ecossistema React.

A diferença prática em relação a uma aba de navegador: Beadbox renderiza em um processo WebView dedicado que não compartilha memória com suas outras 47 abas. Expandir uma árvore épica com 100+ issues aninhados, aplicar filtros em todo o backlog, trocar entre workspaces: essas operações se sentem qualitativamente diferentes quando o renderizador não compete por recursos.

Extensão com o CLI, não uma API REST

Linear tem uma API GraphQL. É bem projetada. Mas estender Linear significa escrever código que fala com os servidores deles, se autentica com os tokens deles e lida com os limites de rate deles.

Beadbox adota uma abordagem diferente: o CLI bd é a API. Cada operação que a GUI realiza passa pelo bd, a mesma ferramenta de linha de comando que você usaria no seu terminal.

Aqui estão três workflows que você pode copiar e colar hoje:

Atualização em massa de prioridades para um barrido de triagem:

# Colocar todos os bugs abertos em prioridade 1 (crítica)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Gerar um resumo diário de status:

# O que mudou nas últimas 24 horas?
echo "=== Closed today ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Currently blocked ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (blocked by: \(.blocked_by | join(", ")))"'

echo "=== Ready to work ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

Agente IA cria e reivindica trabalho:

# O agente descobre um bug, registra e reivindica
ISSUE_ID=$(bd create \
  --title "Fix race condition in auth middleware" \
  --type bug \
  --priority 1 \
  --json | jq -r '.id')

bd update "$ISSUE_ID" --status=in_progress --assignee=agent-3

# ... o agente faz o trabalho ...

bd update "$ISSUE_ID" --status=closed
bd comments add "$ISSUE_ID" --author agent-3 \
  "Fixed in commit abc1234. Root cause: mutex not held during token refresh."

Se você roda agentes IA de programação (Claude Code, Cursor, Copilot Workspace), eles já sabem executar comandos CLI. Sem biblioteca cliente, sem dança de autenticação. Apenas pipes Unix e scripts shell.

Experimente o Beadbox para ver esses workflows visualizados em tempo real enquanto os agentes os executam.

Offline-first não é uma feature, é uma arquitetura

Alguns trackers cloud oferecem um "modo offline" que faz cache de dados recentes e sincroniza ao reconectar. É uma feature adicionada a uma arquitetura fundamentalmente online. Os modos de falha são previsíveis: cache desatualizado, conflitos de sincronização, operações que se empilham em silêncio e falham depois.

Beadbox funciona offline porque nunca esteve online. Em modo embutido, todo o seu banco de issues é um diretório no seu sistema de arquivos. Sem processo de servidor. Sem daemon. Sem socket de rede. O CLI bd lê e escreve nesse diretório. Beadbox o monitora com fs.watch() e renderiza o que encontra.

Não há nada para sincronizar porque não há nada remoto. Se depois você decidir colaborar, o push/pull do Dolt oferece sincronização explícita e visível. Mas o padrão é local. O padrão é seu.

E quanto à segurança? Se você está avaliando Beadbox para ambientes air-gapped ou sensíveis, aqui está a postura concreta:

• Criptografia em repouso: Beadbox não criptografa o diretório .beads/ por conta própria. Depende da criptografia a nível de SO (FileVault no macOS, LUKS no Linux, BitLocker no Windows). Se seu modelo de ameaça exige criptografia por banco de dados, esta é uma lacuna.
• Backups: Seu diretório .beads/ é um diretório normal. cp -r, rsync, Time Machine ou dolt push para um remoto funcionam. O histórico de commits do Dolt também permite reverter mudanças acidentais com dolt reset.
• O que sai da máquina: Em modo embutido, nada. Zero chamadas de rede. Na app de desktop, existem duas conexões de saída opcionais: API do GitHub para verificar atualizações do Beadbox (pode ser desativada nos ajustes), e analytics PostHog se você aceitar (desativada por padrão, sem PII coletado). Nenhuma transmite dados de issues.

Para ambientes air-gapped, projetos classificados ou desenvolvedores que trabalham em aviões e trens, isso não é um bônus. É a única arquitetura que funciona.

Sem a armadilha do preço por assento

Linear cobra $8/month por membro no plano Standard. Razoável para um time de cinco pessoas. Menos razoável quando seu "time" inclui 13 agentes IA que precisam ler e escrever issues.

O modelo por assento assume times estáveis e de tamanho humano. Engenharia agêntica quebra essa premissa. Você pode subir 3 agentes para um bugfix e 13 para um release. Cada um precisa de acesso à API. Em preços SaaS, cada agente é um assento. Cada assento é uma linha na fatura. O custo escala linearmente com um recurso que você está escalando exponencialmente.

beads é open-source. O CLI é gratuito. Sem taxa por assento, sem tiers de uso, sem "entre em contato com vendas para enterprise." Você pode rodar 2 agentes ou 200 contra o mesmo banco de dados local e o custo não muda.

Beadbox (a GUI) é gratuito durante a beta. O preço pós-beta ainda não foi definido, mas não será por assento. Agentes não são pessoas. Cobrar por agente faz tanto sentido quanto cobrar por janela de terminal.

Ecossistema open-source

beads não é um jardim murado. O CLI é open-source em github.com/steveyegge/beads, e a comunidade construiu 30+ ferramentas sobre ele: geradores de relatório personalizados, integrações CI, scripts de orquestração de agentes, extensões de dashboard e adaptadores de exportação.

O que isso significa na prática:

Você pode inspecionar tudo. O formato de armazenamento é Dolt, consultável com SQL padrão. O código fonte do CLI é Go, legível e bifurcável. Se bd create faz algo inesperado, você pode ler o código que o executa.

Você pode estender sem pedir permissão. Sem processo de aprovação de marketplace, sem programa de parceiros, sem negociação de limites de API. Escreva um script shell, um plugin Go ou um wrapper Python. A flag --json do CLI em cada comando dá saída estruturada para canalizar para o que você construir.

Seus dados são portáveis. O push/pull do Dolt permite que seu banco de issues viva em qualquer servidor que você controle, sincronize com DoltHub, ou fique no seu sistema de arquivos para sempre. Não há wizard de exportação porque não há nada de onde exportar. Os dados já são seus, em um formato que você pode consultar diretamente.

A comunidade constrói ferramentas específicas para agentes. Os desenvolvedores que usam beads diariamente são os que rodam frotas de agentes IA. As extensões que constroem resolvem problemas de coordenação de agentes: operações batch, scripts de resolução de dependências, geradores de status de frota. Não é engajamento comunitário teórico. São profissionais construindo ferramentas para seus próprios workflows e publicando-as.

Coordenação orientada a agentes

A maioria dos issue trackers trata "automação" como um webhook que dispara quando um humano muda um status. Isso é adaptar uma API a um workflow feito para humanos. beads e Beadbox foram projetados desde o início para coordenação de agentes IA.

Identidade estruturada de agentes. Cada agente tem um arquivo CLAUDE.md que define seu papel, limites e protocolo de comunicação. As flags --actor e --author do CLI bd vinculam cada ação a um agente específico. Quando eng2 assume uma tarefa e publica um plano, o sistema sabe que foi eng2, não uma "automação" genérica.

O comando bd prime. Rode bd prime em qualquer workspace e ele produz um bloco de contexto projetado para assistentes de codificação IA. Cole no prompt de sistema do seu agente e ele conhecerá o conjunto completo de comandos, formatos de saída e padrões de workflow. Ensinar um novo agente a usar beads leva um comando, não uma página de documentação.

Grafos de dependência que agentes realmente usam. Agentes não trabalham com quadros Kanban. Trabalham com árvores e bloqueadores. beads rastreia relações pai/filho e dependências de bloqueio nativamente. bd blocked mostra cada bead esperando algo. bd ready mostra tudo que está desbloqueado e pronto. Beadbox renderiza isso como uma árvore de dependências interativa onde você vê de relance o que está travado e por quê.

Visibilidade de frota em tempo real. Beadbox monitora o banco de dados beads e atualiza a UI em segundos. O Activity Dashboard mostra cards de status de agentes (quem está ativo, quem silencioso, quem travado), um fluxo de pipeline (onde o trabalho se acumula) e um feed de eventos com filtro cruzado (clique em um agente para ver apenas suas ações). Esta é a visão de "centro de missão" que torna gerenciáveis 13 agentes em paralelo.

Escolhendo a ferramenta certa para sua equipe

Nenhuma ferramenta é universalmente correta. Aqui está uma análise honesta:

Escolha Linear se:

• Sua equipe tem 10+ pessoas e precisa de gestão de projetos centralizada
• Você depende de integrações com Slack/GitHub/Figma
• Stakeholders não técnicos precisam acessar seu issue tracker
• Você quer infraestrutura gerenciada com zero overhead operacional
• Você é um time de produto entregando em ciclos regulares

Escolha Beadbox se:

• Você valoriza soberania de dados (issues nunca saem da sua máquina)
• Você trabalha offline regularmente ou em ambientes de rede restrita
• Você gerencia agentes IA que precisam ler e escrever issues programaticamente
• Você quer histórico de issues Git-native (branch, diff, merge nos seus issues)
• Você prefere workflows CLI-first com um complemento visual quando necessário
• Você é desenvolvedor solo ou equipe pequena (1-10) que não precisa de features enterprise

Mantenha sua ferramenta atual se:

• O custo de troca excede a fricção que você experimenta
• Sua equipe investiu em integrações que dependem da API do seu tracker atual
• Seu workflow já se encaixa nas opiniões da sua ferramenta

Migrando do Linear (ou outros trackers)

Sejamos diretos: não existe ferramenta automatizada de migração do Linear para o Beadbox hoje. Sem wizard de importação CSV, sem ponte API, sem UI de mapeamento de status.

Se você está começando do zero, perfeito. bd init, comece a criar issues, e o Beadbox os vê imediatamente. Fricção zero.

Se você tem um projeto Linear existente que quer trazer, o caminho viável agora é por script: exporte da API do Linear (eles suportam exportação CSV e por API), transforme os dados, e use bd create em loop para recriar os issues. Você perderá metadados específicos do Linear (ciclos, views de projeto, timers de SLA) mas preservará títulos, descrições, prioridades e status. Um script de migração é um projeto de fim de semana, não uma integração de um trimestre.

Sabemos que isso não é suficiente para equipes com milhares de issues e anos de histórico. Construir um pipeline de importação adequado está no nosso roadmap mas ainda não foi entregue. Se a fricção de migração é sua preocupação principal, espere até que tenhamos construído, ou avalie se começar do zero é aceitável para seu caso de uso.

Começando

Beadbox é gratuito durante a beta. Instale com Homebrew:

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

Se você já usa beads, Beadbox detecta seus workspaces .beads/ existentes automaticamente. Abra a app e seus issues estão lá. Sem passo de importação. Sem criação de conta.

Se você é novo no beads, Beadbox guia você na inicialização do seu primeiro workspace. Você estará vendo seus issues em menos de 60 segundos.

Baixe o Beadbox ou confira o beads para ver se o issue tracking local-first combina com seu workflow.