nixos-config/docs/research/intent-board-architektur-ux-evaluation.md

Research-Bericht: Architektur-, UX- und Effizienzbewertung des Intent Boards

Stand: 07.09.2026
Status: COMPLETE
Untersuchungsart: statische Repository-Analyse und Webrecherche; keine Änderungen, keine Live-Abfragen auf blunix

Fragestellung

Ist das Intent Board mit seiner Agentenpipeline für den heutigen Zweck angemessen komplex, verständlich, iterierbar und ressourcenschonend? Insbesondere wurde geprüft:

• Kartenquellen, Phasen, Runtime-Wahl, Dispatch, Bearbeitung und Abschluss
• Architektur und mögliche Über- beziehungsweise Unterentwicklung
• Sichtbarkeit von Status, Ergebnissen, Fehlern und Verantwortlichkeiten
• Zerlegung in Unter-Intents, parallele Bearbeitung, Zusammenführung und Evaluation
• Rollen, Übergaben, Freigaben und Reviewmechanismen
• vorhandene Signale zur Maschinenqualität
• Aussagen und Datenlücken zu Token-, Laufzeit- und Kosteneffizienz

Methode

Repository-Analyse

Maßgeblich für Aussagen über den Projektzustand waren insbesondere:

• hosts/blunix/localServices/board-agent/{README.md,board.html,trigger.py,worker.py,completion_watcher.py,failure_handler.py,test_board_agent.py}
• hosts/blunix/localServices/board-agent.nix
• hosts/blunix/localServices/agent-codex/{README.md,builder.py,test_agent_codex.py}
• agents/{AGENTS.md,planner.md,builder.md,reviewer.md,researcher.md,admin.md,agent-manager.md,catalog.json}
• agents/tests/roles.sh
• docs/{pipelines.md,herdr-orchestration.md}
• relevante Intents, Research-Intents, Research-Berichte und Board-Reviewberichte
• Git-Status und jüngere Commit-Historie der Board-/Agentenartefakte

Es wurden keine Secrets oder privaten Pane-Transkripte gelesen.

Externe Quellen

Externe Quellen wurden nur für allgemeine Maßstäbe herangezogen:

• Official Kanban Guide, Kanban University
• WCAG 2.2: Understanding Dragging Movements, W3C
• WCAG 2.2: Understanding Keyboard, W3C
• How we built our multi-agent research system, Anthropic
• New tools for building agents, OpenAI
• How evals drive the next chapter in AI for businesses, OpenAI
• Measuring model performance on real-world tasks, OpenAI
• A shared playbook for trustworthy third-party evaluations, OpenAI

Quellenaussagen und Empfehlungen wurden auf den Stand des Abrufs geprüft. Herstellerangaben zu eigenen Agentensystemen sind keine unabhängigen Nachweise für dieses Projekt.

Tatsächlich ausgeführte Prüfungen

• vollständiges Lesen der maßgeblichen Rollen- und Repository-Anweisungen
• statische Analyse von Board-UI, API, Queue, Worker, Completion- und Fehlerpfad
• Sichtung der Testfallnamen und relevanter Testimplementierungen
• Abgleich von Dokumentation, Implementierung und vorhandenen Reviews
• Git-Status-, Historien- und Corpus-Inventur
• Webrecherche in aktuellen, möglichst primären Quellen

Nicht ausgeführt:

• Board-Bedienung im Browser
• Live-Status, Logs oder Zustandsdateien auf blunix
• Python-Unit-Tests: python3 ist in dieser Codex-Runtime nicht vorhanden
• Nix-Evaluation, Build, Deployment oder Service-Neustart
• tatsächliche Token-, Kosten-, Laufzeit- oder UX-Messung
• Änderungen an Dateien, Karten, Runtime-Schalter oder Systemzustand

Kurzurteil

Das System ist im sicherheits- und reproduzierbarkeitskritischen Kern überwiegend angemessen konstruiert: feste Pfade, validierte Slugs und Runtimes, atomare Queue-Übergaben, Runtime-Snapshots, read-only Reviewer/Researcher und klar getrennte Fehlerpfade sind für ein schreib- und deployfähiges Agentensystem gerechtfertigt.

