Sie erstellen ein Epic mit 15 Teilaufgaben. Sie verteilen sie auf eine Handvoll Agenten oder Teammitglieder. Zwei Tage spaeter fragt jemand: "Wie weit ist der Auth-Rewrite?"
Sie fuehren bd show bb-r4f aus. Das zeigt Ihnen das Epic selbst. Titel, Beschreibung, Prioritaet. Es sagt Ihnen nicht, wie viele Kinder abgeschlossen sind. Also fuehren Sie bd list --parent bb-r4f aus. Sie bekommen eine flache Liste von IDs und Titeln. Um den Status jedes einzelnen zu sehen, pipen Sie durch jq oder fuehren bd show fuer jedes Kind einzeln aus. Einige dieser Kinder haben eigene Teilaufgaben. Jetzt sind Sie drei Ebenen tief und rekonstruieren einen Baum aus Terminal-Ausgaben in Ihrem Kopf.
Das funktioniert, wenn ein Epic drei Kinder hat. Bei zehn bricht es zusammen. Und wenn Sie KI-Agenten koordinieren, die in schneller Folge Teilaufgaben erstellen, Blocker melden und Issues schliessen, ist die CLI-Ausgabe veraltet in der Zeit zwischen Befehlseingabe und fertigem Lesen.
Das Problem ist nicht beads. Die beads CLI eignet sich hervorragend fuer strukturiertes, scriptfaehiges Issue-Management. Das Problem ist, dass hierarchischer Fortschritt ein visuelles Konzept ist und Terminals Text in Zeilen rendern.
Wie ein Epic-Baum in Beadbox aussieht
Oeffnen Sie Beadbox, klicken Sie auf ein Epic und sehen Sie dessen Kinder in einem zusammenklappbaren Baum. Jedes Kind zeigt ein Status-Badge (open, in_progress, ready_for_qa, closed), einen Prioritaetsindikator und den Zustaendigen. Das Epic selbst zeigt einen Fortschrittsbalken: "9 von 14 abgeschlossen (64%)." Diese Zahl aktualisiert sich, wenn Kinder geschlossen werden.
Klappen Sie ein Kind auf, das selbst ein Epic ist, und Sie sehen seine Teilaufgaben darunter verschachtelt. Der Fortschritt des uebergeordneten Epics aggregiert ueber alle Nachfolger, nicht nur ueber direkte Kinder. Ein dreistufiges Epic mit 40 Issues insgesamt ueber Engineering, QA und Dokumentation zeigt Ihnen den tatsaechlichen Fertigstellungsgrad oben, unter Beruecksichtigung jedes Blattknotens im Baum.
Blockierte Issues erhalten eine deutliche visuelle Behandlung. Wenn bb-m3q von bb-k7p abhaengt und bb-k7p noch offen ist, steht das Blocked-Badge neben dem Status von bb-m3q. Sie muessen nicht bd dep list ausfuehren, um den Engpass zu entdecken. Er ist im Baum sichtbar, auf der Ebene, wo er relevant ist.
Vergleichen Sie das mit dem CLI-Workflow. Um "Was blockiert den Fortschritt beim Auth-Epic?" zu beantworten, wuerden Sie ausfuehren:
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(", "))"'
Das ist eine voellig gueltige Pipeline. Sie liefert die richtige Antwort. Aber Sie muessen sie schreiben, sich an die Flags erinnern und sie jedes Mal neu ausfuehren, wenn Sie ein Update wollen. In Beadbox ist dieselbe Information immer im Baum sichtbar. Keine Abfrage noetig.
Echtzeit-Updates: Der Baum aendert sich, waehrend Sie zuschauen
Hier zeigt das visuelle Modell seinen wahren Wert. Wenn ein Agent bd update bb-k7p --status=closed in einem Terminal ausfuehrt, erkennt Beadbox die Dateisystemaenderung innerhalb von Millisekunden. Der WebSocket-Server erkennt den Schreibvorgang im .beads/-Verzeichnis, sendet die Aenderung und die React-UI rendert neu.
Im Epic-Baum sieht das so aus: bb-k7p wechselt von einem orangenen "in_progress"-Badge zu einem gruenen "closed"-Badge. Der Fortschrittsbalken des uebergeordneten Epics steigt von 64% auf 71%. Und bb-m3q, das auf bb-k7p blockiert war, verliert seinen Blocked-Indikator und erscheint als verfuegbare Arbeit.
All das passiert, ohne dass Sie einen Befehl ausfuehren oder einen Refresh-Button klicken. Wenn Sie eine Flotte von Agenten beaufsichtigen, die durch ein Release-Epic arbeiten, beobachten Sie, wie sich der Baum fuellt, waehrend Aufgaben abgeschlossen werden. Engpaesse zeigen sich in dem Moment, in dem sie entstehen, weil Blocked-Badges in Echtzeit erscheinen. Stagnierte Teilbaeume (Cluster von Issues, die ihren Status nicht mehr aendern) werden nach einigen Minuten Inaktivitaet visuell offensichtlich, vor dem Hintergrund stetigen Fortschritts anderswo.
Der zugrunde liegende Mechanismus ist unkompliziert. Beadbox betreibt einen WebSocket-Server, der fs.watch() auf Ihrem .beads/-Verzeichnis aufruft. Jeder Datenbank-Schreibvorgang loest einen Broadcast aus. Der clientseitige Hook empfaengt das Signal und ruft die relevante Server Action erneut ab. Kein Polling-Intervall, kein manueller Refresh. Die Latenz vom CLI-Befehl zum UI-Update liegt typischerweise unter einer Sekunde.
Tastaturgesteuerte Navigation
Beadbox ist eine Desktop-App fuer Entwickler und verhaelt sich entsprechend. j und k bewegen sich durch die Issue-Liste (Vim-Stil). Enter oeffnet das ausgewaehlte Issue im Detail-Panel. / fokussiert die Suchleiste. Escape schliesst, was gerade offen ist. Pfeiltasten klappen Knoten im Epic-Baum auf und zu.
Sie koennen ein ganzes Backlog sichten, ohne die Maus zu beruehren. Bewegen Sie sich mit j durch die Liste, oeffnen Sie ein Issue, um seine Beschreibung zu lesen, druecken Sie Escape zum Schliessen, gehen Sie zum naechsten. Wenn Sie etwas entdecken, das eine Statusaenderung braucht, wechseln Sie fuer Mutationen in den Terminal (bd update). Beadbox ist von Grund auf eine leseintensive Oberflaeche. Die CLI uebernimmt Schreibvorgaenge. Die GUI uebernimmt das Verstaendnis.
Diese Trennung ist beabsichtigt. Eine GUI, die versucht, die CLI fuer Schreibvorgaenge zu ersetzen, baut am Ende Formulare fuer jede moegliche Flag-Kombination. Eine GUI, die sich auf Lesen und Navigation konzentriert, kann fuer das optimieren, worin Terminals am schlechtesten sind: hierarchische, quervernetzte Daten auf einen Blick zeigen.
Mehrere Projekte, ein Fenster
Wenn Sie an mehr als einer Codebasis arbeiten, jede mit ihrer eigenen .beads/-Datenbank, handhabt der Workspace-Switcher von Beadbox das. Ein Dropdown in der Kopfzeile listet jeden erkannten Workspace auf. Klicken Sie auf einen (oder finden Sie den Workspace mit /-Suche) und die gesamte Ansicht laedt aus der Datenbank dieses Projekts neu. Filter und Scroll-Position bleiben pro Workspace erhalten, sodass ein Zurueckwechseln Ihren Platz nicht verliert.
Die Erkennung ist automatisch. Beadbox scannt registrierte Workspaces in der bd-Konfiguration und Verzeichnisse mit .beads/-Datenbanken. Fuegen Sie ein neues Projekt hinzu, initialisieren Sie beads darin, und beim naechsten Oeffnen von Beadbox erscheint es im Dropdown. Kein Import, kein Konfigurationsbildschirm.
Fuer Entwickler, die mehrere Services pflegen, oder fuer Teams, in denen jeder Agent in einem separaten Repository arbeitet, macht dies Beadbox zu einer einzigen Ansicht ueber alle aktiven Projekte. Die Alternative sind mehrere Terminal-Fenster, die jeweils bd list gegen einen anderen --db-Pfad ausfuehren.
Was das ersetzt
Beadbox ersetzt nicht die CLI. Wenn Sie Ihre Workflows skripten, bd list durch jq pipen oder Agenten haben, die Issues programmatisch erstellen und schliessen, funktioniert das alles weiterhin unveraendert. Beadbox liest dieselbe Datenbank, in die Ihre Skripte schreiben.
Was es ersetzt, ist der mentale Aufwand, den Projektzustand aus flacher Textausgabe zu rekonstruieren. Die Fragen, die Beadbox auf einen Blick beantwortet und die die CLI nur durch zusammengesetzte Abfragen beantwortet:
- Wie weit ist dieses Epic wirklich?
- Was ist gerade blockiert, und wovon?
- Welche Teilaufgaben wurden seit Stunden nicht angefasst?
- Machen die Agenten Fortschritt oder stagnieren sie?
Das sind visuelle Fragen. Sie verdienen visuelle Antworten.
Erste Schritte
Beadbox ist waehrend der Beta kostenlos. Installation mit Homebrew:
brew tap beadbox/cask && brew install --cask beadbox
Wenn Sie bereits beads verwenden, erkennt Beadbox Ihre .beads/-Workspaces beim Start. Kein Import, kein Konto. Oeffnen Sie die App, klappen Sie ein Epic auf und sehen Sie, wo Ihr Projekt wirklich steht.
Laeuft auf macOS, Linux und Windows.