Initial wireframe planning

01 Regeln/Obsidian Struktur.md

@@ -0,0 +1,153 @@
+---
+kind: rule
+project: HiveGrid Screen Project
+area: Obsidian
+status: active
+---
+
+# Obsidian Struktur
+
+Dieser Vault ist der Arbeitsbereich fuer Screens, Wireframes und Handoffs.
+
+---
+
+## Ordner
+
+| Ordner | Zweck |
+|---|---|
+| `01 Regeln` | dauerhafte Regeln und Arbeitsweisen |
+| `02 Wireframes` | alle Wireframe-Pakete, Screen-Dateien und Canvas-Dateien |
+| `02 Wireframes/_Templates` | Vorlagen fuer neue Pakete und Screens |
+| `03 Quellen und Repo` | Hinweise zum Gitea-Repo und lokalen Planning-Dateien |
+| `hivegrid-cloud` | technisches Repo mit Planning-Quellen |
+
+---
+
+## Dateiarten
+
+| Dateiart | Beispiel | Zweck |
+|---|---|---|
+| Paket-Datei | `WF-[Ticket] [Flow Name].md` | sammelt Scope, Brainstorming, Screen-Liste und Handoff |
+| Screen-Datei | `S01 Profil auswaehlen.md` | beschreibt genau einen Screen |
+| State-Datei | `ST01 Keine Suchergebnisse.md` | beschreibt einen Zustand, der nicht als eigener Frame gebaut wird |
+| Canvas-Datei | `WF-[Ticket] [Flow Name].canvas` | visueller Flow-Tree in Obsidian Canvas |
+| Tracker | `Screen Paket Tracker.md` | Uebersicht ueber Pakete und Status |
+
+---
+
+## Flow-Typen
+
+| Typ | Bedeutung |
+|---|---|
+| Normaler Flow | eigener Nutzerweg mit Start, Entscheidung und Ziel |
+| Zubringerflow | klaert Vorbedingungen und fuehrt in einen anderen Flow |
+| Auth-Core-Flow | zentraler Sicherheitsflow, der von mehreren Zubringerflows genutzt wird |
+
+Aktuelle Auth-Core-Entscheidung:
+
+- `WF-P2 Set Password` ist ein zentraler Auth-Core-Flow.
+- Passwort Reset, Einladung/initialer Mitarbeiterzugang, Passwort aendern, Admin-Reset und Security-Incident koennen dorthin fuehren.
+- Neukunden-Signup ist die Ausnahme und setzt das Passwort direkt im Signup-Flow.
+
+---
+
+## Benennung
+
+Pakete:
+
+```text
+WF-[Ticket] [Name].md
+```
+
+Screens:
+
+```text
+S01 [Screen Name].md
+S02 [Screen Name].md
+B01 [Branch Name].md
+ST01 [State Name].md
+```
+
+IDs:
+
+- `S01`, `S02`, `S03` = Hauptflow
+- `B01`, `B02`, `B03` = Branch/Variante
+- `M01`, `M02` = Modal/Overlay
+- `ST01`, `ST02` = Zustand
+
+---
+
+## Link-Anzeige in Tabellen
+
+In Tabellen werden lange Links mit normalen Markdown-Links gekuerzt.
+
+Warum: Obsidian-Wiki-Aliase nutzen `|`, und dieses Zeichen kann Markdown-Tabellen kaputt machen.
+
+Beispiel:
+
+```md
+[MD](<P2 Auth/WF-P2 Login und 2FA/Screens/S01 Login.md>)
+[Canvas](<P2 Auth/WF-P2 Login und 2FA/WF-P2 Login und 2FA.canvas>)
+```
+
+Regel:
+
+- In Tracker-Tabellen kurze Labels verwenden: `MD`, `Canvas`, `Subframe`.
+- In Tabellen keine `[[Pfad|Alias]]`-Links verwenden.
+- Lange Pfade nur in der Datei selbst oder im Frontmatter ausschreiben.
+- Der sichtbare Tabelleninhalt soll scanbar bleiben.
+
+---
+
+## Frontmatter
+
+Jede Paket- und Screen-Datei bekommt oben Metadaten. Dadurch kann Obsidian spaeter Tabellen daraus bauen.
+
+Beispiel Screen:
+
+```yaml
+---
+kind: screen
+ticket: P2
+package: WF-[Ticket] [Flow Name]
+id: S01
+screen: Profil auswaehlen
+umsetzung: Bauen
+status: Validiert
+subframe: ""
+---
+```
+
+---
+
+## Obsidian Canvas
+
+Canvas-Dateien liegen direkt im jeweiligen Paketordner.
+
+Grid-Regel:
+
+- Hauptflow nach rechts
+- Varianten nach unten
+- Varianten laufen danach wieder nach rechts weiter
+- wenn es unuebersichtlich wird, entsteht ein neues Paket
+
+Qualitaetsregel:
+
+- keine ueberlappenden Nodes
+- keine verdeckten Labels
+- keine Kante durch andere Karten
+- kurze Kantenlabels mit genug Abstand
+- Canvas nach dem Erstellen mit JSON-Check pruefen
+
+---
+
+## Subframe-Schutz
+
+Subframe wird nicht automatisch aus dem Tracker heraus bearbeitet.
+
+Regel:
+
+- Bestehende Subframe-Screens bleiben unberuehrt, auch wenn sie gleich heissen.
+- Der Assistant darf Subframe nur nach expliziter Freigabe fuer einen konkreten Flow nutzen.
+- Ohne Freigabe werden nur Obsidian-Dateien vorbereitet: Paket, Screens, Canvas, Tracker.
+- David kann bestehende oder gleichnamige Subframe-Screens spaeter selbst pruefen, ersetzen oder loeschen.

