mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
14b458860c
meldestelle/docs/04_Agents/Roadmaps/Rulebook_Roadmap.md
Stefan Mogeritsch 14b458860c feat(validation): integrate ÖTO/FEI rule validations and centralized validators 
- Added `OetoValidators` with live-validation for OEPS numbers, FEI-IDs, license classes, and horse data to align with ÖTO/FEI 2026 standards.
- Expanded `ReiterProfilViewModel` and `PferdProfilViewModel` to include validation states (`ValidationResult`) for enhanced form feedback and dirty state tracking.
- Standardized mock data in `Stores.kt` and `NennungModels.kt` to comply with updated validation rules.
- Created `OetoValidatorsTest` to ensure validation logic accuracy (30 unit tests, all green).
- Updated `build.gradle.kts` to include `kotlin.test` dependency for JVM testing.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-03 09:04:12 +02:00

6.1 KiB
Raw Blame History

📜 [ÖTO/FEI Rulebook Expert] — Schritt-für-Schritt Roadmap

Stand: 3. 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
      • Ergebnis: siehe docs/03_Domain/02_Reference/Validierungsregeln.md Abschnitt „OEPS‑Mitgliedsnummer“
    • FEI-ID
      • Gültiges Format definieren (numerisch 7–8 stellig + Legacy‑Code NNNAA NN)
      • Pflichtregel national/international festhalten (Turnierkategorie‑abhängig)
      • 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
    • Lizenzklassen (R1–R4, RD1–RD3, LZF)
      • Vollständige Liste aller gültigen Lizenzklassen
      • Erste Lizenz‑Zuordnungstabellen (Springen + Dressur) als DRAFT mit Paragraphen‑Platzhaltern
      • Ergebnis: siehe docs/03_Domain/02_Reference/Validierungsregeln.md Abschnitt „Lizenzklassen“
    • Altersklassen Pferd
      • Mindestalter je Disziplin/Klasse als DRAFT‑Tabellen (ÖTO/FEI) ergänzt
      • Berechnungsregel: Stichtag 1. Jänner des Geburtsjahres
      • Ergebnis: siehe docs/03_Domain/02_Reference/Validierungsregeln.md Abschnitt „Altersklassen Pferd“
    • Ergebnis als Dokument docs/03_Domain/02_Reference/Validierungsregeln.md ablegen (Status: DRAFT v0.3)

  • A-2 | Abteilungs-Zwangsteilungsregeln vollständig spezifizieren

    • CSN-C-NEU: Bewerb ≤95cm → ohne Lizenz | mit Lizenz (§ 231 ÖTO, Platzhalter) — spezifiziert
    • CSN-C-NEU: Bewerb ≥100cm → R1 | R2 und höher (§ 231 ÖTO, Platzhalter) — spezifiziert
    • Weitere Pflicht-Teilungsregeln geprüft: CDN, CCN — derzeit keine generische Zwangsteilung wie CSN-C-NEU identifiziert (Platzhalter‑Paragraphen nachtragen)
    • Ergebnis dokumentiert in docs/03_Domain/02_Reference/TURNIER_KLASSEN.md
    • 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).
    • Optionale Jugend-/Jahrgangsteilungen als Regel‑Modell (Regulation‑as‑Data) ergänzt, keine systemweite Pflicht.

🟠 Sprint B — Kurzfristig (nächste Woche)

  • B-1 | Validierungs-Implementierung Frontend begleiten

    • Spezifikation aus Sprint A-1 (v0.3 DRAFT) an 🎨 Frontend übergeben
    • 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)
    • 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)

  • B-2 | Validierungs-Implementierung Backend begleiten

    • 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)
    • 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) 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