Upload Hivegrid wireframes

.obsidian/workspace.json

@@ -15,9 +15,9 @@
               "state": {
                 "file": "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas",
                 "viewState": {
-                  "x": 893.2958606826328,
-                  "y": 1014.1714018415311,
-                  "zoom": -0.35771249981815517
+                  "x": 1957.9246249982489,
+                  "y": 721.10076308881,
+                  "zoom": -1.4901064138147808
                 }
               },
               "icon": "lucide-layout-dashboard",
@@ -188,9 +188,28 @@
   },
   "active": "716943f64774c290",
   "lastOpenFiles": [
-    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md",
-    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas",
+    "01 Regeln/Screen Agent Workflow.md",
+    "01 Regeln/Screen Agent Workflow - Brainstorming.md",
     "02 Wireframes/P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas",
+    "02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas",
+    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md",
+    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04 Rolle anlegen Zwischenschritt.md",
+    "hivegrid-cloud/tests/e2e/tasks.spec.ts",
+    "hivegrid-cloud/tests/e2e/files.spec.ts",
+    "hivegrid-cloud/prisma/schema/tasks.prisma",
+    "hivegrid-cloud/prisma/schema/files.prisma",
+    "hivegrid-cloud/prisma/schema/entityLinks.prisma",
+    "hivegrid-cloud/prisma/rls/task-isolation.sql",
+    "hivegrid-cloud/prisma/rls/file-isolation.sql",
+    "hivegrid-cloud/prisma/migrations/20260624120000_p4b_tasks_entitylinks/migration.sql",
+    "hivegrid-cloud/prisma/migrations/20260624120000_p4b_tasks_entitylinks",
+    "hivegrid-cloud/prisma/migrations/20260623160000_p4a_files_platform/migration.sql",
+    "AI README.md",
     "02 Wireframes/Screen Paket Tracker.md",
     "02 Wireframes/P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas",
     "02 Wireframes/P2 Auth/WF-P2 Passwort Reset/WF-P2 Passwort Reset.canvas",
@@ -214,24 +233,6 @@
     "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D01 Rollen-Dropdown in Mitarbeiterliste.md",
     "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md",
     "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md",
-    "02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/WF-P2 Profil und Sicherheit.md",
-    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas",
-    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md",
-    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md",
-    "02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Screens/S01 Profil Settings.md",
-    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas",
-    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M03 2FA deaktivieren.md",
-    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens/M02 Device Token hinzufuegen.md",
-    "02 Wireframes/P2 Auth/WF-P2 Change Password/WF-P2 Change Password.canvas",
-    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Varianten",
-    "02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens",
-    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Varianten",
-    "02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens",
-    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Varianten",
-    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/Screens",
-    "02 Wireframes/P2 Auth/WF-P2 Change Password/Varianten",
-    "02 Wireframes/P2 Auth/WF-P2 Change Password/Screens",
-    "02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Varianten",
-    "02 Wireframes/P2 Auth/WF-P2 Profil und Sicherheit/Screens"
+    "02 Wireframes/P2 Auth/WF-P2 2FA Verwalten/WF-P2 2FA Verwalten.canvas"
   ]
 }

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.

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md

@@ -9,7 +9,7 @@ typ: Admin Blocker
 umsetzung: Nur dokumentieren
 status: In Subframe
 route: von S02/M02
-subframe: "https://app.subframe.com/f023064a5ca0/design/99f96d31-4cb5-4d7c-a252-3f8bef9f1b59/edit"
+subframe: "https://app.subframe.com/f023064a5ca0/design/0363300b-6455-4fd9-9102-659d0a66b0ea/edit"
 ---
 
 # D03 - Rolle in Nutzung blockiert