01 Regeln/Wireframing Playbook.md

@@ -0,0 +1,560 @@
+---
+kind: rule
+project: HiveGrid Screen Project
+area: Wireframing
+status: active
+---
+
+# Wireframing Playbook
+
+Stand: 2026-06-24
+
+Dieses Playbook definiert, wie Wireframe-Pakete fuer HiveGrid in Obsidian vorbereitet, validiert und als Markdown/Canvas abgelegt werden. Subframe wird nur nach expliziter Freigabe genutzt.
+
+Ziel: Nicht jeden Spezialzustand einzeln bauen, sondern nur die Screens bauen, die Struktur, Aufgabe, Entscheidung oder Risiko sichtbar machen.
+
+---
+
+## 1. Grundprinzip
+
+Ein Wireframe klaert:
+
+- was der Nutzer auf diesem Screen tun soll
+- welche Daten sichtbar sind
+- welche Aktionen moeglich sind
+- welche Entscheidungen oder Blocker existieren
+- welche Komponenten/Archetypen wiederverwendet werden
+
+Subframe wird erst nach expliziter Freigabe genutzt. Mikro-Zustaende werden dokumentiert, aber nicht jedes Mal als eigener Frame gebaut.
+
+Wichtig: Der Assistant bereitet Flows, Screen-Dateien und Canvas in Obsidian vor. David validiert und kann die Screens selbst in Subframe bauen. Bestehende Subframe-Screens werden nicht automatisch bearbeitet, ueberschrieben oder geloescht, auch wenn sie gleich heissen.
+
+---
+
+## 2. Arbeitsablauf pro Wireframe-Paket
+
+Kein Flow wird direkt gebaut. Vorher gibt es immer ein kurzes Brainstorming und eine Validierung.
+
+Es wird immer nur **ein kleines Paket nach dem anderen** bearbeitet. Nicht mehrere Flows gleichzeitig finalisieren.
+
+Grundregel:
+
+```text
+Ein Flow -> Varianten brainstormen -> Entscheidung treffen -> Screen-Kandidaten sammeln -> jeden Screen validieren -> erst dann bauen/ablegen.
+```
+
+Screen-Listen entstehen aus dem Brainstorming. Sie werden nicht vorab automatisch festgelegt.
+
+0. **Intent Check: Was ist ueberhaupt gewollt?**
+   - Welches Ticket oder Modul ist betroffen?
+   - Was soll der Nutzer am Ende schaffen?
+   - Geht es um einen echten Flow, einen einzelnen Screen, einen Zustand oder nur Dokumentation?
+   - Welche Planning-Quellen muessen gelesen werden?
+   - Welche Annahmen sind noch unsicher?
+   - Was ist ausdruecklich nicht Teil dieses Pakets?
+
+1. **Scope sammeln**
+   - Ticket/Modul
+   - Ziel des Flows
+   - Nutzerrolle
+   - Rollenunterschiede: normale Rolle vs. Admin
+   - Startpunkt
+   - wichtige Daten
+   - wichtige Aktionen
+   - bekannte Constraints aus Planning/Specs
+
+2. **Mini-Brainstorming**
+   - Was ist der Happy Path?
+   - Wo verzweigt der Flow?
+   - Wo kann der Nutzer blockiert sein?
+   - Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?
+   - Welche davon sind Inline, Banner, Toast, Modal oder eigener Screen?
+   - Welche UX-Varianten sind denkbar?
+   - Was spricht fuer oder gegen jede Variante?
+   - Welche Variante empfiehlt der Assistant?
+   - Welche Variante entscheidet David?
+   - Erst danach: Welche Screens/Zustaende koennten daraus entstehen?
+
+3. **Entscheidungsschritt**
+   - David entscheidet die UX-Richtung.
+   - Offene Fragen werden markiert.
+   - Wenn keine Entscheidung moeglich ist, wird das Paket nicht gebaut.
+   - Erst nach der Entscheidung entsteht eine Screen-Kandidatenliste.
+
+4. **Screen Validation Gate**
+   - Jeder Screen-Kandidat wird einzeln entschieden.
+   - Kein Screen wird in Subframe gebaut, bevor er validiert ist.
+   - Kein Screen wird in den Flow eingebaut, nur weil er "vielleicht gebraucht" wird.
+   - Fehler-/Meldungszustaende werden einzeln entschieden: Inline, Banner, Toast, Modal, eigener Screen oder nur Dokumentation.
+   - Ein Screen bekommt erst danach eine Umsetzung: `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus`.
+
+5. **Validierung vor dem Bau**
+   - Screen-Liste steht
+   - Reuse-vs-Bauen ist entschieden
+   - offene Fragen sind markiert
+   - Hauptflow und Varianten sind verstanden
+   - jeder Screen wurde einzeln geprueft
+
+6. **Screen-Dateien/Canvas vorbereiten**
+   - nur die validierten Screens
+   - Canvas nur fuer den validierten Flow anlegen
+   - vorhandene D0-Komponenten und Archetypen dokumentieren
+   - keine unnoetigen Sonderkomponenten erfinden
+   - kein Subframe-Bau ohne ausdrueckliche Freigabe von David
+
+7. **Markdown-Paket schreiben**
+   - Screen-Liste
+   - Subframe-Links
+   - Daten je Screen
+   - Aktionen je Screen
+   - Banner, Toasts und Inline-Meldungen
+   - Zustaende
+   - offene Fragen
+
+8. **Handoff-Check**
+   - jedes sichtbare Feld hat eine Datenquelle
+   - jeder Button hat eine Aktion
+   - die relevanten Zustaende sind beschrieben
+   - der Screen ist als `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus` markiert
+
+---
+
+## 2a. Brainstorming-Regeln
+
+Brainstorming ist Pflicht, bevor Screens festgelegt werden.
+
+Der Assistant darf nicht direkt eine finale Screen-Liste erzeugen. Er arbeitet zuerst mit Optionen.
+
+### Ablauf
+
+1. **Flow-Frage formulieren**
+   - Worum geht es in diesem Flow?
+   - Welches Nutzerproblem wird geloest?
+   - Was ist der Startpunkt und was ist das Ziel?
+
+2. **Varianten anbieten**
+   - mindestens 2 sinnvolle Varianten, wenn es echte UX-Entscheidungen gibt
+   - pro Variante kurz: Vorteil, Nachteil, Aufwand, Risiko
+   - keine Scheingenauigkeit, wenn eine Variante offensichtlich falsch ist
+
+3. **Empfehlung geben**
+   - der Assistant darf eine Empfehlung geben
+   - die Empfehlung ist nicht automatisch die Entscheidung
+
+4. **David entscheidet**
+   - Entscheidung markieren als `genommen`, `spaeter`, `raus` oder `unklar`
+   - bei `unklar` wird nicht gebaut
+
+5. **Screen-Kandidaten ableiten**
+   - erst nach Davids Entscheidung
+   - Kandidaten sind noch nicht final
+   - Meldungs-/Error-State-Kandidaten werden separat gesammelt
+
+6. **Screen Validation Gate**
+   - jeder Kandidat wird einzeln geprueft
+   - danach erst finale Liste
+   - jeder relevante Fehler-/Meldungszustand bekommt eine UI-Form
+
+### Entscheidungsformat
+
+Fuer Brainstorming wird dieses Format genutzt:
+
+| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
+|---|---|---|---|---|
+| A | - | - | - | - |
+| B | - | - | - | - |
+
+Danach:
+
+| Entscheidung | Status | Notiz |
+|---|---|---|
+| - | genommen / spaeter / raus / unklar | - |
+
+### Meldungs-/Error-State-Check im Brainstorming
+
+Bei jedem Flow wird waehrend des Brainstormings abgefragt:
+
+- Was kann erfolgreich passieren?
+- Was kann fehlschlagen?
+- Was kann den Nutzer blockieren?
+- Was muss der Nutzer sofort korrigieren koennen?
+- Was darf nicht verschwinden?
+- Was ist copy-kritisch oder sicherheitskritisch?
+- Welche Meldungen duerfen nicht dem Developer ueberlassen werden?
+
+Diese Matrix wird fuer jedes Paket genutzt:
+
+| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
+|---|---|---|---|---|
+| - | Inline / Banner / Toast / Modal / Screen | ja / nein | ja / nein | - |
+
+Regel: Ein Fehler wird nicht danach entschieden, ob er technisch ein Error ist, sondern danach, was der Nutzer als Naechstes tun muss.
+
+---
+
+## 2b. Rollen- und Permission-Regel
+
+Bei jedem Flow wird kurz geprueft, ob sich die UX fuer Admin und normale Nutzer unterscheidet.
+
+Standardannahme:
+
+- **Normale Rolle** = hoechste Rolle unter Admin.
+- **Admin** = eigene Variante nur dann, wenn Ziel, Rechte, Daten oder Weiterleitung sichtbar anders sind.
+
+Regeln:
+
+- Wenn Admin nur nach erfolgreichem Login woanders landet, wird das als **Outcome** dokumentiert, nicht automatisch als eigener Screen gebaut.
+- Wenn Admin andere Daten, andere Aktionen oder andere Risiken sieht, wird eine eigene Variante geprueft.
+- Tenant-/Workspace-/Profil-Auswahl fuer Admin wird als eigener Flow behandelt, wenn sie mehr ist als eine reine Weiterleitung.
+- Permission-Denied, gesperrte Funktionen und sichtbare Rechte-Unterschiede werden im Screen-Paket dokumentiert.
+
+Beispiel Login:
+
+| Rolle | Nach erfolgreichem Login |
+|---|---|
+| Normale Rolle | Home/Dashboard |
+| Admin | Tenant-/Workspace-Auswahl oder Admin-Startpunkt |
+
+---
+
+## 2c. Zentrale Auth-Core-Flows
+
+Manche Auth-Flows sind zentrale Sicherheitsbausteine und werden von mehreren anderen Flows angesteuert.
+
+Aktuelle Produktentscheidung:
+
+`Set Password` wird als zentraler Flow behandelt.
+
+Er kann aus mehreren Zubringer-Flows gestartet werden:
+
+- Passwort Reset
+- Einladung / initialer Mitarbeiterzugang
+- Passwort aendern
+- Admin-Reset
+- Sicherheitsmassnahme nach Incident
+
+Regeln:
+
+- Der zentrale Flow wird als eigenes Paket gebrainstormt und validiert.
+- Zubringer-Flows dokumentieren nur, wie der Nutzer in den zentralen Flow kommt.
+- Sonderregeln des Zubringer-Flows werden nicht im zentralen Flow versteckt, sondern im jeweiligen Paket dokumentiert.
+- Auth-Core-Flows brauchen eine dokumentierte Zurueck-/Abbrechen-Aktion, wenn ein Nutzer den Einstieg versehentlich geoeffnet haben kann, z. B. bei Passwort Reset.
+- Die Zurueck-Aktion ist normalerweise kein eigener Screen, sondern eine sekundare Navigation im jeweiligen Auth-Screen.
+- 2FA wird im Set-Password-Flow grundsaetzlich angeboten.
+- Wenn 2FA fuer den konkreten Einstieg verpflichtend ist, wird das im Zubringerpaket oder als Regel im Set-Password-Paket markiert.
+- Admin-Reset kann bestimmen, ob 2FA verpflichtend oder freiwillig ist.
+- Neukunden-Signup ist eine bewusste Ausnahme: Das Passwort wird direkt im Signup-Flow gesetzt, damit der Einstieg moeglichst wenig Reibung hat.
+
+Wichtig: Diese Entscheidung weicht bewusst von der einfachen D-P2-Planung ab und ist eine UX-/Produktentscheidung nach Abstimmung mit Development.
+
+---
+
+## 2e. Subframe-Schutzregel
+
+Subframe ist kein automatischer naechster Schritt.
+
+Regeln:
+
+- Kein bestehender Subframe-Screen wird ohne ausdrueckliche Freigabe bearbeitet.
+- Kein bestehender Subframe-Screen wird geloescht oder ueberschrieben.
+- Gleichnamige vorhandene Subframe-Screens sind nur Kontext, keine Arbeitsanweisung.
+- Neue Subframe-Screens werden nur angelegt, wenn David den konkreten Flow und den Subframe-Bau freigibt.
+- Bis zur Freigabe arbeitet der Assistant ausschliesslich in Obsidian: Paket-MD, Screen-MD, Canvas und Tracker.
+- Wenn Subframe spaeter genutzt wird, werden neue Screens eindeutig verlinkt und im Tracker dokumentiert.
+
+---
+
+## 2d. Screen Validation Gate
+
+Bevor ein Screen in einen Flow eingebaut wird, muss er einzeln validiert werden.
+
+### Validierungsfragen
+
+- Ist das ein eigener Arbeitsmoment fuer den Nutzer?
+- Wird hier eine neue Struktur gebraucht?
+- Gibt es eine neue Entscheidung oder einen Risiko-Moment?
+- Reicht ein vorhandener Archetyp?
+- Ist es nur ein Zustand, Banner, Toast oder Inline-Hinweis?
+- Muss dieser Screen jetzt gebaut werden, oder reicht `Spaeter`?
+- Welche Daten und Aktionen sind wirklich noetig?
+
+### Ergebnis
+
+Jeder Screen-Kandidat bekommt eine klare Entscheidung:
+
+| Entscheidung | Bedeutung |
+|---|---|
+| Bauen | wird als eigener Subframe-Frame gebaut |
+| Wiederverwenden | vorhandener Archetyp reicht |
+| Nur dokumentieren | im MD festhalten, kein Frame |
+| Spaeter | relevant, aber nicht fuer dieses Paket |
+| Raus | bewusst nicht Teil des Scopes |
+
+Erst nach dieser Entscheidung darf der Screen in die finale Screen-Liste.
+
+### Copy-kritische Zustaende
+
+Manche Zustaende sind technisch nur Banner, Inline-Meldung oder Erfolgsscreen, muessen aber trotzdem gebaut werden.
+
+Grund: Der Text, die Tonalitaet und die naechste Handlung sollen vom Design entschieden werden, nicht spaeter zufaellig vom Developer.
+
+Ein Zustand wird eher gebaut, wenn:
+
+- er sehr haeufig vorkommt
+- der Nutzer danach wissen muss, was als Naechstes passiert
+- Sicherheit, Vertrauen oder Zugang betroffen ist
+- der Text sensibel ist
+- die Meldung ein eigener mentaler Schritt im Flow ist
+- die Entscheidung nicht dem Developer ueberlassen werden soll
+
+Beispiele:
+
+- Magic-Link gesendet
+- Passwort geaendert
+- E-Mail nicht gefunden / neutraler Sicherheitstext
+- falsche Login-Daten
+- 2FA gesperrt
+- Link abgelaufen
+- Account gesperrt
+
+Field-Validierungen wie "Passwort zu schwach", "Pflichtfeld fehlt" oder "ungueltige Telefonnummer" werden normalerweise nicht einzeln gebaut, wenn sie durch das Form/Input-Kit abgedeckt sind. Ausnahme: Der Zustand ist fachlich oder rechtlich wichtig.
+
+---
+
+## 3. Was gilt als Screen?
+
+Ein Screen ist ein eigener Arbeitsmoment fuer den Nutzer.
+
+Ein Screen liegt vor, wenn der Nutzer:
+
+- auf einer eigenen Seite landet
+- eine Entscheidung trifft
+- Daten prueft
+- etwas erstellt oder bearbeitet
+- einen Flow startet, fortsetzt oder beendet
+- blockiert ist und eine Loesung braucht
+
+Beispiele: Login, 2FA, Profil-Auswahl, Kontaktliste, Projekt-Detail, Flow-Editor, Loeschbestaetigung, Reassign-Workflow.
+
+---
+
+## 4. Wann wird ein Screen in Subframe gebaut?
+
+Ein Screen wird gebaut, wenn mindestens eine Regel zutrifft:
+
+1. **Neue Struktur**
+   - Das Layout unterscheidet sich sichtbar von den bekannten Archetypen.
+
+2. **Neue Aufgabe**
+   - Der Nutzer macht hier etwas Eigenes, nicht nur dieselbe Liste mit anderen Daten.
+
+3. **Neue Entscheidung**
+   - Der Nutzer muss auswaehlen, bestaetigen, abbrechen, wechseln oder fortfahren.
+
+4. **Risiko-Moment**
+   - Loeschen, sperren, Rechte fehlen, Zahlung offen, Datenverlust, irreversible Aktion.
+
+5. **Bespoke UI**
+   - Kanban, Kalender, Plantafel, Flow-Editor, Form-Builder, Chat, Cmd+K, Public Booking.
+
+6. **Auth oder Public**
+   - Screens ohne normale App-Shell oder mit hoher Aussenwirkung.
+
+---
+
+## 5. Was wird nicht als eigener Subframe-Screen gebaut?
+
+Diese Dinge werden meistens dokumentiert, aber nicht als eigener Frame gebaut:
+
+- normaler Error-Banner auf einer bestehenden Seite
+- Toast nach Speichern, Loeschen oder Export
+- Field-Error in einem Standardformular
+- Empty-State einer normalen Liste, wenn A7 schon greift
+- Loading-Skeleton einer normalen Seite
+- Permission-State, wenn er nur Standard-A7 ist
+- zweite oder dritte Liste mit gleicher Struktur
+- Standard-Confirm-Modal ohne besondere Logik
+- Hover, Focus, Disabled, Pressed
+
+Ausnahme: Wenn der Zustand die Bedienung oder Struktur veraendert, wird er gebaut.
+
+Beispiel: Account gesperrt und alle Aktionen sind deaktiviert, nur "Zahlung aktualisieren" bleibt moeglich.
+
+---
+
+## 6. Banner, Toasts und Inline-Meldungen
+
+Banner und Meldungen gehoeren immer zum Screen-Paket, auch wenn sie nicht als eigener Frame gebaut werden.
+
+### Entscheidungs-Hierarchie
+
+| UI-Form | Wann verwenden? | Typische Beispiele | Meist bauen? |
+|---|---|---|---|
+| Inline | betrifft genau ein Feld und kann direkt dort korrigiert werden | Pflichtfeld fehlt, E-Mail ungueltig, Passwort zu kurz, 2FA-Code falsch | nein |
+| Screen-Banner | betrifft den aktuellen Screen oder das aktuelle Formular | Login-Daten falsch, Captcha erforderlich, Formular konnte nicht gespeichert werden | nur wenn optisch/fachlich wichtig |
+| Globaler Banner | betrifft App/Shell oder Tenant/Account allgemein | Zahlung offen, Tenant gesperrt, Wartung | D0/App-Shell |
+| Toast | kurze Rueckmeldung nach Aktion, nicht blockierend | gespeichert, kopiert, Einladung versendet, Export gestartet | nein |
+| Modal/Dialog | Nutzer muss bestaetigen oder kurz entscheiden, bleibt aber im Kontext | loeschen bestaetigen, Rolle wechseln, Reassign bestaetigen | falls eigener Entscheidmoment |
+| Eigener Screen | Nutzer ist blockiert, in neuem Flow-Status oder braucht klare naechste Schritte | Link abgelaufen, Magic-Link gesendet, 2FA nicht verfuegbar, Account gesperrt | ja |
+
+### Entscheidungsfragen
+
+- Kann der Nutzer direkt im Feld korrigieren? Dann `Inline`.
+- Bleibt der Nutzer im selben Screen und kann dort weiterarbeiten? Dann `Banner`.
+- Ist es nur eine kurze Rueckmeldung nach einer Aktion? Dann `Toast`.
+- Muss der Nutzer bestaetigen oder eine kleine Entscheidung treffen, ohne den Screen zu verlassen? Dann `Modal/Dialog`.
+- Ist der Nutzer blockiert oder in einem neuen Flow-Zustand? Dann `eigener Screen`.
+- Ist Sicherheit, Zugang, Vertrauen oder rechtlicher Kontext betroffen? Eher `Banner` oder `Screen`, nicht Toast.
+- Darf die Meldung verschwinden? Wenn nein, kein Toast.
+
+### Blockierende Error States
+
+Blockierende Error States muessen im Screen-Paket genauer beschrieben werden.
+
+Pflichtangaben:
+
+- sichtbarer Titel oder Kernaussage
+- Ursache in Nutzersprache
+- naechste Primaeraktion
+- sekundare Aktion, z. B. zurueck oder Support/Admin kontaktieren
+- ob der Nutzer im aktuellen Screen bleiben kann oder einen eigenen Screen braucht
+
+Beispiel:
+
+| Ereignis | UI-Form | Bauen? | Inhalt |
+|---|---|---|---|
+| 2FA nicht verfuegbar | Eigener Screen | ja | 2FA kann nicht uebersprungen werden, Admin kontaktieren |
+| Reset-Link abgelaufen | Eigener Screen | ja | Link ist nicht mehr gueltig, neuen Link anfordern |
+| 2FA-Code falsch | Inline | nein | Code pruefen und erneut eingeben |
+
+### Globale Banner
+
+Gehoeren zur App-Shell/D0 und koennen ueberall auftauchen.
+
+Beispiele:
+
+- Zahlung offen
+- Tenant gesperrt
+- Account frozen
+- Loeschung vorgemerkt
+- Systemwartung
+
+### Screen-Banner
+
+Gehoeren direkt zum jeweiligen Screen.
+
+Beispiele:
+
+- Projekt ist abgeschlossen
+- Lead hat keine Weiterverarbeitungsfreigabe
+- Dieses Formular ist unveroeffentlicht
+- Verbindung zu Integration fehlgeschlagen
+
+### Action-Feedback
+
+Wird bei der jeweiligen Aktion dokumentiert.
+
+Beispiele:
+
+- gespeichert
+- geloescht
+- Export gestartet
+- Export fehlgeschlagen
+- Einladung versendet
+
+Regel: Banner, Toast oder Inline-Meldung nur bauen, wenn sie den Screen optisch oder funktional wesentlich veraendert. Sonst im Markdown dokumentieren.
+
+---
+
+## 7. Subframe-Grid-Regeln
+
+Subframe wird wie ein Flow-Board genutzt.
+
+### Hauptflow
+
+- Der Hauptflow laeuft von links nach rechts.
+- Jeder naechste Hauptschritt liegt eine Spalte weiter rechts.
+- Der Happy Path bleibt in einer horizontalen Linie.
+
+### Varianten und Branches
+
+- Eine Variante geht eine Reihe nach unten.
+- Zwei Varianten gehen zwei Reihen nach unten.
+- Drei Varianten gehen drei Reihen nach unten.
+- Jede Variante laeuft danach wieder nach rechts weiter.
+
+Beispiel:
+
+```text
+S01 Login -> S02 2FA -> S03 Profil-Auswahl -> S04 Dashboard
+              |
+              v
+           B01 2FA gesperrt -> B02 Wiederherstellungscode
+```
+
+### Wann wird ein neuer Flow gebaut?
+
+Ein neuer Flow wird gebaut, wenn:
+
+- die Variante mehr als 2-3 eigene Screens braucht
+- die Variante eine eigene Nutzeraufgabe ist
+- eine andere Rolle betroffen ist
+- die Grid-Ansicht unuebersichtlich wird
+- ein Screen sehr spezifisch oder bespoke wird
+- ein anderer Modulbereich beginnt
+
+Regel: Lieber ein sauberer kleiner Flow als ein riesiges unlesbares Board.
+
+### Canvas-Qualitaetsregeln
+
+Jede Canvas-Datei muss vor Abschluss lesbar geprueft werden.
+
+Pflichtregeln:
+
+- Nodes gross genug anlegen, damit Titel und Inhalt lesbar bleiben.
+- Gruppen brauchen genug Padding; Gruppenlabels duerfen keine Nodes oder Kanten verdecken.
+- Kanten duerfen nicht durch andere Nodes laufen.
+- Lange Kantenlabels vermeiden.
+- Kantenlabels sind erlaubt, wenn genug Abstand zwischen den Karten ist.
+- Labels kurz halten, z. B. `Magic-Link`, `falsch`, `Captcha`, `gesperrt`, `2FA`, `ok`.
+- Wenn Labels ueber Nodes oder Gruppen liegen, Karten weiter auseinanderziehen statt die Labels direkt zu entfernen.
+- Keine direkte Kante bauen, wenn sie durch einen anderen wichtigen Schritt laeuft.
+- Outcomes duerfen als Text-Node dokumentiert werden, wenn sie keine eigenen Screens sind.
+- Nach dem Schreiben der Canvas muss JSON validiert werden.
+
+Richtwerte:
+
+| Element | Mindestgroesse |
+|---|---|
+| File-Node | 360 x 170 |
+| Text-Node | 420 x 170 |
+| Gruppe | mindestens 80 px Padding um Nodes |
+
+---
+
+## 8. Umsetzung und Status
+
+### Umsetzung
+
+`Umsetzung` beschreibt, was mit dem Screen oder Zustand gemacht wird.
+
+| Wert | Bedeutung |
+|---|---|
+| Bauen | Eigener Screen/Frame in Subframe |
+| Wiederverwenden | vorhandenes Pattern/Archetyp reicht |
+| Nur dokumentieren | kein Frame, aber im Markdown beschreiben |
+| Spaeter | bewusst noch nicht jetzt |
+| Raus | nicht im Scope |
+
+### Status
+
+`Status` beschreibt, wie weit der Eintrag gerade ist.
+
+| Wert | Bedeutung |
+|---|---|
+| Idee | noch nicht entschieden |
+| Brainstormed | grob besprochen |
+| Validiert | entschieden, kann gebaut/dokumentiert werden |
+| In Subframe | wird gerade gebaut |
+| Review | gebaut, muss geprueft werden |
+| Fertig | bereit zur Uebergabe |