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
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:
@@ -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.
|
||||
Reference in New Issue
Block a user