docs(roadmaps): add sprint execution order and detailed role-specific roadmaps
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled

- 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>
This commit is contained in:
2026-04-02 14:35:40 +02:00
parent 1a695df60b
commit 7e16b3f318
15 changed files with 1588 additions and 0 deletions
@@ -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 (R1R4, 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 |