meldestelle/docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md

🧹 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.