infra: integrate Keycloak monitoring, update alertmanager config, and finalize docs cleanup

Added a Prometheus scrape job for Keycloak metrics. Updated Alertmanager to use Mailpit for local testing. Completed documentation consolidation and marked cleanup-related tasks as done in the master roadmap.

.gitea/workflows/docker-publish.yaml

@@ -10,9 +10,6 @@ on:
       - 'core/**'
       - 'frontend/**'
       - 'config/docker/**'
-      #      - 'build.gradle.kts'
-      #      - 'settings.gradle.kts'
-      #      - 'gradle.properties'
       - 'docker-compose.yaml'
       - '.gitea/workflows/docker-publish.yaml'
 
@@ -105,20 +102,6 @@ jobs:
           username: ${{ secrets.REGISTRY_USER }}
           password: ${{ secrets.REGISTRY_TOKEN }}
 
-      #      - name: Build and push Docker image
-      #        uses: docker/build-push-action@v6
-      #        with:
-      #          context: .
-      #          file: ${{ matrix.dockerfile }}
-      #          push: true
-      #          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_PREFIX }}/${{ matrix.name }}:latest
-      #          build-args: |
-      #            DOCKER_BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ')
-      #            VERSION=${{ github.sha }}
-      #            GRADLE_VERSION=${{ env.GRADLE_VERSION }}
-      #            JAVA_VERSION=${{ env.JAVA_VERSION }}
-      #            JVM_OPTS_APPEND=${{ env.JVM_OPTS_ARM64 }}
-
       - name: Extract metadata
         id: meta
         uses: docker/metadata-action@v5
@@ -145,7 +128,3 @@ jobs:
             JAVA_VERSION=${{ env.JAVA_VERSION }}
             KEYCLOAK_IMAGE_TAG=26.4
             JVM_OPTS_APPEND=${{ env.JVM_OPTS_ARM64 }}
-#          cache-from: type=local,src=/tmp/.buildx-cache
-#          cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max
-#          cache-from: type=gha
-#          cache-to: type=gha,mode=max

config/docker/monitoring/alertmanager/alertmanager.yaml

@@ -1,26 +1,19 @@
 global:
   resolve_timeout: 5m
-  # FIX: Hier müssen echte Werte stehen, keine Variablen!
+  # Wir nutzen Mailpit für lokale Tests
-  # Wenn du noch keinen SMTP hast, trag Dummy-Werte ein, damit der Container startet.
+  smtp_smarthost: 'mailpit:1025'
-  smtp_smarthost: 'smtp.gmail.com:587'
+  smtp_from: 'alertmanager@meldestelle.local'
-  smtp_from: 'alertmanager@meldestelle.at'
+  smtp_require_tls: false
-  smtp_auth_username: 'deine-email@gmail.com'
-  smtp_auth_password: 'dein-passwort'
-  smtp_require_tls: true
 
 route:
+  group_by: ['alertname']
+  group_wait: 10s
+  group_interval: 10s
+  repeat_interval: 1h
   receiver: 'email-notifications'
-  # ... (Rest bleibt gleich)
 
 receivers:
   - name: 'email-notifications'
     email_configs:
-      - to: 'admin@meldestelle.at'
+      - to: 'admin@meldestelle.local'
         send_resolved: true
-
-  - name: 'slack-critical'
-    slack_configs:
-      # FIX: Auch hier die echte Webhook URL eintragen oder den Block entfernen, wenn nicht genutzt
-      - api_url: 'https://hooks.slack.com/services/example'
-        channel: '#alerts-critical'
-        # ...

config/docker/monitoring/prometheus/prometheus.yaml

@@ -12,8 +12,6 @@ alerting:
   alertmanagers:
     - static_configs:
         - targets:
-            # Da wir Alertmanager noch nicht im Docker Compose haben (kommt noch!),
-            # lassen wir das vorerst auskommentiert oder fügen den Container hinzu.
             - "alertmanager:9093"
 
 rule_files:
@@ -33,7 +31,13 @@ scrape_configs:
     static_configs:
       - targets: [ 'consul:8500' ]
 
-  # 3. Spring Boot Services via Consul Discovery.
+  # 3. Keycloak Metrics (statisches Target)
+  - job_name: 'keycloak'
+    metrics_path: '/metrics'
+    static_configs:
+      - targets: [ 'keycloak:8080' ]
+
+  # 4. Spring Boot Services via Consul Discovery.
   # Das ist die Magie: Prometheus fragt Consul nach allen Services.
   # Wenn ein Service das Tag 'metrics' oder 'spring-boot' hat (oder einfach alle), wird er scraped.
   - job_name: 'consul-services'
