Upload Hivegrid wireframes

01 Regeln/Screen Agent Workflow - Brainstorming.md

@@ -0,0 +1,480 @@
+---
+kind: brainstorm
+project: HiveGrid Screen Project
+area: Agent Workflow
+status: draft
+validated: 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.

01 Regeln/Screen Agent Workflow.md

@@ -0,0 +1,282 @@
+---
+kind: rule
+project: HiveGrid Screen Project
+area: Agent Workflow
+status: active
+validated: true
+---
+
+# Screen Agent Workflow
+
+Use this file for all HiveGrid screen, flow, Canvas, tracker and Subframe planning work.
+
+Outcome: The agent guides David through UX screen/flow planning, validates every decision with David, documents only validated outcomes, and keeps Obsidian, Tracker, Canvas and Subframe references synchronized.
+
+This file is the operative checklist. `Screen Agent Workflow - Brainstorming.md` is only the archive and must not override this file.
+
+---
+
+## MUST
+
+- MUST read the relevant Planning, tickets, existing flow package, screen files, tracker and Canvas before proposing changes.
+- MUST check for similar existing flows, screens, reusable patterns and naming conflicts before creating a new flow or screen.
+- MUST use internal Planning as the default source of truth.
+- MUST use external research only as decision support, and validate relevant research-derived ideas with David before they enter planning.
+- MUST give an assumption and recommendation before asking David a decision question.
+- MUST have David validate every product, UX, screen, state, backlog, scope and research-derived decision.
+- MUST keep one small flow or screen package in focus at a time.
+- MUST maintain Error-State candidates for every flow and validate them with David.
+- MUST document UX behavior: visible data, actions, states, permissions, dependencies and flow logic.
+- MUST avoid backend implementation decisions; Development decides technical implementation.
+- MUST sync structural changes immediately across package MD, screen files, tracker, Canvas and Subframe links.
+- MUST keep Canvas readable: grouped, labeled, non-confusing and JSON-valid.
+- MUST ask before committing, unless David explicitly said to commit/push or clearly asked to "mach und push".
+
+---
+
+## NEVER
+
+- NEVER finalize unvalidated decisions.
+- NEVER silently create, delete, rename or split screens.
+- NEVER build or edit Subframe without explicit OK for the concrete screen or flow.
+- NEVER overwrite or revert David's manual changes in Obsidian or Subframe.
+- NEVER let external examples override internal Planning without making the conflict visible and asking David.
+- NEVER create Canvas nodes for normal Toasts, Banners, Inline States, field validation or pure documentation states.
+- NEVER invent unavailable components; mark them as open component questions.
+- NEVER commit unrelated local changes such as `.obsidian/workspace.json` or unrelated Canvas edits.
+
+---
+
+## DEFAULTS
+
+- DEFAULT view is Admin unless the flow clearly requires a non-admin variant.
+- DEFAULT for roles/permissions: think about them briefly, document only if visibly relevant or risky.
+- DEFAULT for Error States: document them, do not build individual screens for every field error.
+- DEFAULT for Backlog: collect candidates, but only mark final Backlog after David validates.
+- DEFAULT for working names: keep sensible names, but validate if the name affects files, Canvas, Tracker, Subframe or flow structure.
+- DEFAULT for final MDs: compact, decision-oriented and readable.
+- DEFAULT for Brainstorming/Draft files: more detailed is allowed.
+
+---
+
+## Workflow
+
+### 1. Brief
+
+Before proposing screens:
+
+- Identify ticket/module, user goal, flow start and flow end.
+- Read relevant Planning, tickets, existing package MDs, screen files, tracker and Canvas.
+- Check whether this is a new flow, existing flow change, screen, modal, state or documentation-only item.
+- Check similar flows/screens and possible reuse.
+- Mark assumptions and unknowns.
+
+### 2. Map
+
+Build the working map before final decisions:
+
+- Happy path.
+- Branches and blockers.
+- Screen candidates.
+- Modal candidates.
+- Toast/Banner/Inline/documentation states.
+- Error-State candidates.
+- Dependency candidates.
+- Scope candidates.
+- Backlog candidates.
+- Component/pattern questions.
+
+Do not finalize this map without David.
+
+### 3. Align
+
+Present decisions in small validated chunks.
+
+Use this pattern when there are alternatives:
+
+| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
+|---|---|---|---|---|
+| A | - | - | - | - |
+| B | - | - | - | - |
+
+Then get David's decision:
+
+| Entscheidung | Status | Notiz |
+|---|---|---|
+| - | genommen / spaeter / raus / unklar / Backlog | - |
+
+For every screen/state candidate, clarify:
+
+- Is it a Screen, Modal, Version, Inline State, Toast, Banner or documentation-only?
+- Does it need Canvas?
+- Does it need a screen file?
+- Does it need Subframe?
+- Does David validate it?
+
+### 4. Document
+
+Only document validated outcomes as final planning.
+
+Document:
+
+- Goal and user task.
+- Visible data.
+- Actions and button outcomes.
+- UX flow logic.
+- States and validated Error States.
+- Dependencies.
+- Component/pattern notes.
+- Scope decisions.
+- Validated Backlog.
+- Open questions.
+
+Do not write backend architecture or implementation details.
+
+### 5. Sync
+
+For every structural change, update all relevant artifacts in the same work block:
+
+- Package MD.
+- Screen file.
+- `02 Wireframes/Screen Paket Tracker.md`.
+- Canvas.
+- Subframe link/flow reference, if applicable.
+
+Then check:
+
+- Search for old names/paths/links with `rg`.
+- Validate changed Canvas JSON.
+- Check Canvas readability.
+- Run `git status --short`.
+- Stage only intended files.
+
+### 6. After-Change Impact Check
+
+When David says he changed something in Obsidian:
+
+- Read the affected files.
+- Check wording, structure and affected screen files.
+- Check whether related screens need edits.
+- Ask before editing further screens.
+
+When David says he changed something in Subframe:
+
+- Read the named screen(s) via MCP when MCP is available.
+- Summarize only the fachlich relevant change.
+- Do not create a changelog.
+- Update Obsidian only for relevant planning changes.
+
+Always ask:
+
+- Does this create or remove an Error State?
+- Does this create or remove a dependency?
+- Does this change a button outcome?
+- Does this create a new Modal, Toast, Banner, Screen or Flow?
+- Does this affect Canvas, Tracker or Subframe links?
+
+If a new screen or flow might be needed, do not create it directly. Start a Mini-Brainstorm first.
+
+---
+
+## Error States
+
+The agent is responsible for finding Error-State candidates. David validates them.
+
+Default: Error States are documented, not built as separate screens.
+
+Own Error Screens only when the state is:
+
+- blockierend
+- fachlich extrem wichtig
+- security-critical
+- legally/copy critical
+- a new mental step for the user
+
+Use this table:
+
+| Ereignis | Ort/Screen | UI-Form/Komponente | Bauen? | Empfehlung | David-Entscheidung |
+|---|---|---|---|---|---|
+| - | - | Inline / Banner / Toast / Modal / Screen / Dokumentation / offene Komponentenfrage | ja / nein | - | offen / validiert / raus / spaeter |
+
+Rules:
+
+- One field can have multiple Error States.
+- Do not create several screens for normal input validation.
+- Assign existing components/patterns when known.
+- If the component is unknown, mark `offene Komponentenfrage`.
+
+---
+
+## Dependency Check
+
+For every flow, quickly check:
+
+- Does this flow start another flow?
+- Is this flow started by another flow?
+- Does it touch central Auth, Account, Admin or Settings flows?
+- Does it change roles, permissions or visibility?
+- Does it create or change Error States in another flow?
+- Can an existing screen, modal or state be reused?
+- Should Canvas or Tracker link to another flow?
+- Are there name, route, screen or Subframe conflicts?
+
+If a dependency could create a new screen/flow, start a Mini-Brainstorm and ask David.
+
+---
+
+## Canvas Rules
+
+Canvas shows:
+
+- real Screens
+- real Modals
+- real Versions/Variants when they are own work moments
+
+Canvas does not show as own nodes:
+
+- Toasts
+- Banners
+- normal Inline States
+- field validation
+- documentation-only states
+
+Still validate and document relevant non-Canvas states with David.
+
+---
+
+## Subframe Rules
+
+Subframe is used only after David explicitly approves a concrete screen or flow.
+
+Before Subframe work:
+
+- Validated screen list exists.
+- Screen purpose is clear.
+- Existing Subframe screens are checked if needed.
+- Existing David changes are respected.
+
+After Subframe work:
+
+- Update screen file frontmatter/link.
+- Update package MD.
+- Update tracker.
+- Update Canvas if structure changed.
+- Verify Dialog/Modal screens use real Dialog/Page Layout patterns, not simulated cards.
+- For every Modal/Dialog screen, explicitly instruct Subframe to use `DialogLayout` -> `Dialog` -> `Dialog.Content`; never accept a fake modal built from `Card`, an absolute overlay, blur background or a full page wrapper.
+- Before handoff, read the page with `get_page_info` and confirm the JSX imports `Dialog` and contains `Dialog.Content`.
+
+---
+
+## Done Criteria
+
+The agent is done only when:
+
+- David validated the relevant decisions.
+- Validated decisions are documented.
+- Error-State candidates were considered and validated or left open.
+- Dependencies were checked.
+- Structural changes are synced across files.
+- Canvas is valid and readable if changed.
+- Subframe links are updated if Subframe was used.
+- Git status was checked.
+- Commit/push handling follows David's instruction.