Visuelles Epic-Fortschrittstracking für Entwicklerteams

Du erstellst ein Epic mit 15 Teilaufgaben. Du verteilst sie auf eine Handvoll Agenten oder Teammitglieder. Zwei Tage später fragt jemand: "Wie weit ist der Auth-Rewrite?"

Du führst bd show bb-r4f aus. Das zeigt dir das Epic selbst. Titel, Beschreibung, Priorität. Es sagt dir nicht, wie viele Kinder abgeschlossen sind. Also führst du bd list --parent bb-r4f aus. Du bekommst eine flache Liste von IDs und Titeln. Um den Status jedes einzelnen zu sehen, pipst du durch jq oder rufst bd show für jedes Kind einzeln auf. Manche dieser Kinder haben eigene Teilaufgaben. Jetzt bist du drei Ebenen tief und rekonstruierst einen Baum im Kopf aus Terminal-Ausgaben.

Das funktioniert, wenn ein Epic drei Kinder hat. Bei zehn bricht es zusammen. Und wenn du KI-Agenten koordinierst, die in schneller Folge Teilaufgaben erstellen, Blocker melden und Issues schließen, ist die CLI-Ausgabe veraltet in der Zeit zwischen Befehlseingabe und fertigem Lesen.

Das Problem ist nicht beads. Die beads CLI eignet sich hervorragend für strukturiertes, skriptfähiges 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

Öffne Beadbox, klick auf ein Epic und du siehst seine Kinder in einem zusammenklappbaren Baum. Jedes Kind zeigt ein Status-Badge (open, in_progress, ready_for_qa, closed), einen Prioritätsindikator und den Zuständigen. Das Epic selbst zeigt einen Fortschrittsbalken: "9 von 14 abgeschlossen (64%)." Diese Zahl aktualisiert sich, sobald Kinder geschlossen werden.

Klapp ein Kind auf, das selbst ein Epic ist, und du siehst seine Teilaufgaben darunter verschachtelt. Der Fortschritt des übergeordneten Epics aggregiert über alle Nachkommen, nicht nur über direkte Kinder. Ein dreistufiges Epic mit 40 Issues insgesamt über Engineering, QA und Dokumentation zeigt dir den tatsächlichen Fertigstellungsgrad oben, unter Berücksichtigung jedes Blattknotens im Baum.

Blockierte Issues bekommen eine deutliche visuelle Behandlung. Wenn bb-m3q von bb-k7p abhängt und bb-k7p noch offen ist, steht das Blocked-Badge neben dem Status von bb-m3q. Du musst nicht bd dep list ausführen, um den Engpass zu finden. Er ist im Baum sichtbar, auf der Ebene, wo er relevant ist.

Vergleich das mit dem CLI-Workflow. Um "Was blockiert den Fortschritt beim Auth-Epic?" zu beantworten, würdest du ausführen:

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 völlig gültige Pipeline. Sie liefert die richtige Antwort. Aber du musst sie schreiben, dir die Flags merken und sie jedes Mal neu ausführen, wenn du ein Update willst. In Beadbox ist dieselbe Information immer im Baum sichtbar. Keine Abfrage nötig.

Echtzeit-Updates: Der Baum ändert sich, während du zuschaust

Hier zeigt das visuelle Modell seinen wahren Wert. Wenn ein Agent bd update bb-k7p --status=closed in einem Terminal ausführt, erkennt Beadbox die Dateisystemänderung innerhalb von Millisekunden. Der WebSocket-Server erkennt den Schreibvorgang im .beads/-Verzeichnis, broadcasted die Änderung und die React-UI rendert neu.

Im Epic-Baum sieht das so aus: bb-k7p wechselt von einem orangenen "in_progress"-Badge zu einem grünen "closed"-Badge. Der Fortschrittsbalken des übergeordneten Epics steigt von 64% auf 71%. Und bb-m3q, das auf bb-k7p blockiert war, verliert seinen Blocked-Indikator und erscheint als verfügbare Arbeit.

