docs: add session logs for comprehensive readiness analyses across all domains

- Added detailed session logs under `docs/99_Journal/` for Backend, Frontend, UI/UX, QA, Documentation, and Architectural readiness. - Documented findings, recommendations, and next steps for each domain to ensure alignment before starting "Phase 3: Feature Development." - Captured key architectural decisions and the need for validated domain models and UI/UX specifications. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-03-16 13:03:27 +01:00
parent 38875a1040
commit 0ca10c7820
7 changed files with 361 additions and 0 deletions
@@ -0,0 +1,57 @@
+# Session Log: Architektonische Gesamtbewertung & Freigabe Phase 3
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🏗️ [Lead Architect] in Zusammenarbeit mit 🧹 [Curator]
+**Typ:** Architektur-Entscheidung & Meilenstein-Review
+
+## 1. Executive Summary
+
+Als Lead Architect habe ich die tiefgehenden Analysen aller Fachbereiche (DevOps, Backend, Frontend, UI/UX, QA, Curator)
+evaluiert, um die Bereitschaft für die "Phase 3: Feature Development" der Master Roadmap zu bewerten.
+
+**Das Ergebnis ist eindeutig:**
+
+* 🟢 **Technologie & Infrastruktur:** 100% Ready. Das Fundament ist robust, modern und produktionsnah.
+* 🔴 **Fachlichkeit & Domäne:** 0% Ready. Es existieren keine verabschiedeten Spezifikationen, Use-Cases oder UI-Flows.
+
+## 2. Zusammenfassung der Fachberichte
+
+1. **🐧 DevOps:** Infrastruktur, CI/CD und lokale Entwicklungsumgebung stehen stabil bereit. Die Dev/Prod-Parität (
+   Keycloak) ist gesichert.
+2. **👷 Backend:** DDD-Core und Spring Boot Blueprints (KMP-kompatibel) sind lauffähig, aber fachliche Implementierung
+   würde ohne Domänenmodelle zu massiven Refactorings führen.
+3. **🎨 Frontend:** KMP, Compose und Offline-First-Sync-Mechanismen sind exzellent aufgesetzt. Es fehlen jedoch
+   Datenmodelle und Wireframes.
+4. **🖌️ UI/UX:** Das Basis-Design-System steht. Es fehlen jedoch zwingend Wireframes, Benutzer-Flows und Offline-First
+   UX-Konzepte, um das alte "SuDo"-System sinnvoll abzulösen.
+5. **🧐 QA:** Test-Infrastruktur (Testcontainers, BDD-Bereitschaft) ist hervorragend. Es fehlen Akzeptanzkriterien,
+   Testdaten und "Given-When-Then"-Szenarien für TDD.
+6. **🧹 Curator:** Docs-as-Code Struktur ist sauber. Jedoch sind alle Domänen-Dokumente im `docs/03_Domain/` als "Draft"
+   markiert, was die "Single Source of Truth"-Regel verletzt.
+
+## 3. Architektonische Entscheidung (ADR)
+
+Ich bestätige das einstimmige Veto des Teams gegen einen sofortigen Start der Programmierung. Das blinde Schreiben von
+Feature-Code wird hiermit untersagt.
+
+**Wir wenden strikt das "Shift-Left" Prinzip an.** Bevor Code geschrieben wird, muss die fachliche Architektur (Domäne)
+geklärt sein.
+
+## 4. Konkreter Fahrplan (Nächste Schritte)
+
+Um die Blockade aufzulösen und Phase 3 aktiv zu schalten, ordne ich folgende Schritte an:
+
+1. **Initiierung des Domain Workshops (Lead Architect & Fachexperte):**
+  * Fokus auf Kernprozesse (z.B. Nennung, Startliste, Ergebnisse).
+  * Überführung der Drafts (`Legacy_Spec_Analysis`, `Use_Cases_Draft.md`) in finale Spezifikationen.
+2. **Parallele Ausarbeitung (QA & UI/UX):**
+  * **QA:** Definition der Akzeptanzkriterien und Gherkin-Szenarien aus den Workshop-Ergebnissen.
+  * **UI/UX:** Erstellung der Wireframes für die Kern-Flows (inkl. Offline-States) basierend auf den neuen
+    Domänenmodellen.
+3. **Dokumenten-Freigabe (Curator):**
+  * Überführung der `docs/03_Domain/` Dokumente vom Status "DRAFT" auf "ACTIVE".
+4. **Roadmap Update:**
+  * Sobald Schritte 1-3 abgeschlossen sind, wird Phase 3 in der `MASTER_ROADMAP.md` freigegeben und das
+    Entwicklungs-Team darf mit der Implementierung beginnen (Aktivierung des `entries-service`).
+
+**Fazit:** Der technische Proof of Concept ist abgeschlossen. Wir wechseln nun in den Domänen- und Spezifikations-Modus.
@@ -0,0 +1,48 @@
+# Session Log: Analyse der Backend-Bereitschaft für die Feature-Entwicklung
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator] in Zusammenarbeit mit 👷 [Backend Developer]
+**Typ:** Code- & Projekt-Review
+
+## 1. Ausgangslage
+
+Nachdem die Infrastruktur freigegeben wurde, hat der 👷 **[Backend Developer]** die aktuelle Code-Basis (`:backend`,
+`:core:core-domain`, `settings.gradle.kts`) auf ihre Bereitschaft für den Start der fachlichen Feature-Entwicklung
+geprüft.
+
+## 2. Analyse-Ergebnisse (Backend Developer)
+
+Die Analyse gliedert sich in zwei Kernbereiche: die technische Basis und die fachliche Ausrichtung.
+
+### 2.1 Technische Bereitschaft: 🟢 Exzellent
+
+Das technische Fundament ist hervorragend aufgestellt und bereit für die Produktiventwicklung:
+
+* **Domain-Driven Design (DDD) Core:** Das `:core:core-domain` Modul ist sehr sauber strukturiert. Die konsequente
+  Nutzung von Kotlin 2.3.0 `Value-Classes` (z.B. für `EntityId`, `ErrorCode` inkl. Regex-Validierung) garantiert
+  maximale Typsicherheit ohne Performance-Verlust zur Laufzeit.
+* **KMP-Kompatibilität:** Die Basis-DTOs und Serializer (wie `KotlinxInstantSerializer`) sind im `commonMain` des
+  Core-Moduls platziert. Dies ermöglicht eine reibungslose Code-Wiederverwendung für das Kotlin/JS Frontend (KMP-Ready).
+* **Service-Blaupause:** Der `ping-service` beweist, dass der aktuelle Technologie-Stack (Spring Boot 3.5.x, Security,
+  Resilience4j, Persistence, Monitoring via Zipkin/Micrometer) lauffähig verdrahtet ist. Auch die Testumgebung inkl.
+  `Testcontainers` steht bereit.
+
+### 2.2 Fachliche Bereitschaft: 🔴 Blockiert (Warten auf Architect)
+
+Trotz der technischen Einsatzbereitschaft darf die fachliche Implementierung noch nicht starten.
+
+* **Roadmap-Status:** Die `MASTER_ROADMAP.md` definiert Phase 3 (Feature Development) aktuell ganz klar als **ON HOLD**.
+* **Fehlende Domänen-Klarheit:** Es steht noch ein fundamentaler "Domain Analysis Workshop" mit dem Fachexperten aus, um
+  die Anforderungen, Aggregate und Bounded Contexts neu zu definieren.
+* **Pausierte Services:** Der für die Fachlichkeit zentrale `:backend:services:entries:entries-service` ist in der
+  `settings.gradle.kts` bewusst auskommentiert und deaktiviert.
+
+## 3. Fazit & Empfehlung
+
+Ein unüberlegter Start der Programmierung würde unweigerlich zu Code führen, der nicht der finalen Domänen-Logik
+entspricht und später aufwendig refaktorisiert werden müsste.
+
+**Nächster logischer Schritt:**
+Bevor Code geschrieben oder der `entries-service` reaktiviert wird, muss der **🏗️ [Lead Architect]** den Domain-Workshop
+leiten. Erst wenn die fachliche "Feature Roadmap" und die Kern-Domänenmodelle spezifiziert sind, erfolgt die Freigabe
+für das Backend-Team.
@@ -0,0 +1,52 @@
+# Session Log: Analyse der Dokumentations-Bereitschaft für die Feature-Entwicklung
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator]
+**Typ:** Projektdokumentations-Review
+
+## 1. Ausgangslage
+
+Als finaler Check vor dem möglichen Start der Phase 3 ("Feature Development") habe ich, der 🧹 **[Curator]**, das Projekt
+aus Sicht der Dokumentation, Wissensverwaltung ("Docs-as-Code") und Nachvollziehbarkeit analysiert.
+
+## 2. Analyse-Ergebnisse (Curator)
+
+### 2.1 Technische Dokumentations-Infrastruktur: 🟢 Hervorragend
+
+Die Basis für die Wissensverwaltung ist in einem exzellenten Zustand:
+
+* **Docs-as-Code:** Die Verzeichnisstruktur unter `/docs` ist aufgeräumt (Phase 1 der Roadmap ist abgeschlossen). Alte
+  Dokumente sind ordnungsgemäß im `_archive` abgelegt.
+* **Projekt-Journal:** Die Nachvollziehbarkeit von Architekturentscheidungen und Readiness-Checks funktioniert
+  fehlerfrei. Alle Agenten dokumentieren ihre Ergebnisse diszipliniert in `docs/99_Journal/`.
+* **Playbooks:** Die Rollen und Vorgaben der KI-Agenten unter `docs/04_Agents/Playbooks/` sind präzise und lenken das
+  Team erfolgreich.
+
+### 2.2 Fachliche Dokumentation (Single Source of Truth): 🔴 Blockiert
+
+Trotz der guten Struktur fehlt der eigentliche Inhalt für die Umsetzung:
+
+* **Domänen-Wissen als Draft:** Der Ordner `docs/03_Domain/` enthält wertvolle Vorarbeiten (z.B.
+  `Legacy_Spec_Analysis_2026-01.md`, `Use_Cases_Draft.md`), aber diese sind explizit als **"Draft"** markiert. Es gibt
+  keine final freigegebenen Spezifikationen.
+* **Keine verbindlichen Verträge:** Für die Entwickler und die QA gibt es in der Dokumentation keine freigegebenen
+  API-Contracts, Bounded Contexts oder Aggregat-Definitionen.
+* **Verletzung der Projekt-Philosophie:** Unsere Guideline lautet: *"Die Dokumentation ist die Single Source of Truth"*.
+  Solange diese "Truth" nicht formuliert ist, darf nicht programmiert werden.
+
+## 3. Fazit & Empfehlung
+
+Ich schließe mich aus dokumentarischer Sicht nahtlos allen anderen Fachbereichen an. Ein Start der Implementierung ohne
+vorherige Festschreibung der Domäne würde das "Docs-as-Code"-Prinzip untergraben.
+
+**Nächste Schritte & Fahrplan (Empfehlung des Curators):**
+
+1. **Einberufung des Lead Architects:** Der **🏗️ [Lead Architect]** muss nun aktiv werden, um den "Domain Workshop"
+   durchzuführen.
+2. **Spezifikationen finalisieren:** Die Ergebnisse des Workshops müssen von den aktuellen "Drafts" in verbindliche,
+   aktive Spezifikationen unter `docs/03_Domain/` überführt werden.
+3. **Roadmap-Update:** Sobald die fachliche Dokumentation steht, passe ich als Curator die `MASTER_ROADMAP.md` an und
+   schalte Phase 3 offiziell auf "ACTIVE".
+
+Alle Disziplinen haben nun gesprochen. Das Veto gegen einen verfrühten Code-Start ist einstimmig. Wir warten auf die
+Architektur.
@@ -0,0 +1,49 @@
+# Session Log: Analyse der Frontend-Bereitschaft für die Feature-Entwicklung
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator] in Zusammenarbeit mit 🎨 [Frontend Expert]
+**Typ:** Code- & Projekt-Review
+
+## 1. Ausgangslage
+
+Nach dem Backend-Review hat nun auch der 🎨 **[Frontend Expert]** das Kotlin Multiplatform (KMP) Frontend (
+`:frontend:core`, `:frontend:shells:meldestelle-portal`) auf seine Bereitschaft für die fachliche Implementierung hin
+untersucht.
+
+## 2. Analyse-Ergebnisse (Frontend Expert)
+
+### 2.1 Technische Bereitschaft: 🟢 Sehr gut
+
+Die Architektur ist exzellent auf die Anforderungen (insbesondere "Offline-First") vorbereitet:
+
+* **Architektur:** Saubere Modul-Trennung (`:core:auth`, `:core:network`, `:core:local-db`, `:core:sync`) und
+  funktionierendes Dependency Injection Setup via Koin im Main-Entrypoint.
+* **Offline-First Basis:** Die lokale Datenbank via SQLDelight (inkl. `WebWorkerDriver` für die Kotlin/JS Target) ist
+  voll funktionsfähig. Der abstrakte `SyncManager` im Modul `:core:sync` bietet genau die richtige Basis für den
+  Delta-Sync mit dem Backend.
+* **UI Foundation:** Das `:core:design-system` etabliert eine professionelle und einheitliche Theming-Grundlage (Farben,
+  Typografie, Material 3), die sich nahtlos in Compose Multiplatform integriert. Ein funktionierendes Basis-Routing (
+  `StateNavigationPort`) und Auth-Flows existieren bereits.
+
+### 2.2 Fachliche Bereitschaft: 🔴 Blockiert (Warten auf Architect & UX)
+
+Trotz der technischen Startklarheit fehlt die Grundlage für die eigentliche Feature-Entwicklung:
+
+* **Roadmap-Status:** Gemäß `MASTER_ROADMAP.md` ist die Phase 3 (Feature Development) weiterhin **ON HOLD**.
+* **Fehlende Spezifikationen:** Es existieren noch keine definierten Use-Cases, Datenmodelle oder API-Contracts (außer
+  Ping) für die kommenden Features.
+* **UX/UI Design:** Konkrete Wireframes, Screen-Layouts oder Benutzer-Flows für die fachlichen Screens (z.B.
+  Nennungs-Übersicht) vom 🖌️ **[UI/UX Designer]** fehlen vollständig.
+
+## 3. Fazit & Empfehlung
+
+Ein verfrühter Start im Frontend würde bedeuten, ohne klare UI-Spezifikationen oder abgestimmte Backend-APIs "ins Blaue"
+zu programmieren. Dies muss vermieden werden.
+
+**Nächster logischer Schritt:**
+Der 🎨 **[Frontend Expert]** schließt sich der Empfehlung des Backends an:
+
+1. Der **🏗️ [Lead Architect]** muss den ausstehenden Domain-Workshop durchführen.
+2. Im Anschluss (oder parallel) muss der **🖌️ [UI/UX Designer]** erste Wireframes für die neuen Features entwerfen.
+3. Erst wenn Fachlichkeit (Domain Models) und Benutzerführung (UX-Flows) definiert sind, kann die
+   Frontend-Implementierung starten.
@@ -0,0 +1,50 @@
+# Session Log: Infrastruktur-Analyse & Freigabe
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator] in Zusammenarbeit mit 🐧 [DevOps Engineer]
+**Typ:** Infrastruktur-Review / Architektur-Entscheidung
+
+## 1. Ausgangslage
+
+Vor dem Start der fachlichen Implementierung wurde der 🐧 **[DevOps Engineer]** beauftragt, einen tiefgehenden Pre-Flight
+Check der lokalen Docker-Infrastruktur (`docker-compose.yaml` und Teil-Dateien) durchzuführen. Ziel war es
+sicherzustellen, dass das "Docs-as-Code" Setup robust, fehlerfrei und bereit für den Entwicklungsalltag ist.
+
+## 2. Analyse-Ergebnisse
+
+Das Setup (unterteilt in `dc-infra.yaml`, `dc-backend.yaml`, `dc-gui.yaml` und `dc-ops.yaml`) wurde als sehr robust und
+durchdacht bewertet.
+Folgende positive Aspekte wurden hervorgehoben:
+
+* **Abhängigkeitsmanagement:** Exzellente Nutzung von `depends_on` mit `condition: service_healthy` (z.B. Backend wartet
+  auf Postgres und Keycloak).
+* **Zentrale Konfiguration:** Erfolgreiche Einbindung von `config/app/base-application.yaml` via Volumes in die Spring
+  Boot Container.
+* **Monitoring & Tools:** Das Ops-Profil bietet ein umfassendes Toolset (Mailpit, pgAdmin, Prometheus, Grafana).
+
+### Identifizierter Klärungsbedarf (DevOps Perspektive)
+
+Der **DevOps Engineer** wies auf eine Abweichung von den dokumentierten Leitlinien für die lokale Entwicklung hin:
+
+* **Keycloak Setup:** Laut Playbook sollte für die lokale Entwicklung das offizielle Image (`quay.io/keycloak/keycloak`)
+  im schnellen `start-dev` Modus laufen.
+* **Ist-Zustand:** Die `dc-infra.yaml` nutzt ein lokales Dockerfile (`config/docker/keycloak/Dockerfile`), führt einen
+  Build-Step (`kc.sh build`) aus und startet den Container im produktionsnahen `--optimized` Modus.
+
+## 3. Architekturentscheidung (Owner)
+
+Der **Owner** wurde über die Abweichung beim Keycloak-Setup informiert und hat folgende architektonische Entscheidung
+getroffen:
+
+* **Entscheidung:** Das aktuelle, produktionsnahe Keycloak-Setup (`build` + `start --optimized`) bleibt unverändert
+  bestehen. Es wird **nicht** auf den reinen `start-dev` Modus zurückgebaut.
+* **Begründung:** Da die Entwicklung direkt auf dem `main`-Branch stattfindet, hat die **Dev/Prod-Parität** höchste
+  Priorität. Die lokale Umgebung soll so nah wie möglich an der späteren Produktionsumgebung (Zora) bleiben. Eine leicht
+  erhöhte initiale Build-Zeit des Containers wird zugunsten von maximaler Stabilität und Vorhersehbarkeit (Vermeidung
+  von "works on my machine" Problemen) in Kauf genommen.
+
+## 4. Fazit & Nächste Schritte
+
+* Die Infrastruktur-Analyse ist abgeschlossen.
+* Das aktuelle Setup ist offiziell für die nächste Phase freigegeben.
+* Das Team kann nun mit der fachlichen Implementierung (Backend/Frontend) beginnen.
@@ -0,0 +1,51 @@
+# Session Log: Analyse der QA-Bereitschaft für die Feature-Entwicklung
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator] in Zusammenarbeit mit 🧐 [QA Specialist]
+**Typ:** Code- & Projekt-Review
+
+## 1. Ausgangslage
+
+Nach den Analysen der Bereiche DevOps, Backend, Frontend und UI/UX hat der 🧐 **[QA Specialist]** das Projekt
+hinsichtlich Testbarkeit, Test-Infrastruktur und "Shift-Left"-Qualitätssicherung bewertet.
+
+## 2. Analyse-Ergebnisse (QA Specialist)
+
+### 2.1 Technische Test-Infrastruktur: 🟢 Hervorragend
+
+Das Projekt bietet eine exzellente Basis für eine moderne Test-Pyramide:
+
+* **Zentrales Test-Modul:** Das Modul `:platform:platform-testing` bündelt alle wichtigen Test-Abhängigkeiten (JUnit 5,
+  AssertJ, MockK). Das sorgt für Konsistenz und vermeidet Versionskonflikte.
+* **Integration Testing Setup:** Die Einbindung von `Testcontainers` (PostgreSQL, Keycloak, Kafka) ist vorhanden. Dies
+  ermöglicht deterministische Integrationstests gegen echte Infrastruktur-Komponenten, statt wackeliger Mocks.
+* **Multiplatform Ready:** Die Test-SourceSets im `:core-domain` Modul sind für Kotlin Multiplatform (JVM, JS) korrekt
+  vorbereitet.
+
+### 2.2 Fachliche Test-Spezifikation (Shift-Left): 🔴 Blockiert
+
+Wie in den anderen Disziplinen fehlt die fachliche Grundlage:
+
+* **Fehlende Akzeptanzkriterien:** Es existieren keine Use-Cases oder konkreten "Definition of Done" Kriterien für die
+  anstehenden Features.
+* **Keine BDD-Szenarien:** Es gibt keine "Given-When-Then" (Gherkin) Spezifikationen, gegen die die Entwickler fachliche
+  Tests (TDD) schreiben könnten.
+* **Testdaten-Mangel:** Da das finale Domain-Modell noch unklar ist, können noch keine realistischen Testdaten (
+  Mock-Objekte für Turniere, Nennungen etc.) definiert werden.
+
+## 3. Fazit & Empfehlung
+
+Ein sofortiger Implementierungsstart würde zu "technisch grünen", aber fachlich nutzlosen Tests führen. Die
+Qualitätssicherung muss "Shift-Left" betrieben werden – also weit vor der ersten Zeile Feature-Code.
+
+**Nächste Schritte & Fahrplan (Empfehlung des QA Specialists):**
+
+1. **Teilnahme am Domain Workshop:** Der QA Specialist muss in den anstehenden Workshop des **🏗️ [Lead Architect]**
+   integriert werden.
+2. **Szenario-Definition:** Parallel zur Definition der Use-Cases durch den Architekten müssen die Akzeptanzkriterien
+   als Gherkin-Szenarien (Given-When-Then) dokumentiert werden.
+3. **Edge-Cases aufdecken:** Im Workshop sollen Randfälle (z.B. "Was passiert bei einer Nennung ohne gültige Lizenz?")
+   identifiziert und als Test-Szenarien festgehalten werden.
+
+Erst wenn diese fachlichen Test-Szenarien als Verträge existieren, dürfen die Entwickler mit der Implementierung
+beginnen, um diese Verträge technisch zu erfüllen (Test-Driven Development Ansatz).
@@ -0,0 +1,54 @@
+# Session Log: Analyse der UI/UX-Bereitschaft für die Feature-Entwicklung
+
+**Datum:** 16. März 2026
+**Verantwortlicher Agent:** 🧹 [Curator] in Zusammenarbeit mit 🖌️ [UI/UX Designer]
+**Typ:** Code- & Projekt-Review
+
+## 1. Ausgangslage
+
+Nach den positiven technischen Reviews durch das Backend- und Frontend-Team hat der 🖌️ **[UI/UX Designer]** das Projekt
+hinsichtlich der User Experience und Design-Bereitschaft analysiert. Der Fokus lag auf dem Zusammenspiel zwischen den
+technischen Möglichkeiten, den alten System-Referenzen und den zukünftigen Anforderungen.
+
+## 2. Analyse-Ergebnisse (UI/UX Designer)
+
+### 2.1 Technische Design-Basis: 🟢 Gut
+
+Die technische Umsetzung der grundlegenden Design-Sprache ist bereits im Frontend-Code verankert:
+
+* **Design System (`AppTheme.kt`):** Ein starkes, "Enterprise-taugliches" Theme (Material 3) ist implementiert. Es
+  definiert Farbpaletten, Kontraste (inkl. Dark Mode) und Typografie-Hierarchien. Dies stellt sicher, dass neue
+  Komponenten konsistent und professionell aussehen werden.
+* **Technologie (Compose):** Compose Multiplatform bietet die perfekte Basis, um hochgradig reaktive und responsive
+  Interfaces schnell zu entwickeln.
+
+### 2.2 Fachliche UI/UX-Spezifikation: 🔴 Blockiert (Wireframes & Flows fehlen)
+
+Die visuelle und konzeptionelle Ausarbeitung der eigentlichen Features fehlt komplett:
+
+* **Fehlende UX-Flows:** Es gibt keine definierten Benutzerpfade. Es ist unklar, wie Nutzer durch die Kernprozesse (z.B.
+  Nennungen anlegen, Startlisten prüfen) navigieren sollen.
+* **Umgang mit Legacy-Screenshots:** Die Bilder des alten "SuDo"-Systems (unter `docs/BilderSuDo/`) sind wertvolle
+  Referenzen für die Datenpunkte, **dürfen aber nicht 1:1 nachgebaut werden**. Das neue UI muss entschlackt, fokussiert
+  und intuitiver gestaltet werden ("Fokus auf den Sport").
+* **Offline-First UX:** Ein entscheidender Aspekt fehlt: Das Interface-Design muss klar kommunizieren, ob der Nutzer
+  offline ist, ob Daten synchronisiert werden oder ob es Sync-Konflikte gibt. Diese speziellen UI-Muster müssen erst
+  gestaltet werden.
+
+## 3. Fazit & Empfehlung
+
+Ein Start der UI-Programmierung ohne vorherige Design-Spezifikationen würde unweigerlich zu einer unstrukturierten
+Benutzeroberfläche ("Datenbank-Felder aufs UI klatschen") und damit zu einer schlechten User Experience führen.
+
+**Nächste Schritte & Fahrplan (Empfehlung des UI/UX Designers):**
+
+1. **Domain Workshop:** Teilnahme (passiv) am ausstehenden Workshop des **🏗️ [Lead Architect]**, um die Fachlichkeit und
+   die notwendigen Datenpunkte zu verstehen.
+2. **Wireframing:** Erstellung von aufgeräumten, responsiven Wireframes (Mobile & Desktop) für die Kern-Flows (z.B.
+   Nennung, Startliste) basierend auf den neuen Modellen und unter zur Hilfenahme der SuDo-Screenshots als fachliche
+   Orientierung.
+3. **Frontend-Abstimmung:** Review der Wireframes mit dem **🎨 [Frontend Expert]**, insbesondere hinsichtlich der
+   Offline-UX-Konzepte.
+
+Erst nach der Freigabe der Wireframes für einen spezifischen Bounded Context sollte das Frontend-Team mit der
+Implementierung der Screens beginnen.