chore(docs): add comprehensive compatibility and architecture reports for 2026 technology stack

- Integrated detailed reports on compatibility and strategic architecture for the 2026 technology stack.
- Documents analyze JVM/Multiplatform components including Kotlin 2.3.0, Java 25, Spring Boot 3.5.9, and Compose Multiplatform.
- Provides guidance on resolving dependency conflicts, best practices, and version alignment for production readiness.

docs/Kompatibilitätsanalyse_01-2026.md

@@ -0,0 +1,219 @@
+Hier ist der vollständige Bericht im Roh-Markdown-Format, wie gewünscht:
+
+# Validierung der Enterprise-Architektur: Umfassende Kompatibilitätsanalyse und Strategische Bewertung des Technologie-Stacks 2026
+
+## Executive Summary
+
+Der vorliegende Forschungsbericht analysiert den vom Auftraggeber spezifizierten Technologie-Stack mit Stand vom **7. Januar 2026**. Die Architektur repräsentiert eine ambitionierte, hybride Plattformstrategie, die modernste JVM-Paradigmen (Java 25, Spring Boot 3.5) mit einer aggressiven Kotlin-Multiplatform-Strategie (Kotlin 2.3.0, Compose Multiplatform, Ktor) vereint. Das Ziel dieser Untersuchung ist die Validierung der Interoperabilität der Einzelkomponenten, die Identifikation kritischer Versionskonflikte sowie die Erstellung einer stabilisierten Kompatibilitätsmatrix („Best Compatibility List“).
+
+Die Analyse deckt eine **kritische Diskrepanz** im Kern der Backend-Architektur auf: Die Kombination von Spring Boot 3.5.9 mit Spring Cloud 2025.1.0 ist technisch nicht tragfähig und führt zu unvermeidbaren Laufzeitfehlern, da der Release Train "Oakwood" (2025.1.x) exklusiv für die Spring Boot Generation 4.0 konzipiert wurde. Des Weiteren identifiziert der Bericht signifikante Synchronisationsrisiken zwischen der sehr neuen Sprachebene (Kotlin 2.3.0, veröffentlicht Dez. 2025) und dem UI-Framework (Compose Multiplatform 1.9.3), welche die Stabilität von Produktions-Builds gefährden.
+
+Trotz dieser spezifischen Konflikte bestätigt die Untersuchung, dass der gewählte Stack grundsätzlich eine zukunftsweisende „State-of-the-Art“-Architektur darstellt, die durch die Nutzung von Java 25 (LTS) und Kotlin 2.3.0 massive Vorteile in Performance (Compact Object Headers, Virtual Threads) und Entwicklerproduktivität (K2 Compiler) bietet, sofern die im Bericht detaillierten Korrekturen implementiert werden.
+
+---
+
+## 1. Fundamentalanalyse: Laufzeitumgebung und Sprachebene
+
+Das Fundament der Architektur bilden Java 25 als Long-Term-Support (LTS) Release und Kotlin 2.3.0. Diese Kombination definiert den technologischen Horizont für die Jahre 2026 bis 2030. Die Synchronisation dieser beiden Komponenten ist entscheidend für den Erfolg aller darauf aufbauenden Frameworks.
+
+### 1.1 Java 25 (LTS): Implikationen für die Enterprise-Architektur
+
+Java 25, veröffentlicht am 16. September 2025, markiert einen signifikanten Meilenstein in der Evolution der Java-Plattform. Als LTS-Release bietet es die notwendige Planungssicherheit für Enterprise-Projekte, bringt jedoch auch tiefgreifende Änderungen in der Speicherverwaltung und Thread-Modellierung mit sich, die direkten Einfluss auf die im Stack verwendeten Frameworks (Spring Boot, Exposed) haben.
+
+#### Architektur-Treiber: Compact Object Headers und Loom-Integration
+
+Die Validierung zeigt, dass Java 25 insbesondere durch die Finalisierung der **Compact Object Headers** (JEP 519) massive Vorteile für die Speichereffizienz von Spring-Boot-Anwendungen bietet. Durch die Reduktion des Objekt-Headers von 128 Bit auf 64 Bit (in 64-Bit-Umgebungen) sinkt der Heap-Verbrauch von objektintensiven Anwendungen signifikant. Dies ist für den vorliegenden Stack besonders relevant, da die Nutzung von ORM-Frameworks wie **Exposed** und **Room** typischerweise eine hohe Anzahl an kleinen Datenobjekten erzeugt.
+
+Ein weiterer kritischer Aspekt ist die volle Integration von Project Loom (Virtual Threads). Spring Boot 3.5.9 ist darauf optimiert, blockierende I/O-Operationen – wie sie bei JDBC-Zugriffen via Exposed auftreten – transparent auf Virtual Threads abzubilden. Dies eliminiert die Notwendigkeit für komplexe reaktive Ketten (R2DBC) in vielen Standardszenarien, sofern die zugrundeliegende Datenbank-Treiber-Schicht (JDBC) kompatibel ist. Die Analyse bestätigt, dass die aktuellen JDBC-Treiber im Java 25 Ökosystem diese Kompatibilität gewährleisten.
+
+### 1.2 Kotlin 2.3.0: Der K2-Compiler als Standard
+
+Mit dem Release vom 16. Dezember 2025 festigt Kotlin 2.3.0 die Rolle des K2-Compilers als unverzichtbares Werkzeug. Für den vorliegenden Stack ergeben sich hieraus spezifische Herausforderungen und Chancen.
+
+#### Interoperabilität und Compiler-Strenge
+
+Kotlin 2.3.0 führt striktere Checks ein, insbesondere den **Unused Return Value Checker**. Dies hat direkte Auswirkungen auf die Code-Qualität im Bereich der Datenbank-Transaktionen (Exposed) und HTTP-Requests (Ktor). Wo früher ignorierte Rückgabewerte (z.B. der Status eines Insert-Statements oder ein HTTP-Response-Code) zu stillen Fehlern führten, erzwingt der Compiler nun eine explizite Behandlung.
+
+Ein Risiko besteht in der binären Kompatibilität von Bibliotheken, die mit älteren Kotlin-Versionen (vor 2.0) kompiliert wurden. Die Analyse der `libs.versions.toml` vom Juli 2025 deutet darauf hin, dass viele Bibliotheksversionen vor dem Release von Kotlin 2.3.0 definiert wurden. Während Kotlin eine hohe Abwärtskompatibilität garantiert, können Compiler-Plugins (KSP, Compose Compiler) hier Ausnahmen bilden. Insbesondere die Interaktion zwischen Kotlin 2.3.0 und dem **Compose Compiler** erfordert eine exakte Versionierung, da Diskrepanzen hier zu Build-Abbrüchen führen.
+
+#### Swift Export und KMP-Strategie
+
+Für den Multiplatform-Teil des Stacks ist Kotlin 2.3.0 essenziell, da es signifikante Verbesserungen im **Swift Export** mitbringt. Die Unterstützung für native Enum-Klassen und variadische Parameter in Swift reduziert den Bedarf an Boilerplate-Code im iOS-Shared-Layer drastisch. Dies validiert die Entscheidung für Kotlin 2.3.0 als strategisch korrekt, sofern die genutzten KMP-Bibliotheken (Ktor, SQLDelight/Room) diese neuen Interop-Features unterstützen.
+
+---
+
+## 2. Das Spring-Ökosystem: Analyse des kritischen Versionskonflikts
+
+Im Bereich der serverseitigen Architektur deckt die Analyse den schwerwiegendsten Konflikt des vorgeschlagenen Stacks auf. Die Annahme, dass eine höhere Versionsnummer (2025.1.0) automatisch Kompatibilität mit der aktuellsten Spring Boot Version (3.5.9) bedeutet, ist in diesem Fall inkorrekt und fatal für die Laufzeitstabilität.
+
+### 2.1 Spring Boot 3.5.9: Stabilität vor dem Major-Sprung
+
+Spring Boot 3.5.9 (Released 18. Dezember 2025) ist ein hochstabiles Maintenance-Release innerhalb der 3.x-Generation. Es basiert auf Spring Framework 6.2.x und Jakarta EE 10. Die Analyse bestätigt, dass diese Version vollständig kompatibel mit Java 25 ist und von dessen LTS-Features profitiert.
+
+### 2.2 Die Inkompatibilität von Spring Cloud 2025.1.0 (Oakwood)
+
+Der Nutzer plant den Einsatz von **Spring Cloud 2025.1.0**. Die detaillierte Prüfung der Spring Cloud Release Trains offenbart jedoch folgende Matrix:
+
+| Release Train | Codename | Benötigte Spring Boot Basis | Spring Framework Basis | Status im Stack |
+| --- | --- | --- | --- | --- |
+| **2025.1.x** | **Oakwood** | **Spring Boot 4.0.x** | Spring Framework 7.x | **INKOMPATIBEL** |
+| **2025.0.x** | **Northfields** | **Spring Boot 3.5.x** | Spring Framework 6.2.x | **KOMPATIBEL** |
+| 2024.0.x | Moorgate | Spring Boot 3.4.x | Spring Framework 6.2.x | VERALTET |
+
+**Technische Fehleranalyse:**
+Der Release Train "Oakwood" (2025.1.0) wurde entwickelt, um die nächste Generation des Spring-Ökosystems zu unterstützen (Spring Boot 4.0). Spring Boot 4.0 führt Breaking Changes ein, darunter Upgrades auf Jakarta EE 11 und Spring Framework 7.
+Wird Spring Cloud 2025.1.0 in eine Spring Boot 3.5.9 Anwendung eingebunden, treten massive Classpath-Konflikte auf. Spring Cloud Oakwood erwartet Klassen und Methoden aus Spring Framework 7, die in der Runtime von Boot 3.5 (Spring Framework 6.2) nicht existieren. Typische Fehlerbilder wären `java.lang.NoSuchMethodError`, `java.lang.ClassNotFoundException` oder `java.lang.NoClassDefFoundError` bereits während der Initialisierung des Application Contexts.
+
+**Strategische Korrektur:**
+Um die Integrität des Stacks zu wahren, ist ein Downgrade des Spring Cloud Release Trains auf **2025.0.1 (Northfields)** zwingend erforderlich. Dieser Release Train wurde zeitgleich mit Spring Boot 3.5.x entwickelt und gewährleistet volle API-Kompatibilität sowie die korrekte Einbindung der Micrometer-Tracing-Bibliotheken (Version 1.15/1.16), die im Stack ebenfalls eine Rolle spielen.
+
+### 2.3 Micrometer und Observability Integration
+
+Im Kontext von Spring Boot 3.5.9 und Spring Cloud 2025.0.1 spielt Micrometer eine zentrale Rolle für Metrics und Tracing. Die Analyse zeigt, dass Spring Boot 3.5.9 standardmäßig **Micrometer 1.15.0** verwaltet. Es gibt jedoch Hinweise auf die Verfügbarkeit von **Micrometer 1.16.1**, welches verbesserte Support-Funktionen für Java 25 bietet.
+Obwohl Spring Boot Dependency Management stabile Versionen vorgibt, ist es in diesem High-Performance-Setup ratsam, die Micrometer-Version explizit auf 1.16.1 zu heben, um von den neuesten Optimierungen im Bereich Virtual Thread Monitoring zu profitieren, die in 1.15 noch experimentell waren.
+
+---
+
+## 3. Multiplatform UI Architektur: Compose und die Compiler-Falle
+
+Der Bereich "Compose Multiplatform" (CMP) ist im Januar 2026 einem schnellen Wandel unterworfen. Die Kombination von CMP 1.9.3 mit Kotlin 2.3.0 stellt ein signifikantes Risiko dar, das ohne manuelle Eingriffe zum Scheitern des Build-Prozesses führen kann.
+
+### 3.1 Die Diskrepanz zwischen CMP 1.9.3 und Kotlin 2.3.0
+
+Compose Multiplatform 1.9.3 basiert auf Jetpack Compose 1.9.4. Kotlin 2.3.0 führt jedoch neue Anforderungen an den Compose Compiler ein, um erweiterte Debugging-Features zu unterstützen – konkret das Mapping von Stack-Traces in minifizierten (R8/ProGuard) Builds.
+
+**Das technische Problem:**
+Kotlin 2.3.0 erwartet standardmäßig eine Compose Runtime der Version **1.10.0** oder höher, um die neuen "Group Key" Stack-Traces zu generieren. Wird CMP 1.9.3 verwendet, kommt es zu einer Version-Mismatch. Der in Kotlin 2.3.0 integrierte Compose Compiler versucht, Bytecode für Features zu generieren, die in der älteren Runtime (1.9.4) noch nicht vorhanden sind.
+Zusätzlich gibt es dokumentierte Fälle, in denen die Kombination aus neuem Android-Gradle-Plugin (AGP), Kotlin 2.3.0 und älteren Compose-Versionen zu Compiler-Crashes (`NotSerializableException` im Daemon) führt, da Inline-Methoden wie `CompositionLocal.getCurrent` nicht korrekt aufgelöst werden.
+
+### 3.2 Strategische Lösung: Upgrade auf CMP 1.10.0
+
+Zum Zeitpunkt dieses Berichts (Januar 2026) ist **Compose Multiplatform 1.10.0** (bzw. ein stabiler Release Candidate) verfügbar. Ein Upgrade auf diese Version ist nicht nur empfohlen, sondern für einen stabilen Betrieb mit Kotlin 2.3.0 faktisch notwendig.
+
+**Vorteile von CMP 1.10.0 im Kontext des Stacks:**
+
+1. **Vollständige Kotlin 2.3.0 Kompatibilität:** Eliminiert Compiler-Crashes und ermöglicht die Nutzung der neuen R8-Stack-Trace-Mappings für besseres Production-Debugging auf Android.
+2. **WebAssembly (Wasm) Reife:** CMP 1.10.0 hebt den Wasm-Support auf ein neues Level (Beta/Stable), was für die "Web"-Komponente des KMP-Stacks essenziell ist. Ältere Versionen (1.9.x) hatten signifikante Einschränkungen bei der Performance und dem Ressourcen-Management im Browser.
+3. **Navigation 3 Integration:** CMP 1.10.0 bündelt die stabilen Artefakte von `androidx.navigation3`, was eine vereinheitlichte Navigation über alle Plattformen (inkl. Non-Android) ermöglicht und externe Bibliotheken wie Voyager potenziell obsolet macht.
+
+---
+
+## 4. Middleware Analyse: Ktor und Koin
+
+### 4.1 Ktor: Synchronisation der Versionen
+
+Der Nutzer schlägt **Ktor 3.3.3** vor. Diese Version wurde im November 2025 veröffentlicht und basiert auf Kotlin 2.2.20.
+Die Analyse zeigt, dass **Ktor 3.4.0** (released im Dezember 2025 parallel zu Kotlin 2.3.0) die korrekte Zielversion für diesen Stack ist.
+
+**Gründe für das Upgrade auf Ktor 3.4.0:**
+
+* **Kotlin 2.3.0 Alignment:** Ktor 3.4.0 wurde explizit gegen Kotlin 2.3.0 kompiliert. Dies verhindert Probleme mit `kotlinx-io` Abhängigkeiten, die in Kotlin 2.3.0 aktualisiert wurden.
+* **Fix für iOS SSE:** Ktor 3.3.x leidet unter einem bekannten Bug im Darwin-Engine (iOS), bei dem Server-Sent Events (SSE) Verbindungen einfrieren können. Ktor 3.4.0 behebt dieses Problem, was für die Zuverlässigkeit der mobilen Clients im Stack entscheidend ist.
+
+**Ktorfit Integration:**
+Falls Bibliotheken wie **Ktorfit** (für Retrofit-ähnliche APIs) genutzt werden, ist zu beachten, dass Ktorfit sehr empfindlich auf KSP-Versionen reagiert. Ktorfit 2.7.1 ist kompatibel mit Ktor 3.3.3. Für Ktor 3.4.0 und Kotlin 2.3.0 wird ein entsprechendes Update (z.B. Ktorfit 2.8.0) benötigt, welches die `compilerPluginVersion` korrekt auf 2.3.x setzt.
+
+### 4.2 Koin 4.1.1: Dependency Injection Stabilität
+
+Koin 4.1.1 erweist sich als stabile Wahl. Das Framework hat sich erfolgreich an die KMP-Architektur angepasst.
+Ein wichtiger Aspekt für 2026 ist die **Koin Annotations** Unterstützung. Mit Kotlin 2.3.0 und KSP 2.3.0 muss sichergestellt werden, dass auch die Koin-Annotations-Bibliothek (Version 2.x) aktualisiert wird, um die Generierung der Modul-Definitionen nicht zu brechen. Koin 4.1.1 selbst ist kompatibel, profitiert aber von Performance-Optimierungen in der Graph-Auflösung, die für komplexe Enterprise-Apps wichtig sind.
+
+---
+
+## 5. Persistenz-Layer: Konsolidierung der "Drei-Datenbanken-Strategie"
+
+Der Stack listet **Exposed 0.61.0**, **SQLDelight 2.2.1** und **Room 2.8.4**. Diese Koexistenz von drei unterschiedlichen Datenbank-Frameworks ist architektonisch auffällig und deutet auf Redundanzen hin.
+
+### 5.1 Serverseitige Persistenz: Exposed 0.61.0
+
+**Status:** Veraltet (Release April 2025).
+**Risiko:** Hoch.
+
+Die Verwendung von Exposed 0.61.0 in einem Kotlin 2.3.0 Umfeld ist hochriskant. Exposed nutzt intern starkes Inlining und reified Types. Da Kotlin 2.3.0 Änderungen an der Bytecode-Generierung und den Standardbibliotheken (z.B. `kotlinx-datetime`) vorgenommen hat, führt eine veraltete Exposed-Version fast sicher zu `NoSuchMethodError` oder Inkompatibilitäten bei Datumsformaten.
+
+**Empfehlung:** Es muss zwingend auf eine neuere Version (z.B. **0.62.0+** oder ein Snapshot vom Dez 2025) aktualisiert werden, die explizit gegen Kotlin 2.2 oder 2.3 gebaut wurde. Falls keine stabile Version verfügbar ist, muss der Server-Teil temporär auf Kotlin 2.2 gepinnt werden, was jedoch den Rest des Stacks ausbremst.
+
+### 5.2 Client-Seite: Room vs. SQLDelight
+
+Im KMP-Bereich (Android/iOS) konkurrieren **Room 2.8.4** und **SQLDelight 2.2.1**.
+
+* **Room 2.8.4:** Google hat Room im Jahr 2025 erfolgreich zu einer echten KMP-Lösung transformiert (Android, iOS, JVM, Native). Es nutzt einen gebündelten SQLite-Treiber, was konsistentes Verhalten über Plattformen hinweg garantiert.
+* **SQLDelight 2.2.1:** Der traditionelle Platzhirsch für KMP-Datenbanken.
+
+**Architektonische Bewertung:**
+Die parallele Nutzung beider Frameworks bläht die App unnötig auf (zwei Compiler-Plugins, zwei Laufzeitumgebungen, erhöhte Build-Zeit).
+Da Room 2.8.4 nun vollen KMP-Support bietet und sich nahtlos in die Jetpack-Architektur (ViewModel, Paging) integriert, empfiehlt sich für Teams mit Android-Hintergrund eine **Konsolidierung auf Room**. SQLDelight ist nur dann vorzuziehen, wenn die volle Kontrolle über SQL-Statements explizit gewünscht ist oder Legacy-Code dies erzwingt. In einem "Greenfield"-Szenario sollte eines der beiden Frameworks eliminiert werden.
+
+---
+
+## 6. Empfohlene Kompatibilitätsmatrix (Best Compatibility List)
+
+Basierend auf der Analyse der Interdependenzen zum Stichtag **Januar 2026** wird folgende bereinigte Versionsliste empfohlen. Diese Konfiguration löst den Spring-Cloud-Konflikt, synchronisiert die Kotlin-Versionen und stabilisiert den UI-Build.
+
+### 6.1 Core & Backend Stack
+
+| Komponente | Version (User) | **Empfohlene Version** | Status / Begründung |
+| --- | --- | --- | --- |
+| **Java SDK** | 25 | **25 (LTS)** | **Validiert.** Fundament für Performance (Loom, Compact Headers). |
+| **Kotlin** | 2.3.0 | **2.3.0** | **Validiert.** Ermöglicht Swift Export & K2 Features. |
+| **Spring Boot** | 3.5.9 | **3.5.9** | **Validiert.** Stabilste Version der 3.x Linie. |
+| **Spring Cloud** | 2025.1.0 | **2025.0.1** | **KORREKTUR ERFORDERLICH.** "Oakwood" (2025.1) benötigt Boot 4.0. "Northfields" (2025.0) ist korrekt für Boot 3.5. |
+| **Exposed** | 0.61.0 | **1.0.0-rc-4** | **Upgrade.** 0.61.0 ist zu alt (April 2025) für Kotlin 2.3. Suchen Sie nach Releases ab Q4 2025. |
+| **Micrometer** | (implizit) | **1.16.1** | **Empfohlen.** Explizites Upgrade für besseren Java 25 Support empfohlen. |
+
+### 6.2 Multiplatform Client Stack
+
+| Komponente | Version (User) | **Empfohlene Version** | Status / Begründung |
+| --- | --- |------------------------| --- |
+| **Compose Multiplatform** | 1.9.3 | **1.10.0-rc02**        | **Upgrade.** Zwingend für volle Kotlin 2.3 Kompatibilität (R8 fixes) und Stabilität. |
+| **Ktor Client** | 3.3.3 | **3.3.3**              | **Upgrade.** Aligniert mit Kotlin 2.3.0 & behebt iOS SSE Bugs. |
+| **Koin** | 4.1.1 | **4.1.1**              | **Validiert.** Stabil. Prüfen auf 4.2 bei Verfügbarkeit. |
+| **Room** | 2.8.4 | **2.8.4**              | **Validiert.** Exzellenter KMP Support. Empfohlen als primäre DB. |
+| **SQLDelight** | 2.2.1 | **(Entfernen)**        | **Konsolidierung.** Redundant zu Room. Empfehlung: Entfernen zur Reduktion der Komplexität. |
+
+### 6.3 Build-System Konfiguration (`libs.versions.toml`)
+
+Die folgende Konfiguration korrigiert die Fehler der `libs.versions.toml` vom Juli 2025 und aktualisiert sie auf den Stand Januar 2026.toml
+
+```
+  [versions]
+  # Core
+  java = "25"
+  kotlin = "2.3.0"
+  agp = "9.0.0"  # Android Gradle Plugin 9.0 ist Standard für diesen Stack
+  
+  # Server
+  springBoot = "3.5.9"
+  springCloud = "2025.0.1" # KORRIGIERT von 2025.1.0 (Oakwood -> Northfields)
+  exposed = "1.0.0-rc-4"       # Platzhalter für aktuellste Version
+  
+  # Client / KMP
+  composeMultiplatform = "1.10.0-rc02" # UPGRADE von 1.9.3
+  ktor = "3.3.3"                  # UPGRADE von 3.3.3
+  room = "2.8.4"
+  koin = "4.1.1"
+```
+
+---
+
+## 7. Migrationsstrategie und Risikomanagement
+
+### 7.1 Auflösung des Spring Cloud Konflikts
+Die Migration von Spring Cloud 2025.1.0 auf 2025.0.1 ist kein Feature-Downgrade, sondern eine **Kompatibilitätskorrektur**.
+*   **Aktion:** In der `build.gradle.kts` muss das `spring-cloud-dependencies` BOM ausgetauscht werden.
+*   **Verifikation:** Starten Sie den Application Context. Überprüfen Sie, ob `Actuator` Endpoints erreichbar sind. Achten Sie auf Logs bezüglich `jakarta.*` Packages – Fehler hier deuten darauf hin, dass noch transitive Abhängigkeiten zu Boot 4.0/Cloud Oakwood bestehen.
+
+### 7.2 Kotlin 2.3.0 & Compiler Plugins
+Der Einsatz von Kotlin 2.3.0 erfordert Disziplin bei den Compiler-Plugins.
+*   **Room KSP:** Stellen Sie sicher, dass der KSP-Prozessor in der Version verwendet wird, die exakt zum Kotlin 2.3.0 Compiler passt. Eine Diskrepanz (z.B. KSP für Kotlin 2.2.20) führt zu sofortigen Build-Fehlern ("Class version mismatch").
+*   **Compose Compiler:** Entfernen Sie explizite Versionsangaben für den Compose Compiler, wenn Sie das offizielle Kotlin-Plugin nutzen, da der Compiler nun gebündelt ist. Erzwingen Sie keine alte Version.
+
+### 7.3 Bereinigung der Datenbank-Abhängigkeiten
+Entscheiden Sie sich strategisch für **Room** oder **SQLDelight**.
+*   Wenn Sie Room wählen: Entfernen Sie das SQLDelight Gradle Plugin und alle `sqldelight`-Dependencies. Dies beschleunigt den Build signifikant, da ein kompletter Code-Generierungsschritt entfällt.
+*   Wenn Sie SQLDelight wählen: Entfernen Sie die Room KSP-Prozessoren.
+
+## Fazit
+
+Der vorgeschlagene Technologie-Stack ist in seiner Konzeption **visionär und leistungsfähig**. Er nutzt die massiven Fortschritte von Java 25 und Kotlin 2.3.0, um eine effiziente, plattformübergreifende Architektur zu schaffen.
+Die ursprüngliche Zusammenstellung enthielt jedoch mit der **Spring Cloud Versionierung** einen fatalen Fehler und mit der **Compose/Exposed-Versionierung** signifikante Stabilitätsrisiken. Durch die Anwendung der in diesem Bericht definierten **Best Compatibility List** – insbesondere dem Wechsel auf Spring Cloud Northfields und Compose 1.10.0 – wird der Stack von einem experimentellen Zustand in eine robuste, produktionstaugliche Enterprise-Lösung überführt.

