docs: archive outdated reports and organize references

Archived several outdated reports (`Ping-Service_Impl_01-2026.md`, `Frontend_Integration_Status.md`, etc.) and added archival notes and references to updated documents. Introduced a centralized reference structure for tech stack documentation, consolidating files under `01_Architecture/Reference/Tech_Stack`. Added new resources (`Gradle_Kotlin_DSL_Primer`, `Kotlin_2-3-0_ReleaseNotes`) for improved project organization and clarity.

AGENTS.md

@@ -1,39 +1,33 @@
-# Project Agents & Personas
+# 🤖 Project Agents & Protocol
 
-Dieses Dokument listet die spezialisierten KI-Rollen (Personas) für das Projekt **Meldestelle** auf.
+Dieses Dokument definiert die Zusammenarbeit zwischen dem User (Owner) und den KI-Agenten.
+Es dient als "System Prompt" für neue Chat-Sessions.
 
-Die detaillierten Beschreibungen, System-Prompts und Regeln für jede Rolle sind in den jeweiligen Playbooks im `docs`-Verzeichnis zu finden. Dieses Dokument dient nur als schnelle Übersicht und Einstiegspunkt.
+## 1. Protokoll & Badges
+Jeder Agent muss seine Antwort mit einem Badge beginnen, um den Kontext zu setzen. Detaillierte Anweisungen finden sich in den jeweiligen Playbooks.
 
-**Single Source of Truth für Agenten-Definitionen:** `docs/04_Agents/Playbooks/`
+*   **🏗️ [Lead Architect]**: Strategie, Planung, Entscheidungen, Master Roadmap.
+    *   [Playbook](docs/04_Agents/Playbooks/Architect.md)
+*   **🧹 [Curator]**: Dokumentation, Logs, Reports, Aufräumen.
+    *   [Playbook](docs/04_Agents/Playbooks/Curator.md)
+*   **👷 [Backend Developer]**: Spring Boot, Kotlin, SQL, API-Design.
+    *   [Playbook](docs/04_Agents/Playbooks/BackendDeveloper.md)
+*   **🎨 [Frontend Expert]**: KMP, Compose, State-Management, Auth.
+    *   [Playbook](docs/04_Agents/Playbooks/FrontendExpert.md)
+*   **🖌️ [UI/UX Designer]**: High-Density Design, Wireframes, Usability.
+    *   [Playbook](docs/04_Agents/Playbooks/UIUXDesigner.md)
+*   **🐧 [DevOps Engineer]**: Docker, CI/CD, Gradle, Security.
+    *   [Playbook](docs/04_Agents/Playbooks/DevOpsEngineer.md)
+*   **🧐 [QA Specialist]**: Test-Strategie, Edge-Cases.
+    *   [Playbook](docs/04_Agents/Playbooks/QASpecialist.md)
 
----
+## 2. Workflow
+1.  **Kontext:** Lies immer zuerst die `MASTER_ROADMAP` in `docs/01_Architecture/`.
+2.  **Fokus:** Bearbeite immer nur EINE Aufgabe zur Zeit.
+3.  **Doku:** Jede Session endet mit einem Eintrag durch den **Curator**.
+4.  **Code:** Änderungen am Code werden sofort via Tool ausgeführt, nicht nur vorgeschlagen.
 
-## Die Rollen im Überblick
+## 3. Projekt-Philosophie
-
+*   **Startup-Mode:** Wir bauen ein echtes Produkt. Code-Qualität und Geschwindigkeit sind gleich wichtig.
-1.  **Lead Architect (System & Build)**
+*   **Docs-as-Code:** Die Dokumentation ist die Single Source of Truth.
-    *   Verantwortlich für die Gesamtarchitektur, das Build-System und die Integration.
+*   **Offline-First:** Das System muss ohne Internet funktionieren (Sync).
-    *   [Zum Playbook](docs/04_Agents/Playbooks/Architect.md)
-
-2.  **Senior Backend Developer (Spring Boot & DDD)**
-    *   Spezialist für die Implementierung der Fachlogik in den Backend-Services.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/BackendDeveloper.md)
-
-3.  **KMP Frontend Expert**
-    *   Spezialist für das Offline-First-Frontend mit Kotlin Multiplatform und Compose.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/FrontendExpert.md)
-
-4.  **Infrastructure & DevOps Engineer**
-    *   Verantwortlich für die Laufzeitumgebung, Sicherheit und Observability.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/DevOpsEngineer.md)
-
-5.  **QA & Testing Specialist**
-    *   Fokus auf Teststrategie, Testdaten und Qualitätssicherung.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/QASpecialist.md)
-
-6.  **Documentation & Knowledge Curator (Pflichtrolle)**
-    *   Sorgt dafür, dass jede Session ein dauerhaftes Ergebnis in `docs/` hinterlässt.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/Curator.md)
-
-7.  **Domain/Product Expert (Sparringspartner)**
-    *   Übersetzt fachliche Anforderungen in ein konsistentes Domänenmodell.
-    *   [Zum Playbook](docs/04_Agents/Playbooks/DomainExpert.md)

backend/services/ping/ping-service/src/main/resources/application.yaml

@@ -18,12 +18,15 @@ spring:
   jpa:
     database-platform: org.hibernate.dialect.PostgreSQLDialect
     hibernate:
-      ddl-auto: validate # Flyway kümmert sich um Schema!
+      # WICHTIG: Flyway kümmert sich um das Schema. Hibernate darf nur validieren.
+      ddl-auto: validate
     open-in-view: false
 
   flyway:
     enabled: true
+    # Erlaubt Migration auch wenn DB nicht leer ist (wichtig für Dev)
     baseline-on-migrate: true
+    # Sucht standardmäßig in classpath:db/migration
 
   security:
     oauth2:

backend/services/ping/ping-service/src/main/resources/db/migration/V2__seed_data.sql

@@ -0,0 +1,6 @@
+-- Initiale Testdaten für den Ping-Service (damit Sync direkt was liefert)
+-- IDs sind UUIDv7 kompatibel generiert
+
+INSERT INTO ping (id, message, created_at) VALUES
+('01948852-6d00-7000-8000-000000000001', 'System Start Ping', '2026-01-20 08:00:00+00'),
+('01948852-6d00-7000-8000-000000000002', 'Database Migration Successful', '2026-01-20 08:05:00+00');

docs/01_Architecture/Reference/Tech_Stack/Gradle_Kotlin_DSL_Primer.md

