Migrate frontend navigation to V3: archive Navigation V2, implement updated screen-tree and back-stack rules, and adapt documentation for startable MVP flow.

docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md

@@ -0,0 +1,66 @@
+---
+type: Architecture
+status: ACTIVE
+owner: 🏗️ Lead Architect & 🧹 Curator
+last_update: 2026-04-02
+sources:
+  - docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md
+  - Domain Workshop 2026-03-24
+---
+
+# Tenant‑Konzept: „Eine Veranstaltung = eine Datenbank“ (in einfacher Sprache)
+
+Kurz gesagt: Jede Veranstaltung bekommt ihre eigene kleine Datenbank. So bleiben Daten sauber getrennt, und die Meldestelle kann offline sicher arbeiten, ohne andere Veranstaltungen zu berühren.
+
+---
+
+## 1. Warum machen wir das?
+
+- Sicherheit und Ordnung: Was zu Veranstaltung A gehört, landet nicht aus Versehen bei Veranstaltung B.
+- Offline‑Tauglichkeit: Eine Datenbank pro Veranstaltung ist klein, lokal und schnell zu sichern/verteilen.
+- Einfache Abrechnung: Die Veranstaltungs‑Kassa und die TeilnehmerKonten sind klar auf Event‑Ebene definiert.
+
+---
+
+## 2. Wie wird bestimmt, welche Datenbank benutzt wird?
+
+Siehe Architektur‑Entscheidung (ADR‑0021):
+
+- Datei: `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`
+- Kerngedanke: Die App leitet aus dem aktuellen „Arbeitskontext“ (gewählte Veranstaltung) den Tenant ab. Alle Lese/Schreib‑Operationen gehen automatisch in die richtige Event‑Datenbank.
+
+---
+
+## 3. Auswirkungen im Überblick
+
+### a) Datenbank‑Schema (Backend)
+
+- Pro Veranstaltung ein eigenes Schema/Datei (z. B. `event-{eventId}.db`).
+- Tabellen wiederholen sich je Veranstaltung (z. B. `turniere`, `bewerbe`, `abteilungen`, `startlisten`, `kassa_belege`).
+- Keine Vermischung zwischen Veranstaltungen. Für Auswertungen über mehrere Veranstaltungen braucht es einen Aggregations‑Prozess.
+
+### b) API‑Design
+
+- Jeder Request enthält implizit oder explizit den Event‑Kontext (Header, Pfad oder Session‑Scope).
+- Schreib‑Operationen validieren, dass die Ziel‑IDs (Turnier, Bewerb, Abteilung) zur aktuellen Veranstaltung gehören.
+- Export/Import: Datenpakete sind pro Veranstaltung abgegrenzt (leichte Weitergabe an Verband oder andere Systeme).
+
+### c) Frontend (Navigation & State)
+
+- Beim Eintritt in eine Veranstaltung wird der Tenant gesetzt; alle folgenden Screens arbeiten innerhalb dieses Kontexts.
+- Wechsel der Veranstaltung leert relevante Caches und setzt den Back‑Stack definiertermaßen zurück (→ Navigation V2).
+- Multi‑Turnier‑Fälle innerhalb EINER Veranstaltung bleiben möglich (Turnierkassa je Turnier, Konsolidierung in Veranstaltungs‑Kassa).
+
+---
+
+## 4. Grenzen & Trade‑offs
+
+- Cross‑Event‑Suche/Auswertung erfordert separate Aggregation (bewusste Entscheidung zugunsten Offline‑First und Sicherheit).
+- Datenmigration (z. B. Zusammenlegen/Teilen von Veranstaltungen) braucht Tools/Assistenten.
+
+---
+
+## 5. Beziehung zur Domäne
+
+- Ubiquitous Language: `Veranstaltung` ist die Root. Kassen und TeilnehmerKonten sind auf Event‑Ebene verankert.
+- Zahlvorgänge können mehrere Rechnungen/Belege aus verschiedenen Turnieren derselben Veranstaltung ausgleichen.

docs/02_Guides/Event-First-Workflow.md

