Ogni issue tracker che hai usato segue lo stesso schema. C'è un servizio cloud. Ha una UI web. Qualcuno costruisce una CLI che parla con l'API del cloud. La CLI è un cittadino di seconda classe: più lenta, meno capace, sempre una versione API indietro.

Ora capovolgi quell'architettura. Parti dalla CLI. Falla scrivere su un database locale. Rendi il database versionato, con la stessa semantica di branching e merging che usi sul codice sorgente. Poi mettici sopra un'app desktop nativa che legge gli stessi file del database direttamente, senza API in mezzo.

Questo è ciò che fanno beads e Beadbox. E il motivo per cui questa architettura esiste sono gli agenti AI.

Il problema: gli agenti non possono cliccare bottoni

Se stai coordinando una flotta di agenti AI (generatori di codice, revisori, tester, deployer), hai bisogno che creino issue, aggiornino stati e leggano code di lavoro. Non possono autenticarsi su Jira. Non possono navigare la UI di Linear. Hanno bisogno di una CLI che scriva su un database locale, veloce, con zero dipendenze di rete.

beads è quella CLI. È un issue tracker open-source, Git-native, progettato esattamente per questo workflow. Il comando bd crea, aggiorna, elenca e chiude issue. Ogni scrittura finisce in un database Dolt locale dentro la directory .beads/ del tuo repository.

I numeri contano. bd create impiega circa 15ms. bd list su 10.000 issue risponde in circa 200ms. Questi benchmark vengono dalla suite di test di beads. Quando gli agenti macinano work item in loop stretti, i millisecondi per operazione determinano se il tuo issue tracker tiene il passo o diventa il collo di bottiglia.

Perché Dolt e non SQLite?

Dolt è un database SQL che implementa la semantica Git. Ogni scrittura è un commit. Ottieni dolt diff per vedere cosa è cambiato tra due punti. Ottieni dolt log per la cronologia completa degli audit. Ottieni dolt branch e dolt merge con lo stesso modello mentale che usi già sul codice.

Per l'issue tracking, questo significa che la cronologia del tuo progetto ha due tracce di audit parallele: git log per le modifiche al codice, dolt log per le modifiche alle issue. Puoi rispondere a domande come "com'era il database delle issue quando abbiamo taggato la v2.1.0?" consultando quel punto nella cronologia Dolt. Puoi creare un branch del database issue per sperimentare con una riorganizzazione, poi fare merge o buttarlo via.

beads ha rimosso il supporto SQLite nella v0.9.0 e ha puntato tutto su Dolt. La semantica di version control non è un nice-to-have: è la base. Quando venti agenti scrivono sullo stesso database issue, vuoi la possibilità di fare diff, branch e merge di quei dati con la stessa sicurezza che hai nel tuo controllo di versione del codice.

La collaborazione opzionale funziona tramite DoltHub. Fai push del database issue verso un remote, i tuoi colleghi fanno pull. Stesso workflow push/pull di Git, applicato a dati strutturati.

Il livello visuale: Beadbox

Gli agenti prosperano con le CLI. Gli umani meno, almeno quando hanno bisogno del quadro d'insieme. Grafi delle dipendenze, alberi di avanzamento delle epic, catene di issue bloccate: sono problemi spaziali che un terminale non riesce a renderizzare bene.

Beadbox è un'applicazione desktop nativa costruita con Tauri (non Electron) che legge la stessa directory .beads/ su cui scrive la CLI. Non c'è nessun passaggio di importazione, nessun processo di sync, nessun livello API. La GUI monitora il filesystem tramite fs.watch(), rileva le modifiche al database Dolt e invia gli aggiornamenti tramite un WebSocket locale. Quando un agente esegue bd update BEAD-42 --status in_progress, il badge di stato cambia in Beadbox in pochi millisecondi.

Ecco come si presenta il workflow nella pratica:

# Un agente crea una issue
bd create --title "Migrate auth to OIDC" --type task --priority 1

# Un altro agente la prende in carico
bd update BEAD-42 --claim --actor agent-3

# Un umano apre Beadbox e vede l'intera board:
# grafi delle dipendenze, alberi delle epic, filtri per stato/priorità/assegnatario
# Nessun comando necessario. Basta guardare.

# L'agente finisce e la segna per la revisione
bd update BEAD-42 --status ready_for_qa

# Beadbox si aggiorna in tempo reale. L'agente QA la prende in carico.

Gli agenti scrivono tramite la CLI. Gli umani leggono tramite la GUI. Entrambi operano sullo stesso database Dolt locale. Nessuna riconciliazione, nessuna cache stantia, nessun "aspetta che faccio refresh."

Beadbox funziona su macOS, Linux e Windows. Supporta workspace multipli, così puoi passare da un progetto all'altro senza riavviare.

Cosa significa davvero "local-first"

Il termine viene abusato. Ecco cosa significa concretamente per beads e Beadbox:

Nessun account. Non ti registri a nulla. Installi la CLI, installi l'app, la punti a una directory. Fatto.

Nessuna dipendenza dal cloud. Tutto gira sul tuo filesystem. I tuoi dati non lasciano mai la tua macchina a meno che tu non faccia esplicitamente dolt push verso un remote. Cade internet? Non cambia nulla. Continui a lavorare.

Nessun server. Non c'è nessun daemon da gestire, nessun container Docker da avviare. Il database Dolt è una directory di file. La CLI legge e scrive quei file. Beadbox li monitora.

Collaborazione opzionale. Quando vuoi condividere, fai push su DoltHub. I tuoi colleghi fanno pull. I conflitti di merge sui dati delle issue si risolvono come quelli sul codice. Ma è opt-in, non obbligatorio.

Confronta con le alternative. Jira ha bisogno di un server (o Atlassian Cloud). Linear ha bisogno di un account e di una connessione internet. GitHub Issues ha bisogno di un repository sui server di GitHub. Anche le opzioni self-hosted come Gitea richiedono un servizio web in esecuzione.

beads ha bisogno di una directory. Beadbox ha bisogno della stessa directory e un doppio click.

Per chi è

Se gestisci agenti AI che devono coordinarsi tramite una coda di lavoro condivisa, e vuoi che gli umani monitorino e guidino quel lavoro visualmente, questo stack è stato costruito per il tuo workflow.

Se gestisci progetti da solo e vuoi issue tracking versionato che vive accanto al tuo codice, senza account cloud, questo stack funziona anche per quello.

Se hai bisogno del modello di permessi enterprise di Jira o dell'editing collaborativo in tempo reale di Linear su un team distribuito, non è lo strumento giusto. beads è local-first per design. È un compromesso, non una svista.

Per iniziare

Installa la CLI beads da github.com/steveyegge/beads, poi installa Beadbox:

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

Inizializza un database beads in qualsiasi progetto:

cd your-project
bd init

Apri Beadbox, puntalo alla directory e stai guardando la tua board delle issue. Nessuna registrazione. Nessun wizard di configurazione. Nessun modale "connetti il tuo account GitHub".

Beadbox è gratis durante la beta.