All das passiert, ohne dass du einen Befehl ausführst oder einen Refresh-Button klickst. Wenn du eine Flotte von Agenten beaufsichtigst, die durch ein Release-Epic arbeiten, beobachtest du, wie sich der Baum füllt, während Aufgaben abgeschlossen werden. Engpässe zeigen sich im Moment ihrer Entstehung, weil Blocked-Badges in Echtzeit erscheinen. Stagnierte Teilbäume (Cluster von Issues, die ihren Status nicht mehr ändern) werden nach ein paar Minuten Inaktivität visuell offensichtlich, vor dem Hintergrund stetigen Fortschritts anderswo.

Der zugrundeliegende Mechanismus ist unkompliziert. Beadbox betreibt einen WebSocket-Server, der fs.watch() auf deinem .beads/-Verzeichnis aufruft. Jeder Datenbank-Schreibvorgang löst einen Broadcast aus. Der clientseitige Hook empfängt 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 für Entwickler und verhält sich entsprechend. j und k bewegen sich durch die Issue-Liste (Vim-Stil). Enter öffnet das ausgewählte Issue im Detail-Panel. / fokussiert die Suchleiste. Escape schließt, was gerade offen ist. Pfeiltasten klappen Knoten im Epic-Baum auf und zu.

Du kannst ein ganzes Backlog sichten, ohne die Maus anzufassen. Beweg dich mit j durch die Liste, öffne ein Issue um seine Beschreibung zu lesen, drücke Escape zum Schließen, geh zum nächsten. Wenn du etwas entdeckst, das eine Statusänderung braucht, wechselst du fürs Schreiben ins Terminal (bd update). Beadbox ist von Grund auf eine leseintensive Oberfläche. Die CLI übernimmt Schreibvorgänge. Die GUI übernimmt das Verstehen.

Diese Trennung ist beabsichtigt. Eine GUI, die versucht, die CLI beim Schreiben zu ersetzen, baut am Ende Formulare für jede mögliche Flag-Kombination. Eine GUI, die sich auf Lesen und Navigation konzentriert, kann für das optimieren, worin Terminals am schlechtesten sind: hierarchische, quervernetzte Daten auf einen Blick zeigen.

Mehrere Projekte, ein Fenster

Wenn du an mehr als einer Codebasis arbeitest, jede mit ihrer eigenen .beads/-Datenbank, handhabt der Workspace-Switcher von Beadbox das. Ein Dropdown im Header listet jeden erkannten Workspace auf. Klick auf einen (oder finde den Workspace mit /-Suche) und die gesamte Ansicht lädt aus der Datenbank dieses Projekts neu. Filter und Scroll-Position bleiben pro Workspace erhalten, sodass ein Zurückwechseln deinen Platz nicht verliert.

Die Erkennung ist automatisch. Beadbox scannt registrierte Workspaces in der bd-Konfiguration und Verzeichnisse mit .beads/-Datenbanken. Füg ein neues Projekt hinzu, initialisiere beads darin, und beim nächsten Öffnen von Beadbox erscheint es im Dropdown. Kein Import, kein Konfigurationsbildschirm.

Für Entwickler, die mehrere Services pflegen, oder für Teams, in denen jeder Agent in einem separaten Repository arbeitet, macht das Beadbox zu einer einzigen Ansicht über alle aktiven Projekte. Die Alternative: mehrere Terminal-Fenster, die jeweils bd list gegen einen anderen --db-Pfad ausführen.

Was das ersetzt

Beadbox ersetzt nicht die CLI. Wenn du deine Workflows skriptest, bd list durch jq pipst oder Agenten hast, die Issues programmatisch erstellen und schließen, funktioniert das alles weiterhin unverändert. Beadbox liest dieselbe Datenbank, in die deine 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.

Loslegen

Beadbox ist während der Beta kostenlos. Installation mit Homebrew:

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

Wenn du bereits beads nutzt, erkennt Beadbox deine .beads/-Workspaces beim Start. Kein Import, kein Account. Öffne die App, klapp ein Epic auf und sieh, wo dein Projekt wirklich steht.

Läuft auf macOS, Linux und Windows.