docs(frontend): add detailed offline-first architecture and web setup documentation

Added documentation to outline the Offline-First strategy for the KMP frontend, emphasizing the use of SQLDelight with cross-platform storage. Also included guidance for setting up Web targets, covering OPFS integration and Web Worker usage. Updated ADRs with decisions for SQLDelight and Koin adoption.

docs/01_Architecture/ARCHITECTURE.md

@@ -1,8 +1,26 @@
-Repository-Architektur (MP-22)
+# Repository-Architektur (MP-22)
 
-Dieses Dokument beschreibt die Zielstruktur und das Mapping vom bisherigen Stand (Ist) zur neuen Struktur (Soll). Es begleitet Epic 2 (MP-22).
+**WARNUNG (Januar 2026): Dieses Dokument ist veraltet.** Die hier beschriebene "Soll"-Struktur wurde teilweise umgesetzt, aber wichtige strategische Änderungen sind in den Statusberichten vom Januar 2026 dokumentiert. Dieses Dokument dient nur noch als historischer Referenzpunkt.
 
-Zielstruktur (Top-Level)
+**Aktuelle Informationen finden Sie in:**
+*   `docs/90_Reports/Backend_Status_Report_01-2026.md`
+*   `docs/90_Reports/Frontend_Status_Report_01-2026.md`
+*   Den ADRs in `docs/01_Architecture/adr/`
+
+---
+
+## Zusammenfassung der wichtigsten Änderungen (Januar 2026)
+
+*   **Backend:** Ein Konflikt zwischen Spring Boot und Spring Cloud wurde durch einen Downgrade von Spring Cloud gelöst.
+*   **Frontend:** Die Persistenz-Strategie wurde von Room auf **SQLDelight** umgestellt, um echte Cross-Platform-Fähigkeit (insbesondere für Web/Wasm) zu ermöglichen.
+*   **Modul-Struktur:** Das `core:core-utils`-Modul wurde bereinigt, um eine strikte Trennung zwischen KMP-kompatiblem Code und JVM-spezifischem Code zu gewährleisten. JVM-spezifischer Code wurde in das neue Modul `:backend:infrastructure:persistence` verschoben.
+*   **Build-System:** Die `libs.versions.toml` wurde stark refaktoriert und nutzt nun Bundles zur Vereinfachung der Gradle-Dateien.
+
+---
+
+## Ursprünglicher Inhalt (Veraltet)
+
+### Zielstruktur (Top-Level)
 
 backend/   Gateway, Discovery (optional), Services
   gateway   Spring Cloud Gateway
@@ -22,7 +40,7 @@ docs/      Architektur, ADRs, C4-Modelle, Guides
   adr      Architecture Decision Records (ADRs)
   c4       C4-Diagramme (PlantUML Quellen)
 
-Ist → Soll Mapping (erste Tranche)
+### Ist → Soll Mapping (erste Tranche)
 
 - Frontend
   - clients/app → frontend/shells/meldestelle-portal (verschieben in Folge-Commit)
@@ -38,18 +56,18 @@ Ist → Soll Mapping (erste Tranche)
   - compose.yaml → docker/docker-compose.yml (neu angelegt, Makefile angepasst)
   - .env Handling → docker/.env.example (neu, als Template)
 
-Build/Gradle
+### Build/Gradle
 
 - settings.gradle.kts bleibt vorerst unverändert. Modul-Verschiebungen folgen in einem separaten Schritt mit angepassten include-Pfaden.
 - Version Catalog (gradle/libs.versions.toml) bleibt die einzige Quelle der Versionswahrheit.
 
-Richtlinien (Kurzfassung)
+### Richtlinien (Kurzfassung)
 
 - Features kommunizieren ausschließlich über Routen (Navigation) und Shared-Modelle in frontend/core/domain.
 - Kein manueller Authorization-Header – nur der DI-verwaltete apiClient aus frontend/core/network (Koin Named Binding).
 - SQLDelight als Offline-SSoT: Schema/Migrationen zentral versionieren, UI liest stets lokal und synchronisiert im Hintergrund.
 