@@ -62,7 +66,7 @@ scrape_configs:
         separator: ':'
         target_label: instance
 
-  # Job 4: Postgres Exporter (Statisch, da kein Consul-Client im Image)
+  # Job 5: Postgres Exporter (Statisch, da kein Consul-Client im Image)
   - job_name: 'postgres-exporter'
     static_configs:
       - targets: [ 'postgres-exporter:9187' ]

config/scripts/backup.sh

@@ -0,0 +1,42 @@
+#!/bin/bash
+# ==========================================
+#  Meldestelle Backup Script
+#  Sichert Datenbanken und Konfigurationen
+# ==========================================
+
+# Konfiguration
+BACKUP_DIR="/home/grandmo/backups/meldestelle"
+DATE=$(date +%Y-%m-%d_%H-%M-%S)
+RETENTION_DAYS=7
+PROJECT_NAME="meldestelle"
+
+# Container Namen (müssen mit docker-compose übereinstimmen)
+DB_CONTAINER="${PROJECT_NAME}-postgres"
+DB_USER="meldestelle" # Oder aus .env lesen
+
+# Verzeichnisse erstellen
+mkdir -p "$BACKUP_DIR"
+
+echo "🚀 Starte Backup: $DATE"
+
+# 1. PostgreSQL Dump
+echo "   -> Erstelle Datenbank-Dump..."
+if docker exec "$DB_CONTAINER" pg_dumpall -U "$DB_USER" > "$BACKUP_DIR/db_dump_$DATE.sql"; then
+    echo "      ✅ DB Dump erfolgreich."
+    gzip "$BACKUP_DIR/db_dump_$DATE.sql"
+else
+    echo "      ❌ FEHLER beim DB Dump!"
+    # Optional: Mail senden oder Exit Code setzen
+fi
+
+# 2. Konfigurations-Dateien sichern (.env ist kritisch!)
+echo "   -> Sichere Konfigurationen..."
+tar -czf "$BACKUP_DIR/config_$DATE.tar.gz" .env docker-compose.yaml dc-*.yaml config/
+
+# 3. Alte Backups löschen (Rotation)
+echo "   -> Lösche Backups älter als $RETENTION_DAYS Tage..."
+find "$BACKUP_DIR" -name "db_dump_*.sql.gz" -mtime +$RETENTION_DAYS -delete
+find "$BACKUP_DIR" -name "config_*.tar.gz" -mtime +$RETENTION_DAYS -delete
+
+echo "✅ Backup abgeschlossen: $BACKUP_DIR"
+ls -lh "$BACKUP_DIR" | grep "$DATE"

config/scripts/deploy.sh

@@ -0,0 +1,22 @@
+#!/bin/bash
+# deploy.sh - Update & Restart Meldestelle Stack
+
+echo "🚀 Starte Deployment..."
+
+# 1. Neueste Konfiguration holen
+echo "   -> Git Pull..."
+git pull origin main
+
+# 2. Neue Images laden
+echo "   -> Docker Pull..."
+docker compose pull
+
+# 3. Container neu starten (nur geänderte)
+echo "   -> Docker Up..."
+docker compose up -d --remove-orphans
+
+# 4. Aufräumen
+echo "   -> Pruning old images..."
+docker image prune -f
+
+echo "✅ Deployment erfolgreich!"

dc-backend.yaml

@@ -29,8 +29,8 @@ services:
       DEBUG: "${GATEWAY_DEBUG:-true}"
 
       # --- KEYCLOAK ---
-      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: "${SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI}"
+      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: "${KC_ISSUER_URI:-http://localhost:8180/realms/meldestelle}"
-      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI: "${SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI}"
+      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI: "${KC_JWK_SET_URI:-http://keycloak:8080/realms/meldestelle/protocol/openid-connect/certs}"
 
       # --- CONSUL ---
       SPRING_CLOUD_CONSUL_HOST: "${SPRING_CLOUD_CONSUL_HOST:-consul}"
@@ -104,8 +104,8 @@ services:
       SERVER_PORT: "${PING_SERVER_PORT:-8082}"
 
       # --- KEYCLOAK ---
-      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: "${SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI}"
+      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER_URI: "${KC_ISSUER_URI:-http://localhost:8180/realms/meldestelle}"
-      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI: "${SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI}"
+      SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI: "${KC_JWK_SET_URI:-http://keycloak:8080/realms/meldestelle/protocol/openid-connect/certs}"
 
       # --- CONSUL ---
       SPRING_CLOUD_CONSUL_HOST: "${CONSUL_HOST:-consul}"

