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

2026-04-02 20:09:22 +02:00
parent 8b40a0624b
commit b787504474
10 changed files with 563 additions and 21 deletions
@@ -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`