@@ -0,0 +1,82 @@
+---
+type: Guide
+status: ACTIVE
+owner: 🧹 Curator & 🏗️ Lead Architect
+last_update: 2026-04-02
+sources:
+  - docs/03_Domain/01_Glossary/Ubiquitous_Language.md
+  - Domain Workshop 2026-03-17
+---
+
+# Event‑First‑Workflow (MVP)
+
+Ziel: Ein neuer Veranstaltungs‑Durchlauf wird konsequent „Event‑First“ aufgebaut. Dabei folgt der Bedienfluss strikt der Domänen‑Hierarchie:
+
+Veranstaltung → Turnier → Bewerbe → Abteilungen → Startliste
+
+---
+
+## 1. Vorbedingungen
+
+- Verein (→ Begriff: Veranstalter) ist im System vorhanden.
+- Grundlegende Stammdaten synchron (Reiter, Pferde, Vereine) – optional für die Planung, erforderlich für Startlisten.
+
+Querverweis: → Ubiquitous Language, Abschnitt „Hierarchie der Veranstaltungs‑Struktur“ und Begriffe „Veranstaltung“, „Turnier“, „Bewerb“, „Abteilung“, „Startliste“.
+
+---
+
+## 2. Schritt‑für‑Schritt
+
+1) Veranstaltung anlegen
+   - Eingaben: Titel, Datum(e), Ort, Typ (Turnier, Reitertreffen, …), Veranstalter (Vereinsnummer), interne Event‑ID (System vergibt).
+   - Output: Veranstaltung existiert, → Veranstaltungs‑Kassa und → TeilnehmerKonto‑Container werden vorbereitet.
+
+2) Turnier anlegen (innerhalb der Veranstaltung; mehrfach möglich)
+   - Eingaben: Turniernummer (offiziell, wenn vorhanden), Sparte(n) (z. B. CDN, CSN), Kategorie (C‑NEU, C, …), geplanter Zeitraum.
+   - Output: Turnier angelegt, → Turnierkassa eröffnet; Ausschreibungs‑Metadaten vorbereiten.
+
+3) Bewerbe anlegen (pro Turnier)
+   - Eingaben: fortlaufende Bewerbsnummer, Bezeichnung, Klasse/Höhe, Richtverfahren, Startberechtigungen.
+   - Output: Bewerbe als Container für Abteilungen vorhanden.
+
+4) Abteilungen planen/anlegen (pro Bewerb, mindestens eine)
+   - Eingaben: Abteilungsnummer (fortlaufend), Abteilungs‑Typ: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH`, optional Teilnehmerkreis‑Filter (Lizenz, Altersklasse …).
+   - Systemhinweis: Bei Überschreiten von ÖTO‑Schwellenwerten zeigt das System WARNUNG + Option „Override“ (→ TBA hat letztes Wort).
+   - Output: Abteilungen stehen für Nennungen/Startlisten bereit.
+
+5) Startliste erzeugen (pro Abteilung)
+   - Eingaben: Nennungen (Paar Reiter+Pferd), Reihenfolgen‑Logik (z. B. Zufall, Startwunsch), Kollisionen prüfen.
+   - Output: Fixierte Startliste je Abteilung; Grundlage für Ergebniserfassung und Abrechnung (Sportförderbeitrag, Tierwohl‑Euro pro Start).
+
+---
+
+## 3. Rollen & Verantwortungen
+
+- Meldestelle: Erfassung/Prüfung der Daten, Startlistenpflege, Kassenabwicklung.
+- TBA (Turnierbeauftragter): Genehmigung von Abteilungs‑Overrides und Regel‑Abweichungen (Override‑Event wird protokolliert).
+- Veranstalter: Finanzielle Verantwortung, Kassen‑Schluss, Freigabe der Ausschreibung.
+
+---
+
+## 4. Artefakte & Systemobjekte
+
+- Veranstaltung (Root) → Veranstaltungs‑Kassa, TeilnehmerKonto‑Container, Multi‑Turnier‑Verrechnung.
+- Turnier → Turnierkassa, Ausschreibung.
+- Bewerb → Liste von Abteilungen.
+- Abteilung → kleinste ausführbare Einheit (Nennungen, Startliste, Ergebnis, Siegerehrung nach Typ).
+
+---
+
+## 5. Akzeptanzkriterien (MVP)
+
+- Erstellung in exakt der Reihenfolge möglich; Zwischenspeichern und spätere Fortsetzung unterstützt.
+- Abteilungen mindestens 1 pro Bewerb; Typ wählbar; Warnungen bei ÖTO‑Schwellenwert‑Überschreitung.
+- Startliste pro Abteilung generierbar; Kollisionen und Startwünsche werden berücksichtigt.
+- Abrechnung: Gebühren pro Start (Sportförderbeitrag, Tierwohl‑Euro) werden korrekt ausgewiesen; Zahlvorgänge können turnierübergreifend auf TeilnehmerKonto verbucht werden (Event‑Ebene).
+
+---
+
+## 6. Querverweise
+
+- Domänenbegriffe: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`
+- ÖTO‑Schwellenwerte: `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`

docs/03_Domain/01_Glossary/Ubiquitous_Language.md

@@ -2,7 +2,7 @@
 type: Reference
 status: ACTIVE
 owner: Lead Architect & ÖTO/FEI Rulebook Expert
-last_update: 2026-03-28
+last_update: 2026-04-02
 sources:
   - ÖTO 2026, Abschnitt A I, § 2 & § 3 & § 4
   - Domain Workshop 2026-03-17
@@ -48,7 +48,9 @@ Veranstalter (OEPS-Mitgliedsverein)
 
 | Begriff           | Definition                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | ÖTO-Referenz                |
 |-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------|
