HiveGrid-Wireframes/01 Regeln/Screen Agent Workflow - Brainstorming.md

kind, project, area, status, validated

kind	project	area	status	validated
brainstorm	HiveGrid Screen Project	Agent Workflow	draft	false

Screen Agent Workflow - Brainstorming

Status: Draft / nicht validiert.

Diese Datei sammelt Ideen fuer die spaetere Agent-Arbeitsanweisung. Sie ist noch kein Regelwerk. Nichts aus dieser Datei gilt final, bis David die Inhalte validiert hat.

Ziel: klaeren, wie ein AI-Agent mit David an Wireframes, Flows, Screens, Canvas, Tracker und Subframe arbeiten soll.

---

Offene Brainstorming-Frage

Wie soll der Agent arbeiten, damit Screen-/Flow-Arbeit strukturiert, nachvollziehbar und synchron bleibt, ohne zu frueh etwas final zu bauen oder zu dokumentieren?

---

BMAD-kompakt fuer Screen-Arbeit

Noch nicht validierter Arbeitsrahmen:

Phase	Arbeitsname	Zweck	Status
B	Brief	Kontext, Ziel, Grenzen und relevante Quellen klaeren	Draft
M	Map	Flow, Varianten, States, Risiken und offene Entscheidungen sichtbar machen	Draft
A	Align	David entscheidet und validiert einzeln	Draft
D	Document	Nur validierte Entscheidungen synchron dokumentieren	Draft

---

Validierte Richtung

Thema	Entscheidung	Status
Research-Reihenfolge	Erst internes Planning/Tickets/Bestand lesen, danach gezielt externe Referenzen recherchieren, wenn offene Fragen bleiben oder der Screen es braucht.	von David validiert
Error-State-Verortung	Erst zentrale Error-State-Kandidatenliste im Flow-Brainstorming, danach validierte Error States bei den betroffenen Screens eintragen.	von David validiert
Error-State-Umsetzung	Error States werden standardmaessig dokumentiert, nicht als eigene Screens gebaut; Ausnahme nur, wenn der Error State fachlich extrem wichtig/blockierend/copy-kritisch ist.	von David validiert
Impact-Check bei neuem Screen/Flow	Wenn eine Aenderung vermutlich einen neuen Screen oder Flow braucht, startet der Agent einen Mini-Brainstorm mit Begruendung, Varianten und Empfehlung; erst danach entscheidet David.	von David validiert
Dependency-Check	Bei jedem Flow wird eine feste kurze Dependency-Liste geprueft, damit Verknuepfungen zu bestehenden Flows, zentralen Flows, Rollen/Sichtbarkeit, Error States, Canvas und Tracker sichtbar bleiben.	von David validiert
Planning vs. externe Referenz	Internes Planning bleibt Default. Wenn externe Referenzen ein klar besseres oder ueblicheres Pattern zeigen, muss der Agent den Widerspruch sichtbar machen und David entscheiden lassen.	von David validiert
Backlog	Agent sammelt aktiv Backlog-Kandidaten, aber nichts wird final als Backlog markiert, bevor David es validiert.	von David validiert
Subframe-Bau	Subframe wird nur nach explizitem OK fuer einen konkreten Screen oder Flow genutzt; davor bleibt die Arbeit in Obsidian.	von David validiert
Struktur-Sync	Jede strukturelle Aenderung wird sofort synchronisiert: Rename, Split, neuer Screen, geloeschter Screen, neuer Flow, Statuswechsel.	von David validiert
Commit/Push	Agent fragt vor Commit kurz nach, ausser David hat explizit gesagt, dass gemacht und gepusht werden soll.	von David validiert
Fragenstil	Agent gibt zuerst eigene Annahme und Empfehlung, dann eine gezielte Entscheidungsfrage.	von David validiert
Benennung	Agent unterscheidet Arbeitsnamen und strukturelle finale Namen. Sinnvolle Arbeitsnamen duerfen bleiben; wenn der Name strukturell wichtig oder unsicher ist, muss David validieren.	von David validiert
Bestand pruefen	Vor neuen Flows/Screens prueft der Agent aehnliche bestehende Flows, vorhandene Screens, wiederverwendbare Patterns und moegliche Konflikte.	von David validiert
Research-Ergebnisse	Research dient als Entscheidungsgrundlage. Relevante Ableitungen daraus muessen mit David abgestimmt und validiert werden, bevor sie in die Planung eingehen.	von David validiert
Detaillierungsgrad	Brainstorming darf ausfuehrlicher sein; finale Flow-/Screen-MDs bleiben kompakt und entscheidungsorientiert.	von David validiert
Scope-Fragen	Agent darf Scope-Erweiterungen aktiv vorschlagen, muss sie aber klar als Scope-Kandidat markieren und von David validieren lassen.	von David validiert
Screens vs. States	Canvas zeigt nur echte Screens, Modals oder Versionen davon. Toasts, Banner und reine Dokumentationsstates werden nicht als Canvas-Screen gebaut, muessen aber von David validiert und dokumentiert werden.	von David validiert
UX-Handoff	Agent plant keine Backend-Implementierung, nimmt aber UX-Verhalten, sichtbare Daten, Aktionen, Permissions, States und Flow-Logik vorweg und dokumentiert sie nach Davids Validierung.	von David validiert
Rollen/Permissions	Standardannahme ist Admin-Ansicht. Rollen/Permissions werden kurz geprueft, aber nur bei offensichtlicher Relevanz dokumentiert oder als offen/Backlog markiert.	von David validiert
Komponenten/Designsystem	Agent prueft vorhandene Komponenten/Patterns und richtet Screen-Dokumentation daran aus; unbekannte Komponenten werden als offene Komponentenfrage markiert.	von David validiert
Canvas-Lesbarkeit	Canvas ist Teil des Handoffs. Nodes und Kanten muessen lesbar, gruppiert und nachvollziehbar sein; nach strukturellen Aenderungen pruefen.	von David validiert
Subframe nach David-Aenderungen	Agent liest genannten Screen, fasst die fachliche Aenderung zusammen, macht Impact-Check auf direkt betroffene Screens/Flows und fragt vor weiteren Aenderungen nach.	von David validiert
Finale Datei	Brainstorming-Datei bleibt Herleitung/Archiv; finale Datei wird eine operative Checkliste fuer Agents.	von David validiert

