Crei un'epic con 15 sotto-task. Li assegni a un pugno di agenti o colleghi. Due giorni dopo, qualcuno chiede: "A che punto e il refactoring dell'autenticazione?"

Esegui bd show bb-r4f. Ottieni l'epic stessa. Titolo, descrizione, priorita. Non ti dice quanti figli sono completati. Cosi esegui bd list --parent bb-r4f. Ottieni una lista piatta di ID e titoli. Per vedere lo stato di ciascuno, fai pipe attraverso jq o esegui bd show su ogni figlio individualmente. Alcuni di quei figli hanno i propri sotto-task. Ora sei a tre livelli di profondita, a ricostruire un albero nella tua testa dall'output del terminale.

Funziona quando un'epic ha tre figli. Crolla a dieci. E se stai coordinando agenti AI che creano sotto-task, segnalano blocchi e chiudono issue in rapida successione, l'output della CLI diventa stantio tra il momento in cui esegui il comando e quello in cui finisci di leggerlo.

Il problema non e beads. La CLI di beads e eccellente per la gestione strutturata e scriptabile delle issue. Il problema e che l'avanzamento gerarchico e un concetto visuale, e i terminali renderizzano testo in righe.

Come appare un albero epic in Beadbox

Apri Beadbox, clicca su un'epic e vedi i suoi figli in un albero comprimibile. Ogni figlio mostra un badge di stato (open, in_progress, ready_for_qa, closed), un indicatore di priorita e l'assegnatario. L'epic stessa visualizza una barra di avanzamento: "9 su 14 completati (64%)." Quel numero si aggiorna man mano che i figli vengono chiusi.

Espandi un figlio che e a sua volta un'epic e vedi i suoi sotto-task annidati sotto. L'avanzamento del genitore aggrega da tutti i discendenti, non solo dai figli diretti. Un'epic a tre livelli con 40 issue totali tra engineering, QA e documentazione ti mostra la percentuale reale di completamento in cima, tenendo conto di ogni nodo foglia nell'albero.

Le issue bloccate ricevono un trattamento visivo distinto. Se bb-m3q dipende da bb-k7p e bb-k7p e ancora aperta, il badge bloccato appare accanto allo stato di bb-m3q. Non hai bisogno di eseguire bd dep list per scoprire il collo di bottiglia. E visibile nell'albero, al livello in cui conta.

Confronta con il workflow CLI. Per rispondere a "cosa blocca l'avanzamento dell'epic di autenticazione", dovresti eseguire:

bd list --parent bb-r4f --status=open --json | \
  jq -r '.[].id' | \
  xargs -I{} bd show {} --json 2>/dev/null | \
  jq -r 'select(.blocked_by | length > 0) | "\(.id) blocked by \(.blocked_by | join(", "))"'

Questa e una pipeline perfettamente valida. Restituisce la risposta corretta. Ma devi scriverla, ricordare i flag e ri-eseguirla ogni volta che vuoi un aggiornamento. In Beadbox, la stessa informazione e sempre visibile nell'albero. Nessuna query necessaria.

Aggiornamenti in tempo reale: l'albero cambia mentre lo guardi

Qui il modello visuale dimostra il suo valore. Quando un agente esegue bd update bb-k7p --status=closed in un terminale, Beadbox intercetta la modifica del filesystem in pochi millisecondi. Il server WebSocket rileva la scrittura nella directory .beads/, invia la modifica e la UI React si ri-renderizza.

Nell'albero epic, appare cosi: bb-k7p passa da un badge arancione "in_progress" a un badge verde "closed". La barra di avanzamento dell'epic genitore passa dal 64% al 71%. E bb-m3q, che era bloccata su bb-k7p, perde il suo indicatore di blocco e appare come lavoro disponibile.

Tutto questo succede senza che tu esegua un comando o clicchi un pulsante di refresh. Se supervisioni una flotta di agenti che lavorano attraverso un'epic di rilascio, guardi l'albero riempirsi man mano che i task vengono completati. I colli di bottiglia emergono nel momento in cui si formano perche i badge bloccati appaiono in tempo reale. I sotto-alberi in stallo (gruppi di issue che smettono di cambiare stato) diventano visivamente ovvi dopo qualche minuto di inattivita, in contrasto con il progresso costante altrove.

