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

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

## Ziel

Eine belastbare, priorisierte Entscheidungsvorlage erstellen, die das Intent
Board, die zugehörige Agentenpipeline und die Maschine als Gesamtsystem
bewertet. Im Fokus stehen angemessene Komplexität, Architektur, Nutzungserlebnis,
Iterierbarkeit sowie ein qualitativ guter Einsatz von Agenten bei möglichst
geringem Tokenverbrauch.

## Board-Runtime

- Für diesen Research-Job vor dem Start im Board die Runtime `codex` wählen.
- Die Runtime ist eine Ausführungsentscheidung für diesen Auftrag; sie ist
  keine Aussage über die generelle Eignung von Codex oder Claude.

## Umfang

- Den aktuellen Board-Aufbau und die dokumentierte sowie implementierte
  Lifecycle-Logik untersuchen, einschließlich Kartenquellen, Phasen,
  Runtime-Wahl, Dispatch, Bearbeitung und Abschluss.
- Bewerten, ob die Architektur für ihren Zweck überentwickelt, angemessen oder
  unterentwickelt ist; dabei Alternativen, Nutzen und Kosten der vorhandenen
  Komplexität konkret benennen.
- Das UX des Boards und der zugehörigen Arbeitsabläufe bewerten: Verständlichkeit
  von Status und Übergängen, Sichtbarkeit von Ergebnissen, Fehlern und
  Verantwortlichkeiten sowie Bedienbarkeit im täglichen Planungsablauf.
- Die Loopfähigkeit bewerten: ein Intent in mehrere Unter-Intents aufteilen,
  diese koordiniert von mehreren Agenten bearbeiten lassen, Resultate wieder
  zusammenführen und anschließend prüfen beziehungsweise evaluieren.
- Die vorhandenen Rollen, Übergaben, Freigaben und Evaluationsschritte darauf
  prüfen, ob sie Parallelität und Qualität ermöglichen, ohne unnötige Agenten-
  oder Planungstokens zu verbrauchen.
- Feststellen, welche bereits verfügbaren Board-, Repository- oder
  Laufzeitsignale Aussagen über die Qualität der Maschine erlauben und welche
  Behauptungen ohne eine spätere Messbasis offenbleiben müssen.
- Ansätze für besonders gute Planung und minimale, zweckgebundene
  Agentennutzung bewerten. Tokenersparnisse nur dann als Tatsache darstellen,
  wenn sie durch Quellen oder vorhandene Daten belegt sind.

## Quellenanforderungen und Methode

- Das Repository ist die maßgebliche Quelle für den tatsächlichen Aufbau und
  Zustand dieser Plattform. Relevante Board-, Rollen-, Pipeline-, Test- und
  Dokumentationsdateien werden systematisch untersucht.
- Mehrere aktuelle, möglichst primäre externe Quellen zu UX für Workflow- und
  Kanban-Systeme, Multi-Agenten-Orchestrierung sowie Agenten-Evaluation
  einbeziehen. Externe Quellen stützen allgemeine Empfehlungen, nicht Aussagen
  über den konkreten Projektzustand.
- Da der Auftrag über den Codex-Pfad läuft, keine Live-Shell-Abfragen auf
  blunix voraussetzen. Fehlende Live-Daten als Einschränkung benennen.
- Im Bericht direkt belegte Fakten, daraus abgeleitete Schlussfolgerungen und
  offene Fragen klar voneinander trennen. Widersprüche zwischen Quellen
  ausdrücklich darstellen.

## Ergebnisformat

- Genau einen nachvollziehbaren Research-Bericht unter `docs/research/<slug>.md`
  mit Fragestellung, Methode, Quellen, Befunden, Unsicherheiten und Fazit
  erstellen.
- Eine priorisierte Entscheidungsvorlage ergänzen. Jede Empfehlung nennt
  Belegbasis, erwarteten Nutzen, Trade-offs beziehungsweise Risiken und die
  nächste zu treffende Entscheidung oder einen späteren Umsetzungsbedarf.
- Falls sinnvoll, mögliche Folge-Intents nur als Vorschläge mit klarer
  Abgrenzung nennen. Keine zusätzlichen Intent-Dateien anlegen.

## Explizit ausgeschlossen

- Keine Änderungen an Board, Agenten, Rollen, Konfiguration, Tests oder
  Machine-Setup.
- Keine Telemetrie, kein Datenschema, keine Instrumentierung und keine
  tatsächliche Auswertung von Nutzungs-, Token-, Kosten- oder Laufzeitdaten.
- Keine Board-Kartenverschiebung, keine Änderung des Board-Runtime-Schalters
  durch diesen Auftrag und kein Start weiterer Jobs.
- Keine Commits, Pushes, Deployments oder Aktivierungen.

## Annahmen

- Der Board-Research-Dispatch kann den Auftrag im Codex-Pfad ausführen und den
  resultierenden Bericht unter `docs/research/` ablegen.
- Die vorhandenen Repository-Artefakte reichen für eine fundierte
  Architektur- und Prozessbewertung, nicht jedoch für Aussagen über reale,
  aggregierte Maschinen- oder Tokenleistung.

## Offene Risiken

- Ohne Live- und Verlaufsdaten kann die Recherche nicht feststellen, ob die
  Maschine in der Praxis gut oder schlecht arbeitet; sie kann nur die
  vorhandene Evidenz, Datenlücken und daraus ableitbare nächste Entscheidungen
  bewerten.
- Externe Best Practices können von den Sicherheits-, Rollen- und
  Reproduzierbarkeitsgrenzen dieser Plattform abweichen. Empfehlungen müssen
  diese Unterschiede ausdrücklich abwägen.
- Eine statische Repository-Analyse kann gelebte Interaktion, subjektives UX
  und tatsächliche Agentenqualität nur begrenzt belegen.

## Erfolgskriterien

- Jeder Fokusbereich dieses Auftrags ist anhand konkreter Quellen bewertet:
  Architektur, Overengineering, UX, Unter-Intent-Zerlegung, Zusammenarbeit
  mehrerer Agenten, Zusammenführung, Evaluation, Datenlage und Token-Effizienz.
- Der Bericht macht klar, welche Aussagen über die Maschinenqualität heute
  belastbar sind und welche eine spätere Messung erfordern.
- Die Entscheidungsvorlage ist priorisiert, umsetzungsnah und benennt für jede
  Empfehlung Nutzen, Trade-offs und eine nächste Entscheidung.
- Der Bericht behauptet weder reale Tokenersparnisse noch Qualitätsurteile ohne
  ausreichenden Beleg.
- Der Auftrag bleibt eine reine Untersuchung und erzeugt außer seinem
  Research-Bericht keine Änderungen am System.