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

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