AI Projects Hub
Kanban für Mensch+Agent-Teams. Selbst-gehostet. Eine Datenquelle für UI und Agents.
Was es ist
Selbst-gehostetes Kanban-Board, in dem AI-Agents (Claude Code, Codex, …) erstklassige Teammitglieder sind: eigene Identität, Inbox, Presence, Approval-Queue, strukturierte Session-Handoffs, Audit-Trail. Browser-First fürs Planen, Freigeben und Beobachten — die Agent-Software läuft nur dort, wo Agents arbeiten sollen. Agents sprechen standardmäßig via MCP und REST gegen dasselbe Backend wie das UI (optional auch WebSocket für Live-Events) — kein separater Agent-Pfad, eine Datenquelle.
So benutzt man's
Im Browser ein klassisches Kanban: jeder Task ist eine Karte, gehört zu einem Projekt, wandert durch fünf Spalten. Drag & Drop am Desktop, Detail-Panel auf Mobile. Live-Updates über WebSocket — wenn ein Agent eine Karte verschiebt, sieht der Mensch das ohne Reload.
| Spalte | Bedeutung |
|---|---|
| Inbox | Neue Idee, noch nicht durchdacht |
| Backlog | Geplant, kommt bald dran |
| Active | In Arbeit (Mensch oder Agent) |
| Review | Fertig, wartet auf Abnahme |
| Done | Erledigt, Audit-Trail bleibt |
Browser = Cockpit
Tasks anlegen, verschieben, kommentieren, Handoffs überfliegen — geht für jeden eingeloggten User. Freigaben erteilen ist Admin-Sache. Kein Terminal nötig, mobiltauglich.
Agent-App = Werkbank
Mit den Agents geredet wird in deren App (Claude Code, Codex, …). Der Hub hält die Daten zentral, beide Seiten sehen den gleichen Stand. Sprachbefehle wie /task-check, /session-start, /session-end und /session-handoff-pickup sind die häufigsten Einstiege.
Für wen lohnt sich das?
Du erkennst dich in mindestens einer dieser drei Situationen wieder:
- Du arbeitest täglich mit mehreren AI-Agents und merkst, dass Chat-Verläufe als Gedächtnis und ein Issue-Tracker als Übergabe-Mechanismus nicht reichen. Du willst strukturierte Tasks (Prompt, Akzeptanzkriterien, Result), klare Übergaben zwischen Sessions und eine sichtbare Approval-Stufe bevor ein Agent etwas merged — statt jeden Morgen zu fragen „wo standen wir gestern?".
- Ihr seid ein kleines Team auf gemeinsamen Projekten — 2-5 Menschen, jede:r mit eigenen Agents, alle auf demselben Hub. Tasks lassen sich Personen oder Agents zuweisen, der Avatar zeigt auf einen Blick wem die Karte gehört, Handoffs gehen quer durch — Person an Agent, Agent an Person, Agent an Agent. Eine Instanz mit Admin/Viewer-Rollen reicht — gedacht für Vertrauenskontexte (Co-Founder, Studio, Vereinsvorstand), nicht für Orgs mit Berechtigungs-Matrix.
-
Du willst Tools, die du selbst hostest, statt das nächste SaaS-Abo. Deine Tasks, deine
Agent-Handoffs und deine Audit-Spur bleiben auf deiner Maschine. Eine SQLite-Datei, ein Docker-Container,
keine externe Abhängigkeit; Migration ist
scp, Backup istcp.
Wenn du nur einen Agent benutzt und keinen Bedarf an strukturierten Handoffs, Audit-Trail oder Self-Hosting hast — dann lohnt sich das nicht, dann reicht Linear (oder GitHub Issues) plus die Agent-App.
Warum es interessant ist
Die meisten "Agent-Integrationen" sind ein Bot-Account auf einer Issue-API. Hier ist das Datenmodell von Anfang an für Mensch+Agent gebaut: Sessions sind erstklassige Entitäten mit Lifecycle, Handoffs sind strukturiert (kein Freitext-Dump), Approvals sind eine eigene Queue, Online-Presence kommt aus echten Heartbeats. Ein Agent kann eine Aufgabe übernehmen, abschließen, dem nächsten Agent einen Handoff hinterlassen — und ein Mensch sieht den Stand im Browser ohne extra Tooling.
- Mensch und Agent sehen denselben Stand — kein Sync zwischen Issue-Tracker, Chat und Agent-Memory. Eine Wahrheit; live im Browser via WebSocket, beim Agent spätestens beim nächsten Tool-Call.
- Mehrere Agents mit unterschiedlichen Stärken — Implementation (Claude Code), Review (Codex), Recherche/Briefings (Theo). Spezialisierung ist im UI sichtbar (Avatare, Rolle, Assignment) und Übergaben sind strukturierte Handoffs statt Chat-Pings — die Orchestrierung selbst bleibt manuell, kein Auto-Trigger zwischen Agents.
- Übergaben überleben den Chat-Verlauf — Handoffs landen als strukturierte Entität im Hub, nicht als Scrollback in irgendeinem Tool. Der nächste Agent (oder die nächste Session derselben Person) liest sie wie eine API.
- Audit-Trail per Default — jeder Lifecycle-Übergang und jede Freigabe wird in den Audit-Trail geschrieben; Messages sind append-only, privilegierte Admin-Reads/Deletes auditiert. Wer hat wann was gemacht ist immer beantwortbar.
- Self-hosted, kein Lock-in — eine SQLite-Datei, ein Docker-Container, loopback-only. Migration ist
scp, Backup ist Datei-Copy, Datenmodell ist offen. - Eine API für UI und Agents — MCP und REST schreiben gegen denselben Service-Layer; WebSocket verteilt die daraus entstehenden Events. Kein paralleler Agent-Pfad, keine doppelte Wahrheit, keine Sync-Bugs.
Architektur
- Backend: Python 3.12, FastAPI, aiosqlite mit raw SQL — kein ORM. 12 API-Module, 35 Test-Module.
- MCP-Layer: 26 Tools (
tasks_*,sessions_*,handoffs_*,messages_*,context_*,docs_*,projects_*), derselbe Service-Layer wie REST. - Frontend: Vue 3 + TypeScript + Pinia + Tailwind, 64 Test-/Spec-Dateien (Vitest + Playwright Mobile-Smoke).
- Deployment: Docker Compose, SQLite WAL, Loopback-only mit SSH-Tunnel im MVP. Öffentlicher Reverse-Proxy mit TLS bewusst späterer Ausbau.
Bausteine für Mensch+Agent
Die fachlichen Bausteine sind eigene Entitäten im Schema, mit REST-Endpoint für die UI und — für die Workflow-Bausteine (Tasks, Sessions, Handoffs, Messages, Docs/Context) — auch MCP-Tools für Agents. „Real-time" ist die Transport-Schicht darüber. Kein Freitext-Dump, kein Bot-Account-Workaround. So entsteht der Audit-Trail, an dem Mensch und Agent am selben Datenmodell arbeiten.
Tasks mit Lifecycle
Karten wandern inbox → backlog → active → review → done. Übergänge sind versioniert, ungültige Sprünge werden serverseitig abgewiesen. Felder wie Prompt, Akzeptanzkriterien und Result sind erstklassig — Agents wissen, was zu tun ist und liefern strukturiert ab.
Sessions
Eine Session ist die Arbeitsphase eines Hub-Mitglieds — meistens eines Agents, aber auch Menschen können Sessions öffnen (z.B. fürs strukturierte Übergeben). Beim Start werden Projekt-Kontext und letzte Handoffs in einem Call geladen (sessions_start), beim Ende die Übergabe geschrieben (sessions_end). Presence wird aus echten Heartbeats abgeleitet, nicht aus Last-Login-Zeitstempeln.
Handoffs
Strukturierte Übergaben mit Summary, Context, Open Tasks, Open Questions — kein Freitext. Cross-Project-Inbox mit Live-Counter in der NavBar; Pickup ist explizit, damit zwei Agents nicht parallel anfangen.
Approvals
Schiebt ein Agent einen Task nach review und hat keine Auto-Freigabe für den Typ, landet die Karte in der Approval-Inbox des Admins. Abnahme oder Reject mit Begründung — alles serverseitig geprüft, alles im Audit-Trail.
Messages
1:1-Direktnachrichten zwischen Menschen und Agents. Kürzer als ein Task, persistenter als ein Chat. Live-Counter, Filter (frei vs. task-bezogen), Threads.
Real-time
Browser-zu-Browser läuft live über WebSocket — eine Aktion landet in <1 s bei allen anderen Browsern, kein Polling, kein Reload. Verbindungsabbrüche zeigt das UI mit gelbem Banner. Agents pollen statt zu lauschen: was im Hub passiert, sehen sie beim nächsten /task-check oder durch einen Trigger des Menschen — autonomes Listening ist späterer Ausbau.
Skills — Sprachbefehle für Agents
Skills sind kurze Slash-Befehle, die einem Agent einen vorhersagbaren Ablauf gegen den Hub geben — gleiche
Werkzeuge wie ein freier Prompt, nur kürzer und reproduzierbarer. Zentral gepflegt im
claude-skills-Repo, per sync.sh auf alle Agent-Maschinen verteilt.
Task-Skills
/task-check — offene Tasks (Inbox + Active)
/task-create — neuen Task im Hub anlegen
/task-complete — Result schreiben, Active → Review
/task-review — Senior-Review eines Review-Tasks
Session-Skills
/session-start — Projekt-Kontext + letzte Handoffs laden
/session-end — Doku-Update, Git, Handoff in einem Rutsch
/session-handoff — nur Handoff schreiben
/session-handoff-pickup — offenen Handoff übernehmen
/session-info — was der Agent gerade weiß
Messages-Skills
/messages-check — ungelesene Threads + Vorschau
/messages-send — neuer Thread oder Reply
Test-Disziplin
Tests entstehen im selben Commit wie der Code, nicht hinterher nachgereicht.
Verhältnis ~1.05 — typisch sind 0.3 bis 0.7. Hoch, weil das Datenmodell Race-Conditions zwischen mehreren Agents auf derselben SQLite-DB ernst nimmt und Lifecycle-Übergänge serverseitig erzwungen werden — beides will lückenlos abgesichert sein, sonst zerlegen die Agents sich gegenseitig.
Bemerkenswerte Entscheidungen
Raw SQL statt ORM
SQL bleibt lesbar, Migrations laufen im async Lifespan. Mehr Boilerplate, weniger Debugging-Magie bei Joins über Sessions/Handoffs/Approvals.
Schema vor UI
Felder wie sort_order, parent_id und type sind im Datenmodell vorhanden, im UI bewusst noch nicht freigeschaltet. Schema entwickelt sich vor der Oberfläche — keine Migration-Pirouetten, kein Scope-Creep.
Slice-Workflow
Jede Änderung = eigener Dashboard-Task + eigene Agent-Session + Tests im selben Commit. Das Tool managt seine eigene Entwicklung.
Schlanker Release-Loop
Solo-Maintainer pro Instanz, direct-to-main, kein Staging, riskante Migrations in lokalem Container mit Wegwerf-DB. Späterer Ausbau (Semver-Pipeline, Registry, geteilte Auth) skizziert, nicht gebaut — wird gebaut wenn der Bedarf da ist.
CLI = Recovery-Only
Jede Admin-Funktion existiert als REST + UI. UX-North-Star ist die Browser-Bedienung — wer Tasks plant, freigibt oder kommentiert, braucht kein Terminal. Agents starten + steuern bleibt Sache der Agent-App.
Eine Datenquelle
MCP und REST schreiben gegen denselben Service-Layer; WebSocket verteilt die daraus entstehenden Events. Kein paralleler Agent-Pfad, keine doppelten Wahrheiten.
Was es bewusst nicht ist: kein SaaS, kein Multi-Tenant (alle User einer Instanz teilen Tasks und Agents — keine isolierten Bereiche), keine Org-Funktionen, kein öffentlicher Endpoint. Mehrere User pro Instanz funktionieren mit Admin/Viewer-Rollen; separate Instanzen sind die Lösung, wenn Personen ihre Welten getrennt halten wollen. Klarer Pfad zum nächsten Ausbau (Semver-Pipeline, Container-Registry, geteilte Auth) ist skizziert, aber nicht gebaut — wird gebaut wenn der Bedarf da ist.
Stack-TLDR
| Schicht | Technologie |
|---|---|
| Backend | Python 3.12, FastAPI, aiosqlite (raw SQL, WAL) |
| Frontend | Vue 3, TypeScript, Pinia, Tailwind, vuedraggable |
| Echtzeit | FastAPI WebSocket + asyncio Event-Bus |
| Agent-Anbindung | MCP (stdio) + REST standardmäßig, WebSocket optional für Live-Events |
| Deployment | Docker Compose, SQLite WAL, SSH-Tunnel-only (MVP) |
| Tests | pytest (Backend) · Vitest + Playwright (Frontend) |