Standardize documentation with headers and archive old files

Applied a unified header format to all documentation files for better status identification, referencing, and ownership tracking. Archived outdated roadmaps, reports, and journal entries. Updated playbooks with new responsibilities, lifecycle rules, and consistent handover formats to align with the new archiving strategy.
2026-01-16 12:17:47 +01:00
parent 39ba21fd77
commit 3465cab246
23 changed files with 393 additions and 212 deletions
@@ -1,59 +1,10 @@
-# Architecture & Build Status Report
-**Datum:** 09.01.2026
-**Von:** Senior Backend Developer
-**An:** Lead Software Architect
-
-## 1. Executive Summary
-Wir haben eine umfassende Stabilisierung der Projekt-Architektur durchgeführt. Kritische Versionskonflikte im Backend (Spring Boot vs. Spring Cloud) wurden behoben. Die Trennung zwischen Frontend (KMP) und Backend (JVM) wurde durch Refactoring des `core`-Bereichs strikt durchgesetzt, um "Pollution" durch JVM-Code im Frontend zu verhindern.
-
-Der Build-Prozess ist derzeit noch durch spezifische **Kotlin/Wasm Kompilierungsfehler** blockiert, die aus der strikten Typisierung und dem JS-Interop von WebAssembly resultieren.
-
+---
+type: Report
+status: ARCHIVED
+owner: Backend Developer
+last_update: 2026-01-15
 ---

-## 2. Durchgeführte Maßnahmen
+# Backend Status Report

-### 2.1 Backend Architecture Alignment
-*   **Spring Cloud Konflikt gelöst:** Downgrade von `2025.1.0` (Oakwood, inkompatibel mit Boot 3.5) auf **`2025.0.1` (Northfields)**. Dies verhindert garantierte Laufzeitfehler (`NoSuchMethodError`).
-*   **Java 25 Optimierung:** Upgrade von Micrometer auf `1.16.1` für besseren Virtual Thread Support.
-*   **Exposed Versionierung:** Bestätigung der Nutzung von `1.0.0-rc-4` (statt der veralteten 0.61.0).
-
-### 2.2 Modul-Hygiene & KMP Trennung
-*   **Refactoring `core:core-utils`:**
-    *   Das Modul enthielt JVM-spezifischen Code (`DatabaseUtils.kt` mit Exposed-Abhängigkeiten), der den Frontend-Build (JS/Wasm) brach.
-    *   **Lösung:** Erstellung eines neuen Moduls **`:backend:infrastructure:persistence`**. Der DB-Code wurde dorthin verschoben. `core:core-utils` ist nun ein reines KMP-Modul.
-*   **Zirkuläre Abhängigkeiten aufgelöst:**
-    *   Das Modul `frontend:shared` hatte Abhängigkeiten zu Feature-Modulen und dem Design-System, was zu Zyklen führte.
-    *   **Lösung:** `frontend:shared` wurde bereinigt und dient nun rein als Basis-Layer (Config, Utils).
-
-### 2.3 Build-System (Gradle & KMP)
-*   **Wasm-Target Konsolidierung:**
-    *   Um Inkonsistenzen bei der Dependency Resolution zu beheben, wurde das Target `wasmJs` **projektweit** in allen relevanten KMP-Modulen (`core`, `frontend`) aktiviert.
-    *   Dies löste die `Unresolved platforms: [wasmJs]` Fehler.
-
---
-
-## 3. Aktuelle Blocker (Wasm Compiler)
-
-Obwohl die Dependency-Struktur nun sauber ist, scheitert der Compiler im `wasmJs` Target an spezifischen Interop-Problemen:
-
-1.  **Fehlende Referenzen (`Unresolved reference`):**
-    *   `org.w3c.dom.Worker` und `kotlinx.browser.window` werden im Wasm-Kontext nicht gefunden.
-    *   *Ursache:* Kotlin/Wasm benötigt möglicherweise explizite Imports oder externe Deklarationen für bestimmte DOM-APIs, die in Kotlin/JS implizit waren, oder die Standard-Bibliothek wird nicht korrekt eingebunden.
-2.  **JS-Interop Einschränkungen:**
-    *   Fehler: `Type 'ERROR CLASS: Symbol not found for Worker' cannot be used as return type`.
-    *   Kotlin/Wasm erlaubt keine komplexen `js("...")` Blöcke innerhalb von Funktionen und hat keinen `dynamic` Typ. Unsere ersten Fixes (Helper-Funktionen) waren ein Schritt in die richtige Richtung, aber die Typen (wie `Worker`) müssen dem Compiler bekannt gemacht werden.
-
---
-
-## 4. Nächste Schritte (Plan)
-
-1.  **Wasm-Build reparieren:**
-    *   Prüfen, ob wir eine explizite Dependency (z.B. `kotlinx-browser` oder `kotlin-stdlib-wasm-js`) benötigen.
-    *   Falls `Worker` in der Wasm-Stdlib fehlt: Definition einer `external class Worker` für Wasm erstellen, um dem Compiler den Typ bekannt zu machen.
-2.  **Backend-Verifikation ("Bauplan"):**
-    *   Sobald der Build durchläuft (oder wir das Frontend temporär exkludieren), werde ich den **`ping-service`** starten.
-    *   Ziel: Nachweis, dass Spring Context, Datenbank-Verbindung (JPA) und die neue Modul-Struktur (`backend:infrastructure:persistence`) zur Laufzeit funktionieren.
-3.  **Sync-Strategie:**
-    *   Anschließend widmen wir uns der im Frontend-Report erwähnten "Offline-Sync"-Logik (basierend auf UUIDv7).
-
-**Empfehlung:** Wir sollten den Wasm-Build-Fix priorisieren, da er aktuell das gesamte Projekt blockiert ("Fail Fast").
+**MOVED:** This file has been archived to `_archive/2026-01-15_Backend_Status_Report_01-2026.md`.