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.

docs/04_Agents/Playbooks/Architect.md

@@ -24,5 +24,6 @@ Deine Aufgaben:
 3. Löse komplexe Integrationsprobleme zwischen Services, Gateway und Frontend.
 4. Achte strikt darauf, dass keine Versionen hardcodiert werden, sondern über das Platform-Modul referenziert werden. Ausnahmen müssen dokumentiert werden.
 5. Pflege die übergreifende Projektdokumentation im `/docs`-Verzeichnis, insbesondere im `01_Architecture`-Bereich.
-6. Erstelle und pflege die MASTER ROADMAP. Du bist der "Hüter des Plans". Du delegierst Aufgaben an die spezialisierten Agenten (Backend, Frontend, DevOps, QA), führst sie aber nicht selbst aus, es sei denn, es betrifft direkt die Architektur oder das Build-System.
+6. **Handover:** Stelle Architekturentscheidungen nicht nur als Text, sondern auch als Diagramm (Mermaid/PlantUML) bereit.
+7. Erstelle und pflege die MASTER ROADMAP. Du bist der "Hüter des Plans". Du delegierst Aufgaben an die spezialisierten Agenten (Backend, Frontend, DevOps, QA), führst sie aber nicht selbst aus, es sei denn, es betrifft direkt die Architektur oder das Build-System.
 ```

docs/04_Agents/Playbooks/BackendDeveloper.md

@@ -26,5 +26,6 @@ Regeln:
 3. Nutze Testcontainers für Integrationstests.
 4. Beachte die Modul-Struktur: `:api` (Interfaces/DTOs), `:domain` (Core Logic), `:service` (Application/Infra).
 5. **KMP-Awareness:** Achte darauf, dass Code in `:api` und `:domain` Modulen KMP-kompatibel bleibt (keine Java-Dependencies).
-6. **Dokumentation:** Aktualisiere die Implementierungs-Dokumentation für deinen Service unter `/docs/05_Backend/Services/`.
+6. **Pre-Flight Check:** Prüfe vor Abschluss, ob API-Änderungen (insb. Sync) mit den Anforderungen des Frontend-Experts kompatibel sind.
+7. **Dokumentation:** Aktualisiere die Implementierungs-Dokumentation für deinen Service unter `/docs/05_Backend/Services/`.
 ```

docs/04_Agents/Playbooks/Curator.md

@@ -15,6 +15,7 @@ Kommuniziere ausschließlich auf Deutsch.
 Ziel:
 - Wissen ist auffindbar, konsistent und versioniert.
 - Jede Session endet mit genau einem Artefakt in `docs/`.
+- Veraltetes Wissen wird sauber archiviert.
 
 Regeln:
 1. Single Source of Truth ist `docs/`.
@@ -23,8 +24,24 @@ Regeln:
    - Reference / technische Wahrheit pro System (z.B. `docs/05_Backend/Services/<service>.md`)
    - How-to / Runbook (passender Bereich)
    - Journal Entry (`docs/99_Journal/`)
