Jeder Issue-Tracker, den Sie jemals benutzt haben, folgt demselben Muster. Es gibt einen Cloud-Service. Er hat eine Web-UI. Jemand baut eine CLI, die mit der Cloud-API kommuniziert. Die CLI ist ein Buerger zweiter Klasse: langsamer, weniger leistungsfaehig, immer eine API-Version hinterher.

Drehen Sie diese Architektur nun um. Beginnen Sie mit der CLI. Lassen Sie sie in eine lokale Datenbank schreiben. Machen Sie die Datenbank versionskontrolliert, mit denselben Branching- und Merging-Semantiken, die Sie fuer Quellcode verwenden. Setzen Sie dann eine native Desktop-App darauf, die dieselben Datenbankdateien direkt liest, ohne API dazwischen.

Genau das tun beads und Beadbox. Und der Grund fuer diese Architektur sind KI-Agenten.

Das Problem: Agenten koennen nicht klicken

Wenn Sie eine Flotte von KI-Agenten koordinieren (Code-Generatoren, Reviewer, Tester, Deployer), muessen diese Issues erstellen, Status aktualisieren und Arbeitsqueues lesen. Sie koennen sich nicht bei Jira authentifizieren. Sie koennen nicht durch die Linear-UI navigieren. Sie brauchen eine CLI, die in eine lokale Datenbank schreibt, schnell, ohne Netzwerkabhaengigkeiten.

beads ist diese CLI. Es ist ein Open-Source, Git-nativer Issue-Tracker, der genau fuer diesen Workflow konzipiert ist. Der bd-Befehl erstellt, aktualisiert, listet und schliesst Issues. Jeder Schreibvorgang landet in einer lokalen Dolt-Datenbank im .beads/-Verzeichnis Ihres Repositories.

Die Zahlen sind hier entscheidend. bd create dauert etwa 15ms. bd list ueber 10.000 Issues liefert Ergebnisse in etwa 200ms. Diese Benchmarks stammen aus der beads Test-Suite. Wenn Agenten in engen Schleifen durch Arbeitspakete brennen, bestimmen Millisekunden pro Operation, ob Ihr Issue-Tracker mithaelt oder zum Engpass wird.

Warum Dolt und nicht SQLite?

Dolt ist eine SQL-Datenbank, die Git-Semantiken implementiert. Jeder Schreibvorgang ist ein Commit. Sie bekommen dolt diff, um zu sehen, was sich zwischen zwei Zeitpunkten geaendert hat. Sie bekommen dolt log fuer die vollstaendige Audit-History. Sie bekommen dolt branch und dolt merge mit demselben mentalen Modell, das Sie bereits fuer Code verwenden.

Fuer Issue-Tracking bedeutet das: Ihre Projekthistorie hat zwei parallele Audit-Trails: git log fuer Code-Aenderungen, dolt log fuer Issue-Aenderungen. Sie koennen Fragen beantworten wie "Wie sah die Issue-Datenbank aus, als wir v2.1.0 getaggt haben?", indem Sie diesen Punkt in der Dolt-History auschecken. Sie koennen Ihre Issue-Datenbank branchen, um eine Reorganisation auszuprobieren, und sie dann zurueckmergen oder verwerfen.

beads hat die SQLite-Unterstuetzung in v0.9.0 entfernt und setzt voll auf Dolt. Die Versionskontroll-Semantiken sind kein nettes Extra; sie sind das Fundament. Wenn zwanzig Agenten in dieselbe Issue-Datenbank schreiben, brauchen Sie die Moeglichkeit, diese Daten mit derselben Zuversicht zu diffen, branchen und mergen wie Ihren Quellcode.

Optionale Zusammenarbeit funktioniert ueber DoltHub. Pushen Sie Ihre Issue-Datenbank zu einem Remote, Teammitglieder pullen Aenderungen. Derselbe Push/Pull-Workflow wie bei Git, angewandt auf strukturierte Daten.

Die visuelle Schicht: Beadbox

Agenten gedeihen mit CLIs. Menschen nicht, zumindest nicht, wenn sie den Ueberblick brauchen. Abhaengigkeitsgraphen, Epic-Fortschrittsbaeume, Ketten blockierter Issues: Das sind raeumliche Probleme, die ein Terminal nicht gut rendern kann.