-DI-Policy & Architecture Guards (MP-23)
+### DI-Policy & Architecture Guards (MP-23)
 
 - DI-Policy (Frontend)
   - Http‑Requests erfolgen ausschließlich über den via Koin bereitgestellten `apiClient` (named Binding) aus `:frontend:core:network`.
@@ -66,7 +84,7 @@ DI-Policy & Architecture Guards (MP-23)
   - Features importieren keine anderen Features (Kommunikation über Navigation + Shared‑Domain‑Modelle). Eine explizite Detekt‑Regel folgt.
   - Netzwerkzugriffe in Features nutzen Koin über die App‑Shell (DI‑Bootstrap). Für schrittweise Migration kann eine Factory den `apiClient` optional beziehen.
 
-Nächste Schritte (MP-22 Folgetasks)
+### Nächste Schritte (MP-22 Folgetasks)
 
 1. Physisches Verschieben der Frontend-Module gemäß Mapping und Anpassung von settings.gradle.kts.
 2. Physisches Verschieben der Backend-Komponenten in backend/* inkl. evtl. Package-Pfade, sofern notwendig.

docs/01_Architecture/adr/0010-sqldelight-for-cross-platform-persistence.md

@@ -0,0 +1,43 @@
+# ADR-0010: SQLDelight für Cross-Platform-Persistenz
+
+## Status
+
+Akzeptiert
+
+## Kontext
+
+Das "Meldestelle Portal" wird als Kotlin Multiplatform (KMP) Anwendung für Desktop (JVM) und Web (JS/Wasm) entwickelt. Eine zentrale Anforderung ist die **Offline-Fähigkeit**, was eine robuste, plattformübergreifende Persistenzlösung erfordert.
+
+Die ursprünglich evaluierte Lösung, **Room**, unterstützt die Web-Targets (JS/Wasm) nicht, was die Implementierung der Offline-Fähigkeit im Browser blockiert. Wir benötigen eine Datenbank-Bibliothek, die auf allen Zielplattformen funktioniert und eine moderne, asynchrone API bietet.
+
+## Entscheidung
+
+Wir werden **SQLDelight** als primäre Persistenz-Bibliothek für das KMP-Frontend einsetzen.
+
+*   **SQLDelight** generiert typsichere Kotlin-APIs aus SQL-Anweisungen und unterstützt alle KMP-Ziele, einschließlich JVM, JS und Wasm.
+*   **Web (JS/Wasm):** Wir nutzen den `WebWorkerDriver` in Kombination mit dem **Origin Private File System (OPFS)**. Dies ermöglicht eine performante, persistente Speicherung, die im Browser-Kontext in einem Hintergrund-Thread läuft, um die UI nicht zu blockieren.
+*   **Desktop (JVM):** Wir verwenden den `JdbcSqliteDriver`, um eine SQLite-Datenbank im Dateisystem des Benutzers zu speichern.
+*   **Async-First:** Die Datenbank-Schnittstellen werden durch die Option `generateAsync = true` standardmäßig als `suspend`-Funktionen generiert, um den asynchronen Anforderungen der Web-Plattform gerecht zu werden.
+
+## Konsequenzen
+
+*   **Positive:**
+    *   **Echte Cross-Platform-Persistenz:** Wir können dieselbe Datenbanklogik und dasselbe Schema auf allen Zielplattformen wiederverwenden.
+    *   **Offline-Fähigkeit im Web:** Die Nutzung von OPFS ermöglicht eine robuste und performante Offline-Speicherung im Browser.
+    *   **Typsicherheit:** SQLDelight bietet eine hohe Typsicherheit bei der Interaktion mit der Datenbank.
+    *   **Asynchrone API:** Die standardmäßig asynchrone API passt gut zu Kotlin Coroutines und den Anforderungen moderner UIs.
+
+*   **Negative:**
+    *   **Erhöhte Komplexität im Web-Setup:** Die Konfiguration von OPFS erfordert spezifische HTTP-Header (`Cross-Origin-Opener-Policy`, `Cross-Origin-Embedder-Policy`), die im Webserver bzw. im Webpack Dev Server gesetzt werden müssen.
+    *   **Lernkurve:** Das Team muss sich mit SQLDelight und den Besonderheiten der plattformspezifischen Treiber vertraut machen.
+
+## Betrachtete Alternativen
+
+*   **Room:** War die ursprüngliche Wahl, wurde aber aufgrund der fehlenden Unterstützung für JS/Wasm verworfen.
+*   **Realm:** Eine weitere plattformübergreifende Datenbank, wurde aber aufgrund der komplexeren Lizenzierung und der engeren Bindung an das Realm-Ökosystem nicht weiter verfolgt.
+*   **IndexedDB (manuell):** Die manuelle Verwendung von IndexedDB im Browser wäre eine Option gewesen, hätte aber zu einer inkonsistenten API zwischen den Plattformen und zu einem erheblichen Mehraufwand bei der Implementierung geführt.
+
+## Referenzen
+
+*   [Frontend Status Report 01-2026](docs/90_Reports/Frontend_Status_Report_01-2026.md)
+*   [SQLDelight Dokumentation](https://cashapp.github.io/sqldelight/)

docs/01_Architecture/adr/0011-koin-for-dependency-injection.md

@@ -0,0 +1,42 @@
+# ADR-0011: Koin für Dependency Injection
+
+## Status
+
+Akzeptiert
+
+## Kontext
+
+Das KMP-Frontend benötigt einen Dependency-Injection-Mechanismus, der auf allen Zielplattformen (JVM, JS, Wasm) funktioniert und gut mit Compose Multiplatform integriert ist. Wir müssen sicherstellen, dass die Anwendungslogik (ViewModels, Repositories) lose gekoppelt und leicht testbar ist.
+
+Besonders wichtig ist die zentrale Bereitstellung von plattformspezifischen Implementierungen (z.B. Datenbank-Treiber) und die Verwaltung von Singletons wie dem Ktor HTTP-Client.
+
+## Entscheidung
+
+Wir werden **Koin** als Dependency-Injection-Framework für das KMP-Frontend verwenden.
+
+*   **Koin** ist ein leichtgewichtiger DI-Container, der vollständig in Kotlin geschrieben ist und alle KMP-Ziele unterstützt.
+*   **Compose-Integration:** Koin bietet eine nahtlose Integration mit Compose Multiplatform (`koin-compose`), die es uns ermöglicht, ViewModels und andere Abhängigkeiten direkt in unseren Composable-Funktionen zu injizieren.
+*   **Modulare Konfiguration:** Wir werden Koin-Module verwenden, um die Abhängigkeiten für jede Schicht unserer Anwendung (Core, Features, Shells) zu definieren. Dies fördert die Modularität und Übersichtlichkeit.
+*   **Zentrale Initialisierung:** Die Koin-Anwendung wird in den plattformspezifischen `main`-Funktionen der "Shell"-Module (z.B. `meldestelle-portal`) initialisiert.
+
+## Konsequenzen
+
+*   **Positive:**
+    *   **Plattformübergreifende DI:** Wir können dieselbe DI-Konfiguration auf allen Zielplattformen verwenden.
+    *   **Vereinfachte Testbarkeit:** Koin erleichtert das Mocking von Abhängigkeiten in Unit-Tests.
+    *   **Gute Integration mit Compose:** Die `koin-compose`-Bibliothek reduziert den Boilerplate-Code bei der Injektion von Abhängigkeiten in die UI.
+    *   **Schnelle Lernkurve:** Koin ist im Vergleich zu anderen DI-Frameworks wie Dagger/Hilt relativ einfach zu erlernen und zu verwenden.
+
+*   **Negative:**
+    *   **Laufzeit-Fehler:** Koin löst Abhängigkeiten zur Laufzeit auf, was bedeutet, dass Fehler in der DI-Konfiguration erst beim Start der Anwendung oder bei der Verwendung einer Abhängigkeit auftreten (im Gegensatz zu Compile-Zeit-Fehlern bei Dagger/Hilt).
+    *   **Service Locator Pattern:** Koin wird manchmal als Service Locator kritisiert, was zu einer weniger strikten Einhaltung von DI-Prinzipien führen kann. Wir werden durch Code-Reviews darauf achten, dass Koin korrekt verwendet wird.
+
+## Betrachtete Alternativen
+
+*   **Dagger/Hilt:** Dagger und Hilt sind mächtige DI-Frameworks, die Compile-Zeit-Sicherheit bieten. Allerdings ist ihre Konfiguration komplexer und ihre Unterstützung für KMP ist weniger ausgereift als die von Koin.
+*   **Manuelle DI:** Die manuelle Implementierung von Dependency Injection wäre eine Option gewesen, hätte aber zu einem erheblichen Mehraufwand und zu mehr Boilerplate-Code geführt.
+
+## Referenzen
+
+*   [Koin Dokumentation](https.koin.io)
+*   [Repository-Architektur (MP-22)](docs/01_Architecture/ARCHITECTURE.md) (veraltet, aber erwähnt die DI-Policy)

docs/02_Onboarding/Development/start-local.md

@@ -1,67 +1,63 @@
- # Start Local (Lokales Setup)
+# Start Local (Lokales Setup)
 
- Kurzanleitung, um das Projekt lokal in wenigen Minuten zu starten.
+Kurzanleitung, um das Projekt lokal in wenigen Minuten zu starten.
 
- ## Voraussetzungen
- - Docker und Docker Compose (v2)
- - Java 25 (JDK)
- - Git
+**Wichtiger Hinweis (Januar 2026):** Der Build ist derzeit aufgrund eines Kotlin/Wasm-Compiler-Problems blockiert. Die Infrastruktur und die Backend-Services können jedoch unabhängig davon gestartet werden.
 
- ## Schnellstart
+## Voraussetzungen
+- Docker und Docker Compose (v2)
+- Java 25 (JDK)
+- Git
 
- ```bash
- # 1) Repository klonen
- git clone https://github.com/StefanMoCoAt/meldestelle.git
- cd meldestelle
+## Schnellstart
 
- # 2) Runtime-Environment vorbereiten (Single Source of Truth)
- #   Kopiere die Vorlage und passe sie bei Bedarf an.
- cp -n .env.template config/env/.env 2>/dev/null || true
- #   Optionale lokale Geheimnisse/Overrides (gitignored):
- #   echo "POSTGRES_PASSWORD=meinlokalespasswort" >> config/env/.env.local
+```bash
+# 1) Repository klonen
+git clone https://github.com/StefanMoCoAt/meldestelle.git
+cd meldestelle
 
- # 3) (Optional) Compose-Files generieren
- #    (nur falls du die Generator-Pipeline nutzt)
- # DOCKER_SSOT_MODE=envless bash scripts/generate-compose-files.sh all development
+# 2) Runtime-Environment vorbereiten
+#    Kopiere die Vorlage.
+cp .env.example .env
 
- # 4) Infrastruktur starten (Postgres, Redis, Kafka, Keycloak, Monitoring, Gateway)
- docker compose -f docker-compose.yaml up -d
+# 3) Infrastruktur starten (Postgres, Redis, Keycloak, Monitoring, Gateway)
+docker compose -f docker-compose.yaml up -d
 
- # 5) Backend-Service starten (Beispiel: Results Service)
- ./gradlew :backend:services:results:results-service:bootRun
- # oder – falls zentral gewollt und unterstützt:
- # ./gradlew bootRun
- ```
+# 4) Backend-Service starten (Beispiel: Results Service)
+./gradlew :backend:services:results:results-service:bootRun
+```
 
- Sobald die Infrastruktur läuft, erreichst du unter anderem:
- - Gateway: http://localhost:8081
- - Keycloak: http://localhost:8180
- - Grafana: http://localhost:3000
- - Prometheus: http://localhost:9090
+Sobald die Infrastruktur läuft, erreichst du unter anderem:
+- Gateway: http://localhost:8081
+- Keycloak: http://localhost:8180
+- Grafana: http://localhost:3000
+- Prometheus: http://localhost:9090
 
- ## Tests ausführen
- ```bash
- ./gradlew test
- # Spezifisches Modul
- ./gradlew :backend:services:results:results-service:test
- ```
+## Tests ausführen
+```bash
+# Führt alle Tests aus (Frontend-Tests könnten fehlschlagen)
+./gradlew test
 
- ## Troubleshooting
- - Dienste starten nicht? Ports belegt oder Logs prüfen:
-   ```bash
-   docker ps
-   docker logs <container-name>
-   ```
- - Infrastruktur neu starten:
-   ```bash
-   docker compose -f docker-compose.yaml down -v
-   docker compose -f docker-compose.yaml up -d
-   ```
- - Environment-Variablen: in `config/env/.env` und optional `config/env/.env.local`.
+# Spezifisches Backend-Modul testen
+./gradlew :backend:services:results:results-service:test
+```
 
- ## Weiterführende Hinweise
- - Architektur: `docs/01_Architecture/ARCHITECTURE.md`
- - ADRs: `docs/01_Architecture/adr/`
- - C4-Diagramme: `docs/01_Architecture/c4/`
+## Troubleshooting
+- Dienste starten nicht? Ports belegt oder Logs prüfen:
+  ```bash
+  docker ps
+  docker logs <container-name>
+  ```
+- Infrastruktur neu starten:
+  ```bash
+  docker compose -f docker-compose.yaml down -v
+  docker compose -f docker-compose.yaml up -d
+  ```
+- Environment-Variablen: werden aus der `.env`-Datei im Root-Verzeichnis geladen.
 
- Stand: Dezember 2025
+## Weiterführende Hinweise
+- Architektur: `docs/01_Architecture/ARCHITECTURE.md` (veraltet, siehe Reports)
+- ADRs: `docs/01_Architecture/adr/`
+- Aktuelle Reports: `docs/90_Reports/`
+
+Stand: Januar 2026 (teilweise aktualisiert)

docs/05_Frontend/README.md

@@ -0,0 +1,32 @@
+# Frontend-Architektur "Meldestelle Portal"
+
+Dieses Verzeichnis dokumentiert die Architektur und die technischen Details des KMP-Frontends "Meldestelle Portal".
+
+## Übersicht
+
+Das Frontend ist eine **Kotlin Multiplatform (KMP)**-Anwendung, die für die folgenden Ziele entwickelt wird:
+*   **Desktop (JVM):** Eine eigenständige Desktop-Anwendung.
+*   **Web (JS/Wasm):** Eine moderne Web-Anwendung, die im Browser läuft.
+
+Die Architektur ist auf **Offline-Fähigkeit** und eine reaktive UI ausgelegt.
+
+## Kerntechnologien
+
+*   **UI:** [Compose Multiplatform](https.jetbrains.com/lp/compose-multiplatform/) für eine deklarative, plattformübergreifende UI.
+*   **Persistenz (Offline-First):** [SQLDelight](https://cashapp.github.io/sqldelight/) für die lokale Speicherung von Daten.
+*   **State Management:** Kotlin Coroutines und Flow in Kombination mit ViewModels.
+*   **Dependency Injection:** [Koin](https://insert-koin.io/) für die lose Kopplung von Komponenten.
+*   **Netzwerk:** [Ktor Client](https://ktor.io/docs/client-introduction.html) für die Kommunikation mit dem Backend.
+
+## Architektur-Prinzipien
+
+*   **Clean Architecture / DDD:** Die Codebasis ist in Schichten unterteilt (UI, Application, Domain, Infrastructure), um eine klare Trennung der Verantwortlichkeiten zu gewährleisten.
+*   **Async-First Data Layer:** Alle Datenbank- und Netzwerk-Interaktionen sind asynchron (`suspend`-Funktionen), um die UI nicht zu blockieren.
+*   **Feature-basierte Modularisierung:** Die Anwendung ist in unabhängige "Feature"-Module unterteilt, die jeweils eine bestimmte Funktionalität kapseln.
+
+## Wichtige Dokumente
+
+*   **[ADR-0010: SQLDelight für Cross-Platform-Persistenz](docs/01_Architecture/adr/0010-sqldelight-for-cross-platform-persistence.md):** Beschreibt die Entscheidung für SQLDelight.
+*   **[ADR-0011: Koin für Dependency Injection](docs/01_Architecture/adr/0011-koin-for-dependency-injection.md):** Beschreibt die Entscheidung für Koin.
+*   **[Offline-First-Architektur](docs/05_Frontend/offline-first-architecture.md):** Detaillierte Beschreibung der Offline-First-Strategie.
+*   **[Web-Setup (Webpack & Worker)](docs/05_Frontend/web-setup.md):** Details zur Konfiguration des Web-Targets.

docs/05_Frontend/offline-first-architecture.md

@@ -0,0 +1,71 @@
+# Offline-First-Architektur
+
+Dieses Dokument beschreibt die **Zielarchitektur** für die Offline-First-Strategie im KMP-Frontend.
+
+---
+
+## Status Quo (Stand: 13.01.2026)
+
+**WICHTIG:** Dieses Dokument beschreibt die **geplante Zielarchitektur**. Die aktuelle Implementierung ist ein erster Schritt in diese Richtung.
+
+*   **SQLDelight-Modul (`:frontend:core:local-db`):** Das Modul ist konfiguriert und nutzt `generateAsync = true` für eine asynchrone API.
+*   **Datenbank-Schema:** Aktuell ist nur eine einfache Tabelle `LocalSettings` implementiert, die zum Speichern von lokalen Schlüssel-Wert-Paaren dient.
+    *   Siehe: `frontend/core/local-db/src/commonMain/sqldelight/at/mocode/frontend/core/localdb/MeldestelleDb.sq`
+*   **Komplexe Entitäten & Sync:** Die im Folgenden beschriebenen Repositories für Fachdaten, die `Flow`-basierte Datenflüsse und die Delta-Sync-Logik sind **noch nicht implementiert**.
+
+---
+
+## Zielarchitektur
+
+### Grundprinzip
+
+Die Anwendung soll auch ohne eine aktive Netzwerkverbindung voll funktionsfähig sein. Alle Daten, die der Benutzer sieht und bearbeitet, werden in einer lokalen Datenbank auf dem Gerät gespeichert. Die Synchronisation mit dem Backend erfolgt im Hintergrund, sobald eine Netzwerkverbindung verfügbar ist.
+
+**Single Source of Truth (für die UI):** Die lokale SQLDelight-Datenbank ist die alleinige Quelle der Wahrheit für die Benutzeroberfläche. Die UI liest niemals direkt aus dem Netzwerk.
+
+### Komponenten
+
+1.  **Lokale Datenbank (SQLDelight):**
+    *   Hält eine Kopie der relevanten Backend-Daten.
+    *   Verwendet plattformspezifische Treiber:
+        *   **Web (JS/Wasm):** `WebWorkerDriver` mit OPFS (Origin Private File System) für persistente Speicherung im Browser.
+        *   **Desktop (JVM):** `JdbcSqliteDriver` für die Speicherung in einer lokalen SQLite-Datei.
+    *   Bietet eine asynchrone API (`suspend`-Funktionen), wie bereits durch `generateAsync` sichergestellt.
+
+2.  **Repositories:**
+    *   Kapseln den Zugriff auf die lokale Datenbank.
+    *   Bieten `Flow`-basierte APIs, um die UI über Datenänderungen zu informieren.
+    *   Beispiel: `fun getHorses(): Flow<List<Horse>>`
+
+3.  **ViewModels:**
+    *   Sammeln die Daten-Flows von den Repositories und transformieren sie in einen UI-Zustand (`StateFlow`).
+    *   Leiten Benutzerinteraktionen an die entsprechenden Use Cases oder Repositories weiter.
+
+4.  **Sync-Logik:**
+    *   Ein separater Mechanismus, der für den Datenabgleich zwischen der lokalen Datenbank und dem Backend verantwortlich ist.
+    *   **Delta-Sync:** Um die Netzwerklast zu minimieren, werden nur die Änderungen seit der letzten Synchronisation übertragen. Dies wird durch die Verwendung von Zeitstempeln oder Versionsnummern (z.B. UUIDv7) in den Datenmodellen ermöglicht.
+    *   **Konfliktlösung:** Bei gleichzeitigen Änderungen auf dem Client und im Backend muss eine Konfliktlösungsstrategie implementiert werden (z.B. "Last-Write-Wins" oder eine manuelle Auflösung durch den Benutzer).
+
+### Datenfluss (Lesen)
+
+1.  Die UI (Composable) beobachtet einen `StateFlow` im ViewModel.
+2.  Das ViewModel sammelt einen `Flow` aus einem Repository.
+3.  Das Repository fragt die lokale SQLDelight-Datenbank ab und gibt einen `Flow` zurück.
+4.  Jede Änderung in der lokalen Datenbank wird automatisch an die UI weitergegeben.
+
+### Datenfluss (Schreiben)
+
+1.  Der Benutzer löst eine Aktion in der UI aus (z.B. Klick auf "Speichern").
+2.  Die UI ruft eine Funktion im ViewModel auf.
+3.  Das ViewModel ruft eine `suspend`-Funktion in einem Repository auf.
+4.  Das Repository schreibt die Änderung in die lokale SQLDelight-Datenbank.
+5.  Die Änderung wird (ggf. in einer separaten "outbox"-Tabelle) für die nächste Synchronisation vorgemerkt.
+6.  Die UI wird durch den Lese-Datenfluss automatisch aktualisiert.
+
+### Synchronisations-Prozess
+
+1.  Ein Hintergrund-Job (z.B. ein Coroutine-Worker) wird periodisch oder bei Netzwerkverfügbarkeit gestartet.
+2.  Der Sync-Worker sendet die vorgemerkten lokalen Änderungen an das Backend.
+3.  Der Sync-Worker fragt das Backend nach neuen Änderungen seit der letzten Synchronisation ab.
+4.  Die neuen Daten vom Backend werden in die lokale Datenbank geschrieben.
+5.  Die UI wird durch den Lese-Datenfluss automatisch aktualisiert.

docs/05_Frontend/web-setup.md

@@ -0,0 +1,34 @@
+# Web-Setup (Webpack & Worker)
+
+Dieses Dokument beschreibt die spezifische Konfiguration für das Web-Target (JS/Wasm) des KMP-Frontends.
+
+## OPFS (Origin Private File System)
+
+Um eine performante und persistente Speicherung der SQLDelight-Datenbank im Browser zu ermöglichen, verwenden wir das **Origin Private File System (OPFS)**. Die Nutzung von OPFS erfordert, dass die Webseite in einem "cross-origin isolated"-Kontext läuft.
+
+### HTTP-Header
+
+Dazu müssen die folgenden HTTP-Header vom Webserver ausgeliefert werden:
+
+*   `Cross-Origin-Opener-Policy: same-origin`
+*   `Cross-Origin-Embedder-Policy: require-corp`
+
+### Webpack Dev Server
+
+Für die lokale Entwicklung wird der Webpack Dev Server verwendet. Um die erforderlichen Header zu setzen, wurde die `webpack.config.d/opfs-headers.js`-Datei erstellt, die die Header zur Konfiguration des Dev Servers hinzufügt.
+
+## Web Worker für SQLDelight
+
+Um die UI nicht zu blockieren, werden alle Datenbank-Operationen in einem separaten **Web Worker** ausgeführt.
+
+*   **`sqlite.worker.js`:** Ein benutzerdefinierter Worker, der die SQLDelight-Datenbank initialisiert und die Anfragen vom Haupt-Thread entgegennimmt.
+*   **`WebWorkerDriver`:** Der SQLDelight-Treiber, der die Kommunikation zwischen dem Haupt-Thread und dem Worker-Thread managed.
+
+## Build-Konfiguration
+
+*   **`build.gradle.kts`:** Im `build.gradle.kts` des `meldestelle-portal`-Moduls wird das `wasmJs` oder `js` Target entsprechend konfiguriert, um die Web-Anwendung zu bauen.
+*   **Webpack-Integration:** Die Gradle-Plugins für KMP/JS und Compose for Web kümmern sich um die Integration mit Webpack und die Erstellung des finalen JavaScript-Bundles.
+
+## Aktueller Blocker (Januar 2026)
+
+Derzeit ist der Build für das `wasmJs`-Target aufgrund von Compiler-Fehlern im Zusammenhang mit dem JS-Interop und fehlenden DOM-API-Referenzen blockiert. Die Behebung dieses Problems hat höchste Priorität.

docs/99_Journal/2026-01-13_initial-curator-analysis.md

@@ -0,0 +1,25 @@
+# Journal: Initiale Projektanalyse durch den Curator
+
+*   **Datum:** 2026-01-13
+*   **Autor:** Documentation & Knowledge Curator
+*   **Thema:** Erste Bestandsaufnahme der Dokumentations-Strategie und -Prozesse.
+
+## Zusammenfassung
+
+Diese Session diente der initialen Analyse des Projekts aus Sicht des Knowledge Curators. Die Analyse basiert auf den Agenten-Definitionen und dem Curator-Playbook.
+
+## Erkenntnisse
+
+Die strategische Grundlage für die Dokumentation im Projekt "Meldestelle" ist hervorragend.
+
+*   **Positiv:**
+    *   Das Prinzip "Docs-as-Code" mit `docs/` als Single Source of Truth ist etabliert.
+    *   Alle Agenten-Rollen haben klar definierte Dokumentationspflichten.
+    *   Die Artefakt-Typen (ADR, Reference, How-to, Journal) sind klar definiert.
+    *   Die Curator-Rolle selbst ist als Mechanismus zur Sicherung von Wissen verankert.
+
+## Offene Punkte & Nächste Schritte
+
+1.  **Validierung der Praxis:** Die aktuelle Analyse ist rein strategisch. Es muss geprüft werden, wie konsequent die Regeln bereits im Projektalltag umgesetzt werden.
+2.  **Analyse bestehender Artefakte:** Eine Durchsicht der Verzeichnisse `docs/01_Architecture/adr/`, `docs/04_Backend/Services/` etc. ist notwendig, um den Reifegrad der bestehenden Dokumentation zu bewerten.
+3.  **Zugriff auf Projektstruktur:** Für eine tiefere Analyse ist eine Übersicht über die gesamte Verzeichnisstruktur des Projekts erforderlich.

docs/99_Journal/2026-01-13_request-for-project-structure-analysis.md

@@ -0,0 +1,29 @@
+# Journal: Auftrag zur Tiefenanalyse & Anforderung der Projektstruktur
+
+* **Datum:** 2026-01-13
+* **Autor:** Documentation & Knowledge Curator
+* **Thema:** Follow-Up zur initialen Analyse und Auftrag zur Überprüfung der Dokumentations-Praxis.
+
+## Zusammenfassung
+
+Aufbauend auf der [initialen Analyse vom 13.01.2026](2026-01-13_initial-curator-analysis.md) wurde heute der Auftrag
+erteilt, eine Tiefenanalyse des Projekts durchzuführen.
+
+Folgende Punkte sollen geprüft werden:
+
+1. Konsistenz der Regelumsetzung im Projektalltag ("Jede Session endet mit einem Artefakt").
+2. Analyse und Bewertung bestehender Artefakte in `docs/`.
+3. Gesamtanalyse der Projektstruktur.
+
+## Offene Punkte & Nächste Schritte
+
+**Blocker:** Für die Durchführung der Analyse ist eine Übersicht der aktuellen Verzeichnisstruktur des gesamten Projekts
+zwingend erforderlich. Ohne diese "Landkarte" kann keine sinnvolle Bewertung der Artefakte und ihrer Vollständigkeit
+stattfinden.
+
+**Nächster Schritt:**
+
+* **Anforderung:** Bereitstellung der Projektstruktur, idealerweise durch die Ausgabe eines Befehls wie `tree -L 3` für
+  das gesamte Repository.
+* Sobald die Struktur vorliegt, wird die eigentliche Analyse in der nächsten Session durchgeführt und das Ergebnis in
+  einem passenden Artefakt festgehalten.