diff --git a/docs/01_Architecture/c4/01-context-de.puml b/docs/01_Architecture/_archive/01-context-de.puml
similarity index 100%
rename from docs/01_Architecture/c4/01-context-de.puml
rename to docs/01_Architecture/_archive/01-context-de.puml
diff --git a/docs/01_Architecture/c4/02-container-de.puml b/docs/01_Architecture/_archive/02-container-de.puml
similarity index 100%
rename from docs/01_Architecture/c4/02-container-de.puml
rename to docs/01_Architecture/_archive/02-container-de.puml
diff --git a/docs/01_Architecture/c4/03-component-events-service-de.puml b/docs/01_Architecture/_archive/03-component-events-service-de.puml
similarity index 100%
rename from docs/01_Architecture/c4/03-component-events-service-de.puml
rename to docs/01_Architecture/_archive/03-component-events-service-de.puml
diff --git a/docs/01_Architecture/c4/Kernentitaeten_Umbenennung.puml b/docs/01_Architecture/_archive/Kernentitaeten_Umbenennung.puml
similarity index 100%
rename from docs/01_Architecture/c4/Kernentitaeten_Umbenennung.puml
rename to docs/01_Architecture/_archive/Kernentitaeten_Umbenennung.puml
diff --git a/docs/01_Architecture/c4/Kernentitäten.puml b/docs/01_Architecture/_archive/Kernentitäten.puml
similarity index 100%
rename from docs/01_Architecture/c4/Kernentitäten.puml
rename to docs/01_Architecture/_archive/Kernentitäten.puml
diff --git a/docs/01_Architecture/c4/container_diagram.mermaid b/docs/01_Architecture/_archive/container_diagram.mermaid
similarity index 100%
rename from docs/01_Architecture/c4/container_diagram.mermaid
rename to docs/01_Architecture/_archive/container_diagram.mermaid
diff --git a/docs/01_Architecture/c4/system_context.mermaid b/docs/01_Architecture/_archive/system_context.mermaid
similarity index 100%
rename from docs/01_Architecture/c4/system_context.mermaid
rename to docs/01_Architecture/_archive/system_context.mermaid
diff --git a/docs/01_Architecture/c4/container_diagram.drawio b/docs/01_Architecture/c4/container_diagram.drawio
new file mode 100644
index 00000000..91b77e28
--- /dev/null
+++ b/docs/01_Architecture/c4/container_diagram.drawio
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/01_Architecture/c4/workflow_turnieranlage.drawio b/docs/01_Architecture/c4/workflow_turnieranlage.drawio
new file mode 100644
index 00000000..da2d3a64
--- /dev/null
+++ b/docs/01_Architecture/c4/workflow_turnieranlage.drawio
@@ -0,0 +1,34 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/temp/Chat-Verlauf-Gemini_2026-04-07.md b/docs/temp/Chat-Verlauf-Gemini_2026-04-07.md
index 3d822d31..e61637e1 100644
--- a/docs/temp/Chat-Verlauf-Gemini_2026-04-07.md
+++ b/docs/temp/Chat-Verlauf-Gemini_2026-04-07.md
@@ -1592,7 +1592,74 @@ Wie machen wir weiter?
Damit sind Veranstaltung, Turnier und Bewerb architektonisch sauber aufgebaut.
Wollen wir uns nun dem nächsten großen Meilenstein widmen: Den Nennungen (Datenschutzkonformes Web-Formular für lizenzfreie Starter vs. n2-xxxxx.dat Import vom ZNS) sowie der Frage, wie Teilnehmer und ihre Pferde sicher in unsere Bewerbe gebucht und abgerechnet werden?
-
+---
+Ich
+---
+
+Wollen wir nicht zuvor die Desktop-App soweit bekommen, dass wir in der Lage sind:
+- Eine oder mehrere Veranstaltungen anzulegen
+- Zu den jeweiligen Veranstaltungen ein oder mehr Turniere anzulegen
+- Den gesammten Prozess Turnier-anlegen
+- Zum Turnier Prüfungen/Bewerbe anlegen
+- usw.
+ Wir müssen den Prozess genauer denfinieren und die Workflows in kleine hädelbare Einheiten bestimmen, damit wir diese Spartenspezifisch und wartbar entwickeln können. Jetzt und in Zukunft.
+ In
+ docs/01_Architecture/c4
+ haben wir schon einige Diagramme/Grafiken zum visualisieren.
+ Kannst du dir diese einmal genauer unter die Lupe nehmen und diese analysiere, korrigieren bzw. vervollständigen, optimieren und aktualisieren?
+ Wir arbeiteten sowohl mit PantUML und Mermaid, aber ich habe jetzt draw.io entdeckt und bin davon begeistert.
+ Könntest du mir im Zuge dessen mir diese Diagramme usw. auf draw.io umschreiben?
+
+---
+Gemini
+---
+
+🏗️ **[Lead Architect] & 🎨 [Frontend Expert]**
+
+Das ist eine absolut sinnvolle Priorisierung! Bevor wir uns in die komplexe Welt der Nennungen stürzen, muss das Fundament (die "Schubladen" in der Desktop-App) stehen. Wenn der Prozess der Turnieranlage unübersichtlich ist, scheitert das System an der Benutzerakzeptanz.
+
+### 1. Architektur-Diagramme & Draw.io Migration
+
+Ich habe mir die alten `.puml` (PlantUML) und `.mermaid` Diagramme angesehen. Da diese teilweise veraltet waren und Sie draw.io bevorzugen, habe ich die Architektur-Diagramme komplett auf `.drawio` migriert und modernisiert:
+
+* **`container_diagram.drawio` (Neu):** Ersetzt die alten Container-Diagramme. Es zeigt klar den Offline-First-Ansatz (Desktop App mit lokaler SQLite) und die Synchronisation mit dem Cloud-Backend.
+* **`workflow_turnieranlage.drawio` (Neu):** Ein komplett neues Flussdiagramm, das exakt den unten beschriebenen 3-stufigen Wizard-Prozess für die Desktop-App visualisiert.
+
+*(Hinweis: Sie können die alten `.puml` und `.mermaid` Dateien im Ordner `docs/01_Architecture/c4/` nun gefahrlos löschen, um das Repository sauber zu halten).*
+
+---
+
+### 2. Der Desktop-App Workflow: "Kleine, händelbare Einheiten"
+
+Um die UI/UX in der Desktop-App (Compose Multiplatform) wartbar und spartenspezifisch zu entwickeln, brechen wir den "Turnier anlegen"-Prozess in einen sauberen **3-stufigen Wizard** herunter. Dies entspricht exakt unserer Domain-Hierarchie:
+
+#### 🟢 Schritt 1: Die Veranstaltung (Das Event-Wochenende)
+*Das ist die organisatorische "Klammer" für alles Weitere.*
+* **Basisdaten:** Name (z.B. "Pferdesporttage Neumarkt"), Zeitraum, Ort.
+* **Stammdaten-Import:** Upload der `ZNS.zip`. Das befüllt unseren lokalen Offline-Pool mit Reitern, Pferden und Funktionären für dieses Wochenende.
+* **Infrastruktur:** Anlegen der Austragungsplätze (z.B. "Waldarena", "Vorbereitungsplatz").
+* **Preisliste:** Definieren der Zusatzartikel (z.B. "Heu", "Ansage", "Tagesbox"), die der Veranstalter verkauft.
+
+#### 🟡 Schritt 2: Das Turnier (Der offizielle Rahmen)
+*Hier konfigurieren wir den eigentlichen sportlichen Wettbewerb.*
+* **Identifikation:** Eingabe der 5-stelligen OEPS-Nummer (z.B. `26128`), Auswahl von Reglement (ÖTO), Sparte (Springen) und Kategorie (CSN-C).
+* **Regelwerk:** Festlegen von Nennschluss, Nachnenngebühren und Nenntauschbörse.
+* **Teilnehmerkreis:** Eventuelle Einschränkungen (Haflinger, Noriker, etc.) nach ÖTO § 3.
+* **Der "Chef":** Zuweisung des Turnierbeauftragten (TB) aus dem zuvor geladenen Funktionärs-Pool.
+* **Nenndaten-Import:** Upload der `n2-26128.dat` (falls Nennungen vom ZNS kommen).
+
+#### 🟠 Schritt 3: Die Bewerbe (Das sportliche Programm)
+*Dies ist die feinste Granularität – hier entsteht der Zeitplan.*
+* **Identifikation:** Bewerbsnummer, Bezeichnung, Klasse/Höhe und die genaue Aufgabe (z.B. "R1").
+* **Ort & Zeit:** Zuweisung zu einem Austragungsplatz, Beginnzeit (Fix/Anschließend), Reitdauer und Pausen (Umbau/Besichtigung).
+* **Funktionäre:** Zuweisung der Richter auf spezifische Positionen (z.B. "C", "M") mit unserer "Warn-Logik" für Qualifikationen.
+* **Finanzen:** Festlegen von Startgeld und ob Preisgeld ausbezahlt wird.
+* **Die Teilungsregel:** Das Wichtigste! Wie wird geteilt? (z.B. `NACH_LIZENZ`, `MANUELL`).
+
+---
+
+**Nächster Schritt für uns:**
+Sollen wir als 🎨 **[Frontend Expert]** genau diesen Wizard (Schritt 1 bis 3) jetzt in Compose Multiplatform als UI-Komponenten (Screens/ViewModels) konzipieren und implementieren, damit Sie die Turnieranlage in der Desktop-App testen können?