diff --git a/docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md b/docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md new file mode 100644 index 00000000..6d05256f --- /dev/null +++ b/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. diff --git a/docs/02_Guides/Event-First-Workflow.md b/docs/02_Guides/Event-First-Workflow.md new file mode 100644 index 00000000..1c0dfc36 --- /dev/null +++ b/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` diff --git a/docs/03_Domain/01_Glossary/Ubiquitous_Language.md b/docs/03_Domain/01_Glossary/Ubiquitous_Language.md index 5de13794..12b8c954 100644 --- a/docs/03_Domain/01_Glossary/Ubiquitous_Language.md +++ b/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 | --- diff --git a/docs/04_Agents/Roadmaps/Curator_Roadmap.md b/docs/04_Agents/Roadmaps/Curator_Roadmap.md index a84aa68a..1d0e8053 100644 --- a/docs/04_Agents/Roadmaps/Curator_Roadmap.md +++ b/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` --- diff --git a/docs/06_Frontend/Navigation_Routing_Diagramm.md b/docs/06_Frontend/Navigation_Routing_Diagramm.md index 400a6e7e..aa8a71a2 100644 --- a/docs/06_Frontend/Navigation_Routing_Diagramm.md +++ b/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: diff --git a/docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md b/docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md new file mode 100644 index 00000000..d18c6cf0 --- /dev/null +++ b/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` diff --git a/docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md b/docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md new file mode 100644 index 00000000..76d6eb45 --- /dev/null +++ b/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` diff --git a/docs/06_Frontend/Reports/2026-04-02_Navigation_Versionierung_Analyse_V2_vs_V3.md b/docs/06_Frontend/Reports/2026-04-02_Navigation_Versionierung_Analyse_V2_vs_V3.md new file mode 100644 index 00000000..59359d8c --- /dev/null +++ b/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 diff --git a/docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md b/docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md new file mode 100644 index 00000000..d14dc3b6 --- /dev/null +++ b/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` diff --git a/docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md b/docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md new file mode 100644 index 00000000..937ba96c --- /dev/null +++ b/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`