---

Zu klaerende Punkte

Diese Fragen muessen gemeinsam entschieden werden:

1. Wie aktiv soll der Agent fuehren?
2. Wann soll der Agent stoppen und David entscheiden lassen?
3. Welche Fragen muss der Agent immer stellen?
4. Was darf der Agent eigenstaendig dokumentieren?
5. Was darf der Agent niemals ohne Freigabe tun?
6. Wie werden offene Entscheidungen und Backlog-Punkte markiert?
7. Wann wird Subframe genutzt?
8. Wann wird committed und gepusht?
9. Wie wird verhindert, dass Canvas, Tracker, Screen-Dateien und Paket-MD auseinanderlaufen?
10. Wie kompakt soll die finale Agent-Anweisung sein?

---

Research: Prompt-/Context-Engineering fuer finale Agent-Datei

Status: Research-Notiz / noch nicht final validiert.

Quellenrichtung:

• OpenAI empfiehlt klare Instruktionen am Anfang, Trennung von Instruktion und Kontext sowie konkrete Ausgabe-/Formatvorgaben.
• OpenAI GPT-5.x Prompt Guidance betont outcome-first Prompts, explizite Validation Rules, Tool-/Workflow-Erwartungen und klare Definition, wann eine Aufgabe fertig ist.
• Anthropic betont klare, strukturierte Prompts, explizite Tool-Nutzung, XML/strukturierte Abschnitte und Context Engineering fuer laenger laufende Agents.
• Anthropic Constitutional-AI-Arbeiten zeigen als allgemeines Muster, dass schriftliche Prinzipien/Regeln Verhalten steuern koennen; fuer uns bedeutet das: die finale Datei muss wie eine kleine Arbeitsverfassung funktionieren, nicht wie lose Notizen.

