Add screen sync workflow rules

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

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.