-| **Abteilung**     | **Atomare operative Einheit für Startlisten und Ergebnisse.** Untereinheit eines Bewerbs mit eigenem Teilnehmerkreis (Lizenz, Pferdealter etc.) und eigener Platzierung/Siegerehrung. Erhält eine fortlaufende **Abteilungsnummer** (1, 2, ...) innerhalb des Bewerbs. Referenz auf Startliste/Ergebnisliste: `BW: 9 Abt: 1` bzw. `9-1`. Die ÖTO definiert sparten- und klassenabhängige Schwellenwerte, ab wievielen Startern eine Abteilung **verpflichtend** getrennt werden muss. Bei Überschreitung gibt das System eine **WARNUNG** (kein harter Fehler) – der TBA hat das letzte Wort (→ *Override-Event*). Vollständige Schwellenwert-Tabellen: → [`Abteilungs-Trennungs-Schwellenwerte.md`](../02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md) | ÖTO § 2 Abs. 7, § 39        |
+| **Abteilung**     | **Kleinste ausführbare, atomare Einheit** für Nennungen, Startlisten, Ergebnisse und Auswertungen. Untereinheit eines Bewerbs mit eigenem Teilnehmerkreis (Lizenz, Pferdealter etc.). Erhält eine fortlaufende **Abteilungsnummer** (1, 2, ...) innerhalb des Bewerbs. Referenz auf Startliste/Ergebnisliste: `BW: 9 Abt: 1` bzw. `9-1`.  
+**Abteilungs-Typen:** `SEPARATE_SIEGEREHRUNG` (= eigene Platzierung, eigene Siegerehrung, separater Ergebnislauf) | `ORGANISATORISCH` (= organisatorische Teilung, z.B. zur Ablaufoptimierung; Platzierung/Preise werden gemeinsam mit anderen Abteilungen dieses Bewerbs geführt).  
+Die ÖTO definiert sparten- und klassenabhängige Schwellenwerte, ab wievielen Startern eine Abteilung **verpflichtend** getrennt werden muss. Bei Überschreitung gibt das System eine **WARNUNG** (kein harter Fehler) – der TBA hat das letzte Wort (→ *Override-Event*). Vollständige Schwellenwert-Tabellen: → [`Abteilungs-Trennungs-Schwellenwerte.md`](../02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md) | ÖTO § 2 Abs. 7, § 39        |
 | **Akteur**        | Historischer Begriff (siehe → *Stammdaten*). Oberbegriff für alle Personen (Reiter, Richter, Funktionäre, Besitzer) und Organisationen (Vereine), die im System interagieren.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | –                           |
 | **Ausschreibung** | Das offizielle Dokument, das alle Bedingungen eines Turniers festlegt. Pflichtfelder gemäß ÖTO (A-Satz der ZNS-Schnittstelle).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              | ÖTO Ausschreibungs-Struktur |
 
@@ -152,6 +154,8 @@ Veranstalter (OEPS-Mitgliedsverein)
 | **Turnier**          | In unserer Software: Eine pferdesportliche Veranstaltung mit einer offiziellen **Ausschreibung** und einer vom OEPS/LFV vergebenen, eindeutigen **Turniernummer**. Entspricht ÖTO § 2 Abs. 2. Ist eine Spezialisierung von → *Veranstaltung*. | ÖTO § 2 Abs. 2, § 5, § 24 |
 | **Turniernummer**    | Vom OEPS vergebene, eindeutige Kennung eines Turniers (z.B. `25123`). Ohne diese Nummer darf keine offizielle Ausschreibung veröffentlicht werden.                                                                                            | ZNS A-Satz                |
 | **Turnierkategorie** | Siehe → *Kategorie*.                                                                                                                                                                                                                          | ÖTO § 3 Abs. 4            |
+| **Turnierkassa**     | Kassa auf Ebene des einzelnen → *Turniers*. Hält Belege, Tagesabschlüsse und Barbestände pro Turnier. Wird in der → *Veranstaltungs‑Kassa* konsolidiert.                                                                                                                             | Billing Context           |
+| **TeilnehmerKonto**  | Konto eines Zahlers auf Ebene der → *Veranstaltung* (nicht nur eines Turniers). Aggregiert Saldo, Einzahlungen und Verrechnungen über alle → *Turniere* derselben Veranstaltung hinweg (Multi‑Turnier‑Aggregation). Ermöglicht, dass eine einzelne Zahlung mehrere Rechnungen in verschiedenen Turnieren derselben Veranstaltung ausgleicht.                         | Billing Context           |
 
 ### V
 
@@ -159,12 +163,14 @@ Veranstalter (OEPS-Mitgliedsverein)
 |-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------|
 | **Veranstaltung** | In unserer Software: Der Oberbegriff für jede Art von pferdesportlicher Veranstaltung, die von einem Verein durchgeführt wird. Erhält eine **intern vergebene ID**. Entspricht dem ÖTO-Oberbegriff „Pferdesportliche Veranstaltung" (§ 2 Abs. 1). Kann vom Typ Turnier, Reitertreffen, Sonderprüfung, PS&S oder Turnierartig sein. | ÖTO § 2 Abs. 1  |
 | **Veranstalter**  | OEPS-Mitgliedsverein (über LFV angeschlossen), der eine Veranstaltung ausrichtet. Besitzt eine **Vereinsnummer**.                                                                                                                                                                                                                  | ÖTO § 2 Abs. 12 |
+| **Veranstaltungs‑Kassa** | Kassen- und Abrechnungsführer auf Ebene der → *Veranstaltung*. Konsolidiert alle Zahlungen, Belege und Rückgelder über mehrere → *Turniere* derselben Veranstaltung. Dient als zentrale Sammelkasse; kann Zahlvorgänge turnierübergreifend splitten und konsolidieren.                                                     | Billing Context |
 
 ### Z
 
-| Begriff | Definition                                                                                                                                 | ÖTO-Referenz      |
-|---------|--------------------------------------------------------------------------------------------------------------------------------------------|-------------------|
-| **ZNS** | Zentrales Nennsystem des OEPS. Datenaustausch-Format für Stammdaten (Reiter, Pferde) und Nennungen. Quelle der Wahrheit für Akteurs-Daten. | ZNS-Schnittstelle |
+| Begriff         | Definition                                                                                                                                                                                                                                 | ÖTO-Referenz      |
+|-----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|
+| **Zahlvorgang** | Eine einzelne Zahlungstransaktion (Bar, Karte, Überweisung), die einen Betrag einem → *TeilnehmerKonto* gutschreibt und dabei **eine Zahlung auf mehrere Rechnungen/Belege** aufteilen kann – auch turnierübergreifend innerhalb derselben → *Veranstaltung*. | Billing Context   |
+| **ZNS**         | Zentrales Nennsystem des OEPS. Datenaustausch-Format für Stammdaten (Reiter, Pferde) und Nennungen. Quelle der Wahrheit für Akteurs-Daten.                                                                                                | ZNS-Schnittstelle |
 
 ---
 