Ableitung fuer unsere finale Agent-Datei:

1. Finale Datei darf kein Brainstorming-Mix sein

   • keine offenen Diskussionen in der operativen Datei
   • nur validierte Regeln
   • offene Themen separat als Backlog/Offen markieren

2. Outcome zuerst

   • direkt am Anfang: Was soll der Agent erreichen?
   • nicht zuerst lange Historie
   • klarer Satz: Agent fuehrt David durch Screen-/Flow-Planung und haelt Artefakte synchron

3. Instruktionshierarchie sichtbar machen

   • MUST / NEVER / DEFAULT / WHEN klar trennen
   • harte Regeln vor optionalen Hinweisen
   • keine widerspruechlichen Regeln in verschiedenen Abschnitten

4. Fester Ablauf

   • Brief
   • Map
   • Align
   • Document
   • Sync
   • After-Change Impact Check

5. Checklisten statt Fliesstext

   • kurze Listen, die Agenten abarbeiten koennen
   • klare Entscheidungspunkte
   • klare Stop-Regeln

6. Output Contracts

   • fuer Brainstorming: Optionen + Empfehlung + David-Entscheidung
   • fuer Error States: Tabelle mit Ort, UI-Form/Komponente, Bauen?, Empfehlung, Entscheidung
   • fuer Dependencies: kurze Checkliste
   • fuer Sync: betroffene Artefakte

7. Grenzen klar markieren

   • Subframe nur nach OK
   • keine Backend-Implementierung planen
   • keine Screens/Flows finalisieren ohne David
   • keine fremden lokalen Aenderungen committen

8. Beispiele sparsam einsetzen

   • ein kleines Beispiel fuer Mini-Brainstorm
   • ein kleines Beispiel fuer Error-State-Tabelle
   • keine langen Beispiel-Flows

9. Finale Datei soll kurz bleiben

   • operative Datei wahrscheinlich 1.5-3 Seiten Markdown
   • Brainstorming-Datei bleibt Archiv

10. Validierungs- und Done-Kriterien

• Agent ist erst fertig, wenn validierte Entscheidungen dokumentiert und Sync geprueft sind
• bei Unsicherheit: David fragen
• bei neuer Screen-/Flow-Vermutung: Mini-Brainstorm statt direkt bauen

Noch von David zu validieren:

• Soll die finale Datei MUST / NEVER / DEFAULT / WHEN als explizite Labels verwenden?
• Soll die finale Datei eine kurze Beispielsektion enthalten?
• Soll BMAD als sichtbarer Begriff bleiben oder nur als interner Ablauf genutzt werden?

---

Notizen aus der aktuellen Arbeitsweise

• Flows werden einzeln behandelt.
• Screens werden einzeln validiert.
• Subframe darf nicht ohne konkrete Freigabe veraendert werden.
• Neue, umbenannte, geloeschte oder gesplittete Screens muessen in Paket-MD, Screen-Datei, Tracker und Canvas synchron bleiben.
• Backlog-Punkte muessen sichtbar bleiben.
• Bestehende Nutzer-Anpassungen duerfen nicht rueckgaengig gemacht werden.

---

Input von David - Agent-Aufgabe

Status: Brainstorming / nicht final validiert.

Der Agent soll zuerst das bestehende System verstehen:

• grosses Planning und Tickets als primaere Referenz lesen
• bestehende Flow- und Screen-Pakete pruefen
• vor neuen Flows/Screens nach aehnlichen bestehenden Flows, vorhandenen Screens und wiederverwendbaren Patterns suchen
• vorhandene Komponenten/Patterns pruefen, wenn sie fuer den Screen relevant sind
• vorhandene Entscheidungen, Backlog-Punkte und Dependencies erkennen
• pruefen, ob neue Flows mit bestehenden Flows kollidieren, sie erweitern oder mit ihnen verknuepft werden muessen
• bei jedem Flow eine kurze Dependency-Liste pruefen

Der Agent soll recherchieren und Referenzen einbeziehen:

