Beads Nexus

tl;dr

• Beads Nexus ist die Weboberfläche für Patricks operatives Task-System — sie übersetzt die Arbeitsweise von KI-Agenten in eine für Menschen verständliche Sicht
• Statt eine weitere Task-Manager-Datenbank aufzubauen, nutzt die UI das bestehende Beads-System als einzige Quelle und macht es über Dashboard, Epic-Ansichten und Kanban-Boards zugänglich
• Technologie: Minimaler Node.js-Server, einfaches HTML/CSS/JS-Frontend — keine Datenbank, kein Framework
• Kernprinzip: Menschen und Agenten arbeiten auf derselben Datenbasis, aber jede Seite bekommt die Sicht, die zu ihrer Arbeitsweise passt
• Aktueller Stand: Produktiver MVP lokal erreichbar

Kurzbeschreibung

Beads Nexus ist eine menschenzentrierte Weboberfläche für das Task-System, das Patrick gemeinsam mit seinen KI-Agenten nutzt. Statt die Kommandozeilen-Werkzeuge nachzubauen, übersetzt die UI den gemeinsamen Arbeitsgraphen in eine für Menschen intuitiv verständliche Darstellung: Dashboard mit Ready-Work-Übersicht, Epic-Ansichten mit Task-Bäumen, Kanban-Board und globaler Suche. Das Besondere: Es gibt keine eigene Datenbank. Alle Informationen leben im bestehenden Beads/Dolt-System, das auch die Agenten nutzen.

Ausgangspunkt / Problemstellung

Die KI-Agenten in Patricks Umgebung nutzen Beads bereits erfolgreich als gemeinsames Aufgaben-System. Sie können Tasks lesen, anlegen, schließen und Notizen ergänzen — alles über die Kommandozeile.

Für Patrick selbst war dieser Zugang jedoch zu umständlich. Statt direkt mit dem System zu arbeiten, musste er ständig die Agenten bitten, Aufgaben für ihn anzulegen oder Details nachzutragen. Das eigentliche Problem: Die Agenten haben einen hervorragenden Zugriff auf den Arbeitsgraphen, der Mensch nicht.

Eine reine grafische Nachbildung der Kommandozeile hätte das Problem nicht gelöst — es brauchte eine Übersetzung zwischen zwei unterschiedlichen Arbeitsweisen.

Idee

Die grundlegende Idee: Eine Weboberfläche, die nicht versucht, die CLI zu ersetzen, sondern zwischen der Arbeitsweise von Menschen und Agenten vermittelt.

Beads und Dolt bleiben die einzige Datenquelle. Die Weboberfläche dient ausschließlich der Darstellung und Interaktion — Änderungen werden kontrolliert an die CLI weitergegeben. Keine neue Datenbank, kein zweites System, kein Datensilo.

Welche Hypothese steckt dahinter?

Menschen und KI-Agenten arbeiten auf denselben Informationen, nutzen diese jedoch fundamental unterschiedlich:

• Menschen orientieren sich an Kontext, Prioritäten, Übersichtlichkeit und räumlicher Anordnung — sie brauchen Dashboards, Boards und visuelle Hierarchien
• KI-Agenten arbeiten effizient über Beziehungen, Abhängigkeiten, exakte IDs und Graphstrukturen — sie bevorzugen präzise Abfragen und strukturierte Ausgaben

Eine erfolgreiche Human-Agent-Oberfläche muss diese unterschiedlichen Perspektiven zusammenbringen, ohne die technische Struktur der einen Seite der anderen aufzuzwingen.

Warum das relevant ist

Mit der zunehmenden Verbreitung von KI-Agenten entstehen neue Formen der Zusammenarbeit. Die meisten bestehenden Werkzeuge sind entweder für Menschen (klassische Task-Manager wie Linear, Jira, Trello) oder für Maschinen (CLIs, APIs, Agent-Frameworks) optimiert — selten für beide gleichzeitig.

Beads Nexus untersucht die Frage: Wie können beide Gruppen auf derselben Datenbasis arbeiten, ohne dass eine Seite ihre bevorzugte Arbeitsweise aufgeben muss?

Das ist kein akademisches Problem. Wer regelmäßig mit KI-Agenten zusammenarbeitet, merkt schnell: Die größte Reibung entsteht nicht an der Technik, sondern an der unterschiedlichen Art, Informationen zu erfassen und darzustellen.

Ansatz

Das System folgt einer klaren Schichtenarchitektur, bei der die bd CLI die einzige Brücke zur Datenhaltung ist:

Dashboard als Entscheidungszentrale

Das Dashboard ist der primäre Einstiegspunkt. Es beantwortet nicht „Was ist technisch ausführbar?” (das tut die CLI), sondern: „Was ist heute relevant für mich?” Aus dem Rohstatus der Aufgaben wird eine menschenlesbare Perspektive berechnet:

Sicherheitsprinzip

Die Weboberfläche sendet niemals freie Kommandos an das System. Jede Aktion hat einen fest definierten Befehl, der vorher auf Korrektheit geprüft wird. Das verhindert nicht nur Fehlbedienungen, sondern stellt auch sicher, dass kein Weg an der validierten Datenbasis vorbeiführt.

Aktueller Stand

Status: MVP — läuft produktiv lokal

Bereits implementiert:

Technische Basis:

• Server: Leichter Node.js-HTTP-Server (kein Framework)
• Frontend: Einfaches HTML, CSS und JavaScript (kein Build-Tool, keine Abhängigkeiten)
• CLI-Anbindung: Saubere Trennung zwischen Web-API und Beads-CLI
• Deployment: Docker-Container im bestehenden Traefik-Netzwerk
• Tests: Automatisierte Tests mit isoliertem Test-Workspace