dc-infra.yaml

@@ -108,6 +108,7 @@ services:
       meldestelle-network:
         aliases:
           - "keycloak"
+          - "auth.mo-code.at"
 
   # --- SERVICE DISCOVERY: Consul ---
   consul:

docs/01_Architecture/MASTER_ROADMAP.md

@@ -0,0 +1,67 @@
+---
+type: Roadmap
+status: ACTIVE
+owner: Lead Architect
+last_update: 2026-03-05
+---
+
+# MASTER ROADMAP: "Operation Self-Sovereignty"
+
+**Strategisches Ziel:**
+Vollständige Migration auf Self-Hosted Infrastruktur (Gitea, Pangolin, Zora) und Konsolidierung der Dokumentation. Der Fokus liegt auf Datensouveränität, Offline-Fähigkeit und einer sauberen, aktuellen Wissensbasis.
+
+**Aktueller technischer Stand (05.03.2026):**
+*   **Infrastruktur:** ✅ "Zora" (MS-R1, ARM64) ist live. Gitea & Registry laufen.
+*   **Networking:** ✅ Pangolin Tunnel ersetzt Cloudflare.
+*   **CI/CD:** ✅ Gitea Actions mit ARM64-Runner (VM 102) aktiv. Docker-Publish Pipeline grün.
+*   **Code-Basis:** ✅ Backend (Java 25), Frontend (Kotlin/JS) bauen sauber auf ARM64.
+*   **Dokumentation:** ✅ Konsolidiert und aufgeräumt.
+
+---
+
+## 1. Arbeitsaufträge an die AGENTS (Phasenplan)
+
+### PHASE 1: Documentation Cleanup (ABGESCHLOSSEN)
+*Ziel: Eine einzige, vertrauenswürdige Quelle der Wahrheit (SSOT) schaffen.*
+
+#### 🧹 Agent: Curator
+*   [x] **Archivierung:** Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach `docs/_archive/` verschoben.
+*   [x] **Konsolidierung:** `Zora_System_Architektur.md` als zentrale Infrastruktur-Doku etablieren.
+*   [x] **Struktur:** `docs/` Ordner aufräumen (unnötige Root-Files in Unterordner).
+*   [x] **Index:** `README.md` im Root als Einstiegspunkt aktualisieren.
+
+### PHASE 2: Infrastructure Hardening (ABGESCHLOSSEN)
+*Ziel: Stabilisierung der neuen Self-Hosted Umgebung.*
+
+#### 🐧 Agent: DevOps Engineer
+*   [x] **Keycloak Fix:** Verbindungsprobleme innerhalb des Docker-Netzwerks (`meldestelle-host`) behoben (Alias `auth.mo-code.at`).
+*   [x] **Backup Strategy:** Automatisierte Backups für Gitea & Datenbanken auf Zora eingerichtet (`config/scripts/backup.sh`).
+*   [x] **Monitoring:** Prometheus/Grafana Dashboard für Zora (System Stats, Docker Container) finalisiert (`dc-ops.yaml`).
+*   [x] **Deployment:** Git-basiertes Deployment-Skript (`config/scripts/deploy.sh`) erstellt.
+
+### PHASE 3: Feature Development (ON HOLD)
+*Ziel: Neuausrichtung der Fachlichkeit.*
+
+#### 🏗️ Agent: Lead Architect & Domain Expert
+*   [ ] **Domain Analysis:** Workshop mit dem Fachexperten zur Neudefinition der Anforderungen.
+*   [ ] **Feature Roadmap:** Erstellung eines neuen Plans basierend auf den Ergebnissen.
+*   [ ] **Entries Service:** Pausiert bis zur Klärung der Anforderungen.
+
+---
+
+## 2. Definition of Done (für Phase 1 & 2)
+1.  [x] `docs/` Root enthält nur noch essentielle Einstiegspunkte (`README.md`, `MASTER_ROADMAP.md`).
+2.  [x] Alle veralteten Dokumente sind im `_archive` oder gelöscht.
+3.  [x] Die `Zora_System_Architektur.md` ist korrekt in `docs/07_Infrastructure/` eingeordnet.
+4.  [x] Ein neuer Entwickler findet sich sofort zurecht.
+5.  [x] Keycloak ist intern erreichbar.
+6.  [x] Backups laufen automatisch.
+
+---
+
+## 3. Wichtige Referenzen
+*   **Infrastruktur:** `docs/07_Infrastructure/Zora_System_Architektur.md`
+*   **Deployment Guide:** `docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md`
+*   **Backup Guide:** `docs/07_Infrastructure/Guides/Setup_Backup_Zora.md`
+*   **CI/CD:** `.gitea/workflows/docker-publish.yaml`
+*   **Projekt-Protokoll:** `docs/04_Agents/Playbooks/`

