Jeder Issue-Tracker, den du je benutzt hast, folgt demselben Muster. Es gibt einen Cloud-Service. Er hat eine Web-UI. Jemand baut eine CLI, die mit der Cloud-API redet. Die CLI ist Bürger zweiter Klasse: langsamer, weniger leistungsfähig, immer eine API-Version hinterher.

Jetzt dreh die Architektur um. Fang mit der CLI an. Lass sie in eine lokale Datenbank schreiben. Mach die Datenbank versionskontrolliert, mit denselben Branching- und Merging-Semantiken, die du für Quellcode verwendest. Setz dann eine native Desktop-App obendrauf, die dieselben Datenbankdateien direkt liest, ohne API dazwischen.

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

Das Problem: Agenten können nicht klicken

Wenn du eine Flotte von KI-Agenten koordinierst (Code-Generatoren, Reviewer, Tester, Deployer), müssen diese Issues erstellen, Status aktualisieren und Arbeitsqueues lesen. Sie können sich nicht bei Jira authentifizieren. Sie können nicht durch die Linear-UI navigieren. Sie brauchen eine CLI, die in eine lokale Datenbank schreibt, schnell, ohne Netzwerkabhängigkeiten.

beads ist diese CLI. Ein Open-Source, Git-nativer Issue-Tracker, der genau für diesen Workflow konzipiert ist. Der bd-Befehl erstellt, aktualisiert, listet und schließt Issues. Jeder Schreibvorgang landet in einer lokalen Dolt-Datenbank im .beads/-Verzeichnis deines Repos.

Die Zahlen sind hier entscheidend. bd create dauert etwa 15ms. bd list über 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 dein Issue-Tracker mithält oder zum Engpass wird.

Warum Dolt und nicht SQLite?

Dolt ist eine SQL-Datenbank, die Git-Semantiken implementiert. Jeder Schreibvorgang ist ein Commit. Du bekommst dolt diff, um zu sehen, was sich zwischen zwei Zeitpunkten geändert hat. Du bekommst dolt log für die vollständige Audit-History. Du bekommst dolt branch und dolt merge mit demselben mentalen Modell, das du bereits für Code nutzt.

Für Issue-Tracking bedeutet das: Deine Projekthistorie hat zwei parallele Audit-Trails: git log für Code-Änderungen, dolt log für Issue-Änderungen. Du kannst Fragen beantworten wie "Wie sah die Issue-Datenbank aus, als wir v2.1.0 getaggt haben?", indem du diesen Punkt in der Dolt-History auscheckst. Du kannst deine Issue-Datenbank branchen, um eine Reorganisation auszuprobieren, und sie dann zurückmergen oder verwerfen.

beads hat die SQLite-Unterstützung 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, willst du die Möglichkeit, diese Daten mit derselben Zuversicht zu diffen, branchen und mergen wie deinen Quellcode.

Optionale Zusammenarbeit funktioniert über DoltHub. Push deine Issue-Datenbank zu einem Remote, Teammitglieder pullen Änderungen. Derselbe Push/Pull-Workflow wie bei Git, angewandt auf strukturierte Daten.

Die visuelle Schicht: Beadbox

Agenten blühen mit CLIs auf. Menschen nicht, zumindest nicht, wenn sie den Überblick brauchen. Abhängigkeitsgraphen, Epic-Fortschrittsbäume, Ketten blockierter Issues: Das sind räumliche Probleme, die ein Terminal nicht gut darstellen 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 überwacht das Dateisystem über fs.watch(), erkennt Dolt-Datenbankänderungen und broadcasted Updates über einen lokalen WebSocket. Wenn ein Agent bd update BEAD-42 --status in_progress ausführt, ändert 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 öffnet Beadbox und sieht das vollständige Board:
# Abhängigkeitsgraphen, Epic-Bäume, Filter nach Status/Priorität/Zuständigem
# Keine Befehle nötig. Einfach hinschauen.

# Der Agent wird fertig und markiert es für Review
bd update BEAD-42 --status ready_for_qa

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

Agenten schreiben über die CLI. Menschen lesen über die GUI. Beide arbeiten auf derselben lokalen Dolt-Datenbank. Keine Abstimmung, keine veralteten Caches, kein "lass mich mal refreshen."

Beadbox läuft auf macOS, Linux und Windows. Es unterstützt mehrere Workspaces, sodass du zwischen Projekten wechseln kannst, ohne neu zu starten.

Was "Local-First" wirklich bedeutet

Der Begriff wird überstrapaziert. Hier ist, was er konkret für beads und Beadbox bedeutet:

Kein Account. Du meldest dich nirgendwo an. Installier die CLI, installier die App, richte sie auf ein Verzeichnis. Fertig.

Keine Cloud-Abhängigkeit. Alles läuft auf deinem Dateisystem. Deine Daten verlassen deinen Rechner nie, es sei denn, du führst explizit dolt push zu einem Remote aus. Internet fällt aus? Ändert sich nichts. Du arbeitest 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 überwacht diese Dateien.

Optionale Zusammenarbeit. Wenn du doch teilen möchtest, push zu DoltHub. Deine Teammitglieder pullen. Merge-Konflikte bei Issue-Daten lösen sich genauso wie bei Code. Aber das ist opt-in, nicht Pflicht.

Vergleich 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 einen laufenden Webservice.

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

Für wen das gedacht ist

Wenn du KI-Agenten betreibst, die sich über eine gemeinsame Arbeitsqueue koordinieren müssen, und du als Mensch diese Arbeit visuell überwachen und steuern willst: Dieser Stack wurde für deinen Workflow gebaut.

Wenn du Projekte allein verwaltest und versionskontrolliertes Issue-Tracking neben deinem Code willst, ohne Cloud-Account: Dieser Stack funktioniert dafür genauso.

Wenn du Jiras Enterprise-Berechtigungsmodell oder Linears kollaboratives Echtzeit-Editing über ein verteiltes Team brauchst, ist das nicht das richtige Tool. beads ist Local-First by Design. Das ist ein bewusster Kompromiss, kein Versäumnis.

Loslegen

Installiere die beads CLI von github.com/steveyegge/beads, dann installiere Beadbox:

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

Initialisiere eine beads-Datenbank in einem beliebigen Projekt:

cd your-project
bd init

Öffne Beadbox, richte es auf das Verzeichnis, und du schaust auf dein Issue-Board. Keine Registrierung. Kein Konfigurationsassistent. Kein "Verbinde deinen GitHub-Account"-Dialog.

Beadbox ist während der Beta kostenlos.