@@ -52,7 +52,9 @@ Text: `Diese Rolle kann nicht geloescht werden, solange Mitarbeiter zugewiesen s
 
 ## Subframe
 
--
+- Umsetzung als echtes Subframe-Dialog-Modal: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
+- Kein Fake-Modal ueber einer Rollenliste, kein Blur-/Overlay-Hintergrund als eigene Page.
+- Subframe: [D03 Rolle in Nutzung blockiert](<https://app.subframe.com/f023064a5ca0/design/0363300b-6455-4fd9-9102-659d0a66b0ea/edit>)
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md

@@ -64,7 +64,8 @@ A5 Modal / Invite Form.
 
 ## Subframe
 
-- Umsetzung als echtes Subframe-Modal mit `DialogLayout`-Root, nicht als nachgebautes Overlay ueber einer duplizierten Mitarbeiterliste.
+- Umsetzung als echtes Subframe-Dialog-Modal: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
+- Kein Fake-Modal per `Card`, duplizierter Mitarbeiterliste oder manuell nachgebautem Overlay.
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md

@@ -9,7 +9,7 @@ typ: Grosses Modal
 umsetzung: Bauen
 status: In Subframe
 route: von S02 Bearbeiten, M04A Rolle anlegen oder M04B Rolle duplizieren
-subframe: "https://app.subframe.com/f023064a5ca0/design/f6b68e89-b65c-4623-805e-dbc0e6943a52/edit"
+subframe: "https://app.subframe.com/f023064a5ca0/design/9a9873e3-d790-4373-b8c2-fadd3b82cbe6/edit"
 ---
 
 # M02 - Rolle bearbeiten
@@ -91,14 +91,14 @@ Verhalten:
 
 ## Subframe
 
-- Finale Variante fuer Umsetzung: `M02 V10 Minimal Accordion Editor`.
+- Finale Subframe-Seite fuer Umsetzung: `M02 Rolle bearbeiten`.
 - Umsetzung als echtes grosses Subframe-Modal mit `DialogLayout` + `Dialog.Content`, nicht als freie Page-Shell.
-- V10 enthaelt realistischere Permission-Vorlagen: laengere Beschreibungen, Accordion-Untergruppen, erweiterte Einstellungen und Zugriffsstufen wie `Kein Zugriff`, `Nur lesen`, `Voller Zugriff`.
+- Der Screen enthaelt realistischere Permission-Vorlagen: laengere Beschreibungen, Accordion-Untergruppen, erweiterte Einstellungen und Zugriffsstufen wie `Kein Zugriff`, `Nur lesen`, `Voller Zugriff`.
 - Die alten M02-Referenzvarianten wurden aus Subframe geloescht, damit der Admin-RBAC-Flow clean bleibt.
 
 | Screen | Subframe |
 |---|---|
-| M02 V10 Minimal Accordion Editor | [Subframe](<https://app.subframe.com/f023064a5ca0/design/f6b68e89-b65c-4623-805e-dbc0e6943a52/edit>) |
+| M02 Rolle bearbeiten | [Subframe](<https://app.subframe.com/f023064a5ca0/design/9a9873e3-d790-4373-b8c2-fadd3b82cbe6/edit>) |
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md

@@ -64,7 +64,8 @@ A5 Confirm-Modal.
 
 ## Subframe
 
-- Umsetzung als echtes Subframe-Confirm-Modal mit `DialogLayout`-Root, ohne duplizierte Mitarbeiterliste oder manuell nachgebauten Overlay-Hintergrund.
+- Umsetzung als echtes Subframe-Confirm-Modal: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
+- Kein Fake-Modal per freiem Container, duplizierter Mitarbeiterliste oder manuell nachgebautem Overlay-Hintergrund.
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md

@@ -9,7 +9,7 @@ typ: Modal Step
 umsetzung: Bauen
 status: In Subframe
 route: von S02 CTA Rolle anlegen
-subframe: "https://app.subframe.com/f023064a5ca0/design/afba0d61-d8d4-45df-a831-31294b8c3077/edit"
+subframe: "https://app.subframe.com/f023064a5ca0/design/479ee52d-8d73-46e9-9a9b-a8798a22d764/edit"
 ---
 
 # M04A - Rolle anlegen
@@ -69,17 +69,17 @@ Modal Step / Create Role Basics.
 
 ## Subframe
 
-- Existierende Subframe-Seite: `M04 V2 Template Preview`.
+- Existierende Subframe-Seite fuer `M04A Rolle anlegen`.
 - Wird als echter Modal-Step im Admin-RBAC-Flow genutzt.
 - Dialog-QA: Varianten muessen `DialogLayout` -> `Dialog` -> `Dialog.Content` nutzen; keine simulierten Overlay-/Card-Modals.
-- Offen: Sobald Subframe-MCP Page-Operationen wieder stabil laufen, M04A optisch an den von David angepassten `M04 V3 Duplicate Aware` Screen angleichen, aber ohne Duplikat-Modus.
+- Subframe-Stand: M04A ist optisch an den M04B-Duplikat-Screen angeglichen, aber ohne Duplikat-Modus.
 
 | Screen | Subframe |
 |---|---|
-| M04A Rolle anlegen | [Subframe](<https://app.subframe.com/f023064a5ca0/design/afba0d61-d8d4-45df-a831-31294b8c3077/edit>) |
+| M04A Rolle anlegen | [Subframe](<https://app.subframe.com/f023064a5ca0/design/479ee52d-8d73-46e9-9a9b-a8798a22d764/edit>) |
 
 ## Notizen
 
 Dieser Screen ist nur fuer den Einstieg `Rolle anlegen`. `Duplizieren` ist ein eigener Screen `M04B Rolle duplizieren`; `Bearbeiten` geht weiterhin direkt nach `M02 Rolle bearbeiten`.
 
-Design-ToDo: Layout, Abstaende, Breite, Footer und Dialog-Struktur sollen dem final angepassten M04B-Duplikat-Screen entsprechen. Inhalte bleiben Create-Mode: keine Quellrolle, kein `Kopie von ...`, kein Hinweis auf kopierte Berechtigungen.
+Design-Stand: Layout, Abstaende, Footer und Dialog-Struktur entsprechen dem final angepassten M04B-Duplikat-Screen. Inhalte bleiben Create-Mode: keine Quellrolle, kein `Kopie von ...`, kein Hinweis auf kopierte Berechtigungen.

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md

@@ -9,7 +9,7 @@ typ: Modal Step
 umsetzung: Bauen
 status: In Subframe
 route: von S02 Zeilenaktion Duplizieren
-subframe: "https://app.subframe.com/f023064a5ca0/design/2f3eaab4-d64a-4448-bf2f-ec4b5d23b650/edit"
+subframe: "https://app.subframe.com/f023064a5ca0/design/610d08e6-5c6a-44d3-9b29-220664393ea0/edit"
 ---
 
 # M04B - Rolle duplizieren
@@ -65,13 +65,13 @@ Modal Step / Duplicate Role Basics.
 
 ## Subframe
 
-- Existierende Subframe-Seite: `M04 V3 Duplicate Aware`.
+- Existierende Subframe-Seite fuer `M04B Rolle duplizieren`.
 - Wird als eigener Modal-Step im Admin-RBAC-Flow genutzt.
 - Dialog-QA: Varianten muessen `DialogLayout` -> `Dialog` -> `Dialog.Content` nutzen; keine simulierten Overlay-/Card-Modals.
 
 | Screen | Subframe |
 |---|---|
-| M04B Rolle duplizieren | [Subframe](<https://app.subframe.com/f023064a5ca0/design/2f3eaab4-d64a-4448-bf2f-ec4b5d23b650/edit>) |
+| M04B Rolle duplizieren | [Subframe](<https://app.subframe.com/f023064a5ca0/design/610d08e6-5c6a-44d3-9b29-220664393ea0/edit>) |
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md

@@ -9,7 +9,7 @@ typ: Admin Blocker
 umsetzung: Nur dokumentieren
 status: In Subframe
 route: von S01/M03/Rollenwechsel
-subframe: "https://app.subframe.com/f023064a5ca0/design/3e05bfb3-3842-4008-964e-f4c68dea0d9e/edit"
+subframe: "https://app.subframe.com/f023064a5ca0/design/c1fd0142-76ad-402d-8eae-25ce9281d298/edit"
 ---
 
 # V01 - Letzter Admin blockiert
@@ -54,7 +54,9 @@ Text: `Dieser Workspace braucht mindestens einen Admin. Weise zuerst einem ander
 
 ## Subframe
 
