docs: add domain workshop agenda and session log for SQLite worker fix

- Added detailed agenda for the domain workshop kickoff under `docs/03_Domain/03_Analysis/Domain_Workshop_Agenda.md`.
- Logged session details for resolving the SQLite worker 404 issue under `docs/99_Journal/2026-03-16_Session_Log_Fix_SQLite_Worker.md`.
- Enhanced `sqlite-config.js` to include a new fallback strategy for better resilience.

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

docs/03_Domain/03_Analysis/Domain_Workshop_Agenda.md

@@ -0,0 +1,36 @@
+# ToDo-Liste: Domain Workshop (Kick-off)
+
+**Datum:** Heute Abend
+**Teilnehmer:** Owner (Fachexperte), 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert]
+
+## Ziel des Abends
+
+Start der fachlichen Klärung (Phase 3). Definition des ersten Kernprozesses, um die Basis für die Feature-Entwicklung zu
+schaffen.
+
+## Agenda & ToDos
+
+### 1. Auswahl des Einstiegs-Themas
+
+*Entscheidung treffen, mit welchem Bounded Context wir starten:*
+
+- [ ] **Option A: Stammdaten & Akteure**
+  *Was definiert ein Pferd, einen Reiter, einen Verein? (Fokus auf OEPS-IDs, Lizenzen, Startkarten).*
+- [ ] **Option B: Turnier- & Bewerbsstruktur**
+  *Wie ist ein Turnier aufgebaut? (Kategorien, Bewerbe, Abteilungen, Richtverfahren).*
+- [ ] **Option C: Der Nennungsprozess**
+  *Der Kern-Workflow: Wie meldet ein Reiter ein Pferd an? Welche Validierungen (Sperrlisten, Lizenzen) greifen hier?*
+
+### 2. Durchführung des Workshops (am gewählten Thema)
+
+- [ ] **Prozess-Skizzierung:** Der Owner beschreibt den fachlichen Ablauf aus der Praxis.
+- [ ] **Regel-Check:** Der 📜 *[ÖTO/FEI Rulebook Expert]* prüft den skizzierten Ablauf live gegen das hinterlegte
+  ÖTO-2026-Regelwerk und weist auf Edge-Cases hin.
+- [ ] **Modellierung:** Der 🏗️ *[Lead Architect]* leitet daraus die ersten Entwürfe für Aggregates und Entitäten ab.
+
+### 3. Abschluss & Übergabe
+
+- [ ] **Festhalten der Ergebnisse:** Dokumentation der getroffenen Definitionen im Ordner
+  `docs/03_Domain/01_Core_Model/`.
+- [ ] **Übergabe an QA & UX:** Auftrag an den *QA Specialist* (für Gherkin-Szenarien) und den *UI/UX Designer* (für
+  Wireframes) basierend auf den Ergebnissen des Abends erteilen.

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

@@ -0,0 +1,49 @@
+# 👷 Session Log: Fix SQLite Worker 404
+
+**Datum:** 2026-03-16
+**Agent:** Backend Developer / DevOps Engineer
+**Status:** ✅ Abgeschlossen
+
+## Problem
+
+Die Web-App schlug beim Start mit folgendem Fehler fehl:
+
+```
+sqlite.worker.js:1 Uncaught SyntaxError: Unexpected token '<'
+Error initializing database schema: WebWorkerException
+```
+
+Der Browser erhielt beim Laden von `sqlite.worker.js` eine HTML-Fehlerseite (404) statt der JavaScript-Datei — daher der
+`Unexpected token '<'`-Fehler.
+
+## Root Cause
+
+`sqlite.worker.js` lag in `frontend/core/local-db/src/jsMain/resources/` und wurde via `CopyWebpackPlugin` in
+`sqlite-config.js` in den Build-Output kopiert. **Kotlin/JS kopiert Ressourcen aus Abhängigkeits-Modulen jedoch nicht
+automatisch** in den Output des Shell-Moduls (`meldestelle-portal`). Die `CopyWebpackPlugin`-Konfiguration griff nicht
+zuverlässig, sodass die Datei im finalen `productionExecutable`-Verzeichnis fehlte.
+
+## Fix
+
+`sqlite.worker.js` direkt in das Shell-Modul kopiert:
+
+```
+frontend/shells/meldestelle-portal/src/jsMain/resources/sqlite.worker.js
+```
+
+Kotlin/JS kopiert alle Ressourcen aus diesem Verzeichnis automatisch in den Build-Output — ohne Abhängigkeit von
+`CopyWebpackPlugin`.
+
+## Verifikation
+
+- `./gradlew :frontend:shells:meldestelle-portal:jsBrowserDistribution` → BUILD SUCCESSFUL
+- `sqlite.worker.js` im Output: `build/dist/js/productionExecutable/sqlite.worker.js` ✅
+- Docker Image neu gebaut und Container neu gestartet
+- `curl http://localhost:4000/sqlite.worker.js` → `200 text/javascript` ✅
+
+## Geänderte Dateien
+
+| Datei                                                                      | Änderung                                                          |
+|----------------------------------------------------------------------------|-------------------------------------------------------------------|
+| `frontend/shells/meldestelle-portal/src/jsMain/resources/sqlite.worker.js` | Neu hinzugefügt (Kopie aus `local-db`)                            |
+| `frontend/shells/meldestelle-portal/webpack.config.d/sqlite-config.js`     | Strategy D (processedResources) als zusätzlicher Fallback ergänzt |

frontend/shells/meldestelle-portal/webpack.config.d/sqlite-config.js

@@ -56,6 +56,8 @@ const pathB = path.resolve(process.cwd(), '../../core/local-db/src/jsMain/resour
 
 // Strategy C: Hardcoded fallback based on typical structure
 const pathC = path.resolve(__dirname, '../../../../core/local-db/src/jsMain/resources/sqlite.worker.js');
+// Strategy D: From processedResources of local-db module (Kotlin/JS build output)
+const pathD = path.resolve(__dirname, '../../../../core/local-db/build/processedResources/js/main/sqlite.worker.js');
 
 let workerSourcePath = null;
 
@@ -68,11 +70,15 @@ if (fs.existsSync(pathA)) {
 } else if (fs.existsSync(pathC)) {
   workerSourcePath = pathC;
   console.log("Found sqlite.worker.js at (Strategy C):", pathC);
+} else if (fs.existsSync(pathD)) {
+  workerSourcePath = pathD;
+  console.log("Found sqlite.worker.js at (Strategy D - processedResources):", pathD);
 } else {
   console.error("ERROR: Could not find sqlite.worker.js in any expected location!");
   console.error("Checked A:", pathA);
   console.error("Checked B:", pathB);
   console.error("Checked C:", pathC);
+  console.error("Checked D:", pathD);
 }
 
 if (workerSourcePath) {