docs/01_Architecture/_archive/MASTER_ROADMAP_2026_Q1.md

@@ -0,0 +1,83 @@
+---
+type: Roadmap
+status: ACTIVE
+owner: Lead Architect
+last_update: 2026-02-07
+---
+
+# MASTER ROADMAP Q1 2026: "Operation Tracer Bullet"
+
+**Strategisches Ziel:**
+Wir validieren die gesamte Architektur-Kette (Frontend -> Gateway -> Service -> DB) anhand des **Ping-Service**. Dieser Service dient als **technischer Blueprint** (Vorlage) für alle kommenden Fach-Services. Er muss "Production Ready" gehärtet sein, bevor wir Fachlichkeit implementieren.
+
+**Aktueller technischer Stand (07.02.2026):**
+*   Build System: ✅ Grün (Gradle, Kotlin 2.3, Spring Boot 3.5.9, Spring Cloud 2025.0.1).
+*   Code-Basis: ✅ `ping-service` existiert, Delta-Sync implementiert.
+*   Infrastruktur: ✅ Docker Environment stabil (Valkey, Keycloak, Consul, Zipkin).
+*   Frontend: ✅ Web-App & Desktop-App (KMP), Login funktioniert, Sync-Logik vorhanden.
+*   Hardware: ✅ Minisforum MS-R1 eingetroffen.
+
+---
+
+## 2. Arbeitsaufträge an die AGENTS (Phasenplan)
+
+### PHASE 1: Backend Hardening & Infrastructure (ABGESCHLOSSEN)
+*Ziel: Der Ping-Service läuft sicher, stabil und beobachtbar in der Docker-Umgebung.*
+
+#### 👷 Agent: Senior Backend Developer
+*   [x] **Security Implementation:** OAuth2 Resource Server & RBAC implementiert.
+*   [x] **Resilience:** CircuitBreaker für `/ping/enhanced` aktiv.
+*   [x] **Observability:** Actuator, Micrometer & Zipkin Tracing aktiv.
+*   [x] **Persistence:** Flyway & Postgres Integration stabil.
+
+#### 🏗️ Agent: Infrastructure & DevOps
+*   [x] **Docker Environment:** `dc-infra`, `dc-backend`, `dc-gui` stabil. Valkey als Redis-Ersatz integriert.
+*   [x] **Gateway Config:** Routing `/api/ping/**` -> `ping-service` mit CircuitBreaker Fallback konfiguriert.
+
+---
+
+### PHASE 2: Frontend Integration (ABGESCHLOSSEN)
+*Ziel: Das Frontend kann authentifiziert mit dem Backend sprechen.*
+
+#### 🎨 Agent: KMP Frontend Expert
+*   [x] **HTTP Client Core:** Ktor Client mit Auth & Error Handling.
+*   [x] **Authentication Flow:** OIDC Login Flow (Keycloak) implementiert.
+*   [x] **UI Implementation:** Debug-Screen für Pings vorhanden.
+
+---
+
+### PHASE 3: Offline & Sync (ABGESCHLOSSEN)
+*Ziel: Datenkonsistenz auch bei Netzwerk-Verlust.*
+
+#### 🤝 Joint Task Force (Backend & Frontend)
+*   [x] **Sync-Protokoll:** `PingEvent` Contract definiert.
+*   [x] **Sync-Fix (CRITICAL):** Typ-Mismatch behoben! Backend und Frontend nutzen nun konsistent `since: Long`.
+*   [x] **Web-App Sync:** SQLDelight Integration vorbereitet.
+
+---
+
+## 3. Definition of Done (für Phase 1 & 2)
+1.  [x] `docker compose up` startet den kompletten Stack fehlerfrei.
+2.  [x] Frontend-User kann sich einloggen (Keycloak).
+3.  [x] Frontend zeigt Daten vom `ping-service` an.
+4.  [x] Beim Abschalten der DB zeigt der Service einen sauberen Fallback (CircuitBreaker offen).
+5.  [x] In Zipkin ist der komplette Request-Trace (Frontend -> Gateway -> Service -> DB) sichtbar.
+
+## 4. Next Steps (Q1/2026)
+1.  **Entries Service:** Beginn der Implementierung des ersten echten Fach-Services ("Nennungen").
+2.  **System Hardening:** Keycloak Production-Config (kein `start-dev`).
+3.  **Reporting / Printing:** (Vorgemerkt)
+    *   Anforderung: PDF-Generierung für Startlisten, Ergebnislisten, Dressur-Protokolle (personalisiert).
+    *   Architektur-Entscheidung: Dezentraler Microservice (wegen Resource-Bursts).
+    *   Technologie-Evaluierung: JasperReports, Thymeleaf + Flying Saucer, etc.
+4.  **Infrastructure Setup (Home-Server):**
+    *   Hardware: Minisforum MS-R1 (ARM64, 12 Cores, 10G LAN) ✅ **GELIEFERT (07.02.2026)**.
+    *   OS: Debian 12 (Vendor Variant) als Host.
+    *   Hypervisor: **Incus** (LXC/LXD Fork).
+    *   Virtualization Strategy:
+        *   `infra-gitea` (LXC Container): Gitea + Actions Runner (Native ARM Builds).
+        *   `docker-host-prod` (VM): Debian VM als Docker Host für den Meldestelle-Stack (Isolation, keine Nesting-Probleme).
+    *   CI/CD: **Multi-Arch Support** (Native ARM64 Builds + x86_64 via `docker buildx` & QEMU).
+    *   Networking: Cloudflare Tunnel (Remote Access).
+    *   Local Discovery: DNS/mDNS Strategie für Offline-Szenarien (Main-App als lokaler Anchor).
+    *   Backup: Automatisierte Snapshots auf externe USB-SSD.

