---
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`