docs: consolidate roadmaps and update architecture documentation

Replaced fragmented roadmaps with a single MASTER_ROADMAP for Q1 2026 as the authoritative source. Deprecated outdated roadmap files and updated Architect playbook to reflect new ownership and delegation responsibilities. Introduced architecture improvement proposals and added related documents for enhanced collaboration and knowledge sharing.

docs/01_Architecture/Roadmap_System_Hardening.md

@@ -1,53 +1,9 @@
-# Roadmap: System-Instandsetzung & Härtung (via Ping-Service)
+# DEPRECATED
 
-Diese Roadmap beschreibt den Plan, den **Ping-Service** als Speerspitze für die technische Instandsetzung und Härtung der gesamten Microservices-Infrastruktur zu nutzen.
+⚠️ **Dieses Dokument ist veraltet.**
 
-**Status:** Entwurf (Bereit für Start am 15.01.2026)
-**Lead:** Software Architect
+Bitte nutze ausschließlich die **[MASTER ROADMAP](MASTER_ROADMAP_2026_Q1.md)** für aktuelle Aufgaben und Planung.
 
 ---
-
-## Phase 1: Infrastruktur-Diagnose (Instandsetzung)
-*Ziel: Sicherstellen, dass alle Basis-Komponenten stabil miteinander sprechen.*
-
-- [ ] **Deep-Health-Check im Ping-Service:**
-    - Implementierung eines `/api/v1/ping/deep` Endpunkts.
-    - Aktive Prüfung der PostgreSQL-Verbindung (via `Exposed`).
-    - Aktive Prüfung der Cache-Verbindung (Valkey/Redis via `Lettuce`).
-    - Validierung der Consul-Registrierung und Config-Abfrage.
-- [ ] **Infrastruktur-Migration (Open Source Härtung):**
-    - Umstellung von Redis auf **Valkey** im `docker-compose.yaml`.
-    - Anpassung der Verbindungs-Parameter im Ping-Service.
-
-## Phase 2: Resilience & Stabilität (Härtung)
-*Ziel: Fehlertoleranz gegenüber Infrastruktur-Ausfällen.*
-
-- [ ] **Resilience4j Integration:**
-    - Konfiguration eines Circuit Breakers für DB-Zugriffe im Ping-Service.
-    - Implementierung eines Fallback-Mechanismus (z.B. "Degraded Mode" Antwort).
-- [ ] **Timeout-Härtung:**
-    - Definition und Test von strikten Connect- und Read-Timeouts in der `application.yaml`.
-- [ ] **Gateway-Integration:**
-    - Test des Rate-Limitings am Gateway speziell für den Ping-Service.
-
-## Phase 3: Security & Observability
-*Ziel: Absicherung der Kommunikationswege und lückenlose Überwachung.*
-
-- [ ] **Security-Chain Validierung:**
-    - Aktivierung der JWT-Prüfung im Ping-Service.
-    - Test der "Service-to-Service" Kommunikation mit Mock-Tokens.
-- [ ] **Tracing-Check:**
-    - Verifikation der Micrometer Tracing Integration (Trace-IDs in Logs und Zipkin).
-
-## Phase 4: Standardisierung (Blueprint)
-*Ziel: Übertragung der Erkenntnisse auf alle anderen Services.*
-
-- [ ] **Refactoring Common-Module:**
-    - Verschieben der bewährten Health- und Resilience-Konfigurationen in ein `core-backend` Modul.
-- [ ] **Update der Dokumentation:**
-    - Aktualisierung der Service-Templates basierend auf dem Ping-Service "Blueprint".
-
----
-
-## Nächster Schritt (Morgen):
-Start mit **Phase 1**: Implementierung des `Deep-Ping` Endpunkts und Vorbereitung der Valkey-Migration.
+(Originalinhalt archiviert)
+...