In Entwicklung / geplant:

• Multi-Workspace-Support — Unterstützung für projekt-spezifische Beads-Workspaces
• Benachrichtigungen — Automatische Hinweise bei Statuswechseln oder neuen Abhängigkeiten

Erkenntnisse

Die wichtigste Erkenntnis aus der bisherigen Entwicklung: Der Wert liegt nicht in der Technik, sondern in der Perspektiv-Übersetzung.

Agenten lieben die exakte, graph-basierte Struktur von Beads: präzise Abfragen, klar definierte Abhängigkeiten, maschinenlesbare Ausgaben. Menschen brauchen das nicht — sie brauchen visuelle Zusammenfassungen, kontextuelle Filter und eine Antwort auf die Frage „Was ist heute wichtig?”

Eine erfolgreiche Human-Agent-Oberfläche muss drei Dinge tun:

1. Nicht die Kommandozeilen-Oberfläche nachahmen (das fühlt sich für Menschen wie ein schlechter Terminal-Emulator an)
2. Nicht eine eigene Datenhaltung einführen (das zerstört die gemeinsame Datenbasis)
3. Sondern die Stärken beider Welten verbinden: die Präzision des agentischen Systems mit der visuellen Intelligenz des Menschen

Ein weiteres Learning: Sicherheit durch klare Architektur. Indem jeder Zugriff auf einen fest definierten Befehl abgebildet wird, entfällt die ganze Klasse von Sicherheitsproblemen, die bei freien Kommandoeingaben entstehen würden.

Nächste Schritte

1. Dependency-Graph-Visualisierung — Interaktiver Graph statt textueller Abhängigkeitsliste
2. Multi-Workspace-Support — Projektübergreifende Ansicht mehrerer Beads-Workspaces
3. Benachrichtigungen — Hinweise bei Statusänderungen oder neuen Abhängigkeiten

Persönliche Note

Der Name „Nexus” ist bewusst gewählt — lateinisch für Verbindung, Verknüpfung, zentraler Zusammenhang. Genau das ist dieses Projekt für meinen Workflow: Es verbindet Menschen, Agenten und Aufgaben über einen gemeinsamen Arbeitsgraphen, ohne selbst zur Datenquelle zu werden.

Was mich daran besonders reizt: Es ist kein weiterer Task-Manager. Ich habe keinen Wert darauf gelegt, Linear, Jira oder Trello nachzubauen — es gibt genug davon. Stattdessen habe ich eine UI gebaut, die genau die Lücke schließt, die zwischen meiner Arbeitsweise und der meiner Agenten existiert. Und zwar auf Basis der Daten, die beide Seiten bereits nutzen.

Die Technik ist bewusst reduziert: Ein einfacher HTTP-Server, Vanilla-JavaScript, kein Framework, keine Datenbank, kein Build-Tool. Das hält die Komplexität niedrig und macht die Verbindung zum System dahinter direkt sichtbar. Es geht nicht um beeindruckende Technik, sondern um eine Arbeitserleichterung, die sich jeden Tag bemerkbar macht.

FAQ

Was ist Beads Nexus? Eine Weboberfläche für das Beads-Task-System, die als Übersetzungsschicht zwischen Menschen und KI-Agenten auf demselben Arbeitsgraphen dient.

Wie unterscheidet sich Beads Nexus von klassischen Task-Managern wie Linear oder Jira? Beads Nexus hat keine eigene Datenbank. Es liest und schreibt ausschließlich über die CLI in das bestehende System, das auch die KI-Agenten nutzen. Es ist eine UI für den gemeinsamen Arbeitsgraphen, kein separates Tool.

Braucht Beads Nexus eine eigene Datenbank? Nein. Alle Daten leben in Beads/Dolt. Die UI ist eine reine Übersetzungsschicht.

Welche Technologie steckt dahinter? Ein minimalistischer Node.js-HTTP-Server mit einfachem HTML/CSS/JS-Frontend. Kein Framework, keine Datenbank, kein Build-Tool. Die einzige Abhängigkeit zur Datenhaltung ist die bd CLI.

Kann ich über die UI alles machen, was auch die CLI kann? Nein — und das ist gewollt. Die UI bildet nur die wichtigsten Operationen ab (Lesen, Anlegen, Notizen, Status-Update). Zerstörerische Operationen und Synchronisations-Befehle bleiben der Kommandozeile vorbehalten.

Wie wird die Sicherheit gewährleistet? Durch strikte Architektur: Der Browser sendet strukturierte Daten, keine Shell-Kommandos. Jeder Zugriff bildet exakt einen vordefinierten Befehl ab. Texteingaben werden über sichere Kanäle übergeben.

Ist das System produktiv einsetzbar? Ja. Der MVP läuft lokal im Docker-Stack und wird aktiv genutzt.

Können mehrere Personen gleichzeitig arbeiten? Aktuell ist es ein Einzelplatz-System. Schreiboperationen werden serialisiert, aber Konflikte bei parallelen Zugriffen durch Agenten und UI sind noch nicht systematisch gelöst.

Kann ich das System selbst installieren? Ja, über Docker Compose mit einem Bind-Mount auf den Beads-Workspace. Die Details stehen im README des Quellcode-Repos.

Was kostet der Betrieb? Nichts. Das System läuft auf der vorhandenen Infrastruktur, verbraucht minimale Ressourcen und hat keine externen Abhängigkeiten.