meldestelle/docs/temp/2026-04-02_Besprechung/Meldestelle_Besprechung!_Wir_berufen_di.md

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