docs/01_Architecture/_archive/Roadmap_2026_Q1.md

@@ -0,0 +1,11 @@
+---
+type: Roadmap
+status: ARCHIVED
+owner: Lead Architect
+last_update: 2026-01-15
+---
+
+# Roadmap Q1 2026: "Operation Tracer Bullet"
+
+**MOVED:** This file has been archived to `_archive/2026-01-15_Roadmap_2026_Q1.md`.
+Please use `MASTER_ROADMAP_2026_Q1.md` as the Single Source of Truth.

docs/07_Infrastructure/Guides/Setup_Backup_Zora.md

@@ -0,0 +1,103 @@
+---
+type: Guide
+status: ACTIVE
+owner: DevOps Engineer
+last_update: 2026-03-05
+tags: [backup, postgres, zora, cron]
+---
+
+# 🛡️ Guide: Automatisierte Backups auf Zora
+
+Dieser Guide beschreibt, wie du regelmäßige Backups der Meldestelle-Datenbank und Konfigurationen auf Zora einrichtest.
+
+## 📋 Voraussetzungen
+
+*   SSH-Zugriff auf Zora (`ssh user@10.0.0.xx`).
+*   Docker-Container `meldestelle-postgres` läuft.
+*   Das Skript `config/scripts/backup.sh` liegt im Repo.
+
+---
+
+## 🛠️ Schritt-für-Schritt Anleitung
+
+### 1. Backup-Skript vorbereiten
+
+Das Skript liegt bereits im Repo unter `config/scripts/backup.sh`.
+Du musst es auf Zora ausführbar machen und ggf. anpassen.
+
+1.  Verbinde dich mit Zora:
+    ```bash
+    ssh user@zora-ip
+    cd ~/meldestelle
+    ```
+
+2.  Mache das Skript ausführbar:
+    ```bash
+    chmod +x config/scripts/backup.sh
+    ```
+
+3.  **WICHTIG:** Prüfe die Variablen im Skript (`nano config/scripts/backup.sh`):
+    *   `BACKUP_DIR`: Wohin sollen die Backups? (Standard: `/home/grandmo/backups/meldestelle`)
+    *   `DB_CONTAINER`: Name des Postgres-Containers (Standard: `meldestelle-postgres`).
+    *   `DB_USER`: Datenbank-User (Standard: `meldestelle`).
+
+### 2. Cronjob einrichten (Automatische Ausführung)
+
+Wir wollen das Backup jede Nacht um 03:00 Uhr laufen lassen.
+
+1.  Öffne die Crontab des Users:
+    ```bash
+    crontab -e
+    ```
+
+2.  Füge folgende Zeile am Ende hinzu:
+    ```cron
+    # Meldestelle Backup: Täglich um 03:00 Uhr
+    0 3 * * * /home/grandmo/meldestelle/config/scripts/backup.sh >> /home/grandmo/meldestelle/logs/backup.log 2>&1
+    ```
+
+3.  Speichern und schließen (`Ctrl+O`, `Enter`, `Ctrl+X`).
+
+### 3. Testen
+
+Führe das Skript einmal manuell aus, um sicherzustellen, dass alles klappt:
+
+```bash
+./config/scripts/backup.sh
+```
+
+*   Prüfe den Output: "✅ Backup abgeschlossen".
+*   Prüfe das Backup-Verzeichnis: `ls -lh /home/grandmo/backups/meldestelle`.
+
+---
+
+## 🔄 Wiederherstellung (Restore)
+
+Falls der Ernstfall eintritt (Datenbank korrupt oder gelöscht):
+
+1.  Stoppe die App-Container (aber lasse die DB laufen):
+    ```bash
+    docker compose stop api-gateway ping-service keycloak
+    ```
+
+2.  Entpacke das Backup:
+    ```bash
+    gunzip /home/grandmo/backups/meldestelle/db_dump_YYYY-MM-DD.sql.gz
+    ```
+
+3.  Spiele den Dump ein:
+    ```bash
+    cat db_dump_YYYY-MM-DD.sql | docker exec -i meldestelle-postgres psql -U meldestelle
+    ```
+
+4.  Starte die App wieder:
+    ```bash
+    docker compose up -d
+    ```
+
+---
+
+## 💡 Tipps
+
+*   **Offsite-Backup:** Kopiere die Backups regelmäßig auf einen externen Speicher (z.B. NAS oder Cloud), falls die Festplatte von Zora ausfällt. `rsync` ist dein Freund!
+*   **Monitoring:** Prüfe regelmäßig die Log-Datei `logs/backup.log`, ob Fehler auftreten.

docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md

@@ -0,0 +1,129 @@
+---
+type: Guide
+status: ACTIVE
+owner: DevOps Engineer
+last_update: 2026-03-05
+tags: [deployment, git, zora, docker]
+---
+
+# 🚀 Guide: Git-basiertes Deployment auf Zora einrichten
+
+Dieser Guide beschreibt, wie du den Produktions-Server "Zora" so konfigurierst, dass er Updates direkt aus dem Gitea-Repository zieht. Dies stellt sicher, dass nicht nur die Docker-Images, sondern auch die `docker-compose.yaml` Konfigurationen immer synchron sind.
+
+## 📋 Voraussetzungen
+
+*   SSH-Zugriff auf Zora (`ssh user@10.0.0.xx`).
+*   `git` und `docker` sind auf Zora installiert.
+*   Ein Gitea-Account mit Zugriff auf das `meldestelle` Repository.
+
+---
+
+## 🛠️ Schritt-für-Schritt Anleitung
+
+### 1. Projektverzeichnis vorbereiten
+
+Verbinde dich mit Zora und gehe in das Zielverzeichnis:
+
+```bash
+ssh user@zora-ip
+cd ~/meldestelle
+```
+
+**WICHTIG:** Falls dort bereits Konfigurationsdateien liegen, erstelle ein Backup:
+
+```bash
+mkdir -p ../backup_meldestelle_$(date +%F)
+cp * ../backup_meldestelle_$(date +%F)/
+```
+
+### 2. Git-Repository initialisieren
+
+Wir verwandeln den Ordner in ein Git-Repo, das mit Gitea verknüpft ist.
+
+```bash
+# Git initialisieren
+git init
+
+# Remote Origin hinzufügen (HTTPS)
+git remote add origin https://git.mo-code.at/mocode-software/meldestelle.git
+
+# Neueste Änderungen holen
+git fetch origin
+
+# Hard Reset auf den main-Branch (ACHTUNG: Überschreibt lokale Änderungen!)
+git reset --hard origin/main
+```
+
+*Jetzt sollten alle `dc-*.yaml` Dateien und Skripte im Ordner liegen.*
+
+### 3. Environment-Variablen (.env) konfigurieren
+
+Die `.env` Datei enthält Geheimnisse und wird **nicht** in Git gespeichert.
+
+1.  Kopiere die Vorlage:
+    ```bash
+    cp .env.example .env
+    ```
+
+2.  Bearbeite die Datei:
+    ```bash
+    nano .env
+    ```
+
+3.  **Wichtige Anpassungen für Production:**
+    *   `KC_HOSTNAME=auth.mo-code.at`
+    *   `KC_ISSUER_URI=https://auth.mo-code.at/realms/meldestelle`
+    *   `KC_JWK_SET_URI=http://keycloak:8080/realms/meldestelle/protocol/openid-connect/certs`
+    *   Setze starke Passwörter für Datenbank, Keycloak und Grafana!
+
+### 4. Deployment-Skript einrichten
+
+Das Skript `config/scripts/deploy.sh` liegt nun im Repo bereit (sobald wir es gepusht haben).
+Du kannst es direkt nutzen oder manuell anlegen:
+
+**Inhalt von `deploy.sh`:**
+
+```bash
+#!/bin/bash
+# deploy.sh - Update & Restart Meldestelle Stack
+
+echo "🚀 Starte Deployment..."
+
+# 1. Neueste Konfiguration holen
+echo "   -> Git Pull..."
+git pull origin main
+
+# 2. Neue Images laden
+echo "   -> Docker Pull..."
+docker compose pull
+
+# 3. Container neu starten (nur geänderte)
+echo "   -> Docker Up..."
+docker compose up -d --remove-orphans
+
+# 4. Aufräumen
+echo "   -> Pruning old images..."
+docker image prune -f
+
+echo "✅ Deployment erfolgreich!"
+```
+
+Mache das Skript ausführbar:
+
+```bash
+chmod +x config/scripts/deploy.sh
+# Optional: Symlink ins Root
+ln -s config/scripts/deploy.sh deploy.sh
+```
+
+---
+
+## 🔄 Workflow für Updates
+
+Wenn du Code oder Konfiguration gepusht hast und die CI-Pipeline durchgelaufen ist:
+
+1.  SSH auf Zora.
+2.  `cd ~/meldestelle`
+3.  `./deploy.sh`
+
+Das System ist nun auf dem neuesten Stand!

