chore(build, dependencies): add Room support with KSP integration and optimize testing dependencies

- Integrated Room plugin and runtime dependencies into `local-db` module, including schema configuration for Room.
- Added KSP processor dependencies for Kotlin Multiplatform compatibility.
- Enhanced `core-domain` module by refining and temporarily adjusting testing dependencies for resolution issues.

docs/01_Architecture/Architecture_OpenSource_Checkliste.md

@@ -0,0 +1,46 @@
+# Open-Source-Konformität & Lizenz-Checkliste
+
+Dieses Dokument dient der Überwachung und Sicherstellung der Open-Source-Konformität des Projekts **Meldestelle**. Es wird vom Lead Architect gepflegt.
+
+## Status der Kern-Komponenten (Stand: Januar 2026)
+
+| Komponente | Lizenz | Status | Risiko | Maßnahme / Kommentar |
+| :--- | :--- | :--- | :--- | :--- |
+| **Kotlin / JVM** | Apache 2.0 / GPLv2+CE | ✅ OK | Sehr gering | Standard-Stack. |
+| **Spring Boot / Cloud** | Apache 2.0 | ✅ OK | Sehr gering | |
+| **PostgreSQL** | PostgreSQL (BSD-like) | ✅ OK | Sehr gering | |
+| **Redis** | **RSALv2 / SSPL** | ⚠️ KRITISCH | Hoch | **Umstieg auf Valkey (BSD) geplant.** |
+| **Consul** | **BSL 1.1** | ⚠️ BEOBACHTEN | Mittel | Lizenzänderung durch HashiCorp. Für interne Nutzung aktuell unkritisch. |
+| **Keycloak** | Apache 2.0 | ✅ OK | Gering | |
+| **SQLDelight** | Apache 2.0 | ✅ OK | Sehr gering | |
+| **Redisson** | Apache 2.0 (Core) | ✅ OK | Gering | Sicherstellen, dass keine PRO-Features genutzt werden. |
+
+---
+
+## Checkliste für neue Abhängigkeiten
+
+Bevor eine neue Bibliothek oder Infrastruktur-Komponente hinzugefügt wird, muss sie folgende Kriterien erfüllen:
+
+1.  **Lizenz-Typ:**
+    *   Bevorzugt: Apache 2.0, MIT, BSD (3-Clause).
+    *   Akzeptabel: MPL 2.0.
+    *   Einzelfallprüfung: LGPL (nur als dynamische Bibliothek).
+    *   **Verboten:** AGPL, SSPL, RSAL, BSL (sofern nicht explizit vom Architect freigegeben).
+
+2.  **Community & Governance:**
+    *   Wird das Projekt von einer neutralen Foundation (Apache, CNCF, Linux Foundation) verwaltet?
+    *   Gibt es eine "Single Vendor" Abhängigkeit (Risiko einer plötzlichen Lizenzänderung)?
+
+3.  **Transitive Abhängigkeiten:**
+    *   Bringt die Bibliothek "versteckte" Copyleft-Lizenzen mit? (Check via Gradle License Plugin).
+
+---
+
+## TODOs & Strategische Entscheidungen
+
+- [ ] **Migration Redis -> Valkey:** Umstellung der Docker-Images und Test der Kompatibilität.
+- [ ] **Consul Review:** Jährliche Prüfung der BSL-Auswirkungen auf unser Deployment-Modell.
+- [ ] **Automatisierung:** Integration eines License-Check-Plugins in den CI-Build (z.B. `com.github.jk1.dependency-license-report`).
+
+---
+*Dieses Dokument ist Teil der "Docs-as-Code" Strategie und muss bei jeder Änderung am Tech-Stack aktualisiert werden.*

docs/05_Backend/ROADMAP.md

@@ -0,0 +1,36 @@
+# Backend Roadmap - Meldestelle
+
+Dieses Dokument beschreibt die geplanten Schritte zur Weiterentwicklung der Backend-Infrastruktur. Der aktuelle Fokus liegt auf der **Härtung der Infrastruktur** unter Nutzung des `ping-service` als technischem Blueprint.
+
+## Status Quo
+*   **Blueprint:** `ping-service` ist funktional, dient aber nun als Zielobjekt für Infrastruktur-Verbesserungen.
+*   **Technologie:** Spring Boot 3.5.9, Kotlin Coroutines, PostgreSQL.
+
+## Meilensteine (Priorisiert)
+
+### Meilenstein 1: Infrastruktur-Härtung (Fokus: Ping-Service)
+*   [ ] **Observability & Monitoring:**
+    *   Vollständige Integration von Spring Boot Actuator.
+    *   Konfiguration von Micrometer/Prometheus Metriken.
+    *   Logging-Standardisierung (Structured Logging/JSON für ELK/Loki).
+*   [ ] **Security Baseline:**
+    *   Integration von Spring Security mit Keycloak (OAuth2/OIDC).
+    *   Absicherung der Endpunkte im `ping-service` (RBAC).
+    *   Validierung der JWT-Tokens am API-Gateway.
+*   [ ] **Resilience & Stability:**
+    *   Härtung des Resilience4j Setups (Circuit Breaker, Bulkhead, Rate Limiter).
+    *   Optimierung der Datenbank-Connection-Pools (HikariCP).
+    *   Einführung von Flyway oder Liquibase für kontrollierte DB-Migrationen.
+
+### Meilenstein 2: Build-System & CI/CD Readiness
+*   [ ] **Gradle Refactoring:** Umstellung auf Version Catalog (`libs.versions.toml`) für alle Backend-Module.
+*   [ ] **Test-Härtung:** Standardisierung der Integrationstests mit Testcontainers (Postgres, Keycloak, Redis).
+*   [ ] **Docker-Optimierung:** Multi-stage Builds und Distroless-Images für reduzierte Angriffsfläche.
+
+### Meilenstein 3: Rollout auf Fach-Services
+*   [ ] Übertragung der gehärteten Standards vom `ping-service` auf `horses`, `members`, etc.
+*   [ ] Dokumentation der "Production Readiness Checklist" für neue Services.
+
+## Nächste Schritte (Vorschlag)
+1.  **Audit des aktuellen `ping-service`:** Identifikation von Lücken in Security und Monitoring.
+2.  **Zentralisierung der Abhängigkeiten:** Einführung der `libs.versions.toml`, um eine konsistente Basis für die Härtung zu haben.