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:40 +02:00
parent 1a695df60b
commit 7e16b3f318
15 changed files with 1588 additions and 0 deletions
@@ -0,0 +1,167 @@
+🏗️ **[Lead Architect]** — Besprechungsprotokoll | Meldestelle-Biest | 2. April 2026
+
+---
+
+### 📋 Anwesenheit & Vorbereitung
+
+| Agent                | Anwesend | Report vorliegend |
+|----------------------|----------|-------------------|
+| 🏗️ Lead Architect   | ✅        | ✅                 |
+| 👷 Backend Developer | ✅        | ✅                 |
+| 🎨 Frontend Expert   | ✅        | ✅                 |
+| 🐧 DevOps Engineer   | ✅        | ✅                 |
+| 🧐 QA Specialist     | ✅        | ✅                 |
+| 📜 Rulebook Expert   | ✅        | ✅                 |
+| 🖌️ UI/UX Designer   | ✅        | ✅                 |
+| 🧹 Curator           | ✅        | ✅                 |
+
+**Alle Entwickler sind anwesend und haben ihre Reports eingereicht. Die Besprechung kann beginnen.**
+
+---
+
+### 📊 Übersicht: Wo stehen wir?
+
+Das Projekt hat in den letzten Tagen starken Momentum im **Frontend** (V2-Screens, Event-First-Workflow, Navigation mit
+Back-Stack) aufgebaut. Die Desktop-App nimmt konkrete Form an. Gleichzeitig haben sich **drei kritische Schulden**
+aufgebaut, die jetzt adressiert werden müssen, bevor wir weiter bauen:
+
+1. **Frontend-Architektur-Schulden:** Business-Logik liegt direkt in den Composables (`StoreV2`-Aufrufe, lokaler
+   `remember`-State). Ohne ViewModel-Refactoring wird der Code bald unwartbar.
+2. **Backend fehlt als Fundament:** Das Frontend läuft auf einem Mock-Store. Echte CRUD-Endpunkte und Tenant-Isolation
+   fehlen vollständig.
+3. **Validierung ist ein Sicherheitsloch:** FEI-IDs, OEPS-Nummern und Lizenzklassen können aktuell als beliebige Strings
+   gespeichert werden — das verletzt ÖTO/FEI-Compliance.
+
+**Kernaussage der Besprechung:** Wir müssen jetzt das Fundament stärken, bevor wir neue Features bauen.
+
+---
+
+### 🎯 Strategie: Die 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
+```
+
+Wir arbeiten **in dieser Reihenfolge** — Säule 1 blockiert Säule 2, Säule 2 blockiert Säule 3.
+
+---
+
+### 📅 Reihenfolge der nächsten Entwicklungsschritte
+
+#### 🔴 Sprint A — Sofort (diese Woche)
+
+**Ziel: Das Fundament stabilisieren, damit alle anderen aufbauen können.**
+
+| #   | Wer           | Aufgabe                                                                                                                  |
+|-----|---------------|--------------------------------------------------------------------------------------------------------------------------|
+| A-1 | 🏗️ Architect | Tenant-Resolution-Strategie entscheiden (Schema-per-Tenant vs. Tenant-ID in allen Tabellen) — **Ergebnis: ADR-0021**     |
+| A-2 | 🎨 Frontend   | ViewModel-Architektur definieren und `VeranstalterViewModel` als Referenz-Implementierung (MVVM/UDF) umsetzen            |
+| A-3 | 👷 Backend    | Tenant-Isolation im Datenzugriffs-Layer implementieren auf Basis von ADR-0021                                            |
+| A-4 | 🧹 Curator    | `docs/01_Architecture/` mit Event-First-Workflow, Navigation-V2 und Tenant-Konzept dokumentieren                         |
+| A-5 | 📜 Rulebook   | Validierungsregeln für OEPS-Nummern, FEI-IDs und Lizenzklassen (R1–R4) schriftlich spezifizieren — als Grundlage für A-6 |
+
+> ⚠️ **A-1 (ADR-0021) ist ein Blocker für A-3!** Der Architect liefert zuerst.
+
+---
+
+#### 🟠 Sprint B — Kurzfristig (nächste Woche)
+
+**Ziel: Frontend und Backend verbinden, Validierung implementieren.**
+
+| #   | Wer                       | Aufgabe                                                                                                                                |
+|-----|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------|
+| B-1 | 👷 Backend                | CRUD-Endpunkte für Veranstalter, Veranstaltungen, Reiter, Pferde, Vereine, Funktionäre implementieren                                  |
+| B-2 | 🎨 Frontend               | ViewModels für alle V2-Screens umsetzen (`PferdProfilViewModel`, etc.) und Ktor-Clients/Repositories für Backend-Anbindung vorbereiten |
+| B-3 | 📜 Rulebook + 🎨 Frontend | Validierungslogik aus Sprint A-5 als Live-Feedback in V2-Edit-Dialogen implementieren                                                  |
+| B-4 | 📜 Rulebook + 👷 Backend  | Dieselbe Validierungslogik serverseitig absichern                                                                                      |
+| B-5 | 🖌️ UI/UX                 | UX-Konzept für Editier-Formulare überarbeiten: AlertDialog vs. dedizierter Screen / Sliding-Panel — **Ergebnis: Wireframes**           |
+| B-6 | 🧐 QA                     | Test-Suite für V2-Navigation und Back-Stack aufbauen; Edge-Cases für Onboarding/Wizard (leere Felder, schnelles Klicken, Abbrechen)    |
+| B-7 | 🐧 DevOps                 | CI/CD Pipeline für Compose-Desktop-Tests headless konfigurieren (GitHub/Gitea Actions)                                                 |
+
+---
+
+#### 🟡 Sprint C — Mittelfristig (in 2 Wochen)
+
+**Ziel: Ausliefern, offline-fähig machen, aufräumen.**
+
+| #   | Wer           | Aufgabe                                                                                                                 |
+|-----|---------------|-------------------------------------------------------------------------------------------------------------------------|
+| C-1 | 🐧 DevOps     | Desktop-App-Packaging konfigurieren (`.msi` / `.deb` / `.dmg`) via `compose.desktop.nativeDistributions`                |
+| C-2 | 🏗️ Architect | Synchronisations-Protokoll-Konzeption starten (Event-Sourcing vs. CRDT vs. Timestamp-Sync)                              |
+| C-3 | 👷 Backend    | Testdaten-Seeder implementieren (reproduzierbare Turnier-, Nennungs- und Stammdaten)                                    |
+| C-4 | 🧐 QA         | Testfälle für Mandanten-Isolation (Daten strikt zwischen Veranstaltungen getrennt)                                      |
+| C-5 | 🖌️ UI/UX     | Wireframes aus B-5 implementieren; Empty States für alle Listenansichten designen und umsetzen                          |
+| C-6 | 📜 Rulebook   | `AltersklasseRechner` vollständig gegen ÖTO 2026 testen; Funktionärs-Qualifikationen auf Enum umstellen                 |
+| C-7 | 🧹 Curator    | `README.md` und Setup-Guide aktualisieren; Unterordner-Struktur für `docs/` einführen; V1-Code-Bereinigung koordinieren |
+| C-8 | 🏗️ Architect | `MASTER_ROADMAP.md` aktualisieren (Desktop-Fokus, Tenant-Isolation, Offline-Sync-Meilensteine)                          |
+| C-9 | 🐧 DevOps     | Semantic Versioning Strategie einführen; koordiniertes Release-Tagging Client + Server                                  |
+
+---
+
+### 📌 Individuelle Arbeitsaufträge (Zusammenfassung)
+
+#### 🏗️ Lead Architect
+
+1. **[A-1, sofort]** ADR-0021 schreiben: Tenant-Resolution-Strategie entscheiden
+2. **[C-2]** Sync-Protokoll-Konzept starten
+3. **[C-8]** MASTER_ROADMAP aktualisieren
+
+#### 👷 Backend Developer
+
+1. **[A-3, nach ADR-0021]** Tenant-Isolation im Datenzugriffs-Layer
+2. **[B-1]** CRUD-APIs für alle Stammdaten-Entitäten
+3. **[B-4]** ÖTO-Validierung serverseitig absichern
+4. **[C-3]** Testdaten-Seeder
+
+#### 🎨 Frontend Expert
+
+1. **[A-2, sofort]** ViewModel-Referenz-Implementierung (`VeranstalterViewModel`, MVVM/UDF)
+2. **[B-2]** Alle V2-ViewModels + Ktor-Client-Repositories
+3. **[B-3]** Validierungs-Live-Feedback in Edit-Dialogen
+
+#### 🐧 DevOps Engineer
+
+1. **[B-7]** CI/CD für Compose Desktop Tests (headless)
+2. **[C-1]** Desktop-App Packaging (Distributionen)
+3. **[C-9]** Semantic Versioning + Release-Strategie
+
+#### 🧐 QA Specialist
+
+1. **[B-6, parallel zu Sprint B]** Test-Suite Navigation/Back-Stack + Onboarding-Edge-Cases
+2. **[C-4]** Mandanten-Isolations-Testfälle
+
+#### 📜 ÖTO/FEI Rulebook Expert
+
+1. **[A-5, sofort]** Validierungsregeln schriftlich spezifizieren (OEPS, FEI-ID, Lizenzklassen)
+2. **[B-3/B-4]** Implementierung der Validierung Frontend + Backend begleiten
+3. **[C-6]** AltersklasseRechner vollständig testen; Funktionärs-Qualifikationen als Enum
+
+#### 🖌️ UI/UX Designer
+
+1. **[B-5]** Wireframes: Dialog vs. Fullscreen-Edit entscheiden
+2. **[C-5]** Wireframes implementieren + Empty States designen und umsetzen
+
+#### 🧹 Curator
+
+1. **[A-4, sofort]** Event-First-Workflow + Navigation-V2 + Tenant-Konzept dokumentieren
+2. **[C-7]** README + Setup-Guide + Docs-Struktur + V1-Code-Bereinigung koordinieren
+
+---
+
+### ✅ Beschlüsse dieser Besprechung
+
+1. **ADR-0021 (Tenant-Resolution)** wird sofort vom Architect erstellt — es ist der wichtigste Blocker.
+2. **ViewModel-Architektur** wird vor neuen Features eingeführt — kein weiterer Code ohne ViewModel.
+3. **Kein neues Feature ohne ÖTO-Validierung** — Rulebook Expert gibt die Spezifikation vor, Backend + Frontend setzen
+   sie gemeinsam um.
+4. **Mock-Store (`StoreV2`) ist temporär** — Ziel von Sprint B ist die vollständige Ablösung durch echte
+   Backend-Anbindung.
+5. **MASTER_ROADMAP** wird am Ende von Sprint C durch den Architect aktualisiert.
+
+---
+
+> 🏁 **Alle Entwickler wissen, was sie wann zu tun haben. Wir ziehen an einem Strang. Sprint A beginnt jetzt.**