• erst internes Planning/Tickets/Bestand lesen
• danach im Internet nach vergleichbaren UI-/Flow-Beispielen suchen, wenn offene Fragen bleiben oder der Screen es braucht
• Referenzen von David aufnehmen und in die Diskussion einordnen
• herausarbeiten, was normalerweise auf so einem Screen steht
• herausarbeiten, welche Aktionen, Zustaende, Modals und Folgeflows typischerweise gebraucht werden
• internes Planning bleibt Default; externe Patterns duerfen Planning nicht stillschweigend ueberschreiben
• wenn externe Referenzen klar bessere oder ueblichere Loesungen zeigen, muss der Agent den Widerspruch sichtbar machen und David entscheiden lassen
• relevante Research-Ableitungen muessen mit David abgestimmt und validiert werden, bevor sie in die Planung uebernommen werden

Der Agent soll David aktiv durch UI-Entscheidungen fuehren:

• nachfragen, ob bestimmte Funktionen in den Screen gehoeren
• sichtbar machen, was eventuell fehlt
• Alternativen und Empfehlungen formulieren
• eigene Annahme und Empfehlung nennen, bevor eine Entscheidungsfrage gestellt wird
• kleine UI-Entscheidungen einzeln klaeren
• nicht stillschweigend finalisieren, wenn Entscheidungen offen sind
• jede Entscheidung muss von David validiert werden
• potenzielle Scope-Erweiterungen als Scope-Kandidat markieren und validieren lassen
• Backlog-Kandidaten aktiv vorschlagen, aber erst nach Davids Validierung final als Backlog markieren
• fuer jeden Kandidaten klar unterscheiden: Screen, Modal, Version, Inline-State, Toast, Banner oder nur Dokumentation
• Toasts, Banner und Dokumentationsstates muessen validiert werden, werden aber nicht automatisch in Canvas als eigener Screen dargestellt

Benennungsrichtung:

• Arbeitsnamen duerfen pragmatisch verwendet werden, wenn sie sinnvoll und eindeutig sind.
• Wenn ein Name Auswirkungen auf Screen-Datei, Canvas, Tracker, Subframe oder Flow-Struktur hat, muss der Agent besonders vorsichtig sein.
• Wenn der Agent unsicher ist oder mehrere Benennungen moeglich sind, fragt er David.
• Strukturrelevante Renames muessen sofort synchronisiert werden.

Der Agent soll nach Validierung dokumentieren:

• Brainstorming und Entscheidungen in Obsidian strukturieren
• Brainstorming darf ausfuehrlicher sein als finale Dateien
• finale Flow-/Screen-MDs sollen kompakt, lesbar und entscheidungsorientiert bleiben
• Screen-Kandidaten erst nach Ruecksprache ableiten
• validierte Inhalte in Paket-MD, Screen-Dateien, Tracker und Canvas synchron halten
• strukturelle Aenderungen sofort in allen betroffenen Artefakten synchronisieren: Paket-MD, Screen-Dateien, Tracker, Canvas, Subframe-Link/Flow-Verweis
• Canvas nach strukturellen Aenderungen auf Lesbarkeit, Gruppierung, Kantenlabels und nachvollziehbare Verdrahtung pruefen
• sichtbare Daten, Aktionen, Sidebar-/Tab-/Listeninhalte, Permissions, States, Flow-Logik und offene UX-/Dev-Fragen dokumentieren
• keine Backend-Implementierung festlegen, aber klar beschreiben, wie es aus Nutzersicht funktionieren soll
• vorhandene Komponenten/Patterns benennen, wenn sie fuer den Screen relevant sind
• unbekannte oder fehlende Komponenten als offene Komponentenfrage markieren
• spaetere Aenderungen von David in Obsidian oder Subframe erkennen bzw. aufnehmen und in Obsidian nachziehen
• Error States erst nach Validierung in die MD aufnehmen
• bei jeder spaeteren Screen-Aenderung pruefen, ob Error States neu entstehen, wegfallen, sich verschieben oder anders dargestellt werden muessen
• bei spaeteren Obsidian-Aenderungen von David pruefen, ob Formulierung, Struktur und betroffene Screen-Dateien konsistent sind
• bei spaeteren Subframe-Aenderungen von David die relevanten geaenderten Screens per MCP lesen, fachlich abgleichen und Obsidian nachziehen