Es ist jedoch asymmetrisch entwickelt:

• Gut bis angemessen entwickelt: Dispatch-Sicherheit, Artefaktgrenzen, Fehlerbehandlung und lineare Builder→Reviewer-Automation.
• Überentwickelt beziehungsweise teuer in der Pflege: zahlreiche überlappende Rollen-, README-, Intent- und Prozessbeschreibungen sowie mehrere miteinander gekoppelte Datei-Queues für einen derzeit seriellen Ein-Nutzer-Betrieb.
• Unterentwickelt: Board-UX, sichtbare Prozessregeln, zugängliche Bedienung, explizite Verantwortlichkeit, echte Unter-Intent-Orchestrierung, Ergebniszusammenführung und belastbare Evaluation.

Damit ist die Plattform kein unnötiger Gesamtentwurf, aber noch eher ein sicherer, dateibasierter Pipeline-Prototyp als ein ausgereiftes Intent- und Multi-Agenten-Steuerungssystem.

Direkt belegter Ist-Zustand

Kartenquellen und Zustand

Das Board vereinigt drei Kartentypen:

1. versionierte Intents aus docs/intent/*.md
2. versionierte Research-Intents aus docs/research-intent/*.md
3. manuelle Ideen ausschließlich aus /var/lib/board-agent/state.json

Phasen, Laufstatus, Runtime-Snapshot, Commit, Reports und Fehlerdetails werden als Overlay im privaten Runtime-State gespeichert. Fehlt eine Intent-Datei vorübergehend, kann eine validierte State-Kopie die Karte weiter anzeigen. Das schützt gegen das vorübergehende Verschwinden unversionierter Dateien während des Builder-Stash-Verfahrens.

Im untersuchten Arbeitsbaum lagen 30 Intent-, 15 Review-, 2 Research-Intent- und 4 Research-Berichtsdateien vor. Zahlreiche Intent- und Reviewdateien waren unversioniert. Deshalb ist Git allein derzeit keine vollständige Historie des sichtbaren Board-Corpus.

Implementierungs-Lifecycle

Für normale Intents existiert der Pfad:

Geplant → In Umsetzung → Builder → Commit/Deploy-Runner → Review → Geprüft oder Planung mit Feedback

Dabei gilt:

• Der Browser-Trigger erzeugt aus Geplant → In Umsetzung einen Board-Job.
• Der Board-Worker führt den Builder nicht selbst aus, sondern übersetzt den Job in die vorhandene agent-codex-Builder-Queue.
• Der Builder arbeitet im gemeinsamen Checkout, schützt ihn durch Lock und Stash und besitzt ein Iterationslimit.
• Bei einem Commit erzeugt die Completion-Pipeline einen Review-Job.
• Der Reviewer prüft den festgelegten Commit read-only und liefert ein markerbegrenztes Report-Artefakt.
• Die Reviewentscheidung bestimmt bereit_fuer_deployment oder planung_mit_feedback.
• Bei no_changes, check_failed, limit_reached oder anderen Builder-Endzuständen erfolgt kein automatischer Folge-Review; ein Builder-Bericht wird stattdessen auf der Karte angeboten.
• Rückwärtsbewegungen sind grundsätzlich möglich; übersprungene Vorwärtsphasen werden serverseitig verhindert.
• Archiviert ist ein bookkeeping-orientierter Endzustand. Reaktivierung muss über Geplant beziehungsweise Recherche angefordert erfolgen.

Für Research gilt separat:

Recherche angefordert → Recherche läuft → Recherche fertig oder Recherche fehlgeschlagen

Research erzeugt keinen Builder-Lauf. Der Worker startet die gespeicherte Runtime, extrahiert den Bericht und schreibt ausschließlich docs/research/<slug>.md.

Runtime-Wahl

Das Board speichert global exakt codex oder claude. Beim Jobstart wird die Auswahl in den Job kopiert; spätere Änderungen beeinflussen die laufende Builder-/Reviewer- beziehungsweise Research-Pipeline nicht. Freitext kann die Runtime nicht überschreiben.

Das ist eine starke Reproduzierbarkeits- und Prompt-Injection-Grenze. UX-seitig bleibt jedoch unklar, dass der Schalter global für alle neu gestarteten Jobs gilt und dass laufende Jobs ihren Snapshot behalten. Die gewählte Runtime wird zwar im State abgelegt, aber nicht auf der Karte angezeigt.

Parallelität

Board-Jobs für das Repository sind absichtlich serialisiert:

• Der Trigger verweigert einen neuen Board-Job, solange im Board-Inbox- oder Processing-Verzeichnis ein Job liegt.
• Review und Research verwenden einen gemeinsamen Repository-Lock.
• Der Builder verwendet zusätzlich Repository-Locks und arbeitet im gemeinsamen Checkout.
• Isolierte Worktrees oder Job-Branches sind ausdrücklich nicht implementiert.

Das passt zur dokumentierten Annahme eines einzelnen Operators und serieller Jobs. Es verhindert aber echte parallele Unter-Intent-Bearbeitung im selben Repository. Mehrere sichtbare Herdr-Spezialisten können konzeptionell parallel arbeiten, doch das Board modelliert oder koordiniert diese Fan-out-/Fan-in-Struktur nicht.

Rollen, Freigaben und Evaluation

Die Rollen sind eng getrennt:

• Planner: interaktive Bedarfsklärung, ein Intent-Artefakt
• Builder: Umsetzung, Commit/Push über Wrapper
• Reviewer: read-only Qualitätsprüfung
• Researcher: Repository-/Webrecherche, ein Bericht
• Administrator: technische Plattformänderungen und gegebenenfalls Aktivierung
• Agent-Manager: Rollen- und Vertragsänderungen
• Orchestrator: Delegation und Synthese im sichtbaren Herdr-Pfad

Die generische Herdr-Dokumentation kennt Rückfragen, Review-Risikoschwellen, Korrekturschleifen und Wiederverwendung von Panes. Die Board-Pipeline ist dagegen headless und enger:

• keine Rückfragen während Builder-, Reviewer- oder Researcher-Jobs
• keine automatische Planner-Rückkehr bei negativem Review
• keine automatische Builder-Korrektur
• keine formalisierte Synthese mehrerer Resultate
• keine separate Evaluationsstufe nach der Zusammenführung

Der Review ist eine fachlich wertvolle unabhängige Prüfung, aber noch keine End-to-End-Evaluation der Gesamtmaschine.

Architektur- und Komplexitätsbewertung

Gerechtfertigte Komplexität

Folgende Komplexität liefert konkreten Nutzen:

• Runtime-Snapshot: verhindert inkonsistente Modellwechsel innerhalb einer Pipeline.
• Markerbasierte Reports bei read-only Modellen: erhält enge Schreibgrenzen, während der Wrapper nur den vorgesehenen Bericht persistiert.
• Pfad- und Slug-Validierung: begrenzt den Zugriff auf feste Intent-/Reportorte.
• Atomare Queue-Dateien und inbox → processing → done/failed: machen Zustandsübergänge nachvollziehbar und wiederholbar.
• Completion- und Failure-Pfade: unterscheiden Builder-Ergebnis, Modellfehler, Vorstartfehler und Sandbox-Setup.
• Commitgebundener Review: begrenzt Reviewumfang und vermeidet eine erneute Volltextanalyse.
• Iterations- und Zeitlimits: begrenzen unbeaufsichtigte Agentenläufe.
• Trennung von Research und Umsetzung: verhindert, dass ein Rechercheauftrag versehentlich Codeänderungen auslöst.

Diese Mechanismen sind angesichts automatischer Commits, Pushes und des dokumentierten automatischen blunix-Deployments keine bloße Zeremonie.

Überentwickelte oder wartungsintensive Bereiche

Die technische Pipeline verteilt einen linearen Ablauf auf Trigger, Board-Worker, Builder-Queue, Deploy-Runner, Completion-Watcher, Review-Worker, Failure-Handler und mehrere Zustandsverzeichnisse. Das ist sicherheitsseitig nachvollziehbar, erzeugt aber hohe Zustands- und Dokumentationskosten.

Konkrete Symptome:

• README, Rollendateien, Pipeline-Dokumentation, Intent-Dokumente, Nix-Kommentare und Tests beschreiben dieselben Regeln teilweise mehrfach.
• Frühere Reviews zeigen wiederholt Abweichungen zwischen neuem Research-Pfad und bestehender Implementierung: zunächst fehlender Dispatch, falsche Modellvariablen, fehlende Schreibfreigabe und uneinheitliche Pfadprüfung.
• Die UI-Kopfzeile behauptet weiterhin, Geplant → In Umsetzung löse den „Admin-Agenten“ aus. Implementiert und dokumentiert ist inzwischen der Builder. Dies ist ein direkt belegter Dokumentations-/UX-Drift.
• Der Runtime-State ist nicht versioniert, während viele Quell- und Ergebnisartefakte unversioniert im Checkout liegen. Dadurch verteilen sich Historie und Wahrheit über Git und lokalen Zustand.

Schlussfolgerung: Nicht die Sicherheitsgrenzen, sondern ihre vielfache manuelle Beschreibung und die Zahl der Übergabeschichten sind der Hauptbereich möglicher Vereinfachung.

Unterentwickelte Bereiche

• keine WIP-Anzeige oder verständliche Kapazitätsanzeige
• keine sichtbaren Übergangsregeln oder „Warum nicht?“-Vorschau vor einem Drag
• keine Owner-/Verantwortlichkeitsanzeige
• keine Laufzeit-, Queue- oder Fortschrittsdetails
• keine Parent-/Child-Beziehung für Unter-Intents
• keine Abhängigkeits- oder Blockiert-durch-Beziehung
• keine Synthese- oder Evaluationskarte
• keine automatische Korrekturschleife
• keine messbare Definition von „Intent erfolgreich“
• keine aggregierte Flow-, Qualitäts-, Token- oder Kostenevidenz

UX-Bewertung

Positive Befunde

• Intent-, Builder-, Review-, Research- und Fehlertexte sind direkt von der Karte aus sichtbar.
• Reportinhalte werden mit textContent beziehungsweise in <pre> angezeigt und nicht als fremdes HTML interpretiert.
• Klickbare Textbereiche für Intent und Reports besitzen Tastaturbehandlung für Enter/Leertaste.
• Fehler werden mit Stufe und bereinigtem Kurzdetail auf der Karte zugänglich.
• Commit-Hashes sind sichtbar.
• Ungültige Übergänge werden serverseitig abgelehnt, nicht nur im Frontend versteckt.
• Archivierte Karten bleiben lesbar.

Wesentliche UX-Probleme

1. Zwölf gleichrangige Spalten vermischen zwei verschiedene Lifecycles.
   Intent- und Research-Phasen stehen in einem horizontalen Streifen. Der Benutzer muss fachlich inkompatible Spalten mental filtern. Kanban University empfiehlt, den tatsächlichen Workflow verständlich zu visualisieren; Swimlanes oder zusätzliche Dimensionen können Arbeitstypen trennen.

2. Drag-and-drop ist die einzige Phasenbedienung.
   Karten sind zwar draggable, besitzen aber keine Schaltfläche oder Auswahl für „in nächste Phase verschieben“. W3C WCAG 2.2 verlangt für Drag-Funktionen eine einfache Pointer-Alternative; vollständige Funktionalität muss außerdem per Tastatur erreichbar sein. Die vorhandenen Tastaturhandler betreffen nur Reportlinks, nicht Kartenübergänge.

3. Die sichtbare Erklärung ist falsch.
   Die Kopfzeile nennt den Admin-Agenten, tatsächlich wird der Builder ausgelöst. Gerade bei einem zustandsändernden System ist dies ein relevanter Vertrauens- und Verantwortlichkeitsfehler.

4. Statusbegriffe sind uneinheitlich.
   queued wird als „läuft…“ angezeigt, obwohl Queue und tatsächliche Ausführung unterschiedliche Zustände sind. Andere interne Werte wie queued_builder, queued_review, no_changes, check_failed oder limit_reached fallen auf Rohbezeichner zurück.

5. Keine Bestätigung vor folgenreichem Drag.
   Ein Drop von Geplant nach In Umsetzung startet einen schreibfähigen Builder-Pfad. Der Übergang besitzt keine explizite Zusammenfassung von Runtime, Ziel, Nebenwirkungen oder Verantwortlichkeit.

6. Globaler Runtime-Schalter ohne Geltungsbereich.
   Es wird nicht erklärt, dass er nur zukünftige Jobs betrifft. Ein kartenbezogener Snapshot ist nicht sichtbar.

7. Schwache Orientierung und Flow-Sichtbarkeit.
   Keine Kartenzähler, WIP-Limits, Filter, Suchfunktion, Gruppierung, aktuelle Queue oder klarer Commitment-/Delivery-Punkt sind sichtbar. Das Board zeigt Zustände, aber kaum Managementinformationen über den Fluss.

8. Polling ohne sichtbaren Aktualitätsstatus.
   Das Board lädt alle fünf Sekunden neu. Fehler beim Abruf erscheinen nur in der Browserkonsole; im UI fehlt „zuletzt aktualisiert“, Offline-/Fehlerbanner oder manuelles Retry.

Loopfähigkeit und Multi-Agenten-Eignung

Was heute funktioniert

Ein einzelner Intent kann linear geplant, gebaut, committed, überprüft und anhand der Reviewentscheidung zurück in die Planung geschickt werden. Research kann unabhängig einen Bericht erzeugen. Herdr besitzt außerhalb des Boards Rollen für Planung, Fachausführung, Review und Synthese.

Was für einen echten Loop fehlt

Ein gewünschter Ablauf

Parent-Intent → Unter-Intents → parallele Agenten → Resultate → Synthese → Evaluation → nächste Iteration

ist nicht als Board-Funktion vorhanden:

• kein Parent-/Child-Datenmodell
• keine Abhängigkeitsgraphen oder Join-Bedingungen
• keine Teilresultat-Schnittstelle
• kein Synthese-Owner
• kein Zustand „wartet auf Unter-Intents“
• keine Kriterien, wann ein Parent abgeschlossen ist
• keine Konfliktbehandlung zwischen parallelen Änderungen
• keine Worktree-Isolation
• keine automatische Folgeaktion nach negativem Review

Die bestehende Repository-Sperre verhindert parallele Board-Agentenläufe sogar bewusst. Das ist für den aktuellen Ein-Nutzer-Betrieb vernünftig, aber mit echter paralleler Umsetzung unvereinbar.

Anthropics eigener Produktionsbericht beschreibt Multi-Agenten-Systeme als besonders geeignet für breit parallelisierbare Recherche, warnt jedoch vor ungefähr 15-fachem Tokenverbrauch gegenüber Chats und vor Problemen bei stark voneinander abhängigen Aufgaben. Diese herstellerspezifischen Zahlen sind nicht auf dieses Projekt übertragbar, stützen aber die Entscheidung, Fan-out nur bei tatsächlich unabhängigen Teilfragen einzusetzen.

Angemessene Zielarchitektur

Nicht sofort ein allgemeines Multi-Agenten-DAG-System bauen. Zunächst genügt ein enges, explizites Kompositionsmodell:

• optionale parent_id
• blocked_by beziehungsweise depends_on
• definierter Ergebnislink
• ein benannter Synthese-Intent
• manuell ausgelöste Evaluation nach abgeschlossenen Kindern
• Parallelität zunächst nur für read-only Research-Unter-Intents
• Builder-Parallelität erst nach Entscheidung für isolierte Worktrees

Damit kann der wichtigste Loop erprobt werden, ohne sofort Scheduler, Konfliktauflösung und verteilte Transaktionen einzuführen.

Agentenqualität und Token-Effizienz

Belastbar vorhandene Signale

Direkt vorhanden sind:

• Queue-Endzustände und Fehlerklassen
• Builder-Abschlussbericht
• Commit-Hash
• Reviewentscheidung und Reviewbericht
• Research-Bericht
• Iterationslimit und Wall-Clock-Timeout
• persistente Deploy-Zustände im Builder-Pfad
• zahlreiche Unit-Testfälle
• historische Reviewberichte mit konkreten Blockern
• Git-Historie der Implementierung

Diese Signale können Einzelabläufe erklären und Regressionen dokumentieren.

Nicht belastbar ableitbar

Ohne zusätzliche Messbasis sind nicht belegbar:

• Erfolgsquote aller Board-Jobs
• mediane oder p95-Laufzeit
• Queue-Wartezeit und Cycle Time
• Anteil negativer Reviews oder notwendiger Nacharbeit
• Fehlklassifikationsrate der Reviewer
• Qualität von Codex gegenüber Claude
• Token- und Kosteneinsparung durch luna/none
• Nutzen des 20-Iterations-Limits
• Produktivitätsgewinn durch mehrere Agenten
• subjektive Bedienqualität des Boards
• Qualität des Gesamtsystems im realen Betrieb

Die reine Zahl vorhandener Intents und Reviews hat keinen vollständigen Nenner und keine standardisierte Outcome-Definition. Sie ist daher keine Qualitätsquote.

OpenAI empfiehlt für Agentensysteme End-to-End-Evaluationen, reale Aufgaben, klare Rubriken, Trace-Auswertung und regelmäßige menschliche Prüfung automatischer Grader. OpenAIs GDPval weist zudem darauf hin, dass automatische Grader Expertenurteile nicht zuverlässig ersetzen. Für dieses Projekt folgt daraus: Der vorhandene Reviewer ist ein Qualitätskontrollpunkt, aber keine ausreichende alleinige Messinstanz.

Bewertung der vorhandenen Effizienzregeln

Plausibel, aber noch nicht quantitativ belegt:

• feste Diff-Scope-Reviews statt Volltext-Repo-Reads
• günstiges Modell für eng definierte Board-Reviews
• atomare Sessions und Iterationslimit
• keine LLM-Nutzung im Dispatcher
• Wiederverwendung des bestehenden Builders statt einer zweiten Implementierung
• Runtime-Snapshot statt erneuter Auswahl in jeder Phase
• Spezialrollen mit engem Kontext und Schreibumfang

Potentiell ineffizient:

• vollständige Rollen- und Repository-Anweisungen werden in frischen headless Sessions erneut gelesen
• überlappende Dokumentation vergrößert Kontext und Drift-Risiko
• negative Reviews erzeugen keine strukturierte, kompakte Korrekturübergabe
• Builder- und Reviewberichte sind Freitext statt kleiner maschinenlesbarer Ergebniszusammenfassungen
• Unter-Intent-Zerlegung kann derzeit nur außerhalb des Boards manuell koordiniert werden

Es wurden keine realen Tokenersparnisse festgestellt oder behauptet.

Widersprüche und Unsicherheiten

• Die Board-README bezeichnet den Builder-Pfad korrekt; die sichtbare UI nennt weiterhin den Admin-Agenten.
• Die generische Herdr-Pipeline beschreibt sichtbare Spezialisten, Orchestrator-Synthese und risikobasiertes Review; die Board-Pipeline verwendet headless Läufe und automatisches Review jedes Builder-Commits.
• docs/pipelines.md beschreibt Review als nachgelagerte, nicht blockierende Prüfung. Das Board verwendet die Reviewentscheidung dagegen als Phasen-Gate zwischen „Review“, „Geprüft“ und „Planung mit Feedback“.
• Die Builder-Rolle verlangt grundsätzlich Prüfungen vor Commit, dokumentiert für nixos-config aber zugleich automatisches Deployment ohne vorherige Flake-/Build-Verifikation durch den Wrapper. Die genaue effektive Reihenfolge konnte ohne Live-Lauf nicht bestätigt werden.
• Dokumentierte frühere Reviewblocker können inzwischen behoben sein; mehrere spätere Commits sprechen dafür. Wegen fehlender Testausführung ist der aktuelle End-to-End-Zustand nicht unabhängig verifiziert.
• Die statische Analyse kann Bedienbarkeit, mobile Nutzung und tatsächlich gelebte Verantwortlichkeiten nur plausibilisieren, nicht messen.
• Die Umgebung datiert auf 07.09.2026; externe Quellen wurden nach aktuellem Abrufstand bewertet. Herstellerinterne Ergebnisse sind nur eingeschränkt generalisierbar.

Priorisierte Entscheidungsvorlage

Priorität	Empfehlung	Belegbasis	Erwarteter Nutzen	Trade-offs/Risiken	Nächste Entscheidung
P0	Board-Wahrheit und folgenreichen Übergang korrigieren: „Builder“ statt „Admin“, klare Bestätigung mit Karte, Runtime-Snapshot und Nebenwirkung vor Jobstart	Direkter Widerspruch zwischen board.html, README und Worker	Verhindert Fehlbedienung und stellt Verantwortlichkeit her	Ein zusätzlicher Klick bremst bewusste Starts geringfügig	Entscheiden, welche Informationen die Startbestätigung verbindlich zeigt
P0	Alternative zu Drag-and-drop anbieten, etwa kartenbezogenes „Weiter“-Menü mit zulässigen Übergängen und Tastaturbedienung	UI-Code; W3C WCAG 2.1.1 und 2.5.7	Mobile, Tastatur- und assistive Bedienbarkeit; weniger Fehl-Drops	Zusätzliche UI-Logik	Entscheiden, ob „nächster Schritt“-Button oder Statusauswahl bevorzugt wird
P0	Intent- und Research-Lifecycle visuell trennen, Archiv gemeinsam ans Ende; Filter oder Swimlanes statt zwölf gleichrangiger Spalten	12-Spalten-UI; Kanban-Guide zu realem Workflow und Swimlanes	Schnellere Orientierung und weniger Fehlzuordnung	Responsive Layout muss neu entschieden werden	Zwei Boards/Tabs gegenüber gemeinsamen Swimlanes evaluieren
P1	Kleine, explizite Prozesspolitik direkt am Board anzeigen: Startbedingung, WIP=1, automatische Schritte, manuelle Gates, Fehler-Recovery und Bedeutung der Runtime	Regeln existieren im Backend/README, nicht im UI; Kanban-Guide fordert sichtbare, einfache Policies	Verringert Wissensabhängigkeit von Repository-Dokumenten	Gefahr neuer Doku-Duplikation	Eine maschinennahe Policy-Quelle festlegen, aus der UI-Text und Tests abgeleitet werden
P1	Laufzustände vereinheitlichen: queued, running, waiting-for-builder, reviewing, failed, completed; Zeitstempel und „zuletzt aktualisiert“ anzeigen	State besitzt mehrere Rohstatus; UI mappt nur wenige	Bessere Diagnose und realistischere Fortschrittsanzeige	Erfordert saubere Statusmigration	Kanonisches Zustandsvokabular und Kompatibilitätsregel beschließen
P1	Minimalen Eval-Korpus definieren, bevor Modellprofile oder Agentenzahl optimiert werden	Vorhandene Tests/Reviews, aber keine Outcome-Baseline; OpenAI-Evalempfehlungen	Vergleichbare Qualität über Runtime-/Promptänderungen	Pflege eines kleinen Goldsets und menschliche Bewertung	10–20 reale, repräsentative Intentfälle plus Rubrik und Edge Cases auswählen
P1	Für jeden Lauf eine kompakte, datensparsame Ergebniszusammenfassung vorsehen: Outcome, Phase, Fehlerklasse, Reviewerentscheidung, Iterationslimit erreicht; Tokens/Kosten nur aufnehmen, wenn Runtime sie zuverlässig liefert	Heute verstreute Queue-/State-/Reportdaten	Erstmalig belastbare Erfolgs- und Nacharbeitsbasis	Datenschutz, Retention und Schemaaufwand; im aktuellen Auftrag nicht umzusetzen	Separaten Mess-/Datenschutz-Intent freigeben oder bewusst verwerfen
P2	Unter-Intent-Pilot nur für unabhängige Research-Aufgaben: Parent, Child, Abhängigkeit, Ergebnislink, manuelle Synthese/Evaluation	Research ist read-only; heutiges Board hat kein Fan-out/Fan-in; Anthropic warnt vor Tokenkosten	Erprobt Loopfähigkeit mit geringem Konfliktrisiko	Mehr Agenten können deutlich mehr Tokens verbrauchen	Einen konkreten Research-Fall mit 2–3 unabhängigen Teilfragen auswählen
P2	Builder-Parallelität erst nach Worktree-Entscheidung	Gemeinsamer Checkout, Locks und Stash erzwingen Serialität	Vermeidet Scheinkonzept von Parallelität und Mergekonflikte	Worktrees erhöhen Betriebs- und Aufräumkomplexität	Entscheiden, ob reale parallele Umsetzung überhaupt häufig genug gebraucht wird
P2	Negative Reviews in eine kleine strukturierte Korrekturübergabe überführen, aber Folge-Builder weiterhin manuell starten	Heute nur Phase „Planung mit Feedback“ und Freitextbericht	Weniger erneutes Kontextlesen, klarerer Loop	Struktur darf wichtige Nuancen nicht abschneiden	Felder severity, file, problem, acceptance_check pilotieren
P2	Dokumentationsduplikation reduzieren und Drift automatisch prüfen	Sichtbarer Admin/Builder-Widerspruch; viele parallele Regeltexte	Weniger Wartung und Kontextverbrauch	Zentrale Quelle kann schwerer lesbar werden	Festlegen, welche Datei pro Regelklasse maßgeblich ist; Tests nur gegen diese Quelle
P3	WIP-Limits und Flow-Metriken erst nach einer Beobachtungsbaseline kalibrieren	Backend erzwingt faktisch global WIP=1; Kanban empfiehlt datenbasierte Anpassung	Macht Kapazität und Engpässe sichtbar	Falsch gewählte Limits schaffen künstliche Blockaden	Zunächst Cycle-/Wait-Time und Blocker über begrenzten Zeitraum erfassen
P3	Modelle oder Reasoning nicht pauschal weiter absenken	Keine reale Token-/Qualitätsmessung; historisch scheiterte ein günstiger Claude-Reviewer am Reportformat	Verhindert unbelegte Sparmaßnahmen mit Qualitätsverlust	Kurzfristig keine garantierte Kostensenkung	Erst nach Eval-Korpus und realer Nutzungsbasis profilweise vergleichen

Vorgeschlagene Folge-Intents

Diese Vorschläge sind voneinander abzugrenzen und wurden nicht angelegt:

1. board-ux-transition-and-lifecycle-separation
   Korrigierte Verantwortlichkeit, Startbestätigung, zugängliche Übergangssteuerung und Trennung der beiden Lifecycles.

2. board-canonical-status-and-policy-model
   Kanonische Statusnamen, sichtbare Übergangspolitik, Aktualitätsanzeige und Vermeidung mehrfach gepflegter Regeltexte.

3. agent-pipeline-eval-baseline
   Kleiner repräsentativer Aufgabenbestand, Rubriken, menschliche Stichprobenprüfung und klar definierte Outcomes; noch keine dauerhafte Telemetrie.

4. research-subintent-fanout-fanin-pilot
   Parent-/Child-Modell ausschließlich für read-only Research, begrenzte Agentenzahl, manuelle Synthese und explizite Evaluation.

5. board-runtime-signal-measurement
   Separater Datenschutz- und Messentscheid zu Laufzeit-, Fehler-, Token- und Kostenfeldern; keine Umsetzung ohne vorherige Festlegung von Zweck, Zugriff und Aufbewahrung.

Fazit

Die Architektur ist nicht pauschal overengineered. Ihre Sicherheits-, Pfad-, Queue- und Reviewgrenzen sind für einen Agentenpfad mit Commit-, Push- und Deploymentfolgen weitgehend angemessen. Überproportional komplex ist die manuelle Vervielfachung derselben Regeln über viele Artefakte; unterentwickelt sind dagegen das sichtbare Board, die Bedienbarkeit und die Orchestrierung zusammengesetzter Intents.

Die höchste Priorität liegt daher nicht bei zusätzlicher Agentenparallelität oder billigeren Modellen, sondern bei korrekter und zugänglicher UX, einer sichtbaren Prozesspolitik und einer kleinen belastbaren Evaluationsbasis. Ein Multi-Agenten-Loop sollte anschließend kontrolliert mit unabhängigen Research-Unter-Intents erprobt werden. Reale Qualitäts-, Token- oder Effizienzgewinne können mit den heute verfügbaren Daten nicht belegt werden.