docs/04_Agents/Roadmaps/Curator_Roadmap.md

@@ -7,7 +7,7 @@
 
 ## 🔴 Sprint A — Sofort (diese Woche)
 
-- [ ] **A-1** | `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect)
+- [x] **A-1** | `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect)
   - [ ] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` eintragen
   - [ ] `Abteilung` als eigenständigen Begriff definieren (kleinste ausführbare Einheit)
   - [ ] `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` als Abteilungs-Typen definieren
@@ -15,24 +15,24 @@
   - [ ] `Veranstaltungs-Kassa` und `TurnierKassa` als separate Begriffe definieren
   - [ ] `Zahlvorgang` (eine Zahlung, mehrere Rechnungen) definieren
 
-- [ ] **A-2** | Event-First-Workflow dokumentieren
-  - [ ] Ablauf: Veranstaltung anlegen → Turnier anlegen → Bewerbe anlegen → Abteilungen → Startliste
-  - [ ] Dokument in `docs/01_Architecture/` oder `docs/02_Guides/` ablegen
+- [x] **A-2** | Event-First-Workflow dokumentieren
+  - [x] Ablauf: Veranstaltung anlegen → Turnier anlegen → Bewerbe anlegen → Abteilungen → Startliste
+  - [x] Dokument in `docs/01_Architecture/` oder `docs/02_Guides/` ablegen → `docs/02_Guides/Event-First-Workflow.md`
 
-- [ ] **A-3** | Navigation-V2 dokumentieren
-  - [ ] Aktuellen Screen-Baum und Back-Stack-Verhalten beschreiben
-  - [ ] Dokument in `docs/06_Frontend/` ablegen
+- [x] **A-3** | Navigation-V2 dokumentieren
+  - [x] Aktuellen Screen-Baum und Back-Stack-Verhalten beschreiben
+  - [x] Dokument in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
 
-- [ ] **A-4** | Tenant-Konzept dokumentieren (nach ADR-0021 vom Architect)
-  - [ ] ADR-0021 in `docs/01_Architecture/ADRs/` verlinken
-  - [ ] Konzept "eine Veranstaltung = eine Datenbank (Tenant)" in Laien-Sprache erklären
-  - [ ] Auswirkungen auf Schema, API und Frontend zusammenfassen
+- [x] **A-4** | Tenant-Konzept dokumentieren (nach ADR-0021 vom Architect)
+  - [x] ADR-0021 in `docs/01_Architecture/ADRs/` verlinken → `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`
+  - [x] Konzept "eine Veranstaltung = eine Datenbank (Tenant)" in Laien-Sprache erklären
+  - [x] Auswirkungen auf Schema, API und Frontend zusammenfassen → `docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md`
 
-- [ ] **A-5** | Session-Log für heutige Besprechung (2. April 2026) erstellen
-  - [ ] Alle Beschlüsse der Meldestelle-Besprechung eintragen
-  - [ ] Domänen-Korrekturen (Abteilung, Kassa, Veranstaltungs-Hierarchie) festhalten
-  - [ ] Zurückgestellte Themen (USB-Fallback, Web-App, Nenn-System) als ⏸️ markieren
-  - [ ] Log in `docs/99_Journal/` ablegen
+- [x] **A-5** | Session-Log für heutige Besprechung (2. April 2026) erstellen
+  - [x] Alle Beschlüsse der Meldestelle-Besprechung eintragen
+  - [x] Domänen-Korrekturen (Abteilung, Kassa, Veranstaltungs-Hierarchie) festhalten
+  - [x] Zurückgestellte Themen (USB-Fallback, Web-App, Nenn-System) als ⏸️ markieren
+  - [x] Log in `docs/99_Journal/` ablegen → `docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md`
 
 ---
 

docs/06_Frontend/Navigation_Routing_Diagramm.md

@@ -14,6 +14,12 @@ Generiert aus: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode
 
 ---
 
+MVP-Hinweis (2026-04-02):
+- Die Desktop‑App startet im MVP ohne erzwungenen Login/Ping direkt in die Haupt‑Shell (Veranstaltungs‑Verwaltung).
+- Der Login‑Knoten und Auth‑Guard im Diagramm bleiben aus Planungsgründen sichtbar, sind jedoch im MVP deaktiviert.
+
+---
+
 ## 1. Übersicht: NavRail-Einstiegspunkte
 
 Die linke Navigationsleiste (NavRail) bietet folgende Direkteinstiege:

docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md

@@ -0,0 +1,15 @@
+---
+type: Redirect
+status: MOVED
+owner: 🧹 Curator
+last_update: 2026-04-02
+moved_to: docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md
+replaced_by: docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
+---
+
+# Navigation V2 — verschoben ins Archiv
+
+Dieses Dokument wurde in das Archiv verschoben und durch „V3“ ersetzt.
+
+- Archiv: `docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
+- Aktuelle Version: `docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md`

docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md

