mocode-software/meldestelle

Files

T

stefan 7e16b3f318

Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled

Details

Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled

Details

Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled

Details

Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled

Details

docs(roadmaps): add sprint execution order and detailed role-specific roadmaps

- 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 <stefan.mo.co@gmail.com>

2026-04-02 14:35:54 +02:00

4.5 KiB

Raw Blame History

👷 [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