--
+- Umsetzung als echtes Subframe-Dialog-Modal: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
+- Kein Fake-Modal ueber einer Rollen-/Settings-Liste, kein Blur-/Overlay-Hintergrund als eigene Page.
+- Subframe: [V01 Letzter Admin blockiert](<https://app.subframe.com/f023064a5ca0/design/c1fd0142-76ad-402d-8eae-25ce9281d298/edit>)
 
 ## Notizen
 

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas

@@ -1,26 +1,26 @@
 {
 	"nodes":[
-		{"id":"group-main","type":"group","x":-120,"y":-680,"width":4000,"height":1440,"label":"Admin RBAC Hauptflow"},
-		{"id":"group-notes","type":"group","x":-120,"y":900,"width":4000,"height":430,"label":"Dokumentierte Zustaende und Backlog"},
-		{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md","x":780,"y":45,"width":440,"height":230},
-		{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md","x":780,"y":-360,"width":440,"height":230},
+		{"id":"group-main","type":"group","x":-120,"y":-680,"width":4280,"height":1440,"label":"Admin RBAC Hauptflow"},
+		{"id":"group-notes","type":"group","x":-120,"y":900,"width":4280,"height":430,"label":"Dokumentierte Zustaende und Backlog"},
 		{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S02 Rollen und Berechtigungen.md","x":1560,"y":440,"width":440,"height":230},
-		{"id":"note-d01","type":"text","text":"# D01 Rollen-Dropdown\n\nKein eigener Screen.\n\nDas Dropdown ist direkt in S01 enthalten:\n- Rolle wechseln\n- `Rollen und Berechtigungen bearbeiten` fuehrt zu S02\n- letzter Admin wird ueber V01 blockiert","x":720,"y":440,"width":500,"height":250},
-		{"id":"note-seed","type":"text","text":"# Rollenmodell\n\nAdmin ist die einzige Start-/Systemrolle.\n\nWeitere Rollen werden vom Admin selbst angelegt.\n\nRollen-Vorlagen sind Work in Progress und werden nicht als feste Rollen in der Liste gezeigt.","x":1520,"y":1020,"width":520,"height":240},
-		{"id":"note-backlog","type":"text","text":"# Backlog / V2\n\nReassign beim Deaktivieren, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Review-Zyklus, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz.","x":3200,"y":1020,"width":600,"height":240},
-		{"id":"d03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md","x":3280,"y":440,"width":440,"height":230},
-		{"id":"note-permission","type":"text","text":"# Permission-Muster\n\nIm Rollen-Modal wird eine konkrete Permission-Zeile vorgebaut:\n\n`Mitarbeiter ansehen`\nBeschreibung darunter\nControl: Toggle `An/Aus`\n\nRead-only/Bearbeiten bleibt spaeteres Advanced Control, falls ein Recht nicht binaer ist.\n\nFinaler Rechtekatalog liegt bei Development.","x":2520,"y":1010,"width":560,"height":280},
-		{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md","x":2680,"y":440,"width":440,"height":230},
 		{"id":"note-navigation","type":"text","text":"# Navigation\n\nS01 ist der Einstieg unter `Settings -> Mitarbeiter`.\n\nDer Rollen-Tab S02 ist direkt ueber die Settings-Tabs erreichbar und zusaetzlich ueber den Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`.","x":-40,"y":1020,"width":520,"height":240},
 		{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md","x":0,"y":45,"width":440,"height":230},
-		{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md","x":2440,"y":-360,"width":440,"height":230},
-		{"id":"m04a","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md","x":2120,"y":120,"width":440,"height":230},
-		{"id":"m04b","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md","x":2120,"y":440,"width":440,"height":230}
+		{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md","x":780,"y":45,"width":440,"height":230},
+		{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md","x":780,"y":-360,"width":440,"height":230},
+		{"id":"note-seed","type":"text","text":"# Rollenmodell\n\nAdmin ist die einzige Start-/Systemrolle.\n\nWeitere Rollen werden vom Admin selbst angelegt.\n\nRollen-Vorlagen sind Work in Progress und werden nicht als feste Rollen in der Liste gezeigt.","x":1520,"y":1020,"width":520,"height":240},
+		{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md","x":2680,"y":440,"width":440,"height":230},
+		{"id":"m04a","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md","x":2120,"y":-110,"width":440,"height":230},
+		{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md","x":2120,"y":-475,"width":440,"height":230},
+		{"id":"note-d01","type":"text","text":"# D01 Rollen-Dropdown\n\nKein eigener Screen.\n\nDas Dropdown ist direkt in S01 enthalten:\n- Rolle wechseln\n- `Rollen und Berechtigungen bearbeiten` fuehrt zu S02\n- letzter Admin wird ueber V01 blockiert","x":720,"y":1015,"width":500,"height":250},
+		{"id":"m04b","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md","x":2980,"y":-110,"width":440,"height":230},
+		{"id":"note-backlog","type":"text","text":"# Backlog / V2\n\nReassign beim Deaktivieren, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Review-Zyklus, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz.","x":3520,"y":1020,"width":600,"height":240},
+		{"id":"d03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md","x":3600,"y":440,"width":440,"height":230},
+		{"id":"note-permission","type":"text","text":"# Permission-Muster\n\nIm Rollen-Modal wird eine konkrete Permission-Zeile vorgebaut:\n\n`Mitarbeiter ansehen`\nBeschreibung darunter\nControl: Toggle `An/Aus`\n\nRead-only/Bearbeiten bleibt spaeteres Advanced Control, falls ein Recht nicht binaer ist.\n\nFinaler Rechtekatalog liegt bei Development.","x":2620,"y":1000,"width":560,"height":280}
 	],
 	"edges":[
 		{"id":"edge-s01-m01","fromNode":"s01","fromSide":"right","toNode":"m01","toSide":"left","label":"Mitarbeiter einladen"},
 		{"id":"edge-s01-m03","fromNode":"s01","fromSide":"right","toNode":"m03","toSide":"left","label":"deaktivieren"},
-		{"id":"edge-s01-d01","fromNode":"s01","fromSide":"right","toNode":"note-d01","toSide":"left","label":"Rolle wechseln inline"},
+		{"id":"edge-s01-d01","fromNode":"s01","fromSide":"right","toNode":"note-d01","toSide":"top","label":"Rolle wechseln inline"},
 		{"id":"edge-s01-s02","fromNode":"s01","fromSide":"right","toNode":"s02","toSide":"left","label":"Rollen bearbeiten"},
 		{"id":"edge-s02-m02","fromNode":"s02","fromSide":"right","toNode":"m02","toSide":"left","label":"bearbeiten"},
 		{"id":"edge-m03-v01","fromNode":"m03","fromSide":"right","toNode":"v01","toSide":"left","label":"letzter Admin"},
@@ -33,6 +33,6 @@
 		{"id":"edge-s02-m04a","fromNode":"s02","fromSide":"right","toNode":"m04a","toSide":"left","label":"Rolle anlegen"},
 		{"id":"edge-s02-m04b","fromNode":"s02","fromSide":"right","toNode":"m04b","toSide":"left","label":"duplizieren"},
 		{"id":"edge-m04a-m02","fromNode":"m04a","fromSide":"right","toNode":"m02","toSide":"left","label":"weiter"},
-		{"id":"edge-m04b-m02","fromNode":"m04b","fromSide":"right","toNode":"m02","toSide":"left","label":"weiter mit Kopie"}
+		{"id":"edge-m04b-m02","fromNode":"m04b","fromSide":"bottom","toNode":"m02","toSide":"top","label":"weiter mit Kopie"}
 	]
-}
+}

02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md

@@ -338,7 +338,7 @@ Layout:
 
 Subframe:
 
-- `M04 V2 Template Preview` ist der bestehende Subframe-Screen fuer M04A.
+- M04A ist der bestehende Subframe-Screen fuer `Rolle anlegen`.
 - Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.
 
 ### M04B Rolle duplizieren
@@ -366,7 +366,7 @@ Layout:
 
 Subframe:
 
-- `M04 V3 Duplicate Aware` ist der bestehende Subframe-Screen fuer M04B.
+- M04B ist der bestehende Subframe-Screen fuer `Rolle duplizieren`.
 - Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.
 
 ### M02 Rolle bearbeiten
@@ -469,9 +469,9 @@ Alle aktiven Screen-Kandidaten sind von David validiert. Das Rollenmodell starte
 | D01 | Rollen-Dropdown in Mitarbeiterliste | Inline-Zustand in S01 | Nur dokumentieren | in S01, kein eigener Subframe-Screen | Validiert |
 | M03 | Mitarbeiter deaktivieren | Confirm Modal | Bauen | von S01 | Validiert |
 | S02 | Rollen und Berechtigungen | Settings Subpage | Bauen | `Settings -> Mitarbeiter`, Tab `Rollen und Berechtigungen` | Validiert |
-| M04A | Rolle anlegen | Modal Step | Bauen | von S02 CTA Rolle anlegen | Subframe: M04 V2 Template Preview |
-| M04B | Rolle duplizieren | Modal Step | Bauen | von S02 Zeilenaktion Duplizieren | Subframe: M04 V3 Duplicate Aware |
-| M02 | Rolle bearbeiten | Grosses Modal | Bauen | von S02 Bearbeiten oder M04A/M04B | Finale Variante: V10 Minimal Accordion Editor |
+| M04A | Rolle anlegen | Modal Step | Bauen | von S02 CTA Rolle anlegen | Subframe: Rolle anlegen |
+| M04B | Rolle duplizieren | Modal Step | Bauen | von S02 Zeilenaktion Duplizieren | Subframe: Rolle duplizieren |
+| M02 | Rolle bearbeiten | Grosses Modal | Bauen | von S02 Bearbeiten oder M04A/M04B | Finale Subframe-Seite: M02 Rolle bearbeiten |
 | D03 | Rolle in Nutzung blockiert | Admin Blocker | Nur dokumentieren | von S02/M02 | Validiert |
 | V01 | Letzter Admin blockiert | Admin Blocker | Nur dokumentieren | von S01/M03/Rollenwechsel | Validiert |
 
@@ -495,13 +495,13 @@ S02 Rollen und Berechtigungen -> D03 Rolle in Nutzung blockiert
 
 ### Subframe-Stand M02/M04A/M04B
 
-`M02 V10 Minimal Accordion Editor` ist die finale Variante fuer die Umsetzung. Die alten M02-Referenzvarianten wurden aus Subframe geloescht, damit der Admin-RBAC-Flow clean bleibt. Fuer den M04-Split werden die bestehenden Subframe-Seiten getrennt referenziert: M04A nutzt `M04 V2 Template Preview`, M04B nutzt `M04 V3 Duplicate Aware`. Aktueller Subframe-Stand im Admin-RBAC-Flow:
+`M02 Rolle bearbeiten` ist die finale Subframe-Seite fuer die Umsetzung. Die alten M02-Referenzvarianten wurden aus Subframe geloescht, damit der Admin-RBAC-Flow clean bleibt. Fuer den M04-Split werden die bestehenden Subframe-Seiten getrennt referenziert: M04A fuer `Rolle anlegen`, M04B fuer `Rolle duplizieren`. Aktueller Subframe-Stand im Admin-RBAC-Flow:
 
 | Screen | Subframe |
 |---|---|
-| M02 Rolle bearbeiten | [V10 Minimal Accordion Editor](<https://app.subframe.com/f023064a5ca0/design/f6b68e89-b65c-4623-805e-dbc0e6943a52/edit>) |
-| M04A Rolle anlegen | [M04 V2 Template Preview](<https://app.subframe.com/f023064a5ca0/design/afba0d61-d8d4-45df-a831-31294b8c3077/edit>) |
-| M04B Rolle duplizieren | [M04 V3 Duplicate Aware](<https://app.subframe.com/f023064a5ca0/design/2f3eaab4-d64a-4448-bf2f-ec4b5d23b650/edit>) |
+| M02 Rolle bearbeiten | [Subframe](<https://app.subframe.com/f023064a5ca0/design/9a9873e3-d790-4373-b8c2-fadd3b82cbe6/edit>) |
+| M04A Rolle anlegen | [Subframe](<https://app.subframe.com/f023064a5ca0/design/479ee52d-8d73-46e9-9a9b-a8798a22d764/edit>) |
+| M04B Rolle duplizieren | [Subframe](<https://app.subframe.com/f023064a5ca0/design/610d08e6-5c6a-44d3-9b29-220664393ea0/edit>) |
 
 ---
 
@@ -535,7 +535,6 @@ Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaet
 | Rollen-Audit | Historie, wer Rollen/Rechte geaendert hat | Audit-Viewer nicht Teil dieses Pakets |
 | Rollen-Review / Needs Review | Rollen markieren, die geprueft werden muessen, inkl. Review-Zyklus | Status `Pruefen` ist UI-vorbereitet, Prozess spaeter |
 | Rollen-Vorlagen ausarbeiten | branchenspezifische Rollen-Vorlagen fuer neue Rollen definieren | Vorlagen sind aktuell Work in Progress und nicht Teil der initialen Rollenliste |
-| M04A visuell an M04B angleichen | M04A `Rolle anlegen` soll exakt wie Davids final angepasster M04B-Duplikat-Screen wirken, aber ohne Duplikat-Modus | offen, weil Subframe-MCP Page-Operationen aktuell timeouten |
 | Rechte-Matrix | Vergleich mehrerer Rollen nebeneinander | fuer v1 zu breit/technisch |
 | Bulk-Aktionen | mehrere Mitarbeiter gleichzeitig einladen, deaktivieren oder Rollen zuweisen | spaeter, wenn Teamlisten groesser werden |
 | Admin-Schutz erweitert | detaillierte Regeln fuer Selbst-Deaktivierung, letzter Admin, kritische Rollenwechsel | v1 dokumentiert Blocker, genaue Policy spaeter mit Dev/Security |
@@ -568,6 +567,6 @@ Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaet
 - [x] David hat die Kandidaten validiert.
 - [x] Screen-Dateien sind angelegt und nach Screen-Zuschnitt synchronisiert.
 - [x] Canvas ist angelegt und nach M04-Split synchronisiert.
-- [x] M02/M04A/M04B Varianten sind auf echte Subframe-Dialog-Struktur geprueft: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
+- [x] M01/M02/M03/M04A/M04B/D03/V01 sind auf echte Subframe-Dialog-Struktur geprueft: `DialogLayout` -> `Dialog` -> `Dialog.Content`.
 - [x] Subframe-Links sind eingetragen.
-- [ ] M04A visuell an final angepassten M04B-Duplikat-Screen angleichen, sobald Subframe-MCP Page-Operationen wieder funktionieren.
+- [x] M04A ist visuell an den final angepassten M04B-Duplikat-Screen angeglichen, aber ohne Duplikat-Modus.

02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas

@@ -14,4 +14,4 @@
 		{"id":"edge-s01-permission","fromNode":"s01","fromSide":"bottom","toNode":"note-permission","toSide":"top","label":"Permission"},
 		{"id":"edge-m01-request","fromNode":"m01","fromSide":"bottom","toNode":"note-request","toSide":"top","label":"Feedback"}
 	]
-}
+}

AI README.md

@@ -26,6 +26,7 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab
 |---|---|
 | `00 Start Here.md` | Einstieg in den Vault |
 | `01 Regeln/` | Arbeitsregeln fuer Wireframing, Obsidian, Subframe und Brainstorming |
+| `01 Regeln/Screen Agent Workflow.md` | Operative Checkliste fuer AI-Agenten bei Screen-/Flow-Arbeit |
 | `02 Wireframes/Screen Paket Tracker.md` | Zentrale Paket- und Flow-Uebersicht |
 | `02 Wireframes/P2 Auth/` | Aktuell aktive Auth-/Account-/Admin-Wireframe-Pakete |
 | `02 Wireframes/_Templates/` | Vorlagen fuer neue Pakete und Screens |
@@ -33,7 +34,8 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab
 
 ## Arbeitsregeln
 
-- Bestehende Regeln zuerst lesen, besonders `01 Regeln/Wireframing Playbook.md`.
+- Fuer Screen-/Flow-Arbeit zuerst `01 Regeln/Screen Agent Workflow.md` lesen und anwenden. Die Brainstorming-Datei dazu ist nur Archiv, nicht operative Regel.
+- Danach die bestehenden Detailregeln lesen, besonders `01 Regeln/Wireframing Playbook.md`.
 - Flows einzeln bearbeiten und nur validierte Entscheidungen final dokumentieren.
 - Keine bestehenden Subframe-Screens loeschen oder ueberschreiben, wenn der Nutzer das nicht explizit verlangt.
 - Neue Screens/Flows immer in Tracker, Paketdatei, Screen-Dateien und Canvas konsistent halten.
@@ -51,6 +53,7 @@ Modal-Screens muessen als echte Subframe-Dialoge gebaut werden:
 
 - Struktur: `DialogLayout` -> `Dialog` -> `Dialog.Content` -> Modal-Inhalt.
 - Nicht erlaubt: Modal per `Card`, freiem `div`, absolutem Overlay, Blur-Hintergrund oder Fullscreen-Container nur visuell nachbauen.
+- Beim Subframe-Prompt fuer jedes Modal explizit die echte Dialog-Struktur verlangen; sonst baut Subframe haeufig nur ein Fake-Modal nach.
 - Vor Handoff per `get_page_info` pruefen, ob `Dialog` importiert wird und `Dialog.Content` im JSX existiert.
 - Layout bevorzugt mit Subframe-Komponenten und Auto Layout/Flex aufbauen.
 - Custom Tailwind-Klassen nur verwenden, wenn sie fuer feste Groessen, Max-Breiten, Scroll-/Overflow-Verhalten oder responsive Constraints wirklich noetig sind.