Backlog-Richtung:

• Agent sammelt aktiv, was fuer spaeter relevant sein koennte.
• Agent markiert Backlog-Kandidaten zuerst als Kandidat/offen.
• David validiert, ob es wirklich Backlog, raus, spaeter oder direkt Teil des Scopes ist.
• Erst danach wird ein Punkt final in die Backlog-/V2-Liste uebernommen.

Commit-/Push-Richtung:

• Vor Commit kurz Rueckfrage, wenn David nicht bereits klar gesagt hat, dass committed/gepusht werden soll.
• Wenn David explizit mach und push oder sinngemaess sagt, darf der Agent den validierten Arbeitsblock committen und pushen.
• Immer gezielt stagen; keine fremden lokalen Aenderungen mitnehmen.
• Vor Commit git status --short und Diff pruefen.

Subframe kommt erst spaeter:

• erst nach Planung und Validierung
• nur nach explizitem OK fuer konkreten Screen oder Flow
• ohne OK keine neuen Subframe-Screens, keine Edits und keine Loeschungen
• bestehende Nutzer-Anpassungen in Subframe respektieren
• wenn David Subframe-Aenderungen meldet, muss der Agent die Planung entsprechend abgleichen

---

Error-State-Pflicht

Status: Brainstorming / Richtung von David bestaetigt.

Der Agent muss selbststaendig eine Error-State-Liste fuehren, bevor final dokumentiert wird.

Diese Liste muss mindestens pruefen:

• Was kann fehlschlagen?
• Was blockiert den Nutzer?
• Was muss inline korrigiert werden?
• Was braucht ein Modal?
• Was braucht einen eigenen Screen?
• Was reicht als Toast oder Banner?
• Welche Error States sind sicherheitskritisch, rechtlich kritisch oder copy-kritisch?
• Welche Error States gehoeren in einen anderen Flow?

Regelrichtung:

• Error States werden aktiv gesammelt.
• David validiert jeden relevanten Error State.
• Erst validierte Error States werden in die Paket-MD oder Screen-Dateien uebernommen.
• Nicht validierte Error States bleiben als offene Kandidaten oder Backlog markiert.
• Error States werden normalerweise dokumentiert, nicht als eigene Screens gebaut.
• Ein einzelnes Feld kann mehrere Error States haben; daraus entstehen nicht automatisch mehrere Screens.
• Eigene Error-Screens entstehen nur, wenn der Zustand fachlich extrem wichtig, blockierend, sicherheitskritisch, rechtlich relevant oder copy-kritisch ist.
• Bei jeder spaeteren Screen-Aenderung muss gefragt werden: Hat diese Aenderung Einfluss auf Error States?
• Wenn ein Screen entfernt, ein Button ergaenzt, ein Schritt verschoben oder ein Flow verknuepft wird, muessen betroffene Error States geprueft und ggf. angepasst werden.
• Error States brauchen spaeter eine konkrete UI-Komponenten-Zuordnung aus dem vorhandenen Component-/Pattern-Set.
• Der Agent darf keine nicht vorhandenen Error-Komponenten erfinden, sondern muss vorhandene Komponenten/Patterns nutzen oder als offene Komponentenfrage markieren.
• Viele Error States koennen fuer Development ableitbar bleiben und muessen nicht als einzelne Screens vorgebaut werden.
• Wichtig ist, dass relevante Error-Richtung, UI-Form/Komponente und Copy-/Verhaltensnotiz dokumentiert und von David validiert sind.

Validierungsformat als Richtung:

Ereignis	Ort/Screen	UI-Form/Komponente	Bauen?	Empfehlung	David-Entscheidung
-	-	Inline / Banner / Toast / Modal / Screen / nur Dokumentation / offene Komponentenfrage	ja / nein	-	offen / validiert / raus / spaeter

Noch zu brainstormen:

• Welche Error-State-Komponenten und Patterns existieren?
• Welche UI-Form darf fuer welchen Error-Typ genutzt werden?
• Welche Error States duerfen nur dokumentiert werden?
• Welche Error States brauchen sichtbare Copy im Screen?

---

Spaetere Aenderungen durch David

Status: Brainstorming / Richtung von David bestaetigt.

Wenn David in Obsidian etwas aendert und den Agent darauf hinweist:

• Agent liest die betroffenen Dateien.
• Agent prueft, ob die Aenderung sprachlich, strukturell und fachlich konsistent ist.
• Wenn Screens betroffen sind, prueft der Agent die zugehoerigen Screen-Dateien.
• Wenn weitere Screens betroffen sein koennten, fragt der Agent nach, bevor er diese bearbeitet.
• Agent macht einen gezielten Impact-Check: Dependencies, Error States, Folgeaktionen, Backlog, Tracker, Canvas.

Wenn David in Subframe etwas aendert und den Agent darauf hinweist:

• Agent liest die von David genannten Screens per MCP.
• Agent vergleicht fachlich, was sich fuer den Flow geaendert hat.
• Agent fasst die fachlich relevante Aenderung kurz zusammen.
• Agent dokumentiert keine reine Aenderungshistorie.
• Agent zieht nur relevante Planungsinhalte nach: neue Buttons, geaenderte Aktionen, neue/entfallene States, neue Screens, geaenderte Namen, geaenderte Routes, geaenderte Dependencies.
• Agent prueft, ob durch die Subframe-Aenderung neue Fragen entstehen, z. B. ob ein Button einen neuen Screen, ein Modal, einen Toast oder einen Error State braucht.
• Wenn die Aenderung weitere Screens betrifft, fragt der Agent nach, bevor er diese Screens bearbeitet.
• Wenn durch eine Aenderung vermutlich ein neuer Screen oder Flow noetig wird, legt der Agent nichts direkt an. Er startet zuerst einen Mini-Brainstorm:
  • Warum koennte ein neuer Screen/Flow noetig sein?
  • Welche Varianten gibt es?
  • Welche Empfehlung hat der Agent?
  • Welche Entscheidung trifft David?

---

Dependency-Check

Status: von David als Richtung validiert.

Bei jedem Flow prueft der Agent kurz:

• Startet dieser Flow einen anderen Flow?
• Wird dieser Flow von einem anderen Flow gestartet?
• Nutzt oder beruehrt er zentrale Auth-/Account-/Admin-Flows?
• Aendert er Berechtigungen, Rollen oder Sichtbarkeit?
• Erzeugt oder veraendert er Error States in anderen Flows?
• Gibt es bestehende Screens, Modals oder States, die wiederverwendet werden koennen?
• Muss Canvas oder Tracker mit einem anderen Flow verlinkt werden?
• Gibt es eine Kollision mit bestehenden Namen, Screens, Routen oder Subframe-Seiten?

Regelrichtung:

• Der Check bleibt kurz.
• Wenn eine Dependency relevant ist, wird sie im Brainstorming markiert.
• Wenn daraus ein neuer Screen/Flow entstehen koennte, startet der Agent zuerst einen Mini-Brainstorm und fragt David.
• Keine stillen Verknuepfungen und keine stillen neuen Screens.

---

Canvas- und Screen-Abgrenzung

Status: von David als Richtung validiert.

Canvas bildet nur ab:

• echte Screens
• echte Modals
• echte Versionen/Varianten eines Screens oder Modals, wenn sie als eigener Arbeitsmoment gelten

Canvas bildet normalerweise nicht als eigenen Screen ab:

• Toasts
• Banner
• Inline-States
• reine Dokumentation
• normale Field-Validation
• kleine Error States, die Development aus dem Form-/Input-Pattern ableiten kann

Regelrichtung:

