🏗️ **[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.**