docs: restructure and streamline sprint execution order
- Consolidated and removed redundant steps in `SPRINT_EXECUTION_ORDER.md`. - Simplified descriptions and roadmap formatting for improved clarity. - Updated progress and dependencies to align with Phase 8 objectives. - Adjusted role-specific roadmaps to reflect the latest sprint updates. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,101 +1,81 @@
|
||||
# 📜 [ÖTO/FEI Rulebook Expert] — Schritt-für-Schritt Roadmap
|
||||
# 📜 [ÖTO/FEI Rulebook Expert] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, ÖTO/FEI Compliance
|
||||
> **Rolle:** Regelwerks-Wächter, Validierungs-Spezialist, Compliance (ÖTO, FEI)
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Validierungsregeln schriftlich spezifizieren — Grundlage für alle anderen Teams
|
||||
- [x] **OEPS-Mitgliedsnummer**
|
||||
- [x] Gültiges Format definieren (Länge, erlaubte Zeichen, Präfixe)
|
||||
- [x] Ungültige Beispiele dokumentieren
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „OEPS‑Mitgliedsnummer“
|
||||
- [x] **FEI-ID**
|
||||
- [x] Gültiges Format definieren (numerisch 7–8 stellig + Legacy‑Code `NNNAA NN`)
|
||||
- [x] Pflichtregel national/international festhalten (Turnierkategorie‑abhängig)
|
||||
- [x] Ungültige Beispiele dokumentieren
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „FEI‑ID“
|
||||
- Backend‑Lookup: `GET /api/fei/resolve/{id}` (Masterdata‑SCS), Mapping‑Quelle `data/fei-id-mapping.json` — dokumentiert in Validierungsregeln 2.9
|
||||
- [x] **Lizenzklassen (R1–R4, RD1–RD3, LZF)**
|
||||
- [x] Vollständige Liste aller gültigen Lizenzklassen
|
||||
- [x] Erste Lizenz‑Zuordnungstabellen (Springen + Dressur) als DRAFT mit Paragraphen‑Platzhaltern
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „Lizenzklassen“
|
||||
- [x] **Altersklassen Pferd**
|
||||
- [x] Mindestalter je Disziplin/Klasse als DRAFT‑Tabellen (ÖTO/FEI) ergänzt
|
||||
- [x] Berechnungsregel: Stichtag 1. Jänner des Geburtsjahres
|
||||
- Ergebnis: siehe `docs/03_Domain/02_Reference/Validierungsregeln.md` Abschnitt „Altersklassen Pferd“
|
||||
- [x] Ergebnis als Dokument `docs/03_Domain/02_Reference/Validierungsregeln.md` ablegen (Status: DRAFT v0.3)
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
- [x] **A-2** | Abteilungs-Zwangsteilungsregeln vollständig spezifizieren
|
||||
- [x] CSN-C-NEU: Bewerb ≤95cm → `ohne Lizenz` | `mit Lizenz` (§ 231 ÖTO, Platzhalter) — spezifiziert
|
||||
- [x] CSN-C-NEU: Bewerb ≥100cm → `R1` | `R2 und höher` (§ 231 ÖTO, Platzhalter) — spezifiziert
|
||||
- [x] Weitere Pflicht-Teilungsregeln geprüft: CDN, CCN — derzeit keine generische Zwangsteilung wie CSN-C-NEU identifiziert (Platzhalter‑Paragraphen nachtragen)
|
||||
- [x] Ergebnis dokumentiert in `docs/03_Domain/02_Reference/TURNIER_KLASSEN.md`
|
||||
- [x] Paragraphen‑Pins ergänzt (Springen § 231, Dressur § 103, CCN Kap. §§3xx) und einheitliche Label‑Konventionen definiert ("ohne Lizenz", "mit Lizenz", "R2 und höher"; Keys: `LZF_ONLY`, `R1_PLUS`, `R1_ONLY`, `R2_PLUS`).
|
||||
- [x] Optionale Jugend-/Jahrgangsteilungen als Regel‑Modell (Regulation‑as‑Data) ergänzt, keine systemweite Pflicht.
|
||||
- [x] **A-1** | Validierungs-Spezifikation erstellen (v0.3 DRAFT)
|
||||
- [x] Paragraphen-Pins ergänzt (Springen § 231, Dressur § 103, CCN §§ 3xx)
|
||||
- [x] Einheitliche Label-Konventionen: `ohne Lizenz`, `mit Lizenz`, `R2 und höher`; Keys: `LZF_ONLY`, `R1_PLUS`,
|
||||
`R1_ONLY`, `R2_PLUS`
|
||||
- [x] Optionale Jugend-/Jahrgangsteilungen als Regulation-as-Data modelliert (keine systemweite Pflicht)
|
||||
- [x] Abteilungs-Trennungs-Schwellenwerte dokumentiert →
|
||||
`docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
|
||||
- [x] Warn-Logik-Spezifikation →
|
||||
`docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md`
|
||||
- [x] CVN (Voltigieren): § 39 Abs. 2 als Fallback; eigene OEPS-CVN-Regeln gelten
|
||||
- [x] CAN (Fahren): § 39 Abs. 2 als Fallback; § 850 Abs. 9 für F1+ Fahrertreffen
|
||||
- [x] `OetoValidators` (KMP) implementiert; `OetoValidatorsTest.kt` grün
|
||||
|
||||
---
|
||||
|
||||
## 🟠 Sprint B — Kurzfristig (nächste Woche)
|
||||
### Sprint B (Teilweise) — Abgeschlossen
|
||||
|
||||
- [x] **B-1** | Validierungs-Implementierung Frontend begleiten
|
||||
- [x] Spezifikation aus Sprint A-1 (v0.3 DRAFT) an 🎨 Frontend übergeben
|
||||
- [x] Implementierung prüfen: Entspricht die Live-Validierung den Regelwerks-Anforderungen?
|
||||
- Ergebnis: `OetoValidators.kt` in `frontend/core/domain` implementiert (OEPS, FEI-ID, Lizenzklasse, Pferd-Alter)
|
||||
- `ReiterProfilViewModel` + `PferdProfilViewModel` mit Live-Validierung (typisierte `ValidationResult`) erweitert
|
||||
- Mock-Daten in `Stores.kt` + `NennungModels.kt` auf regelkonforme Formate korrigiert (OEPS, Lizenzklassen)
|
||||
- [x] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit prüfen
|
||||
- Ergebnis: Alle Fehlertexte zweistufig (`short` für Inline-Hint, `long` für Tooltip/Dialog), regelwerkskonform
|
||||
- 30 Unit-Tests in `OetoValidatorsTest.kt` — alle grün (BUILD SUCCESSFUL)
|
||||
- [x] Spezifikation v0.3 DRAFT an 🎨 Frontend übergeben
|
||||
- [x] Implementierung geprüft: Live-Validierung entspricht Regelwerks-Anforderungen
|
||||
- [x] Fehlermeldungs-Texte auf Korrektheit und Verständlichkeit geprüft
|
||||
- [x] Session-Log → `docs/99_Journal/2026-04-03_Rulebook_B1_Validierung_Frontend.md`
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-2** | Validierungs-Implementierung Backend begleiten
|
||||
- [x] FEI Legacy→Numeric Resolver implementiert (`/api/fei/resolve/{id}`) — erste Version in Masterdata‑SCS
|
||||
- [ ] Spezifikation aus Sprint A-1 an 👷 Backend übergeben (Lizenz-/Altersmatrix als Regulation‑as‑Data)
|
||||
- [x] FEI Legacy→Numeric Resolver implementiert (`/api/fei/resolve/{id}`) — erste Version in Masterdata-SCS
|
||||
- [ ] Lizenz-/Altersmatrix als Regulation-as-Data 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
|
||||
- [ ] Abweichungen Backend ↔ Frontend-Validierung dokumentieren und klären
|
||||
- [ ] Lizenz×Bewerb-Tabellen (Springen + Dressur) von DRAFT auf STABLE anheben (nach Fachfreigabe)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **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-1** | `AltersklasseRechner` implementieren und testen
|
||||
- [ ] Altersklassen-Berechnung für Pferd (Jahrgang → Kategorie) umsetzen
|
||||
- [ ] Grenzfälle: Pferd im Geburtsjahr, Jahreswechsel, Stichtag-Regeln
|
||||
- [ ] Unit-Tests mit `OetoValidatorsTest.kt`-Grenzfällen als Basis
|
||||
|
||||
- [ ] **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-2** | Regelwerk-Enums vervollständigen
|
||||
- [ ] Alle Lizenzklassen-Übergänge formal prüfen (R1→R2→R3→R4, LZF-Sonderfall)
|
||||
- [ ] FEI-Kategorien-Mapping auf ÖTO-Lizenzklassen vervollständigen
|
||||
- [ ] Enums in KMP-Modul `core:domain` als SSoT festlegen
|
||||
|
||||
- [ ] **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
|
||||
- [ ] **C-3** | Compliance-Dokumentation: Series-Context vorbereiten
|
||||
- [ ] Regelwerk-Grundlagen für Cups/Serien/Meisterschaften recherchieren
|
||||
- [ ] Anforderungen an konfigurierbare Reglements (Phase 2+) dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Meine Aufgabe | Blockiert / Ermöglicht wen |
|
||||
|---------------------------------------|--------------------------------------------------|
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 👷 Backend: serverseitige Validierung (Blocker) |
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 🎨 Frontend: Live-Feedback in Dialogen (Blocker) |
|
||||
| Validierungs-Spezifikation (A-1) v0.3 | 🧐 QA: Testfälle für Validierung |
|
||||
| Abteilungs-Zwangsteilungsregeln (A-2) | 👷 Backend: `Bewerb.validate()` (Blocker) |
|
||||
| Funktionärs-Qualifikationen (C-2) | 👷 Backend: Enum-Implementierung |
|
||||
| Meine Aufgabe | Blockiert wen |
|
||||
|-------------------------|---------------------------------------------------|
|
||||
| B-2 Spec an Backend | 👷 Backend: A-3 Sonderregeln, B-3 ÖTO-Validierung |
|
||||
| B-1 ✅ Spec an Frontend | 🎨 Frontend: B-3 Live-Validierung |
|
||||
| C-1 AltersklasseRechner | 🧐 QA: C-3 Validierungs-Tests |
|
||||
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-2 Backend-Übergabe** — Lizenz-/Altersmatrix als Regulation-as-Data an Backend übergeben; Backend wartet auf diese
|
||||
Spezifikation für A-3 und B-3.
|
||||
2. **Lizenz×Bewerb DRAFT → STABLE** — Fachfreigabe einholen, damit Backend und Frontend auf stabiler Basis arbeiten
|
||||
können.
|
||||
3. **C-1 AltersklasseRechner** — Grenzfälle (Jahrgang, Stichtag) sind komplex und müssen vor Backend-Implementierung
|
||||
spezifiziert sein.
|
||||
|
||||
Reference in New Issue
Block a user