From 7e16b3f318e8447ec6db8d344c05e7eae5383831 Mon Sep 17 00:00:00 2001 From: Stefan Mogeritsch Date: Thu, 2 Apr 2026 14:35:40 +0200 Subject: [PATCH] docs(roadmaps): add sprint execution order and detailed role-specific roadmaps MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added `SPRINT_EXECUTION_ORDER.md` to define the cross-role sprint step sequence. - Created individual roadmaps for Architect, Backend, Frontend, DevOps, Rulebook, QA, UI/UX, and Curator. - Captured developer responsibilities, dependencies, and timelines for Sprints A–C. - Aligned sprint planning documentation with session log agreements. - Provided structured documentation in `docs/04_Agents/Roadmaps/`. Signed-off-by: Stefan Mogeritsch --- docs/04_Agents/Roadmaps/Architect_Roadmap.md | 57 +++++ docs/04_Agents/Roadmaps/Backend_Roadmap.md | 96 ++++++++ docs/04_Agents/Roadmaps/Curator_Roadmap.md | 96 ++++++++ docs/04_Agents/Roadmaps/DevOps_Roadmap.md | 74 ++++++ docs/04_Agents/Roadmaps/Frontend_Roadmap.md | 87 +++++++ docs/04_Agents/Roadmaps/QA_Roadmap.md | 88 +++++++ docs/04_Agents/Roadmaps/Rulebook_Roadmap.md | 88 +++++++ .../Roadmaps/SPRINT_EXECUTION_ORDER.md | 214 ++++++++++++++++++ docs/04_Agents/Roadmaps/UIUX_Roadmap.md | 84 +++++++ .../2026-04-02_Besprechung_Sprint-Planung.md | 206 +++++++++++++++++ .../1._USB-Stick_Fallback_bei_LAN-Ausfall.md | 135 +++++++++++ .../Besprechung_2026-04-02.md | 26 +++ ...Meldestelle_Besprechung!_Wir_berufen_di.md | 167 ++++++++++++++ ...kay,_alle_Entwickler_haben_Ihre_Aufgabe.md | 42 ++++ ...kay,_ich_bin_der_Besitzer_dieses_Projek.md | 128 +++++++++++ 15 files changed, 1588 insertions(+) create mode 100644 docs/04_Agents/Roadmaps/Architect_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/Backend_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/Curator_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/DevOps_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/Frontend_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/QA_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/Rulebook_Roadmap.md create mode 100644 docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md create mode 100644 docs/04_Agents/Roadmaps/UIUX_Roadmap.md create mode 100644 docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md create mode 100644 docs/temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md create mode 100644 docs/temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md create mode 100644 docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md create mode 100644 docs/temp/2026-04-02_Besprechung/Okay,_alle_Entwickler_haben_Ihre_Aufgabe.md create mode 100644 docs/temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md diff --git a/docs/04_Agents/Roadmaps/Architect_Roadmap.md b/docs/04_Agents/Roadmaps/Architect_Roadmap.md new file mode 100644 index 00000000..11f19101 --- /dev/null +++ b/docs/04_Agents/Roadmaps/Architect_Roadmap.md @@ -0,0 +1,57 @@ +# 🏗️ [Lead Architect] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Strategie, Architektur-Entscheidungen (ADRs), Domänen-Modell, Master-Roadmap + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | ADR-0021 schreiben: Tenant-Resolution-Strategie + - [ ] Optionen analysieren: Schema-per-Tenant vs. Tenant-ID in allen Tabellen + - [ ] Entscheidung treffen und begründen + - [ ] ADR-0021 in `docs/01_Architecture/ADRs/` ablegen + - [ ] Backend Developer informieren (A-3 ist Blocker) + +- [ ] **A-2** | Domänen-Modell formal präzisieren + - [ ] Hierarchie `Veranstaltung → Turnier → Bewerb → Abteilung` als offizielles Modell festschreiben + - [ ] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier) ins Modell aufnehmen + - [ ] Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo modellieren + - [ ] Abteilungs-Typen `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` ins Modell aufnehmen + - [ ] Curator beauftragen: `Ubiquitous_Language.md` aktualisieren + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | ADR für LAN-Sync-Protokoll schreiben + - [ ] Optionen analysieren: Event-Sourcing vs. CRDT vs. Timestamp-Sync + - [ ] Entscheidung für Meldestelle ↔ Richter-Turm Sync treffen + - [ ] ADR in `docs/01_Architecture/ADRs/` ablegen + +> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Synchronisations-Protokoll-Konzeption starten + - [ ] Offline-First-Konzept für Desktop ↔ Backend ausarbeiten + - [ ] Conflict-Resolution-Strategie definieren (was passiert bei gleichzeitigen Änderungen?) + - [ ] Ergebnis als Konzept-Dokument in `docs/01_Architecture/` ablegen + +- [ ] **C-2** | MASTER_ROADMAP aktualisieren + - [ ] Desktop-App-Fokus eintragen + - [ ] Tenant-Isolation-Meilensteine eintragen + - [ ] Offline-Sync-Meilensteine eintragen + - [ ] Sprint A/B/C Ergebnisse als "erledigt" markieren + +--- + +## 📌 Abhängigkeiten + +| Meine Aufgabe | Blockiert wen | +|----------------------|----------------------------------------------------------| +| ADR-0021 (A-1) | 👷 Backend: Tenant-Isolation (Backend Sprint A) | +| Domänen-Modell (A-2) | 👷 Backend: Schema-Design; 🎨 Frontend: ViewModel-Design | +| LAN-Sync ADR (B-1) | 🎨 Frontend: Sync-UI; 👷 Backend: Sync-Endpunkte | diff --git a/docs/04_Agents/Roadmaps/Backend_Roadmap.md b/docs/04_Agents/Roadmaps/Backend_Roadmap.md new file mode 100644 index 00000000..76517e1e --- /dev/null +++ b/docs/04_Agents/Roadmaps/Backend_Roadmap.md @@ -0,0 +1,96 @@ +# 👷 [Backend Developer] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Spring Boot / Ktor, Kotlin, SQL, API-Design, Datenbankschema, Services + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +> ⚠️ **Warten auf ADR-0021 vom Architect** bevor A-1 beginnt! + +- [ ] **A-1** | Tenant-Isolation im Datenzugriffs-Layer implementieren + - [ ] ADR-0021 (Architect) lesen und Strategie übernehmen + - [ ] Tenant-Resolution-Mechanismus implementieren (wie erkennt das Backend die Ziel-Datenbank?) + - [ ] Alle Datenzugriffe mit Tenant-Kontext absichern + - [ ] Sicherstellen: Kein Cross-Tenant-Datenzugriff möglich + +- [ ] **A-2** | Datenbankschema: Domänen-Hierarchie umsetzen + - [ ] Tabelle `veranstaltungen` anlegen (interne ID, Tenant-Grenze) + - [ ] Tabelle `turniere` anlegen (FK → `veranstaltung_id`, OEPS-Turniernummer als eigenes Feld) + - [ ] Tabelle `bewerbe` anlegen (FK → `turnier_id`, Klasse, Höhe, Bezeichnung) + - [ ] Tabelle `abteilungen` anlegen (FK → `bewerb_id`, `nr`, `bezeichnung`, + `typ: SEPARATE_SIEGEREHRUNG | ORGANISATORISCH`) + - [ ] Tabelle `teilnehmer_konten` anlegen (FK → `veranstaltung_id`, aggregiert Salden über Turniere) + - [ ] Tabelle `turnier_kassa` anlegen (FK → `turnier_id`, separate Kassa pro Turnier) + - [ ] Migrations-Skript schreiben und testen + +- [ ] **A-3** | Validierungs-Grundlage: Turnierkategorie-Limits + - [ ] `Turnier.validate()`: Bewerbs-Klassen gegen Limits der Turnierkategorie prüfen (z.B. kein S-Springen auf + C-Turnier) + - [ ] Voraussetzung: Spezifikation von 📜 Rulebook Expert (A-5) abwarten + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | CRUD-Endpunkte für alle Stammdaten-Entitäten + - [ ] `POST/GET/PUT/DELETE /veranstaltungen` + - [ ] `POST/GET/PUT/DELETE /turniere` (inkl. Status-Feld: `DRAFT | PUBLISHED`) + - [ ] `POST/GET/PUT/DELETE /bewerbe` + - [ ] `POST/GET/PUT/DELETE /abteilungen` + - [ ] `POST/GET/PUT/DELETE /reiter` + - [ ] `POST/GET/PUT/DELETE /pferde` + - [ ] `POST/GET/PUT/DELETE /vereine` + - [ ] `POST/GET/PUT/DELETE /funktionaere` + +- [ ] **B-2** | Kassa-Service implementieren + - [ ] `TeilnehmerKonto`-Service: Saldo aus mehreren Turnieren aggregieren + - [ ] `Zahlvorgang`-Service: Eine Zahlung auf Veranstaltungs-Ebene buchen + - [ ] Rechnungs-Generierung: Separate Rechnung je Turnier aus einem Zahlvorgang + - [ ] Endpunkte: `GET /veranstaltungen/{id}/kassa/saldo`, `POST /veranstaltungen/{id}/zahlvorgaenge` + +- [ ] **B-3** | ÖTO-Validierung serverseitig absichern + - [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) umsetzen + - [ ] OEPS-Nummern-Format validieren + - [ ] FEI-ID-Format validieren + - [ ] Lizenzklassen-Validierung (R1–R4, LZF) + - [ ] Altersklassen-Kompatibilität Pferd × Bewerb validieren + - [ ] Abteilungs-Zwangsteilung im CSN-C-NEU durchsetzen (Bewerb ≤95cm: ohne/mit Lizenz; ≥100cm: R1/R2+) + +- [ ] **B-4** | Nennungs-Service (Grundstruktur) + - [ ] Tabelle `nennungen` anlegen (FK → `abteilung_id`, Status: `NEU | GEPRÜFT | BESTÄTIGT | ABGELEHNT`) + - [ ] `POST /turniere/{id}/nennungen` — Nennungs-Eingang vom Web-Formular + - [ ] `GET /turniere/{id}/nennungen` — Postfach für Desktop-App (Meldestelle) + - [ ] `PATCH /nennungen/{id}/status` — Bestätigen / Ablehnen + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Testdaten-Seeder implementieren + - [ ] Reproduzierbare Veranstaltung mit 2 Turnieren (Neumarkt-Szenario) + - [ ] Bewerbe mit korrekten Abteilungen (inkl. CSN-C-NEU Pflicht-Teilung) + - [ ] Reiter, Pferde, Vereine als Stammdaten + - [ ] Nennungen in verschiedenen Status-Stufen + - [ ] Seeder via Gradle-Task ausführbar + +- [ ] **C-2** | Statistik-Endpunkte + - [ ] `GET /turniere/{id}/statistiken` — Statistiken pro Turnier + - [ ] `GET /veranstaltungen/{id}/statistiken` — Aggregierte Statistiken über alle Turniere + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|------------------------------------------------|--------------------| +| ADR-0021 (Tenant-Strategie) | 🏗️ Architect | +| Validierungs-Spezifikation (OEPS, FEI, Lizenz) | 📜 Rulebook Expert | +| Domänen-Modell final | 🏗️ Architect | + +| Meine Aufgabe | Ermöglicht wem | +|------------------------|--------------------------------| +| CRUD-Endpunkte (B-1) | 🎨 Frontend: Backend-Anbindung | +| Kassa-Service (B-2) | 🎨 Frontend: Kassa-Screen | +| Nennungs-Service (B-4) | 🎨 Frontend: Nennungs-Postfach | diff --git a/docs/04_Agents/Roadmaps/Curator_Roadmap.md b/docs/04_Agents/Roadmaps/Curator_Roadmap.md new file mode 100644 index 00000000..a84aa68a --- /dev/null +++ b/docs/04_Agents/Roadmaps/Curator_Roadmap.md @@ -0,0 +1,96 @@ +# 🧹 [Curator] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Dokumentation, Session-Logs, Reports, Aufräumen, Wissens-Management + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **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 + - [ ] `TeilnehmerKonto` auf Veranstaltungsebene (Multi-Turnier-Aggregation) eintragen + - [ ] `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 + +- [ ] **A-3** | Navigation-V2 dokumentieren + - [ ] Aktuellen Screen-Baum und Back-Stack-Verhalten beschreiben + - [ ] Dokument in `docs/06_Frontend/` ablegen + +- [ ] **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 + +- [ ] **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 + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | Roadmaps-Verzeichnis pflegen + - [ ] Alle 8 Roadmap-Dateien in `docs/04_Agents/Roadmaps/` auf Vollständigkeit prüfen + - [ ] Abgeschlossene Aufgaben in den Roadmaps als `[x]` markieren (nach Rückmeldung der Teams) + +- [ ] **B-2** | `docs/05_Backend/` aktualisieren + - [ ] Neues Datenbankschema (Tabellen: veranstaltungen, turniere, bewerbe, abteilungen) dokumentieren + - [ ] API-Endpunkte-Übersicht aktualisieren sobald Backend Sprint B abgeschlossen + +- [ ] **B-3** | `docs/06_Frontend/` aktualisieren + - [ ] ViewModel-Architektur-Muster (MVVM/UDF) dokumentieren (nach Frontend Sprint A) + - [ ] Verweis auf `VeranstalterViewModel` als Referenz-Implementierung + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | `README.md` aktualisieren + - [ ] Desktop-App als primären Fokus hervorheben + - [ ] Schnellstart-Anleitung für lokale Entwicklungsumgebung prüfen und aktualisieren + - [ ] Veraltete Abschnitte (V1-Referenzen) entfernen oder als deprecated markieren + +- [ ] **C-2** | Setup-Guide aktualisieren + - [ ] Schritt-für-Schritt-Anleitung: Projekt klonen → Docker starten → Desktop-App starten + - [ ] Voraussetzungen (JDK, Gradle, Docker) mit genauen Versionen dokumentieren + - [ ] Dokument in `docs/02_Guides/` ablegen + +- [ ] **C-3** | Unterordner-Struktur in `docs/` einführen (falls erforderlich) + - [ ] Aktuelle Struktur analysieren: Gibt es überladene Verzeichnisse? + - [ ] Vorschlag für saubere Unterordner-Struktur erstellen + - [ ] Mit Architect abstimmen und umsetzen + +- [ ] **C-4** | V1-Code-Bereinigung koordinieren + - [ ] Alle V1-Dateien und -Module identifizieren (gemeinsam mit Frontend + Backend) + - [ ] Bereinigungsplan erstellen: Was kann gelöscht werden, was muss migriert werden? + - [ ] Bereinigung koordinieren und dokumentieren + +- [ ] **C-5** | Reports-Verzeichnis pflegen + - [ ] Nach Sprint A, B, C: Kurzberichte von allen Entwicklern einsammeln + - [ ] In `docs/90_Reports/` archivieren + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|-----------------------------|-------------------------| +| ADR-0021 (Tenant-Strategie) | 🏗️ Architect — für A-4 | +| Domänen-Modell final | 🏗️ Architect — für A-1 | +| ViewModel-Referenz | 🎨 Frontend — für B-3 | +| Neues DB-Schema | 👷 Backend — für B-2 | + +| Meine Aufgabe | Ermöglicht wem | +|--------------------------------|---------------------------------------------------| +| `Ubiquitous_Language.md` (A-1) | Alle: gemeinsames Vokabular, kein Missverständnis | +| Session-Log (A-5) | Alle: Nachvollziehbarkeit der Beschlüsse | +| README + Setup-Guide (C-1/C-2) | Neue Entwickler: sofortiger Einstieg ins Projekt | diff --git a/docs/04_Agents/Roadmaps/DevOps_Roadmap.md b/docs/04_Agents/Roadmaps/DevOps_Roadmap.md new file mode 100644 index 00000000..a3f47d11 --- /dev/null +++ b/docs/04_Agents/Roadmaps/DevOps_Roadmap.md @@ -0,0 +1,74 @@ +# 🐧 [DevOps Engineer] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Docker, CI/CD, Gradle, Security, Desktop-Packaging, Infrastruktur + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | Docker-Compose-Setup auf aktuellen Stand bringen + - [ ] Alle Services (Backend, DB, Infra) in `docker-compose.yaml` / `dc-*.yaml` prüfen + - [ ] Sicherstellen: Lokale Entwicklungsumgebung startet mit einem einzigen Befehl + - [ ] Healthchecks für alle Services definieren + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | CI/CD Pipeline für Compose Desktop Tests (headless) + - [ ] GitHub Actions / Gitea Actions Workflow anlegen + - [ ] Headless-Umgebung für Compose Desktop Tests konfigurieren (Xvfb oder virtueller Framebuffer) + - [ ] Gradle-Task für Desktop-Tests in Pipeline integrieren + - [ ] Build-Artefakte (JAR / native Binaries) als Pipeline-Ausgabe speichern + - [ ] Fehlgeschlagene Tests als Build-Blocker konfigurieren + +- [ ] **B-2** | Gradle-Build-Optimierungen + - [ ] Build-Cache aktivieren und prüfen + - [ ] Parallele Modul-Builds konfigurieren + - [ ] Gradle-Wrapper-Version auf aktuellen Stand bringen + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Desktop-App Packaging konfigurieren + - [ ] `compose.desktop.nativeDistributions` in `build.gradle.kts` konfigurieren + - [ ] Windows: `.msi`-Installer bauen + - [ ] Linux: `.deb`-Paket bauen + - [ ] macOS: `.dmg`-Image bauen (falls erforderlich) + - [ ] App-Icon und Metadaten (Name, Version, Publisher) eintragen + - [ ] Testinstallation auf Ziel-Betriebssystem durchführen + +- [ ] **C-2** | Semantic Versioning einführen + - [ ] Versionierungsschema definieren: `MAJOR.MINOR.PATCH` + - [ ] Gemeinsame Versions-Quelle für Client (Frontend) und Server (Backend) festlegen + - [ ] Git-Tagging-Strategie definieren (`v1.0.0`, `v1.0.0-backend`, etc.) + - [ ] Release-Tagging in CI/CD-Pipeline integrieren + - [ ] `CHANGELOG.md` Vorlage anlegen + +- [ ] **C-3** | Produktions-Deployment vorbereiten + - [ ] Reverse-Proxy-Konfiguration (Nginx / Traefik) für Backend prüfen + - [ ] HTTPS-Zertifikat-Management dokumentieren + - [ ] Backup-Strategie für Produktionsdatenbanken definieren + +--- + +## ⏸️ Zurückgestellt + +> ⏸️ **USB-Stick Fallback** — Separate Besprechung zu einem späteren Zeitpunkt +> ⏸️ **Web-App Deployment** — Wird erst nach Desktop-App (Sprint A+B) gestartet + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|-------------------------|------------------| +| Headless-Test-Strategie | 🧐 QA Specialist | + +| Meine Aufgabe | Ermöglicht wem | +|---------------------------|----------------------------------------| +| CI/CD Pipeline (B-1) | 🧐 QA: Automatisierte Test-Ausführung | +| Desktop-Packaging (C-1) | Alle: Auslieferbare Desktop-App | +| Semantic Versioning (C-2) | Alle: Koordiniertes Release-Management | diff --git a/docs/04_Agents/Roadmaps/Frontend_Roadmap.md b/docs/04_Agents/Roadmaps/Frontend_Roadmap.md new file mode 100644 index 00000000..32ba6ad5 --- /dev/null +++ b/docs/04_Agents/Roadmaps/Frontend_Roadmap.md @@ -0,0 +1,87 @@ +# 🎨 [Frontend Expert] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** KMP, Compose Desktop, State-Management, MVVM/UDF, Backend-Anbindung + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | ViewModel-Architektur definieren und Referenz-Implementierung umsetzen + - [ ] MVVM mit UDF (Unidirectional Data Flow) als verbindliches Muster festlegen + - [ ] `Intent`- und `State`-Klassen-Struktur definieren (Vorlage für alle anderen ViewModels) + - [ ] `VeranstalterViewModel` als vollständige Referenz-Implementierung umsetzen + - [ ] `State`-Klasse definieren + - [ ] `Intent`-Klasse (Sealed Class) definieren + - [ ] Business-Logik aus Composables herausziehen (keine `StoreV2`-Aufrufe mehr direkt in `onSaved`) + - [ ] Lokalen `remember`-State durch ViewModel-State ersetzen + - [ ] Ergebnis als Muster-Dokument in `docs/06_Frontend/` ablegen + +- [ ] **A-2** | Abteilungs-Logik im Bewerb-Dialog berücksichtigen + - [ ] Beim Anlegen eines Bewerbs: Abteilungs-Auswahl als Teil des Dialogs + - [ ] CSN-C-NEU: Automatischer Vorschlag der Pflicht-Teilung (ohne/mit Lizenz; R1/R2+) + - [ ] Abteilungs-Typ setzen: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH` + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | ViewModels für alle V2-Screens umsetzen + - [ ] `TurnierViewModel` + - [ ] `BewerbViewModel` (inkl. Abteilungs-Logik) + - [ ] `PferdProfilViewModel` + - [ ] `ReiterProfilViewModel` + - [ ] `VereinsViewModel` + - [ ] `FunktionaerViewModel` + - [ ] `AbteilungViewModel` (Startliste, Ergebnisse) + +- [ ] **B-2** | Ktor-Clients und Repositories für Backend-Anbindung vorbereiten + - [ ] Ktor-HTTP-Client konfigurieren (BaseURL, Auth-Header, Timeout) + - [ ] Repository-Interface je Entität definieren (ermöglicht späteres Austauschen von Mock → Real) + - [ ] `VeranstalterRepository` mit echtem Backend-Client implementieren + - [ ] `TurnierRepository` implementieren + - [ ] `BewerbRepository` implementieren + - [ ] `AbteilungRepository` implementieren + - [ ] `StoreV2` schrittweise durch echte Repositories ersetzen + +- [ ] **B-3** | Validierungs-Live-Feedback in Edit-Dialogen + - [ ] Spezifikation von 📜 Rulebook Expert (Sprint A-5) als Basis nutzen + - [ ] OEPS-Nummer: Inline-Validierung beim Tippen + - [ ] FEI-ID: Inline-Validierung beim Tippen + - [ ] Lizenzklasse × Bewerbs-Klasse: Warnung wenn nicht erlaubt + - [ ] Altersklasse Pferd: Warnung wenn nicht kompatibel + +- [ ] **B-4** | Kassa-Screen: Veranstaltungs-Kassa implementieren + - [ ] Gesamt-Saldo-Ansicht (Salden aus allen Turnieren der Veranstaltung) + - [ ] Turnier-übergreifender Zahlvorgang (eine Zahlung, mehrere Rechnungen) + - [ ] Rechnungsvorschau je Turnier + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Mock-Store (`StoreV2`) vollständig ablösen + - [ ] Alle verbleibenden `StoreV2`-Referenzen durch echte Repositories ersetzen + - [ ] `StoreV2` nach vollständiger Ablösung entfernen oder als `@Deprecated` markieren + +- [ ] **C-2** | LAN-Sync-UI vorbereiten (nach ADR von Architect) + - [ ] Verbindungsstatus-Anzeige (Online/Offline/LAN) + - [ ] Sync-Trigger manuell und automatisch + +> ⏸️ **USB-Stick Fallback (Export/Import UI)** — Separate Besprechung zu einem späteren Zeitpunkt + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|----------------------------------|--------------------| +| Domänen-Modell final (Abteilung) | 🏗️ Architect | +| CRUD-Endpunkte | 👷 Backend | +| Validierungs-Spezifikation | 📜 Rulebook Expert | +| Wireframes Edit-Formulare | 🖌️ UI/UX Designer | + +| Meine Aufgabe | Ermöglicht wem | +|--------------------------|-----------------------------------------------| +| ViewModel-Referenz (A-1) | Alle anderen ViewModels folgen diesem Muster | +| Ktor-Repositories (B-2) | Ablösung von StoreV2, echte Daten im Frontend | diff --git a/docs/04_Agents/Roadmaps/QA_Roadmap.md b/docs/04_Agents/Roadmaps/QA_Roadmap.md new file mode 100644 index 00000000..a632f19f --- /dev/null +++ b/docs/04_Agents/Roadmaps/QA_Roadmap.md @@ -0,0 +1,88 @@ +# 🧐 [QA Specialist] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Test-Strategie, Edge-Cases, Regressions-Tests, Qualitätssicherung + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | Test-Strategie für Desktop-App definieren + - [ ] Testpyramide für Compose Desktop festlegen (Unit / Integration / UI-Tests) + - [ ] Tooling entscheiden: `kotlin.test`, Compose UI Test, Mockk + - [ ] Test-Konventionen dokumentieren (Namensschema, Ordnerstruktur, Arrange-Act-Assert) + - [ ] Dokument in `docs/06_Frontend/` oder `docs/07_Infrastructure/` ablegen + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | Test-Suite: V2-Navigation und Back-Stack + - [ ] Navigations-Flows für alle V2-Screens abdecken (vorwärts + zurück) + - [ ] Back-Stack-Verhalten testen (korrekter Zustand nach Zurück-Navigation) + - [ ] Deep-Link / direkter Screen-Aufruf testen (falls implementiert) + +- [ ] **B-2** | Test-Suite: Onboarding-Wizard Edge-Cases + - [ ] Leere Pflichtfelder → Button bleibt deaktiviert + - [ ] Schnelles wiederholtes Klicken auf „Weiter" / „Speichern" → kein doppelter Submit + - [ ] Abbrechen mitten im Wizard → kein inkonsistenter Zustand + - [ ] Ungültige Eingaben (z.B. falsches OEPS-Nummern-Format) → Fehlermeldung sichtbar + +- [ ] **B-3** | Test-Suite: Abteilungs-Logik + - [ ] CSN-C-NEU Bewerb ≤95cm: Pflicht-Teilung `ohne Lizenz` / `mit Lizenz` wird erzwungen + - [ ] CSN-C-NEU Bewerb ≥100cm: Pflicht-Teilung `R1` / `R2+` wird erzwungen + - [ ] Organisatorische Abteilung: Gesamtrangliste wird korrekt zusammengeführt + - [ ] Separate Siegerehrung: Abteilungen werden nicht zusammengeführt + +- [ ] **B-4** | Test-Suite: ViewModel-Verhalten (nach Frontend Sprint A) + - [ ] State-Initialisierung korrekt + - [ ] Intent → State-Transition für alle definierten Intents + - [ ] Fehler-State bei Backend-Fehler korrekt gesetzt + - [ ] Loading-State während asynchroner Operationen + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Test-Suite: Mandanten-Isolation + - [ ] Veranstaltung A kann keine Daten von Veranstaltung B lesen + - [ ] Veranstaltung A kann keine Daten in Veranstaltung B schreiben + - [ ] Turnier-übergreifender Kassa-Zugriff nur innerhalb derselben Veranstaltung möglich + +- [ ] **C-2** | Test-Suite: Kassa und Zahlvorgang + - [ ] Teilnehmer an 2 Turnieren → 1 Zahlvorgang → 2 korrekte separate Rechnungen + - [ ] Saldo-Berechnung korrekt (Summe aus beiden Turnier-Kassas) + - [ ] Bereits bezahlte Beträge werden nicht doppelt verrechnet + +- [ ] **C-3** | Test-Suite: ÖTO-Validierung (nach Rulebook Sprint A-5) + - [ ] OEPS-Nummer: Gültige und ungültige Formate testen + - [ ] FEI-ID: Gültige und ungültige Formate testen + - [ ] Lizenzklasse × Bewerbs-Klasse: Alle erlaubten und verbotenen Kombinationen + - [ ] Altersklasse Pferd × Bewerb: Grenzfälle (genau im Grenzjahr) + +- [ ] **C-4** | Regressions-Test-Suite aufbauen + - [ ] Kritische User-Flows als automatisierte Tests abdecken + - [ ] Tests in CI/CD-Pipeline integrieren (gemeinsam mit 🐧 DevOps) + +--- + +## ⏸️ Zurückgestellt + +> ⏸️ **USB-Stick Fallback Tests** — Separate Besprechung zu einem späteren Zeitpunkt +> ⏸️ **Nennungs-Workflow End-to-End Test (Web → Backend → Desktop)** — Nach Web-App Besprechung + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|------------------------------------|--------------------| +| ViewModel-Referenz-Implementierung | 🎨 Frontend | +| Validierungs-Spezifikation | 📜 Rulebook Expert | +| CI/CD Pipeline (headless) | 🐧 DevOps | +| Testdaten-Seeder | 👷 Backend | + +| Meine Aufgabe | Ermöglicht wem | +|----------------------|-------------------------------------------------| +| Test-Strategie (A-1) | 🐧 DevOps: korrekte Pipeline-Konfiguration | +| Alle Test-Suites | Alle: Vertrauen in Codequalität und Korrektheit | diff --git a/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md b/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md new file mode 100644 index 00000000..599cfe40 --- /dev/null +++ b/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md @@ -0,0 +1,88 @@ +# 📜 [ÖTO/FEI Rulebook Expert] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, ÖTO/FEI Compliance + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | Validierungsregeln schriftlich spezifizieren — Grundlage für alle anderen Teams + - [ ] **OEPS-Mitgliedsnummer** + - [ ] Gültiges Format definieren (Länge, erlaubte Zeichen, Präfixe) + - [ ] Ungültige Beispiele dokumentieren + - [ ] **FEI-ID** + - [ ] Gültiges Format definieren + - [ ] Wann ist FEI-ID Pflicht? (Turnierkategorie-abhängig) + - [ ] Ungültige Beispiele dokumentieren + - [ ] **Lizenzklassen (R1–R4, RD1–RD3, LZF)** + - [ ] Vollständige Liste aller gültigen Lizenzklassen + - [ ] Welche Lizenz erlaubt welche Bewerbsklasse? (Zuordnungstabelle Springen + Dressur) + - [ ] **Altersklassen Pferd** + - [ ] Mindestalter je Bewerbsklasse / Höhe (Springen + Dressur) + - [ ] Berechnungsregel: Stichtag für Pferdealter (1. Jänner des Geburtsjahres) + - [ ] Ergebnis als Dokument `docs/03_Domain/02_Reference/Validierungsregeln.md` ablegen + +- [ ] **A-2** | Abteilungs-Zwangsteilungsregeln vollständig spezifizieren + - [ ] CSN-C-NEU: Bewerb ≤95cm → `ohne Lizenz` | `mit Lizenz` (§ 231 ÖTO) + - [ ] CSN-C-NEU: Bewerb ≥100cm → `R1` | `R2 und höher` (§ 231 ÖTO) + - [ ] Gibt es weitere Pflicht-Teilungsregeln in anderen Kategorien? (CDN, CCN prüfen) + - [ ] Ergebnis in `TURNIER_KLASSEN.md` ergänzen + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | Validierungs-Implementierung Frontend begleiten + - [ ] Spezifikation aus Sprint A-1 an 🎨 Frontend übergeben + - [ ] Implementierung prüfen: Entspricht die Live-Validierung den Regelwerks-Anforderungen? + - [ ] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit prüfen + +- [ ] **B-2** | Validierungs-Implementierung Backend begleiten + - [ ] Spezifikation aus Sprint A-1 an 👷 Backend übergeben + - [ ] Serverseitige Validierung prüfen: Werden alle Regeln korrekt durchgesetzt? + - [ ] Grenzfälle definieren und an 🧐 QA weitergeben + +- [ ] **B-3** | Bewerbs-Typen und Bewertungslogik dokumentieren + - [ ] Stilspringen: Berechnungsformel Grundnote − Abzüge dokumentieren (§ 204 ÖTO) + - [ ] Dressurreiterprüfung: Bewertungskriterien dokumentieren (§ 103 ÖTO) + - [ ] Reihungsregeln bei Punktgleichheit dokumentieren + - [ ] Ergebnis: `REITER_PRUEFUNGEN.md` aktualisieren / vervollständigen + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen + - [ ] Alle Altersklassen-Grenzen aus dem Regelwerk extrahieren + - [ ] Testfälle für Grenzjahre definieren (z.B. Pferd born Jan vs. Dez) + - [ ] Testfälle an 🧐 QA übergeben + +- [ ] **C-2** | Funktionärs-Qualifikationen als Enum spezifizieren + - [ ] Alle Funktionärs-Typen auflisten (Richter, Parcourschef, Veterinär, etc.) + - [ ] Qualifikationsstufen je Typ definieren (z.B. Richter: Regional, National, International) + - [ ] Zuordnung: Welche Qualifikation ist für welche Turnierkategorie Pflicht? + - [ ] Ergebnis als Enum-Vorlage für 👷 Backend bereitstellen + +- [ ] **C-3** | ZNS-Export-Compliance prüfen + - [ ] ZNS-Dateiformat auf Aktualität (ÖTO 2026) prüfen + - [ ] Prüfungsart-Codes (`DR`, `ST`, etc.) im `zns-parser` validieren + - [ ] Fehlende oder veraltete Codes identifizieren und dokumentieren + +--- + +## ⏸️ Zurückgestellt + +> ⏸️ **Nenn-Formular Validierungsregeln (Lizenz × Klasse × Alter für Web-Formular)** — Nach Web-App Besprechung + +--- + +## 📌 Abhängigkeiten + +| Meine Aufgabe | Blockiert / Ermöglicht wen | +|---------------------------------------|--------------------------------------------------| +| Validierungs-Spezifikation (A-1) | 👷 Backend: serverseitige Validierung (Blocker) | +| Validierungs-Spezifikation (A-1) | 🎨 Frontend: Live-Feedback in Dialogen (Blocker) | +| Validierungs-Spezifikation (A-1) | 🧐 QA: Testfälle für Validierung | +| Abteilungs-Zwangsteilungsregeln (A-2) | 👷 Backend: `Bewerb.validate()` (Blocker) | +| Funktionärs-Qualifikationen (C-2) | 👷 Backend: Enum-Implementierung | diff --git a/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md b/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md new file mode 100644 index 00000000..f0b45290 --- /dev/null +++ b/docs/04_Agents/Roadmaps/SPRINT_EXECUTION_ORDER.md @@ -0,0 +1,214 @@ +# 🗓️ Sprint Execution Order — Entwickler-übergreifende Reihenfolge + +> **Stand:** 2. April 2026 +> **Autor:** 🏗️ Lead Architect +> **Zweck:** Verbindliche, entwickler-übergreifende Ausführungsreihenfolge aller Sprint-Schritte. +> Dieses Dokument ist die **Single Source of Truth** für „Wer macht was, in welcher Reihenfolge". + +--- + +## 📐 Legende + +| Symbol | Bedeutung | +|--------|----------------------------------------------------------------| +| 🔴 | Blocker — muss abgeschlossen sein bevor Folgeschritte beginnen | +| 🟡 | Kann parallel gestartet werden, sobald Voraussetzung erfüllt | +| 🟢 | Kann sofort und unabhängig gestartet werden | +| ⏳ | Wartet auf eine andere Aufgabe | +| ✅ | Abgeschlossen | +| ⏸️ | Zurückgestellt — separate Besprechung | +| `→` | „ermöglicht" / „blockiert" | + +--- + +## 🔴 PHASE 1 — Fundament legen (Woche 1, Sprint A) + +> **Ziel:** Alle Grundlagen schaffen, auf denen alle anderen aufbauen. +> Diese Phase darf nicht übersprungen werden — sie blockiert fast alles andere. + +### Schritt 1 — Startet sofort, gleichzeitig (Tag 1) + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|---------------|--------------------------------------------------------------------------------------------|-------------------------------------------------| +| 🔴 | 🏗️ Architect | **A-1** ADR-0021 schreiben: Tenant-Resolution-Strategie | → Freischalten von Schritt 2 (Backend A-1) | +| 🔴 | 🏗️ Architect | **A-2** Domänen-Modell formal präzisieren (`Veranstaltung → Turnier → Bewerb → Abteilung`) | → Freischalten von Backend A-2 und Frontend A-2 | +| 🔴 | 📜 Rulebook | **A-1** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenz, Alter) | → Freischalten von Backend A-3, Frontend B-3 | +| 🔴 | 📜 Rulebook | **A-2** Abteilungs-Zwangsteilungsregeln vollständig spezifizieren (CSN-C-NEU) | → Freischalten von Backend A-3, Frontend A-2 | +| 🟢 | 🧐 QA | **A-1** Test-Strategie für Desktop-App definieren (Testpyramide, Tooling, Konventionen) | → Grundlage für alle QA-Schritte | +| 🟢 | 🐧 DevOps | **A-1** Docker-Compose-Setup auf aktuellen Stand bringen | → Stabile lokale Dev-Umgebung für alle | +| 🟢 | 🧹 Curator | **A-5** Session-Log für heutige Besprechung erstellen | → Nachvollziehbarkeit der Beschlüsse | + +--- + +### Schritt 2 — Startet sobald Schritt 1 (Architect A-1 + A-2) abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------| +| 🔴 | 👷 Backend | **A-1** Tenant-Isolation im Datenzugriffs-Layer implementieren (basiert auf ADR-0021) | → Sichere Tenant-Grenze; Grundlage für alle weiteren Backend-Schritte | +| 🔴 | 👷 Backend | **A-2** Datenbankschema umsetzen: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` | → Freischalten von Backend B-1, B-2 | +| 🟡 | 🎨 Frontend | **A-1** ViewModel-Architektur definieren + `VeranstalterViewModel` als Referenz-Implementierung umsetzen (MVVM/UDF) | → Muster für alle anderen ViewModels | +| 🟡 | 🧹 Curator | **A-1** `Ubiquitous_Language.md` aktualisieren (nach Domänen-Modell vom Architect) | → Gemeinsames Vokabular für alle Teams | +| 🟡 | 🧹 Curator | **A-2** Event-First-Workflow dokumentieren | → Onboarding neuer Entwickler | + +--- + +### Schritt 3 — Startet sobald Schritt 2 (Backend A-2 + Rulebook A-1/A-2) abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|---------------------------------------------------------------------------------------------------|--------------------------------------------| +| 🔴 | 👷 Backend | **A-3** Turnierkategorie-Limits validieren (`Turnier.validate()`, `Bewerb.validate()`) | → ÖTO-konforme Dateneingabe gesichert | +| 🟡 | 🎨 Frontend | **A-2** Abteilungs-Logik im Bewerb-Dialog (CSN-C-NEU Pflicht-Teilung als Vorschlag + Validierung) | → Korrekte Abteilungsanlage durch Benutzer | +| 🟡 | 🧹 Curator | **A-3** Navigation-V2 dokumentieren (Screen-Baum, Back-Stack) | → | +| 🟡 | 🧹 Curator | **A-4** Tenant-Konzept dokumentieren (nach ADR-0021) | → | + +--- + +## 🟠 PHASE 2 — Verbinden & Implementieren (Woche 2, Sprint B) + +> **Ziel:** Frontend und Backend verbinden. Validierungslogik aktiv. Kassa-Service lauffähig. +> **Voraussetzung:** Phase 1 vollständig abgeschlossen. + +### Schritt 4 — Startet parallel, sobald Phase 1 abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------| +| 🔴 | 👷 Backend | **B-1** CRUD-Endpunkte für alle Stammdaten-Entitäten (`veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `reiter`, `pferde`, `vereine`, `funktionaere`) | → Freischalten von Frontend B-2 | +| 🟡 | 🎨 Frontend | **B-1** ViewModels für alle V2-Screens umsetzen (`TurnierViewModel`, `BewerbViewModel`, `PferdProfilViewModel`, etc.) | → Echte Datenbindung in allen Screens | +| 🟡 | 🖌️ UI/UX | **B-1** Wireframes: Edit-Formulare (AlertDialog vs. dedizierter Screen / Sliding-Panel) | → Grundlage für Frontend-Umsetzung der Formulare | +| 🟡 | 🖌️ UI/UX | **B-2** Wireframes: Bewerb + Abteilung anlegen (Abteilungs-Auswahl inkl. Pflicht-Felder) | → | +| 🟡 | 🖌️ UI/UX | **B-3** Wireframes: Kassa-Screen (Gesamt-Saldo + Zahlvorgang + Rechnungsvorschau) | → | +| 🟡 | 🐧 DevOps | **B-1** CI/CD Pipeline für Compose Desktop Tests headless konfigurieren | → Automatisierte Qualitätssicherung | +| 🟡 | 🐧 DevOps | **B-2** Gradle-Build-Optimierungen (Cache, parallele Builds, Wrapper-Update) | → Schnellere Build-Zeiten für alle | + +--- + +### Schritt 5 — Startet sobald Backend B-1 (CRUD-Endpunkte) abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------| +| 🔴 | 🎨 Frontend | **B-2** Ktor-Clients + Repositories für Backend-Anbindung; `StoreV2` schrittweise ersetzen | → Echte Daten statt Mock; Freischalten von Frontend B-3, B-4 | +| 🟡 | 🧹 Curator | **B-1** Roadmaps-Verzeichnis pflegen (abgeschlossene Tasks markieren) | → Transparenz über Fortschritt | +| 🟡 | 🧹 Curator | **B-2** `docs/05_Backend/` aktualisieren (neues DB-Schema, API-Endpunkte-Übersicht) | → | + +--- + +### Schritt 6 — Startet sobald Schritt 5 (Frontend B-2) abgeschlossen ist UND Rulebook A-1 vorliegt + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------| +| 🔴 | 👷 Backend | **B-3** ÖTO-Validierung serverseitig absichern (OEPS, FEI-ID, Lizenz, Altersklassen, Abteilungs-Zwangsteilung) | → Daten-Integrität auf Server-Ebene gesichert | +| 🟡 | 🎨 Frontend | **B-3** Validierungs-Live-Feedback in Edit-Dialogen (OEPS, FEI-ID, Lizenz × Klasse, Altersklasse) | → Benutzer sieht Fehler sofort | +| 🟡 | 📜 Rulebook | **B-1** Validierungs-Implementierung Frontend begleiten + prüfen | → Qualitätssicherung der Regelwerks-Compliance | +| 🟡 | 📜 Rulebook | **B-2** Validierungs-Implementierung Backend begleiten + prüfen | → | +| 🟡 | 🧐 QA | **B-1** Test-Suite: V2-Navigation und Back-Stack | → | +| 🟡 | 🧐 QA | **B-2** Test-Suite: Onboarding-Wizard Edge-Cases | → | +| 🟡 | 🧐 QA | **B-3** Test-Suite: Abteilungs-Logik (CSN-C-NEU Pflicht-Teilungen) | → | + +--- + +### Schritt 7 — Startet sobald Backend B-1 + B-3 abgeschlossen sind + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|-----------------------------------------------------------------------------------------------------------|----------------------------------------------------------| +| 🔴 | 👷 Backend | **B-2** Kassa-Service implementieren (`TeilnehmerKonto`, `Zahlvorgang`, Rechnungs-Generierung je Turnier) | → Freischalten von Frontend B-4 | +| 🟡 | 👷 Backend | **B-4** Nennungs-Service (Grundstruktur: Eingang, Status-Workflow, Postfach-Endpunkt) | → Freischalten von Frontend-Nennungs-Postfach (Sprint C) | +| 🟡 | 🧐 QA | **B-4** Test-Suite: ViewModel-Verhalten (State-Initialisierung, Intent → Transition, Error-State) | → | +| 🟡 | 📜 Rulebook | **B-3** Bewerbs-Typen und Bewertungslogik dokumentieren (Stilspringen, Dressurreiter, Reihungsregeln) | → | + +--- + +### Schritt 8 — Startet sobald Backend B-2 (Kassa-Service) + UI/UX Wireframes abgeschlossen sind + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|---------------------------------------------------------------------------------------------------------------|-----------------------------------------------| +| 🟡 | 🎨 Frontend | **B-4** Kassa-Screen: Gesamt-Saldo-Ansicht, Zahlvorgang, Rechnungsvorschau je Turnier | → Vollständige Kassa-Funktion für Meldestelle | +| 🟡 | 🧹 Curator | **B-3** `docs/06_Frontend/` aktualisieren (ViewModel-Architektur-Muster, Verweis auf `VeranstalterViewModel`) | → | + +--- + +## 🟡 PHASE 3 — Ausliefern & Aufräumen (Woche 3–4, Sprint C) + +> **Ziel:** Stabilisieren, testen, ausliefern, dokumentieren. +> **Voraussetzung:** Phase 2 vollständig abgeschlossen. + +### Schritt 9 — Startet parallel sobald Phase 2 abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|----------------------------------------------------------------------------------------------------------|--------------------------------------------| +| 🟡 | 🎨 Frontend | **C-1** `StoreV2` vollständig ablösen und entfernen / als `@Deprecated` markieren | → Saubere Architektur, kein Tech-Debt mehr | +| 🟡 | 👷 Backend | **C-1** Testdaten-Seeder implementieren (Neumarkt-Szenario: 2 Turniere, Bewerbe, Abteilungen, Nennungen) | → Reproduzierbare Testbasis für QA | +| 🟡 | 🧐 QA | **C-1** Test-Suite: Mandanten-Isolation (Veranstaltung A kann keine Daten von B lesen/schreiben) | → | +| 🟡 | 🧐 QA | **C-2** Test-Suite: Kassa und Zahlvorgang (1 Zahlung → 2 korrekte Rechnungen) | → | +| 🟡 | 📜 Rulebook | **C-1** `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Testfälle an QA übergeben | → | +| 🟡 | 🐧 DevOps | **C-1** Desktop-App Packaging (`.msi`, `.deb`, `.dmg`) | → Auslieferbare Desktop-App | +| 🟡 | 🖌️ UI/UX | **C-1** Wireframes aus Sprint B implementieren (Edit-Formulare + Sliding-Panel) | → | +| 🟡 | 🖌️ UI/UX | **C-2** Empty States für alle Listenansichten designen und umsetzen | → | +| 🟡 | 🧹 Curator | **C-1** `README.md` aktualisieren (Desktop-App Fokus, Schnellstart, V1-Referenzen entfernen) | → | +| 🟡 | 🧹 Curator | **C-2** Setup-Guide aktualisieren (`docs/02_Guides/`) | → | + +--- + +### Schritt 10 — Startet sobald Schritt 9 abgeschlossen ist + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|-------------|---------------------------------------------------------------------------------------------------------|-----------------------| +| 🟡 | 🧐 QA | **C-3** Test-Suite: ÖTO-Validierung (alle OEPS/FEI-ID/Lizenz-Kombinationen) | → | +| 🟡 | 👷 Backend | **C-2** Statistik-Endpunkte (`GET /turniere/{id}/statistiken`, `GET /veranstaltungen/{id}/statistiken`) | → | +| 🟡 | 📜 Rulebook | **C-2** Funktionärs-Qualifikationen auf Enum umstellen | → | +| 🟡 | 🐧 DevOps | **C-2** Semantic Versioning einführen + Release-Tagging in CI/CD | → | +| 🟡 | 🧹 Curator | **C-3** Unterordner-Struktur in `docs/` einführen (nach Abstimmung mit Architect) | → | +| 🟡 | 🧹 Curator | **C-4** V1-Code-Bereinigung koordinieren (gemeinsam mit Frontend + Backend) | → | + +--- + +### Schritt 11 — Abschluss Sprint C (nach Schritt 10) + +| Priorität | Wer | Aufgabe | Ergebnis / Ermöglicht | +|-----------|---------------|--------------------------------------------------------------------------------------------------------|-------------------------------------| +| 🟡 | 🏗️ Architect | **C-1** Synchronisations-Protokoll-Konzeption starten (Offline-First Desktop ↔ Backend) | → Grundlage für LAN-Sync (Sprint D) | +| 🟡 | 🏗️ Architect | **C-2** `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine) | → Aktueller Überblick für alle | +| 🟡 | 🐧 DevOps | **C-3** Produktions-Deployment vorbereiten | → | +| 🟡 | 🧹 Curator | **C-5** Reports-Verzeichnis pflegen (Kurzberichte Sprint A, B, C einsammeln + archivieren) | → | + +--- + +## ⏸️ Zurückgestellte Themen (eigene Besprechungen) + +| Thema | Status | Notiz | +|----------------------------------------------------------|-------------------------|------------------------------------------------------------------| +| USB-Stick Fallback (Export/Import bei LAN-Ausfall) | ⏸️ Separate Besprechung | Konzept liegt vor (JSON + Versionierung + Checksum) | +| Web-App Präsentation (Veranstaltung → Turnier → Inhalte) | ⏸️ Separate Besprechung | Hierarchie noch nicht final besprochen | +| Nenn-System (Web-Formular, dynamisch aus Turnier-Daten) | ⏸️ Separate Besprechung | Konzept liegt vor, Priorisierung nach Desktop-App-Fertigstellung | +| Live-Ergebnisse Web-App (SSE/WebSocket) | ⏸️ Separate Besprechung | Konzept liegt vor, nach Nenn-System | + +--- + +## 🔗 Kritischer Pfad (Blocker-Kette) + +Das ist die längste abhängige Kette — Verzögerung hier verzögert alles: + +``` +🏗️ ADR-0021 + └─→ 👷 Tenant-Isolation (Backend A-1) + └─→ 👷 DB-Schema (Backend A-2) + └─→ 👷 CRUD-Endpunkte (Backend B-1) + └─→ 🎨 Ktor-Repositories (Frontend B-2) + └─→ 🎨 Live-Validierung (Frontend B-3) + └─→ 🎨 Kassa-Screen (Frontend B-4) + └─→ 🧐 Kassa-Tests (QA C-2) + +📜 Validierungs-Spezifikation (Rulebook A-1) + └─→ 👷 ÖTO-Validierung Backend (Backend B-3) + └─→ 🎨 Live-Validierung Frontend (Frontend B-3) + └─→ 🧐 Validierungs-Tests (QA C-3) +``` + +--- + +## 📊 Gesamtübersicht: Wer ist wann aktiv? + +| Phase / Woche | 🏗️ Architect | 👷 Backend | 🎨 Frontend | 📜 Rulebook | 🐧 DevOps | 🧐 QA | 🖌️ UI/UX | 🧹 Curator | +|--------------------------|------------------------------|---------------------------------------|----------------------------------------------------------|--------------------------------------|-----------------------|------------------------------------|-----------------------------------|-------------------------------------| +| **Woche 1 (Sprint A)** | ADR-0021, Domänen-Modell | ⏳ (wartet auf ADR) | ViewModel-Referenz | Validierungsregeln, Abteilungsregeln | Docker-Setup | Test-Strategie | (Start Wireframes) | Session-Log, Ubiquitous_Language | +| **Woche 2 (Sprint B)** | LAN-Sync ADR | CRUD-APIs, Kassa-Service, Validierung | ViewModels, Repositories, Live-Validierung, Kassa-Screen | Implementierung begleiten | CI/CD, Gradle | Navigation-Tests, Abteilungs-Tests | Wireframes | Docs aktualisieren | +| **Woche 3–4 (Sprint C)** | Sync-Konzept, Roadmap-Update | Seeder, Statistiken | StoreV2-Ablösung | AltersklasseRechner, Enums | Packaging, Versioning | Isolation-Tests, Kassa-Tests | Empty States, Wireframes umsetzen | README, Setup-Guide, V1-Bereinigung | diff --git a/docs/04_Agents/Roadmaps/UIUX_Roadmap.md b/docs/04_Agents/Roadmaps/UIUX_Roadmap.md new file mode 100644 index 00000000..380e611a --- /dev/null +++ b/docs/04_Agents/Roadmaps/UIUX_Roadmap.md @@ -0,0 +1,84 @@ +# 🖌️ [UI/UX Designer] — Schritt-für-Schritt Roadmap + +> **Stand:** 2. April 2026 +> **Rolle:** High-Density Design, Wireframes, Usability, Compose Desktop UX + +--- + +## 🔴 Sprint A — Sofort (diese Woche) + +- [ ] **A-1** | Design-Inventur: Bestehende V2-Screens analysieren + - [ ] Alle vorhandenen V2-Screens katalogisieren (Screenshots in `docs/ScreenShots/`) + - [ ] Inkonsistenzen in Spacing, Typografie und Farbgebung identifizieren + - [ ] Offene UX-Probleme und fehlende Empty States dokumentieren + - [ ] Ergebnis als kurze Issue-Liste für Sprint B vorbereiten + +--- + +## 🟠 Sprint B — Kurzfristig (nächste Woche) + +- [ ] **B-1** | Wireframes: Editier-Formulare (AlertDialog vs. dedizierter Screen) + - [ ] Entscheidungsgrundlage erarbeiten: Wann AlertDialog, wann Fullscreen-Edit, wann Sliding-Panel? + - [ ] Kriterien definieren: Anzahl der Felder, Komplexität, Kontext-Erhalt + - [ ] Wireframes für beide Varianten erstellen (am Beispiel Reiter-Edit und Pferd-Edit) + - [ ] Entscheidung treffen und als Design-Richtlinie dokumentieren + - [ ] Ergebnis in `docs/06_Frontend/` ablegen + +- [ ] **B-2** | Wireframes: Bewerb anlegen mit Abteilungs-Logik + - [ ] Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung + - [ ] CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge + - [ ] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestalten + +- [ ] **B-3** | Wireframes: Veranstaltungs-Kassa + - [ ] Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren + - [ ] Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar + - [ ] Rechnungsvorschau: Zwei separate Rechnungen je Turnier nebeneinander oder als Tab + +- [ ] **B-4** | Empty States für alle Listenansichten + - [ ] Liste aller Screens mit möglichen leeren Zuständen erstellen + - [ ] Illustrations-Konzept oder Icon + Text für Empty States definieren + - [ ] Konsistente Vorlage für alle Empty States umsetzen + +--- + +## 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +- [ ] **C-1** | Wireframes aus Sprint B implementieren + - [ ] Editier-Dialog / Fullscreen-Edit gemäß Entscheidung aus B-1 in Compose umsetzen + - [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik gemäß B-2 umsetzen + - [ ] Kassa-Screen gemäß B-3 umsetzen + +- [ ] **C-2** | Design-System konsolidieren + - [ ] Farb-Palette in `MaterialTheme` / `Theme.kt` vereinheitlichen + - [ ] Typografie-Skala definieren (Überschriften, Body, Labels, Captions) + - [ ] Wiederverwendbare Komponenten identifizieren und als Composables extrahieren + (z.B. `MeldestelleCard`, `SectionHeader`, `StatusBadge`) + +- [ ] **C-3** | Abteilungs-Ansicht: Startliste und Ergebnisliste + - [ ] Wireframe: Startliste einer Abteilung (Startnummer, Reiter, Pferd, Verein) + - [ ] Wireframe: Ergebnisliste einer Abteilung (Platz, Reiter, Pferd, Ergebnis) + - [ ] Wireframe: Gesamtrangliste Bewerb (organisatorische Abteilungen zusammengeführt) + - [ ] Wireframe: Separate Siegerehrungsliste (CSN-C-NEU, getrennt nach Lizenzklasse) + +--- + +## ⏸️ Zurückgestellt + +> ⏸️ **Web-App Präsentation (Veranstaltungs-Seite, Turnier-Seite)** — Separate Besprechung zu einem späteren Zeitpunkt +> ⏸️ **Nenn-Formular (Web)** — Separate Besprechung zu einem späteren Zeitpunkt +> ⏸️ **Live-Ergebnis-Seite (Web)** — Separate Besprechung zu einem späteren Zeitpunkt + +--- + +## 📌 Abhängigkeiten + +| Warte auf | Von wem | +|---------------------------------------------|---------------| +| Domänen-Modell final (Abteilung, Kassa) | 🏗️ Architect | +| ViewModel-Struktur (welche States gibt es?) | 🎨 Frontend | + +| Meine Aufgabe | Ermöglicht wem | +|------------------------------------|-----------------------------------------------| +| Wireframes Editier-Formulare (B-1) | 🎨 Frontend: Implementierung der Edit-Dialoge | +| Wireframes Kassa (B-3) | 🎨 Frontend: Kassa-Screen-Implementierung | +| Design-System (C-2) | Alle: konsistentes UI ohne Nacharbeit | diff --git a/docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md b/docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md new file mode 100644 index 00000000..45f7c718 --- /dev/null +++ b/docs/99_Journal/2026-04-02_Besprechung_Sprint-Planung.md @@ -0,0 +1,206 @@ +# 🧹 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. diff --git a/docs/temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md b/docs/temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md new file mode 100644 index 00000000..51224dc0 --- /dev/null +++ b/docs/temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md @@ -0,0 +1,135 @@ +🏗️ **[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. diff --git a/docs/temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md b/docs/temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md new file mode 100644 index 00000000..c25a30ed --- /dev/null +++ b/docs/temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md @@ -0,0 +1,26 @@ +Meldestelle Besprechung! + +Wir berufen diese Besprechung ein, um die nächsten Entwicklungsschritte zu besprechen. +Es liegen aktuellen Reports aller Entwickler von diesem Projekt vor. +Jeder Entwickler hat in seinem Report Empfehlungen priorisiert. + +docs/90_Reports/2026-04-02_Architect_Report.md +docs/90_Reports/2026-04-02_Backend_Report.md +docs/90_Reports/2026-04-02_Curator_Report.md +docs/90_Reports/2026-04-02_DevOps_Report.md +docs/90_Reports/2026-04-02_Frontend_Report.md +docs/90_Reports/2026-04-02_QA_Report.md +docs/90_Reports/2026-04-02_Rulebook_Report.md +docs/90_Reports/2026-04-02_UIUX_Report.md + +In dieser Besprechung wollen wir + +- Übersicht bekommen +- Strategie besprechen +- Arbeitsaufträge für jeden Entwickler ausarbeiten +- genaue Reihenfolge der nächsten Entwicklungsschritte festlegen + +Am Ende dieser Besprechung, soll jeder Entwickler genau wissen was er wann machen soll. +Wir wollen alle an einem Strang ziehen. + +Sind alle Entwickler anwesend und vorbereitet? diff --git a/docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md b/docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md new file mode 100644 index 00000000..ba0364b2 --- /dev/null +++ b/docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md @@ -0,0 +1,167 @@ +🏗️ **[Lead Architect]** — Besprechungsprotokoll | Meldestelle-Biest | 2. April 2026 + +--- + +### 📋 Anwesenheit & Vorbereitung + +| Agent | Anwesend | Report vorliegend | +|----------------------|----------|-------------------| +| 🏗️ Lead Architect | ✅ | ✅ | +| 👷 Backend Developer | ✅ | ✅ | +| 🎨 Frontend Expert | ✅ | ✅ | +| 🐧 DevOps Engineer | ✅ | ✅ | +| 🧐 QA Specialist | ✅ | ✅ | +| 📜 Rulebook Expert | ✅ | ✅ | +| 🖌️ UI/UX Designer | ✅ | ✅ | +| 🧹 Curator | ✅ | ✅ | + +**Alle Entwickler sind anwesend und haben ihre Reports eingereicht. Die Besprechung kann beginnen.** + +--- + +### 📊 Übersicht: Wo stehen wir? + +Das Projekt hat in den letzten Tagen starken Momentum im **Frontend** (V2-Screens, Event-First-Workflow, Navigation mit +Back-Stack) aufgebaut. Die Desktop-App nimmt konkrete Form an. Gleichzeitig haben sich **drei kritische Schulden** +aufgebaut, die jetzt adressiert werden müssen, bevor wir weiter bauen: + +1. **Frontend-Architektur-Schulden:** Business-Logik liegt direkt in den Composables (`StoreV2`-Aufrufe, lokaler + `remember`-State). Ohne ViewModel-Refactoring wird der Code bald unwartbar. +2. **Backend fehlt als Fundament:** Das Frontend läuft auf einem Mock-Store. Echte CRUD-Endpunkte und Tenant-Isolation + fehlen vollständig. +3. **Validierung ist ein Sicherheitsloch:** FEI-IDs, OEPS-Nummern und Lizenzklassen können aktuell als beliebige Strings + gespeichert werden — das verletzt ÖTO/FEI-Compliance. + +**Kernaussage der Besprechung:** Wir müssen jetzt das Fundament stärken, bevor wir neue Features bauen. + +--- + +### 🎯 Strategie: Die 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 +``` + +Wir arbeiten **in dieser Reihenfolge** — Säule 1 blockiert Säule 2, Säule 2 blockiert Säule 3. + +--- + +### 📅 Reihenfolge der nächsten Entwicklungsschritte + +#### 🔴 Sprint A — Sofort (diese Woche) + +**Ziel: Das Fundament stabilisieren, damit alle anderen aufbauen können.** + +| # | Wer | Aufgabe | +|-----|---------------|--------------------------------------------------------------------------------------------------------------------------| +| A-1 | 🏗️ Architect | Tenant-Resolution-Strategie entscheiden (Schema-per-Tenant vs. Tenant-ID in allen Tabellen) — **Ergebnis: ADR-0021** | +| A-2 | 🎨 Frontend | ViewModel-Architektur definieren und `VeranstalterViewModel` als Referenz-Implementierung (MVVM/UDF) umsetzen | +| A-3 | 👷 Backend | Tenant-Isolation im Datenzugriffs-Layer implementieren auf Basis von ADR-0021 | +| A-4 | 🧹 Curator | `docs/01_Architecture/` mit Event-First-Workflow, Navigation-V2 und Tenant-Konzept dokumentieren | +| A-5 | 📜 Rulebook | Validierungsregeln für OEPS-Nummern, FEI-IDs und Lizenzklassen (R1–R4) schriftlich spezifizieren — als Grundlage für A-6 | + +> ⚠️ **A-1 (ADR-0021) ist ein Blocker für A-3!** Der Architect liefert zuerst. + +--- + +#### 🟠 Sprint B — Kurzfristig (nächste Woche) + +**Ziel: Frontend und Backend verbinden, Validierung implementieren.** + +| # | Wer | Aufgabe | +|-----|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------| +| B-1 | 👷 Backend | CRUD-Endpunkte für Veranstalter, Veranstaltungen, Reiter, Pferde, Vereine, Funktionäre implementieren | +| B-2 | 🎨 Frontend | ViewModels für alle V2-Screens umsetzen (`PferdProfilViewModel`, etc.) und Ktor-Clients/Repositories für Backend-Anbindung vorbereiten | +| B-3 | 📜 Rulebook + 🎨 Frontend | Validierungslogik aus Sprint A-5 als Live-Feedback in V2-Edit-Dialogen implementieren | +| B-4 | 📜 Rulebook + 👷 Backend | Dieselbe Validierungslogik serverseitig absichern | +| B-5 | 🖌️ UI/UX | UX-Konzept für Editier-Formulare überarbeiten: AlertDialog vs. dedizierter Screen / Sliding-Panel — **Ergebnis: Wireframes** | +| B-6 | 🧐 QA | Test-Suite für V2-Navigation und Back-Stack aufbauen; Edge-Cases für Onboarding/Wizard (leere Felder, schnelles Klicken, Abbrechen) | +| B-7 | 🐧 DevOps | CI/CD Pipeline für Compose-Desktop-Tests headless konfigurieren (GitHub/Gitea Actions) | + +--- + +#### 🟡 Sprint C — Mittelfristig (in 2 Wochen) + +**Ziel: Ausliefern, offline-fähig machen, aufräumen.** + +| # | Wer | Aufgabe | +|-----|---------------|-------------------------------------------------------------------------------------------------------------------------| +| C-1 | 🐧 DevOps | Desktop-App-Packaging konfigurieren (`.msi` / `.deb` / `.dmg`) via `compose.desktop.nativeDistributions` | +| C-2 | 🏗️ Architect | Synchronisations-Protokoll-Konzeption starten (Event-Sourcing vs. CRDT vs. Timestamp-Sync) | +| C-3 | 👷 Backend | Testdaten-Seeder implementieren (reproduzierbare Turnier-, Nennungs- und Stammdaten) | +| C-4 | 🧐 QA | Testfälle für Mandanten-Isolation (Daten strikt zwischen Veranstaltungen getrennt) | +| C-5 | 🖌️ UI/UX | Wireframes aus B-5 implementieren; Empty States für alle Listenansichten designen und umsetzen | +| C-6 | 📜 Rulebook | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Funktionärs-Qualifikationen auf Enum umstellen | +| C-7 | 🧹 Curator | `README.md` und Setup-Guide aktualisieren; Unterordner-Struktur für `docs/` einführen; V1-Code-Bereinigung koordinieren | +| C-8 | 🏗️ Architect | `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine) | +| C-9 | 🐧 DevOps | Semantic Versioning Strategie einführen; koordiniertes Release-Tagging Client + Server | + +--- + +### 📌 Individuelle Arbeitsaufträge (Zusammenfassung) + +#### 🏗️ Lead Architect + +1. **[A-1, sofort]** ADR-0021 schreiben: Tenant-Resolution-Strategie entscheiden +2. **[C-2]** Sync-Protokoll-Konzept starten +3. **[C-8]** MASTER_ROADMAP aktualisieren + +#### 👷 Backend Developer + +1. **[A-3, nach ADR-0021]** Tenant-Isolation im Datenzugriffs-Layer +2. **[B-1]** CRUD-APIs für alle Stammdaten-Entitäten +3. **[B-4]** ÖTO-Validierung serverseitig absichern +4. **[C-3]** Testdaten-Seeder + +#### 🎨 Frontend Expert + +1. **[A-2, sofort]** ViewModel-Referenz-Implementierung (`VeranstalterViewModel`, MVVM/UDF) +2. **[B-2]** Alle V2-ViewModels + Ktor-Client-Repositories +3. **[B-3]** Validierungs-Live-Feedback in Edit-Dialogen + +#### 🐧 DevOps Engineer + +1. **[B-7]** CI/CD für Compose Desktop Tests (headless) +2. **[C-1]** Desktop-App Packaging (Distributionen) +3. **[C-9]** Semantic Versioning + Release-Strategie + +#### 🧐 QA Specialist + +1. **[B-6, parallel zu Sprint B]** Test-Suite Navigation/Back-Stack + Onboarding-Edge-Cases +2. **[C-4]** Mandanten-Isolations-Testfälle + +#### 📜 ÖTO/FEI Rulebook Expert + +1. **[A-5, sofort]** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenzklassen) +2. **[B-3/B-4]** Implementierung der Validierung Frontend + Backend begleiten +3. **[C-6]** AltersklasseRechner vollständig testen; Funktionärs-Qualifikationen als Enum + +#### 🖌️ UI/UX Designer + +1. **[B-5]** Wireframes: Dialog vs. Fullscreen-Edit entscheiden +2. **[C-5]** Wireframes implementieren + Empty States designen und umsetzen + +#### 🧹 Curator + +1. **[A-4, sofort]** Event-First-Workflow + Navigation-V2 + Tenant-Konzept dokumentieren +2. **[C-7]** README + Setup-Guide + Docs-Struktur + V1-Code-Bereinigung koordinieren + +--- + +### ✅ Beschlüsse dieser Besprechung + +1. **ADR-0021 (Tenant-Resolution)** wird sofort vom Architect erstellt — es ist der wichtigste Blocker. +2. **ViewModel-Architektur** wird vor neuen Features eingeführt — kein weiterer Code ohne ViewModel. +3. **Kein neues Feature ohne ÖTO-Validierung** — Rulebook Expert gibt die Spezifikation vor, Backend + Frontend setzen + sie gemeinsam um. +4. **Mock-Store (`StoreV2`) ist temporär** — Ziel von Sprint B ist die vollständige Ablösung durch echte + Backend-Anbindung. +5. **MASTER_ROADMAP** wird am Ende von Sprint C durch den Architect aktualisiert. + +--- + +> 🏁 **Alle Entwickler wissen, was sie wann zu tun haben. Wir ziehen an einem Strang. Sprint A beginnt jetzt.** diff --git a/docs/temp/2026-04-02_Besprechung/Okay,_alle_Entwickler_haben_Ihre_Aufgabe.md b/docs/temp/2026-04-02_Besprechung/Okay,_alle_Entwickler_haben_Ihre_Aufgabe.md new file mode 100644 index 00000000..dfa0a05c --- /dev/null +++ b/docs/temp/2026-04-02_Besprechung/Okay,_alle_Entwickler_haben_Ihre_Aufgabe.md @@ -0,0 +1,42 @@ +🏗️ **[Lead Architect]** — Besprechungsabschluss | 2. April 2026 + +--- + +### Abschlussfrage an alle Entwickler + +Die Frage geht in die Runde — und hier die Rückmeldungen: + +| Agent | Status | Offene Fragen | +|----------------------|-----------------------------------------------------------------|---------------| +| 🏗️ Lead Architect | ✅ Klar — starte sofort mit ADR-0021 | Keine | +| 👷 Backend Developer | ✅ Klar — warte auf ADR-0021, dann Schema | Keine | +| 🎨 Frontend Expert | ✅ Klar — starte ViewModel-Architektur parallel | Keine | +| 🐧 DevOps Engineer | ✅ Klar — CI/CD headless ist Sprint B Aufgabe | Keine | +| 🧐 QA Specialist | ✅ Klar — Test-Strategie-Dokument und Navigation-Tests starten | Keine | +| 📜 Rulebook Expert | ✅ Klar — Validierungsregeln-Spezifikation beginnt sofort | Keine | +| 🖌️ UI/UX Designer | ✅ Klar — Design-Inventur der V2-Screens als erster Schritt | Keine | +| 🧹 Curator | ✅ Klar — `Ubiquitous_Language.md` und Session-Log sind Sprint A | Keine | + +**Alle Entwickler sind informiert. Keine offenen Fragen.** + +--- + +### 🏁 Besprechung offiziell beendet + +**Erstellt in dieser Besprechung:** + +- ✅ Strategischer Sprint-Plan (A → B → C) mit klaren Verantwortlichkeiten +- ✅ 8 individuelle Schritt-für-Schritt Roadmaps (`docs/04_Agents/Roadmaps/`) +- ✅ Entwickler-übergreifende Ausführungsreihenfolge (`SPRINT_EXECUTION_ORDER.md`) +- ✅ Domänen-Modell präzisiert (`Veranstaltung → Turnier → Bewerb → Abteilung`) +- ✅ Veranstaltungs-Kassa-Konzept ausgearbeitet (Multi-Turnier-Saldo, 1 Zahlung, 2 Rechnungen) +- ✅ Zurückgestellte Themen dokumentiert (⏸️ USB-Fallback, Web-App, Nenn-System, Live-Ergebnisse) + +**Der nächste Schritt liegt beim Architect:** `ADR-0021` — Tenant-Resolution-Strategie. + +> 🎯 **Wir ziehen an einem Strang. Sprint A beginnt jetzt.** + +--- + +*🧹 Curator-Hinweis: Session-Log dieser Besprechung bitte unter `docs/99_Journal/` +als `2026-04-02_Besprechung_Sprint-Planung.md` ablegen — das ist Aufgabe A-5 in der Curator Roadmap.* diff --git a/docs/temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md b/docs/temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md new file mode 100644 index 00000000..b2d4024f --- /dev/null +++ b/docs/temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md @@ -0,0 +1,128 @@ +🏗️ **[Lead Architect]** — Antwort auf Domänen-Fragen des Projekt-Owners | 2. April 2026 + +--- + +### 1. Ist die Hierarchie korrekt verstanden? Fast — aber wir müssen das Domain-Modell schärfen. + +Dein Verständnis ist **im Kern richtig**, aber die aktuelle `Ubiquitous_Language.md` hat hier noch eine **Unschärfe**, +die wir jetzt klären müssen: + +**Aktuelles Modell (wie dokumentiert):** + +``` +Veranstalter + └── Veranstaltung (interne ID, selbst vergeben) + ├── Typ: Turnier | Reitertreffen | ... + └── [wenn Typ = Turnier] + └── Turniernummer (OEPS-vergeben, eindeutig) +``` + +Das aktuelle Modell impliziert **1 Veranstaltung = 1 Turnier** (eine Turniernummer je Veranstaltung). + +**Das Neumarkt-Szenario bricht dieses Modell auf:** +Neumarkt ist **eine organisatorische Veranstaltung** (selber Veranstalter, selbes Gelände, selber Zeitraum), aber +besteht aus **zwei offiziellen OEPS-Turnieren** mit je eigener Turniernummer. + +**Korrekte Hierarchie (erweitert):** + +``` +Veranstalter (OEPS-Mitgliedsverein, z.B. URV Neumarkt) + └── Veranstaltung (interne ID, z.B. "NM-2026") + │ ← Tenant-Grenze (eigene Datenbank, ADR-0020) + │ ← Örtlich & zeitlich begrenzt + │ + ├── Turnier #1 (OEPS-Turniernummer: 26128, CSN-C NEU) + │ ├── Bewerbe (1–14) + │ └── Turnier-Kassa + │ + └── Turnier #2 (OEPS-Turniernummer: 26129 o.ä., z.B. CSNP-C NEU) + ├── Bewerbe (1–N) + └── Turnier-Kassa +``` + +**Antwort auf deine Frage:** ✅ **Ja, genau so.** Die `Veranstaltung` ist unser interner Überbegriff mit selbst +vergebener ID und ist gleichzeitig die Tenant-Grenze (eine Datenbank). Innerhalb dieser Veranstaltung gibt es eine oder +mehrere pferdesportliche Veranstaltungen — aktuell vom Typ `Turnier` — jede mit ihrer vom Verband (OEPS/FEI) vergebenen +Turniernummer. **Diese Unterscheidung muss noch in die `Ubiquitous_Language.md` und in das Datenbankschema einfließen +** (das ist ein Arbeitsauftrag für den Curator + Backend). + +--- + +### 2. Veranstaltungs-Kassa mit Turnier-übergreifendem Saldo: Umsetzbar? + +✅ **Ja, das ist absolut umsetzbar — und architektonisch sauber lösbar.** + +#### Das Konzept: Drei Ebenen der Kassa + +``` +VERANSTALTUNGS-KASSA (Aggregations-Ebene) + ├── TeilnehmerKonto (Reiter × Pferd, pro Veranstaltung) + │ ├── Saldo aus Turnier #1 (z.B. –€ 75,-) + │ └── Saldo aus Turnier #2 (z.B. –€ 45,-) + │ Gesamt-Offener-Betrag: –€ 120,- + │ + └── Zahlvorgang (1× Kassagang am Ende der Veranstaltung) + ├── Rechnung Turnier #1 (€ 75,-) → OEPS-Meldung Turnier 26128 + └── Rechnung Turnier #2 (€ 45,-) → OEPS-Meldung Turnier 26129 +``` + +#### Wie das funktioniert (Ablauf Neumarkt): + +| Schritt | Was passiert | +|----------------------------------------------------------------|--------------------------------------------------------| +| Teilnehmer meldet sich für Bewerbe in **Turnier 1** | Forderung wird `TurnierKassa #1` verbucht | +| Derselbe Teilnehmer meldet sich für Bewerbe in **Turnier 2** | Forderung wird `TurnierKassa #2` verbucht | +| Teilnehmer kommt **einmal** zur Kassa (Ende der Veranstaltung) | System zeigt Gesamt-Saldo aus beiden Turnieren | +| Kassier nimmt **eine Zahlung** entgegen | `Zahlvorgang` wird auf `Veranstaltungs-Ebene` gebucht | +| System generiert **zwei separate Rechnungen** | Je eine pro Turnier (für OEPS-Abrechnung notwendig) | +| Turnier-Kassenabschluss | Jede `TurnierKassa` schließt separat ab (OEPS-konform) | + +#### Warum zwei separate Rechnungen notwendig sind: + +Das ist nicht nur ein Komfort-Feature — es ist eine **OEPS-Pflicht**. Jedes Turnier mit eigener Turniernummer muss +separat an den Verband gemeldet werden. Die Startgelder und Nenngelder sind je Turniernummer nachvollziehbar zu belegen. +Eine gemeinsame Rechnung über beide Turniere würde die ZNS-Meldung erschweren. + +--- + +### 3. Statistiken: Separat und aggregiert + +Selbe Logik, selbe Lösung: + +| Ansicht | Quelle | +|------------------------------------|----------------------------------------------------| +| **Statistik Turnier #1** | Nur Daten aus `Turnier.id = 26128` | +| **Statistik Turnier #2** | Nur Daten aus `Turnier.id = 26129` | +| **Statistik Veranstaltung gesamt** | Aggregation über alle Turniere der `Veranstaltung` | + +Das ist eine reine Abfrage-/Reporting-Frage. Da die `Veranstaltung` die Tenant-Grenze ist (alle Daten in einer +Datenbank), sind sowohl turnierspezifische als auch veranstaltungsweite Auswertungen mit einfachen SQL-Abfragen +realisierbar — keine aufwendige Cross-Tenant-Kommunikation nötig. + +--- + +### 📌 Was das für unsere Arbeitsaufträge bedeutet + +Deine Fragen zeigen eine **wichtige Lücke** im bisherigen Plan, die wir jetzt schließen müssen: + +| Priorität | Wer | Aufgabe | +|------------------------------|---------------|-----------------------------------------------------------------------------------------------------------------------------| +| 🔴 **Sofort (vor ADR-0021)** | 🏗️ Architect | Domänen-Modell präzisieren: `Veranstaltung` 1:N `Turnier` explizit festlegen. `Ubiquitous_Language.md` anpassen. | +| 🔴 **Sprint A** | 👷 Backend | Datenbankschema: `veranstaltungen` Tabelle + `turniere` Tabelle (mit FK auf Veranstaltung, Turniernummer als OEPS-vergeben) | +| 🟠 **Sprint B** | 👷 Backend | `teilnehmer_konto` auf Veranstaltungs-Ebene; `zahlvorgang` mit Multi-Turnier-Aufteilung; Rechnungs-Generierung pro Turnier | +| 🟠 **Sprint B** | 🎨 Frontend | UI für Veranstaltungs-Kassa: Gesamtsaldo-Ansicht + Zahlvorgang + Rechnungsvorschau je Turnier | +| 🟡 **Sprint C** | 🧐 QA | Testfälle: Teilnehmer an 2 Turnieren → 1 Zahlung → 2 korrekte Rechnungen | + +> ⚠️ **Wichtig:** Der Begriff `TeilnehmerKonto` auf Veranstaltungsebene (über mehrere Turniere) ist **neu** und muss in +> die `Ubiquitous_Language.md` aufgenommen werden. Das ist ein Auftrag für Curator + Rulebook Expert gemeinsam. + +--- + +### ✅ Kurz-Zusammenfassung für den Owner + +1. **Ja** — `Veranstaltung` (interne ID, Tenant-Grenze) enthält ein oder mehrere `Turnier` (mit OEPS-Turniernummer). Das + Modell muss noch formal so dokumentiert werden. +2. **Ja** — Eine `Veranstaltungs-Kassa` mit Turnier-übergreifendem Saldo, einem Zahlvorgang, aber zwei separaten + Rechnungen ist architektonisch sauber umsetzbar und ist sogar die richtige Lösung für die OEPS-konforme Abrechnung. +3. **Ja** — Statistiken können auf beiden Ebenen (per Turnier und gesamt per Veranstaltung) ausgewertet werden, ohne + Mehraufwand, da alle Daten im selben Tenant (Datenbank) liegen.