• Auch nicht gebaute States muessen validiert werden, wenn sie fuer UX, Copy, Fehlerverhalten oder Development relevant sind.
• Der Agent dokumentiert sie bei Flow oder Screen, aber legt keine Canvas-Nodes dafuer an.
• Jede echte Version, die als eigener Screen/Modal gelten soll, braucht eigene Screen-Datei, Tracker-Zeile und Canvas-Node.
• Der Agent muss kurz begruenden, warum ein Kandidat Screen, Modal, Version, Toast, Banner, Inline-State oder nur Dokumentation ist.

---

UX-Handoff statt Backend-Planung

Status: von David als Richtung validiert.

Der Agent plant nicht, wie etwas technisch im Backend umgesetzt wird.

Der Agent soll aber aus UX-/Produkt-Sicht vorwegnehmen und dokumentieren:

• welche Daten sichtbar sind
• welche Daten in Sidebars, Listen, Tabellen, Tabs, Modals und Details stehen
• welche Aktionen verfuegbar sind
• was beim Klick auf Buttons passiert
• welche Rollen/Permissions etwas sehen oder ausfuehren duerfen
• welche States, Error States und leeren Zustaende es gibt
• wie ein Flow startet, weitergeht, verzweigt und endet
• welche anderen Flows beruehrt oder gestartet werden
• welche Fragen fuer Development offen bleiben

Regelrichtung:

• Es wird beschrieben, wie es fuer Nutzer funktionieren soll.
• Technische Umsetzung bleibt Development.
• Research und Davids Entscheidungen klaeren, was in die UX gehoert.
• Alles Relevante wird erst nach Davids Validierung final dokumentiert.

---

Rollen und Permissions

Status: von David als Richtung validiert.

Standardannahme:

• Screens werden erstmal als Admin-Ansicht geplant.
• Der Agent soll Rollen/Permissions kurz mitdenken, aber nicht jeden Flow dadurch aufblaehen.

Dokumentiert wird nur, wenn:

• offensichtlich nicht jeder Zugriff haben sollte
• Admin vs. Nicht-Admin sichtbar andere UX erzeugt
• eine Aktion besonders kritisch ist
• eine Permission-Frage fuer spaeter offen bleibt

Regelrichtung:

• Offensichtliche Rechtefragen als offene Frage oder Backlog markieren.
• Keine vollstaendige Permission-Matrix pro Flow erzwingen.
• Wenn ein Flow explizit RBAC/Permissions behandelt, gelten natuerlich die detaillierteren Regeln des jeweiligen Flow-Pakets.

---

Komponenten und Designsystem

Status: von David als Richtung validiert.

Der Agent soll vorhandene Komponenten und UI-Patterns beruecksichtigen.

Regelrichtung:

• Vor neuen oder komplexeren Screens pruefen, ob passende Komponenten/Patterns existieren.
• Screen-Dokumentation an vorhandenen Komponenten/Patterns ausrichten.
• Keine Komponenten erfinden, wenn nicht klar ist, dass es sie gibt.
• Wenn eine Komponente gebraucht wird, aber unklar ist, ob sie existiert, als offene Komponentenfrage markieren.
• Error-State-Komponenten spaeter separat brainstormen und danach fuer Error-State-Dokumentation nutzen.

---

Canvas-Lesbarkeit

Status: von David als Richtung validiert.

Canvas ist Teil des Handoffs, nicht nur eine Ablage.

Regelrichtung:

• Nodes muessen lesbar angeordnet sein.
• Kanten duerfen nicht unnoetig unlesbar kreuzen.
• Kantenlabels sollen kurz und verstaendlich sein.
• Zusammenhaengende Bereiche sollen gruppiert werden.
• Dokumentierte States/Backlog duerfen getrennt vom Hauptflow stehen.
• Nach strukturellen Aenderungen muss Canvas auf JSON-Validitaet und Lesbarkeit geprueft werden.

---

Ergebnis spaeter

Nach der Brainstorming-Session soll daraus eine kompakte, validierte Agent-Anweisung entstehen, z. B.:

• 01 Regeln/Screen Agent Workflow.md
• plus kurzer Verweis in AI README.md
• Brainstorming-Datei bleibt als Herleitung/Archiv bestehen.
• Finale Datei wird kurz, operativ und checklistenartig.