docs/07_Infrastructure/Konfig-Matrix_Dev-ProZora.md

@@ -29,4 +29,3 @@ Konfigurations-Matrix
 | **ZIPKIN_HEAP**                   | `256m`                                              | `1024m`                                       | Mehr Puffer für Tracing-Daten auf Zora.                                           |
 | **CONSUL_IMAGE**                  | `hashicorp/consul:1.22.1`                           | `hashicorp/consul:1.22.1`                     | Versionierung.                                                                    |
 | **MP_MAX_MESSAGES**               | `500`                                               | `5000`                                        | Mailpit Speicherlimit.                                                            |
-

docs/07_Infrastructure/Zora_System_Architektur.md

@@ -0,0 +1,74 @@
+
+## 🏗️ System-Architektur "Zora" (ARM64)
+
+**Stand: 05. März 2026**
+
+Die gesamte Umgebung läuft auf einer **ARM64-Architektur** (Cortex-A720). Dies bietet hohe Performance bei geringem Energieverbrauch, erfordert aber spezifische Build-Konfigurationen (SVE-Support, ARM64-Images).
+
+### 1. Gitea & Central Registry (LXC)
+
+* **Rolle:** Quellcode-Verwaltung, CI/CD-Steuerung und Container-Registry.
+* **IP-Adresse:** `10.0.0.22:3000` (Intern) / `git.mo-code.at` (Extern).
+* **Registry:** Integriert unter `git.mo-code.at`.
+* **Pfad-Struktur:** `git.mo-code.at/mocode-software/meldestelle/<service-name>`
+
+
+* **Wichtig für Entwickler:** Authentifizierung erfolgt via Gitea-Benutzer oder Access-Token.
+
+### 2. Gitea-Power-Runner (VM 102)
+
+Der Runner ist das "Arbeitstier" des Systems.
+
+* **Software:** `act_runner` (v0.2.11).
+* **Ressourcen:** 16 GiB RAM (optimiert für schwere Kotlin/JS-Builds).
+* **Build-Stack:** Java 25 (Temurin), Gradle 9.3.1.
+* **Besonderheiten:**
+* **Sequenzieller Build:** Um GitHub Rate-Limits und RAM-Spitzen zu vermeiden, arbeitet der Runner die Matrix-Jobs kontrolliert ab.
+* **Docker Buildx:** Native ARM64-Builds mit Optimierungs-Flags (`-XX:+UseTransparentHugePages`, `-XX:+UseSVE=1`).
+* **Der "Terser-Fix":** Für die Web-App wurde die Minifizierung deaktiviert, da das Terser-Plugin mit der `sqlite-wasm` Bibliothek kollidiert. Dies wird über die Datei `z_disable-minification.js` im Webpack-Ordner sichergestellt (das Präfix `z_` erzwingt die Ausführung als letzten Schritt).
+
+
+
+### 3. Meldestelle-Host (VM 110 / .50)
+
+Die Zielumgebung für das Deployment.
+
+* **Deployment-Methode:** Docker Compose mit Profilen (`infra`, `backend`, `gui`).
+* **Verzeichnis:** `~/meldestelle/`
+* **Service-Übersicht:**
+
+| Dienst | Externer Port | Interner Port | Image-Name (Registry) |
+| --- | --- | --- | --- |
+| **Web-App** | 4000 | 4000 (Caddy) | `web-app` |
+| **API-Gateway** | 8081 | 8081 | `api-gateway` |
+| **Keycloak** | 8180 (Admin) | 8080 | `keycloak` |
+| **Ping-Service** | 8082 | 8082 | `ping-service` |
+| **Consul** | 8500 | 8500 | `hashicorp/consul` |
+
+---
+
+## 🛠️ Der CI/CD Workflow
+
+Wenn ein Entwickler Code in den `main`-Branch pusht:
+
+1. **Trigger:** Gitea Actions erkennt den Push.
+2. **Build:** Der Runner (VM 102) baut die Services.
+* Das Frontend nutzt Kotlin/JS.
+* Das Backend nutzt Kotlin/JVM (Java 25).
+
+
+3. **Tagging:** Jedes Image erhält zwei Tags:
+* `:latest` (für den schnellen Pull).
+* `:sha-<long>` (für eindeutige Versionierung und Rollbacks).
+
+
+4. **Registry:** Die Images werden nach `git.mo-code.at` gepusht.
+5. **Deployment (Manuell/Host):** Auf der VM 110 wird via `docker compose pull` die neueste Version geladen.
+
+---
+
+## 📝 Wichtige Hinweise für Entwickler
+
+* **Frontend-Builds:** Lokal kann weiterhin mit `./gradlew jsBrowserDistribution` gearbeitet werden. Im Production-Build (`-Pproduction=true`) sorgt die Konfiguration im Ordner `webpack.config.d` dafür, dass der Runner nicht abstürzt.
+* **Docker-Registry:** Vor dem ersten Pull auf einem neuen System ist ein `docker login git.mo-code.at` zwingend erforderlich.
+* **Service-Discovery:** Die Dienste kommunizieren intern über das Docker-Netzwerk `meldestelle-network`. Namen wie `api-gateway`, `keycloak` oder `postgres` werden automatisch aufgelöst.