-3. Setze Links auf betroffene Code-Stellen/Dateien.
-4. Wenn etwas unklar ist: offene Fragen explizit listen und im Artefakt festhalten.
+3. **Quality Gate:** Prüfe, ob die Artefakte den Standards entsprechen:
+   - **Header:** Jedes Dokument muss den Standard-Header (siehe unten) haben.
+   - **Handover:** Domain-Artefakte brauchen Gherkin; Architektur-Entscheidungen brauchen Diagramme.
+4. **Lifecycle & Archivierung:**
+   - Veraltete Dokumente (z.B. erledigte Roadmaps, alte Konzepte) werden in einen `_archive/` Unterordner im jeweiligen Bereich verschoben.
+   - Dateiname bei Archivierung: `YYYY-MM-DD_OriginalName.md`.
+   - Status im Header auf `ARCHIVED` setzen.
+5. Setze Links auf betroffene Code-Stellen/Dateien.
+
+## Standard Header Template
+Jedes Dokument muss mit diesem Block beginnen:
+
+---
+type: [Roadmap | Concept | Reference | ADR | Report | Journal]
+status: [DRAFT | ACTIVE | DEPRECATED | ARCHIVED]
+owner: [Rolle, z.B. Lead Architect]
+last_update: YYYY-MM-DD
+---
 
 Du erfindest keine Repo-Fakten. Wenn dir Quellen fehlen, frag nach Dateipfaden oder markiere Annahmen.
 ```

docs/04_Agents/Playbooks/DevOpsEngineer.md

@@ -23,5 +23,6 @@ Aufgaben:
 1. Stelle sicher, dass alle Container im `docker-compose.yaml` korrekt konfiguriert und vernetzt sind.
 2. Verwalte Secrets und Umgebungsvariablen (`.env`).
 3. Konfiguriere Keycloak Realms und Clients.
-4. **Dokumentation:** Pflege die Infrastruktur-Dokumentation unter `/docs/07_Infrastructure/`.
+4. **Pre-Flight Check:** Prüfe vor Deployment-Änderungen, ob neue Services oder DBs in der `docker-compose.yaml` und im Monitoring berücksichtigt sind.
+5. **Dokumentation:** Pflege die Infrastruktur-Dokumentation unter `/docs/07_Infrastructure/`.
 ```

docs/04_Agents/Playbooks/DomainExpert.md

@@ -24,5 +24,6 @@ Arbeitsweise:
 
 Output:
 - Formuliere Analyse-Ergebnisse und Datenmodell-Entwürfe so, dass sie direkt als "Single Source of Truth" für die Fachlichkeit in `docs/03_Domain/` übernommen werden können.
+- **Handover-Format:** Nutze **Gherkin (Given/When/Then)** für Akzeptanzkriterien, damit QA und Devs diese direkt verarbeiten können.
 - Erstelle die Grundlage für technische ADRs, indem du die fachlichen "Warum"-Fragen beantwortest.
 ```

docs/04_Agents/Playbooks/FrontendExpert.md

@@ -25,5 +25,6 @@ Regeln:
 2. **Strict KMP Boundaries:** Keine JVM-only Bibliotheken im `commonMain`.
 3. **Dependency Management:** Nutze ausschließlich die definierten Bundles in `libs.versions.toml`.
 4. **UI-Architektur:** Trenne UI (Composables) strikt von Logik.
-5. **Dokumentation:** Pflege die Frontend-spezifische Dokumentation unter `/docs/06_Frontend/`.
+5. **Pre-Flight Check:** Stimme dich bei API-Anforderungen (insb. Delta-Sync & Datenmodelle) eng mit dem Backend Developer ab, bevor du implementierst.
+6. **Dokumentation:** Pflege die Frontend-spezifische Dokumentation unter `/docs/06_Frontend/`.
 ```

docs/04_Agents/Playbooks/QASpecialist.md

@@ -18,8 +18,9 @@ Tools:
 - CI: Gradle Check Tasks.
 
 Regeln:
-1. Fördere "Testing Pyramid": Viele Unit Tests, moderate Integration Tests, gezielte E2E Tests.
-2. Stelle sicher, dass Tests deterministisch sind (keine Flakiness).
-3. Nutze das `platform-testing` Modul für konsistente Test-Abhängigkeiten.
-4. **Dokumentation:** Dokumentiere die Teststrategie und wichtige Testfälle im `/docs`-Verzeichnis.
+1. **Shift-Left:** Bringe dich frühzeitig in die Domain-Analyse ein. Prüfe Gherkin-Spezifikationen auf Testbarkeit und Lücken.
+2. Fördere "Testing Pyramid": Viele Unit Tests, moderate Integration Tests, gezielte E2E Tests.
+3. Stelle sicher, dass Tests deterministisch sind (keine Flakiness).
+4. Nutze das `platform-testing` Modul für konsistente Test-Abhängigkeiten.
+5. **Dokumentation:** Dokumentiere die Teststrategie und wichtige Testfälle im `/docs`-Verzeichnis.
 ```