@@ -0,0 +1,125 @@
+---
+type: Frontend
+status: ACTIVE
+owner: 🎨 Frontend Expert & 🧹 Curator
+last_update: 2026-04-02
+sources:
+  - docs/06_Frontend/Navigation_Routing_Diagramm.md
+  - docs/02_Guides/Event-First-Workflow.md
+  - docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md
+replaces: docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md
+---
+
+# Navigation V3 — Screen‑Baum & Back‑Stack‑Regeln (jetzt gültig)
+
+Dieses Dokument beschreibt die jetzt gültige, startfähige Fassung der Desktop‑App Navigation (Compose Multiplatform, MVP‑Stand ohne erzwungenen Login/Ping).
+
+---
+
+## 1. Screen‑Baum (Routen)
+
+- AppRoot
+  - MainShell (ohne Login/Ping)
+    - Veranstaltungen (Tab‑Root)
+      - Veranstaltung.Detail(eventId)
+        - Turnier.Detail(tournamentId)  
+          - Bewerb.Detail(contestId)
+            - Abteilung.Detail(divisionId)
+              - Startliste(divisionId)
+          - Kassa.Turnier(tournamentId)
+        - Kassa.Veranstaltung(eventId)
+    - StammdatenImport (Tab‑Root)
+    - Reiter (Tab‑Root, Placeholder)
+    - Pferde (Tab‑Root, Placeholder)
+    - Funktionaere (Tab‑Root, Placeholder)
+    - Meisterschaften (Tab‑Root, Placeholder)
+    - Cups (Tab‑Root, Placeholder)
+
+Hinweise:
+- Fachliche Struktur folgt dem Event‑First‑Workflow: Veranstaltung → Turnier → Bewerb → Abteilung. Abteilung ist kleinste ausführbare Einheit.
+- Kassen‑Screens existieren getrennt für Turnier und Veranstaltung (Terminologie gemäß Ubiquitous Language).
+
+---
+
+## 1a. Haupt‑Shell (Abfragen, Status & Einstieg)
+
+Quellen: `frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/DesktopApp.kt`,
+`frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/layout/DesktopMainLayout.kt`,
+`frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/navigation/DesktopNavigationPort.kt`
+
+- Einstieg/Startzustand
+  - Start‑Screen in der Desktop‑Shell ist `AppScreen.Onboarding` (siehe `DesktopNavigationPort`, Initialwert und `DesktopApp` Login‑Gate).
+  - Onboarding setzt im MVP ein Dummy‑Token via `AuthTokenManager.setToken(...)` und leitet in `VeranstaltungVerwaltung` weiter.
+  - Kein erzwungener Login im MVP: `DesktopApp` erlaubt zentrale Screens ohne Auth, Login‑Route existiert weiterhin optional.
+
+- TopBar (Breadcrumb)
+  - Zeigt kontextabhängige Breadcrumbs (Verwaltung → Veranstalter → Veranstaltung → Turnier ...), inkl. Klick‑Navigation auf Eltern.
+  - Kein Logout‑Button im MVP (auf Kundenwunsch entfernt).
+
+- Content (Screens)
+  - Zentrale Verwaltung: `VeranstaltungVerwaltungV2` mit Navigations‑Callbacks zu Profilen, Import, Reiter/Pferde/Funktionäre/Vereine.
+  - Ping‑Screen existiert (`PingScreen`/`PingViewModel`), ist aber kein Einstiegspunkt und wird nicht automatisch abgefragt.
+
+- Footer/Statusleiste (`DesktopFooterBar`)
+  - Zeigt Online/Offline‑Status (MVP: Stub‑State), Geräte‑Verbindungsstatus inkl. Gerätename „Richter‑Turm“ (Stub) und Chat‑Trigger, wenn Gerät verbunden.
+  - Dient rein der Anzeige; keine Navigations‑Einträge im Back‑Stack.
+
+- Validierungs‑Hinweise
+  - Bei inkonsistentem Kontext (z. B. IDs nicht vorhanden) wird ein `InvalidContextNotice` mit Rücksprung angeboten.
+
+---
+
+## 2. Navigations‑Konventionen
+
+- Route IDs: stabile, serialisierbare IDs (`eventId`, `tournamentId`, `contestId`, `divisionId`).
+- SingleTop/SingleTask je Tab: erneuter Klick auf einen Tab bringt zum jeweiligen Tab‑Root, Stack bleibt je Tab erhalten.
+- Hierarchischer Drilldown (Parent → Child). „Zurück“ führt jeweils eine Ebene hoch.
+- Deep Links: `app://event/{eventId}/tournament/{tId}/contest/{cId}/division/{dId}` öffnen direkt die Abteilung; Eltern werden synthetisch für den Back‑Pfad aufgebaut.
+
+---
+
+## 3. Back‑Stack‑Regeln (V3)
+
+1) App‑Start
+   - Startet in MainShell → Tab „Veranstaltungen“.
+
+2) Wechsel Tab → Tab
+   - Eigener Stack je Tab; Wechsel speichert und restauriert den jeweiligen Stack (SingleTask je Tab).
+
+3) Navigieren innerhalb „Veranstaltungen“
+   - Veranstaltungen (Liste) → Veranstaltung.Detail → Turnier.Detail → Bewerb.Detail → Abteilung.Detail → Startliste.
+   - „Zurück“ springt exakt eine Ebene zurück; beim Verlassen von Startliste zurück zur Abteilung.
+
+4) Kassa öffnen
+   - Von Turnier.Detail zu Kassa.Turnier: Push auf Stack, Back kehrt zu Turnier.Detail zurück.
+   - Von Veranstaltung.Detail zu Kassa.Veranstaltung: Push auf Stack, Back kehrt zu Veranstaltung.Detail zurück.
+
+5) Override‑Dialoge (Regelwerk)
+   - Modal/Sheet, kein eigener Stack‑Eintrag. Schließen kehrt zum aktuellen Screen zurück. Override‑Events werden protokolliert.
+
+6) Auth/Logout (MVP)
+   - Kein erzwungener Login; Logout‑Sonderregeln aus V2 sind im MVP nicht aktiv. Bei späterer Aktivierung gelten die bisherigen Regeln (MainShell‑Stack leeren, zurück zum Entry).
+
+---
+
+## 4. Zustandsmanagement
+
+- Screens sind UDF/MVVM‑kompatibel (Details separat dokumentiert).
+- Navigation‑State kann optional `returnTo` für spätere Login‑Flows halten; im MVP ohne Wirkung.
+
+---
+
+## 5. Edge‑Cases & Tests
+
+- Abteilungswechsel: Beim Wechsel der Abteilung innerhalb eines Bewerbs bleibt der Stack auf Bewerb‑Ebene erhalten; nur das Abteilung‑Detail wird ersetzt.
+- Datenverlust vermeiden: Vor Navigation prüfen, ob ungespeicherte Änderungen vorliegen (z. B. Kassa‑Buchung), ggf. Confirm‑Dialog.
+- Deep‑Link Pfadaufbau: synthetische Eltern korrekt in den Back‑Pfad einhängen.
+
+---
+
+## 6. Querverweise
+
+- Routing‑Diagramm: `docs/06_Frontend/Navigation_Routing_Diagramm.md`
+- Event‑First‑Workflow: `docs/02_Guides/Event-First-Workflow.md`
+- Begriffe: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`
+- Analyse/Begründung: `docs/06_Frontend/Reports/2026-04-02_Navigation_Versionierung_Analyse_V2_vs_V3.md`

docs/06_Frontend/Reports/2026-04-02_Navigation_Versionierung_Analyse_V2_vs_V3.md

@@ -0,0 +1,103 @@
+---
+type: Report
+status: ACTIVE
+owner: 🎨 Frontend Expert
+last_update: 2026-04-02
+sources:
+  - docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md
+  - docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md
+  - docs/06_Frontend/Navigation_Routing_Diagramm.md
+  - docs/02_Guides/Event-First-Workflow.md
+---
+
+# Frontend Navigation — Versionsanalyse V2 → V3
+
+Dieses Dokument analysiert die Abweichungen zwischen der Dokumentation „Navigation V2“ und der tatsächlich startfähigen Desktop‑App und legt ein konsistentes Vorgehen für „V3“ fest.
+
+---
+
+## 1) Zusammenfassung (Executive Brief)
+
+- Problem: „Navigation V2“ enthält Elemente (Ping/SystemStatus, Login‑Flow), die in der aktuell startfähigen Desktop‑App nicht aktiv genutzt werden. Dadurch entstand ein Versions‑Drift in Doku und Kommunikation („V2“ wurde fälschlich als aktuell betrachtet).
+- Entscheidung: Wir führen „V3“ als jetzt gültige, startfähige Fassung ein. „V2“ wird als „DEPRECATED“ markiert und bleibt als Referenz erhalten.
+- Ziel: Einheitliche, aktuelle SSoT für Navigation/Back‑Stack, synchron mit Event‑First‑Workflow und der laufenden Desktop‑App.
+
+---
+
+## 2) Befunde (V2 vs. aktueller Stand)
+
+- Start‑Pfad
+  - V2: „Landing → SystemStatus (Ping), Login“ beschrieben.
+  - Aktuell: App startet ohne aktiven Ping‑Screen und ohne verpflichtenden Login‑Flow direkt in die Haupt‑Shell.
+
+- Auth/Login
+  - V2: Login/returnTo vorgesehen, Back‑Stack berücksichtigt Logout.
+  - Aktuell: Kein aktiver Login‑Zwang; Logout‑Regel daher für MVP nicht relevant.
+
+- Tabs/NavRail
+  - V2: Haupt‑Tabs wie Dashboard, Veranstaltungen, Suche, Einstellungen.
+  - Aktuell: „Veranstaltungen“ ist implementiert; weitere Bereiche sind (teils) Placeholder. Siehe „Navigation_Routing_Diagramm.md“ (Stand 2026‑03‑26).
+
+- Event‑First‑Workflow
+  - Konsistenz: Die fachliche Hierarchie Veranstaltung → Turnier → Bewerb → Abteilung bleibt gültig (Session‑Log 2026‑04‑02).
+  - Kleinste ausführbare Einheit: Abteilung.
+
+- Kassa‑Flows
+  - Terminologie und Platzierung (Turnierkassa, Veranstaltungs‑Kassa) bleiben konzeptionell richtig; UI‑Verfügbarkeit im MVP ist noch selektiv.
+
+---
+
+## 3) Vorschlag „V3“ (jetzt gültige Fassung)
+
+- Start & Shell
+  - AppRoot startet direkt in „MainShell“ (ohne Ping/Login).
+  - Primärer Einstiegspunkt: Tab „Veranstaltungen“.
+
+- Tabs/NavRail (V3 Status)
+  - Veranstaltungen: ACTIVE (implementiert)
+  - Stammdaten‑Import: ACTIVE (UI vorhanden; Polling noch offen laut Diagramm)
+  - Reiter, Pferde, Funktionäre, Meisterschaften, Cups: PLACEHOLDER
+
+- Drilldown Veranstaltungen (V3)
+  - Veranstaltungen (Liste)
+    → Veranstaltung.Detail
+      → Turnier.Detail (inkl. Nennungs‑Tab / Stammdaten v2)
+        → Bewerb.Detail → Abteilung.Detail → Startliste
+  - Back: jeweils exakt eine Ebene hoch (keine modale Einträge im Stack)
+
+- Back‑Stack Regeln (V3)
+  - Tabs: SingleTop/SingleTask je Tab (Wechsel erhält jeweiligen Stack)
+  - Modale Override‑Dialoge: kein eigener Stack‑Eintrag; Schließen kehrt zurück
+  - Logout‑Sonderfall: vorerst „n. v.“ im MVP (kein erzwungener Login)
+
+---
+
+## 4) Migration & Aufräumen
+
+- Dokumente
+  - „Navigation_V2_Screen‑Baum_und_Back‑Stack.md“ → Status: DEPRECATED, Verweis auf „Navigation_V3_…“
+  - Neues Dokument: „Navigation_V3_Screen‑Baum_und_Back‑Stack.md“ (jetzt gültige Fassung)
+
+- Querverweise
+  - Session‑Logs und Roadmaps behalten Verweise auf V2 als historische Referenz, ergänzen aber den Link zu V3 als SSoT.
+
+- Code‑Ausrichtung (non‑functional in diesem Schritt)
+  - Prüfen, ob Routing‑Guards/Login‑Artefakte im Code noch referenziert werden; falls ja, als Feature‑Flags/TODO kennzeichnen oder entfernen, um Doku‑Drift zu vermeiden.
+
+---
+
+## 5) Akzeptanzkriterien (V3)
+
+- Beim App‑Start landet der User ohne Ping/Login direkt im Tab „Veranstaltungen“.
+- Tab‑Wechsel bewahrt je Tab den eigenen Stack (SingleTop/SingleTask Verhalten dokumentiert).
+- Drilldown und Back‑Navigation entlang Event‑First‑Workflow funktionieren deterministisch (eine Ebene zurück).
+- Dokumente sind konsistent: V3 beschreibt genau das implementierte Verhalten; V2 ist klar als veraltet markiert.
+
+---
+
+## 6) Nächste Schritte
+
+1) V3‑Dokument erstellen und verlinken (dieser Commit)
+2) V2 als DEPRECATED markieren (dieser Commit)
+3) Optional: Navigation_Routing_Diagramm auf „kein Login/Ping im MVP“ ergänzen
+4) Review durch 🏗️ Lead Architect und 🧹 Curator; danach V3 als SSoT in Roadmaps/Logs referenzieren

docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md

@@ -0,0 +1,43 @@
+---
+type: Journal
+status: ACTIVE
+owner: 🧹 Curator
+last_update: 2026-04-02
+sources:
+  - Besprechung Meldestelle 2026-04-02
+  - docs/03_Domain/01_Glossary/Ubiquitous_Language.md
+---
+
+# Session‑Log — Meldestelle‑Besprechung (2. April 2026)
+
+## ✅ Beschlüsse
+
+- Ubiquitous Language wird als SSoT geführt; Aktualisierungen zu Abteilung, Kassen, TeilnehmerKonto, Zahlvorgang sind angenommen.
+- Event‑First‑Workflow (Veranstaltung → Turnier → Bewerbe → Abteilungen → Startliste) ist der verbindliche Bedienfluss fürs MVP.
+- Abteilung ist kleinste ausführbare Einheit; Typisierung eingeführt: `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH`.
+- Kassen‑Konzept bestätigt: Turnierkassa je Turnier, Konsolidierung in Veranstaltungs‑Kassa auf Event‑Ebene.
+- Zahlvorgang darf mehrere Rechnungen/Belege ausgleichen (auch turnierübergreifend innerhalb derselben Veranstaltung); Buchung auf TeilnehmerKonto (Event‑Ebene).
+- Navigation V2: Screen‑Baum festgelegt, Back‑Stack‑Regeln (SingleTop Tabs, Logout poppt MainShell, modale Overrides nicht im Stack) angenommen.
+- Tenant‑Konzept bestätigt: „Eine Veranstaltung = eine Datenbank (Tenant)“, gemäß ADR‑0021; Auswirkungen auf Schema, API, Frontend dokumentieren.
+
+## 🛠️ Domänen‑Korrekturen
+
+- Hierarchie fixiert: Veranstaltung → Turnier → Bewerb/Prüfung → Abteilung.
+- Abteilung: Definition geschärft; Schwellenwerte liefern WARNUNG (kein harter Fehler); TBA‑Override wird protokolliert.
+- Kassa‑Begriffe: Turnierkassa (tournament‑scoped), Veranstaltungs‑Kassa (event‑scoped, konsolidiert).
+
+## ⏸️ Zurückgestellte Themen
+
+- ⏸️ USB‑Fallback für Datensync (Offsite‑Export/Import) – Evaluierung Sprint B/C.
+-
+ ⏸️ Web‑App (PWA) – nach Desktop‑MVP, Anforderungen sammeln.
+- ⏸️ Nenn‑System‑Integration (ZNS Live‑Sync) – nach Abschluss Stammdaten‑Stabilisierung.
+
+## 🔗 Verweise
+
+- Ubiquitous Language: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`
+- Event‑First‑Workflow: `docs/02_Guides/Event-First-Workflow.md`
+- Navigation V2: `docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
+ - Navigation V2 (Archiv): `docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md`
+- Tenant‑Konzept (Laien‑Erklärung): `docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md`
+- ADR‑0021: `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`

docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md

@@ -0,0 +1,96 @@
+---
+type: Frontend
+status: ARCHIVED
+owner: 🎨 Frontend Expert & 🧹 Curator
+archived_at: 2026-04-02
+moved_from: docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md
+deprecated_by: docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
+sources:
+  - docs/99_Journal/2026-04-01_Session_Log_BackStack_Navigation.md
+  - docs/02_Guides/Event-First-Workflow.md
+---
+
+# Navigation V2 — Screen‑Baum & Back‑Stack‑Regeln (archiviert)
+
+ACHTUNG: Dieses Dokument beschreibt eine ältere Fassung mit Ping/SystemStatus und Login‑Flow. Die jetzt gültige, startfähige Fassung ist „V3“:
+
+- Aktuelle Version: `docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md`
+- Dieses V2‑Dokument bleibt als Referenz im Archiv bestehen.
+
+---
+
+## 1. Screen‑Baum (Routen)
+
+- AppRoot
+  - Landing
+    - SystemStatus (Ping, Verbindungen)
+    - Login(returnTo?)
+  - MainShell (nach Login)
+    - Dashboard
+    - Veranstaltungen
+      - Veranstaltung.Detail(eventId)
+        - Turnier.Detail(tournamentId)
+          - Bewerb.Detail(contestId)
+            - Abteilung.Detail(divisionId)
+              - Startliste(divisionId)
+          - Kassa.Turnier(tournamentId)
+        - Kassa.Veranstaltung(eventId)
+    - Suche (global)
+    - Einstellungen
+
+Hinweise:
+- Die Struktur folgt dem Event‑First‑Workflow (→ Guide). Abteilung ist die kleinste ausführbare Einheit.
+- Separate Kassa‑Screens für Turnier und Veranstaltung (→ Ubiquitous Language: Veranstaltungs‑Kassa, Turnierkassa).
+
+---
+
+## 2. Navigations‑Konventionen
+
+- Route IDs: Verwende stabile, serialisierbare IDs (`eventId`, `tournamentId`, `contestId`, `divisionId`). Kopfnummern sind keine stabilen IDs.
+- SingleTop für Haupt‑Tabs (Dashboard, Veranstaltungen, Suche, Einstellungen): erneuter Klick bringt zum Tab‑Root und ersetzt nicht den Stack.
+- Detail‑Drilldown ist hierarchisch (Parent → Child). Zurück führt jeweils eine Ebene hoch.
+- Deep Links: `app://event/{eventId}/tournament/{tId}/contest/{cId}/division/{dId}` öffnen direkt die Abteilung; Eltern werden als „synthetische“ Back‑Kette aufgebaut.
+
+---
+
+## 3. Back‑Stack‑Regeln
+
+1) Logout
+   - Poppt den gesamten MainShell‑Stack und landet auf Landing → Login.
+
+2) Wechsel Tab → Tab
+   - Jeder Tab hat eigenen Stack. Wechsel zwischen Tabs speichert den jeweiligen Stack (SingleTask je Tab).
+
+3) Navigieren innerhalb „Veranstaltungen“
+   - Veranstaltungen (Liste) → Veranstaltung.Detail → Turnier.Detail → Bewerb.Detail → Abteilung.Detail → Startliste.
+   - Back springt exakt eine Ebene zurück; beim Verlassen von Startliste zurück zur Abteilung.
+
+4) Öffnen Kassa
+   - Von Turnier.Detail zu Kassa.Turnier: Push auf Stack.
+   - Von Veranstaltung.Detail zu Kassa.Veranstaltung: Push auf Stack.
+   - Back kehrt zur jeweiligen Detailseite zurück.
+
+5) Override‑Dialoge (Regelwerk)
+   - Modal/Sheet, kein eigener Stack‑Eintrag. Schließen kehrt zum aktuellen Screen zurück. Override‑Events werden protokolliert.
+
+---
+
+## 4. Zustandsmanagement
+
+- Screens sind UDF/MVVM‑kompatibel (Details in eigener Doku; Verweis aus Sprint B).
+- Navigation‑State hält `returnTo` für Login‑Flüsse (z. B. Deep Link → Login → zurück zum Ziel).
+
+---
+
+## 5. Edge‑Cases & Tests
+
+- Abteilungswechsel: Beim Wechsel der Abteilung innerhalb eines Bewerbs bleibt der Stack auf Bewerb‑Ebene erhalten; nur das Abteilung‑Detail wird ersetzt.
+- Datenverlust vermeiden: Vor Navigation prüfen, ob ungespeicherte Änderungen vorliegen (z. B. Kassa‑Buchung), ggf. Confirm‑Dialog.
+
+---
+
+## 6. Querverweise
+
+- Back‑Stack Session Log: `docs/99_Journal/2026-04-01_Session_Log_BackStack_Navigation.md`
+- Event‑First‑Workflow: `docs/02_Guides/Event-First-Workflow.md`
+- Begriffe: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`