docs/README.md

@@ -6,15 +6,15 @@ Willkommen im "Gehirn" des Projekts. Dieses Verzeichnis ist die **Single Source
 
 ### 🏗️ Core
 *   **[`01_Architecture`](01_Architecture)**: Der Masterplan. ADRs, Roadmaps und C4-Modelle.
-    *   *Start hier:* `MASTER_ROADMAP_2026_Q1.md`
+    *   *Start hier:* [`MASTER_ROADMAP.md`](01_Architecture/MASTER_ROADMAP.md)
 *   **[`02_Guides`](02_Guides)**: Guides für neue Entwickler (Setup, Guidelines).
 *   **[`03_Domain`](03_Domain)**: Fachlichkeit (Turnierregeln, Entities).
 
 ### 🛠️ Tech Stack
 *   **[`05_Backend`](05_Backend)**: Spring Boot Services, API-Specs, DB-Schema.
-    *   *Referenz:* `05_Backend/Services/PingService_Reference.md`
 *   **[`06_Frontend`](06_Frontend)**: Kotlin Multiplatform, Compose UI, State Management.
-*   **[`07_Infrastructure`](07_Infrastructure)**: Docker, Keycloak, CI/CD.
+*   **[`07_Infrastructure`](07_Infrastructure)**: Docker, Keycloak, CI/CD, Zora-Architektur.
+    *   *Referenz:* [`Zora_System_Architektur.md`](07_Infrastructure/Zora_System_Architektur.md)
 
 ### 🤖 Process
 *   **[`04_Agents`](04_Agents)**: Playbooks für unsere KI-Mitarbeiter.
@@ -39,6 +39,6 @@ Willkommen im "Gehirn" des Projekts. Dieses Verzeichnis ist die **Single Source
 ---
 
 ## 🚀 Quick Links
-*   [Master Roadmap](01_Architecture/MASTER_ROADMAP_2026_Q1.md)
+*   [Master Roadmap](01_Architecture/MASTER_ROADMAP.md)
-*   [Ping Service Reference](05_Backend/Services/PingService_Reference.md)
 *   [Agent Playbooks](04_Agents)
+*   [Zora Infrastruktur](07_Infrastructure/Zora_System_Architektur.md)

docs/_archive/CloudFlare.md

@@ -23,5 +23,3 @@
 
  **johnny.ns.cloudflare.com**
  **roxy.ns.cloudflare.com**
-
-