docs/Technischer_Kompatibilitäs-Architektur_KMP-2-3-0_Ökosystem.md

@@ -0,0 +1,218 @@
+# Technischer Kompatibilitäts- und Architekturbericht: Kotlin Multiplatform 2.3.0 Ökosystem
+
+## 1. Strategische Einordnung und exekutive Zusammenfassung
+
+Die Veröffentlichung von Kotlin 2.3.0 am 16. Dezember 2025 markiert einen signifikanten Wendepunkt in der Reifeentwicklung des Kotlin Multiplatform (KMP) Ökosystems. Für Softwarearchitekten und Entwicklungsleiter, die eine Einführung oder Migration auf diese Version planen, stellt sich die Landschaft nicht mehr als experimentelles Feld dar, sondern als eine streng typisierte, hochintegrierte Plattform, die jedoch eine präzise Orchestrierung der Versionen erfordert. Nach der fundamentalen Umstellung auf den K2-Compiler in Version 2.0.0 fokussiert sich die Version 2.3.0 auf die Stabilisierung der Sprachfeatures, die strikte Durchsetzung von Typ-Sicherheit und die Synchronisation mit der modernen Java-Welt, spezifisch Java 25.
+
+Die zentrale Herausforderung bei der Adoption von Kotlin 2.3.0 liegt nicht in der Sprache selbst, sondern in der Interdependenz mit den Build-Systemen und Frameworks, die zeitgleich massive Versionssprünge vollziehen. Wir beobachten eine kritische Konvergenz dreier Hauptstränge im ersten Quartal 2026:
+
+1. **Der Build-System-Shift:** Der Übergang von Gradle 8.x auf Gradle 9.0 und die damit einhergehende fundamentale Änderung im Android Gradle Plugin (AGP) 9.0, welches die separate Deklaration des Kotlin-Android-Plugins obsolet macht.
+
+
+2. **Der Backend-Baseline-Shift:** Die Veröffentlichung von Spring Boot 4.0, welches zwar auf einer Kotlin 2.2 Baseline basiert, aber architektonisch für die Nutzung mit Kotlin 2.3 und Java 25 vorbereitet ist.
+
+
+3. **Die UI-Konsolidierung:** Compose Multiplatform 1.10.0, das erstmals eine vereinheitlichte Preview-Logik und stabile Navigation (Navigation 3.0) bietet, wodurch die Fragmentierung zwischen Android- und Desktop-Entwicklung drastisch reduziert wird.
+
+
+
+Dieser Bericht analysiert diese Abhängigkeiten tiefgehend und definiert die notwendigen Konfigurationen für eine stabile, produktive Entwicklungsumgebung. Er richtet sich an technische Entscheidungsträger, die Risiken minimieren und die Langlebigkeit ihrer KMP-Architektur sicherstellen müssen.
+
+## 2. Kernsprache und Compiler-Infrastruktur
+
+Das Fundament jeder KMP-Architektur im Jahr 2026 ist der K2-Compiler in der Version 2.3.0. Es ist essenziell zu verstehen, dass Kotlin 2.3.0 nicht nur neue Features bringt, sondern auch permissives Verhalten der Vergangenheit korrigiert. Dies hat direkte Auswirkungen auf die Kompatibilität von bestehendem Code und Bibliotheken.
+
+### 2.1 Der K2-Compiler: Striktheit und Sicherheit
+
+Mit Version 2.3.0 verlässt JetBrains endgültig die Toleranzphasen der K1-Ära. Der Compiler erzwingt nun Muster, die zuvor bestenfalls Warnungen erzeugten. Ein prominentes Beispiel hierfür ist der **Unused Return Value Checker**. In der funktionalen Programmierung und insbesondere in der asynchronen Programmierung mit Coroutinen ist der Rückgabewert oft das einzige Indiz für den Erfolg oder das Handle einer Operation (z.B. ein `Job`-Objekt). Das Ignorieren solcher Werte führte in der Vergangenheit oft zu subtilen Bugs, bei denen Hintergrundprozesse "fire-and-forget" gestartet wurden, ohne dass das aufrufende System deren Lebenszyklus kontrollierte. Der neue Checker in Kotlin 2.3.0 hebt dieses Problem auf die Ebene eines Compiler-Fehlers oder einer strikten Warnung, was die Codequalität in komplexen Multiplatform-Projekten inhärent erhöht, aber auch Refactoring in bestehenden Codebasen erzwingen kann.
+
+Darüber hinaus wurde die **Kontext-sensitive Auflösung** (Context-Sensitive Resolution) überarbeitet. Dies betrifft vorwiegend DSLs (Domain Specific Languages), wie sie in Gradle-Build-Skripten (`build.gradle.kts`) oder in Compose UI-Deklarationen verwendet werden. In früheren Versionen gab es Inkonsistenzen in der Typinferenz, abhängig davon, ob ein Lambda als Top-Level-Konstrukt oder als Argument übergeben wurde. Kotlin 2.3.0 harmonisiert dieses Verhalten. Für den Entwickler bedeutet dies weniger "magische" Typfehler in komplexen UI-Hierarchien, erfordert aber unter Umständen Anpassungen in eigenen DSL-Bibliotheken, da der Compiler nun strenger auf Typ-Hierarchien achtet.
+
+### 2.2 Java 25 Interoperabilität und Bytecode-Generierung
+
+Ein strategisches Highlight von Kotlin 2.3.0 ist die explizite Unterstützung für **Java 25**. Während viele Android-Projekte noch auf Java 17 oder 21 basieren, ermöglicht Kotlin 2.3.0 für reine JVM-Module (z.B. im Backend mit Spring Boot oder Ktor) die Generierung von Bytecode, der die neuesten Instruktionen und Optimierungen der Java Virtual Machine 25 nutzt.
+
+Dies hat weitreichende Implikationen für die Build-Pipeline. Wenn ein KMP-Projekt Java 25 Features nutzt, muss sichergestellt sein, dass nicht nur der Kompilierungs-Classpath (JDK Home), sondern auch die Runtime-Umgebung (Docker-Container, CI-Server) über eine Java 25 Runtime verfügt. Die Standard-Einstellung des Kotlin-Compilers bleibt, falls nicht anders konfiguriert, oft konservativ (z.B. 1.8 oder die Version der Gradle-Daemon-JVM), weshalb die explizite Konfiguration der `jvmToolchain` in Gradle zwingend erforderlich wird, um Diskrepanzen zwischen Entwicklungsumgebung und Produktionsumgebung zu vermeiden.
+
+### 2.3 Migration und Deprecations
+
+Der Übergang zu Kotlin 2.3.0 zieht harte Grenzen bezüglich veralteter Konfigurationen:
+
+* **Sprachversionen:** Die Unterstützung für `-language-version 1.8` wurde komplett entfernt. Noch kritischer für Multiplatform-Projekte ist, dass `-language-version 1.9` für Nicht-JVM-Plattformen (Native, JS, Wasm) ebenfalls entfernt wurde. Das bedeutet, dass Projekte nicht mehr temporär auf einem alten Sprachlevel verharren können, um Inkompatibilitäten im Native-Code zu umgehen – der Code muss K2-konform sein.
+
+
+* **Bitcode:** Für iOS-Targets wurde die `embedBitcode` DSL endgültig entfernt. Dies spiegelt Apples Entscheidung wider, Bitcode in Xcode 15/16 abzuschaffen. Build-Skripte, die noch `embedBitcode` enthalten, werden unter Kotlin 2.3.0 brechen und müssen bereinigt werden.
+
+
+
+**Tabelle 1: Kernkomponenten und Versionierung**
+
+| Komponente | Version | Status | Kritische Anmerkung / Anforderung |
+| --- | --- | --- | --- |
+| **Kotlin Compiler** | **2.3.0** | Stable | Erzwingt K2-Semantik; Java 25 Support 
+
+|
+| **API Version** | 2.3 | Stable |  |
+| **Sprachversion** | 2.3 | Stable | Support für 1.8 (alle) und 1.9 (non-JVM) entfernt
+
+|
+| **JVM Target** | Bis 25 | Stable | Toolchain-Konfiguration empfohlen |
+| **IntelliJ IDEA** | 2025.3+ | Required | Plugin ist in 2025.3+ gebündelt
+
+|
+
+## 3. Build-System Architektur: Gradle und AGP
+
+Die wohl komplexeste Abhängigkeitsmatrix bei der Einführung von Kotlin 2.3.0 betrifft das Build-System. Hier treffen die Zyklen von Gradle, dem Android Gradle Plugin (AGP) und dem Kotlin Gradle Plugin (KGP) aufeinander.
+
+### 3.1 Die Gradle-Basisinfrastruktur
+
+Kotlin 2.3.0 unterstützt ein breites Spektrum an Gradle-Versionen, beginnend bei 7.6.3 bis hin zum brandneuen Gradle 9.0.0. Diese Breite ist jedoch trügerisch. Für ein modernes KMP-Projekt, das 2026 gestartet wird, ist die Nutzung von Gradle-Versionen unter 8.0 nicht empfehlenswert.
+
+Der Grund liegt in der Validierung der JVM-Targets. Gradle 8.0+ hat das Standardverhalten bei Inkompatibilitäten der JVM-Targets von einer bloßen Warnung (`warning`) zu einem Fehler (`error`) geändert. Dies schützt Entwickler davor, versehentlich Bibliotheken einzubinden, die mit einer neueren Java-Version kompiliert wurden als das Projekt selbst unterstützt. Da Kotlin 2.3.0 standardmäßig Java 25 unterstützt, ist diese strikte Validierung essenziell, um "Class File Version"-Fehler zur Laufzeit zu vermeiden.
+
+**Empfehlung:** Setzen Sie auf **Gradle 8.11.1** oder, falls Sie die neuesten AGP-Features nutzen wollen, direkt auf **Gradle 9.0.0**. Gradle 9.0.0 setzt zwingend eine Java 17 Runtime für den Daemon voraus, was mit den Anforderungen moderner Android-Entwicklung harmoniert.
+
+### 3.2 Die Zäsur: Android Gradle Plugin (AGP) 9.0
+
+Mit AGP 9.0 (Release-Zeitraum März 2025, stabil im Jan 2026 verfügbar) vollzieht Google einen Paradigmenwechsel in der Integration von Kotlin.
+In Versionen vor 9.0 musste jedes Android-Modul explizit das `kotlin-android` Plugin anwenden. AGP 9.0 hingegen besitzt eine **eingebaute Laufzeitabhängigkeit** zum Kotlin Gradle Plugin.
+
+Das bedeutet konkret: Wenn Sie AGP 9.0.0 verwenden, ist das explizite Anwenden von `id("org.jetbrains.kotlin.android")` in Ihren `build.gradle.kts` Dateien nicht nur redundant, sondern deprecated und wird Warnungen erzeugen. Kotlin 2.3.0 erkennt AGP 9.0 und deaktiviert die interne Logik des alten Plugins, um Konflikte zu vermeiden. Dies erfordert jedoch ein Umdenken bei der Konfiguration der Build-Skripte.
+
+Für Projekte, die noch nicht bereit sind, auf die absolute "Bleeding Edge" von AGP 9.0 zu wechseln, bietet **AGP 8.13.0** den stabilsten Hafen. Diese Version ist vollständig kompatibel mit Kotlin 2.3.0, unterstützt Java 17 Toolchains und erfordert keine strukturellen Änderungen an den Plugin-Blöcken.
+
+### 3.3 Kompatibilitätsmatrix Build-Tools
+
+Die folgende Matrix visualisiert die getesteten und unterstützten Kombinationen für Kotlin 2.3.0.
+
+Tabelle 2: Gradle & AGP Kompatibilität für Kotlin 2.3.0
+
+| Android Gradle Plugin (AGP) Version | Min. Gradle Version | Max. Gradle Version | Kompatibilitäts-Status mit Kotlin 2.3.0 | Empfohlenes Szenario |
+| --- | --- | --- | --- | --- |
+| **9.0.0 / 9.1.0** (Alpha/Beta) | 9.0.0 | 9.x | **Unterstützt** (Deprecated `kotlin-android` Plugin) | Green-Field Projekte mit höchstem Modernitätsanspruch |
+| **8.13.x** | 8.7+ | 8.14 | **Voll Unterstützt** | **Produktions-Standard** für Q1 2026 |
+| **8.10.x - 8.12.x** | 8.7+ | 8.11+ | **Voll Unterstützt** | Stabile Bestandsprojekte |
+| **8.2.2 - 8.9.x** | 8.2+ | 8.9+ | **Unterstützt** | Legacy-Wartung |
+| **< 8.2.2** | - | - | **Inkompatibel** | Migration zwingend erforderlich |
+
+### 3.4 Java Toolchains Konfiguration
+
+Ein häufig übersehener Aspekt ist die korrekte Konfiguration der Java Toolchain. Da Kotlin 2.3.0 und AGP 8.x+ die Kompilierung von der Gradle-Daemon-JVM entkoppeln, muss die `jvmToolchain` im `kotlin`-Block definiert werden.kotlin
+
+```
+// build.gradle.kts (Root oder Shared Module)
+kotlin {
+// Definiert die Java-Version für die Kotlin-Kompilierung (z.B. 17 oder 21 für Android)
+jvmToolchain(21)
+}
+```
+
+Ohne diese Definition versucht Gradle, die Java-Version des Daemons zu nutzen, was in CI/CD-Umgebungen (wo oft unterschiedliche JDKs installiert sind) zu nicht-reproduzierbaren Builds führen kann.[8]
+
+## 4. UI-Framework: Compose Multiplatform (CMP)
+
+Für die Entwicklung der Benutzeroberfläche in einem KMP-Projekt ist Compose Multiplatform (CMP) die Standardwahl. Hierbei ist eine wichtige Unterscheidung in der Versionierung zu treffen, die oft zu Verwirrung führt: Die Trennung zwischen **Compiler-Plugin** und **Laufzeit-Bibliothek**.
+
+### 4.1 Compose Compiler: Version 2.3.0
+
+Seit Kotlin 2.0.0 ist der Compose Compiler direkt in das Kotlin-Repository integriert. Das bedeutet, es gibt keine separate Versionierung mehr für den Compiler.
+*   **Anforderung:** Wenn Sie Kotlin 2.3.0 verwenden, **müssen** Sie den Compose Compiler in Version 2.3.0 verwenden.
+*   **Integration:** Dies geschieht über das Gradle-Plugin `org.jetbrains.kotlin.plugin.compose`. Alte Referenzen auf `androidx.compose.compiler:compiler` müssen zwingend entfernt werden, da diese Artefakte nicht mehr mit dem K2-Compiler kompatibel sind.[11]
+
+### 4.2 Compose Laufzeit & UI: Version 1.10.0
+
+Während der Compiler an Kotlin gebunden ist, entwickeln sich die UI-Bibliotheken (Foundation, Material, Runtime) eigenständig weiter. Für Kotlin 2.3.0 ist die kompatible Version **Compose Multiplatform 1.10.0** (veröffentlicht im Dezember 2025).[6, 12]
+
+Diese Version bringt massive Verbesserungen für die Cross-Plattform-Entwicklung:
+1.  **Vereinheitlichte `@Preview` Annotation:** Bis Version 1.9 mussten Entwickler unterschiedliche Annotationen für Android-Previews (`androidx...`) und Desktop-Previews (`org.jetbrains...` oder desktop-spezifisch) nutzen. CMP 1.10.0 führt eine unified Annotation in `commonMain` ein.[6] Dies reduziert Boilerplate-Code signifikant und ermöglicht es, UI-Komponenten direkt im gemeinsamen Code zu visualisieren, ohne plattformspezifische Stubs erstellen zu müssen.
+2.  **Navigation 3.0:** Mit CMP 1.10.0 wird Navigation 3.0 stabil. Dies löst den veralteten `PredictiveBackHandler` ab und bietet eine typsichere, ereignisgesteuerte Navigationsstruktur, die auch Deep-Linking auf iOS und Desktop unterstützt.[6]
+3.  **Web (Wasm/HTML) Reife:** Die Version 1.10.0 bringt erstmals Accessibility-Support für Web-Targets.[13] Dies ist ein entscheidender Schritt für Enterprise-Anwendungen, da Barrierefreiheit oft eine harte Anforderung für interne Tools darstellt. Zudem wurde die API zum Einbetten von HTML-Inhalten verbessert, was hybride Ansätze erleichtert.
+
+**Tabelle 3: Compose Multiplatform Konfiguration**
+
+| Komponente | Version | Gradle Plugin / Artefakt | Anmerkung |
+| :--- | :--- | :--- | :--- |
+| **Compiler Plugin** | **2.3.0** | `org.jetbrains.kotlin.plugin.compose` | Version muss exakt Kotlin-Version matchen |
+| **Gradle Plugin** | **1.10.0** | `org.jetbrains.compose` | Steuert Abhängigkeiten und Multiplatform-Tasks |
+| **Runtime Libs** | **1.10.0** | `org.jetbrains.compose.runtime:runtime` | Basiert auf Jetpack Compose 1.10/Material 1.4 |
+| **Material 3** | **1.4.0** | `org.jetbrains.compose.material3:material3` | [14] |
+
+## 5. Backend-Integration: Spring Boot 4.0
+
+Für KMP-Projekte, die nicht nur Clients, sondern auch Server-Komponenten umfassen (Full-Stack Kotlin), ist die Kompatibilität mit Spring Boot entscheidend.
+
+### 5.1 Spring Boot 4.0 und die "Kotlin 2.2 Baseline"
+
+Spring Boot 4.0 (erschienen Nov 2025) basiert offiziell auf einer **Kotlin 2.2 Baseline**.[5, 15] Dies ist eine bewusste Entscheidung des Spring-Teams, um Bibliotheksentwicklern Stabilität zu garantieren und nicht sofort auf den allerneuesten Compiler zu zwingen.
+Das bedeutet jedoch **nicht**, dass Kotlin 2.3.0 inkompatibel ist. Im Gegenteil: Spring Boot 4.0 ist darauf ausgelegt, mit neueren Kotlin-Versionen zu laufen ("forward compatibility").
+
+**Integrations-Strategie:**
+Um Kotlin 2.3.0 in einem Spring Boot 4.0 Projekt zu nutzen, müssen Sie die von Spring verwaltete Kotlin-Version überschreiben. In `build.gradle.kts` geschieht dies typischerweise im `plugins`-Block oder über `ext["kotlin.version"] = "2.3.0"`. Da Kotlin eine strikte binäre Rückwärtskompatibilität pflegt, funktioniert der Spring Boot 4.0 Bytecode (kompiliert mit 2.2) problemlos mit der 2.3.0 Runtime.
+
+### 5.2 Serialisierung: Jackson vs. Kotlinx.Serialization
+
+Ein kritischer Punkt in Spring Boot 4.0 ist die Behandlung von JSON. Spring Boot 4.0 führt ein neues Starter-Modul ein: `spring-boot-starter-kotlinx-serialization-json`.[5]
+*   **Das Problem:** Da Spring Boot 4.0 auf der 2.2 Baseline fußt, zieht dieser Starter standardmäßig eine Version von `kotlinx.serialization`, die evtl. nicht optimal für Kotlin 2.3.0 ist.
+*   **Die Lösung:** Wenn Sie diesen Starter nutzen, müssen Sie sicherstellen, dass Sie explizit die `kotlinx.serialization` Version **1.10.0** erzwingen (siehe Abschnitt Bibliotheken), da diese Version mit dem Kotlin 2.3.0 Compiler-Plugin synchronisiert ist.[5]
+
+## 6. Essenzielle Bibliotheken und Versionen
+
+Ein KMP-Projekt steht und fällt mit der Kompatibilität seiner Kernbibliotheken. Da Kotlin 2.3.0 Änderungen im Compiler (K2) mitbringt, müssen Bibliotheken, die Compiler-Plugins nutzen oder tief in die IR (Intermediate Representation) eingreifen, aktualisiert werden.
+
+### 6.1 Kotlinx.Coroutines: 1.10.2
+
+Für asynchrone Programmierung ist **Version 1.10.2** die korrekte Wahl für Kotlin 2.3.0.[16]
+Diese Version beinhaltet Anpassungen an die neuen Kontext-sensitiven Auflösungen des Compilers und behebt spezifische Memory-Leaks im Native-Memory-Management, die bei der Nutzung von Flows auf iOS auftreten konnten.
+
+### 6.2 Kotlinx.Serialization: 1.10.0
+
+Hier ist strikte Disziplin erforderlich. Das Serialization-Plugin greift direkt in den Kompilierungsprozess ein.
+*   **Regel:** Die Version des Gradle-Plugins (`kotlin("plugin.serialization")`) muss **2.3.0** sein.
+*   **Regel:** Die Version der Laufzeitbibliothek (`kotlinx-serialization-json`) sollte **1.10.0** (oder der zum Release-Zeitpunkt verfügbare RC) sein.[17] Mischmasch-Versionen führen hier unweigerlich zu `java.lang.NoSuchMethodError` oder Compiler-Abstürzen.
+
+### 6.3 Netzwerkschicht: Ktor & Okio
+*   **Ktor:** Die Versionen **3.2.2** oder **3.3.0** sind kompatibel. Ktor 3.3.0 bringt zudem verbesserte Unterstützung für OpenAPI und WebRTC, was gut mit den neuen Web-Fähigkeiten von Compose harmoniert.
+*   **Okio/AtomicFU:** Nutzen Sie AtomicFU **0.29.0** für atomare Operationen im Multiplatform-Code.[14]
+
+**Tabelle 4: Empfohlener "Bill of Materials" (BOM) für Kotlin 2.3.0**
+
+| Bibliothek | Empfohlene Version | Gradle Koordinaten | Grund / Abhängigkeit |
+| :--- | :--- | :--- | :--- |
+| **Coroutines** | 1.10.2 | `org.jetbrains.kotlinx:kotlinx-coroutines-core` | K2-Kompatibilität [16] |
+| **Serialization** | 1.10.0 | `org.jetbrains.kotlinx:kotlinx-serialization-json` | Sync mit Compiler 2.3.0 [17] |
+| **DateTime** | 0.7.1 | `org.jetbrains.kotlinx:kotlinx-datetime` | Fixes für Wasm/JS [14] |
+| **Ktor Client** | 3.2.2 / 3.3.0 | `io.ktor:ktor-client-core` | Stabile Netzwerk-Layer |
+| **SQLDelight** | 2.0.2+ | `app.cash.sqldelight` | Datenbank-Support |
+| **Koin** | 4.0.0+ | `io.insert-koin:koin-core` | Dependency Injection für KMP |
+
+## 7. Migration und Projektaufbau: Eine Roadmap
+
+Für den Aufbau eines neuen Projekts ("Greenfield") oder die Migration eines bestehenden ("Brownfield") ergeben sich aus den oben genannten Daten klare Handlungsempfehlungen.
+
+### 7.1 Szenario A: Neues Projekt (Greenfield)
+
+Starten Sie direkt mit dem modernsten Stack, um technische Schulden in 2026 zu vermeiden.
+1.  **Gradle:** Setzen Sie `distributionUrl` auf **Gradle 9.0**.
+2.  **AGP:** Nutzen Sie **AGP 9.0.0** (oder RC). Verzichten Sie in den Modul-Build-Files auf `id("kotlin-android")`. Der `com.android.application` Plugin-Block ist ausreichend.
+3.  **Kotlin:** `version "2.3.0"` im `libs.versions.toml`.
+4.  **Compose:** Plugin Version `1.10.0`.
+5.  **Struktur:** Nutzen Sie die neue Projektstruktur, die Logik strikt in `commonMain` hält und plattformspezifische Ordner (`androidMain`, `iosMain`) nur für echte Interop-Fälle (z.B. Bluetooth, Kamera) verwendet.
+
+### 7.2 Szenario B: Migration (Brownfield)
+
+Die Migration ist risikobehafteter, insbesondere wegen der veralteten Sprachversionen.
+1.  **Code-Bereinigung:** Entfernen Sie alle Referenzen auf `-language-version 1.8` oder `1.9` (für Native). Der Code muss compilieren, ohne dass diese Flags gesetzt sind.
+2.  **Bitcode entfernen:** Löschen Sie alle `embedBitcode`-Blöcke aus den Gradle-Skripten.
+3.  **Schrittweises Upgrade:**
+    *   Upgrade Gradle auf 8.11.1 (sicherer Zwischenschritt vor 9.0).
+    *   Upgrade AGP auf 8.13.0 (vermeidet den Plugin-DSL-Bruch von AGP 9.0 vorerst).
+    *   Upgrade Kotlin auf 2.3.0 und Compose auf 1.10.0.
+    *   Upgrade der Bibliotheken (Coroutines, Serialization).
+4.  **Validierung:** Prüfen Sie Warnungen des "Unused Return Value Checkers". In vielen Fällen deckt dieser Checker logische Fehler in der Fehlerbehandlung von Netzwerk-Calls auf.
+
+## 8. Fazit und Ausblick
+
+Kotlin 2.3.0 ist keine einfache inkrementelle Version, sondern ein stabilisierender Meilenstein, der das Ökosystem auf die Post-K2-Ära einschwört. Die Kompatibilität ist gewährleistet, sofern man die "Regeln des Spiels" beachtet: **Synchronisation von Compiler- und Bibliotheks-Versionen**, **Beachtung der AGP-9.0-Zäsur** und **Verwendung moderner Gradle-Infrastruktur**.
+
+Für Entwickler bietet die Kombination aus Kotlin 2.3.0, Compose 1.10.0 und Spring Boot 4.0 eine mächtige, durchgängig typisierte Plattform, die von der Datenbank (via Exposed/SQLDelight) über das Backend (Spring Boot/Ktor) bis hin zur UI auf iOS, Android und Web (Compose) reicht. Die Investition in die korrekte Einrichtung der Build-Skripte zu Beginn des Projekts amortisiert sich durch die massive Reduktion von "Dependency Hell"-Problemen im weiteren Projektverlauf.

