1 · Pipeline
Der Default-Startscreen. Er beantwortet: Was blockiert Produktfortschritt? Wo liegt Arbeit? Was muss ein Mensch entscheiden?
StufenCycle timeWIP limits Agent Platform Blueprint · v0.1
Von der rohen Idee zur geprüften Lieferung — und wieder zurück in bessere Agenten
Eine umfassende Produkt- und Systemdokumentation für eine kleine Team-„Software Factory“: GitLab als Audit- und Code-System, Hermes als Orchestrator, isolierte Worker als Ausführungsschicht und eine Control Plane als gemeinsame UI.
Design-Entscheidung: GitLab ist immer die fachliche und technische Source of Truth. Hermes Kanban ist ausschließlich die langlebige Agenten-Execution-Queue. Die UI zeigt, erklärt und steuert auditiert — sie darf weder GitLab ersetzen noch freie Shell-/Git-Schreibzugriffe aus dem Browser auslösen.
3
Startrollen
Orchestrator · Coder · Reviewer. Research, Security, Reproducer und Release erst ergänzen, wenn der Kernpfad zuverlässig läuft.
01 · Der vollständige Produktfluss
Eine Idee startet nicht mit Coding, sondern mit einem belegbaren Entscheidungsprozess.
Der Flow ist für CLI, GitLab-Issue und spätere UI identisch. Nur der Einstiegspunkt ändert sich.
Analyse / User-InteraktionOrchestrierungAusführung / DeliveryRisiko- oder Human GateEvaluation / Lernen
Der früheste Automatismus beginnt erst nach einem bewussten Trigger — beispielsweise agent:grill auf einem GitLab-Issue oder „Neue Idee“ im Control Center. Keine vage Notiz darf automatisch Code schreiben.
02 · Team-Server & Runtime
Der Agentenserver ist eine kontrollierte Ausführungsumgebung, kein Produktionsserver.
Die Control Plane fragt nur über typisierte APIs nach Status und sendet auditiert Kommandos. Worker brauchen projekt- und rollenbezogene Tokens, nicht den persönlichen Admin-Token eines Teammitglieds.
03 · Control Plane UI
Die UI muss Entscheidungen schneller und sicherer machen — nicht nur Agenten hübsch darstellen.
Zuerst Hermes Dashboard + GitLab verwenden. Die eigene UI entsteht, sobald ihr echte Freigaben, mehrere Projekte und laufende Worker zentral sehen müsst.
◈ AGENT FACTORYproduct-lab / sleep-sound-tracker● gateway online · 3 worker
Sleep Sound Tracker
Privacy-first Wellness MVP · Idea #42 · letzten 24 Stunden
SIGNALS
4
Idea #42: SchnarchtrackerOwner: Enrico · neu
CI finding: mobile audioGitLab issue #61
GRILL / TRIAGE
1
Fragen an Founder wartenTask K-142 · blocked
DISCOVERY
3
Markt-Researchresearcher · 62%
Android spiketech-spike · 41%
PLAN
1
MVP Decision Briefwartet auf Inputs
DELIVERY
0
Kein Coding vor GoPolicy gate
VALIDATE
2
Privacy gate offenHuman review nötig
Spike verdicts2 / 4 abgeschlossen
Approval Inbox
● Discovery-Budget für #42 freigebenPENDING
● Privacy-Entscheidung: Audio lokal haltenPENDING
● MR !81: RegressionstestREADY
Live Activity
09:41 · researchersource saved
09:39 · tech-spiketest running
09:28 · orchestratortask blocked
Concept only: die UI schreibt keine Shell-Befehle. Aktionen erzeugen einen validierten Kanban-Command mit Audit-ID.
2 · Approval Inbox
Die wichtigste Teamansicht. Keine generischen Chat-Antworten, sondern begründete, evidenzverlinkte Entscheidungen mit erlaubten Folgen.
Human gateriskapprove / reject3 · Task Detail
Vollständiger Brief, Worker-Profil, Skill- und Prompt-Version, Kosten, Runs, GitLab-Links, Artefakte und ein klarer Stop/Retry-Button.
auditlogsevidence04 · Rollen, Rechte und harte Gates
Ein Agent ist nicht durch seinen Prompt sicher, sondern durch seine technischen Grenzen.
| Rolle | Darf | Darf nie | Typischer Output |
|---|---|---|---|
| Orchestrator | Events validieren, Tasks erstellen/routen, GitLab kommentieren | Code pushen, mergen, deployen, Prod-Secrets lesen | Kanban-Graph, Status, Gate-Anfrage |
| Research / Grill | Interview, Recherche, Decision Briefs schreiben | Code ändern oder Produktclaims freigeben | Idea Brief, Fragen, Quellen |
| Coder | isolierter Worktree, eigener Branch, Tests, Draft-MR | geschützte Branches, Merge, Deployment | kleiner, testbarer Draft-MR |
| Reviewer | Diff / CI lesen, Review kommentieren | Code schreiben oder eigene Befunde freigeben | Finding mit Datei, Impact, Repro, Testgap |
| Security | Scans/Fundstellen prüfen, Issues anlegen | Secretausgabe, Risiko selbst wegwinken | Risikoanalyse, Severity, Gate-Empfehlung |
| Mensch | Plan, Risiko, Merge, Deploy und Policies freigeben | — | nachvollziehbare Entscheidung |
Code-Write-Gate
1Autorisierter GitLab-Akteur oder UI-User fordert explizit @hermes fix an.
2Issue/MR trägt ein passendes Label, z. B. agent:implement.
3Plan und Akzeptanzkriterien existieren; Task ist nicht durch offene Security-/Privacy-Risiken blockiert.
4Coder erhält einen eigenen Worktree und begrenztes Token.
Merge-/Release-Gate
1Deterministische Checks: Format, Lint, Tests, Secret-, Dependency- und SAST-Scan.
2Unabhängiger Reviewer hat Logik und Testlücken geprüft.
3Security-Review bei Auth, Daten, Infra, Secrets, Migrationen oder externen Effekten.
4Mensch merge-t. Auto-Merge erst später, nur eng begrenzt und gemessen.
05 · Evaluation & kontrolliertes Lernen
„Selbstverbesserung“ ist ein Release-Prozess für Skills — kein Selbstumschreiben.
Run outcome / CI failure / Review finding / Incident
↓
structured lesson
↓
classify: shared | project-specific | temporary
↓
Skill / Prompt / AGENTS.md change as MR
↓
Eval corpus + baseline comparison
↓
Human review → versioned rollout
Was in den Eval-Korpus gehört
- alte MRs mit bekannten Review-Findings
- bewusst unsichere Codebeispiele
- historische CI-Fehler mit erwarteter Diagnose
- Bug-Repros und erwartete Regressionstests
- Prompt-Injection-Beispiele in Issues, MRs und Webinhalten
- Discovery-Entscheidungen mit späteren echten Outcomes
↑
Qualität
Recall bei echten Security-/Review-Findings, Testabdeckung, validierte Spike-Verdicts.
↓
Fehlalarme
Wie viele Review-Kommentare oder Triage-Tickets wurden vom Menschen verworfen?
€
Effizienz
Kosten und Laufzeit pro erfolgreichem, akzeptiertem Ergebnis — nicht pro Agentenrun.
↩
Sicherheit
Blockierte Aktionen, Retry-Schleifen, Kill-Switch-Nutzung, unzulässige Toolversuche.
06 · Was oft fehlt — aber für ein Team nötig ist
Diese Teile sind nicht glamourös, entscheiden aber darüber, ob das System operierbar bleibt.
Must-have vor produktivem Code-Write
✓SSO + RBAC: Teammitglied, Rolle und Aktion sind im Audit nachvollziehbar.
✓Webhook-Absicherung: HTTPS, GitLab-Secret, Label-/Actor-Filter und Idempotency-Key.
✓Sandboxing: Worker ohne Host-Docker-Socket, mit Runtime-, CPU-, Speicher- und Egress-Grenzen.
✓Secrets: projekt- und rollenbezogene Tokens; nichts in Skills, Logs, Prompt oder Git.
✓Kill Switch: global, pro Projekt und pro Worker; sichtbar im UI.
✓Retention & Backup: Kanban-/Audit-Daten sichern, Rohlogs und sensible Artefakte zeitlich begrenzen.
Nice nach dem bewiesenen Kernflow
+Budget Policies: Tagesbudget, Modell-Whitelist, WIP- und Parallelitätslimits pro Projekt.
+Incident Mode: Read-only Analyse, Evidence Bundle, menschliche Freigabe vor jeder Änderung.
+Environment Promotion: Dev → Staging → Prod mit separaten Tokens und Freigaben.
+Team Notifications: Slack/Matrix/Discord nur für echte Gates, Fehler oder Abschlüsse — kein Agenten-Spam.
+Model Routing: günstiges Modell für Triage, starkes Modell für Architektur/Security, Fallback bei Ausfall.
+Tenant-Isolation: wenn mehrere Kunden-/Teams/Repos strikt getrennt arbeiten sollen.
Größtes Risiko: Nicht „das Modell macht einen Syntaxfehler“, sondern dass untrusted Inhalte aus einem MR, Issue oder Webartikel als Anweisung behandelt werden. Deshalb: Content ist Datenmaterial; nur eure signierten und autorisierten Steuerpfade können Agentenaktionen auslösen.
07 · Realistische Bau-Reihenfolge
Erst die unsichtbare Zuverlässigkeit, dann die Factory-Optik.
Phase 0 · Agent Platform Repository
Gemeinsame Skills, Policies, Prompt-Quellen, Webhook-Filter und Eval-Fixtures in GitLab anlegen. Noch keine Coding-Automation.
Phase 1 · Read-only Product Lab
agent:grill → Idea Brief → Research/Spikes → Decision Brief. Alles landet als GitLab-Kommentar und Kanban-Historie. Kein Git-Push.
Phase 2 · Event-to-MR-Kernpfad
Ein Projekt, drei Rollen, Worktrees, Draft-MRs, CI und unabhängiger Review. Zuerst manuell mit dispatch --dry-run prüfen.
Phase 3 · Shared Server Operations
Caddy/SSO, GitLab-Service-Accounts, Sandbox, Secrets, Backups, Kill Switch und Audit-Ansicht. Erst jetzt Teamzugriff erweitern.
Phase 4 · Control Plane MVP
Pipeline, Task-Detail, Approval Inbox, Worker Status, GitLab-Verlinkung und Audit Timeline. Kein zweites GitLab, keine eigene CI-Engine.
Phase 5 · Gemessene Automation
Eval-Korpus, Skill-Release-Flow, Kosten-/Qualitätsmetriken und nur für wiederholt sichere Low-Risk-Fälle enger Auto-Flow.
Erster konkreter Trigger
So startet eine Idee heute, bevor die UI existiert.
# 1) Im Hermes-Chat: grill-me führt das Interview.
# 2) Der bestätigte Idea Brief wird als GitLab Issue in product-lab gespeichert.
# 3) Dann explizit Discovery starten:
hermes kanban create "Discovery: Privacy-first Schnarchtracker" \
--triage \
--assignee product-orchestrator \
--goal \
--goal-max-turns 12 \
--idempotency-key "idea:sleep-sound-tracker:v1"
# 4) Zuerst sehen, was starten würde:
hermes kanban dispatch --dry-run
# 5) Erst nach Prüfung echte Worker starten:
hermes kanban dispatch --max 3
Im Team ersetzt später ein GitLab-Issue mit agent:grill oder der „Neue Idee“-Button in der UI den manuellen CLI-Start. Der nachgelagerte Kanban-/Gate-Flow bleibt identisch.