Ogni issue tracker che hai usato segue lo stesso schema. C'e un servizio cloud. Ha una UI web. Qualcuno costruisce una CLI che parla con l'API del cloud. La CLI e un cittadino di seconda classe: piu 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 e cio 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 e quella CLI. E 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 qui. bd create impiega circa 15ms. bd list su 10.000 issue restituisce 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.

Perche Dolt e non SQLite?

Dolt e un database SQL che implementa la semantica Git. Ogni scrittura e un commit. Ottieni dolt diff per vedere cosa e 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 gia 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?" controllando quel punto nella cronologia Dolt. Puoi fare branch del tuo database issue per sperimentare con una riorganizzazione, poi fare merge o buttarlo via.

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

La collaborazione opzionale funziona tramite DoltHub. Pusha il tuo database issue verso un remoto, 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 e un'applicazione desktop nativa costruita con Tauri (non Electron) che legge la stessa directory .beads/ su cui scrive la CLI. Non c'e 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 appare 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/priorita/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 "lasciami fare refresh."

Beadbox funziona su macOS, Linux e Windows. Supporta workspace multipli, cosi 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 remoto. Internet va giu? Non cambia nulla. Continui a lavorare.

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

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

Confronta questo 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 l'esecuzione di un servizio web.

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

Per chi e

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

Se gestisci progetti da solo e vuoi issue tracking versionato che vive accanto al tuo codice, senza un 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, questo non e lo strumento giusto. beads e local-first per design. E 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 e gratis durante la beta.