diff --git a/01 Regeln/Obsidian Struktur.md b/01 Regeln/Obsidian Struktur.md index 5097cb24..ac8ed2af 100644 --- a/01 Regeln/Obsidian Struktur.md +++ b/01 Regeln/Obsidian Struktur.md @@ -139,6 +139,13 @@ Qualitaetsregel: - kurze Kantenlabels mit genug Abstand - Canvas nach dem Erstellen mit JSON-Check pruefen +Sync-Regel: + +- Jeder echte Screen braucht einen Canvas-Node. +- Wenn ein Screen umbenannt, gesplittet, geloescht oder neu angelegt wird, muessen Canvas, Screen-Datei, Paket-MD und `Screen Paket Tracker` im selben Arbeitsschritt abgeglichen werden. +- Wenn aus einer Variante ein eigener Screen wird, braucht sie einen eigenen Canvas-Node und eine eigene Tracker-Zeile. +- Ohne Davids Freigabe wird ein geplanter Split nur dokumentiert, aber nicht als neuer Subframe-Screen gebaut. + --- ## Subframe-Schutz diff --git a/01 Regeln/Wireframing Playbook.md b/01 Regeln/Wireframing Playbook.md index 685657e4..209d8f2f 100644 --- a/01 Regeln/Wireframing Playbook.md +++ b/01 Regeln/Wireframing Playbook.md @@ -101,6 +101,7 @@ Screen-Listen entstehen aus dem Brainstorming. Sie werden nicht vorab automatisc - vorhandene D0-Komponenten und Archetypen dokumentieren - keine unnoetigen Sonderkomponenten erfinden - kein Subframe-Bau ohne ausdrueckliche Freigabe von David + - neue, geloeschte, umbenannte oder gesplittete Screens immer in Screen-Dateien, Paket-MD, Tracker und Canvas synchron halten 7. **Markdown-Paket schreiben** - Screen-Liste @@ -264,6 +265,48 @@ Regeln: --- +## 2f. Screen-Aenderungs- und Sync-Regel + +Jede Aenderung an Screen-Struktur, Screen-Namen oder Screen-Zuschnitt muss als synchroner Paket-Update behandelt werden. Das gilt auch, wenn nur in Subframe oder nur in der Planung gearbeitet wurde. + +Pflichtablauf bei jeder Screen-Aenderung: + +1. **Bestand pruefen** + - Aktuellen Subframe-Flow per MCP lesen, wenn der Flow bereits in Subframe existiert. + - Aktuelle Screen-Dateien, Paket-MD, `Screen Paket Tracker` und Canvas-Datei pruefen. + - Vorhandene lokale Aenderungen respektieren; nichts ungefragt zuruecksetzen. + +2. **Screen-Entscheidung klaeren** + - Ist es derselbe Screen mit anderem Namen? + - Ist es ein Zustand innerhalb eines Screens? + - Ist es eine Variante zur Auswahl? + - Oder ist es ein eigener Screen mit eigener Nutzeraufgabe? + - Wenn aus einer Variante ein eigener Screen werden soll, muss David das vorher validieren. + +3. **Synchron eintragen** + - Screen-Datei: Frontmatter `screen`, Titel, Ziel, Route, Subframe-Link. + - Paket-MD: Flowbeschreibung, Screen Validation Gate, validierte Screen-Liste, Subframe-Grid, Screen-Pakete, Handoff-Check. + - `Screen Paket Tracker`: Name, Status, Route/Ort, MD-Link, Subframe-Link, Canvas-Link. + - Canvas: eigener Node fuer jeden echten Screen; Kanten und Labels passend aktualisieren. + - Subframe: nur nach Freigabe Screens anlegen, loeschen, umbenennen oder bearbeiten. + +4. **Abgleich vor Abschluss** + - `rg` nach alten Screen-Namen und toten Subframe-Links ausfuehren. + - Subframe-Flow erneut lesen, wenn Subframe geaendert wurde. + - Canvas-Datei als JSON validieren, wenn sie geaendert wurde. + - `git diff --name-only` pruefen und dem Nutzer sagen, was bewusst nicht geaendert wurde. + +Regeln: + +- Ein Subframe-Screen ohne Tracker-/Canvas-Eintrag ist ein Fehler. +- Ein Canvas-Screen ohne Screen-Datei oder Tracker-Zeile ist ein Fehler. +- Eine Screen-Datei mit geloeschtem oder falschem Subframe-Link ist ein Fehler. +- Mehrere reale Einstiegssituationen duerfen nur dann als eine Screen-Datei bleiben, wenn David sie explizit als Zustandsvarianten desselben Screens validiert. +- Wenn zwei Einstiegssituationen eigene Screens sind, brauchen sie eigene Screen-Namen, eigene Tracker-Zeilen und eigene Canvas-Nodes. +- Vor David-Freigabe wird ein geplanter Split nur als offene Entscheidung oder Backlog notiert, nicht stillschweigend gebaut. + +--- + ## 2d. Screen Validation Gate Bevor ein Screen in einen Flow eingebaut wird, muss er einzeln validiert werden. 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 0fd0f273..7271a25c 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 @@ -340,6 +340,8 @@ M04 hat zwei bestehende Subframe-Varianten: - `M04 V2 Template Preview`: Einstieg fuer eine komplett neue Rolle mit leerem Formular und WIP-Vorlagenbereich. - `M04 V3 Duplicate Aware`: Einstieg fuer `Duplizieren` mit vorausgefuellten Basisdaten aus der Quellrolle. +Offene Strukturentscheidung: Wenn David bestaetigt, dass `Rolle anlegen` und `Duplizieren` zwei eigene Screens sein sollen, muessen sie als getrennte Screen-Eintraege mit eigenen Canvas-Nodes, Tracker-Zeilen und ggf. eigenen Screen-Dateien umgesetzt werden. Bis dahin bleiben sie als bestehende M04-Entwuerfe dokumentiert und werden nicht weiter gebaut. + ### M02 Rolle bearbeiten Ziel: Admin bearbeitet die Basisdaten und Berechtigungen einer vorhandenen oder gerade angelegten eigenen Rolle, ohne die Rollen-Subpage zu verlassen. Die Systemrolle `Admin` ist geschuetzt. @@ -503,6 +505,7 @@ Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaet | 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 | +| M04-Split pruefen | `Rolle anlegen` und `Duplizieren` ggf. als zwei eigene Screens fuehren | erst nach Davids Freigabe; dann Screen-Dateien, Tracker, Canvas und Subframe sauber synchronisieren | --- diff --git a/02 Wireframes/Screen Paket Tracker.md b/02 Wireframes/Screen Paket Tracker.md index e7c27bb1..68d0cd3d 100644 --- a/02 Wireframes/Screen Paket Tracker.md +++ b/02 Wireframes/Screen Paket Tracker.md @@ -138,6 +138,7 @@ Diese Datei ist der erste Ort, um zu sehen: | WF-P2 Admin RBAC | Rollenmodell | Genommen | Zum Start gibt es nur die Systemrolle `Admin`; Admins koennen eigene Rollen anlegen und benennen. | Vordefinierte Rollen sind raus | | WF-P2 Admin RBAC | Rollen-Vorlagen | WIP | Beim Erstellen einer Rolle koennen spaeter Vorlagen angeboten werden, sie sind aber noch nicht final. | In v1 nur als vorbereiteter/disabled Bereich dokumentieren | | WF-P2 Admin RBAC | Rollen-Editor Einstieg | Genommen | Neue Rolle startet in M04 `Rolle anlegen` mit Name, Beschreibung und Bereich; Bearbeiten springt direkt in M02 `Rolle bearbeiten`. | Duplizieren nutzt M04 V3 mit vorausgefuellten Daten | +| WF-P2 Admin RBAC | M04-Split | Offen | Pruefen, ob `Rolle anlegen` und `Duplizieren` als zwei eigene Screens gefuehrt werden. | Erst nach Davids Freigabe: eigene Screen-Dateien, Tracker-Zeilen, Canvas-Nodes und Subframe-Screens synchronisieren | | WF-P2 Admin RBAC | Settings-Aufteilung | Genommen | `Settings -> Mitarbeiter` wird Oberpunkt; Tabs: `Mitarbeiter`, `Rollen und Berechtigungen`. | Sichtbarer Wireframe-Einstieg; technische Route spaeter abstimmen | | WF-P2 Admin RBAC | Rollenzuweisung | Genommen | In der Mitarbeiterliste gibt es pro Mitarbeiter ein Rollen-Dropdown; Bearbeiten fuehrt zu `Rollen und Berechtigungen`. | Kein eigenes Rollen-Modal aus S01 | | WF-P2 Admin RBAC | Berechtigungen | Genommen | Kein separater Berechtigungen-Tab; Rechtebereiche leben im Tab `Rollen und Berechtigungen` beim Bearbeiten einer Rolle. | Macht das Paket kompakter | @@ -172,6 +173,7 @@ Diese Liste sammelt Punkte, die in einzelnen Paketen als `Backlog`, `Spaeter` od | WF-P2 Profil und Sicherheit | Security / Sessions | Backlog | Eigene Seite fuer aktive Sessions, Trust Devices und Session-Verwaltung | | WF-P2 Profil und Sicherheit | Ueberall abmelden / Session einzeln abmelden | Backlog | Gehoert zur spaeteren Security/Sessions-Seite | | WF-P2 2FA Verwalten | Trust Devices / aktive Sessions | Backlog | Nicht Teil des 2FA-Verwalten-Modals, sondern spaeter Security/Sessions | +| WF-P2 Admin RBAC | M04-Split Rolle anlegen / Duplizieren | Backlog/Klaeren | Nach Freigabe ggf. zwei echte M04-Screens statt Varianten fuehren; dann Screen-Dateien, Tracker, Canvas und Subframe-Flow synchronisieren | | WF-P2 Konto loeschen | Echter Loeschprozess | Backlog | Workspace-/Account-Loeschprozess mit operativer Bearbeitung spaeter ausarbeiten | | WF-P2 Konto loeschen | Voller DSGVO-/Export-Wizard | Backlog | Datenexport-Step, Reauth, Confirm Phrase, Countdown und Legal/Billing-Details spaeter | | WF-P2 Konto loeschen | Workspace-Settings ausbauen | Backlog | Minimaler Workspaces-Bereich enthaelt v1 nur Loeschungsanfrage | diff --git a/AI README.md b/AI README.md index a5d12e8e..42b0e12b 100644 --- a/AI README.md +++ b/AI README.md @@ -37,6 +37,8 @@ Gemeint ist der lokale Ordner `./hivegrid-cloud/`. Wenn fuer die aktuelle Aufgab - 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. +- Bei jeder Screen-Umbenennung, Screen-Aufteilung, Screen-Loeschung oder neuem Subframe-Screen muss der komplette Sync geprueft werden: Screen-Datei, Paket-MD, `Screen Paket Tracker`, Canvas und Subframe-Flow. Wenn daraus mehrere echte Screens entstehen, brauchen sie eigene Tracker-Zeilen und eigene Canvas-Nodes. +- Wenn eine moegliche Screen-Aufteilung noch nicht von David validiert ist, nur als offene Entscheidung dokumentieren und keine neuen Subframe-Screens anlegen. - Backlog-Punkte klar markieren, damit V2-Themen nicht verloren gehen. - Bei Subframe-Arbeit bestehende Nutzer-Anpassungen nicht rueckgaengig machen. - `hivegrid-cloud/` nur als Referenz verwenden. @@ -67,12 +69,12 @@ Standardbefehle: ```bash git status --short -git add . +git add git commit -m "Update wireframe planning" git push ``` -Vor jedem Commit pruefen, dass `hivegrid-cloud/` nicht staged ist. +Vor jedem Commit pruefen, dass `hivegrid-cloud/` nicht staged ist und keine fremden lokalen Aenderungen wie `.obsidian/workspace.json` oder Canvas-Aenderungen versehentlich committed werden. ## Aktueller Remote