gradle/libs.versions.toml

@@ -4,7 +4,7 @@
 
 [versions]
 # --- Android Ecosystem ---
-# agp = "8.1.4"
+# agp = "8.13"
 
 # --- Kotlin Ecosystem ---
 kotlin = "2.3.0"
@@ -16,16 +16,17 @@ kotlinx-coroutines = "1.10.2"
 
 
 # --- Spring Ecosystem ---
-# KORREKTUR: Version auf Benutzerwunsch angepasst (war 4.0.1)
+# Spring Boot 3.5.x Linie (kompatibel zu Spring Framework 6.2)
 springBoot = "3.5.9"
-# Spring Cloud Version kompatibel zu Spring Boot
-springCloud = "2025.1.0"
+# Spring Cloud Release Train kompatibel zu Spring Boot 3.5.x → Northfields (2025.0.x)
+springCloud = "2025.0.1"
 # springCloudGateway = "4.3.0"
 springDependencyManagement = "1.1.7"
 springdoc = "3.0.0"
 
 # --- Ktor (API Layer & Client) ---
-ktor = "3.3.3"
+# Kotlin 2.3.0 Alignment + iOS SSE Fix
+ktor = "3.4.0"
 
 # --- DI ---
 koin = "4.1.1"
@@ -34,10 +35,12 @@ koinCompose = "4.1.1"
 # --- Compose UI ---
 androidx-lifecycle = "2.9.6"
 composeHotReload = "1.0.0"
-composeMultiplatform = "1.9.3"
+# Für Kotlin 2.3.0 erforderlich (R8/StackTrace Fixes, Wasm Reife)
+composeMultiplatform = "1.10.0"
 
 # --- Database & Persistence ---
-exposed = "0.61.0"
+# Stabil für Kotlin 2.3.0 (anstelle von 0.61.0)
+exposed = "0.62.0"
 postgresql = "42.7.8"
 hikari = "7.0.2"
 h2 = "2.4.240"