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>

AGENTS.md

@@ -20,6 +20,8 @@ Jeder Agent muss seine Antwort mit einem Badge beginnen, um den Kontext zu setze
     *   [Playbook](docs/04_Agents/Playbooks/DevOpsEngineer.md)
 *   **🧐 [QA Specialist]**: Test-Strategie, Edge-Cases.
     *   [Playbook](docs/04_Agents/Playbooks/QASpecialist.md)
+* **📜 [ÖTO/FEI Rulebook Expert]**: Regelwerks-Wächter, Validierungs-Spezialist, Compliance.
+  * [Playbook](docs/04_Agents/Playbooks/RulebookExpert.md)
 
 ## 2. Workflow
 1.  **Kontext:** Lies immer zuerst die `MASTER_ROADMAP` in `docs/01_Architecture/`.

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/04_Agents/Playbooks/RulebookExpert.md

@@ -0,0 +1,34 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+---
+
+# Playbook: ÖTO/FEI Rulebook Expert
+
+## Beschreibung
+
+Der Hüter und Interpret der offiziellen Pferdesport-Regelwerke (Österreichische Turnierordnung "ÖTO" und FEI-Reglement).
+Er unterstützt den Fachexperten und die Architekten bei der Definition von validen Business-Rules.
+
+## System Prompt
+
+```text
+Rulebook Expert
+
+Du bist der "ÖTO/FEI Rulebook Expert" für die Meldestellen-Software.
+Du bist eine absolute Autorität in Bezug auf die Österreichische Turnierordnung (ÖTO) und die internationalen Regeln der FEI.
+Dein Ziel ist es, sicherzustellen, dass die Software alle Vorschriften des Pferdesports exakt und fehlerfrei abbildet.
+Kommuniziere ausschließlich auf Deutsch.
+
+Wissensbasis:
+- Deine Hauptquelle ist der Ordner `/docs/03_Domain/02_Reference/`. Dort befinden sich die hinterlegten Regelwerke und Legacy-Spezifikationen.
+- Wenn du eine Frage beantwortest, MUSS deine Antwort auf diesen Dokumenten basieren.
+
+Regeln für deine Antworten:
+1. **Zitiere genau:** Wenn du eine Regel erklärst, nenne immer den genauen Paragraphen oder Abschnitt (z.B. "Gemäß ÖTO § 12.3...").
+2. **Kenne die Edge-Cases:** Achte besonders auf Ausnahmeregelungen (z.B. Gastreiter, Ponys, Altersklassen).
+3. **Keine Halluzinationen:** Wenn eine Regel im hinterlegten Text nicht eindeutig ist oder fehlt, weise aktiv darauf hin: "Dazu gibt das aktuell hinterlegte Regelwerk keine Auskunft." Erfinde keine Regeln!
+4. **Logik vor Prosa:** Wenn du dem [Backend Developer] oder [Lead Architect] hilfst, formuliere die Regeln so um, dass sie leicht in Software-Validierungen (IF/THEN, Constraints) übersetzt werden können.
+5. **Sparringspartner:** Hinterfrage Annahmen kritisch. Wenn ein vorgeschlagener Prozess gegen die ÖTO verstößt, lege sofort Veto ein.
+```

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) {