🏗️ **[Lead Architect]** — Domänen-Korrektur & USB-Fallback-Präzisierung | 2. April 2026 --- ### ✅ Domänen-Korrektur wird übernommen: Die vollständige Hierarchie Danke für die wichtige Korrektur. Das Domänen-Modell wird entsprechend präzisiert: ``` Veranstaltung (interne ID, Tenant-Grenze) └── Turnier (OEPS-Turniernummer, z.B. 26128) └── Prüfung / Bewerb (z.B. Bewerb 3 "90cm Stilspringen") └── Abteilung(en) ← KLEINSTE EINHEIT ├── eigene Startliste ├── eigene Ergebnisliste └── eigene Siegerehrung ``` **Das bedeutet konkret:** Ein Bewerb (z.B. "Springprüfung 90cm") kann in **mehrere Abteilungen** aufgeteilt werden — entweder wegen zu vieler Starter (Teilungs-Abteilung) oder weil es regelkonform zwingend ist (z.B. im CSN-C-NEU: `ohne Lizenz` vs. `mit Lizenz`). Die `Abteilung` ist die Einheit, die: - eine **Startnummern-Vergabe** hat - eine **Startliste** hat (wird an den Richter-Turm übergeben) - ein **Ergebnis** hat (kommt vom Richter-Turm zurück) - eine **Siegerehrung** bekommt --- ### 🔧 USB-Fallback Konzept: Korrigiert auf Abteilungs-Ebene Das USB-Export/Import-Protokoll aus der letzten Besprechung wird auf die korrekte kleinste Einheit angepasst: #### Korrigiertes Dateiformat ```json { "meldestelle_export": { "version": "1.0", "veranstaltung_id": "NM-2026", "turnier_nr": "26128", "bewerb_nr": 3, "bewerb_bezeichnung": "Stilspringen 90cm", "abteilung_nr": 1, "abteilung_bezeichnung": "ohne Lizenz", "exportiert_am": "2026-04-25T10:15:00", "exportiert_von": "MELDESTELLE", "typ": "STARTLISTE", "checksum": "sha256:...", "daten": { ... } } } ``` #### Korrigierter Export-/Import-Flow ``` MELDESTELLE (Desktop) RICHTER-TURM (Desktop) ────────────────────── ────────────────────── Bewerb 3 hat 2 Abteilungen: [Export Startliste Abt. 1] ──USB──► [Import → Richter startet Abt. 1] [Export Startliste Abt. 2] ──USB──► [Import → Richter startet Abt. 2] ◄──USB── [Export Ergebnis Abt. 1] ◄──USB── [Export Ergebnis Abt. 2] [Import Ergebnis Abt. 1] [Import Ergebnis Abt. 2] └── Gesamtrangliste Bewerb 3 (aus beiden Abteilungen, je nach Prüfungstyp) ``` #### Wichtige Regel für zusammengeführte Ergebnisse Nach dem Import beider Abteilungsergebnisse entscheidet der **Prüfungstyp**, ob: - **Separate Siegerehrung** pro Abteilung (z.B. CSN-C-NEU: `ohne Lizenz` und `mit Lizenz` werden getrennt geehrt), * *oder** - **Gesamtrangliste** aus allen Abteilungen (bei rein organisatorischer Teilung wegen Starter-Anzahl) Diese Unterscheidung muss beim Anlegen der Abteilung gesetzt werden ( `abteilung_typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`). --- ### 📄 TURNIER_KLASSEN.md Update — Konsequenzen für das System Das aktualisierte Dokument bestätigt und formalisiert die **zwingende Abteilungs-Teilung** im C-NEU-Bereich: | Kategorie | Höhe | Pflicht-Teilung | |---------------|-----------|--------------------------------------------------| | **CSN-C-NEU** | bis 95 cm | Abteilung `ohne Lizenz` ↔ Abteilung `mit Lizenz` | | **CSN-C-NEU** | ab 100 cm | Abteilung `R1` ↔ Abteilung `R2 und höher` | Das ist kein optionales Feature — das System **muss** beim Anlegen eines Bewerbs im CSN-C-NEU automatisch die korrekten Abteilungen vorschlagen bzw. erzwingen. **Arbeitsauftrag daraus (ergänzt zu Sprint A-5):** | # | Wer | Aufgabe | |------|-------------|----------------------------------------------------------------------------------------------------------------------------| | A-5a | 📜 Rulebook | Vollständige Liste aller zwingenden Abteilungs-Teilungsregeln aus ÖTO 2026 spezifizieren (C-NEU bereits bekannt, weitere?) | | A-5b | 👷 Backend | `Abteilung`-Entität ins Schema aufnehmen (FK: `bewerb_id`, Felder: `nr`, `bezeichnung`, `typ`, `siegerehrung_separat`) | | A-5c | 🎨 Frontend | Beim Anlegen eines Bewerbs: Abteilungs-Logik als Teil des Bewerb-Dialogs (Vorschlag + Pflicht-Validierung) | --- ### 📌 Aktualisierte Domänen-Begriffe für `Ubiquitous_Language.md` Folgende Begriffe müssen ergänzt werden (Auftrag an 🧹 Curator): | Begriff | Definition | |-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------| | **Abteilung** | Kleinste ausführbare Einheit eines Bewerbs/einer Prüfung. Hat eine eigene Startliste, eigene Ergebnisse und ggf. eine eigene Siegerehrung. | | `SEPARATE_SIEGEREHRUNG` | Abteilungs-Typ: Die Abteilung hat eine eigenständige Siegerehrung (z.B. bei Lizenz-Trennung im C-NEU). | | `ORGANISATORISCH` | Abteilungs-Typ: Rein organisatorische Aufteilung wegen Starter-Anzahl. Ergebnisse werden in einer Gesamtrangliste zusammengeführt. | --- ### 🎯 Scope-Bestätigung | Thema | Status | |-----------------------------------------|-------------------------------------------| | USB-Fallback (korrigiert auf Abteilung) | ✅ Konzept präzisiert — weiter in Sprint B | | Web-App Präsentation-Hierarchie | ⏸️ Separate Besprechung später | | Nenn-System Web-Formular | ⏸️ Separate Besprechung später | | Live-Ergebnisse Web-App | ⏸️ Separate Besprechung später | | **Fokus jetzt** | 🖥️ Desktop-App (Sprint A + B) | > ⚠️ **Wichtiger Hinweis für alle Entwickler:** Die `Abteilung` als eigenständige Domänen-Entität muss **sofort** in > alle laufenden Arbeiten einfließen — besonders in das Backend-Schema (A-3) und das ViewModel-Design (A-2). Wer > Startlisten oder Ergebnisse ohne Abteilungs-Bezug modelliert, baut falsch.