# 🧹 Session-Log: Sprint-Planungs-Besprechung > **Datum:** 2. April 2026 > **Erstellt von:** 🧹 Curator > **Aufgabe:** Curator Roadmap A-5 --- ## 📋 Teilnehmer | Agent | Rolle | Anwesend | |----------------------------|--------------------------------------|----------| | Owner / Projekt-Owner | Fach-Experte, Auftraggeber | ✅ | | 🏗️ Lead Architect | Strategie, ADRs, Domänen-Modell | ✅ | | 👷 Backend Developer | Spring Boot, Kotlin, SQL, API | ✅ | | 🎨 Frontend Expert | KMP, Compose Desktop, ViewModels | ✅ | | 🐧 DevOps Engineer | Docker, CI/CD, Packaging | ✅ | | 🧐 QA Specialist | Tests, Edge-Cases, Qualität | ✅ | | 📜 ÖTO/FEI Rulebook Expert | Regelwerk, Validierung, Compliance | ✅ | | 🖌️ UI/UX Designer | Wireframes, Design-System, Usability | ✅ | | 🧹 Curator | Dokumentation, Logs, Aufräumen | ✅ | --- ## 🎯 Ziele der Besprechung 1. Übersicht über den aktuellen Projektstand verschaffen 2. Strategie für die nächsten Entwicklungsschritte besprechen 3. Individuelle Arbeitsaufträge für jeden Entwickler ausarbeiten 4. Genaue Reihenfolge der nächsten Entwicklungsschritte festlegen --- ## 📊 Besprochene Themen & Beschlüsse ### 1. Domänen-Modell präzisiert **Beschluss:** Die Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` wurde offiziell festgelegt. ``` Veranstalter └── Veranstaltung (interne ID, Tenant-Grenze / eigene Datenbank) └── Turnier (OEPS-Turniernummer, z.B. 26128) └── Bewerb / Prüfung (z.B. Bewerb 3 "Stilspringen 90cm") └── Abteilung(en) ← KLEINSTE EINHEIT ├── eigene Startliste ├── eigene Ergebnisliste └── eigene Siegerehrung (je nach Typ) ``` **Wichtig:** Eine `Veranstaltung` kann mehrere `Turniere` enthalten (Beispiel Neumarkt 2026: zwei OEPS-Turniere mit je eigener Turniernummer unter einer gemeinsamen Veranstaltung). **Abteilungs-Typen:** - `SEPARATE_SIEGEREHRUNG` — Abteilung mit eigenständiger Siegerehrung (z.B. Lizenz-Trennung im CSN-C-NEU) - `ORGANISATORISCH` — Rein organisatorische Aufteilung, Ergebnisse werden zur Gesamtrangliste zusammengeführt --- ### 2. Veranstaltungs-Kassa Konzept **Beschluss:** Die Veranstaltungs-Kassa ermöglicht turnier-übergreifende Saldoansicht mit einem Zahlvorgang aber separaten Rechnungen je Turnier. ``` VERANSTALTUNGS-KASSA ├── TeilnehmerKonto (Reiter × Pferd, pro Veranstaltung) │ ├── Saldo aus Turnier #1 │ └── Saldo aus Turnier #2 │ Gesamt-Offener-Betrag └── Zahlvorgang (1× Kassagang) ├── Rechnung Turnier #1 → OEPS-Meldung Turnier-Nr. X └── Rechnung Turnier #2 → OEPS-Meldung Turnier-Nr. Y ``` **Begründung:** OEPS-Pflicht — jedes Turnier mit eigener Turniernummer muss separat gemeldet werden. --- ### 3. Neue Domänen-Begriffe (für `Ubiquitous_Language.md`) | Begriff | Definition | |--------------------------|-------------------------------------------------------------------------------------------------------------| | **Abteilung** | Kleinste ausführbare Einheit eines Bewerbs. Hat eigene Startliste, Ergebnisse und ggf. eigene Siegerehrung. | | **TeilnehmerKonto** | Aggregiertes Konto eines Teilnehmers auf Veranstaltungsebene über mehrere Turniere. | | **Veranstaltungs-Kassa** | Kassa-Ansicht auf Veranstaltungsebene mit Turnier-übergreifendem Saldo. | | **TurnierKassa** | Kassa für ein einzelnes Turnier (separate OEPS-Abrechnung). | | **Zahlvorgang** | Ein Kassagang — kann mehrere Rechnungen (je Turnier) umfassen. | | `SEPARATE_SIEGEREHRUNG` | Abteilungs-Typ mit eigenständiger Siegerehrung. | | `ORGANISATORISCH` | Abteilungs-Typ mit zusammengeführter Gesamtrangliste. | --- ### 4. Abteilungs-Zwangsteilung im CSN-C-NEU **Beschluss:** Das System muss beim Anlegen eines Bewerbs im CSN-C-NEU automatisch die korrekten Abteilungen vorschlagen bzw. erzwingen. | Kategorie | Höhe | Pflicht-Teilung | |---------------|-----------|------------------------------| | **CSN-C-NEU** | bis 95 cm | `ohne Lizenz` ↔ `mit Lizenz` | | **CSN-C-NEU** | ab 100 cm | `R1` ↔ `R2 und höher` | --- ### 5. Strategie: 3 Säulen des nächsten Sprints ``` SÄULE 1: FUNDAMENT SÄULE 2: VERBINDUNG SÄULE 3: QUALITÄT ───────────────────── ────────────────────── ───────────────────── ViewModel-Architektur → CRUD-APIs Backend → ÖTO-Validierung Tenant-Isolation → Frontend-Anbindung → Tests & QA Dokumentation (ADR) → Desktop-Packaging → UI/UX Konsistenz ``` **Reihenfolge:** Säule 1 → Säule 2 → Säule 3 (jede Säule blockt die nächste) --- ### 6. Sprint-Planung #### 🔴 Sprint A — Sofort (diese Woche) | # | Wer | Aufgabe | |-----|---------------|---------------------------------------------------------------------------------------------------| | A-1 | 🏗️ Architect | **ADR-0021**: Tenant-Resolution-Strategie (Schema-per-Tenant vs. Tenant-ID) → **BLOCKER für A-3** | | A-2 | 🎨 Frontend | ViewModel-Architektur (MVVM/UDF) definieren + `VeranstalterViewModel` als Referenz | | A-3 | 👷 Backend | Tenant-Isolation im Datenzugriffs-Layer (nach ADR-0021) | | A-4 | 🧹 Curator | `Ubiquitous_Language.md`, Event-First-Workflow, Navigation-V2, Tenant-Konzept dokumentieren | | A-5 | 📜 Rulebook | Validierungsregeln für OEPS-Nr., FEI-ID, Lizenzklassen + Abteilungs-Zwangsteilung spezifizieren | | A-6 | 🖌️ UI/UX | Design-Inventur: V2-Screens katalogisieren, Inkonsistenzen dokumentieren | #### 🟠 Sprint B — Nächste Woche | # | Wer | Aufgabe | |-----|-------------|-----------------------------------------------------------------------| | B-1 | 👷 Backend | CRUD-Endpunkte für alle Stammdaten-Entitäten | | B-2 | 🎨 Frontend | Alle V2-ViewModels + Ktor-Client-Repositories | | B-3 | 📜 + 🎨 | Validierungslogik als Live-Feedback in V2-Edit-Dialogen | | B-4 | 📜 + 👷 | Validierungslogik serverseitig absichern | | B-5 | 🖌️ UI/UX | Wireframes: Editier-Formulare, Bewerb+Abteilung, Veranstaltungs-Kassa | | B-6 | 🧐 QA | Test-Suite: Navigation/Back-Stack + Onboarding-Edge-Cases | | B-7 | 🐧 DevOps | CI/CD Pipeline für Compose-Desktop-Tests (headless) | #### 🟡 Sprint C — In 2 Wochen | # | Wer | Aufgabe | |-----|---------------|-------------------------------------------------------------------| | C-1 | 🐧 DevOps | Desktop-App Packaging (.msi / .deb / .dmg) | | C-2 | 🏗️ Architect | Sync-Protokoll-Konzept (Event-Sourcing vs. CRDT vs. Timestamp) | | C-3 | 👷 Backend | Testdaten-Seeder | | C-4 | 🧐 QA | Mandanten-Isolations-Testfälle | | C-5 | 🖌️ UI/UX | Wireframes implementieren + Empty States | | C-6 | 📜 Rulebook | AltersklasseRechner testen + Funktionärs-Qualifikationen als Enum | | C-7 | 🧹 Curator | README + Setup-Guide + Docs-Struktur + V1-Bereinigung | | C-8 | 🏗️ Architect | MASTER_ROADMAP aktualisieren | | C-9 | 🐧 DevOps | Semantic Versioning + Release-Strategie | --- ## ⏸️ Zurückgestellte Themen > Explizit vom Owner auf "später" verschoben — keine Priorität in Sprint A–C. | Thema | Begründung | |-------------------------------------------------------------|-----------------------------------------------------------------------| | ⏸️ **USB-Stick Fallback bei LAN-Ausfall** | Konzept bekannt, aber aktuell kein Sprint-Slot — separate Besprechung | | ⏸️ **Web-App Präsentation (Veranstaltungs-/Turnier-Seite)** | Separate Besprechung erforderlich | | ⏸️ **Nenn-System (Web-Formular)** | Separate Besprechung erforderlich | | ⏸️ **Live-Ergebnisse (Web-App)** | Separate Besprechung erforderlich | --- ## 📌 Erstellte Artefakte | Datei | Beschreibung | |------------------------------------------------------------|-------------------------------------------------| | `docs/04_Agents/Roadmaps/Architect_Roadmap.md` | Sprint-Roadmap für 🏗️ Lead Architect | | `docs/04_Agents/Roadmaps/Backend_Roadmap.md` | Sprint-Roadmap für 👷 Backend Developer | | `docs/04_Agents/Roadmaps/Frontend_Roadmap.md` | Sprint-Roadmap für 🎨 Frontend Expert | | `docs/04_Agents/Roadmaps/DevOps_Roadmap.md` | Sprint-Roadmap für 🐧 DevOps Engineer | | `docs/04_Agents/Roadmaps/QA_Roadmap.md` | Sprint-Roadmap für 🧐 QA Specialist | | `docs/04_Agents/Roadmaps/Rulebook_Roadmap.md` | Sprint-Roadmap für 📜 Rulebook Expert | | `docs/04_Agents/Roadmaps/UIUX_Roadmap.md` | Sprint-Roadmap für 🖌️ UI/UX Designer | | `docs/04_Agents/Roadmaps/Curator_Roadmap.md` | Sprint-Roadmap für 🧹 Curator | | `docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md` | Entwickler-übergreifende Ausführungsreihenfolge | | `docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md` | **Dieses Dokument** | --- ## ✅ Offizielle Beschlüsse 1. **ADR-0021 (Tenant-Resolution)** wird sofort vom Architect erstellt — kritischer Blocker. 2. **ViewModel-Architektur** wird vor neuen Features eingeführt — kein neuer Code ohne ViewModel. 3. **Kein neues Feature ohne ÖTO-Validierung** — Rulebook Expert gibt Spezifikation vor. 4. **Mock-Store (`StoreV2`) ist temporär** — Ablösung durch echtes Backend in Sprint B. 5. **MASTER_ROADMAP** wird am Ende von Sprint C durch den Architect aktualisiert. 6. **`Abteilung`** ist die kleinste ausführbare Einheit — alle Entwickler müssen dies sofort in ihre Arbeiten einfließen lassen. 7. **Fokus liegt auf der Desktop-App** (Sprint A+B). Web-App kommt danach (Sprint C+D). --- > 🏁 **Besprechung offiziell beendet um ca. 14:30 Uhr, 2. April 2026.** > Sprint A beginnt sofort.