diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 9085dc98..8cfa86f8 100644 --- a/.obsidian/workspace.json +++ b/.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" ] } \ No newline at end of file diff --git a/01 Regeln/Screen Agent Workflow - Brainstorming.md b/01 Regeln/Screen Agent Workflow - Brainstorming.md new file mode 100644 index 00000000..b6fb6e1b --- /dev/null +++ b/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. diff --git a/01 Regeln/Screen Agent Workflow.md b/01 Regeln/Screen Agent Workflow.md new file mode 100644 index 00000000..1c1c5589 --- /dev/null +++ b/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. diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md index ed760117..666fc4aa 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md +++ b/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]() ## Notizen diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md index 3b9534bc..c137d2df 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md +++ b/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 diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md index aa55cf4c..514bbb1b 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md +++ b/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]() | +| M02 Rolle bearbeiten | [Subframe]() | ## Notizen diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md index d9a9dc8c..02e1a74c 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md +++ b/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 diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md index c52b9ec6..25817774 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md +++ b/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]() | +| M04A Rolle anlegen | [Subframe]() | ## 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. diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md index 4d3d78fb..52609db1 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md +++ b/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]() | +| M04B Rolle duplizieren | [Subframe]() | ## Notizen diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md index f07e82af..78ee61ec 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md +++ b/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]() ## Notizen diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas index 08a2a4d5..a4d3719c 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.canvas +++ b/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"} ] -} +} \ No newline at end of file diff --git a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md b/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md index 80070e85..9c98273d 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md +++ b/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]() | -| M04A Rolle anlegen | [M04 V2 Template Preview]() | -| M04B Rolle duplizieren | [M04 V3 Duplicate Aware]() | +| M02 Rolle bearbeiten | [Subframe]() | +| M04A Rolle anlegen | [Subframe]() | +| M04B Rolle duplizieren | [Subframe]() | --- @@ -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. diff --git a/02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas b/02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas index 440e77a5..93e2191f 100644 --- a/02 Wireframes/P2 Auth/WF-P2 Konto loeschen/WF-P2 Konto loeschen.canvas +++ b/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"} ] -} +} \ No newline at end of file diff --git a/AI README.md b/AI README.md index 42b0e12b..b4f38ccc 100644 --- a/AI README.md +++ b/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.