@@ -0,0 +1,115 @@
+---
+type: Reference
+status: ACTIVE
+owner: DevOps Engineer
+tags: [gradle, kotlin, dsl, build]
+---
+
+# Gradle Kotlin DSL Primer
+
+**Quelle:** [Original Gradle Documentation](https://docs.gradle.org/current/userguide/kotlin_dsl.html)
+**Kontext:** Dieses Dokument dient als Referenz für die im Projekt verwendete Gradle Kotlin DSL. Es fasst die wichtigsten Konzepte und Syntax-Elemente zusammen.
+
+---
+
+Gradle’s Kotlin DSL offers an alternative to the traditional Groovy DSL, delivering an enhanced editing experience in supported IDEs.
+
+## Key Concepts
+
+### Script File Names
+*   Groovy DSL: `.gradle`
+*   Kotlin DSL: `.gradle.kts`
+
+To activate the Kotlin DSL, use the `.gradle.kts` extension for your build scripts, settings file (`settings.gradle.kts`), and initialization scripts (`init.gradle.kts`).
+
+### Type-safe Model Accessors
+The Kotlin DSL replaces Groovy's dynamic resolution with type-safe model accessors for elements contributed by plugins (configurations, tasks, extensions). This provides better IDE support (code completion, refactoring).
+
+**Example:**
+```kotlin
+plugins {
+    `java-library`
+}
+
+dependencies {
+    // 'api', 'implementation' are type-safe accessors
+    api("junit:junit:4.13")
+    implementation("org.apache.commons:commons-lang3:3.12.0")
+}
+
+tasks {
+    // 'test' is a type-safe accessor for the Test task
+    test {
+        useJUnitPlatform()
+    }
+}
+```
+
+Accessors are available for elements contributed by plugins applied in the `plugins {}` block. For elements created dynamically later in the script, you must fall back to string-based lookups:
+```kotlin
+configurations.create("custom")
+
+dependencies {
+    "custom"("com.google.guava:guava:32.1.2-jre")
+}
+```
+
+### Lazy Property Assignment
+The Kotlin DSL supports lazy property assignment using the `=` operator for types like `Property` and `ConfigurableFileCollection`. This is the preferred way over the `set()` method.
+
+```kotlin
+// Instead of:
+// javaVersion.set(JavaLanguageVersion.of(17))
+
+// Use:
+javaVersion = JavaLanguageVersion.of(17)
+```
+
+### Working with Containers
+You can interact with containers like `tasks` or `configurations` in several ways:
+
+1.  **Container API (using `named` and `register`):**
+    ```kotlin
+    tasks.named<Test>("test") {
+        testLogging.showExceptions = true
+    }
+    tasks.register<Copy>("myCopy") {
+        from("source")
+        into("destination")
+    }
+    ```
+
+2.  **Delegated Properties (using `by existing` and `by registering`):**
+    ```kotlin
+    val test by tasks.existing(Test::class) {
+        testLogging.showStackTraces = true
+    }
+    val myCopy by tasks.registering(Copy::class) {
+        from("source")
+        into("destination")
+    }
+    ```
+
+### Extra Properties
+Access project or task-level extra properties via delegated properties:
+```kotlin
+// Define an extra property
+val myNewProperty by extra("initial value")
+
+// Read an existing extra property
+val myExtraProperty: String by extra
+```
+
+### Kotlin DSL Plugin (`kotlin-dsl`)
+This plugin is essential for developing build logic in Kotlin (e.g., in `buildSrc` or for convention plugins). It automatically applies the Kotlin plugin and adds necessary dependencies like `kotlin-stdlib` and `gradleKotlinDsl()`.
+
+```kotlin
+// buildSrc/build.gradle.kts
+plugins {
+    `kotlin-dsl`
+}
+
+repositories {
+    mavenCentral()
+}
+```

docs/01_Architecture/Reference/Tech_Stack/Konfiguration_Kotlin-2-3-0_Java-25.md

@@ -0,0 +1,79 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+tags: [kotlin, java, configuration, setup]
+---
+
+# Tech-Stack Referenz: Kotlin 2.3.0 & Java 25 (KMP)
+
+**Kontext:** Dieses Dokument beschreibt die notwendigen Konfigurationen, um Kotlin 2.3.0 mit Java 25 in einem Kotlin Multiplatform (KMP) Projekt mit Gradle 9.x zu verwenden.
+
+---
+
+### 1. Kern-Spezifikationen
+
+| Komponente | Version  | Status |
+| --- |----------| --- |
+| **Kotlin** | `2.3.0`  | Stabil (K2 Compiler standardmäßig aktiv) |
+| **Java (JDK)** | `25`     | LTS (Long-Term Support) |
+| **Gradle** | `9.2.1`  | Erforderlich für JDK 25 Support |
+| **Android Plugin (AGP)** | `8.8.0+` | Empfohlen für Gradle 9.x Kompatibilität |
+
+---
+
+### 2. Gradle Konfiguration (`build.gradle.kts`)
+
+Für ein **Kotlin Multiplatform (KMP)** Projekt ist die Java Toolchain-Konfiguration entscheidend, um sicherzustellen, dass der Kotlin-Compiler und die JVM-Targets Java 25 korrekt ansprechen.
+
+```kotlin
+plugins {
+    kotlin("multiplatform") version "2.3.0"
+    id("com.android.library") version "8.8.0" // Falls Android Target genutzt wird
+}
+
+kotlin {
+    // Globale Toolchain-Definition für alle JVM/Android Targets
+    jvmToolchain {
+        languageVersion.set(JavaLanguageVersion.of(25))
+    }
+
+    jvm {
+        compilations.all {
+            compilerOptions.configure {
+                jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_25)
+            }
+        }
+    }
+    
+    // Weitere Targets (Beispiel iOS)
+    iosArm64()
+    iosSimulatorArm64()
+}
+```
+
+---
+
+### 3. Gradle Wrapper Update
+
+Damit das Projekt Java 25 erkennt, muss der Wrapper auf dem neuesten Stand sein:
+
+**Terminal-Befehl:**
+```bash
+./gradlew wrapper --gradle-version 9.2.1 --distribution-type all
+```
+
+---
+
+### 4. Wichtige Kompatibilitätshinweise
+
+* **IDE-Version:** IntelliJ IDEA 2025.3 (oder neuer) wird für die volle Unterstützung von JDK 25 und dem Kotlin 2.3.0 Plugin empfohlen.
+* **K2 Compiler:** Kotlin 2.3.0 nutzt den K2-Compiler.
+* **Bytecode:** Java 25 Bytecode wird nur generiert, wenn das `jvmTarget` explizit auf `25` gesetzt ist.
+
+---
+
+### 5. Bekannte Features in diesem Setup
+
+* **Java 25 Features:** Unterstützung für die finalen Versionen von *Scoped Values* und *Structured Concurrency*.
+* **Kotlin 2.3.0 Features:** Nutzung von `explicit backing fields` und dem verbesserten `unused return value` Checker.

docs/01_Architecture/Reference/Tech_Stack/Kotlin_2-3-0_ReleaseNotes.md

@@ -0,0 +1,73 @@
+---
+type: Reference
+status: ACTIVE
+owner: Lead Architect
+tags: [kotlin, release-notes, tech-stack]
+---
+
+# What's new in Kotlin 2.3.0
+
+**Quelle:** [Original Kotlin Documentation](https://kotlinlang.org/docs/whatsnew23.html)
+**Datum des Dokuments:** 16. Dezember 2025
+**Kontext:** Dieses Dokument dient als Referenz für die im Projekt verwendete Kotlin-Version.
+
+---
+
+The Kotlin 2.3.0 release is out! Here are the main highlights:
+
+*   **Language:** More stable and default features, unused return value checker, explicit backing fields, and changes to context-sensitive resolution.
+*   **Kotlin/JVM:** Support for Java 25.
+*   **Kotlin/Native:** Improved interop through Swift export, faster build time for release tasks, C and Objective-C library import in Beta.
+*   **Kotlin/Wasm:** Fully qualified names and new exception handling proposal enabled by default, as well as new compact storage for Latin-1 characters.
+*   **Kotlin/JS:** New experimental suspend function export, `LongArray` representation, unified companion object access, and more.
+*   **Gradle:** Compatibility with Gradle 9.0 and a new API for registering generated sources.
+*   **Compose compiler:** Stack traces for minified Android applications.
+*   **Standard library:** Stable time tracking functionality and improved UUID generation and parsing.
+
+## Language
+
+Kotlin 2.3.0 focuses on feature stabilization, introduces a new mechanism for detecting unused return values, and improves context-sensitive resolution.
+
+### Stable features
+
+The following features have now graduated to Stable:
+*   Support for nested type aliases
+*   Data-flow-based exhaustiveness checks for `when` expressions
+
+### Features enabled by default
+*   Support for `return` statements in expression bodies with explicit return types is now enabled by default.
+
+### Experimental: Unused return value checker
+Kotlin 2.3.0 introduces the unused return value checker to help prevent ignored results.
+
+### Experimental: Explicit backing fields
+A new syntax for explicitly declaring the underlying field that holds a property's value, simplifying the common backing properties pattern.
+
+## Kotlin/JVM: Support for Java 25
+Starting with Kotlin 2.3.0, the compiler can generate classes containing Java 25 bytecode.
+
+## Kotlin/Native
+*   **Improved Swift Export:** Direct mapping for native enum classes and variadic function parameters.
+*   **C and Objective-C Library Import is in Beta:** Better diagnostics for binary compatibility issues.
+*   **Faster Build Time:** Up to 40% faster release builds, especially for iOS targets.
+
+## Kotlin/Wasm
+*   **Fully Qualified Names Enabled by Default:** `KClass.qualifiedName` is now available at runtime without extra configuration.
+*   **Compact Storage for Latin-1 Characters:** Reduces metadata and binary size.
+*   **New Exception Handling for `wasmWasi`:** Enabled by default for better compatibility with modern WebAssembly runtimes.
+
+## Kotlin/JS
+*   **Experimental Suspend Function Export:** Export suspend functions directly to JavaScript using `@JsExport`.
+*   **`BigInt64Array` for `LongArray`:** Simplifies interop with JavaScript APIs that use typed arrays.
+*   **Unified Companion Object Access:** Consistent access to companion objects in interfaces across all JS module systems.
+
+## Gradle
+*   Fully compatible with Gradle 7.6.3 through 9.0.0.
+*   New experimental API for registering generated sources.
+
+## Standard library
+*   **Stable Time Tracking:** `kotlin.time.Clock` and `kotlin.time.Instant` are now stable.
+*   **Improved UUID Generation:** New functions like `Uuid.parseOrNull()`, `Uuid.generateV4()`, and `Uuid.generateV7()`.
+
+## Compose compiler
+*   **Stack Traces for Minified Android Apps:** The compiler now outputs ProGuard mappings for Compose stack traces when applications are minified by R8.

docs/02_Guides/CodingGuidelines/kdoc-style.md

@@ -0,0 +1,63 @@
+---
+type: Guide
+status: ACTIVE
+owner: Lead Architect
+tags: [coding-style, kdoc, documentation]
+---
+
+# KDoc-Styleguide (Kurzfassung)
+
+Dieser Styleguide definiert die wichtigsten Regeln für KDoc-Kommentare in Kotlin-Projekten der Meldestelle. Ziel:
+Verständliche, konsistente API-Dokumentation via Dokka (GFM/HTML).
+
+## Grundregeln
+
+- Sprache: Deutsch für Fließtexte; Code/Bezeichner bleiben Englisch.
+- Jeder public class, interface, object, enum, public function und public property erhält einen KDoc-Block.
+- KDoc beginnt mit einem vollständigen, aussagekräftigen Satz in der dritten Person.
+- Beispiele und wichtige Hinweise als kurze Absätze oder Listen, keine Romane.
+
+## Struktur eines KDoc-Blocks
+
+```kotlin
+/**
+ * Beschreibt prägnant, was das Element macht und warum es existiert.
+ *
+ * Details: Optionale Erläuterung von Parametern, Nebenwirkungen, Fehlerfällen.
+ *
+ * @param id Eindeutige Kennung des Members
+ * @return Das gefundene Objekt oder null, wenn nicht vorhanden
+ * @throws IllegalArgumentException Falls Parameter ungültig sind
+ */
+fun findMember(id: MemberId): Member?
+```
+
+## Tags
+
+- @param: Für jeden Parameter bei public Funktionen
+- @return: Wenn Rückgabewert semantisch relevant ist
+- @throws: Relevante Exceptions dokumentieren
+- @since, @see: Sparsam verwenden, wenn es wirklichen Mehrwert bringt
+
+## Stil & Sprache
+
+- Klar, knapp, aktiv. Keine Redundanz.
+- Domänenbegriffe verwenden (BCs: members, horses, events, masterdata, infrastructure).
+- Keine Interna oder Secrets dokumentieren.
+
+## Beispielschnipsel
+
+```kotlin
+/** Erstellt einen neuen Event und persistiert ihn transaktional. */
+fun createEvent(cmd: CreateEventCommand): EventId
+```
+
+## Dokka-Hinweise
+
+- Dokka erzeugt GFM (Markdown) unter build/dokka/gfm und HTML unter build/dokka/html.
+- Source-Link führt auf GitHub (main-Branch). Prüfe Links in der CI.
+
+## Review
+
+- PR-Checklist: "KDoc vollständig?" anhaken, wenn neue public APIs hinzugekommen sind.
+- Vale/markdownlint gelten nur für .md; KDoc wird redaktionell in Code-Reviews geprüft.

docs/02_Guides/branchschutz-und-pr-workflow.md

@@ -0,0 +1,54 @@
+---
+type: Guide
+status: ACTIVE
+owner: DevOps Engineer
+tags: [git, workflow, pr, branching]
+---
+
+# Branchschutz & Pull-Request Workflow
+
+Diese Anleitung beschreibt einen einfachen, robusten Flow für `main` mit kurzen Feature-Branches und klaren
+Qualitätschecks.
+
+## 1) Branch-Naming
+
+- Feature: `feature/<kurz-beschreibung>`
+- Bugfix: `fix/<kurz-beschreibung>`
+- Docs: `docs/<kurz-beschreibung>`
+
+Optional: Issue-Key voranstellen, z. B. `feature/MP-7-doku-konsolidieren`.
+
+## 2) Pull Request (PR)
+
+- PR-Titel nach Conventional Commits (kurz): `docs(api): Front‑Matter vereinheitlicht (MP-7)`
+- Beschreibung kurz mit Bulletpoints; DoD-Checkliste abhaken (Template vorhanden)
+- CI muss grün sein (Backend + Docs)
+
+## 3) Branchschutz (GitHub Einstellungen → Branches → main)
+
+- Require a pull request before merging
+- Require status checks to pass before merging
+  - aktivieren: `CI Docs`, `CI` (Backend falls vorhanden)
+- Require linear history
+- Require approvals: mindestens 1 (bei Solo-Projekt optional, aber empfohlen)
+- Allow squash merging only
+- Disallow force pushes, Disallow deletions
+
+## 4) Commits & YouTrack
+
+- Commit-Message enthält Issue-Key (z. B. `MP-7`) → erleichtert Nachverfolgung
+- In Doku-Front‑Matter `yt_epic`/`yt_issues` pflegen
+- Optional: GitHub Secrets `YT_URL`, `YT_TOKEN` setzen → CI validiert verlinkte Issues, und `youtrack-sync.yml`
+  kommentiert beim Merge automatisch ins Issue
+
+## 5) Definition of Done (Auszug)
+
+- Doku aktuell (README/ADR/C4/API)
+- Front‑Matter valide (`modul`, `status`, `summary`, optional `last_reviewed`, `review_cycle`, `yt_*`)
+- Links funktionieren (CI link-check grün)
+- Tests grün
+
+## 6) Lokale Tipps
+
+- Vor dem Push: `markdownlint`, `vale` lokal laufen lassen (optional via pre-commit hooks)
+- kleine, häufige PRs statt großer Monster-PRs

docs/02_Guides/start-local.md

@@ -0,0 +1,66 @@
+---
+type: Guide
+status: ACTIVE
+owner: DevOps Engineer
+tags: [setup, local, docker, gradle]
+---
+
+# Start Local (Lokales Setup)
+
+Kurzanleitung, um das Projekt lokal in wenigen Minuten zu starten.
+
+## Voraussetzungen
+- Docker und Docker Compose (v2)
+- Java 25 (JDK)
+- Git
+
+## Schnellstart
+
+```bash
+# 1) Repository klonen
+git clone https://github.com/StefanMoCoAt/meldestelle.git
+cd meldestelle
+
+# 2) Runtime-Environment vorbereiten
+#    Kopiere die Vorlage.
+cp .env.example .env
+
+# 3) Infrastruktur starten (Postgres, Redis, Keycloak, Monitoring, Gateway)
+docker compose --profile infra up -d
+
+# 4) Backend starten (Gateway + Ping Service)
+docker compose --profile backend up -d
+```
+
+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
+# Führt alle Tests aus
+./gradlew test
+
+# Spezifisches Backend-Modul testen
+./gradlew :backend:services:ping:ping-service:test
+```
+
+## Troubleshooting
+- Dienste starten nicht? Ports belegt oder Logs prüfen:
+  ```bash
+  docker ps
+  docker logs <container-name>
+  ```
+- Infrastruktur neu starten:
+  ```bash
+  docker compose down -v
+  docker compose --profile infra up -d
+  ```
+- Environment-Variablen: werden aus der `.env`-Datei im Root-Verzeichnis geladen.
+
+## Weiterführende Hinweise
+- Architektur: `docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md`
+- ADRs: `docs/01_Architecture/adr/`
+- Aktuelle Reports: `docs/90_Reports/`

docs/02_Onboarding/CodingGuidelines/kdoc-style.md

@@ -1,66 +1,9 @@
 ---
-owner: project-maintainers
+type: Guide
-status: active
+status: ARCHIVED
-review_cycle: 365d
+owner: Lead Architect
-last_reviewed: 2025-10-28
-summary: KDoc-Styleguide für die Meldestelle. Mindeststandards für KDoc, damit Dokka lesbare API-Doku generiert.
-bc: infrastructure
-doc_type: how-to
 ---
 
-# KDoc-Styleguide (Kurzfassung)
+# KDoc Styleguide
 
-Dieser Styleguide definiert die wichtigsten Regeln für KDoc-Kommentare in Kotlin-Projekten der Meldestelle. Ziel:
+**MOVED:** This file has been moved to `docs/02_Guides/CodingGuidelines/kdoc-style.md`.
-Verständliche, konsistente API-Dokumentation via Dokka (GFM/HTML).
-
-## Grundregeln
-
-- Sprache: Deutsch für Fließtexte; Code/Bezeichner bleiben Englisch.
-- Jeder public class, interface, object, enum, public function und public property erhält einen KDoc-Block.
-- KDoc beginnt mit einem vollständigen, aussagekräftigen Satz in der dritten Person.
-- Beispiele und wichtige Hinweise als kurze Absätze oder Listen, keine Romane.
-
-## Struktur eines KDoc-Blocks
-
-```kotlin
-/**
- * Beschreibt prägnant, was das Element macht und warum es existiert.
- *
- * Details: Optionale Erläuterung von Parametern, Nebenwirkungen, Fehlerfällen.
- *
- * @param id Eindeutige Kennung des Members
- * @return Das gefundene Objekt oder null, wenn nicht vorhanden
- * @throws IllegalArgumentException Falls Parameter ungültig sind
- */
-fun findMember(id: MemberId): Member?
-```
-
-## Tags
-
-- @param: Für jeden Parameter bei public Funktionen
-- @return: Wenn Rückgabewert semantisch relevant ist
-- @throws: Relevante Exceptions dokumentieren
-- @since, @see: Sparsam verwenden, wenn es wirklichen Mehrwert bringt
-
-## Stil & Sprache
-
-- Klar, knapp, aktiv. Keine Redundanz.
-- Domänenbegriffe verwenden (BCs: members, horses, events, masterdata, infrastructure).
-- Keine Interna oder Secrets dokumentieren.
-
-## Beispielschnipsel
-
-```kotlin
-/** Erstellt einen neuen Event und persistiert ihn transaktional. */
-fun createEvent(cmd: CreateEventCommand): EventId
-```
-
-## Dokka-Hinweise
-
-- Dokka erzeugt GFM (Markdown) unter build/dokka/gfm und HTML unter build/dokka/html.
-- Source-Link führt auf GitHub (main-Branch). Prüfe Links in der CI.
-
-## Review
-
-- PR-Checklist: "KDoc vollständig?" anhaken, wenn neue public APIs hinzugekommen sind.
-- Vale/markdownlint gelten nur für .md; KDoc wird redaktionell in Code-Reviews geprüft.

docs/02_Onboarding/branchschutz-und-pr-workflow.md

@@ -1,57 +1,9 @@
 ---
-modul: workflow-pr-branchschutz
+type: Guide
-status: active
+status: ARCHIVED
-last_reviewed: 2025-10-22
+owner: DevOps Engineer
-review_cycle: 180d
-summary: Empfehlungen für Branchschutz, PR-Ablauf und Naming-Konventionen.
-yt_epic: MP-1
-yt_issues: [ ]
 ---
 
-# Branchschutz & Pull-Request Workflow
+# Branchschutz & PR Workflow
 
-Diese Anleitung beschreibt einen einfachen, robusten Flow für `main` mit kurzen Feature-Branches und klaren
+**MOVED:** This file has been moved to `docs/02_Guides/branchschutz-und-pr-workflow.md`.
-Qualitätschecks.
-
-## 1) Branch-Naming
-
-- Feature: `feature/<kurz-beschreibung>`
-- Bugfix: `fix/<kurz-beschreibung>`
-- Docs: `docs/<kurz-beschreibung>`
-
-Optional: Issue-Key voranstellen, z. B. `feature/MP-7-doku-konsolidieren`.
-
-## 2) Pull Request (PR)
-
-- PR-Titel nach Conventional Commits (kurz): `docs(api): Front‑Matter vereinheitlicht (MP-7)`
-- Beschreibung kurz mit Bulletpoints; DoD-Checkliste abhaken (Template vorhanden)
-- CI muss grün sein (Backend + Docs)
-
-## 3) Branchschutz (GitHub Einstellungen → Branches → main)
-
-- Require a pull request before merging
-- Require status checks to pass before merging
-  - aktivieren: `CI Docs`, `CI` (Backend falls vorhanden)
-- Require linear history
-- Require approvals: mindestens 1 (bei Solo-Projekt optional, aber empfohlen)
-- Allow squash merging only
-- Disallow force pushes, Disallow deletions
-
-## 4) Commits & YouTrack
-
-- Commit-Message enthält Issue-Key (z. B. `MP-7`) → erleichtert Nachverfolgung
-- In Doku-Front‑Matter `yt_epic`/`yt_issues` pflegen
-- Optional: GitHub Secrets `YT_URL`, `YT_TOKEN` setzen → CI validiert verlinkte Issues, und `youtrack-sync.yml`
-  kommentiert beim Merge automatisch ins Issue
-
-## 5) Definition of Done (Auszug)
-
-- Doku aktuell (README/ADR/C4/API)
-- Front‑Matter valide (`modul`, `status`, `summary`, optional `last_reviewed`, `review_cycle`, `yt_*`)
-- Links funktionieren (CI link-check grün)
-- Tests grün
-
-## 6) Lokale Tipps
-
-- Vor dem Push: `markdownlint`, `vale` lokal laufen lassen (optional via pre-commit hooks)
-- kleine, häufige PRs statt großer Monster-PRs

docs/02_Onboarding/start-local.md

@@ -1,63 +1,9 @@
-# Start Local (Lokales Setup)
+---
+type: Guide
+status: ARCHIVED
+owner: DevOps Engineer
+---
 
-Kurzanleitung, um das Projekt lokal in wenigen Minuten zu starten.
+# Start Local
 
-**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.
+**MOVED:** This file has been moved to `docs/02_Guides/start-local.md`.
-
-## Voraussetzungen
-- Docker und Docker Compose (v2)
-- Java 25 (JDK)
-- Git
-
-## Schnellstart
-
-```bash
-# 1) Repository klonen
-git clone https://github.com/StefanMoCoAt/meldestelle.git
-cd meldestelle
-
-# 2) Runtime-Environment vorbereiten
-#    Kopiere die Vorlage.
-cp .env.example .env
-
-# 3) Infrastruktur starten (Postgres, Redis, Keycloak, Monitoring, Gateway)
-docker compose -f docker-compose.yaml up -d
-
-# 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
-
-## Tests ausführen
-```bash
-# Führt alle Tests aus (Frontend-Tests könnten fehlschlagen)
-./gradlew test
-
-# Spezifisches Backend-Modul testen
-./gradlew :backend:services:results:results-service: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: werden aus der `.env`-Datei im Root-Verzeichnis geladen.
-
-## 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/02_Reference/Tech_Stack/Gradle_Kotlin_DSL_Primer.md

@@ -1,108 +1,9 @@
-# Gradle Kotlin DSL Primer
+---
-
+type: Reference
-**Quelle:** [Original Gradle Documentation](https://docs.gradle.org/current/userguide/kotlin_dsl.html)
+status: ARCHIVED
-**Kontext:** Dieses Dokument dient als Referenz für die im Projekt verwendete Gradle Kotlin DSL. Es fasst die wichtigsten Konzepte und Syntax-Elemente zusammen.
+owner: DevOps Engineer
-
 ---
 
-Gradle’s Kotlin DSL offers an alternative to the traditional Groovy DSL, delivering an enhanced editing experience in supported IDEs.
+# Gradle Kotlin DSL Primer
 
-## Key Concepts
+**MOVED:** This file has been moved to `docs/01_Architecture/Reference/Tech_Stack/Gradle_Kotlin_DSL_Primer.md`.
-
-### Script File Names
-*   Groovy DSL: `.gradle`
-*   Kotlin DSL: `.gradle.kts`
-
-To activate the Kotlin DSL, use the `.gradle.kts` extension for your build scripts, settings file (`settings.gradle.kts`), and initialization scripts (`init.gradle.kts`).
-
-### Type-safe Model Accessors
-The Kotlin DSL replaces Groovy's dynamic resolution with type-safe model accessors for elements contributed by plugins (configurations, tasks, extensions). This provides better IDE support (code completion, refactoring).
-
-**Example:**
-```kotlin
-plugins {
-    `java-library`
-}
-
-dependencies {
-    // 'api', 'implementation' are type-safe accessors
-    api("junit:junit:4.13")
-    implementation("org.apache.commons:commons-lang3:3.12.0")
-}
-
-tasks {
-    // 'test' is a type-safe accessor for the Test task
-    test {
-        useJUnitPlatform()
-    }
-}
-```
-
-Accessors are available for elements contributed by plugins applied in the `plugins {}` block. For elements created dynamically later in the script, you must fall back to string-based lookups:
-```kotlin
-configurations.create("custom")
-
-dependencies {
-    "custom"("com.google.guava:guava:32.1.2-jre")
-}
-```
-
-### Lazy Property Assignment
-The Kotlin DSL supports lazy property assignment using the `=` operator for types like `Property` and `ConfigurableFileCollection`. This is the preferred way over the `set()` method.
-
-```kotlin
-// Instead of:
-// javaVersion.set(JavaLanguageVersion.of(17))
-
-// Use:
-javaVersion = JavaLanguageVersion.of(17)
-```
-
-### Working with Containers
-You can interact with containers like `tasks` or `configurations` in several ways:
-
-1.  **Container API (using `named` and `register`):**
-    ```kotlin
-    tasks.named<Test>("test") {
-        testLogging.showExceptions = true
-    }
-    tasks.register<Copy>("myCopy") {
-        from("source")
-        into("destination")
-    }
-    ```
-
-2.  **Delegated Properties (using `by existing` and `by registering`):**
-    ```kotlin
-    val test by tasks.existing(Test::class) {
-        testLogging.showStackTraces = true
-    }
-    val myCopy by tasks.registering(Copy::class) {
-        from("source")
-        into("destination")
-    }
-    ```
-
-### Extra Properties
-Access project or task-level extra properties via delegated properties:
-```kotlin
-// Define an extra property
-val myNewProperty by extra("initial value")
-
-// Read an existing extra property
-val myExtraProperty: String by extra
-```
-
-### Kotlin DSL Plugin (`kotlin-dsl`)
-This plugin is essential for developing build logic in Kotlin (e.g., in `buildSrc` or for convention plugins). It automatically applies the Kotlin plugin and adds necessary dependencies like `kotlin-stdlib` and `gradleKotlinDsl()`.
-
-```kotlin
-// buildSrc/build.gradle.kts
-plugins {
-    `kotlin-dsl`
-}
-
-repositories {
-    mavenCentral()
-}
-```

docs/02_Reference/Tech_Stack/Konfiguration_Kotlin-2-3-0_Java-25.md

@@ -1,72 +1,9 @@
+---
+type: Reference
+status: ARCHIVED
+owner: Lead Architect
+---
+
 # Tech-Stack Referenz: Kotlin 2.3.0 & Java 25 (KMP)
 
-**Kontext:** Dieses Dokument beschreibt die notwendigen Konfigurationen, um Kotlin 2.3.0 mit Java 25 in einem Kotlin Multiplatform (KMP) Projekt mit Gradle 9.x zu verwenden.
+**MOVED:** This file has been moved to `docs/01_Architecture/Reference/Tech_Stack/Konfiguration_Kotlin-2-3-0_Java-25.md`.
-
----
-
-### 1. Kern-Spezifikationen
-
-| Komponente | Version  | Status |
-| --- |----------| --- |
-| **Kotlin** | `2.3.0`  | Stabil (K2 Compiler standardmäßig aktiv) |
-| **Java (JDK)** | `25`     | LTS (Long-Term Support) |
-| **Gradle** | `9.2.1`  | Erforderlich für JDK 25 Support |
-| **Android Plugin (AGP)** | `8.8.0+` | Empfohlen für Gradle 9.x Kompatibilität |
-
----
-
-### 2. Gradle Konfiguration (`build.gradle.kts`)
-
-Für ein **Kotlin Multiplatform (KMP)** Projekt ist die Java Toolchain-Konfiguration entscheidend, um sicherzustellen, dass der Kotlin-Compiler und die JVM-Targets Java 25 korrekt ansprechen.
-
-```kotlin
-plugins {
-    kotlin("multiplatform") version "2.3.0"
-    id("com.android.library") version "8.8.0" // Falls Android Target genutzt wird
-}
-
-kotlin {
-    // Globale Toolchain-Definition für alle JVM/Android Targets
-    jvmToolchain {
-        languageVersion.set(JavaLanguageVersion.of(25))
-    }
-
-    jvm {
-        compilations.all {
-            compilerOptions.configure {
-                jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_25)
-            }
-        }
-    }
-    
-    // Weitere Targets (Beispiel iOS)
-    iosArm64()
-    iosSimulatorArm64()
-}
-```
-
----
-
-### 3. Gradle Wrapper Update
-
-Damit das Projekt Java 25 erkennt, muss der Wrapper auf dem neuesten Stand sein:
-
-**Terminal-Befehl:**
-```bash
-./gradlew wrapper --gradle-version 9.2.1 --distribution-type all
-```
-
----
-
-### 4. Wichtige Kompatibilitätshinweise
-
-* **IDE-Version:** IntelliJ IDEA 2025.3 (oder neuer) wird für die volle Unterstützung von JDK 25 und dem Kotlin 2.3.0 Plugin empfohlen.
-* **K2 Compiler:** Kotlin 2.3.0 nutzt den K2-Compiler.
-* **Bytecode:** Java 25 Bytecode wird nur generiert, wenn das `jvmTarget` explizit auf `25` gesetzt ist.
-
----
-
-### 5. Bekannte Features in diesem Setup
-
-* **Java 25 Features:** Unterstützung für die finalen Versionen von *Scoped Values* und *Structured Concurrency*.
-* **Kotlin 2.3.0 Features:** Nutzung von `explicit backing fields` und dem verbesserten `unused return value` Checker.

docs/02_Reference/Tech_Stack/Kotlin_2-3-0_ReleaseNotes.md

@@ -1,66 +1,9 @@
-# What's new in Kotlin 2.3.0
+---
-
+type: Reference
-**Quelle:** [Original Kotlin Documentation](https://kotlinlang.org/docs/whatsnew23.html)
+status: ARCHIVED
-**Datum des Dokuments:** 16. Dezember 2025
+owner: Lead Architect
-**Kontext:** Dieses Dokument dient als Referenz für die im Projekt verwendete Kotlin-Version.
-
 ---
 
-The Kotlin 2.3.0 release is out! Here are the main highlights:
+# What's new in Kotlin 2.3.0
 
-*   **Language:** More stable and default features, unused return value checker, explicit backing fields, and changes to context-sensitive resolution.
+**MOVED:** This file has been moved to `docs/01_Architecture/Reference/Tech_Stack/Kotlin_2-3-0_ReleaseNotes.md`.
-*   **Kotlin/JVM:** Support for Java 25.
-*   **Kotlin/Native:** Improved interop through Swift export, faster build time for release tasks, C and Objective-C library import in Beta.
-*   **Kotlin/Wasm:** Fully qualified names and new exception handling proposal enabled by default, as well as new compact storage for Latin-1 characters.
-*   **Kotlin/JS:** New experimental suspend function export, `LongArray` representation, unified companion object access, and more.
-*   **Gradle:** Compatibility with Gradle 9.0 and a new API for registering generated sources.
-*   **Compose compiler:** Stack traces for minified Android applications.
-*   **Standard library:** Stable time tracking functionality and improved UUID generation and parsing.
-
-## Language
-
-Kotlin 2.3.0 focuses on feature stabilization, introduces a new mechanism for detecting unused return values, and improves context-sensitive resolution.
-
-### Stable features
-
-The following features have now graduated to Stable:
-*   Support for nested type aliases
-*   Data-flow-based exhaustiveness checks for `when` expressions
-
-### Features enabled by default
-*   Support for `return` statements in expression bodies with explicit return types is now enabled by default.
-
-### Experimental: Unused return value checker
-Kotlin 2.3.0 introduces the unused return value checker to help prevent ignored results.
-
-### Experimental: Explicit backing fields
-A new syntax for explicitly declaring the underlying field that holds a property's value, simplifying the common backing properties pattern.
-
-## Kotlin/JVM: Support for Java 25
-Starting with Kotlin 2.3.0, the compiler can generate classes containing Java 25 bytecode.
-
-## Kotlin/Native
-*   **Improved Swift Export:** Direct mapping for native enum classes and variadic function parameters.
-*   **C and Objective-C Library Import is in Beta:** Better diagnostics for binary compatibility issues.
-*   **Faster Build Time:** Up to 40% faster release builds, especially for iOS targets.
-
-## Kotlin/Wasm
-*   **Fully Qualified Names Enabled by Default:** `KClass.qualifiedName` is now available at runtime without extra configuration.
-*   **Compact Storage for Latin-1 Characters:** Reduces metadata and binary size.
-*   **New Exception Handling for `wasmWasi`:** Enabled by default for better compatibility with modern WebAssembly runtimes.
-
-## Kotlin/JS
-*   **Experimental Suspend Function Export:** Export suspend functions directly to JavaScript using `@JsExport`.
-*   **`BigInt64Array` for `LongArray`:** Simplifies interop with JavaScript APIs that use typed arrays.
-*   **Unified Companion Object Access:** Consistent access to companion objects in interfaces across all JS module systems.
-
-## Gradle
-*   Fully compatible with Gradle 7.6.3 through 9.0.0.
-*   New experimental API for registering generated sources.
-
-## Standard library
-*   **Stable Time Tracking:** `kotlin.time.Clock` and `kotlin.time.Instant` are now stable.
-*   **Improved UUID Generation:** New functions like `Uuid.parseOrNull()`, `Uuid.generateV4()`, and `Uuid.generateV7()`.
-
-## Compose compiler
-*   **Stack Traces for Minified Android Apps:** The compiler now outputs ProGuard mappings for Compose stack traces when applications are minified by R8.

docs/04_Agents/Playbooks/UIUXDesigner.md

@@ -0,0 +1,105 @@
+---
+type: Playbook
+status: ACTIVE
+owner: Curator
+role: UI/UX Designer
+last_update: 2026-01-23
+---
+
+# 🎨 Agent Playbook: UI/UX Designer
+
+> **Motto:** "Information Density over White Space. Speed over Animation."
+
+## 1. Rolle & Verantwortung
+Du bist der **Product Design Specialist** für das Projekt "Meldestelle".
+Wir bauen keine Consumer-App für Gelegenheitsnutzer, sondern ein **Hochleistungs-Werkzeug** für Experten (Turniermeldestellen), die unter Zeitdruck tausende Datensätze verwalten.
+
+Deine Aufgabe ist es, die Brücke zwischen fachlicher Anforderung (Domain Expert) und technischer Umsetzung (Frontend Expert) zu schlagen. Du lieferst keine bunten Bilder, sondern **umsetzbare Spezifikationen**.
+
+---
+
+## 2. System Prompt & Persönlichkeit
+
+Wenn du aktiviert wirst, handle nach folgenden Grundsätzen:
+
+*   **Du bist ein "Toolsmith":** Du denkst wie ein Konstrukteur von Flugzeug-Cockpits oder Trading-Terminals.
+*   **Gnadenlose Effizienz:** Jeder Klick ist einer zu viel. Jede Mausbewegung kostet Zeit.
+*   **Kritischer Blick:** Hinterfrage Standard-Material-Design-Regeln (z.B. riesige Paddings), wenn sie die Informationsdichte verringern.
+
+**Dein System-Prompt:**
+```text
+Du bist der UI/UX Designer der Meldestelle.
+Deine Design-Philosophie: "High Density Enterprise UI".
+1. Optimiere für Datendichte, nicht für "Luftigkeit".
+2. Priorisiere Tastatur-Steuerung (Tab-Order, Shortcuts).
+3. Nutze visuelle Hierarchie (Typografie, Kontrast), um den Blick zu lenken.
+4. Denke in "States": Loading, Error, Empty, Offline, Syncing.
+5. Liefere Output als ASCII-Mockups oder direkt als Kotlin-Compose-Strukturvorschläge.
+```
+
+---
+
+## 3. Design-Prinzipien (The Meldestelle Way)
+
+### A. High Density (Compact Mode)
+*   Standard Material 3 ist zu "luftig" für uns.
+*   Nutze `VisualDensity.Compact` wo immer möglich.
+*   Tabellen und Listen sind das Herzstück. Zeige so viele Zeilen wie möglich, ohne die Lesbarkeit zu opfern.
+
+### B. Keyboard First
+*   Die App muss **komplett ohne Maus** bedienbar sein.
+*   Definiere `FocusRequester` und `KeyboardActions` für Formulare.
+*   Schlage globale Shortcuts vor (z.B. `F5` für Refresh, `Ctrl+S` für Speichern, `Esc` für Zurück).
+
+### C. Feedback & Status
+*   Der User muss dem System vertrauen.
+*   **Offline-Indikator:** Muss immer sichtbar sein, wenn keine Verbindung besteht.
+*   **Sync-Status:** Zeige an, wann zuletzt synchronisiert wurde.
+*   **Optimistic UI:** Zeige Änderungen sofort an, synchronisiere im Hintergrund.
+
+---
+
+## 4. Arbeitsweise & Output
+
+Du erstellst keine Figma-Files, sondern "Code-Ready Specs" in Markdown.
+
+### Format 1: ASCII Wireframes
+Für grobe Layouts:
+```text
++-------------------------------------------------------+
+| [Back]  Turnier: CSN-B* Stadl Paura        [Offline]  |
++-------------------------------------------------------+
+|                                                       |
+|  [ Suchfeld (Ctrl+F) ................... ] [Filter]   |
+|                                                       |
+|  #  | Pferd           | Reiter           | Status     |
+|  ---|-----------------|------------------|----------- |
+|  01 | Black Beauty    | Max Mustermann   | [Start]    |
+|  02 | Fury            | Erika Muster     | [Paid]     |
+|  .. | ...             | ...              | ...        |
+|                                                       |
++-------------------------------------------------------+
+| [F1] Hilfe | [F2] Neuer Eintrag | [F12] Abrechnung    |
++-------------------------------------------------------+
+```
+
+### Format 2: Compose-Struktur
+Für detaillierte Anweisungen an den Frontend-Dev:
+```kotlin
+// Vorschlag für die Listen-Struktur
+Column(Modifier.fillMaxSize()) {
+   HeaderSection(height = 48.dp) // Kompakt!
+   SearchRow(Modifier.focusRequester(focusSearch))
+   LazyColumn(
+       verticalArrangement = Arrangement.spacedBy(4.dp) // Wenig Abstand
+   ) { ... }
+   FooterActions(Modifier.height(32.dp))
+}
+```
+
+---
+
+## 5. Interaktion mit anderen Agenten
+
+*   **Mit Domain Expert:** Kläre, welche Daten *wirklich* wichtig sind (Prio 1) und welche ausgeblendet werden können (Details).
+*   **Mit Frontend Expert:** Liefere keine abstrakten Ideen, sondern nutze das Vokabular von Jetpack Compose (`Row`, `Column`, `Surface`, `MaterialTheme`).

docs/90_Reports/2026-01-17_Frontend_Status.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: FINAL
+status: ARCHIVED
 owner: Frontend Expert
 date: 2026-01-17
 tags: [frontend, kmp, auth, ping, architecture]
@@ -8,6 +8,10 @@ tags: [frontend, kmp, auth, ping, architecture]
 
 # 🚩 Statusbericht: Frontend (17. Jänner 2026)
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Status:** ✅ **Erfolgreich abgeschlossen**
 
 Wir haben heute die technische Basis des Frontends massiv stabilisiert und das "Ping-Feature" als vollständige Referenz-Implementierung für gesicherte API-Kommunikation fertiggestellt.

docs/90_Reports/2026-01-17_LeadArchitect_Handover.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: ACTION_REQUIRED
+status: ARCHIVED
 owner: Lead Architect
 date: 2026-01-17
 tags: [architecture, handover, critique, roadmap]
@@ -8,6 +8,10 @@ tags: [architecture, handover, critique, roadmap]
 
 # 🏗️ Lead Architect Status Report & Handover
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Datum:** 17. Jänner 2026
 **Status:** 🟡 **PARTIALLY BLOCKED** (Frontend Architecture Split)
 **Ziel:** Abschluss "Trace Bullet" (Ping Feature mit Auth, Sync & Tracing)

docs/90_Reports/2026-01-19_Frontend_Refactoring_Status.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: FINAL
+status: ARCHIVED
 owner: Frontend Expert
 date: 2026-01-19
 tags: [frontend, refactoring, clean-architecture, ping-feature]
@@ -8,6 +8,10 @@ tags: [frontend, refactoring, clean-architecture, ping-feature]
 
 # 🚩 Statusbericht: Frontend Refactoring (19. Jänner 2026)
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Status:** ✅ **Erfolgreich abgeschlossen**
 
 Wir haben die vom Lead Architect kritisierte Fragmentierung im Frontend behoben und das Ping-Feature auf eine saubere **Clean Architecture** migriert.

docs/90_Reports/2026-01-19_LeadArchitect_Review.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: APPROVED
+status: ARCHIVED
 owner: Lead Architect
 date: 2026-01-19
 tags: [architecture, review, frontend, ping-feature]
@@ -8,6 +8,10 @@ tags: [architecture, review, frontend, ping-feature]
 
 # 🏗️ Lead Architect Review: Frontend Refactoring
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Datum:** 19. Jänner 2026
 **Status:** ✅ **APPROVED**
 **Referenz:** `docs/90_Reports/2026-01-19_Frontend_Refactoring_Status.md`

docs/90_Reports/2026-01-20_Frontend_Integration_Status.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: DRAFT
+status: ARCHIVED
 owner: Frontend Expert
 date: 2026-01-20
 tags: [frontend, backend, integration, ping-feature]
@@ -8,6 +8,10 @@ tags: [frontend, backend, integration, ping-feature]
 
 # 🚩 Statusbericht: Frontend-Backend Integration (20. Jänner 2026)
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Status:** ✅ **Erfolgreich verifiziert**
 
 Wir haben die Integration zwischen dem KMP-Frontend (Desktop App) und dem Spring Boot Backend (via Gateway) erfolgreich getestet und stabilisiert.

docs/90_Reports/2026-01-23_Weekend_Status_Report.md

@@ -0,0 +1,49 @@
+---
+type: Report
+status: FINAL
+owner: Lead Architect
+date: 2026-01-23
+tags: [status, milestone, tracer-bullet]
+---
+
+# 🚀 Weekend Status Report: "Operation Tracer Bullet"
+
+**Datum:** 23. Jänner 2026
+**Phase:** Validierung & Härtung
+
+## 1. Executive Summary
+Das Projekt hat einen kritischen Meilenstein erreicht. Der "Tracer Bullet" (Ping-Service) durchdringt erfolgreich den gesamten Stack – vom Frontend (Desktop) über das Gateway bis zur Datenbank, inklusive Security und Resilience.
+Die technische Basis ist stabilisiert, die "Kinderkrankheiten" (Versionskonflikte, Docker-Networking) sind geheilt.
+
+## 2. Status pro Gewerk
+
+### 🏗️ Architecture & Build
+*   **Status:** 🟢 GRÜN
+*   **Erfolg:** Tech-Stack Stabilisierung (ADR-0013) hat Build-Probleme eliminiert.
+*   **Doku:** `AGENTS.md` definiert klare Zusammenarbeit.
+
+### 🐧 Infrastructure (DevOps)
+*   **Status:** 🟢 GRÜN
+*   **Erfolg:** Docker-Environment ist vollständig operational.
+*   **Highlight:** Lösung des JWT-Validierungsproblems ("Split Horizon") ermöglicht saubere Auth in Containern.
+
+### 👷 Backend (Spring Boot)
+*   **Status:** 🟢 GRÜN
+*   **Erfolg:** `ping-service` ist "Production Ready".
+    *   Flyway Migrationen aktiv.
+    *   CircuitBreaker & Metrics aktiv.
+    *   Security (RBAC) aktiv.
+
+### 🎨 Frontend (KMP)
+*   **Status:** 🟡 GELB (Teilweise fertig)
+*   **Erfolg:** Desktop-App kann sich einloggen und synchronisieren.
+*   **Offen:** Web-Support (PKCE Flow) muss nachgezogen werden.
+*   **UX:** Design ist noch rudimentär ("Developer Art").
+
+## 3. Risiken & Blocker
+*   **Keine Blocker.** Der Weg für die fachliche Implementierung ist frei.
+
+## 4. Plan für das Wochenende / Nächste Woche
+1.  **Web-Auth:** Frontend Expert implementiert PKCE für Browser-Support.
+2.  **Integration Test:** Einmaliger kompletter Durchstich (Frontend -> Backend -> DB) mit laufendem Docker-Stack.
+3.  **Domain Start:** Beginn der Arbeit an der `Events` (Veranstaltungen) Domäne.

docs/90_Reports/Backend_Status_Report_01-2026.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: FINAL
+status: ARCHIVED
 author: Senior Backend Developer
 date: 2026-01-17
 context: Phase 3 - Sync Implementation
@@ -8,6 +8,10 @@ context: Phase 3 - Sync Implementation
 
 # Backend Status Report: Phase 3 (Sync) abgeschlossen
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 ## 1. Zusammenfassung
 Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
 

docs/90_Reports/Infrastructure_Status_Report_01-2026.md

@@ -1,6 +1,6 @@
 ---
 type: Report
-status: FINAL
+status: ARCHIVED
 owner: DevOps Engineer
 last_update: 2026-01-20
 context: Phase 1-3 (Backend Ready)
@@ -8,6 +8,10 @@ context: Phase 1-3 (Backend Ready)
 
 # Infrastructure Status Report: "Tracer Bullet" Readiness
 
+**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
+
+---
+
 **Datum:** 20. Jänner 2026
 **Autor:** DevOps & Infrastructure Engineer (Updated by Backend Developer)
 **Ziel:** Bestätigung der Einsatzbereitschaft der lokalen Entwicklungsumgebung für Phase 1 (Backend Hardening) und Phase 3 (Sync).

docs/90_Reports/Ping-Service_Impl_01-2026.md

@@ -1,3 +1,17 @@
+---
+type: Report
+status: ARCHIVED
+owner: Lead Architect
+date: 2026-01-10
+tags: [backend, ping-service, task]
+---
+
+# Arbeitsauftrag: Implementierung des `ping-service` (Tracer Bullet)
+
+**ARCHIVED:** This is the original task description. The implementation has evolved. Please refer to `docs/05_Backend/Services/PingService_Reference.md`.
+
+---
+
 **An:** Senior Backend Developer
 **Von:** Lead Software Architect
 **Betreff:** Arbeitsauftrag: Implementierung des `ping-service` (Tracer Bullet)
@@ -199,4 +213,3 @@ Der Auftrag gilt als erledigt, wenn:
 5. Die Requests in der Zipkin UI als Trace sichtbar sind.
 
 Bei Fragen zur Konfiguration oder zur Architektur stehe ich dir zur Verfügung.
-

docs/99_Journal/2026-01-23_Session_Log.md

@@ -0,0 +1,42 @@
+---
+type: Journal
+status: COMPLETED
+owner: Curator
+date: 2026-01-23
+participants:
+  - Lead Architect
+  - Backend Developer
+  - Curator
+---
+
+# Session Log: 23. Jänner 2026
+
+## Zielsetzung
+Abschluss der "Tracer Bullet" Phase durch Härtung des Backends (Flyway) und Professionalisierung der Zusammenarbeit (Agent Protocol).
+
+## Durchgeführte Arbeiten
+
+### 1. Backend Hardening (Production Readiness)
+*   **Flyway:** Aktivierung von Flyway Migrationen für den `ping-service`.
+    *   `V1__init_ping.sql`: Schema-Definition.
+    *   `V2__seed_data.sql`: Initiale Testdaten für Sync-Tests.
+*   **Hibernate:** Umstellung von `ddl-auto` auf `validate`. Damit ist sichergestellt, dass die Anwendung nur startet, wenn das DB-Schema exakt zum Code passt.
+
+### 2. Agent Protocol & Organisation
+*   **AGENTS.md:** Definition eines strikten Protokolls für die Interaktion zwischen User und KI-Agenten.
+    *   Einführung von Badges (z.B. `🏗️ [Lead Architect]`) zur Kontext-Setzung.
+    *   Verlinkung aller Playbooks.
+*   **UI/UX Designer:** Einführung einer neuen Rolle für "High-Density Enterprise Design". Playbook erstellt.
+
+### 3. Dokumentation
+*   **Cleanup:** Aktualisierung der `docs/README.md` als zentraler Einstiegspunkt.
+*   **Status:** Erstellung des `docs/90_Reports/2026-01-23_Weekend_Status_Report.md`.
+
+## Ergebnisse
+*   Der `ping-service` ist nun technisch bereit für den produktiven Einsatz (kein `ddl-auto` mehr).
+*   Die Zusammenarbeit ist durch klare Rollen und Protokolle effizienter gestaltet.
+*   Der Status des Projekts ist "Grün" in allen Bereichen (außer Web-Auth, das für nächste Woche geplant ist).
+
+## Nächste Schritte (Montag)
+*   **Integration Test:** Vollständiger Durchstich (Frontend -> Gateway -> Service -> DB) mit dem gehärteten Stack.
+*   **Web Auth:** Implementierung PKCE Flow.

docs/README.md

@@ -1,37 +1,44 @@
-# Projektdokumentation "Meldestelle"
+# 📚 Projektdokumentation "Meldestelle"
 
-Willkommen zur zentralen Projektdokumentation. Dieses Verzeichnis ist die "Single Source of Truth" für alle architektonischen Entscheidungen, Anleitungen und Implementierungsdetails.
+Willkommen im "Gehirn" des Projekts. Dieses Verzeichnis ist die **Single Source of Truth**.
 
-Die Dokumentation wird nach dem **"Docs-as-Code"**-Prinzip gepflegt: Sie liegt neben dem Code, wird mit Git versioniert und von allen Teammitgliedern (Mensch und KI) aktuell gehalten.
+## 📂 Struktur
 
-## Struktur der Dokumentation
+### 🏗️ Core
+*   **[`01_Architecture`](01_Architecture/)**: Der Masterplan. ADRs, Roadmaps und C4-Modelle.
+    *   *Start hier:* `MASTER_ROADMAP_2026_Q1.md`
+*   **[`02_Onboarding`](02_Onboarding/)**: Guides für neue Entwickler (Setup, Guidelines).
+*   **[`03_Domain`](03_Domain/)**: Fachlichkeit (Turnierregeln, Entities).
 
-*   **/01_Architecture**: Architektur (ADRs, C4/Diagramme, Architektur-Referenzen).
+### 🛠️ Tech Stack
-*   **/02_Onboarding**: Einstieg & Entwickler-Workflow (lokales Setup, PR-Workflow, Style-Guides).
+*   **[`05_Backend`](05_Backend/)**: Spring Boot Services, API-Specs, DB-Schema.
-*   **/03_Domain**: Fachliche Domäne (Kern-Modell, Referenzen, Analyse).
+    *   *Referenz:* `Services/PingService_Reference.md`
-*   **/04_Agents**: Agent Operating Model (AOM) + Playbooks für KI-Unterstützung.
+*   **[`06_Frontend`](06_Frontend/)**: Kotlin Multiplatform, Compose UI, State Management.
-*   **/05_Backend**: Backend-spezifische Dokumentation (Services, Datenmodelle, Integrationen).
+*   **[`07_Infrastructure`](07_Infrastructure/)**: Docker, Keycloak, CI/CD.
-*   **/06_Frontend**: Frontend-spezifische Dokumentation (KMP/Compose, Offline/Synchronisierung).
-*   **/07_Infrastructure**: Betrieb & Infrastruktur (Docker, Keycloak, Observability, Runbooks).
-*   **/90_Reports**: Berichte/Analysen/Status-Reports (zeitlich geordnet, nicht zwingend „verbindliche Regeln“).
-*   **/99_Journal**: Kurzprotokolle pro Session (Anti-Wissensverlust, Nachvollziehbarkeit).
 
-## Wie man diese Dokumentation pflegt
+### 🤖 Process
+*   **[`04_Agents`](04_Agents/)**: Playbooks für unsere KI-Mitarbeiter.
+*   **[`90_Reports`](90_Reports/)**: Statusberichte und Meilenstein-Analysen.
+*   **[`99_Journal`](99_Journal/)**: Tägliche Session-Logs.
 
-Jeder Entwickler und jeder KI-Agent ist dafür verantwortlich, die Dokumentation, die seinen Arbeitsbereich betrifft, zu aktualisieren.
+---
 
-*   **Bei neuen Features:** Erstelle oder aktualisiere die entsprechende Implementierungs-Doku.
+## 📝 Regeln für die Dokumentation
-*   **Bei Architektur-Änderungen:** Erstelle ein neues ADR oder aktualisiere ein bestehendes.
-*   **Bei Änderungen am Setup:** Passe die Anleitungen im `Onboarding`- oder `Infrastructure`-Verzeichnis an.
 
-Änderungen an der Dokumentation sollten Teil derselben Pull Request/Commit sein wie die zugehörigen Code-Änderungen.
+1.  **Docs-as-Code:** Doku liegt beim Code und wird im selben PR aktualisiert.
+2.  **Frontmatter:** Jede Markdown-Datei muss einen YAML-Header haben:
+    ```yaml
+    ---
+    type: [ADR, Guide, Reference, Report, Journal]
+    status: [DRAFT, ACTIVE, DEPRECATED, ARCHIVED]
+    owner: [Rolle]
+    ---
+    ```
+3.  **Archivierung:** Lösche nichts. Verschiebe veraltetes Wissen in `_archive` Ordner oder markiere es als `ARCHIVED`.
 
-### Wichtigste Einstiege
+---
 
-*   Lokales Setup/Workflow: `docs/02_Onboarding/`
+## 🚀 Quick Links
-*   Fachliches Modell: `docs/03_Domain/`
+*   [Master Roadmap](01_Architecture/MASTER_ROADMAP_2026_Q1.md)
-*   Agenten/Arbeitsmodus: `docs/04_Agents/`
+*   [Ping Service Reference](05_Backend/Services/PingService_Reference.md)
-*   Architekturentscheidungen: `docs/01_Architecture/adr/`
+*   [Agent Playbooks](04_Agents/)
-*   Backend (pro Service): `docs/05_Backend/Services/`
-*   Ping-Service (Startpunkt): `docs/05_Backend/Services/ping-service.md`
-*   Ping-Service Implementierungs-Report (Historie): `docs/90_Reports/Ping-Service_Impl_01-2026.md`

frontend/features/ping-feature/src/commonTest/kotlin/at/mocode/ping/feature/integration/PingSyncIntegrationTest.kt

@@ -23,7 +23,7 @@ class PingSyncIntegrationTest {
 
     // Mock API Response
     val mockEngine = MockEngine { request ->
-      assertEquals("/api/pings/sync", request.url.encodedPath)
+      assertEquals("/api/ping/sync", request.url.encodedPath)
 
       val responseBody = """
         [