Beadbox ist eine native Desktop-Anwendung, gebaut mit Tauri (nicht Electron), die dasselbe .beads/-Verzeichnis liest, in das die CLI schreibt. Kein Import-Schritt, kein Sync-Prozess, keine API-Schicht. Die GUI ueberwacht das Dateisystem ueber fs.watch(), erkennt Dolt-Datenbankaenderungen und sendet Updates ueber einen lokalen WebSocket. Wenn ein Agent bd update BEAD-42 --status in_progress ausfuehrt, aendert sich das Status-Badge in Beadbox innerhalb von Millisekunden.

So sieht der Workflow in der Praxis aus:

# Ein Agent erstellt ein Issue
bd create --title "Migrate auth to OIDC" --type task --priority 1

# Ein anderer Agent beansprucht es
bd update BEAD-42 --claim --actor agent-3

# Ein Mensch oeffnet Beadbox und sieht das vollstaendige Board:
# Abhaengigkeitsgraphen, Epic-Baeume, Filter nach Status/Prioritaet/Zustaendigem
# Keine Befehle noetig. Einfach hinschauen.

# Der Agent beendet die Arbeit und markiert sie zur Ueberpruefung
bd update BEAD-42 --status ready_for_qa

# Beadbox aktualisiert sich in Echtzeit. Der QA-Agent nimmt es auf.

Agenten schreiben ueber die CLI. Menschen lesen ueber die GUI. Beide arbeiten auf derselben lokalen Dolt-Datenbank. Keine Abstimmung, keine veralteten Caches, kein "lassen Sie mich aktualisieren."

Beadbox laeuft auf macOS, Linux und Windows. Es unterstuetzt mehrere Workspaces, sodass Sie zwischen Projekten wechseln koennen, ohne neu zu starten.

Was "Local-First" wirklich bedeutet

Der Begriff wird ueberstrapaziert. Hier ist, was er konkret fuer beads und Beadbox bedeutet:

Kein Konto. Sie melden sich nirgendwo an. Installieren Sie die CLI, installieren Sie die App, richten Sie sie auf ein Verzeichnis. Fertig.

Keine Cloud-Abhaengigkeit. Alles laeuft auf Ihrem Dateisystem. Ihre Daten verlassen Ihren Rechner nie, es sei denn, Sie fuehren explizit dolt push zu einem Remote aus. Internet faellt aus? Nichts aendert sich. Sie arbeiten weiter.

Kein Server. Es gibt keinen Daemon zu verwalten, keinen Docker-Container zu starten. Die Dolt-Datenbank ist ein Verzeichnis mit Dateien. Die CLI liest und schreibt diese Dateien. Beadbox ueberwacht diese Dateien.

Optionale Zusammenarbeit. Wenn Sie doch teilen moechten, pushen Sie zu DoltHub. Ihre Teammitglieder pullen. Merge-Konflikte bei Issue-Daten werden genauso geloest wie bei Code. Aber das ist opt-in, nicht erforderlich.

Vergleichen Sie das mit den Alternativen. Jira braucht einen Server (oder Atlassian Cloud). Linear braucht ein Konto und eine Internetverbindung. GitHub Issues braucht ein Repository auf GitHubs Servern. Selbst selbstgehostete Optionen wie Gitea erfordern das Betreiben eines Webservices.

beads braucht ein Verzeichnis. Beadbox braucht dasselbe Verzeichnis und einen Doppelklick.

Fuer wen das gedacht ist

Wenn Sie KI-Agenten betreiben, die sich ueber eine gemeinsame Arbeitsqueue koordinieren muessen, und Sie als Mensch diese Arbeit visuell ueberwachen und steuern wollen, wurde dieser Stack fuer Ihren Workflow gebaut.

Wenn Sie Projekte allein verwalten und versionskontrolliertes Issue-Tracking neben Ihrem Code wollen, ohne Cloud-Konto, funktioniert dieser Stack dafuer ebenso.

Wenn Sie Jiras Enterprise-Berechtigungsmodell oder Linears kollaboratives Echtzeit-Editing ueber ein verteiltes Team brauchen, ist dies nicht das richtige Tool. beads ist Local-First by Design. Das ist ein bewusster Kompromiss, kein Versaeumnis.

Loslegen

Installieren Sie die beads CLI von github.com/steveyegge/beads, dann installieren Sie Beadbox:

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

Initialisieren Sie eine beads-Datenbank in einem beliebigen Projekt:

cd your-project
bd init

Oeffnen Sie Beadbox, richten Sie es auf das Verzeichnis, und Sie schauen auf Ihr Issue-Board. Keine Registrierung. Kein Konfigurationsassistent. Kein "Verbinden Sie Ihr GitHub-Konto"-Dialog.

Beadbox ist waehrend der Beta kostenlos.