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>

docs/99_Journal/2026-03-16_Session_Log_QA_Readiness.md

@@ -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).