docs(reports): add comprehensive status and recommendation reports for key roles

- Created and saved detailed reports for Frontend, Backend, UI/UX, Architecture, DevOps, QA, Rulebook, and Curation in `docs/90_Reports/`.
- Included prioritized action items, challenges, and next steps across disciplines.
- Addressed documentation gaps and organized steps for improving workflow consistency and validation across the stack.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

docs/90_Reports/2026-04-02_Architect_Report.md

@@ -0,0 +1,41 @@
+# 🏗️ [Lead Architect] Report - 2. April 2026
+
+## 1. Aktueller Status
+
+Das Projekt hat durch die "Event-First"-Philosophie (Initialisierung einer spezifischen Datenbank pro Veranstaltung) und
+die fokussierte Compose-Desktop-Entwicklung (V2-Screens) eine deutliche Richtung eingenommen. Die
+Architekturentscheidung (ADR-0020) bezüglich LAN-Isolation und Mandantenfähigkeit (Tenant-per-Event) beginnt sich im
+Code (lokaler State, Event-bezogene Stores) niederzuschlagen, muss aber zwingend im Backend nachgezogen werden.
+
+## 2. Empfehlungen & Prioritäten
+
+**🔴 P1: Mandantenfähigkeit (Tenant Isolation) im Backend verankern**
+
+* *Warum:* Das Frontend plant für jedes Event eine "eigene Datenbank". Das Backend läuft derzeit noch als klassischer
+  Monolith ohne harte Isolation der Veranstaltungsdaten (Nennungen, Prüfungen, Starterlisten). Wenn wir dies jetzt nicht
+  architektonisch sauber im Backend (z.B. über Schema-per-Tenant oder Tenant-IDs in allen Tabellen) lösen, bauen wir
+  enorme technische Schulden auf.
+* *Aktion:* Definition der Tenant-Resolution-Strategie für Ktor/Spring Boot (wie erkennt das Backend, auf welche
+  Event-Datenbank eine Anfrage zielt?). Umsetzung im Datenzugriff-Layer.
+
+**🔴 P1: State-Management-Architektur für Compose (MVI/MVVM)**
+
+* *Warum:* Der aktuelle Frontend-Code mischt UI-Deklaration und Business-Logik (`StoreV2` Aufrufe direkt in den
+  `onSaved`-Callbacks, viel lokaler `remember`-State). Bei steigender Komplexität (z.B. Nennungssystem) wird dies
+  unwartbar.
+* *Aktion:* Verbindliche Festlegung auf ein Architekturmuster für das KMP/Compose Frontend (z.B. striktes MVVM mit UDF -
+  Unidirectional Data Flow). Auslagern des Status in `ViewModels` und Definition klarer `Intent`/`State` Klassen für die
+  V2-Screens.
+
+**🟠 P2: Synchronisations-Protokoll (Offline-First/LAN)**
+
+* *Warum:* Die Meldestelle muss offline auf Turnieren funktionieren.
+* *Aktion:* Start der Konzeptionsphase für das Daten-Synchronisations-Protokoll zwischen der Master-Datenbank (Backend)
+  und den lokalen Client-Datenbanken (Desktop). Entscheidung zwischen Event-Sourcing, CRDTs oder simplen
+  Timestamp-basierten Sync-Ansätzen.
+
+**🟡 P3: Master-Roadmap Update**
+
+* *Warum:* Die jüngsten Entwicklungen haben die Prioritäten verschoben.
+* *Aktion:* Aktualisierung der `MASTER_ROADMAP.md` in `docs/01_Architecture/`, um den Fokus auf die Desktop-App, die
+  Tenant-Isolation und die anstehenden Offline-Sync-Meilensteine widerzuspiegeln.