Add screen sync workflow rules

2026-06-25 19:29:09 +02:00
1 parent ea32264b1b
commit 56c05a425a
@@ -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
@@ -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.
@@ -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 |

 ---

@@ -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 |
@@ -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 <konkrete Dateien>
 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