Il meccanismo sottostante e semplice. Beadbox esegue un server WebSocket che chiama fs.watch() sulla tua directory .beads/. Ogni scrittura al database attiva una trasmissione broadcast. L'hook lato client riceve il segnale e ri-esegue il fetch della server action pertinente. Nessun intervallo di polling, nessun refresh manuale. La latenza dal comando CLI all'aggiornamento della UI e tipicamente sotto il secondo.

Navigazione keyboard-first

Beadbox e un'app desktop per sviluppatori, e si comporta come tale. j e k muovono attraverso la lista delle issue (stile vim). Enter apre la issue selezionata nel pannello di dettaglio. / porta il focus sulla barra di ricerca. Escape chiude qualsiasi cosa tu abbia aperta. I tasti freccia espandono e comprimono i nodi dell'albero epic.

Puoi fare triage di un intero backlog senza toccare il mouse. Scendi nella lista con j, apri una issue per leggere la descrizione, premi Escape per chiudere, vai alla successiva. Se noti qualcosa che richiede un cambio di stato, passi comunque al terminale per le mutazioni (bd update). Beadbox e un'interfaccia orientata alla lettura per design. La CLI gestisce le scritture. La GUI gestisce la comprensione.

Questa separazione e intenzionale. Una GUI che cerca di sostituire la CLI per le scritture finisce per costruire form per ogni possibile combinazione di flag. Una GUI che si concentra sulla lettura e la navigazione puo ottimizzare per la cosa in cui i terminali sono peggiori: mostrare dati gerarchici e con riferimenti incrociati a colpo d'occhio.

Piu progetti, una sola finestra

Se lavori su piu di un codebase, ognuno con il proprio database .beads/, lo switcher di workspace di Beadbox gestisce la cosa. Un menu a tendina nell'header elenca ogni workspace rilevato. Cliccane uno (o trova il workspace con la ricerca /), e l'intera vista si ricarica dal database di quel progetto. Filtri e posizione di scorrimento persistono per workspace, cosi tornare indietro non ti fa perdere il segno.

Il rilevamento e automatico. Beadbox scansiona i workspace registrati nella configurazione di bd e le directory che contengono database .beads/. Aggiungi un nuovo progetto, inizializza beads al suo interno, e la prossima volta che apri Beadbox appare nel menu a tendina. Nessuna importazione, nessuna schermata di configurazione.

Per gli sviluppatori che mantengono diversi servizi, o per i team dove ogni agente lavora in un repository separato, questo trasforma Beadbox in un pannello unico su tutti i progetti attivi. L'alternativa sono piu finestre di terminale, ognuna che esegue bd list con un diverso percorso --db.

Cosa sostituisce

Beadbox non sostituisce la CLI. Se scrivi script per i tuoi workflow, fai pipe di bd list attraverso jq, o hai agenti che creano e chiudono issue programmaticamente, tutto quello continua a funzionare invariato. Beadbox legge lo stesso database su cui scrivono i tuoi script.

Cio che sostituisce e il carico mentale di ricostruire lo stato del progetto da output testuale piatto. Le domande a cui Beadbox risponde a colpo d'occhio, e a cui la CLI risponde solo tramite query composte:

A che punto e realmente questa epic?
Cosa e bloccato adesso, e da cosa?
Quali sotto-task non sono stati toccati da ore?
Gli agenti stanno facendo progressi, o si sono bloccati?

Sono domande visuali. Meritano risposte visuali.

Per iniziare

Beadbox e gratis durante la beta. Installa con Homebrew:

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

Se usi gia beads, Beadbox rileva i tuoi workspace .beads/ all'avvio. Nessuna importazione, nessun account. Apri l'app, espandi un'epic e guarda a che punto e davvero il tuo progetto.

Funziona su macOS, Linux e Windows.