chore(deps): update traefik:v3.7 docker digest to d685879

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.gitattributes

@@ -0,0 +1,6 @@
+*.sh text eol=lf
+*.ps1 text eol=crlf
+*.md text
+*.json text
+*.yml text
+*.yaml text

.gitignore

@@ -28,3 +28,5 @@ Thumbs.db
 *.tmp
 *.log
 .serena/
+.claude/settings.local.json
+memory/

CLAUDE.md

@@ -10,9 +10,10 @@ Claude muss vor jeder fachlichen oder technischen Aenderung mindestens diese Dat
 
 1. `HOMELAB_ARCHITECTURE_MASTER_V2.md`
 2. `docs/WORKFLOW.md`
-3. `docs/REPO_MAP.md`
+3. `docs/README.md`
-4. `docs/SERVICE_CATALOG.md`
+4. `docs/REPO_MAP.md`
-5. die betroffene `docker-compose.yml`
+5. `docs/SERVICE_CATALOG.md`
+6. die betroffene `docker-compose.yml`
 
 Zusaetzlich je nach Thema:
 
@@ -89,7 +90,7 @@ Wenn Drift vermutet wird, nicht raten. Erst die Pflichtmatrix in `docs/GITOPS_DR
 - `traefik`: Host-Ports 80/443
 - `gitea`: SSH-Port 222
 - `AdGuard Home`: DNS-Port 53 und LAN-Admin-Port 8082
-- `tailscale`: `network_mode: host`
+- `tailscale`: natives Unraid-Plugin (`tailscale.plg`, Interface `tailscale1`), Subnet-Router fuers LAN; nicht repo-/Komodo-verwaltet. Der frueher repo-verwaltete userspace-Docker-Stack `host-services/tailscale/` wurde am 2026-06-06 entfernt.
 - `Plex-Media-Server`: historischer Host-Netz-Sonderfall, nicht als Repo-Stack enthalten
 - `scrutiny`: `privileged: true` fuer SMART/Laufwerkszugriff
 - `Komodo`: Docker-Socket und native Auth ohne pauschale ForwardAuth

HOMELAB_ARCHITECTURE_MASTER_V2.md

@@ -3,7 +3,7 @@
 > **Single Source of Truth** für Docker-Netzwerkarchitektur, Sicherheitsregeln, Zielbild und Migration des Kallilabcore-Homelabs.
 > **Arbeitsregel für KI-Assistenten:** Dieses Dokument immer zuerst lesen, bevor Fragen zu Containern, Netzwerken, Traefik, Tailscale, Migration oder Security beantwortet werden.
 
-**Stand:** 2026-05-23 | **Aktueller Schwerpunkt:** GitOps / Doku-Synchronisierung / Reproduzierbare Deployments
+**Stand:** 2026-06-02 | **Aktueller Schwerpunkt:** GitOps / Doku-Synchronisierung / Reproduzierbare Deployments
 
 ---
 
@@ -145,6 +145,7 @@ Diese Dienste sind über echte `*.kaleschke.info`-Domains erreichbar:
 - `gitea` (Web) — git.kaleschke.info
 - `immich_server` — immich.kaleschke.info
 - `nextcloud` — cloud.kaleschke.info
+- `plex` — plex.kaleschke.info (Traefik, native Plex-Auth; Plex Remote Access/Port 32400 bleibt aus)
 
 ### 4.2 Nicht öffentlich / nur Tailscale oder Traefik + Middleware
 Diese Dienste sind **keine Public Apps**:
@@ -162,6 +163,8 @@ Diese Dienste sind **keine Public Apps**:
 - `bentopdf` — pdf.kaleschke.info (Middleware)
 - `monitoring-grafana` — monitoring.kaleschke.info (Middleware)
 - `hermes-dashboard` — hermes.kaleschke.info (Middleware)
+- `super-productivity` — sp.kaleschke.info (Middleware)
+- `n8n` — n8n.kaleschke.info (Traefik ohne pauschale Middleware, native Auth + Webhook-Ausnahme analog Komodo)
 - `Traefik-Dashboard`
 - `AdGuard Home` — Admin-UI auf Port 8082 (`80` im Container), kein Traefik, nur Tailscale-IP `100.80.98.33`; 2026-05-26 bewusst keine 2FA-/Traefik-Umstellung
 
@@ -238,7 +241,7 @@ Legende Status:
 | `AdGuard Home` | ✅ | `dns_net` (172.23.0.3), `frontend_net` | Port 53 DNS direkt, Port 8082 Admin nur auf Tailscale-IP `100.80.98.33` | DNS-Server + Upstream zu unbound; kein Traefik fuer Admin-UI | Admin-Port bleibt bewusst ohne Traefik/2FA, aber nicht mehr auf allen LAN-Interfaces |
 | `unbound` | ✅ | `dns_net` | intern | Upstream-Resolver für AdGuard, isoliert | — |
 | `ddns-updater` | ✅ | `frontend_net` | intern | Cloudflare DNS API; bleibt in `frontend_net` | Dokumentierte Ausnahme |
-| `tailscale` | ✅ | `host` | VPN-Zugang | Git-Stack (`host-services/tailscale/`) | nutzt `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` als dokumentierte VPN-Ausnahme |
+| `tailscale` | ✅ | `host` | VPN-Zugang / Subnet-Router | **Natives Unraid-Plugin** (`tailscale.plg`, Interface `tailscale1`, State `/boot/config/plugins/tailscale/state`) — **nicht** repo-/Komodo-verwaltet | Subnet-Router fuer `192.168.178.0/24`; der redundante userspace-Docker-Stack `host-services/tailscale/` wurde am 2026-06-06 entfernt |
 
 ### 7.2 Sicherheit / Identity
 
@@ -271,7 +274,9 @@ Legende Status:
 | `immich_server` | ✅ | `immich_default`, `frontend_net` | Traefik | aktiv via `immich.kaleschke.info` | — |
 | `immich_machine_learning` | ✅ | `immich_default` | intern | bleibt intern | — |
 | `nextcloud` | ✅ | `frontend_net`, `nextcloud_internal` | Traefik | aktiv via `cloud.kaleschke.info`, nativer Nextcloud-Login, WebDAV/CardDAV faehig | CalDAV/CardDAV-Redirect via Traefik-Labels |
-| `plex` | ✅ | `host` | Plex native, **LAN/Tailscale-only** (Remote Access aus seit 2026-05-28) | Compose-Stack unter `host-services/plex/`; Host-Netz bleibt fuer Discovery / Plex GDM dokumentierte Ausnahme; Server geclaimt von `Xeridos`; Smart-TVs (Schlafzimmer, Wohnzimmer) ueber WLAN-LAN per mDNS | — |
+| `plex` | ✅ | `host` | Traefik via `plex.kaleschke.info` + Plex native Auth; LAN direkt `:32400` | Compose-Stack unter `host-services/plex/`; Host-Netz bleibt fuer Discovery / Plex GDM dokumentierte Ausnahme; Traefik routet per File-Provider-Ausnahme auf `http://192.168.178.58:32400`, weil Docker-Labels Host-Netz-Container aus Traefik heraus auf `127.0.0.1` routen wuerden; kein direkter WAN-Port 32400 und Plex Remote Access bleibt aus; Server geclaimt von `Xeridos`; Smart-TVs (Schlafzimmer, Wohnzimmer) ueber WLAN-LAN per mDNS | — |
+| `super-productivity` | ✅ vorbereitet | `frontend_net` | Traefik + Middleware | Persoenliche Task-PWA des Operators; Issues kommen aus Gitea `Micha/mails` via n8n-Mail-Workflow | Deploy + Webhook + DNS-Eintrag offen |
+| `n8n` | ✅ vorbereitet | `frontend_net` | Traefik, native Auth (keine pauschale Authelia) | Workflow-Automation; erster Workflow: GMX-Mail -> OpenAI-Extraktion -> Gitea-Issue in `Micha/mails`; `N8N_ENCRYPTION_KEY` ist Stack-ENV-Pflichtsecret | Deploy + Webhook + Owner-Setup offen |
 
 ### 7.5 Admin / Operations
 
@@ -304,7 +309,7 @@ Legende Status:
 
 | Container | Status | Ziel |
 |---|---|---|
-| — | — | Plex ist nicht mehr offen: der Dienst ist als Repo-Compose-Stack unter `host-services/plex/` dokumentiert; `host`-Netz bleibt als Discovery-Ausnahme. |
+| — | — | Plex ist nicht mehr direkt offen: der Dienst ist als Repo-Compose-Stack unter `host-services/plex/` dokumentiert; `host`-Netz bleibt als Discovery-Ausnahme. Externer Zugriff laeuft ausschliesslich ueber Traefik/443 auf `plex.kaleschke.info`; keine direkte 32400-WAN-Freigabe. Technisch nutzt Plex als einzige Host-Netz-Route `traefik/dynamic/plex.yml`, weil Docker-Labels fuer `network_mode: host` in Traefik auf `127.0.0.1:32400` zeigen. |
 
 ### 7.8 Entfernte Container
 
@@ -402,6 +407,8 @@ Für den laufenden Betrieb gilt stattdessen:
 | `nextcloud` | keine zentrale ForwardAuth-Middleware | Nextcloud bringt eigene Auth, Clients und WebDAV/CardDAV-Endpunkte mit; Traefik bleibt Reverse Proxy, Auth bleibt app-nativ |
 | `monitoring-influxdb3-core` | Host-Port 8181 auf LAN-IP; `user: "0"` | Home Assistant laeuft in einer VM ausserhalb des Compose-Netzes und muss Metriken schreiben koennen; keine Traefik-Route, kein `frontend_net`, Zugriff nur ueber Token und LAN-IP `INFLUXDB_BIND_IP`; InfluxDB 3 Core benoetigt im aktuellen Container-Setup Root-Rechte fuer den lokalen Object-Store-Pfad im named volume |
 | `monitoring-promtail` | Docker-Socket read-only | Docker-Log-Discovery fuer Loki; keine Schreibrechte, keine Appdaten-Persistenz ueber den Socket |
+| `n8n` | keine pauschale Authelia-Middleware | Webhook-Endpunkte (`/webhook/*`, `/webhook-test/*`) muessen ohne ForwardAuth erreichbar bleiben; n8n bringt eigene Owner-/Login-Auth mit (analog Komodo/Nextcloud) |
+| `plex` | Traefik ohne Authelia, File-Provider-Ausnahme trotz Host-Netz | Plex bringt native Konto-/Client-Auth mit; vorgeschaltete ForwardAuth wuerde Plex Web, Apps und Client-Flows stoeren. Docker-Labels sind fuer diesen Host-Netz-Container ungeeignet, weil Traefik sonst `127.0.0.1:32400` nutzt; daher `traefik/dynamic/plex.yml` mit Ziel `192.168.178.58:32400`. Route nur ueber Traefik/443 (`plex.kaleschke.info`), direkter Plex-WAN-Port 32400 und Plex Remote Access bleiben deaktiviert. |
 
 ---
 
@@ -459,6 +466,22 @@ Damit ist sofort klar:
 
 ## 13. Betriebserfahrungen und Entscheidungs-Log
 
+### Fix Common Problems Plugin entfernt (2026-06-03)
+
+Befund: Drei `grep -R ... /usr/local/emhttp`-Prozesse liefen seit ~7 Tagen durchgehend mit je 100 % CPU (TIME+ 177-179 h). Status `R`, von PID 1 adoptierte Zombies einer laengst beendeten Fix-Common-Problems-(FCP)-Scan-Session. Folge: konstante Load 14.6 auf 12 Cores, IOWAIT-Peaks bis 55 %, USB-Flash unter Dauer-IO.
+
+Ursache: Unraids `/usr/local/emhttp` enthaelt Symlinks `mnt -> /mnt` (mehrere TB Array) und `boot -> /boot` (USB-Flash). GNU `grep -R` dereferenziert Symlinks rekursiv. Ein FCP-Scan-Schritt (`/etc/cron.daily/fix.common.problems.sh -> scripts/scan.php`) hat dadurch effektiv die gesamte Array-Struktur gegrept und ist beim ersten Treffer-Loop haengen geblieben. Der Lock `/tmp/fix.common.problems/scanRunning` war vom 2026-06-03 04:40 - jeder weitere Daily-Cron-Run wuerde dasselbe Verhalten reproduzieren.
+
+Massnahme: FCP-Plugin per `plugin remove fix.common.problems.plg` deinstalliert. Cron-Eintrag, Plugin-Verzeichnis und `/tmp`-Reste sauber. Load fiel innerhalb Minuten auf 1.08 (1-min).
+
+Entscheidung: FCP wird bewusst **nicht** wieder installiert. Begruendung:
+
+- Restliche Risiken werden bereits ueber andere Wege abgedeckt: Scrutiny (Laufwerks-SMART), Monitoring-Stack (Container-Health, Prometheus-Alerts, Blackbox), Posture-Check (Filesystem-/Drift-/Authelia-Audit), Critical-Events-Watcher (`services/posture-check/docker-critical-events.sh`).
+- FCP ist ein externes Community-Plugin und nicht Teil der Repo-managed GitOps-Welt; Verhalten haengt von einer Online-Templates-Datei ab.
+- Ein einmaliges Hang-up reicht, um die Flash-Drive 7 Tage lang zu thrashen - das Verhaeltnis Nutzen/Risiko ist negativ.
+
+Folgen fuer Doku: Eintrag in `docs/AUDIT_2026-05-25_TODO.md` unter "Zuletzt geschlossen"; FCP taucht nicht mehr als Voraussetzung in DR/Monitoring-Pfaden auf, da es nie produktiv referenziert war.
+
 ### Plex Server Reclaim und LAN-only-Profil (2026-05-28)
 
 Befund: Die `Preferences.xml` des Plex-Servers war seit dem 18.05.2026 13:18 jungfraeulich (391 Bytes, ohne `PlexOnlineMail`/`PlexOnlineUsername`/`PlexOnlineToken`). Der Server war damit nicht mit einem Plex.tv-Account geclaimt, obwohl die Smart-TVs ueber LAN-Discovery (mDNS/Plex-GDM) weiter funktionierten. Beim Login als `Xeridos` ueber `app.plex.tv` meldete der Server "Keine Berechtigung", weil kein Owner registriert war. Zusaetzlich war die `library_sections`-Konfiguration leer (Backups vom 19./22./28.05. ebenfalls ~370 KB statt MBs/GBs); die Bibliotheks-Konfiguration war seit dem 18.05. weg, die Filmdateien unter `/mnt/user/media/*` blieben aber intakt (~833 Verzeichnisse, davon `movies/` 1.4 TB und `Heimatfilme/` 300 GB).
@@ -474,7 +497,8 @@ Endstand:
 
 - `PlexOnlineUsername="Xeridos"`, `PlexOnlineMail="michideheld@gmx.de"`, `PlexOnlineHome="1"`.
 - Bibliotheken neu angelegt via Plex-Web → Verwalte Mediatheken → `/data/movies`, `/data/Heimatfilme` etc.
-- `PublishServerOnPlexOnlineKey="0"` (Remote Access deaktiviert), Plex-Relay aus → Plex bleibt strikt LAN/Tailscale-only, konsistent zum Tailscale-First-Operator-Modell.
+- `PublishServerOnPlexOnlineKey="0"` (Remote Access deaktiviert), Plex-Relay aus.
+- 2026-06-06: Externer Komfortzugriff ueber `https://plex.kaleschke.info` via Traefik ergaenzt. Das ist **kein** Plex-Remote-Access und keine direkte FRITZ!Box-Freigabe auf `32400`; Plex bleibt hinter Traefik/443 und nutzt native Plex-Auth.
 
 Konsequenzen fuer Doku/Betrieb:
 

README.md

@@ -8,19 +8,20 @@ Vor jeder Aenderung lesen:
 
 1. `HOMELAB_ARCHITECTURE_MASTER_V2.md`
 2. `docs/WORKFLOW.md`
+3. `docs/README.md`
 
 Bei Restore-, Host-Ausfall- oder Wiederanlauf-Fragen zusaetzlich:
 
-3. `docs/DISASTER_RECOVERY.md`
+4. `docs/DISASTER_RECOVERY.md`
-4. `docs/RESTORE_MATRIX.md`
+5. `docs/RESTORE_MATRIX.md`
-5. `docs/SERVICES_RECOVERY.md`
+6. `docs/SERVICES_RECOVERY.md`
 
 Bei Hardware-, Netzwerk-, Provider- oder Kapazitaetsfragen zusaetzlich:
 
-6. `docs/HARDWARE_INVENTORY.md`
+7. `docs/HARDWARE_INVENTORY.md`
-7. `docs/NETWORK_INVENTORY.md`
+8. `docs/NETWORK_INVENTORY.md`
-8. `docs/EXTERNAL_DEPENDENCIES.md`
+9. `docs/EXTERNAL_DEPENDENCIES.md`
-9. `docs/CAPACITY_AND_LIFECYCLE.md`
+10. `docs/CAPACITY_AND_LIFECYCLE.md`
 
 ## Architektur
 
@@ -75,4 +76,5 @@ Bei Hardware-, Netzwerk-, Provider- oder Kapazitaetsfragen zusaetzlich:
 - Recovery-kritische Services-Pfade wie Gitea-Repositories, Komodo-Workspaces und Host-Automation sind in `docs/SERVICES_RECOVERY.md` beschrieben.
 - Hardware-, Netzwerk-, Provider- und Capacity-Inventare sind als operative Audit-Dokumente unter `docs/HARDWARE_INVENTORY.md`, `docs/NETWORK_INVENTORY.md`, `docs/EXTERNAL_DEPENDENCIES.md` und `docs/CAPACITY_AND_LIFECYCLE.md` vorbereitet.
 - Der verbindliche Detailablauf steht in `docs/WORKFLOW.md`.
+- Der Doku-Index mit aktiven und archivierten Dokumenten steht in `docs/README.md`.
 - `nextcloud`, `bentopdf` und `monitoring` folgen dem dokumentierten Netz-/Secret-/Traefik-Modell; der zentrale Monitoring-Stack buendelt Prometheus, Loki, Promtail, Grafana und InfluxDB 3 Core.

apps/bentopdf/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   bentopdf:
-    image: bentopdfteam/bentopdf:2.8.4@sha256:f54b9ed9c56b767e0098b525468206689b666323c2b500b9686c3cf41cdfa348
+    image: bentopdfteam/bentopdf:2.8.5@sha256:2d867aacb8ab5b196d00ee86944b1899d09d72df355384c5e15cf974737963a0
     container_name: bentopdf
     restart: unless-stopped
     tmpfs:

apps/immich/docker-compose.yml

@@ -34,6 +34,17 @@ services:
     container_name: immich_machine_learning
     image: ghcr.io/immich-app/immich-machine-learning:release@sha256:a2501141440f10516d329fdfba2c68082e19eb9ba6016c061ac80d23beadf7f3
     restart: unless-stopped
+    environment:
+      # Workaround fuer gunicorn-25.1.0-Control-Socket-Bug: der Worker haengt
+      # nach "Control socket listening at /usr/src/gunicorn.ctl" und erreicht
+      # nie "Application startup complete" -> Container bleibt dauerhaft
+      # unhealthy, ML (Gesichtserkennung/CLIP/Smart-Search) ist tot.
+      # --no-control-socket deaktiviert das fehlerhafte Feature. immich-ml
+      # startet gunicorn als Subprozess, der GUNICORN_CMD_ARGS aus der Env
+      # liest und anhaengt. Bestaetigte Upstream-Regression seit Immich 2.6
+      # (immich#27228, gunicorn#3510). Re-check: bei Immich-Update, das
+      # gunicorn auf >25.1.0/<25.1.0 mit Fix bringt, wieder entfernen.
+      GUNICORN_CMD_ARGS: "--no-control-socket"
     volumes:
       - model-cache:/cache
     networks:
@@ -43,7 +54,7 @@ services:
 
   redis:
     container_name: immich_redis
-    image: redis:7.4-alpine@sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99
+    image: redis:8.8.0-alpine@sha256:09160599abd229764c0fb44cb6be640294e1d360a54b19985ab4843dcf2d90f1
     restart: unless-stopped
     networks:
       - immich_default
@@ -52,14 +63,15 @@ services:
 
   database:
     container_name: immich_postgres
-    image: tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:739cdd626151ff1f796dc95a6591b55a714f341c737e27f045019ceabf8e8c52
+    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
     restart: unless-stopped
     environment:
       POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
       POSTGRES_USER: immich
       POSTGRES_DB: immich
+    shm_size: 128mb
     volumes:
-      - /mnt/user/appdata/immich_postgres:/var/lib/postgresql/data
+      - /mnt/user/appdata/immich_postgres_vectorchord:/var/lib/postgresql/data
       - /mnt/user/appdata/secrets/immich_postgres_password.txt:/run/secrets/postgres_password:ro
     networks:
       - immich_default

apps/mail-archiver/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   mail-archiver:
-    image: s1t5/mailarchiver@sha256:94d7525db56b13154a14203f8fb7b53fac034f28a914c32da9d2e426b49328ed
+    image: s1t5/mailarchiver@sha256:4ea7ecc47ad1dd2c523b85c3967574b61e39def1b6fd26edf874e21733c4018c
     container_name: mail-archiver
     restart: unless-stopped
     environment:

apps/mealie/docker-compose.yml

@@ -1,9 +1,15 @@
 services:
   mealie:
-    image: ghcr.io/mealie-recipes/mealie:v3.12.0@sha256:8d962f611390a1cca667eed32a29e9467e9c01c523e2db3ad00f667372067f9d
+    image: ghcr.io/mealie-recipes/mealie:v3.19.2@sha256:f68e959bf66f4f458893ea58facac71690fe6f2ac7a31466b5cecb41b4e99c02
     container_name: mealie
     restart: unless-stopped
 
+    # OIDC: Authelia ueber Host-LAN-IP -> Traefik erreichbar (Container-DNS loest
+    # auth.kaleschke.info sonst nicht; gleiches Muster wie Komodo. SNI bleibt der
+    # Hostname, Let's-Encrypt-Cert validiert weiter.
+    extra_hosts:
+      - "auth.kaleschke.info:192.168.178.58"
+
     environment:
       TZ: Europe/Berlin
       ALLOW_SIGNUP: "false"
@@ -18,6 +24,16 @@ services:
 
       BASE_URL: https://mealie.kaleschke.info
 
+      # --- Authelia OIDC SSO (additiv, 2026-06-06; lokaler Login bleibt) ---
+      OIDC_AUTH_ENABLED: "true"
+      OIDC_PROVIDER_NAME: Authelia
+      OIDC_CONFIGURATION_URL: https://auth.kaleschke.info/.well-known/openid-configuration
+      OIDC_CLIENT_ID: mealie
+      OIDC_CLIENT_SECRET: ${MEALIE_OIDC_CLIENT_SECRET}
+      OIDC_SIGNUP_ENABLED: "true"
+      OIDC_AUTO_REDIRECT: "false"
+      OIDC_REMEMBER_ME: "true"
+
     volumes:
       - /mnt/user/appdata/mealie/data:/app/data
 
@@ -38,7 +54,7 @@ services:
       - traefik.http.services.mealie.loadbalancer.server.port=9000
 
   mealie-postgres:
-    image: postgres:17.9@sha256:5b96f1a16bd9768b060dd2ffe55cb6225c4d9ef4d214a8b21eb08134869a97e4
+    image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
     container_name: mealie-postgres
     restart: unless-stopped
 
@@ -47,10 +63,10 @@ services:
       POSTGRES_USER: mealie
       POSTGRES_DB: mealie
       POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
-      PGDATA: /var/lib/postgresql/data
+      PGDATA: /var/lib/postgresql/18/docker
 
     volumes:
-      - /mnt/user/appdata/mealie/postgres:/var/lib/postgresql/data
+      - /mnt/user/appdata/mealie/postgres18:/var/lib/postgresql
       - /mnt/user/appdata/secrets/mealie_postgres_password.txt:/run/secrets/postgres_password:ro
 
     networks:

apps/n8n/docker-compose.yml

@@ -0,0 +1,51 @@
+services:
+  n8n:
+    image: docker.n8n.io/n8nio/n8n:2.26.2@sha256:61ba01bc5e39304bbc928c9dbecd938c3a5cc1331b68affba6a34d0f654c43d9
+    container_name: n8n
+    restart: unless-stopped
+
+    security_opt:
+      - no-new-privileges:true
+
+    dns:
+      - 1.1.1.1
+      - 8.8.8.8
+
+    environment:
+      TZ: Europe/Berlin
+      GENERIC_TIMEZONE: Europe/Berlin
+
+      N8N_HOST: n8n.kaleschke.info
+      N8N_PORT: "5678"
+      N8N_PROTOCOL: https
+      N8N_EDITOR_BASE_URL: https://n8n.kaleschke.info/
+      WEBHOOK_URL: https://n8n.kaleschke.info/
+      N8N_PROXY_HOPS: "1"
+
+      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
+
+      N8N_DIAGNOSTICS_ENABLED: "false"
+      N8N_PERSONALIZATION_ENABLED: "false"
+      N8N_HIRING_BANNER_ENABLED: "false"
+      N8N_RUNNERS_ENABLED: "true"
+      N8N_BLOCK_ENV_ACCESS_IN_NODE: "true"
+
+    volumes:
+      - /mnt/user/appdata/n8n/data:/home/node/.n8n
+
+    networks:
+      - frontend_net
+
+    labels:
+      - "traefik.enable=true"
+      - "traefik.docker.network=frontend_net"
+      - "traefik.http.routers.n8n.rule=Host(`n8n.kaleschke.info`)"
+      - "traefik.http.routers.n8n.entrypoints=websecure"
+      - "traefik.http.routers.n8n.tls=true"
+      - "traefik.http.routers.n8n.tls.certresolver=le"
+      - "traefik.http.routers.n8n.middlewares=secure-headers@file"
+      - "traefik.http.services.n8n.loadbalancer.server.port=5678"
+
+networks:
+  frontend_net:
+    external: true

apps/n8n/workflows/mail-to-gitea-issue.json

@@ -0,0 +1,284 @@
+{
+  "name": "GMX -> OpenAI -> Gitea Issue (Super Productivity)",
+  "nodes": [
+    {
+      "parameters": {
+        "pollTimes": {
+          "item": [
+            {
+              "mode": "everyMinute"
+            }
+          ]
+        },
+        "format": "simple",
+        "options": {
+          "customEmailConfig": "[\"UNSEEN\"]",
+          "forceReconnect": 15
+        },
+        "postProcessAction": "read"
+      },
+      "id": "11111111-1111-1111-1111-111111111111",
+      "name": "IMAP: GMX UNSEEN",
+      "type": "n8n-nodes-base.emailReadImap",
+      "typeVersion": 2,
+      "position": [
+        240,
+        300
+      ],
+      "credentials": {
+        "imap": {
+          "id": "REPLACE_GMX_IMAP_CRED_ID",
+          "name": "GMX IMAP"
+        }
+      }
+    },
+    {
+      "parameters": {
+        "assignments": {
+          "assignments": [
+            {
+              "id": "a1",
+              "name": "from",
+              "value": "={{ $json.from }}",
+              "type": "string"
+            },
+            {
+              "id": "a2",
+              "name": "subject",
+              "value": "={{ $json.subject }}",
+              "type": "string"
+            },
+            {
+              "id": "a3",
+              "name": "date",
+              "value": "={{ $json.date }}",
+              "type": "string"
+            },
+            {
+              "id": "a4",
+              "name": "messageId",
+              "value": "={{ $json.messageId || $json['message-id'] || '' }}",
+              "type": "string"
+            },
+            {
+              "id": "a5",
+              "name": "text",
+              "value": "={{ ($json.text || $json.textPlain || '').toString().slice(0, 8000) }}",
+              "type": "string"
+            }
+          ]
+        },
+        "options": {}
+      },
+      "id": "22222222-2222-2222-2222-222222222222",
+      "name": "Extract mail fields",
+      "type": "n8n-nodes-base.set",
+      "typeVersion": 3.4,
+      "position": [
+        460,
+        300
+      ]
+    },
+    {
+      "parameters": {
+        "method": "POST",
+        "url": "https://api.openai.com/v1/chat/completions",
+        "authentication": "genericCredentialType",
+        "genericAuthType": "httpHeaderAuth",
+        "sendHeaders": true,
+        "headerParameters": {
+          "parameters": [
+            {
+              "name": "Content-Type",
+              "value": "application/json"
+            }
+          ]
+        },
+        "sendBody": true,
+        "specifyBody": "json",
+        "jsonBody": "={\n  \"model\": \"gpt-4o-mini\",\n  \"temperature\": 0.2,\n  \"response_format\": {\n    \"type\": \"json_schema\",\n    \"json_schema\": {\n      \"name\": \"issue_extraction\",\n      \"strict\": true,\n      \"schema\": {\n        \"type\": \"object\",\n        \"additionalProperties\": false,\n        \"required\": [\"title\", \"body_md\", \"priority\", \"due_date\", \"category\"],\n        \"properties\": {\n          \"title\":    { \"type\": \"string\", \"maxLength\": 80 },\n          \"body_md\":  { \"type\": \"string\" },\n          \"priority\": { \"type\": \"string\", \"enum\": [\"niedrig\", \"normal\", \"hoch\"] },\n          \"due_date\": { \"type\": [\"string\", \"null\"], \"description\": \"ISO YYYY-MM-DD oder null\" },\n          \"category\": { \"type\": \"string\" }\n        }\n      }\n    }\n  },\n  \"messages\": [\n    {\n      \"role\": \"system\",\n      \"content\": \"Du extrahierst aus einer E-Mail eine Aufgabe fuer ein Issue-Tracking-System. Antworte ausschliesslich gemaess JSON-Schema. Sprache: Deutsch.\\n- title: imperativ, max. 80 Zeichen, ohne abschliessenden Punkt.\\n- body_md: 2 bis 6 Saetze. Was ist zu tun, warum, bis wann. Keine Begruessungen.\\n- priority: niedrig | normal | hoch.\\n- due_date: ISO YYYY-MM-DD wenn aus Mail ableitbar, sonst null.\\n- category: kurzes Schlagwort (rechnung, termin, technik, familie, sonstiges, ...).\"\n    },\n    {\n      \"role\": \"user\",\n      \"content\": {{ JSON.stringify('Absender: ' + $json.from + '\\nDatum: ' + $json.date + '\\nBetreff: ' + $json.subject + '\\n\\nMailtext:\\n' + $json.text) }}\n    }\n  ]\n}",
+        "options": {
+          "timeout": 60000
+        }
+      },
+      "id": "33333333-3333-3333-3333-333333333333",
+      "name": "OpenAI: extract issue",
+      "type": "n8n-nodes-base.httpRequest",
+      "typeVersion": 4.2,
+      "position": [
+        680,
+        300
+      ],
+      "credentials": {
+        "httpHeaderAuth": {
+          "id": "REPLACE_OPENAI_HEADER_AUTH_CRED_ID",
+          "name": "OpenAI Bearer"
+        }
+      }
+    },
+    {
+      "parameters": {
+        "assignments": {
+          "assignments": [
+            {
+              "id": "b1",
+              "name": "extracted",
+              "value": "={{ JSON.parse($json.choices[0].message.content) }}",
+              "type": "object"
+            },
+            {
+              "id": "b2",
+              "name": "mail",
+              "value": "={{ $('Extract mail fields').item.json }}",
+              "type": "object"
+            }
+          ]
+        },
+        "options": {}
+      },
+      "id": "44444444-4444-4444-4444-444444444444",
+      "name": "Parse OpenAI JSON",
+      "type": "n8n-nodes-base.set",
+      "typeVersion": 3.4,
+      "position": [
+        900,
+        300
+      ]
+    },
+    {
+      "parameters": {
+        "assignments": {
+          "assignments": [
+            {
+              "id": "c1",
+              "name": "title",
+              "value": "={{ ($json.extracted.priority === 'hoch' ? '[P1] ' : '') + $json.extracted.title }}",
+              "type": "string"
+            },
+            {
+              "id": "c2",
+              "name": "body",
+              "value": "={{ $json.extracted.body_md + '\\n\\n---\\n**Kategorie:** ' + $json.extracted.category + '\\n**Prioritaet:** ' + $json.extracted.priority + ($json.extracted.due_date ? '\\n**Faellig:** ' + $json.extracted.due_date : '') + '\\n**Quelle:** Mail von ' + $json.mail.from + ' (' + $json.mail.date + ')\\n**Betreff:** ' + $json.mail.subject + '\\n**Message-ID:** ' + $json.mail.messageId }}",
+              "type": "string"
+            }
+          ]
+        },
+        "options": {}
+      },
+      "id": "55555555-5555-5555-5555-555555555555",
+      "name": "Build issue payload",
+      "type": "n8n-nodes-base.set",
+      "typeVersion": 3.4,
+      "position": [
+        1120,
+        300
+      ]
+    },
+    {
+      "parameters": {
+        "method": "POST",
+        "url": "https://git.kaleschke.info/api/v1/repos/Micha/mails/issues",
+        "authentication": "genericCredentialType",
+        "genericAuthType": "httpHeaderAuth",
+        "sendHeaders": true,
+        "headerParameters": {
+          "parameters": [
+            {
+              "name": "Content-Type",
+              "value": "application/json"
+            },
+            {
+              "name": "Accept",
+              "value": "application/json"
+            }
+          ]
+        },
+        "sendBody": true,
+        "specifyBody": "json",
+        "jsonBody": "={\n  \"title\": {{ JSON.stringify($json.title) }},\n  \"body\": {{ JSON.stringify($json.body) }},\n  \"assignees\": [\"Micha\"]\n}",
+        "options": {
+          "timeout": 30000
+        }
+      },
+      "id": "66666666-6666-6666-6666-666666666666",
+      "name": "Gitea: create issue",
+      "type": "n8n-nodes-base.httpRequest",
+      "typeVersion": 4.2,
+      "position": [
+        1340,
+        300
+      ],
+      "credentials": {
+        "httpHeaderAuth": {
+          "id": "REPLACE_GITEA_HEADER_AUTH_CRED_ID",
+          "name": "Gitea Token"
+        }
+      }
+    }
+  ],
+  "connections": {
+    "IMAP: GMX UNSEEN": {
+      "main": [
+        [
+          {
+            "node": "Extract mail fields",
+            "type": "main",
+            "index": 0
+          }
+        ]
+      ]
+    },
+    "Extract mail fields": {
+      "main": [
+        [
+          {
+            "node": "OpenAI: extract issue",
+            "type": "main",
+            "index": 0
+          }
+        ]
+      ]
+    },
+    "OpenAI: extract issue": {
+      "main": [
+        [
+          {
+            "node": "Parse OpenAI JSON",
+            "type": "main",
+            "index": 0
+          }
+        ]
+      ]
+    },
+    "Parse OpenAI JSON": {
+      "main": [
+        [
+          {
+            "node": "Build issue payload",
+            "type": "main",
+            "index": 0
+          }
+        ]
+      ]
+    },
+    "Build issue payload": {
+      "main": [
+        [
+          {
+            "node": "Gitea: create issue",
+            "type": "main",
+            "index": 0
+          }
+        ]
+      ]
+    }
+  },
+  "active": false,
+  "settings": {
+    "executionOrder": "v1"
+  },
+  "meta": {
+    "instanceId": "homelab-n8n"
+  },
+  "tags": []
+}

apps/nextcloud/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   nextcloud:
-    image: nextcloud:33.0.2-apache@sha256:39b2ba219271a22851f8409a7b1295d5892aba1696d9193500311c02e60591a4
+    image: nextcloud:33.0.5-apache@sha256:56bdc45109067500fd0832fa64832b7c77a167d9394cbf5f0f4b59740b94194d
     container_name: nextcloud
     restart: unless-stopped
     depends_on:
@@ -46,7 +46,7 @@ services:
       - "traefik.http.services.nextcloud.loadbalancer.server.port=80"
 
   nextcloud-postgres:
-    image: postgres:17.9@sha256:5b96f1a16bd9768b060dd2ffe55cb6225c4d9ef4d214a8b21eb08134869a97e4
+    image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
     container_name: nextcloud-postgres
     restart: unless-stopped
     environment:
@@ -54,9 +54,9 @@ services:
       POSTGRES_DB: nextcloud
       POSTGRES_USER: nextcloud
       POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
-      PGDATA: /var/lib/postgresql/data
+      PGDATA: /var/lib/postgresql/18/docker
     volumes:
-      - /mnt/user/appdata/nextcloud/postgres:/var/lib/postgresql/data
+      - /mnt/user/appdata/nextcloud/postgres18:/var/lib/postgresql
       - /mnt/user/appdata/secrets/nextcloud_postgres_password.txt:/run/secrets/postgres_password:ro
     networks:
       - nextcloud_internal
@@ -64,7 +64,7 @@ services:
       - no-new-privileges:true
 
   nextcloud-redis:
-    image: redis:7.4-alpine@sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99
+    image: redis:8.8.0-alpine@sha256:09160599abd229764c0fb44cb6be640294e1d360a54b19985ab4843dcf2d90f1
     container_name: nextcloud-redis
     restart: unless-stopped
     command: redis-server --save 60 1 --loglevel warning

apps/ntfy/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   ntfy:
-    image: binwiederhier/ntfy@sha256:2b9e12d56a538f4402da51328eeca02696c4b207ab7fbe031c27e51a22ca9b86
+    image: binwiederhier/ntfy@sha256:f8a9b104313b87cc24ae4f775f39e6328205b57dff6ede3eaf098a91e5d79f59
     container_name: ntfy
     restart: unless-stopped
     dns:                       

apps/paperless-gpt/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   paperless-gpt:
-    image: icereed/paperless-gpt:v0.24.0@sha256:15bad5d455b98f21bb7b5d6615f56871ff67a8bb379dc0dd7ba411f4633071a6
+    image: icereed/paperless-gpt:v0.25.1@sha256:c0ce6186028911101a2cfe68353f14a9dbb2653596f3f1cff94de4b6db3114ff
     container_name: paperless-gpt
     restart: unless-stopped
     security_opt:
@@ -15,15 +15,18 @@ services:
       PAPERLESS_API_TOKEN: "${PAPERLESS_API_TOKEN}"
       MANUAL_TAG: "paperless-gpt"
       AUTO_TAG: "paperless-gpt-auto"
-      LLM_PROVIDER: "ollama"
+      LLM_PROVIDER: "openai"
-      LLM_MODEL: "qwen3:8b"
+      LLM_MODEL: "gpt-5.4-mini"
-      OLLAMA_HOST: "http://192.168.178.103:11434"
+      OPENAI_API_KEY: "${OPENAI_API_KEY}"
-      OLLAMA_CONTEXT_LENGTH: "4096"
+      OPENAI_BASE_URL: "https://api.openai.com/v1"
-      TOKEN_LIMIT: "1500"
+      TOKEN_LIMIT: "12000"
+      LLM_REQUESTS_PER_MINUTE: "30"
       LLM_LANGUAGE: "German"
       OCR_PROVIDER: "llm"
-      VISION_LLM_PROVIDER: "ollama"
+      VISION_LLM_PROVIDER: "openai"
-      VISION_LLM_MODEL: "minicpm-v:latest"
+      VISION_LLM_MODEL: "gpt-5.4-mini"
+      VISION_LLM_TEMPERATURE: "1.0"
+      VISION_LLM_REQUESTS_PER_MINUTE: "20"
       OCR_PROCESS_MODE: "image"
       CREATE_NEW_TAGS: "true"
       AUTO_GENERATE_TITLE: "true"

apps/paperless/docker-compose.yml

@@ -1,8 +1,11 @@
 services:
   paperless:
-    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.10@sha256:07a0b4ba01ce377c82a0636e16c0c3d931fde5b7e9304de6601986cc42d9b6e6
+    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.15@sha256:6c86cad803970ea782683a8e80e7403444c5bf3cf70de63b4d3c8e87500db92f
     container_name: paperless-ngx
     restart: unless-stopped
+    # OIDC: Authelia ueber Host-LAN-IP -> Traefik erreichbar (Container-DNS sonst nicht)
+    extra_hosts:
+      - "auth.kaleschke.info:192.168.178.58"
     security_opt:
       - no-new-privileges:true
     environment:
@@ -17,6 +20,11 @@ services:
       - PAPERLESS_OCR_LANGUAGE=deu+eng
       - PAPERLESS_URL=https://paperless.kaleschke.info
 
+      # --- Authelia OIDC SSO (additiv, 2026-06-06; lokaler Login bleibt) ---
+      - PAPERLESS_APPS=allauth.socialaccount.providers.openid_connect
+      - PAPERLESS_SOCIAL_AUTO_SIGNUP=true
+      - 'PAPERLESS_SOCIALACCOUNT_PROVIDERS={"openid_connect":{"OAUTH_PKCE_ENABLED":true,"APPS":[{"provider_id":"authelia","name":"Authelia","client_id":"paperless","secret":"${PAPERLESS_OIDC_SECRET}","settings":{"server_url":"https://auth.kaleschke.info"}}]}}'
+
       # Barcode / ASN
       - PAPERLESS_CONSUMER_ENABLE_BARCODES=1
       - PAPERLESS_CONSUMER_ENABLE_ASN_BARCODE=1

apps/super-productivity/docker-compose.yml

@@ -0,0 +1,25 @@
+services:
+  super-productivity:
+    image: johannesjo/super-productivity:v18.9.1@sha256:773760107344e739f4c29409f7842db66a1b167d50eb2c40248cb5b5b328652e
+    container_name: super-productivity
+    restart: unless-stopped
+
+    security_opt:
+      - no-new-privileges:true
+
+    networks:
+      - frontend_net
+
+    labels:
+      - "traefik.enable=true"
+      - "traefik.docker.network=frontend_net"
+      - "traefik.http.routers.super-productivity.rule=Host(`sp.kaleschke.info`)"
+      - "traefik.http.routers.super-productivity.entrypoints=websecure"
+      - "traefik.http.routers.super-productivity.tls=true"
+      - "traefik.http.routers.super-productivity.tls.certresolver=le"
+      - "traefik.http.routers.super-productivity.middlewares=authelia@file,secure-headers@file"
+      - "traefik.http.services.super-productivity.loadbalancer.server.port=80"
+
+networks:
+  frontend_net:
+    external: true

apps/unbound/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   unbound:
-    image: shaanmajid/unbound:1.24.2@sha256:d278b71c592b2555cc802911bb0757a6a24f4a8ad7f5848720296c04876eeb63
+    image: shaanmajid/unbound:1.25.1@sha256:f140db02a005904802bf5840093e95e675321aa060a00426fdffc2a3ac2eeb6b
     container_name: unbound
     restart: unless-stopped
     volumes:

audit/raw/01_volumes_partitions.txt

@@ -0,0 +1,22 @@
+### VOLUMES ###
+DriveLetter  Label            FS    Size_GB   Free_GB  Health
+C            (kein Label)     NTFS  166.9     59.5     Healthy
+D            Daten-Projekte   NTFS  167.7     148.6    Healthy
+E            Games            NTFS  930.6     714.9    Healthy
+G            M2 SSD           NTFS  930.9     877.5    Healthy
+H            Externe HDD      NTFS  7452.0    3801.3   Healthy
+(kein BW)    Recovery x5      NTFS  diverse   diverse  Healthy
+
+### DISKS ###
+Disk 0  INTEL SSDSC2BW180A3L  SATA  167.68 GB  GPT  Healthy  Serial: CVCV3105053K180EGN
+Disk 1  INTEL SSDSC2BW180A3L  SATA  167.68 GB  GPT  Healthy  Serial: CVCV311302TH180EGN
+Disk 2  Samsung SSD 980 PRO 1TB  NVMe  931.51 GB  GPT  Healthy
+Disk 3  WDC WDS100T2B0C        NVMe  931.51 GB  GPT  Healthy
+Disk 4  asmedia ASM235         USB   7.28 TB    GPT  Healthy
+
+### PARTITIONS ###
+Disk 0: [Reserved 16MB] [C: 166.87 GB Basic] [Recovery 809 MB]
+Disk 1: [Reserved 15.98 MB] [D: 167.66 GB Basic]
+Disk 2: [Reserved 15.98 MB] [E: 930.63 GB Basic] [Recovery 885 MB]   <- F: ist weg
+Disk 3: [System 100 MB] [Reserved 16 MB] [G: 930.89 GB Basic] [Recovery 524 MB]
+Disk 4: [Reserved 15.98 MB] [H: 7.28 TB Basic]

audit/raw/02_folder_structure.txt

@@ -0,0 +1,52 @@
+### D:\ TOP-LEVEL ###
+00_Inbox        Directory  2026-06-04
+10_Dokumente    Directory  2026-06-04
+11_Bilder       Directory  2026-06-04  [ReadOnly-Attribut gesetzt]
+12_Videos       Directory  2026-06-04
+13_Musik        Directory  2026-06-04
+14_Downloads    Directory  2026-06-04
+20_Projekte     Directory  2026-06-04
+30_Finanzen     Directory  2026-06-04
+90_Archiv       Directory  2026-06-04
+Micha           Directory  2026-06-05  [Altquelle, noch vorhanden]
+WSL             Directory  2026-06-04  [nicht in Soll-Doku]
+DumpStack.log   File
+
+### D:\Micha INHALT ###
+Videos          Directory  2026-06-05  [1 Datei, 0 MB - fast leer]
+(alle anderen Unterordner weg)
+
+### D:\00_Inbox INHALT ###
+Desktop         Directory  2026-06-05  [ReadOnly - das ist das Known-Folder-Ziel!]
+
+### E:\ TOP-LEVEL ###
+BattleNet       Directory  2026-06-04  [SOLL]
+EA              Directory  2026-06-04  [SOLL]
+EpicGames       Directory  2026-06-04  [SOLL]
+Riot            Directory  2026-06-04  [SOLL]
+Steam           Directory  2026-06-05  [SOLL]
+Ubisoft         Directory  2026-06-04  [SOLL]
+_Standalone     FEHLT!                 [SOLL laut Doku]
+
+### G:\ TOP-LEVEL ###
+Apps            Directory  2026-06-04  [nicht in Soll-Doku]
+Gitea_Clone     Directory  2026-04-15  [nicht in Soll-Doku - bewusst, homelab-infra]
+repos           Directory  2026-06-05  [SOLL]
+Tools           Directory  2026-06-05  [SOLL - Doku schreibt 'tools' lowercase, NTFS case-insensitive]
+Workspace       Directory  2026-06-04  [nicht in Soll-Doku]
+
+### KNOWN FOLDER REDIRECTS (Ist) ###
+Desktop   -> D:\00_Inbox\Desktop      [ABWEICHUNG! Soll: D:\Micha\Desktop]
+Documents -> D:\10_Dokumente          [OK]
+Downloads -> D:\14_Downloads          [OK]
+Pictures  -> D:\11_Bilder             [OK]
+Music     -> D:\13_Musik              [OK]
+Videos    -> D:\12_Videos             [OK]
+
+### DOPPELBESTAND D:\Micha\* vs D:\NN_* ###
+D:\Micha\Dokumente : NICHT VORHANDEN  |  D:\10_Dokumente  : 4011 Dateien, 595 MB
+D:\Micha\Bilder    : NICHT VORHANDEN  |  D:\11_Bilder     : 7789 Dateien, 12367 MB
+D:\Micha\Videos    : 1 Datei, 0 MB   |  D:\12_Videos     : 1 Datei, 0 MB
+D:\Micha\Musik     : NICHT VORHANDEN  |  D:\13_Musik      : 0 Dateien
+D:\Micha\Downloads : NICHT VORHANDEN  |  D:\14_Downloads  : 2186 Dateien, 2211 MB
+D:\Micha\Finanzen  : NICHT VORHANDEN  |  D:\30_Finanzen   : 126 Dateien, 123 MB

audit/raw/03_os_security.txt

@@ -0,0 +1,63 @@
+### OS BASELINE ###
+Caption:       Microsoft Windows 11 Pro
+Build:         26200
+Version:       10.0.26200
+Architecture:  64-Bit
+InstallDate:   2026-05-10 13:11:27
+LastBoot:      2026-06-05 07:57:08
+Uptime:        0.04 Tage (~1 Stunde zum Audit-Zeitpunkt)
+Manufacturer:  Micro-Star International Co., Ltd.
+Model:         MS-7D32
+RAM:           31.79 GB
+CPU:           Intel Core i5-14600KF, 14 Cores, 20 Threads, 3500 MHz
+
+### AKTIVIERUNG ###
+Name:          Windows(R), Professional edition
+LicenseStatus: 1 (Aktiv)
+Channel:       OEM_DM
+
+### AUSSTEHENDE UPDATES ###
+Windows Update pending: 0
+Reboot pending:         Nein
+
+### DEFENDER ###
+AMProductVersion:   4.18.26040.7
+AMServiceEnabled:   True
+AntivirusEnabled:   True
+AntispywareEnabled: True
+RealTimeProtection: True
+TamperProtection:   True
+SignatureAge:       0 Tage (aktuell)
+Exclusions:        KEIN ADMIN -> nicht lesbar
+ASR Rules:         KEIN ADMIN -> nicht lesbar (Get-MpPreference liefert leer)
+
+### FIREWALL ###
+Domain:  Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
+Private: Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
+Public:  Enabled, DefaultInboundAction: NotConfigured, DefaultOutboundAction: NotConfigured
+HINWEIS: NotConfigured = Windows-Default (eingehend blockieren, ausgehend erlauben)
+
+### BITLOCKER ###
+KEIN ADMIN -> Get-BitLockerVolume verweigert (Access Denied). Status unbekannt.
+
+### SECURE BOOT ###
+KEIN ADMIN -> Confirm-SecureBootUEFI verweigert. Status unbekannt.
+
+### TPM ###
+KEIN ADMIN -> Get-Tpm liefert alle Felder leer. Status unbekannt.
+
+### UAC ###
+EnableLUA:                  1 (aktiv)
+ConsentPromptBehaviorAdmin: 5 (Nachfrage mit UI, ohne Secure Desktop laut Wert, aber...)
+PromptOnSecureDesktop:      1 (Secure Desktop ist AN - Standard-Konfiguration korrekt)
+
+### LOKALE ADMINS ###
+Gruppe Administratoren: Administrator, michi
+
+### BCD ###
+KEIN ADMIN -> bcdedit /enum verweigert.
+Letzte bekannte Aussage (Doku boot-cleanup-plan): Keine partition=F: Referenz nach Cleanup + Neustarttest.
+
+### WinRE ###
+KEIN ADMIN -> reagentc /info verweigert.
+Letzte bekannte Aussage (Doku): WinRE Disabled.

audit/raw/04_network_ssh.txt

@@ -0,0 +1,58 @@
+### NETZWERK-ADAPTER (UP) ###
+Ethernet     Intel I225-V  MAC: 04-7C-16-53-04-E4  1 Gbps
+Tailscale    Tunnel                                 100 Gbps (virtuell)
+vEthernet    WSL (Hyper-V) MAC: 00-15-5D-F3-5F-C9  10 Gbps (virtuell)
+
+### IP-ADRESSEN ###
+Ethernet:   192.168.178.103/24
+Tailscale:  100.78.133.37/32
+WSL bridge: 172.26.80.1/20
+(WLAN, Bluetooth etc.: APIPA 169.254.x.x - nicht konfiguriert/inaktiv)
+
+### DNS ###
+Ethernet DNS: 192.168.178.58  (= Kallilabcore AdGuard Home)
+WLAN DNS:     192.168.178.58
+
+### TAILSCALE STATUS ###
+100.78.133.37  baerchen-1     (dieser Rechner)     online
+100.105.203.21 baerchen       (alter Rechner)       offline, last seen 20h ago
+100.73.83.55   iphone-14      iOS                  online
+100.112.0.90   kallilab-core  linux                online
+100.80.98.33   kallilabcore   linux                active; direct 192.168.178.58:49917
+
+### LAUSCHENDE TCP-PORTS ###
+Port   Adresse          Prozess            Bemerkung
+135    0.0.0.0/::       svchost            RPC Endpoint Mapper
+139    192.168.178.103  System             NetBIOS
+445    ::               System             SMB
+3000   ::1/::           wslrelay / docker  Docker / WSL lokal
+5040   0.0.0.0          svchost            WS-Discovery (WDAS)
+5357   ::               System             WSD HTTP
+7680   ::               svchost            WUDO (Delivery Optimization)
+11434  127.0.0.1        ollama             Ollama API (lokal)
+22885  127.0.0.1        Battle.net         lokal
+26822  127.0.0.1        MSI.TerminalServer MSI Center
+27036  0.0.0.0          steam              Steam Remote Play (0.0.0.0 - offen!)
+27060  127.0.0.1        steam              Steam lokal
+32683  127.0.0.1        MSI.CentralServer  MSI Center
+33683  127.0.0.1        MSI.CentralServer  MSI Center
+38810  fd7a:...         tailscaled
+49553  100.78.133.37    tailscaled
+50123  127.0.0.1        iCUE               Corsair lokal
+51037  127.0.0.1        RazerAppEngine
+55316  127.0.0.1        RazerAppEngine
+59686  127.0.0.1        steam
+60999  127.0.0.1        Agent              Claude Code
+
+### SSH ###
+~\.ssh\config: LEER (keine Host-Eintraege)
+~\.ssh\id_ed25519: vorhanden (411 Bytes, erstellt 2026-04-04)
+~\.ssh\id_ed25519.pub: vorhanden (97 Bytes)
+~\.ssh\known_hosts: vorhanden (4719 Bytes, zuletzt 2026-06-04)
+~\.ssh\known_hosts.old + .pre-port222-Backup: vorhanden
+
+KEY PERMISSIONS id_ed25519:
+  NT-AUTORITAET\SYSTEM      FullControl  Allow
+  VORDEFINIERT\Administratoren FullControl  Allow
+  baerchen\michi            FullControl  Allow
+BEFUND: Zu viele Berechtigungen - Admins-Gruppe hat FullControl auf Private Key.

audit/raw/05_dev_tools.txt

@@ -0,0 +1,66 @@
+### DEV TOOLCHAIN ###
+git:    2.54.0.windows.1
+python: 3.13.13
+node:   24.16.0 (LTS)
+go:     1.26.4 windows/amd64
+
+### GIT CONFIG ###
+user.name:    michaelkaleschke-spec
+user.email:   michaelkaleschke@googlemail.com
+commit.gpgsign: nicht gesetzt (Commits nicht signiert)
+
+### WSL ###
+Ubuntu       Stopped   Version 2
+docker-desktop  Running  Version 2
+
+### DOCKER CONTEXTS ###
+default        npipe:////./pipe/docker_engine     (nicht aktiv)
+desktop-linux* npipe:////./pipe/dockerDesktopLinuxEngine  (aktiv)
+
+### KUBECTL ###
+Keine Contexts konfiguriert.
+
+### WINGET INVENTAR (158 Pakete, Auswahl) ###
+CPUID CPU-Z MSI 2.20.1
+CPUID HWMonitor 1.63
+CrystalDiskInfo 9.9.1
+Docker Desktop 4.76.0
+Git 2.54.0
+AusweisApp 2.5.1
+Node.js LTS 24.16.0
+Corsair iCUE5 5.46.67
+NVIDIA App 11.0.7.247 / Treiber 610.47
+WISO Steuer 2026 33.07.3410
+Go 1.26.4
+Microsoft Edge 148.0.3967.96
+Microsoft OneDrive 23.038 (Update verfuegbar: 26.078)
+RivaTuner Statistics Server 7.3.7
+Razer Synapse 4.0.683
+Steam 2.10.91.91
+Banking4 Home
+Battle.net / Hearthstone / Overwatch / World of Warcraft
+Microsoft 365 16.0.20026.20140
+
+### AUTOSTART ###
+HKCU\Run:
+  BraveSoftware Update -> BraveUpdateCore.exe
+  Steam               -> E:\Steam\steam.exe -silent
+  RazerAppEngine      -> Synapse autoStart
+  Docker Desktop      -> Docker Desktop.exe
+
+HKLM\Run:
+  SecurityHealth     -> SecurityHealthSystray.exe
+  Corsair iCUE5      -> iCUE Launcher.exe --autorun
+  RtkAudUService     -> Realtek Audio Service
+
+Startup-Ordner (User):   Ollama.lnk
+Startup-Ordner (Alle):   Tailscale.lnk
+
+### GEPLANTE TASKS (nicht-Microsoft, aktiv) ###
+OneDrive Reporting Task
+OneDrive Startup Task
+OneDrive Per-Machine Standalone Update Task
+PostponeDeviceSetupToast
+BraveSoftwareUpdateTask (2x User-Varianten)
+NVIDIA App SelfUpdate
+SoftLanding\CreativeManagementTask  [UNBEKANNT - pruefen]

audit/raw/06_events_hardware.txt

@@ -0,0 +1,45 @@
+### HARDWARE ###
+CPU:  Intel Core i5-14600KF, 14 Cores / 20 Threads, 3500 MHz Base
+RAM:  31.79 GB
+MB:   MSI MS-7D32
+Energieplan: Ausbalanciert (381b4222) - aktiv
+Verfuegbare Plaene: Ausbalanciert, Ultimative Leistung, Hoechstleistung, Energiesparmodus
+
+### PHYSICAL DISKS (SMART) ###
+INTEL SSDSC2BW180A3L  SSD  Healthy  OK   (Disk 0, C:)
+INTEL SSDSC2BW180A3L  SSD  Healthy  OK   (Disk 1, D:)
+Samsung SSD 980 PRO 1TB  SSD  Healthy  OK  (Disk 2, E:)
+WDC WDS100T2B0C       SSD  Healthy  OK   (Disk 3, G:)
+asmedia ASM235        Unspecified  Healthy  OK  (Disk 4, H:)
+Get-StorageReliabilityCounter: keine Ausgabe (Wear-Daten nicht via WMI verfuegbar - typisch fuer SATA SSDs und USB)
+
+### GERAETE MIT STATUS "Unknown" (PnP) ###
+MyBookLiveDuo (SoftwareDevice)    - Netzwerkgeraet, nicht angebunden - erwartet
+HID-Tastatur (Keyboard)           - ghosted device - harmlos
+Dell S2722DGM (DP) (Monitor)      - Display-Enumeration Artefakt
+Generic Monitor x2                - Display-Enumeration Artefakt
+[LG] webOS TV OLED65G48LW x2      - Netzwerkgeraet, nicht lokal - erwartet
+Standard-Volumeschattenkopie x3   - VSS Snapshots - erwartet
+KEINE echten Fehlercodes (kein gelbes Ausrufezeichen).
+
+### EVENT LOG FEHLER seit Installation (2026-05-10) ###
+ID 20   (70x): Defender KB4052623 Installation fehlgeschlagen (0x80240016)
+               -> Timing-Problem bei Update-Kaskade, harmlos wenn aktuell
+ID 10010 (15x): DCOM Server-Timeout {3E11DF0F-...}
+               -> bekanntes Windows-Hintergrundrauschen, harmlos
+ID 7000   (3x): Steam Client Service Start fehlgeschlagen
+               -> Steam war beim Boot noch nicht bereit, harmlos
+ID 7023   (3x): Windows Modules Installer beendet mit Fehler
+               -> Update-Installationsabbrueche, pruefbar nach Analyse der Zeitstempel
+ID 6008   (2x): Unerwartetes Herunterfahren am 2026-05-19 13:56:56
+               -> Einmaliger Vorfall (BSOD oder Stromausfall) kurz nach Installation
+ID 7034   (2x): MSI Center Service unerwartet beendet
+               -> bekannte Instabilitaet MSI Center, harmlos wenn kein Datenverlust
+ID 7043   (1x): Dienst konnte nicht gestoppt werden
+ID 1012   (3x): unbekannte ID - weitere Analyse noetig
+ID 36     (2x): unbekannte ID - weitere Analyse noetig
+
+### CRASH DUMPS ###
+C:\Windows\Minidump: nicht vorhanden
+C:\Windows\MEMORY.DMP: nicht vorhanden
+Bewertung: kein BSOD-Dump vorhanden (ggf. Dump-Einstellung "automatisch neu starten" ohne Dump-Schreiben)

core/gitea/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   gitea:
-    image: docker.gitea.com/gitea:1.25.4@sha256:17d18218be2dad1f8ed402a4f906989505c90ab8b66ee9befcecfb5d470133e7
+    image: docker.gitea.com/gitea:1.26.2@sha256:7d13848af12645600a5f9d93ee2560daa9c6fa6b5b859b7bff3a5e1c0b661031
     container_name: gitea
     restart: unless-stopped
     security_opt:

docs/AI_CONTEXT.md

@@ -1,213 +1,80 @@
 # AI Context
 
-Stand: 2026-05-04
+Stand: 2026-06-05
 
-Diese Datei ist fuer KI-Agenten gedacht, die das Homelab-Repo schnell verstehen muessen. Sie ersetzt nicht die Detaildokumente, sondern fasst Zielbild, Betriebsmodell und Risiken zusammen.
+Kurzer Kontext fuer KI-Agenten. Nicht als Ersatz fuer die echten Runbooks lesen.
 
-## Kurzfassung
+## Systembild
 
-Dieses Repository beschreibt ein Unraid-basiertes Homelab namens `Kallilabcore`. Der Betrieb folgt GitOps: Gitea `origin/master` ist die Quelle der Wahrheit, der lokale Clone ist Arbeitskopie, Komodo deployed aus Gitea, Docker Runtime und Host sind Ergebnis, nicht Bearbeitungsort.
+- Host: Unraid `Kallilabcore`
+- Betriebsmodell: GitOps mit Gitea `origin/master` als Sollzustand
+- Deploy: Komodo zieht aus Gitea und startet Compose-Stacks
+- Ingress: Traefik; WAN-seitig bewusst nur `443/tcp`
+- Secrets: nie im Repo, meist unter `/mnt/user/appdata/secrets/`
+- Backup: Borg plus host-seitige Dumps; Hetzner ist Offsite, H:/ ist lokale Nearline-Kopie
 
-Traefik ist der zentrale Web-Einstieg fuer HTTP(S). Admin-/Ops-UIs liegen entweder hinter Authelia/secure headers oder sind als Ausnahme dokumentiert. Secrets liegen ausserhalb des Repos auf dem Host, meistens unter `/mnt/user/appdata/secrets/`.
+## Vor jeder Aenderung lesen
 
-## Zielbild des Homelabs
+1. `HOMELAB_ARCHITECTURE_MASTER_V2.md`
+2. `docs/WORKFLOW.md`
+3. betroffene Compose-Datei
+4. bei Service-Fragen `docs/SERVICE_CATALOG.md`
+5. bei Restore/DR `docs/DISASTER_RECOVERY.md` und `docs/RESTORE_MATRIX.md`
 
-- stabile Compose-first Infrastruktur
+## Harte Regeln
-- keine produktiven Dockerman-/Ad-hoc-Container als Dauerzustand
-- Traefik als einziger oeffentlicher Web-Eingang
-- GitOps ueber Gitea + Komodo
-- klare Trennung von Web-Netz, Backend-Netz und app-internen Netzen
-- saubere Backup-/Restore-Faehigkeit ueber Borg, Dumps und dokumentierte Pfade
-- keine stillen Host-Hotfixes ohne Repo-/Doku-Abgleich
-
-## Architekturblocke
-
-### Ingress / Netzwerk
-
-- `traefik` nimmt 80/443 entgegen.
-- Docker-Labels definieren Service-Routing.
-- `traefik/dynamic/*` bleibt nur fuer Middlewares, TLS und Dashboards.
-- Neue Service-Routen gehoeren nicht in den File-Provider.
-
-### DNS / Remote
-
-- AdGuard Home beantwortet LAN-DNS und nutzt Unbound als Upstream.
-- Tailscale stellt Remote-Zugang bereit und nutzt `network_mode: host`.
-
-### GitOps
-
-- Gitea hostet das Repo unter `git.kaleschke.info`.
-- Komodo ist Stack-Manager und Deploy-Consumer.
-- Komodo Periphery braucht Docker-Socket und `/mnt/user/services` Mount, um Stacks reproduzierbar zu deployen.
-- Neue produktive Komodo-Stacks aus `Micha/homelab-infra` muessen einen aktiven Gitea->Komodo-Webhook auf die aktuelle Stack-ID haben; Ausnahmen wie deaktivierte/pausierte Stacks muessen dokumentiert werden.
-- Der `komodo`-Self-Stack ist eine dokumentierte Ausnahme ohne aktiven Gitea-Webhook; Bootstrap/Recovery laeuft ueber `docs/SERVICES_RECOVERY.md`.
-
-### Identity / Security
-
-- Authelia stellt ForwardAuth fuer viele Admin-UIs bereit.
-- Authelia nutzt GMX SMTP fuer Identity-/2FA-Benachrichtigungen; Passwort liegt als Host-Secret `authelia_smtp_password.txt`.
-- Vaultwarden ist ein separater Passwort-Tresor.
-- Komodo ist bewusst nicht pauschal hinter Authelia, weil UI, API, Webhooks und Periphery-WebSocket sonst leicht gebrochen werden koennen.
-- Komodo-Compose, Komodo-Secrets und Komodo-Runtime nur gemeinsam mit dem Betreiber aendern; `KOMODO_WEBHOOK_SECRET` ist bewusst getrennt von `KOMODO_SECRET_KEY`. Gitea-Webhooks nicht pauschal vereinheitlichen: einzelne Komodo-Stacks koennen eigene per-Stack-Webhook-Secrets haben.
-
-### Apps
-
-Wichtige Apps sind Paperless, Immich, Mealie, Mail Archiver, Nextcloud, ntfy, Vaultwarden und Gitea. Admin-/Ops-Tools sind u. a. Glance, Komodo, Borg UI, Filebrowser, code-server, Glances, Scrutiny, Speedtest, Monitoring Grafana und Hermes Agent.
-
-### Hermes Agent — Architektur und Ops-Monitor
-
-Hermes laeuft nach Model C (siehe `ops/hermes-agent/README.md`):
-
-- `hermes-gateway` als Docker-Container auf dem Unraid-Host, intern auf `hermes_net:8642`
-- Terminal-Befehle werden via SSH auf eine dedizierte Linux-VM ausgefuehrt
-- VM-IP: `192.168.178.143`, SSH-User: `hermes`
-- Repo-Clone auf der VM: `/srv/hermes-workspace/homelab-infra/`
-
-**Fuer KI-Agenten wichtig:** Das Hermes-Terminal laeuft auf der VM, nicht auf dem Unraid-Host.
-`/mnt/user/...`-Pfade sind von der VM aus nicht direkt erreichbar.
-Docker-CLI ist auf der VM nicht installiert — fuer Homelab-Checks wird `check_health.py` verwendet.
-
-**Ops-Monitor (homelab-ops-monitor):**
-
-- Skill: `ops/hermes-agent/skills/homelab-ops-monitor.md`
-- Script: `ops/hermes-agent/scripts/check_health.py` — prueft Services via HTTP, keine externen Deps
-- Wissensbasis: `ops/hermes-agent/services.json` — maschinenlesbare Ableitung aus `docs/SERVICE_CATALOG.md`
-- Check-Strategie: HTTP GET fuer URL-basierte Services, interne Services (DBs, Redis) als `"internal"` markiert
-- ntfy-Topic fuer Alerts: `homelab-alerts` auf `https://ntfy.kaleschke.info`
-
-Nach Aenderungen an `services.json` oder `check_health.py`: `git pull` auf der VM ausfuehren.
-- Mail Archiver ist ein Hybrid-Dienst mit `frontend_net` fuer IMAP/Traefik und `backend_net` fuer PostgreSQL; die Web-UI liegt hinter Authelia und behaelt zusaetzlich App-eigene Auth.
-
-### Monitoring / Metriken
-
-- Zielzustand ist ein zentraler Stack `monitoring/` unter `https://monitoring.kaleschke.info`.
-- `monitoring-grafana` ist die zentrale UI fuer Prometheus, Loki und InfluxDB 3 Core.
-- `monitoring-prometheus` sammelt Infrastruktur-Metriken; `monitoring-loki` + `monitoring-promtail` sammeln Docker-Logs.
-- `monitoring-influxdb3-core` ist nicht public und nicht im `frontend_net`.
-- Home Assistant schreibt ueber LAN-only Port 8181 nach InfluxDB, gebunden ueber `INFLUXDB_BIND_IP`.
-- Ein `401 Unauthorized` von InfluxDB ohne Token ist beim Reachability-Test ein Erfolgssignal.
-- Die frueheren Altstaende `ops/loki` und `ops/grafana-influxdb` wurden aus dem aktiven Repo entfernt; fuer Monitoring immer `monitoring/` verwenden, Rollback nur ueber Git-Historie.
-- Uptime Kuma ist entfernt; HTTP-Verfuegbarkeit laeuft ueber Blackbox Exporter, Prometheus-Alerts und `Homelab / Availability` in Monitoring Grafana.
-
-## Deployment-Logik
-
-Normalfall:
-
-1. lokaler Clone synchronisieren
-2. betroffene Dokumente und Compose-Datei lesen
-3. minimal aendern
-4. lokal validieren
-5. committen und pushen
-6. Komodo-Webhook / Deploy beobachten
-7. Runtime testen
-8. Doku aktualisieren
-
-Wichtig: Komodo-Web-Editor ist nicht der Bearbeitungsort. Wenn Komodo und Git voneinander abweichen, zuerst Git und Komodo Workspace pruefen, nicht live herumprobieren.
-
-Beim Anlegen neuer produktiver Stacks ist der Gitea->Komodo-Webhook Pflicht. Nach dem Anlegen muss ein Test-Push oder Test-Delivery zeigen, dass Gitea die aktuelle Komodo-Stack-ID erreicht.
-
-## Netzwerkmodell
-
-| Netzwerk | Bedeutung |
-|---|---|
-| `frontend_net` | Web-/Proxy-Netz fuer Traefik-geroutete Dienste und Dienste mit Internetbedarf |
-| `backend_net` | internes Netz fuer shared PostgreSQL, Redis und Backends |
-| `dns_net` | AdGuard + Unbound |
-| app-interne Netze | Isolation von App + DB/Cache, z. B. Immich, Mealie, Nextcloud, Monitoring |
-| `host` | nur dokumentierte Sonderfaelle wie Tailscale/Plex |
-
-Regeln:
 
+- Keine Secrets zitieren oder ins Repo schreiben.
+- Keine produktiven Host-Hotfixes ohne Repo-Abgleich.
 - Datenbanken nie ins `frontend_net`.
-- Admin-UIs nur mit Traefik + Middleware oder dokumentierter Ausnahme.
+- Direkte Host-Ports sind Ausnahme.
-- Direkte Host-Ports sind Ausnahme, nicht Default.
+- Traefik dynamic config und Authelia Host-Config sind manuelle Sync-Ausnahmen.
-- Runtime-Netznamen koennen Compose-Projektpraefixe bekommen, z. B. `monitoring_monitoring_influx_lan`.
+- Bei Drift zuerst Git, Gitea, Komodo Workspace, Docker Runtime und Host getrennt pruefen.
+- Nach zwei fehlgeschlagenen Reparaturversuchen stoppen und `docs/GITOPS_DRIFT_RUNBOOK.md` nutzen.
 
-## Security-Modell
+## Bekannte Ausnahmen
 
-- Secrets nie ins Git.
+- Traefik: Host-Ports 80/443, WAN-Freigabe nur 443
-- Werte niemals zitieren, auch nicht aus `.env`, Stack ENV, Logs oder Screenshots.
+- Gitea: SSH auf Host-Port 222, keine WAN-Freigabe
-- Secret-Dateien bevorzugt unter `/mnt/user/appdata/secrets/`.
+- AdGuard: DNS 53 direkt; Admin nur auf Tailscale-IP `100.80.98.33:8082`
-- `_FILE`-Varianten bevorzugen, falls Image sie unterstuetzt.
+- Tailscale und Plex: Host-Netz
-- Wenn `_FILE` nicht unterstuetzt wird, Komodo Stack Environment Variables verwenden.
-- Docker-Socket, `privileged: true`, Host-Netz und breite Mounts sind nur mit dokumentierter Begruendung akzeptabel.
-
-Bekannte Ausnahmen:
-
-- Traefik: 80/443
-- Gitea: SSH 222
-- AdGuard: DNS 53 direkt; Admin 8082 ist bewusst ohne Traefik/2FA, aber auf Tailscale-IP `100.80.98.33` begrenzt
-- Tailscale: Host-Netz, `NET_ADMIN`, `NET_RAW`, `/dev/net/tun`
 - Scrutiny: privileged
-- Komodo: Docker-Socket, native Auth
+- Komodo/Periphery: Docker-Socket-Zugriff
-- InfluxDB: LAN-only 8181 fuer Home Assistant Writer
+- InfluxDB 3 Core: `127.0.0.1:8181`, Root-User-Ausnahme dokumentiert
-- `monitoring-influxdb3-core`: `user: "0"` als dokumentierte Host-Appdata-Permissions-Ausnahme
-- Traefik dynamic config: manueller Host-Sync
 
-## Backup- und Restore-Modell
+## Aktuelle Restpunkte
 
-Borg sichert kritische Appdaten, Secrets, Traefik-State und Dump-Artefakte. Datenbank-Restore soll bevorzugt ueber Dumps laufen, nicht ueber rohe Live-DB-Verzeichnisse.
+Authoritativ: `docs/MASTER_TODO.md`.
 
-Wichtige Pfade:
+Kurzfassung:
 
-- `/mnt/user/appdata`
+- Auth-/OIDC-/CrowdSec-/Hermes-Themen bewusst geparkt
-- `/mnt/user/appdata/secrets`
+- Wochenend-Sprint 2026-06-05: `docs/WEEKEND_EXECUTION_PLAN_2026-06-05.md`
-- `/mnt/user/services`
+  und `docs/WEEKEND_STATUS_2026-06-05.md`
-- `/mnt/user/documents`
-- `/mnt/user/photos`
-- `/mnt/user/backups/borg/dumps/latest`
 
-Dump-Skript:
+Letzte Bestaetigung:
 
-- `ops/borg-ui/scripts/pre-backup-dumps.sh`
+- Windows-Image `baerchen`: Veeam Agent Free Job `baerchen-c-image` auf
-- soll auf dem Unraid Host laufen
+  `\\kallilabcore\backups\windows-images\baerchen`, erster Full-Backup-Lauf
-- soll nicht als Borg-UI Inline-Hook behandelt werden, solange die Architektur nicht bewusst geaendert wird
+  2026-06-05 erfolgreich, GUI-Wert 53,8 GB, Dauer 0:11:31. Recovery-USB ist
-
+  erstellt; Boot-/SMB-/Restore-Point-Test ohne Restore ist noch offen.
-Disaster Recovery folgt einer Bootstrap-Reihenfolge:
+- Veeam Storage Encryption ist beim ersten Full-Lauf nicht aktiv
-
+  (`StorageEncryptionEnabled=False`); nachtraegliche Aktivierung ist eine
-1. Traefik, AdGuard, Tailscale
+  Operator-Entscheidung, weil sie Passwort- und Restore-Prozess aendert.
-2. PostgreSQL, Authelia, Redis, Gitea
+- BitLocker fuer `baerchen` ist bewusst nicht aktiviert und bleibt
-3. Komodo
+  Operator-Entscheidung.
-4. kritische Apps
+- Tailscale-Inventar 2026-06-05 real gemessen: `Kallilabcore`
-5. restliche Apps/Ops inklusive Hermes Agent
+  `100.80.98.33`, IPv6 `fd7a:115c:a1e0::2c01:62b2`, kein Exit Node, aber
-
+  aktiver Subnet Router fuer `192.168.178.0/24`. Dadurch ist die Tailnet-ACL
-## Typische Arbeitsweise im Repo
+  sicherheitsrelevant; Entscheidung Default-Allow vs tag-basierte ACL offen.
-
+- Unraid-Flash-Backup-Artefaktpruefung: `ops/maintenance/check-unraid-flash-backup.sh`
-- Fuer Fragen zuerst `HOMELAB_ARCHITECTURE_MASTER_V2.md` lesen.
+  prueft Artefakt, SHA256, Alter und Kern-Configs. Test 2026-06-05 gegen Host
-- Fuer operative Aenderungen `docs/WORKFLOW.md` lesen.
+  erfolgreich laut `docs/MASTER_TODO.md`.
-- Fuer Service-Details `docs/SERVICE_CATALOG.md` und die Compose-Datei lesen.
+- Borg-Nachlauf 2026-06-01 erfolgreich: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, Freshness Critical 0 / Warnings 0.
-- Fuer Drift `docs/GITOPS_DRIFT_RUNBOOK.md` nutzen.
+- H:/ Nearline-Pull 2026-06-01 repariert: Borg-Dumps werden kuratiert kopiert, Gitea-Bundles aktuell.
-- Fuer Rollback `docs/ROLLBACK.md` nutzen.
+- Family-Status-Dashboard liegt als `monitoring/grafana/dashboards/family-status.json` im Repo.
-- Fuer Restore `docs/DISASTER_RECOVERY.md` und `docs/RESTORE_MATRIX.md` nutzen.
+- Alt-Volumes nach PG18/VectorChord-Burn-in sind seit 2026-06-02 reversibel archiviert unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602`; die alten Originalpfade sind nicht mehr aktiv gemountet.
-
+- Family-Onboarding ist auf drei Nutzungsziele fokussiert: Vaultwarden, Immich und Mealie; praktischer Ablauf in `docs/FAMILY_ONBOARDING.md`.
-KI-Agenten sollen konservativ arbeiten: keine indirekten Live-Aenderungen, keine Deployments, keine Commits, keine Host-Schreibbefehle, wenn der Benutzer nur Analyse oder Doku verlangt.
+- Externer Betreibercheck: `ops/maintenance/check-external-operator.sh`; FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`, DNS fuer Public Apps hat keine AAAA-Records, Host hat keine globale Provider-IPv6.
-
+- FRITZ!Box-UI 2026-06-01: Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, WAN-Freigabe nur `443/tcp`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
-## Bekannte Risiken und Altlasten
+- FRITZ!Box-Konfig-Backup 2026-06-01 extern/off-system in Vaultwarden abgelegt; Datei und Kennwort bleiben ausserhalb des Repos.
-
+- Hetzner-Account-Hygiene 2026-06-01 erledigt: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok; Storage Box SSH-only, Maintenance-Key in Vaultwarden. Append-only forced-command brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Operator-Entscheidung: fuer dieses Homelab bewusst nicht umsetzen.
-- Traefik dynamic config muss manuell auf den Host synchronisiert werden; Komodo deployed diese Dateien nicht automatisch.
-- `backend_net` und app-interne Netze muessen bei Runtime-Problemen live geprueft werden, weil Compose-Projektpraefixe Netznamen veraendern koennen.
-- Authelia `configuration.yml` ist Repo-Baseline fuer nicht geheime Einstellungen, wird aber nicht automatisch von Komodo auf den Host kopiert; die produktive Host-Datei kann OIDC-/Secret-Konfiguration enthalten. Bei Auth-Aenderungen Repo-Baseline, Host-Config und Compose-Middlewares pruefen und nicht blind ueberschreiben.
-- Authelia nutzt PostgreSQL, aber bewusst kein Redis-Session-Backend; Redis ist kein Authelia-Bootstrap-Blocker.
-- Authelia-Notifier ist SMTP; bei Auth-Aenderungen Host-Config backupen, `authelia validate-config` ausfuehren und erst danach neu starten.
-- `paperless-ngx` nutzt fuer DB/Redis bewusst Stack ENV statt `_FILE`.
-- `glance-docker-socket-proxy`, `glances` und `komodo-periphery` nutzen Docker-/Socket-Zugriff; Zugriff bewusst behandeln.
-- `borg-ui` und `filebrowser` haben breite Mounts; bei Hardening nicht ad hoc, sondern gezielt vorgehen.
-- `scrutiny` ist privilegiert und hat Device-Mounts.
-- `Plex-Media-Server` ist im Architekturziel als Host-Sonderfall dokumentiert, aber nicht als Repo-Compose-Stack enthalten.
-- Echte `stack.env`- und `.env`-Dateien gehoeren nicht ins Repo; fuer Hermes liegt nur `ops/hermes-agent/stack.env.example` im Git.
-- Einige Images nutzen mutable Tag plus Digest. Das friert den aktuellen Digest ein, ist aber kein automatisches Upgrade-Modell.
-- Stateful Images werden bevorzugt als Minor-/Patch-Tag plus Digest gepinnt; Redis-Caches bleiben bewusst ungedigestet.
-
-## Arbeitsregel bei Unsicherheit
-
-Nicht raten. Erst diese Reihenfolge:
-
-1. Repo-Doku lesen
-2. Compose-Datei lesen
-3. Git-Stand pruefen
-4. Komodo Workspace pruefen
-5. Docker Runtime pruefen
-6. Host-Listener / echten Request pruefen
-7. genau eine abweichende Ebene benennen
-
-Wenn zwei Reparaturversuche scheitern: keine weiteren Schreibbefehle, Pflichtmatrix aus `docs/GITOPS_DRIFT_RUNBOOK.md` ausfuellen.

docs/AI_HANDOFF_2026-05-06.md

@@ -1,80 +0,0 @@
-# AI Handoff 2026-05-06
-
-Kompakte Quelle fuer einen neuen Chat. Ziel: nicht das ganze Repo neu auditieren, sondern mit dem bekannten Stand weiterarbeiten.
-
-## Aktueller Stand
-
-- Repo: `G:\Gitea_Clone\homelab-infra`
-- Remote: `https://git.kaleschke.info/Micha/homelab-infra.git`
-- Branch: `master`
-- Letzter bekannter Commit: `e0e12f1 Document stale Komodo webhook cleanup`
-- Unraid-Host: `ssh root@192.168.178.58`
-- Push-Befehl, der zuverlaessig funktioniert: `git -C "G:\Gitea_Clone\homelab-infra" push origin master`
-- Nicht anfassen ohne explizite Freigabe: untracked `Homelab_Audit_2026-05-05.pdf` und untracked `ops/hermes-agent/services.yaml`.
-
-## Audit-Arbeit Erledigt
-
-- K1: ungueltige Digests fuer Authelia, ntfy und borg-ui korrigiert und smoke-getestet.
-- K2: Authelia nutzt bewusst kein Redis; Doku entsprechend korrigiert.
-- K3/M1/M2 alt: Authelia Repo-Baseline geklaert, Homepage/Komodo ACL-Drift bereinigt.
-- M3a/M3b: Digest-Pinning fuer stateful/Tier-1 und weitere versionierte Apps umgesetzt; Redis-Caches bewusst ohne Digest, Nextcloud bewusst offen.
-- M5/N5: `.gitignore` eingefuehrt, Hermes `stack.env` zu `stack.env.example`.
-- M6/M7/M8: Hermes-Domain, Grafana/Influx `user: "0"` und Tailscale-Capabilities dokumentiert.
-- M9: Backup Scope / Restore Matrix erledigt.
-- N-Aufraeumen: alte Compose-`version:` Felder, leere Env-Beispiele und `.keep`-Platzhalter bereinigt.
-- Mail Archiver: `mail.kaleschke.info` liegt hinter `authelia@file,secure-headers@file`; Smoke-Test war 302 zu Authelia.
-- Hermes: Restore/DR-Doku ergaenzt.
-- Authelia SMTP: GMX SMTP eingerichtet, validiert, deployed und smoke-getestet.
-- M10: `KOMODO_WEBHOOK_SECRET` ist von `KOMODO_SECRET_KEY` getrennt.
-
-## Wichtige Runtime-Details
-
-### Authelia SMTP
-
-- Adresse: `submission://mail.gmx.net:587`
-- Mailkonto: `michideheld@gmx.de`
-- SMTP-Passwort liegt nur auf dem Host: `/mnt/user/appdata/secrets/authelia_smtp_password.txt`
-- Host-Config wurde vor Umstellung gesichert: `/mnt/user/appdata/authelia/config/configuration.yml.bak-20260506-smtp`
-- Authelia-Compose nutzt explizite DNS-Server, weil der SMTP-Startup-Check externe Namen aufloesen muss.
-- Nach Deploy war `authelia` healthy; `auth.kaleschke.info` antwortete 200, geschuetzte Routen 302 zu Authelia.
-
-### Komodo / M10
-
-- Komodo-Runtime nur gemeinsam mit dem Betreiber aendern.
-- `KOMODO_SECRET_KEY` wurde nicht geaendert.
-- `KOMODO_WEBHOOK_SECRET` wurde geaendert und ist jetzt eigener 64-Zeichen-Wert.
-- Neuer Wert liegt nur auf dem Host in `/mnt/user/services/stacks/komodo/.env`.
-- Komodo Compose auf Host: `/mnt/user/services/stacks/komodo/compose.yaml`.
-- Backups vom M10-Sprint:
-  - `/mnt/user/appdata/komodo/_m10_backup_20260506-184838`
-  - `/mnt/user/services/gitea/data/gitea/_m10_backup_20260506-184838/gitea.db.bak`
-- `komodo-core` wurde gezielt recreated.
-- `komodo-mongo` wurde nicht neu gestartet.
-- `komodo-periphery` lief durch und meldete sich wieder am Core-Websocket an.
-- Gitea-Komodo-Webhooks: 29 aktive Hooks, 29 zuletzt erfolgreich, 0 aktiv fehlgeschlagen.
-- Ein stale Gitea-Webhook auf eine nicht mehr existierende Komodo-Stack-ID wurde deaktiviert, nicht geloescht.
-- Eine Warnung `request branch does not match expected` ist ein Branch-Filter-Skip, kein Secret-/Auth-Fehler.
-- Fuer neue Gitea-Webhooks im Standardfall den globalen `KOMODO_WEBHOOK_SECRET` aus der Komodo-Host-`.env` nutzen, ausser Komodo zeigt fuer den Stack explizit ein eigenes per-Stack-Secret.
-
-## Sicherheitsregeln Fuer Weitere Arbeit
-
-- Keine Secret-Werte im Chat oder Git ausgeben.
-- Bei Host-Pruefungen nur SET/MISSING, Laengen und Pfade zeigen.
-- Komodo-Compose, Komodo-Secrets und Komodo-Runtime nur bewusst und kleinschrittig aendern.
-- Bei jedem Deploy pro Stack smoke-testen; nicht mehrere kritische Stacks parallel veraendern.
-- Untracked Dateien nicht automatisch committen.
-- Bei Authelia-Aenderungen: Host-Config sichern, `authelia validate-config` ausfuehren, dann erst neu starten.
-- Bei Komodo-Aenderungen: Gitea-Webhooks und Komodo-Core-Secret-Seite zusammen betrachten.
-
-## Naechste Sinnvolle Next-Level-Themen
-
-- Grafana/Influx rootless betreiben statt `user: "0"`; eigener Sprint wegen Volume-Rechten.
-- Restore-Test fuer Vaultwarden und Paperless dokumentiert durchfuehren.
-- Komodo Periphery von Legacy-Passkey auf Public-Key-Modell haerten.
-- Monitoring/Alerting reifer machen: externe Alarme, Restore-Test-Reminder, Backup-Erfolg sichtbar.
-- Gitea/Komodo Webhook-Landschaft weiter aufraeumen und per-Stack-Secret-Strategie dokumentieren.
-- DR-Test fuer `backend_net`/externe Docker-Netze explizit aufnehmen.
-
-## Startprompt Fuer Neuen Chat
-
-Bitte zuerst `docs/AI_HANDOFF_2026-05-06.md` lesen und als aktuelle Arbeitsquelle verwenden. Nicht das ganze Repo neu auditieren, ausser ich fordere es an. Beachte besonders: Komodo nur gemeinsam und kleinschrittig aendern, keine Secret-Werte ausgeben, untracked PDF und `ops/hermes-agent/services.yaml` nicht anfassen. Wir starten jetzt mit Next-Level-Hardening.

docs/ALERTING_MAP.md

@@ -1,31 +0,0 @@
-# Alerting Map
-
-Stand: 2026-05-23
-
-Ziel: Alle problemrelevanten Homelab-Meldungen landen auf einem Handy-Topic.
-
-## ntfy Topics
-
-| Topic | Zweck |
-|---|---|
-| `homelab-alerts` | Alles, was Aufmerksamkeit braucht: Prometheus, Docker-Events, Posture, Zertifikate/Token, Compose-Drift, Borg-Pre-Hook-Fehler und Restore-Fehler |
-| `homelab-info` | Optionale Erfolgsmeldungen, z. B. erfolgreiche Restore-Testlaeufe |
-
-## Sender
-
-| Sender | Pfad | Problem-Topic | Hinweis |
-|---|---|---|---|
-| Prometheus / Alertmanager | `monitoring/alertmanager/alertmanager.yml`, `monitoring/alertmanager-ntfy-bridge/bridge.py` | `homelab-alerts` | Zentrale Monitoring-Alerts via Bridge |
-| Posture Check | `services/posture-check/posture-check.sh` | `homelab-alerts` | Warning und Critical gehen auf dasselbe Handy-Topic |
-| Cert / Token Check | `services/posture-check/cert-token-check.sh` | `homelab-alerts` | Prueft produktive HTTPS-Domains und Cloudflare Token |
-| Compose Runtime Drift | `services/posture-check/compose-runtime-drift.sh` | `homelab-alerts` | Meldet Abweichungen zwischen Repo-Compose und Runtime-Image |
-| Docker Critical Events | `services/posture-check/docker-critical-events.sh` | `homelab-alerts` | Meldet Docker `die`, `oom` und `kill` Events |
-| Borg Pre-Hook | `ops/borg-ui/scripts/pre-borg.sh` | `homelab-alerts` | Meldet Fehler vor Borg, z. B. Posture-, Dump- oder Restore-Freshness-Fehler |
-| Restore Jobs | `ops/restore-tests/run-restore-job-with-ntfy.sh` | `homelab-alerts` | Erfolg geht an `homelab-info`, Fehler immer an `homelab-alerts` |
-
-## Konvention
-
-- `NTFY_BASE_URL` zeigt standardmaessig auf `https://ntfy.kaleschke.info`.
-- Neue Problem-Alerts sollen `homelab-alerts` nutzen.
-- Erfolgsmeldungen sind optional und sollen nicht in `homelab-alerts` landen, ausser sie sind bewusst als Lebenszeichen gewuenscht.
-- Blackbox-Endpoint-Alerts sollen bekannte WAN-/Provider-Sammelausfaelle zusammenfassen, damit kurze DSL-Reconnects keine ntfy-Flut pro Domain erzeugen.

docs/ALERT_RULES.md

@@ -0,0 +1,54 @@
+# Alert Rules
+
+Stand: 2026-06-05
+
+Diese Datei beschreibt die produktiven Alarmwege und wichtigsten Regeln. Die
+Konfiguration selbst liegt in `monitoring/prometheus/alerts.yml` und in den
+Skripten unter `services/posture-check/`.
+
+## Alarmwege
+
+| Weg | Quelle | Ziel |
+|---|---|---|
+| Prometheus / Alertmanager | `monitoring/prometheus/alerts.yml` | ntfy `homelab-alerts` |
+| Posture Check | `services/posture-check/posture-check.sh` | ntfy `homelab-alerts` |
+| Cert / Token Check | `services/posture-check/cert-token-check.sh` | ntfy `homelab-alerts` |
+| Compose Runtime Drift | `services/posture-check/compose-runtime-drift.sh` | ntfy `homelab-alerts` |
+| Docker Critical Events | `services/posture-check/docker-critical-events.sh` | ntfy `homelab-alerts` |
+| Borg Pre-Hook | `ops/borg-ui/scripts/pre-borg.sh` | ntfy `homelab-alerts` |
+| Restore Jobs | `ops/restore-tests/run-restore-job-with-ntfy.sh` | Fehler `homelab-alerts`, Erfolg `homelab-info` |
+
+## Prometheus-Regeln
+
+| Alarm | Ausloeser | Severity | Aktion |
+|---|---|---|---|
+| `HomelabExternalConnectivityDown` | mindestens 5 HTTP-Ziele down | warning | WAN/DNS/Provider pruefen, nicht jede Domain einzeln jagen |
+| `HomelabEndpointDown` | einzelnes HTTP-Ziel down | critical | Dienst, Traefik-Route und Backend pruefen |
+| `HomelabEndpointSlow` | Endpoint >5s | warning | Dienstlast oder Backend-Latenz pruefen |
+| `HomelabCertificateExpiresSoon` | Cert <21 Tage | warning | ACME/Traefik-Renewal beobachten |
+| `HomelabCertificateExpiresCritical` | Cert <=7 Tage | critical | Renewal sofort pruefen |
+| `HomelabDiskAlmostFull` | Filesystem >85% | warning | Platz schaffen oder Schwelle pruefen |
+| `HomelabDiskCritical` | Filesystem >95% | critical | Sofort Platz schaffen |
+| `HomelabHighMemoryUsage` | MemAvailable <10% | warning | Speicherfresser identifizieren |
+| `HomelabTraefik5xx` | >=5 5xx je Service in 5 Minuten | warning | betroffenes Backend pruefen |
+| `HomelabTextfileExporterStale` | Textfile-Exporter >2h alt | warning | Host-Cron pruefen |
+| `HomelabBorgMetricsMissing` | Borg-Metrik fehlt | critical | Textfile-Exporter oder Borg-UI pruefen |
+| `HomelabBorgBackupStale` | letztes Borg-Backup >30h | warning | Backup-Lauf nachholen/pruefen |
+| `HomelabBorgLastJobFailed` | letzter Borg-Job fehlgeschlagen | critical | Borg-UI-Job-Log pruefen |
+| `HomelabBorgLastJobCompletedWithWarnings` | letzter Borg-Job mit Warnungen | warning | Warnung im Borg-UI-Job lesen |
+| `HomelabCriticalContainerDown` | kritischer Container fehlt | critical | Komodo/Docker-Status pruefen |
+| `HomelabPrometheusTargetDown` | Scrape-Ziel down | critical | node-exporter/cadvisor/blackbox/traefik pruefen |
+
+Die Liste der ueberwachten Critical-Container steht in
+`services/posture-check/export-prometheus-textfile.sh`.
+
+## Bekannte Luecken
+
+- Kein externer Dead-Man's-Switch fuer Prometheus/ntfy-Bridge. Optional spaeter
+  ueber Uptime-Kuma Push-Monitor oder Healthchecks.io.
+- Kein Inode-Alarm. Bei Paperless/Immich spaeter sinnvoll, aber aktuell kein
+  dokumentierter Vorfall.
+- Container-Memory-Limits werden erst nach realen Peak-Daten gesetzt; OOM/kill
+  wird ueber `docker-critical-events.sh` gemeldet, sobald der Host-Watcher per
+  Unraid User Script aktiviert ist. Start/Stop/Status/Smoke laufen ueber
+  `services/posture-check/docker-critical-events-supervisor.sh`.

docs/AUDIT_2026-05-23.md

@@ -1,369 +0,0 @@
-# Homelab Audit - 2026-05-23
-
-Stand: 2026-05-23, repo-basiert. Erstellt nach `docs/WORKFLOW.md` und `docs/GITOPS_DRIFT_RUNBOOK.md`. Quellebasis: `origin/master` plus lokaler Clone, ohne Schreibbefehle, ohne Deploy.
-
-Dieser Audit ist eine punktuelle Sollzustands-Bewertung, kein Live-Status. Die Live-Verifikations-Schritte stehen am Ende in Abschnitt 9; alle dortigen Outputs ersetzen Vermutungen durch Messwerte.
-
-## 0. Executive Summary
-
-Ampel-Bewertung pro Bereich:
-
-| Bereich | Ampel | Kernaussage |
-|---|---|---|
-| GitOps-Konsistenz (lokal/Gitea) | 🟡 | Lokaler Clone ist **1 Commit voraus** auf `master` (`cd650b1`, Haertungs-Commit). Bis zum Push existiert dieser Stand nur lokal, nicht in Gitea — bei einem Clone-Verlust ist er weg. |
-| GitOps-Konsistenz (Working Tree) | 🟢* | Keine echten Inhaltsaenderungen offen. Die 47 "modified files" aus `git status` im Linux-Mount sind voraussichtlich CRLF/LF-Mount-Artefakte (durch `git diff -w --stat` auf Stichprobe bestaetigt leer). Bitte am Windows-Host gegenpruefen. |
-| Hardening-Sprint (Mai 2026) | 🟢 | Alle vier Post-Restore-Sprint-Items sind im Repo umgesetzt (Filebrowser-Mounts, Authelia Argon2id, Gitea Webhook-Allowlist, Backup-Dump-Konsistenz). |
-| Backup/Restore-Readiness | 🟢 | `pre-backup-dumps.sh` deckt alle relevanten SQLite/PostgreSQL/Mongo-Quellen ab. Borg-UI-Scope umfasst `/mnt/user/services`, `homelab-infra`, `stacks`, `posture-check`. Live-Frische ist offen (Abschnitt 9). |
-| Monitoring-Migration | 🟡 | `monitoring/` Stack im Repo komplett, aber Live-Deploy laut `docs/NEXT_SPRINT_TODO_2026-05-16.md` noch ausstehend. Alte Stacks `ops/grafana-influxdb` und `ops/loki` sollen erst nach Live-Smoke-Test gestoppt werden. |
-| Doku-Drift Repo vs. Master-Doku | 🟠 | `apps/jellyfin/`, `host-services/plex/` und einige andere existieren produktiv als Compose-Stacks, sind aber in `HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/SERVICE_CATALOG.md` und `docs/REPO_MAP.md` **nicht aufgefuehrt**. Authelia-ACL kennt `jellyfin.kaleschke.info` als bypass, im Masterdoku-Hostkatalog steht es nicht. |
-| Repo-Hygiene | 🟡 | 8 leere Verzeichnisse im Working Tree (siehe 4.3). `.serena/` ist untracked und nicht in `.gitignore`. Drei `ops/windows-reinstall/*.ps1` sind untracked. |
-| Bekannte Ausnahmen | 🟢 | Alle Ausnahmen aus `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 10 sind weiterhin dokumentiert und durch den Policy-Check abgedeckt (0 Critical, 4 Warnings, 9 Info – alles dokumentierte Ausnahmen). |
-
-**Kernfazit:** Das Homelab ist sehr nah an der "Endstufe". Es gibt keine kritischen Befunde. Die einzige Pflichtaktion vor dem naechsten geplanten Schritt ist der **Push des lokalen Commits `cd650b1` nach Gitea**, damit `origin/master` wieder die Quelle der Wahrheit ist. Danach sind nur noch zwei priorisierte Pakete offen: Monitoring-Stack live finalisieren und Doku auf den Stand der neuen Stacks (Jellyfin/Plex/...) nachziehen.
-
----
-
-## 1. Methodik und Quellen
-
-Diese Audit-Quellen wurden gelesen (repo-seitig):
-
-- `HOMELAB_ARCHITECTURE_MASTER_V2.md`
-- `docs/WORKFLOW.md`
-- `docs/REPO_MAP.md`
-- `docs/SERVICE_CATALOG.md`
-- `docs/RESTORE_MATRIX.md`
-- `docs/GITOPS_DRIFT_RUNBOOK.md`
-- `docs/NEXT_SPRINT_TODO_2026-05-16.md`
-- `ops/borg-ui/scripts/pre-backup-dumps.sh`
-- `ops/borg-ui/docker-compose.yml`
-- `ops/borg-ui/all-important-sources.txt`
-- `ops/filebrowser/docker-compose.yml`
-- `security/authelia/configuration.yml`
-- `core/gitea/docker-compose.yml`
-- `apps/jellyfin/docker-compose.yml`
-- `host-services/plex/docker-compose.yml`
-- `ops/policy-checks/last-report.md`
-
-Schreibbefehle: keine. Deploys: keine. Containerlaufzeit, Komodo-Webhook-Status, Borg-Lauf-Frische und Host-Listener wurden bewusst nicht angetastet — dafuer steht der Live-Daten-Block in Abschnitt 9.
-
----
-
-## 2. Schicht A — GitOps und Konsistenz
-
-### 2.1 Lokaler Clone vs. `origin/master`
-
-```
-## master...origin/master [ahead 1]
-HEAD          = cd650b19ac057a1b74ac63503e5dba50eaf5b8ea
-origin/master = af231dd4e835b19005cc0842509199d480af00d9
-```
-
-- **Befund:** Lokaler Clone ist 1 Commit voraus.
-- **Commit:** `cd650b1 Close Gitea signup, dedup posture-check alerts, extend Borg scope` (Sat May 23 11:01:24 2026 +0200).
-- **Inhalt** (laut Commit-Message und betroffenen Dateien):
-  - Gitea: `DISABLE_REGISTRATION=true`, `ENABLE_OPENID_SIGNIN=false`, `ENABLE_OPENID_SIGNUP=false`
-  - Repo-Pflicht-Doku ergaenzt: Komodo-Stack-Webhook-Pflicht in `CLAUDE.md`, `AI_CONTEXT.md`, `WORKFLOW.md`
-  - `posture-check.sh`: Disk1-NTFS-Funktion ausgelagert, Inode-Check auf NTFS uebersprungen, ntfy-Dedup via Fingerprint-State + `ALERT_REPEAT_SECONDS`
-  - `docker-critical-events.sh`: JSON-Parsing, `die exit=0` gefiltert, strukturierte ntfy-Message
-  - `borg-ui`: `/mnt/user/services` als `/local/services:ro` gemountet, `all-important-sources.txt` ergaenzt
-  - Unraid User Scripts dokumentiert (daily report)
-  - `MIGRATION_LOG.md`, `RESTORE_MATRIX.md`, `DISASTER_RECOVERY.md` aktualisiert
-- **Risiko:** Bei Verlust des Windows-Clones (Reinstall, Diskcrash) ist dieser Stand verloren, weil er nicht in Gitea liegt. Komodo deployt ausserdem aus Gitea und kennt diese Aenderungen noch nicht.
-- **Empfohlene Aktion (Pflicht vor weiterer Arbeit):** In GitHub Desktop `Push origin` ausfuehren. Danach Komodo-Reaktion fuer die betroffenen Stacks (`gitea`, `borg-ui`) pruefen und Smoke-Tests laufen lassen.
-
-### 2.2 Working-Tree-Status
-
-```
-$ git status --short
- M CLAUDE.md
- M HOMELAB_ARCHITECTURE_MASTER_V2.md
- M apps/homepage/docker-compose.yml
- ...
-(47 Dateien als modified gemeldet, plus 4 Untracked)
-```
-
-- **Bewertung:** Die 47 "modified files" sind mit hoher Wahrscheinlichkeit **Mount-Artefakte** durch CRLF/LF zwischen Windows-Clone und Linux-Mount. Stichprobe `git diff -w --stat CLAUDE.md HOMELAB_ARCHITECTURE_MASTER_V2.md` lieferte leer — d. h. keine inhaltlichen Diffs.
-- **Aktion:** Bitte am Windows-Host in GitHub Desktop `git status --short` ausfuehren. Wenn dort der Tree leer ist (nur die 4 Untracked), gibt es keinen echten Working-Tree-Drift. Wenn dort echte Diffs erscheinen, hier bitte zurueckmelden — dann ist das ein eigener Befund.
-- **Optional (nicht Pflicht):** `.gitattributes` mit `* text=auto eol=lf` haerten, damit dieser Mount-Effekt fuer KI-Audits aus dem Weg geht. Das ist ein eigener kleiner Commit, kein Audit-Output.
-
-### 2.3 Untracked Files
-
-```
-?? .serena/
-?? ops/windows-reinstall/backup-delta-after-2026-05-07.ps1
-?? ops/windows-reinstall/cleanup-dualboot-bcd.ps1
-?? ops/windows-reinstall/repair-disk0-boot-to-new-windows.ps1
-```
-
-- `.serena/` ist das Working-Directory des Serena Code-Search-Tools. Hat eigene `.gitignore` intern, aber das `.serena/`-Verzeichnis selbst ist nicht in der Repo-`.gitignore`.
-- **Aktion (klein):** `.serena/` in `.gitignore` aufnehmen, damit es nicht versehentlich committet wird.
-- Die drei PowerShell-Scripts unter `ops/windows-reinstall/` sind Windows-Reinstall-Helfer. Entscheidung offen: ins Repo aufnehmen (mit Kontextkommentar warum sie dort liegen) oder lokal halten und in `.gitignore` aufnehmen. Vorschlag: aufnehmen, weil `ops/` der dokumentierte Ort fuer Ops-Skripte ist.
-
-### 2.4 Letzte Commit-Historie (Top 10)
-
-```
-cd650b1 Close Gitea signup, dedup posture-check alerts, extend Borg scope    [LOKAL, NICHT GEPUSHT]
-af231dd Fix zero-count noise pattern handling
-428223d Mark posture report scripts executable
-b6d3ed4 Tune homelab availability alerts
-9e7bebb Add daily operations report with hardened log-noise filtering
-b7cbbe5 Fix Jellyfin external DNS
-71ac18b Fix Jellyfin native auth routing
-90f270b Fix Jellyfin config permissions
-e28f8da Add Jellyfin media server stack
-edfec5b Add Plex media server stack
-```
-
-- Die letzten Tage waren sichtbar: Jellyfin/Plex hinzugefuegt, Availability-Alerts feinjustiert, Posture-Check-Skripte produktiv gemacht, dann der grosse Haertungs-Commit gestern (2026-05-23 11:01).
-
-### 2.5 Compose-Inventar vs. Doku
-
-Repo hat folgende Compose-Stacks, die in den Doku-Quellen (`HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md`) **nicht oder nur teilweise** aufgefuehrt sind:
-
-| Stack | Status im Repo | Status in Master-Doku |
-|---|---|---|
-| `apps/jellyfin/docker-compose.yml` | produktiv vorhanden, gepinnt `jellyfin:10.11.8@sha256:...`, Traefik `jellyfin.kaleschke.info`, `secure-headers@file`, native Auth, `/mnt/user/media:ro` + `/mnt/user/photos:ro` | **fehlt** in 7.4 Apps; Authelia-ACL kennt aber bereits `jellyfin.kaleschke.info` als bypass — Doku hinkt hinterher |
-| `host-services/plex/docker-compose.yml` | produktiv vorhanden, gepinnt `plexinc/pms-docker:1.43.1.10611-1e34174b1@sha256:...`, `network_mode: host`, `/mnt/user/media:ro` + `/mnt/user/photos:ro` | Master-Doku sagt explizit "Plex-Media-Server ist historischer Host-Sonderfall, nicht als Repo-Compose-Stack enthalten" — **das stimmt nicht mehr**, Plex ist jetzt ein Repo-Compose-Stack |
-| `host-services/docker/` | leeres Verzeichnis | nicht erwaehnt |
-| `infra/dns/` | leeres Verzeichnis | nicht erwaehnt |
-| `ops/Semaphore/` | Skripten/Playbooks aber kein Compose | nicht erwaehnt |
-| `ops/backrest/` | leeres Verzeichnis (Stack laut Master-Doku am 2026-05-15 entfernt) | korrekt als entfernt dokumentiert; Verzeichnis sollte leer bleiben oder weg |
-| `apps/firefly/`, `apps/firefly-fints/` | leere Verzeichnisse | nicht erwaehnt |
-| `apps/stirling-pdf/` | leeres Verzeichnis (durch `bentopdf` abgeloest) | korrekt als abgeloest dokumentiert |
-
-- **Aktion (Doku-Synchronisierung):** `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 7 (Container-Zielbild), `docs/SERVICE_CATALOG.md` und `docs/REPO_MAP.md` um Jellyfin und Plex erweitern. Plex-Doku im Master umschreiben: nicht mehr "historisch ausserhalb Repo", sondern "Compose-Stack mit `network_mode: host` als VPN-Discovery-Ausnahme".
-- **Aktion (Repo-Hygiene):** Die leeren Verzeichnisse `apps/firefly`, `apps/firefly-fints`, `apps/stirling-pdf`, `host-services/docker`, `infra/dns`, `ops/backrest`, `ops/grafana-influxdb/scripts`, `ops/Semaphore/playbooks`, `ops/Semaphore/Scripts` aufraeumen — Master-Doku sagt: "Leere `.keep`-Platzhalter wurden entfernt; neue Verzeichnisse sollen erst mit konkretem Inhalt ins Repo." Diese Verzeichnisse verletzen diese Regel passiv.
-
-### 2.6 Image-Pinning
-
-Lt. `docs/NEXT_SPRINT_TODO_2026-05-16.md` sind diese Stacks noch nicht voll versioniert gepinnt:
-- `ddns-updater` — `latest...@sha256`
-- `glances` — `latest-full@sha256`
-- `scrutiny` — `latest-omnibus@sha256`
-
-Das ist bewusst dokumentiert und kein Audit-Befund.
-
----
-
-## 3. Schicht B — Hardening-Sprint 2026-05 (Sitrep)
-
-Dies war der Sprint, der nach dem 2026-05 Restore explizit gesetzt wurde. Stand im Repo:
-
-| Sprint-Item | Stand 2026-05-16 (Plan) | Stand 2026-05-23 (Repo) | Beleg |
-|---|---|---|---|
-| **(1) Backup-Konsistenz** — `dump_sqlite_container` fuer Gitea/Vaultwarden/Uptime-Kuma/Speedtest/Filebrowser + `pg_dump` Nextcloud | offen | ✅ erledigt | `ops/borg-ui/scripts/pre-backup-dumps.sh` Z. 97–139 (`dump_sqlite_container`), Z. 253–258 (Nextcloud `pg_dump`), Z. 261–264 (alle SQLite-Container mit Host-Fallback), Z. 267 (Filebrowser BoltDB). Borg-Scope erweitert um `/mnt/user/services` (Borg-UI Compose Z. 26 + `all-important-sources.txt` Z. 23–25). |
-| **(2) Filebrowser entschaerfen** — `/mnt/user/appdata:/srv/appdata` weg, gezielte RW-Subpfade | offen | ✅ erledigt | `ops/filebrowser/docker-compose.yml` Z. 11–16. Keine Appdata-Mounts mehr. Nur noch `/mnt/user/documents`, `/mnt/user/photos`, `/mnt/user/projekte` als Datenmounts plus eigener `/database` und `/config`. |
-| **(3) Authelia Argon2id haerten** — iterations 3, memory 65536, parallelism 4 | offen | ✅ erledigt | `security/authelia/configuration.yml` Z. 17–25. Exakt die geplanten Parameter sind aktiv. |
-| **(4) Gitea Webhook-Allowlist** — `ALLOWED_HOST_LIST=*` einschraenken | offen | ✅ erledigt | `core/gitea/docker-compose.yml` Z. 18: `GITEA__webhook__ALLOWED_HOST_LIST=komodo-core,localhost,127.0.0.1,192.168.178.0/24`. Zusatz aus heutigem Commit: Public Registration und OpenID-Signup/Signin sind deaktiviert. |
-
-Alle vier Items sind **im Repo abgeschlossen**. Live-Wirksamkeit haengt am Komodo-Deploy aus Gitea — und genau da haengt aktuell der ungepushte Commit `cd650b1` davor (siehe 2.1). Solange er nicht in Gitea ist, ist insbesondere die Gitea-Signup-Schliessung im Live-Stand nicht garantiert.
-
-**Bewusst nicht angefasste Liste (Operator-Entscheidung 2026-05-16) ist weiterhin gueltig:**
-- Hermes — bleibt VM-seitig offen, NAS-Stack bewusst nicht starten
-- Disk1 NTFS — Phase-2-Migration nach Plan
-- Komodo native Auth ohne ForwardAuth
-- Grafana/Influxdb3-core `user: "0"`
-- Image-Pinning-Vereinheitlichung (`:latest@sha256:`) fuer ddns-updater/glances/scrutiny
-
----
-
-## 4. Schicht C — "Endstufe?"-Bewertung
-
-### 4.1 Backup/Restore-Readiness
-
-- **Dump-Coverage:** `pre-backup-dumps.sh` deckt 14 Quellen ab: PostgreSQL-Globals + 3 Shared-DBs + 3 dedizierte Postgres (mealie, immich, nextcloud) + 4 SQLite (gitea, vaultwarden, uptime-kuma, speedtest-tracker) + Filebrowser-BoltDB + Borg-UI + Grafana + Komodo-Mongo. Deckt 1:1 die Restore-Matrix-Eintraege ab.
-- **Borg-Scope:** `all-important-sources.txt` enthaelt 27 Eintraege inkl. neuer `services/homelab-infra`, `services/stacks`, `services/posture-check` und `secrets`.
-- **Restore-Validierungen:** Laut `docs/RESTORE_MATRIX.md` sind am 2026-05-07 Mini-Restores fuer `gitea`, `vaultwarden` und `paperless` validiert worden — dokumentierter Stand.
-- **Live offen:** Wann lief der letzte Borg-Lauf? Sind alle Dumps unter `/mnt/user/backups/borg/dumps/latest` frischer als 24h? Siehe Live-Checkliste 9.4.
-
-### 4.2 Monitoring-Migration
-
-- Repo-Zielzustand `monitoring/docker-compose.yml` (337 Zeilen Compose) existiert mit Prometheus, Alertmanager, ntfy-Bridge, Blackbox-Exporter, Loki, Promtail, Grafana, node-exporter, cAdvisor, InfluxDB3 Core.
-- Provisioning unter `monitoring/grafana/provisioning/` und `monitoring/prometheus/`, `monitoring/loki/`, `monitoring/promtail/`, `monitoring/alertmanager/`, `monitoring/blackbox/` vollstaendig vorhanden.
-- Alte Stacks `ops/grafana-influxdb/` und `ops/loki/` bewusst noch im Repo (dokumentierter Altstand, Rollback-Referenz).
-- **Live offen:** Ist `monitoring` schon als Komodo-Stack deployed? Laufen die Container? Sind die Secret-Dateien `monitoring_grafana_admin_password.txt`, `monitoring_grafana_influxdb_token.txt`, `influxdb3_admin_token.json` auf dem Host? Siehe Live-Checkliste 9.5.
-
-### 4.3 Repo-Hygiene
-
-| Befund | Schwere | Aktion |
-|---|---|---|
-| 8 leere Verzeichnisse (`apps/firefly`, `apps/firefly-fints`, `apps/stirling-pdf`, `host-services/docker`, `infra/dns`, `ops/backrest`, `ops/grafana-influxdb/scripts`, `ops/Semaphore/playbooks`, `ops/Semaphore/Scripts`) | klein | Aufraeumen, danach committen |
-| `.serena/` untracked, nicht in `.gitignore` | klein | `.serena/` zu `.gitignore` hinzufuegen |
-| 3 `ops/windows-reinstall/*.ps1` untracked | klein | Entscheidung treffen: ins Repo oder ignorieren |
-
-### 4.4 Bekannte dokumentierte Ausnahmen
-
-Aus `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 10 — alle weiterhin gueltig und durch den Policy-Check abgedeckt (`ops/policy-checks/last-report.md` 0 Critical):
-
-- Traefik 80/443
-- Tailscale Host-Netz + Capabilities
-- AdGuard Port 53 + 8082 (Admin-Port LAN-only, dokumentiert; **offener Punkt im Master:** "Traefik-Absicherung ausstehend (Block F)" — bewusst spaeter)
-- Plex Host-Netz (aber Master-Doku-Eintrag jetzt falsch, siehe 2.5)
-- Scrutiny `privileged: true`
-- Komodo Docker-Socket + keine pauschale Middleware
-- glance-docker-socket-proxy Read-only Socket
-- Gitea SSH 222
-- ddns-updater `frontend_net`
-- mail-archiver Hybrid-Netze
-- `traefik/dynamic/*` manueller Host-Sync
-- nextcloud native Auth
-- monitoring-influxdb3-core LAN 8181 + `user: "0"`
-- monitoring-promtail Docker-Socket read-only
-
-Keine ungeplanten neuen Ausnahmen.
-
-### 4.5 Endstufen-Definition
-
-"Endstufe" ist erreicht, wenn alle folgenden Punkte gruen sind:
-
-1. **Gitea = Quelle der Wahrheit** — kein lokaler Commit ohne Push 🟡 (heute: `cd650b1` ungepusht)
-2. **Hardening-Sprint im Repo abgeschlossen** 🟢
-3. **Backup-Konsistenz live verifiziert (Borg laeuft, Dumps frisch)** ❓ Live
-4. **Monitoring-Stack live, alte Altstaende gestoppt** 🟡
-5. **Doku synchron mit Repo (Jellyfin/Plex, leere Verzeichnisse, ...)** 🟠
-6. **Policy-Check 0 Critical** 🟢 (4 Warnings sind dokumentierte Ausnahmen)
-7. **Restore-Lab gepflegt (`mail-archiver` als naechste Uebung empfohlen)** 🟡 dokumentiert offen
-
-Sechs der sieben Punkte sind in Reichweite ohne neue Architekturentscheidungen. Punkt 3 und 4 brauchen Live-Daten (Abschnitt 9). Punkt 1 ist 1 Push entfernt.
-
----
-
-## 5. Priorisierte Restliste
-
-| Prio | Aktion | Begruendung | Aufwand |
-|---|---|---|---|
-| **P0** | `cd650b1` nach Gitea pushen | GitOps-Quelle-der-Wahrheit, Voraussetzung fuer alles weitere | 30 Sekunden |
-| **P0** | Live-Daten aus Abschnitt 9 einholen | Ohne Live-Frische ist Endstufen-Bewertung unvollstaendig | 5 Minuten |
-| **P1** | Monitoring-Stack live finalisieren (Secrets pruefen, deployen, Smoke-Test, alte Altstaende stoppen) | Aus `docs/NEXT_SPRINT_TODO_2026-05-16.md` der naechste produktive Schritt | 1–2 Stunden mit Tests |
-| **P2** | Doku-Drift schliessen: Jellyfin und Plex in `HOMELAB_ARCHITECTURE_MASTER_V2.md` 7.4 + 7.1, `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md` ergaenzen; Plex-Eintrag in Abschnitt 7.7 "noch offene Sonderfaelle" entfernen (ist umgesetzt) | Doku ist Source of Truth fuer KI-Audits und Nachfolge | 30 Minuten |
-| **P2** | Home Assistant -> InfluxDB final testen, HA-Dashboard in `monitoring-grafana` anlegen | aus NEXT_SPRINT_TODO | 1–2 Stunden |
-| **P3** | Repo-Hygiene: 8 leere Verzeichnisse loeschen, `.serena/` in `.gitignore`, Entscheidung zu `ops/windows-reinstall/*.ps1` | minor, aber dokumentiert | 15 Minuten |
-| **P3** | Naechster Restore-Lab-Lauf: `mail-archiver` (empfohlen in `RESTORE_MATRIX.md`) | Restore-Routine ueben, bevor sie gebraucht wird | 1 Stunde |
-| **P4** | `.gitattributes` mit `* text=auto eol=lf` hinzufuegen, um CRLF/LF-Mount-Effekte bei KI-Audits zu vermeiden | klein, kosmetisch fuer kuenftige Audits | 5 Minuten |
-| **bleibt** | Hermes VM-Seite, Disk1-NTFS Phase 2, AdGuard Admin-Port hinter Traefik (Block F), Image-Pinning ddns/glances/scrutiny | bewusste Operator-Entscheidung, kein Audit-Beduerfnis | nicht jetzt |
-
----
-
-## 6. Was bewusst NICHT angetastet wurde (Audit-Verzicht)
-
-Konsistent mit der bekannten Nicht-Anfassen-Liste:
-
-- Hermes (VM-seitig offen)
-- Disk1 NTFS (Phase-2-Migration nach Plan)
-- Komodo native Auth ohne ForwardAuth
-- Grafana / influxdb3-core `user: "0"` Uebergangsausnahme
-- Image-Pinning-Vereinheitlichung fuer ddns-updater/glances/scrutiny
-
----
-
-## 7. Risiken und Drift-Indikatoren
-
-| Risiko | Wahrscheinlichkeit | Wirkung | Migitation |
-|---|---|---|---|
-| Lokaler Clone-Verlust (Disk, Reinstall) bevor `cd650b1` gepusht wurde | gering, aber real (Du bist im Reinstall-Kontext, siehe `ops/windows-reinstall/`!) | Verlust von Gitea-Signup-Closure und Posture-Check-Verbesserungen | **Sofort pushen** |
-| Komodo deployt aus Gitea, `gitea` und `borg-ui` laufen aktuell ohne die heutigen Verbesserungen | mittel | Gitea Signup steht noch offen, Borg-Scope umfasst `/mnt/user/services` noch nicht | Push + Komodo-Reaktion pruefen |
-| 47 vermeintlich modified files koennten doch echte Diffs sein, wenn der Windows-Host etwas anderes zeigt | gering | falsche Audit-Aussage | Punkt 9.1 auf dem Windows-Host pruefen |
-| Doku-Drift wird groesser, wenn weitere Stacks ohne Doku-Update hinzukommen | mittel | KI-Audits und Onboarding leiden | P2-Doku-Sync nicht aufschieben |
-| Monitoring-Stack-Migration unfertig, alter und neuer Stack koennten parallel werden | mittel | Doppelte Metric-/Log-Pipeline, Verwirrung bei Diagnose | Live-Status klaeren bevor Deploy |
-
----
-
-## 8. Sources of Truth — Schnellzugriff
-
-- Operative Quelle der Wahrheit: Gitea `origin/master` (https://git.kaleschke.info/Micha/homelab-infra)
-- Architektur-Master: `HOMELAB_ARCHITECTURE_MASTER_V2.md`
-- Workflow / GitOps-Regeln: `docs/WORKFLOW.md`
-- Drift-Runbook: `docs/GITOPS_DRIFT_RUNBOOK.md`
-- Restore-Quellen: `docs/RESTORE_MATRIX.md`, `docs/DISASTER_RECOVERY.md`
-- Letzter Policy-Check: `ops/policy-checks/last-report.md` (0 Critical)
-- Letzte Sprint-Restliste: `docs/NEXT_SPRINT_TODO_2026-05-16.md`
-
----
-
-## 9. Live-Daten-Checkliste — bitte ausfuehren und zurueckspielen
-
-Fuehre die folgenden Bloecke am Unraid-Host (per SSH oder Web-Terminal) und am Windows-Host (Git Bash / PowerShell in `G:\Gitea_Clone\homelab-infra`) aus und pastiere die Outputs zurueck. Ich integriere sie dann in diesen Report.
-
-### 9.1 Windows-Host: Echter Working-Tree-Status
-
-```powershell
-cd G:\Gitea_Clone\homelab-infra
-git status --short
-git log origin/master..HEAD --oneline
-```
-
-Erwartet: Working tree leer (oder nur die 4 Untracked). `cd650b1` als einziger lokaler Commit.
-
-### 9.2 Unraid-Host: Gitea online
-
-```bash
-curl -sI --max-time 5 https://git.kaleschke.info/ | head -5
-docker exec gitea sh -lc 'gitea --version'
-```
-
-Erwartet: `HTTP/2 200` (oder ein Auth-Code, der den Erreichbarkeitstest erfuellt). Gitea-Version stimmt mit Image-Tag `1.25.4` ueberein.
-
-### 9.3 Unraid-Host: Komodo-Webhook-Status
-
-In Komodo UI fuer jeden produktiven Stack aus `Micha/homelab-infra` pruefen:
-- `webhook_enabled: true`
-- Gitea-Hook auf `http://komodo-core:9120/listener/github/stack/<stack-id>/deploy` aktiv
-- `last_status` der letzten Webhook-Delivery in Gitea (Repository -> Settings -> Webhooks)
-
-Pflicht-Stacks zum Pruefen: `traefik`, `gitea`, `authelia`, `vaultwarden`, `postgresql17`, `redis`, `paperless-ngx`, `immich`, `nextcloud`, `mealie`, `mail-archiver`, `ntfy`, `homepage`, `paperless-gpt`, `borg-ui`, `filebrowser`, `code-server`, `uptime-kuma`, `glance`, `glances`, `scrutiny`, `speedtest-tracker`, `bentopdf`, `ddns-updater`, `komodo`, `jellyfin`, `plex`, `adguard`, `tailscale`, `monitoring`, `hermes-agent` (sofern produktiv).
-
-Bei Stacks **ohne** aktiven Webhook bitte den Grund vermerken (dokumentierte Ausnahme oder Nachholbedarf).
-
-### 9.4 Unraid-Host: Borg-Lauf-Frische und Dump-Coverage
-
-```bash
-ls -lah /mnt/user/backups/borg/dumps/latest/
-stat -c '%y %n' /mnt/user/backups/borg/dumps/latest/*.dump /mnt/user/backups/borg/dumps/latest/*.sql /mnt/user/backups/borg/dumps/latest/*.archive.gz /mnt/user/backups/borg/dumps/latest/*.sqlite 2>/dev/null | sort
-docker exec borg-ui borg list --short 2>&1 | tail -10
-```
-
-Erwartet: Alle 14 Artefakte aus 4.1 sind vorhanden, mtime juenger als 24h. Borg-Archive-Liste zeigt regelmaessige Laeufe.
-
-### 9.5 Unraid-Host: Monitoring-Stack live?
-
-```bash
-docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}" | grep monitoring
-ls -la /mnt/user/appdata/secrets/ | grep -E 'monitoring|influxdb3'
-curl -sI --max-time 5 https://monitoring.kaleschke.info/ | head -5
-ss -ltnp 2>/dev/null | grep -E ':8181|:9090|:3100' | head -10
-```
-
-Erwartet: Entweder alle `monitoring-*` Container laufen (dann ist 4.2 🟢) oder gar nicht (dann ist 4.2 🟡 wie aktuell bewertet). Halb-Zustand ist ein Audit-Befund.
-
-### 9.6 Unraid-Host: GitOps-Pflichtmatrix Spot-Check fuer einen Stack
-
-Beispiel `gitea` (weil der heutige Commit ihn betrifft):
-
-```bash
-cd /mnt/user/services/stacks/gitea
-git rev-parse --short HEAD
-git status -sb
-docker inspect gitea --format '{{.Image}}'
-docker exec gitea sh -lc 'env | grep -E "ALLOWED_HOST_LIST|DISABLE_REGISTRATION|ENABLE_OPENID"'
-```
-
-Erwartet: Komodo-Workspace `HEAD` zeigt entweder auf `cd650b1` (wenn Push schon erfolgt + Komodo deployed) oder auf `af231dd` (vor dem Push). ENV-Vars in der Live-Runtime spiegeln den Commit, der Komodo zuletzt deployed hat.
-
-### 9.7 Unraid-Host: Host-Listener-Spot-Check
-
-```bash
-ss -ltnp 2>/dev/null | grep -E ':80|:443|:53|:222|:8082|:8181' | sort
-```
-
-Erwartet exakt die dokumentierten Ausnahmen aus `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 10. Andere Listener = Befund.
-
----
-
-## 10. Nachhalte-Vorschlag
-
-Wenn Du moechtest, halte ich diesen Audit in zwei Schritten zu Ende:
-
-1. Du fuehrst Abschnitt 9 aus und pastierst die Outputs zurueck.
-2. Ich aktualisiere diesen Report mit den Live-Ergebnissen, ergaenze die Ampel und schliesse die offenen 🟡/🟠 Punkte oder benenne sie als echte Restliste.
-
-Bis dahin gilt der Stand dieses Reports als Repo-Audit, nicht als Endstufen-Zertifikat.

docs/AUDIT_2026-05-23_FINAL.md

@@ -1,22 +0,0 @@
-# Homelab Audit Final - 2026-05-23
-
-Stand: 2026-05-25 07:33 CEST. Ergebnis nach Push, Live-Messung, Doku-Sync, Repo-Hygiene und erneuter Live-Nachmessung.
-
-| Punkt | Ampel | Beleg |
-|---|---|---|
-| P0 `cd650b1` nach Gitea pushen | gruen | Push `af231dd..cd650b1 master -> master`; produktiver Runtime-Stand `66ee10c` enthaelt `cd650b1`. Die abschliessenden Audit-Doku-Commits liegen in Gitea; der runtime-relevante Stack-Inhalt fuer `gitea`, `borg-ui` und `monitoring` ist seit `66ee10c` unveraendert. |
-| P0 Live-Daten ablegen | gruen | `docs/AUDIT_2026-05-23_LIVE.md` angelegt, keine Secret-Werte dokumentiert. |
-| P1 Monitoring live / Altstaende down | gruen | 10 `monitoring-*` Container laufen, `0` unhealthy, `0` starting, `0` stopped; alte `grafana`/`influxdb3-core`/`loki`/`alloy` Container sind nicht vorhanden. `monitoring.kaleschke.info` liefert 302 zu Authelia, Prometheus ist bereit, Loki `/ready` liefert `ready`. |
-| P1 Jellyfin/Plex Doku | gruen | `HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/SERVICE_CATALOG.md` und `docs/REPO_MAP.md` ergaenzt; Plex ist als Repo-Compose-Stack dokumentiert, nicht mehr als nicht migrierter Dockerman-Sonderfall. |
-| P2 Borg-Frische | gruen | Borg-UI DB: letzter Backup-Job `completed`, Archiv `Taegliche-Sicherung-2026-05-25T05:52:44.157`, `nfiles=100221`; 15 kanonische Dump-/Archive-Artefakte von 2026-05-25 06:09/06:10 CEST und damit juenger als 24 h. |
-| P3 Repo-Hygiene | gruen | `.serena/` in `.gitignore`; leere Verzeichnisse entfernt; `ops/windows-reinstall/*.ps1` bewusst ins Repo aufgenommen. |
-| Policy-Check | gruen | `ops/policy-checks/check_repo.ps1`: 0 Critical, dokumentierte Warnings zu Plex Host-Netz, InfluxDB/Grafana `user: "0"` und bekannten mutable-tag-Ausnahmen. |
-
-## Bewusst offen
-
-- Keine offenen Punkte aus der Audit-Restliste.
-- Nicht Teil des Audits: Nach Disk1 Phase 2 laeuft seit 2026-05-25 eine nicht korrigierende Parity-Pruefung (`NOCORRECT`) im Hintergrund; Zwischenstand der Nachmessung: `mdResyncAction=check P`, `mdResyncCorr=0`.
-
-## Schlussbewertung
-
-Das Homelab ist fuer die Audit-Restliste in der Endstufe. Es gibt keine kritischen Repo-, GitOps- oder Live-Befunde aus diesem Audit. Monitoring ist produktiv und ready, alte Altstaende sind down, Backups und Dumps sind frisch.

docs/AUDIT_2026-05-23_LIVE.md

@@ -1,88 +0,0 @@
-# Homelab Audit Live-Daten - 2026-05-23
-
-Stand: 2026-05-23 11:27 CEST. Quelle: lokaler Windows-Clone und SSH auf `Kallilabcore`. Secret-Werte wurden nicht ausgelesen oder redaktiert; dokumentiert sind nur Status, Dateinamen, Modi, Env-Key-Namen und nicht geheime Bool-/Host-Werte.
-
-## 9.1 Windows-Host / Git
-
-- `git status --short` nach dem initialen Push: keine tracked Modifikationen, untracked waren `.serena/`, `docs/AUDIT_2026-05-23.md`, `docs/CODEX_ENDSTUFE_PROMPT_2026-05-23.md` und drei `ops/windows-reinstall/*.ps1`.
-- `cd650b1` wurde nach `origin/master` gepusht: `af231dd..cd650b1 master -> master`.
-
-## 9.2 Gitea online
-
-- `curl -sI https://git.kaleschke.info/`: `HTTP/2 200`.
-- `docker exec gitea gitea --version`: `1.25.4`.
-- Signup-Smoke: `/user/sign_up` meldet Registration disabled.
-
-## 9.3 Komodo / Workspace-Reaktion
-
-| Stack | Workspace HEAD | Status | Live-Beleg |
-|---|---:|---|---|
-| `gitea` | `cd650b1` | `## master...origin/master` | Container neu gestartet, Env-Keys aktiv |
-| `borg-ui` | `cd650b1` | `## master...origin/master` | Container healthy, `/mnt/user/services -> /local/services` gemountet |
-| `monitoring` | `cd650b1` | `## master...origin/master`, untracked Host-Backup `monitoring/prometheus/alerts.yml.bak-20260520-incident` | Stack laeuft seit 4 Tagen |
-
-Gitea Live-Env ohne Secrets:
-
-```text
-GITEA__service__DISABLE_REGISTRATION=true
-GITEA__openid__ENABLE_OPENID_SIGNIN=false
-GITEA__openid__ENABLE_OPENID_SIGNUP=false
-GITEA__webhook__ALLOWED_HOST_LIST=komodo-core,localhost,127.0.0.1,192.168.178.0/24
-```
-
-## 9.4 Borg-Lauf-Frische und Dump-Coverage
-
-- Borg UI DB: Repository `appdata-critical`, `last_backup=2026-05-23 02:30:12 UTC`, `archive_count=30`, letzter Job `completed`, `nfiles=100056`.
-- Schedule: `Taegliche Sicherung` enabled, letzter Lauf `2026-05-23 02:30:11 UTC`, naechster Lauf `2026-05-24 02:30:00 UTC`.
-- Hinweis: `docker exec borg-ui borg list --short` funktioniert ohne Repository-Parameter/Env nicht (`Invalid location format: ""`). Der Borg-UI-Status wurde deshalb ueber die lokale Borg-UI-Datenbank ohne Secret-Spalten ausgewertet.
-
-Frische Artefakte in `/mnt/user/backups/borg/dumps/latest`:
-
-```text
-2026-05-23 04:00 postgresql17-globals.sql
-2026-05-23 04:00 postgresql17-mailarchiver.dump
-2026-05-23 04:00 postgresql17-paperless.dump
-2026-05-23 04:01 postgresql17-authelia.dump
-2026-05-23 04:01 mealie.dump
-2026-05-23 04:01 gitea.sqlite.dump
-2026-05-23 04:01 immich.dump
-2026-05-23 04:01 nextcloud.dump
-2026-05-23 04:01 uptime-kuma.sqlite.dump
-2026-05-23 04:01 vaultwarden.sqlite.dump
-2026-05-23 04:01 speedtest-tracker.sqlite.dump
-2026-05-23 04:01 filebrowser.bolt.dump
-2026-05-23 04:01 borg-ui.sqlite
-2026-05-23 04:01 grafana.sqlite
-2026-05-23 04:01 komodo-mongo.archive.gz
-```
-
-Bewertung: 15 aktuelle Dump-/Archive-Artefakte sind juenger als 24 h. Aeltere nackte `.sqlite`-Dateien vom 2026-05-16 liegen noch im Verzeichnis, sind aber Legacy-Kopien ohne `.dump`-Suffix und nicht Teil der aktuellen Dump-Serie.
-
-## 9.5 Monitoring-Stack
-
-- Aktive Container: `monitoring-grafana`, `monitoring-promtail`, `monitoring-prometheus`, `monitoring-cadvisor`, `monitoring-influxdb3-core`, `monitoring-loki`, `monitoring-blackbox-exporter`, `monitoring-alertmanager-ntfy-bridge`, `monitoring-alertmanager`, `monitoring-node-exporter`.
-- Alte Altcontainer `grafana`, `influxdb3-core`, `loki`, `alloy`: nicht vorhanden in `docker ps -a`.
-- Secret-Dateien vorhanden und mode `600`: `monitoring_grafana_admin_password.txt`, `monitoring_grafana_influxdb_token.txt`, `influxdb3_admin_token.json`.
-- `https://monitoring.kaleschke.info/`: `HTTP/2 302` zu Authelia, wie erwartet.
-- Host-Listener fuer Monitoring: nur `127.0.0.1:8181`; keine Host-Listener fuer `:9090` oder `:3100`.
-- Prometheus readiness: `Prometheus Server is Ready.`
-- Grafana health: `database=ok`, Version `12.4.3`.
-- Loki: Container laeuft und API/metrics liefert `loki_build_info`; `/ready` liefert aktuell `503 Service Unavailable`, waehrend Query-/Metrics-Endpunkte 200-Zaehler zeigen. Kein Reparaturversuch gestartet, weil der produktive Logpfad nachweislich Daten annimmt und die Stop-Regel keine blinden Eingriffe erlaubt.
-
-## 9.6 GitOps Spot-Check Gitea
-
-- `/mnt/user/services/stacks/gitea`: `cd650b1`, `## master...origin/master`.
-- Docker-Image: `docker.gitea.com/gitea:1.25.4`.
-- Live-ENV spiegelt `cd650b1` fuer Registrierung, OpenID und Webhook-Allowlist.
-
-## 9.7 Host-Listener
-
-Dokumentierte Listener gefunden:
-
-- `:80`, `:443` Traefik
-- `:53` AdGuard DNS
-- `:222` Gitea SSH
-- `:8082` AdGuard Admin
-- `127.0.0.1:8181` Monitoring InfluxDB
-
-Zusaetzlich sichtbar: mehrere `wsdd2` Listener auf `:5355` je Interface. Das ist Host-/Unraid-Service-Discovery, kein Compose-Webdienst und kein GitOps-Stack-Port.

docs/AUDIT_2026-05-25.md

@@ -1,895 +0,0 @@
-# Homelab-Audit KalliLab CORE
-
-Stand: 2026-05-25
-Methode: Repo-basierter Audit auf `master` (lokaler Clone). Keine Live-Messung gegen den Host. Querverweise auf Audit-Live-Daten aus `docs/AUDIT_2026-05-23_LIVE.md`, wo verfuegbar.
-Auftrag: externer, kritischer Audit-Blick zusaetzlich zur internen `docs/STRATEGISCHE_BEWERTUNG_2026-05-23.md`.
-
-## Wichtige Vorbemerkung
-
-Es gibt seit dem 23.05. eine fundierte interne Bewertung (`docs/STRATEGISCHE_BEWERTUNG_2026-05-23.md`) und eine konsolidierte Hausaufgabenliste (`docs/CODEX_KONSOLIDIERUNG_2026-05-23.md`). Davon wurden seit dem 25.05. bereits umgesetzt:
-
-- Jellyfin entfernt (MASTER 7.8)
-- Homepage entfernt (MASTER 7.8)
-- Uptime-Kuma entfernt (MASTER 7.8, SECRETS_MAP 29)
-- Monitoring-Stack produktiv (AUDIT_FINAL 9), Altstaende-Container down
-- Disk1 NTFS -> XFS Phase 2 abgeschlossen am 2026-05-25 (STORAGE_LAYOUT 3)
-- Unraid-Flash-Backup live (`unraid-flash-config.tar.gz` im Borg-Lauf)
-- GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` aktiv (DR 10, MASTER 7.1)
-
-Diese geloesten Punkte werden hier nicht wiederholt. Dieser Audit konzentriert sich auf das, was nach dem 23.05.-Sprint **noch offen ist** und auf das, was die strategische Bewertung **nicht oder nur kurz angerissen** hat.
-
----
-
-# Phase 1: Repo-Inventar
-
-## Ordnerstruktur (Ist-Zustand)
-
-```
-homelab-infra/
-├── apps/          9 Stacks (bentopdf, immich, mail-archiver, mealie, nextcloud, ntfy, paperless, paperless-gpt, unbound)
-├── core/          1 Stack (gitea)
-├── docs/          28 Markdown-Dokumente
-├── env/           2 *.example
-├── host-services/ 3 Stacks (Adguard, plex, tailscale)
-├── infra/         3 Stacks (ddns-updater, postgresql17, redis)
-├── monitoring/    1 Compose mit 10 Services + Provisioning
-├── ops/           17 Verzeichnisse (Semaphore, borg-ui, code-server, filebrowser, glance, glances, grafana-influxdb [Altstand], hermes-agent, komodo, loki [Altstand], policy-checks, restore-tests, scrutiny, speedtest, uptime-kuma [Altrest], windows-reinstall)
-├── security/      2 Stacks (authelia, vaultwarden)
-├── services/      1 posture-check (Host-Skripte)
-└── traefik/       1 Compose + dynamic/ (3 Files)
-```
-
-**Inventar-Befund:**
-
-- ~30 Compose-Dateien, 1 zentraler Compose-Multi-Service (`monitoring/`).
-- 29 Composes wurden vom Policy-Checker validiert (`ops/policy-checks/last-report.md`): **0 Critical, 4 Warnings, 9 Info**.
-- Doku-Dichte ist hoch (REPO_MAP, SERVICE_CATALOG, RESTORE_MATRIX, DISASTER_RECOVERY, SECRETS_MAP, WORKFLOW, STORAGE_LAYOUT, GITOPS_DRIFT_RUNBOOK, ALERTING_MAP).
-- Restore-Tests sind als echte Scripts versioniert (`ops/restore-tests/`). Ueberdurchschnittlich.
-
-## Gut dokumentierte Bereiche (Belegt)
-
-| Bereich | Quelle |
-|---|---|
-| Architektur, Netze, Ausnahmen | `HOMELAB_ARCHITECTURE_MASTER_V2.md` |
-| GitOps-Workflow, Drift | `docs/WORKFLOW.md`, `docs/GITOPS_DRIFT_RUNBOOK.md` |
-| Backup-Scope, Restore-Wege, Tier-Modell | `docs/RESTORE_MATRIX.md`, `docs/DISASTER_RECOVERY.md`, `ops/borg-ui/BACKUP_SCOPE.md` |
-| Storage / Cache-Policy / FS / Posture | `docs/STORAGE_LAYOUT.md` (zum Audit-Zeitpunkt noch `docs/STORAGE_LAYOUT.draft.md`) |
-| Secret-Inventur | `docs/SECRETS_MAP.md` |
-| Alert-Pfade | `docs/ALERTING_MAP.md` |
-
-## Luecken / Unklar (vermutet bzw. Rueckfrage noetig)
-
-| Luecke | Warum es ein Audit-Loch ist |
-|---|---|
-| `docs/STORAGE_LAYOUT.draft.md` ist `Draft 1.3`, nicht `Active` | Stand zum Audit-Zeitpunkt 2026-05-25: mehrere Hard Rules (12 Constitution) galten formal noch nicht. Hard Rule 11 (kein Stack ohne Restore-Pfad in RESTORE_MATRIX) wurde schon eingehalten — also nur Formal-Luecke. Folgearbeit: als `docs/STORAGE_LAYOUT.md` Active heben. |
-| `docs/SERVICES_RECOVERY.md` ist als verbindlich angekuendigt (STORAGE_LAYOUT 4), aber nicht im Repo | Konkrete Mirror-Mechanik fuer `services/gitea/git/repositories/` ≤ 6 h ist nirgends spezifiziert. |
-| Hardware-Inventar: kein zentrales Dokument | Keine Stelle im Repo nennt CPU-Modell, RAM-Groesse, NIC-Speed, Mainboard, Parity-Disk-Groessen — nur "Samsung 970 EVO Plus 2 TB" steht in STORAGE_LAYOUT 3. |
-| USV: keine Erwaehnung | Keine Datei nennt eine USV. Unklar, ob vorhanden. |
-| Familien-/User-Onboarding-Doku | Keine Doku, die deine Frau/Kinder lesen muessten ("So loggst du dich in Nextcloud ein"). Aktuell ist alles Operator-Doku. |
-
-## Fuer den Audit besonders wichtige Dateien (verwendet)
-
-- `HOMELAB_ARCHITECTURE_MASTER_V2.md` — komplett
-- `docs/WORKFLOW.md`, `docs/REPO_MAP.md`, `docs/SERVICE_CATALOG.md` — komplett
-- `docs/DISASTER_RECOVERY.md`, `docs/RESTORE_MATRIX.md`, `docs/SECRETS_MAP.md` — komplett
-- `docs/STORAGE_LAYOUT.md` (zum Audit-Zeitpunkt `docs/STORAGE_LAYOUT.draft.md`), `docs/STRATEGISCHE_BEWERTUNG_2026-05-23.md` — komplett
-- `docs/AUDIT_2026-05-23_LIVE.md`, `docs/AUDIT_2026-05-23_FINAL.md`
-- `ops/policy-checks/last-report.md`
-- `monitoring/docker-compose.yml`, `monitoring/prometheus/alerts.yml`
-- `traefik/docker-compose.yml`, `traefik/dynamic/middlewares.yml`
-- `security/authelia/configuration.yml`, `security/authelia/docker-compose.yml`
-- `apps/paperless/docker-compose.yml`, `apps/immich/docker-compose.yml`, `apps/nextcloud/docker-compose.yml`
-- `host-services/Adguard/docker-compose.yml`
-
----
-
-# A. Executive Summary
-
-**Was schon stark ist:**
-
-- GitOps-Disziplin: Gitea als Sollzustand, Komodo als Consumer, dokumentierter Drift-Runbook, Stop-Regel ("zwei Fehlversuche -> Pflichtmatrix"). Seltene Reife.
-- Backup-Architektur: Pre-Backup-Dumps + Borg + Restore-Tests mit echtem Smoke-Test-Kriterium ("Container startet ≠ Erfolg"). 15 frische Dumps < 24 h alt (`AUDIT_LIVE 9.4`).
-- Architektur-Klarheit: `frontend_net` / `backend_net` / app-interne Netze, keine Sammelnetze, dokumentierte Ausnahmen.
-- Image-Pinning: Tier-1-Stateful mit `<minor>@sha256:...`. Konsequent durchgezogen.
-- Secrets-Hygiene: Keine Secret-Werte im Repo, `_FILE`-Mounts + Komodo Stack ENV, explizit dokumentierte Ausnahmen.
-- Policy-as-Code: `check_repo.ps1` mit 0 Critical und sauber dokumentierten Exceptions.
-
-**Was kritisch ist:**
-
-- **AdGuard Admin-Port 8082 ohne Authelia/2FA am LAN gebunden** (`host-services/Adguard/docker-compose.yml:16`) — dokumentierte "Operator-Entscheidung" 2026-05-25. Im Heim-LAN tolerierbar, mit IoT/Gaeste-WLAN potenziell ein Pfad zur DNS-Manipulation. Niedrigster Aufwand: Bind nur auf Tailscale-Interface.
-- **Authelia ACL: 2FA nur fuer `files.kaleschke.info` und `scrutiny.kaleschke.info`** (`security/authelia/configuration.yml:44-48`). Borg-UI, Code-Server, Filebrowser, Glance — alles nur `one_factor`. Bei Pwd-Kompromittierung des Operator-Accounts ist Borg-UI + Code-Server der direkteste Pfad zur Datenexfiltration.
-- **Authelia-Repo-Baseline ↔ Host-Config-Drift "by design"** (`docs/REPO_MAP.md:48`, `SERVICE_CATALOG 23`). User-DB, OIDC-Clients und Secrets sind hostseitig, Manual-Merge-Pflicht. Stelle, an der Drift mit Anlauf passiert.
-- **Komodo Self-Bootstrap-Problem ist nur dokumentiert, nicht geloest** (MASTER 13: Self-Stack Drift-Recovery 2026-05-04). Bei Recovery vom kalten Host musst du Komodo aus `compose.yaml` neu erzeugen — dafuer brauchst du die `.env` mit `KOMODO_*`-Secrets, die nur auf Host und ggf. Vaultwarden liegen.
-- **Backup-Off-Site-Diversitaet:** BorgBase Hetzner ist Single-Provider; Borg-Passphrase analog gesichert ist als TODO markiert (`docs/DISASTER_RECOVERY.md:64,401`). Wenn Hetzner-Account verloren geht, ist das halbe DR-Versprechen weg.
-
-**Was unnoetig komplex ist:**
-
-- Drei dokumentierte Monitoring-/Logging-Pfade gleichzeitig im Repo: `ops/grafana-influxdb` (Altstand), `ops/loki` (Altstand), `monitoring/` (Ziel). Die Altstaende sind als Container down, aber **Verzeichnisse noch im Repo** — Doppelpflege-Risiko. Der versprochene Repo-Cleanup (`git rm`) fehlt.
-- Hermes-Agent: NAS-Stack bewusst deaktiviert ("VM-seitig offen"), aber Stack-Verzeichnis und Compose mit Dashboard-Domain bleiben im Repo. Mehr "Schwebezustand" als operativer Wert.
-- BentoPDF: "vorbereitet", noch nie produktiv abgenommen (`SERVICE_CATALOG 52`, `MASTER 7.5`).
-- `infra/redis` ist als shared Cache deklariert, wird de facto nur von Paperless genutzt (Authelia nicht, Immich/Nextcloud/Mealie haben eigene Redis). Das "shared" stimmt im Repo nicht mit der Realitaet ueberein.
-
-**Groesster Hebel:**
-
-**Authelia OIDC-Provider aktivieren** — wenn Nextcloud, Immich, Grafana (und perspektivisch Mealie via OIDC-Bridge) per SSO laufen, gewinnst du gleichzeitig:
-
-- (a) Familien-Onboarding-Komfort (ein Login),
-- (b) zentrale Brute-Force-Regulation und Audit,
-- (c) Voraussetzung fuer sinnvolles CrowdSec/Fail2Ban,
-- (d) zentrale 2FA-Pflicht statt App-by-App.
-
-Das ist ein Sprint, nicht ein Quartal, und macht aus deinem "Admin-Authelia" ein echtes Identity-System.
-
-**Was ein erfahrener Homelabber sofort aendern wuerde:**
-
-1. AdGuard-Admin-Port nur auf Tailscale-Interface binden (5 Min, Compose-Edit).
-2. Borg-Passphrase auf Papier in Bankschliessfach (15 Min, off-system).
-3. `scrutiny` und `ddns-updater` `no-new-privileges` Warning aufraeumen (10 Min) — kosmetisch, aber Policy-Check sollte clean sein.
-4. Altstaende `ops/grafana-influxdb/` und `ops/loki/` aus Repo entfernen (Backup-Branch dann `git rm`).
-5. Renovate-Bot gegen Gitea einrichten — beendet manuelle Digest-Pflicht.
-
----
-
-# B. Scorecard (1 = exzellent, 10 = ungenuegend)
-
-| Bereich | Note | Begruendung |
-|---|---:|---|
-| Hardware | **nicht bewertbar** | Keine Inventar-Doku im Repo. Nur Cache-NVMe genannt. Siehe Phase H. |
-| Ordnerstruktur | **2** | Klare Trennung apps/infra/ops/security/core; konsistente Namenskonvention (mit Migrationsplan in STORAGE_LAYOUT 6). Kleinerer Haenger: `host-services/Adguard/` mit Grossbuchstabe. |
-| Storage | **3** (Repo-Stand) / **2** (mit STORAGE_LAYOUT Active) | Cache-XFS, Disk1-XFS jetzt erreicht. Pfad-Disziplin via `/mnt/user/...`. Posture-Check etabliert. Note durch Draft-Status und fehlendes `SERVICES_RECOVERY.md` gedrueckt. |
-| Docker-Architektur | **2** | Netzmodell klar, Healthchecks fehlen grossflaechig, `latest@sha256` als bewusster Kompromiss bei einigen Images dokumentiert. Keine Memory-Limits. |
-| Reverse Proxy / Zugriff | **2** | DNS-Challenge, Wildcard-faehig, Authelia ForwardAuth, dynamic config sauber getrennt. Manuelle Host-Sync-Ausnahme ist pragmatisch. |
-| Security | **3** | Solides Fundament (Authelia Argon2id, no-new-privileges-Standard, Webhook-Allowlist, `cloudflare_dns_api_token` als Docker Secret), aber: nur 2 Domains mit 2FA, AdGuard-Admin direkt am LAN, kein WAF/Bouncer, Authelia Regulation 5-Min-Ban ist gentil. |
-| Netzwerk / DNS | **2** | AdGuard + Unbound + Tailscale-Trias ist Best-of-Class-Homelab. FritzBox als Router nicht im Repo dokumentiert, daher Note nicht 1. |
-| Backup | **2** | Borg, Pre-Dumps, Tier-Modell, dokumentierter Scope. Punkt-Abzug: Single-Provider Off-Site, Passphrase nicht analog, Komodo-Mongo-Dump-Verifikation nicht im Auto-Cron. |
-| Restore-Faehigkeit | **2** | RESTORE_MATRIX mit Smoke-Test je Dienst, Restore-Test-Schedule + Validierungen fuer Vaultwarden/Gitea/Paperless dokumentiert. Punkt-Abzug: Immich-Restore noch nie geuebt — groesster Datentopf. |
-| GitOps | **1-2** | Webhook-Pflicht fuer neue Stacks, Source-of-Truth-Hierarchie, Drift-Runbook. Self-Bootstrap-Problem von Komodo zieht von 1 auf 2. |
-| Monitoring | **3** | Stack produktiv, aber Altstaende noch im Repo, Family-View-Dashboard fehlt, Alerts (`alerts.yml`) sehr knapp (5 Regeln), keine Cert-Expiry-Alert auf Prometheus-Ebene (Cert-Token-Check laeuft separat). |
-| Dokumentation | **1** | Aussergewoehnlich. SERVICE_CATALOG ist Gold. Einziger Punkt: kein End-User-/Familien-Onboarding. |
-| Automatisierung | **3** | Borg-Dumps automatisiert, posture-check Host-Cron, Alert->ntfy-Pipe. Aber: keine CI gegen Repo, kein Renovate, kein automatisches Image-Update-Tracking. |
-| Wartbarkeit | **2** | Doku traegt; Sprintpflege-Disziplin sichtbar (MIGRATION_LOG, AUDIT_FINAL). Risiko: Authelia-Drift, Hermes-Schwebezustand. |
-| Nerd-Faktor | **2-** | Komodo + Borg-UI + ntfy-Bridge + Posture-Check + Restore-Lab + Hermes-Experiment + Push-Mirror + Digest-Pinning. Liegt zwischen "Solider Senior" und "Spielwiese halten lernen". |
-
-**Gesamteindruck: 2 (gut).** Strukturell weit ueber durchschnittlichem Homelab; konkrete Luecken sind klar benennbar und nicht systemisch.
-
----
-
-# C. Top-20 Findings
-
-> Format: priorisiert nach Risiko-zu-Aufwand-Hebel. Jeder Eintrag hat Fundstelle, Empfehlung und Prio.
-
-### F-01 · AdGuard-Admin am LAN ohne Auth
-
-- **Kategorie:** Security / Zugriff
-- **Fundstelle:** `host-services/Adguard/docker-compose.yml:16`, `MASTER 10`, `docs/SERVICE_CATALOG.md:14`
-- **Beobachtung:** Port `8082:80` direkt auf alle Interfaces. Bewusste Operator-Entscheidung 2026-05-25.
-- **Risiko:** Jedes Geraet im LAN kann DNS-Filterregeln, Upstream und Logging manipulieren. IoT-Kompromittierung oder Gast-WLAN -> DNS-Hijack moeglich.
-- **Best Practice:** Admin-UIs nicht im LAN ohne Auth. Entweder hinter Traefik+Authelia mit `two_factor` oder Bind auf Tailscale-Interface (z. B. `100.x.y.z:8082:80`).
-- **Empfehlung:** Schritt 1 — Bind auf Tailscale-IP (S, 5 Min). Schritt 2 — optional spaeter Traefik-Route hinter Authelia.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** S
-- **Validierung:** `ss -ltnp | grep :8082` zeigt nur Tailscale-IP; LAN-Browser-Zugriff schlaegt fehl.
-- **Rollback:** Compose-Diff zurueck, Komodo redeploy.
-
-### F-02 · Borg-Passphrase nicht analog gesichert
-
-- **Kategorie:** Backup / DR
-- **Fundstelle:** `docs/DISASTER_RECOVERY.md:64,401`, `docs/SECRETS_MAP.md:48`
-- **Beobachtung:** `borg_repo_passphrase.txt` liegt im Host-Filesystem unter `/mnt/user/appdata/secrets/`. Doku weist explizit darauf hin, dass eine externe analoge Sicherung Operator-Aufgabe ist.
-- **Risiko:** Wenn Unraid-Host und ggf. Vaultwarden gleichzeitig defekt sind, ist das verschluesselte Borg-Repo bei Hetzner nutzlos.
-- **Empfehlung:** Auf Papier ausdrucken, in Bankschliessfach oder bei vertrauter Person versiegelt. Zusaetzlich in Vaultwarden hinterlegen (aber Vaultwarden hilft nicht, wenn es selbst restauriert werden muss).
-- **Prioritaet:** Muss sofort
-- **Aufwand:** S
-- **Validierung:** Du kannst den Wert ohne Host wiederherstellen.
-
-### F-03 · Single-Provider Off-Site Backup
-
-- **Kategorie:** Backup
-- **Fundstelle:** `ops/borg-ui/BACKUP_SCOPE.md`, `docs/RESTORE_MATRIX.md:77-96`, `STORAGE_LAYOUT 8.1`
-- **Beobachtung:** Hetzner Storage Box als alleiniges Off-Site-Borg-Ziel. STORAGE_LAYOUT 8.1 sieht zusaetzlich lokales Borg-Repo auf `/mnt/user/backups/borg/` vor (gleicher Host) und eine externe Wechselplatte (manuell rotiert).
-- **Risiko:** Hetzner-Account-Verlust (Payment-Issue, Account-Hack, Provider-Outage) = halbes 3-2-1.
-- **Best Practice:** Zweites Off-Site-Ziel mit unterschiedlichem Provider oder Cold-Wechselplatte mit fester Rotationskadenz.
-- **Empfehlung:** (a) Wechselplatten-Rotation in fester Kadenz dokumentieren (zwei Platten, monatlicher Tausch). Oder (b) zweites Borg-Repo bei rsync.net / BorgBase EU2 / privatem 2. Standort.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M
-- **Validierung:** `borg list` gegen beide Repos, beide < 7 Tage alt.
-
-### F-04 · Authelia 2FA-Pflicht zu schmal
-
-- **Kategorie:** Security
-- **Fundstelle:** `security/authelia/configuration.yml:44-53`
-- **Beobachtung:** Nur `files.kaleschke.info` und `scrutiny.kaleschke.info` sind `two_factor`. Tier-1-Operator-UIs wie Borg-UI, Code-Server, Filebrowser (zweite Route?), Komodo (eigene Auth), Glance, Grafana laufen mit `one_factor`.
-- **Risiko:** Operator-Passwort-Kompromittierung (Phishing, Keylogger, Browser-Save-Leak) gibt ohne 2FA Vollzugriff auf Code-Server (Repo + Workspace), Borg-UI (Restore-Pfade), Filebrowser (Documents/Photos).
-- **Empfehlung:** ACL erweitern: `two_factor` fuer `borg.kaleschke.info`, `code.kaleschke.info`, `files.kaleschke.info` (schon), `glance.kaleschke.info` (debattierbar), `traefik.kaleschke.info`. Komodo bleibt Ausnahme.
-- **Prioritaet:** Muss sofort
-- **Aufwand:** S
-- **Validierung:** Nach Login auf `borg.kaleschke.info` wird 2FA-Prompt erzwungen.
-- **Rollback:** ACL-Block zurueck.
-
-### F-05 · Repo-Altstaende `ops/grafana-influxdb/` und `ops/loki/` nicht entfernt
-
-- **Kategorie:** Wartbarkeit / GitOps
-- **Fundstelle:** Repo-Wurzeln `ops/grafana-influxdb/`, `ops/loki/`; `MASTER 7.6`, `SERVICE_CATALOG 68-70,80-81`, `AUDIT_FINAL 9`
-- **Beobachtung:** Container down, aber Compose-Dateien + Provisioning bleiben im Repo. Doku referenziert beide gleichzeitig. Risiko: jemand (zukuenftiges Ich, KI) deployt versehentlich den Altstand.
-- **Empfehlung:** `git rm` der beiden Verzeichnisse, Tag `pre-monitoring-cleanup` fuer Rollback, MIGRATION_LOG-Eintrag.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** S
-- **Validierung:** `policy-checks` laeuft clean, Repo enthaelt nur noch `monitoring/`.
-
-### F-06 · Hermes-Agent im Schwebezustand
-
-- **Kategorie:** App-Landschaft / Wartbarkeit
-- **Fundstelle:** `ops/hermes-agent/docker-compose.yml`, `MASTER 7.5`, `SERVICE_CATALOG 82-83`
-- **Beobachtung:** "NAS-Stack bewusst deaktiviert" wegen offener VM-Seite. Dashboard-Domain (`hermes.kaleschke.info`) + Authelia-ACL + Secret-Pfade dokumentiert.
-- **Risiko:** Schleichender Verfall — in 6 Monaten verstehst du Model-C nicht mehr ohne `ops/hermes-agent/README.md`. Bei jeder Authelia-/Compose-Aenderung musst du Hermes mitpruefen, obwohl es nichts tut.
-- **Empfehlung:** Operator-Entscheidung mit 60-Tage-Deadline ehrlich treffen. Wenn nicht produktiv bis 2026-07-25: `git rm ops/hermes-agent/`, Domain aus DNS, ACL-Eintrag raus.
-- **Prioritaet:** Sollte zeitnah (Entscheidung)
-- **Aufwand:** S (Entfernen) / L (echte Produktiv-Aktivierung)
-- **Validierung:** Entweder Smoke-Test auf `hermes.kaleschke.info` mit funktionalem Use-Case-Beleg, oder Repo-clean.
-
-### F-07 · Monitoring-Stack ohne Digest-Pin
-
-- **Kategorie:** Reproduzierbarkeit / GitOps
-- **Fundstelle:** `monitoring/docker-compose.yml:3,28,66,84,100,118,276,296`
-- **Beobachtung:** Prometheus, Alertmanager, Blackbox, Loki, Promtail, Grafana, node-exporter, cAdvisor sind alle nur per Tag gepinnt (`prom/prometheus:v3.7.3`, `grafana/grafana:12.4.3`, ...). Nur `influxdb3-core` hat `@sha256:`. Das widerspricht der Image-Versionierungs-Disziplin der Tier-1-Stateful-Dienste.
-- **Risiko:** Wenn upstream einen Tag erneut pushed (Versionsdrift, Supply Chain), wird beim Rebuild ein anderer Container deployed — gerade Monitoring sollte stabil sein.
-- **Empfehlung:** Beim naechsten Komodo-Redeploy aktuellen Digest auslesen und einpinnen. Vorbereitung fuer Renovate (F-12).
-- **Prioritaet:** Nice to have
-- **Aufwand:** S
-- **Validierung:** `grep '@sha256' monitoring/docker-compose.yml` listet alle 10 Services.
-
-### F-08 · Alert-Regeln zu duenn
-
-- **Kategorie:** Monitoring
-- **Fundstelle:** `monitoring/prometheus/alerts.yml`
-- **Beobachtung:** Exakt 5 Regeln: ExternalConnectivityDown, EndpointDown, EndpointSlow, DiskAlmostFull, MemoryHighUsage, Traefik5xx. Es fehlen:
-  - Borg-Lauf-Frische (ueber `node_exporter` textfile collector oder Pushgateway).
-  - Zertifikatslaufzeit (Blackbox kann `probe_ssl_earliest_cert_expiry`, aber keine Alert-Regel dafuer).
-  - Container-down-Alert (cAdvisor liefert `container_last_seen`).
-  - PostgreSQL-Connection-Saturation.
-  - Loki ingestion-rate / log-volume spike.
-  - InfluxDB-Disk-Pressure.
-  - Backup-Job-Failure.
-- **Risiko:** Du siehst Probleme nicht, bevor sie weh tun. Cert-Expiry und Borg-Stale sind die schmerzhaftesten Blind-Spots.
-- **Empfehlung:** Mindestens zwei Regeln nachziehen: `BorgArchiveStale` (>30 h, Pushgateway oder textfile) und `TLSCertExpiryNear` (<14 Tage). Rest als Folge-Sprint.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M
-- **Validierung:** Alerts feuern in Test-Bedingung (Borg-Dump-File touch -d backwards).
-
-### F-09 · Komodo-Self-Bootstrap-Problem
-
-- **Kategorie:** GitOps / DR
-- **Fundstelle:** `MASTER 13: Komodo Self-Stack Drift-Recovery 2026-05-04`
-- **Beobachtung:** Du hattest schon einen Drift-Vorfall (Komodo-Core ran aus `/tmp/*repair.yml`, Mongo-Pfad fehlte). Recovery-ENV liegt als "temporaeres Tier-1-Secret-Material" unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env` (Doku-Stand).
-- **Risiko:** Bei Totalausfall musst du Komodo aus Compose-Datei wiederbeleben, dafuer brauchst du die Stack-ENV mit `KOMODO_SECRET_KEY`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY` etc., die nur als Komodo Stack ENV existieren. Klassisches Henne-Ei.
-- **Empfehlung:** Komodo-Self-Stack aus Komodos eigener Verwaltung herausnehmen und als handgepflegten `docker compose`-Service in `services/komodo-bootstrap/` halten. Stack-ENV als versiegelte Datei unter `/mnt/user/appdata/secrets/` mit deterministischem Restore-Pfad in RESTORE_MATRIX.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M
-- **Validierung:** Komodo-Stack-Datei lebt im Repo unter `services/`, nicht in Komodos eigener Workspace-Sicht.
-
-### F-10 · Authelia Repo↔Host Drift "by design"
-
-- **Kategorie:** GitOps / Security
-- **Fundstelle:** `docs/REPO_MAP.md:48`, `security/authelia/configuration.yml`, `SERVICE_CATALOG 23`
-- **Beobachtung:** Repo enthaelt Baseline ohne Secrets, OIDC, Users-DB. Manuelles Merge auf den Host noetig. Es gibt keine automatische Konsistenz-Pruefung.
-- **Risiko:** Repo-Aenderung (z. B. neue ACL-Regel) wird gepusht, aber nie auf den Host gemerged -> Drift, Authelia hinkt der Wahrheit hinterher.
-- **Empfehlung:** Symmetrisch zum Traefik-Dynamic-Workflow (manueller Sync explizit als Pflicht in WORKFLOW.md). Zusaetzlich ein einfaches Diff-Script `services/authelia-diff.sh`, das `diff` zwischen Repo-Baseline und Host-Datei zeigt, und das im posture-check als Warning auftaucht, wenn die ACL-Sektion differiert.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** S
-- **Validierung:** Script laeuft, posture-check kennt einen neuen Check `authelia_config_drift`.
-
-### F-11 · Immich-Restore noch nie geuebt
-
-- **Kategorie:** Backup / Restore
-- **Fundstelle:** `docs/RESTORE_MATRIX.md:49`, Restore-Test-Schedule
-- **Beobachtung:** Vaultwarden / Gitea / Paperless haben Mini-Restore-Tests (2026-05-07). Immich nicht. Immich ist der groesste Datentopf (Familien-Fotos).
-- **Risiko:** Silent Corruption in Postgres-pgvecto-rs-Daten bemerkst du erst beim Restore-Versuch.
-- **Empfehlung:** Eigener Sprint: Immich-Restore-Test gegen `/mnt/user/backups/restore-lab/immich/` mit Sub-Set der `immich.dump` und einem Foto-Sample. Smoke-Test = "10 Fotos im Browser sichtbar nach Restore".
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M
-- **Validierung:** Report unter `/mnt/user/backups/restore-reports/immich-<datum>.json`.
-
-### F-12 · Keine Image-Update-Automatik (Renovate o. ae.)
-
-- **Kategorie:** Wartbarkeit
-- **Fundstelle:** Repo-weit; `docs/WORKFLOW.md:282-288` (Image-Versionierung)
-- **Beobachtung:** Digest-Pinning ist konsequent, aber rein manuell. Bei ~30 Images bedeutet das, du musst monatlich fuer Patch-Updates manuell Digests auslesen — oder es bleibt liegen.
-- **Risiko:** CVE-Patches werden nicht eingespielt, weil "der laufende Stand ist stabil".
-- **Empfehlung:** Renovate Bot (self-hosted, gegen Gitea), Gitea-Actions-Runner. Renovate oeffnet PRs fuer Patch-/Minor-Updates; Major-Updates werden mit Labels separiert.
-- **Prioritaet:** Sollte zeitnah (oder Nice to have, je nach Schmerz)
-- **Aufwand:** M (Initial-Setup ist substantiell)
-- **Validierung:** Renovate hat erste PRs in Gitea geoeffnet, du mergst eines davon kontrolliert.
-
-### F-13 · Keine OIDC-SSO fuer User-Apps
-
-- **Kategorie:** Security / UX
-- **Fundstelle:** `security/authelia/configuration.yml`, `docs/SECRETS_MAP.md`
-- **Beobachtung:** Authelia kann OIDC, ist aber nur als ForwardAuth konfiguriert. Nextcloud, Immich, Grafana, Mealie laufen mit eigenen User-DBs.
-- **Risiko:** N getrennte Passwortspeicher, N getrennte 2FA-Setups, keine zentrale Sperrung bei Account-Kompromittierung. Familie hat keinen einfachen Onboarding-Pfad.
-- **Empfehlung:** OIDC-Provider in Authelia aktivieren, Nextcloud (via Plugin), Immich (nativer OIDC-Support), Grafana (nativer OIDC-Support) als Clients konfigurieren. Vaultwarden via OIDC-Bridge nur, wenn der Aufwand klar mehrwertig ist — sonst bewusst auslassen.
-- **Prioritaet:** Sollte zeitnah (groesster Hebel laut Executive)
-- **Aufwand:** L
-- **Validierung:** Familienkonto kann sich mit einem Login bei Nextcloud + Immich + Grafana anmelden.
-
-### F-14 · Kein WAF / Bouncer vor oeffentlichen Apps
-
-- **Kategorie:** Security
-- **Fundstelle:** `traefik/docker-compose.yml`, oeffentliche Hosts in `docs/REPO_MAP.md:127-152`
-- **Beobachtung:** Sechs oeffentliche Apps mit nativer Auth (vault, paperless, mealie, ntfy, git, immich, cloud) ohne IP-Bouncer. Authelia-Regulation greift nur fuer die ForwardAuth-Pfade; Apps mit eigener Auth bekommen den vollen Traffic.
-- **Risiko:** Credential-Stuffing-Bot-Wellen treffen die App selbst (Nextcloud, Immich) — Logs sind im Loki, aber kein Sperr-Mechanismus.
-- **Empfehlung:** CrowdSec als Bouncer fuer Traefik (`crowdsecurity/traefik-bouncer`). Nutzt Loki/Logs fuer Erkennung, sperrt IPs auf Traefik-Ebene, bevor sie die Apps treffen.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M
-- **Validierung:** CrowdSec-Dashboard zeigt erste Sperren; Test-Brute-Force gegen `nextcloud.kaleschke.info` wird bei N Versuchen geblockt.
-
-### F-15 · Healthchecks fehlen grossflaechig
-
-- **Kategorie:** Docker / Operations
-- **Fundstelle:** Spot-checks: `apps/paperless/docker-compose.yml`, `apps/immich/docker-compose.yml`, `security/authelia/docker-compose.yml`, `traefik/docker-compose.yml` — keiner hat `healthcheck:`-Block.
-- **Beobachtung:** Restart-Policy ist ueberall `unless-stopped`, aber ohne Healthcheck kann Docker keinen Crash-Loop bei "Container laeuft, aber App tot" erkennen.
-- **Risiko:** Bei Soft-Failure (Postgres-Connection-Pool tot, Authelia haengt im Storage-Connect) merkst du nichts, weil Container "running" bleibt.
-- **Empfehlung:** Fuer Tier-1 (Traefik `wget /ping`, Authelia `/api/health`, PostgreSQL `pg_isready`, Komodo `wget /api/healthcheck`) Healthchecks ergaenzen. Fuer Tier-2 schrittweise.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** M (pro Stack 5–15 Min)
-- **Validierung:** `docker ps` zeigt `(healthy)` neben den Tier-1-Containern.
-
-### F-16 · `infra/redis` als "shared" deklariert, faktisch nur Paperless
-
-- **Kategorie:** Architektur-Konsistenz
-- **Fundstelle:** `infra/redis/docker-compose.yml`, `docs/SERVICE_CATALOG.md:31` ("shared Redis Cache")
-- **Beobachtung:** Immich, Nextcloud, Mealie haben jeweils eigene Redis-Instanzen. Authelia nutzt bewusst kein Redis (MASTER 13). Paperless nutzt es laut Compose. Effektiv "Paperless-Redis im Frack des shared-Caches".
-- **Risiko:** Niedrig. Aber: Wenn du `infra/redis` fuer etwas anderes wegnimmst, denkst du, es kostet Paperless was — und das waere der Fall.
-- **Empfehlung:** Doku-Update: SERVICE_CATALOG 31 praezisieren ("dediziertes Redis fuer Paperless; andere Stacks haben eigene Redis-Instanzen"). Architektur bleibt, nur Etikett ehrlich machen. Alternativ: in `apps/paperless/` als App-internes Netz konsolidieren wie Mealie.
-- **Prioritaet:** Nice to have
-- **Aufwand:** S (Doku) / M (Architektur)
-
-### F-17 · Plex bleibt als Host-Net-Stack
-
-- **Kategorie:** Security / Architektur
-- **Fundstelle:** `host-services/plex/docker-compose.yml`, `MASTER 7.4`
-- **Beobachtung:** Plex laeuft als Host-Net wegen Discovery/GDM. Dokumentierte Ausnahme.
-- **Risiko:** Plex hat hoehere Angriffsoberflaeche als Apps mit Traefik. Plex-Login wurde mehrfach Ziel von Account-Uebernahmen (Plex.tv-Auth-Issues 2024/25). Bei Plex.tv-Kompromittierung greift Authelia nicht — Plex authentifiziert gegen Plex.tv.
-- **Empfehlung:** Plex bewusst beibehalten (Doku stuetzt), aber: (a) "Remote Access" in Plex-UI deaktivieren, wenn nur lokal/Tailscale genutzt. (b) Plex-Server nicht in `frontend_net` (waere schaedlich) — bleibt Host-Net, korrekt.
-- **Prioritaet:** Nice to have
-- **Aufwand:** S
-- **Validierung:** Plex `Remote Access` UI zeigt "disabled".
-
-### F-18 · Nextcloud ohne ForwardAuth, ohne dedizierte Brute-Force-Doku
-
-- **Kategorie:** Security
-- **Fundstelle:** `apps/nextcloud/docker-compose.yml`, `MASTER 13: Nextcloud-Entscheidung`
-- **Beobachtung:** Bewusste Ausnahme (WebDAV/CardDAV). In Nextcloud selbst sind Brute-Force-Schutz, 2FA-Pflicht und App-Passwords konfigurierbar, aber nicht im Repo dokumentiert.
-- **Risiko:** Familien-Konto mit schwachem Passwort + Nextcloud oeffentlich = direkter Pfad zu Dokumenten/Fotos.
-- **Empfehlung:** `apps/nextcloud/POST_INSTALL.md` mit Pflicht-Checkliste: Brute-Force-Plugin aktiv, 2FA-Provider TOTP installiert, Admin-Account hat 2FA, "Enforce 2FA for admin group" gesetzt. Optional: `OCC`-Befehle als Skript in `services/nextcloud-policy/`.
-- **Prioritaet:** Sollte zeitnah
-- **Aufwand:** S
-- **Validierung:** Test-Login ohne 2FA als Admin schlaegt fehl.
-
-### F-19 · Keine Container-Memory-Limits
-
-- **Kategorie:** Docker / Hardware-Schutz
-- **Fundstelle:** Spot-checks aller Composes
-- **Beobachtung:** Keine `mem_limit:` oder `deploy.resources.limits` Sektion in Tier-1- oder Tier-2-Stacks.
-- **Risiko:** Bei Image-Bug oder Memory-Leak (z. B. Immich-ML, Paperless-OCR-Loop) kann ein Container den Host in OOM treiben. Posture-Check + Docker-Critical-Events sehen das nachher, aber praeventiver waere Container-Limit + Docker-OOM-Kill fuer den richtigen Prozess.
-- **Empfehlung:** Fuer Tier-1 (Postgres, Authelia, Traefik, Komodo) sanfte Limits setzen (z. B. Postgres 2 GB, Authelia 256 MB, Traefik 256 MB). Fuer Immich-ML-Container ein hartes Limit, das Verhungern verhindert.
-- **Prioritaet:** Nice to have
-- **Aufwand:** M
-- **Validierung:** `docker stats` zeigt `MEM USAGE / LIMIT` ungleich `unlimited`.
-
-### F-20 · Paperless-DBPass weiter als Stack-ENV (dokumentierte Ausnahme)
-
-- **Kategorie:** Secrets
-- **Fundstelle:** `MASTER 13: Secrets in Komodo Stacks`, `docs/SECRETS_MAP.md:25`
-- **Beobachtung:** Paperless unterstuetzt `_FILE` nicht fuer DB-Pass. Bewusste Ausnahme.
-- **Risiko:** Stack-ENV liegt in Komodo-DB (Mongo), nicht im Repo. Bei Komodo-Mongo-Backup-Luecke fehlt das Passwort beim Restore.
-- **Empfehlung:** Erweiterung der Disaster-Recovery-Doku: explizite Liste aller "Stack-ENV-only"-Secrets mit Zeiger, dass `komodo-mongo.archive.gz` fuer Restore zwingend ist, oder die ENV manuell vorgehalten werden muss (in Vaultwarden + externer Notiz).
-- **Prioritaet:** Nice to have
-- **Aufwand:** S
-- **Validierung:** DR-Doc Abschnitt "Stack-ENV-Werte" referenziert konkrete Restore-Pfade.
-
----
-
-# D. Risiko-Matrix
-
-| Risiko | Bereich | Wahrscheinlichkeit | Auswirkung | Prioritaet | Massnahme |
-|---|---|---|---|---|---|
-| Borg-Passphrase weg -> Restore unmoeglich | Backup | niedrig | katastrophal | P0 | F-02 analoge Sicherung |
-| Hetzner-Account-Verlust -> halbes 3-2-1 | Backup | niedrig-mittel | hoch | P0/P1 | F-03 Zweitziel |
-| AdGuard-Admin-Manipulation aus LAN | Security | niedrig | hoch (DNS-Hijack) | P0 | F-01 Bind auf Tailscale |
-| Operator-Pwd-Leak -> 2FA fehlt fuer Borg-UI/Code-Server | Security | mittel | hoch | P0 | F-04 2FA-ACL erweitern |
-| Komodo-Self-Bootstrap-Failure nach Totalausfall | DR | niedrig | hoch | P1 | F-09 Bootstrap-Datei in `services/` |
-| Authelia Repo↔Host Drift unbemerkt | GitOps/Security | mittel | mittel | P1 | F-10 Diff-Check |
-| Immich Silent Corruption -> kein Restore-Test belegt | Backup | niedrig | sehr hoch (Familien-Fotos) | P1 | F-11 Restore-Test |
-| Cert-Expiry unbemerkt -> Public Apps down | Operations | niedrig | mittel | P1 | F-08 Alert-Regel |
-| Nextcloud Brute-Force ohne Bouncer | Security | mittel | mittel-hoch | P1 | F-14 CrowdSec / F-18 Nextcloud-Haerten |
-| Image-Update-Stillstand -> CVE bleibt | Security | mittel | mittel | P1 | F-12 Renovate |
-| Hermes-Wartungsschuld | Wartbarkeit | hoch | niedrig | P1 | F-06 Entscheidung |
-| Repo-Altstaende ueberleben -> Doppel-Deploy | GitOps | mittel | niedrig | P1 | F-05 Cleanup |
-| OOM durch unlimitierte Container | Hardware | niedrig | mittel | P2 | F-19 mem_limit |
-| Healthcheck-Luecke -> Soft-Failure stumm | Operations | mittel | niedrig | P2 | F-15 Healthchecks |
-| Monitoring-Stack ohne Digest-Pin | Reproduzierbarkeit | niedrig | niedrig | P2 | F-07 Digests + Renovate |
-| Hardware-SPOF (kein zweiter Host) | Hardware | niedrig | sehr hoch | P3 | Cold-Standby / 2. Host |
-
----
-
-# E. Zielarchitektur (realistisch fuer privates Homelab)
-
-**Hardware**
-
-- 1× Unraid-Host (bestehend) als Production. CPU mit AVX2/AVX-512 fuer Immich-ML. ≥ 32 GB RAM (fuer 2× Postgres + Immich-ML + Loki/Prometheus + 2 VMs).
-- 2× NVMe als BTRFS-RAID1-Cache, sobald Cache-Auslastung > 70 % (STORAGE_LAYOUT 15.3).
-- Parity-Disk ≥ groesste Daten-Disk.
-- USV mit USB-Steuerung (NUT-faehig: APC Back-UPS RS 700+, Eaton 3S, CyberPower CP1500EPFCLCD). Direkter Shutdown bei Power-Loss.
-- Optional: zweiter alter Mini-PC oder NUC als Cold-Standby mit Tailscale, der den letzten Komodo-Bootstrap + Gitea-Mirror tragen kann.
-
-**Netzwerk**
-
-- FritzBox (bestehend) als Router + NAT.
-- VLANs nur wenn IoT-WLAN dazukommt (FritzBox-Gast-WLAN reicht fuer Anfang).
-- DNS: AdGuard -> Unbound (bestehend). Admin-UI nur Tailscale.
-- Tailscale (bestehend): Operator-Pfad. Subnet-Router optional fuer LAN-Devices ueber Tailscale.
-
-**Storage**
-
-- Cache `only` fuer `appdata`, `system`, `domains` (bestehend STORAGE_LAYOUT 4).
-- Disk1 (XFS) fuer `services`, `documents`, `photos`, `backups`, `media`, `finance`, `projekte`.
-- Externe Wechselplatte (XFS) fuer Cold-Off-Site mit fester monatlicher Rotation.
-
-**Ordnerstruktur (Repo)**
-
-- Beibehalten. Nur Cleanup von Altstaenden (F-05). Naming `kebab-case`-Migration aus STORAGE_LAYOUT 6 schrittweise.
-
-**Docker**
-
-- Compose-only via Komodo (bestehend).
-- Digest-Pin fuer alle Images (F-07).
-- Healthchecks fuer Tier-1 (F-15).
-- Mem-Limits fuer Tier-1 + Immich-ML (F-19).
-- App-interne Netze fuer Stack-Isolation (bestehend).
-
-**Reverse Proxy**
-
-- Traefik v3 (bestehend), DNS-Challenge, Wildcard.
-- Dynamic Config nur fuer Middlewares, TLS, Dashboard (bestehend).
-- CrowdSec-Bouncer (F-14) fuer oeffentliche Apps.
-
-**Auth**
-
-- Authelia als ForwardAuth **und** OIDC-Provider (F-13).
-- Nextcloud, Immich, Grafana via OIDC.
-- 2FA-Pflicht fuer alle Operator-Dienste (F-04).
-- Komodo bewusste Ausnahme (bestehend).
-
-**Backup**
-
-- Borg lokal (`/mnt/user/backups/borg/`) + Borg Hetzner + Wechselplatte.
-- Pre-Dump-Hooks (bestehend).
-- Borg-Passphrase off-system analog (F-02).
-- Restore-Tests automatisiert (F-11 Immich, dann andere via CI).
-
-**Monitoring**
-
-- `monitoring/`-Stack als alleinige Quelle. Altstaende raus (F-05).
-- Family-View-Dashboard in Grafana (alles gruen, Backup-Frische, Cert-Tage).
-- Alerts ausgebaut (F-08).
-- Posture-Check + Docker-Critical-Events -> ntfy `homelab-alerts` (bestehend).
-
-**Dokumentation**
-
-- Aktuelle Doku-Tiefe halten.
-- `SERVICES_RECOVERY.md` und `STORAGE_LAYOUT.md` (Active) finalisieren.
-- Familien-/User-Onboarding-Doku als eigenes kleines Dokument.
-
-**GitOps**
-
-- Gitea + Komodo (bestehend).
-- GitHub-Push-Mirror (umgesetzt, bestaetigt durch MASTER 7.1).
-- Renovate-Bot gegen Gitea (F-12).
-- Optional: Staging-Branch + zweites Komodo-Ziel in Tailscale-VM (Phase 3).
-
-**Restore**
-
-- RESTORE_MATRIX bleibt fuehrend.
-- Restore-Lab unter `/mnt/user/backups/restore-lab/` (bestehend).
-- Immich-Restore als Luecke schliessen (F-11).
-- Komodo-Self-Bootstrap raus aus Komodo (F-09).
-
----
-
-# F. Priorisierte Massnahmenliste
-
-| # | Aufgabe | Warum | Kategorie | Prio | Aufwand | Risiko (bei Nicht-Tun) | Mehrwert | Abhaengigkeiten | Validierung |
-|---|---|---|---|---|---|---|---|---|---|
-| 1 | Borg-Passphrase analog sichern | DR-SPOF schliessen | Backup | P0 | S | katastrophal | DR-Sicherheit | — | Wert ohne Host abrufbar |
-| 2 | AdGuard-Admin auf Tailscale-IP binden | LAN-Angriffsflaeche | Security | P0 | S | hoch | LAN-IoT-Haertung | — | `ss -ltnp` zeigt nur Tailscale |
-| 3 | 2FA-ACL erweitern (borg, code, files, traefik) | Operator-Pwd-Leak | Security | P0 | S | hoch | 2FA-Coverage | Authelia-TOTP-Setup | Login erzwingt 2FA |
-| 4 | Altstaende `ops/grafana-influxdb`+`ops/loki` `git rm` | Repo-Hygiene, kein Re-Deploy | GitOps | P0 | S | niedrig | Klarheit | Tag setzen | Policy-Check clean |
-| 5 | Hermes 60-Tage-Deadline | Wartungsschuld | App | P1 | S/L | mittel | Komplexitaet raus | Operator-Entscheidung | Entweder produktiv oder weg |
-| 6 | Immich-Restore-Test einrichten | Groesster Datentopf ungeprueft | Backup | P1 | M | hoch | Restore-Vertrauen | Restore-Lab-Pfad | Smoke-Test-Report |
-| 7 | Renovate-Bot in Gitea | manuelle Digest-Pflege | Wartung | P1 | M | mittel | Update-Hygiene | Gitea-Runner | erste PR offen |
-| 8 | Alert-Regeln (Borg-Frische, Cert-Expiry) | Blind-Spot Operations | Monitoring | P1 | M | mittel | echte Alerts | Pushgateway o. textfile | Alert in Test |
-| 9 | Family-View-Dashboard Grafana | Morgens 30 s Check | Monitoring | P1 | M | niedrig | Uebersicht | Datasources stehen | Dashboard funktioniert |
-| 10 | Komodo-Self-Bootstrap als `services/komodo-bootstrap/` | Henne-Ei-Problem | GitOps/DR | P1 | M | mittel | sauberer Recovery-Pfad | Komodo-Stack-Doku | Bootstrap aus Repo allein moeglich |
-| 11 | Authelia-Drift-Diff-Check in posture-check | Repo↔Host Drift | GitOps | P1 | S | mittel | Drift-Detektion | posture-check-Erweiterung | neuer Check sichtbar |
-| 12 | Healthchecks Tier-1 | Soft-Failure-Erkennung | Docker | P1 | M | niedrig | Self-Healing-Trigger | — | `docker ps` zeigt `healthy` |
-| 13 | CrowdSec-Bouncer vor Traefik | oeffentliche Apps schuetzen | Security | P1 | M | mittel | Brute-Force-Stop | Traefik-Middleware | Test-IP wird geblockt |
-| 14 | Nextcloud-Haertung dokumentieren | Public App + native Auth | Security | P1 | S | mittel | App-Haertung | Plugin-Install | 2FA-erzwingt |
-| 15 | Authelia OIDC-Provider + Nextcloud/Immich/Grafana | SSO, Familien-Onboarding | Security/UX | P2 | L | niedrig | hoher Mehrwert | Authelia-OIDC-Setup | SSO-Login funktioniert |
-| 16 | Immich-Smartphone-Auto-Backup fuer Familie | Killer-App fuer Familie | App | P2 | S | niedrig | hoher Mehrwert | — | Familien-Foto in Immich |
-| 17 | Monitoring-Stack Digests + Renovate-Pin | Reproduzierbarkeit | GitOps | P2 | S | niedrig | konsistent | Renovate optional | `@sha256` an allen Images |
-| 18 | Mem-Limits Tier-1 + Immich-ML | OOM-Schutz | Hardware/Docker | P2 | M | niedrig | Schutz | — | `docker stats` zeigt Limits |
-| 19 | Off-Site-Zweitziel (rsync.net o. Wechselplatte) | Single-Provider | Backup | P2 | M | mittel | 3-2-1 echt | Borg-Config | beide Repos < 7d |
-| 20 | Staging-Branch + 2. Komodo-Ziel | Risiko-Aenderung testbar | GitOps | P3 | L | niedrig | Reife | 2. VM/Host | Deploy auf staging klappt |
-
----
-
-# G. Refactoring-Plan (Sprints)
-
-## Sprint 0 — Sicherheitsnetz und Ist-Zustand sichern (1 Tag)
-
-- **Ziel:** Du kannst danach im schlimmsten Fall alles, was du jetzt aenderst, sicher zurueckrollen.
-- **Aufgaben:**
-  - Git-Tag `audit-2026-05-25-baseline` auf `master` setzen und nach Gitea + GitHub-Mirror pushen.
-  - Borg-Lauf manuell ausloesen ("freshen up"), Erfolg im Log dokumentieren.
-  - Aktuellen Komodo-Mongo-Dump verifizieren (`mongorestore --dry-run`).
-  - `docs/MIGRATION_LOG.md` Eintrag "Audit-Sprint-Start".
-- **Erfolgskriterium:** Tag pushed, Borg-Lauf gruen, Mongo-Dump verifiziert.
-- **Validierung:** `git fetch && git tag | grep audit-2026-05-25-baseline` und `ls /mnt/user/backups/borg/dumps/latest/` zeigt fresh.
-- **Rollback:** N/A (rein additiv).
-- **Risiko bei Nichtumsetzung:** Keine Notbremse fuer Sprint 1.
-
-## Sprint 1 — Offensichtliche Risiken entschaerfen (1 Woche)
-
-- **Ziel:** P0-Risiken weg, Repo-Hygiene wieder gruen.
-- **Aufgaben (in dieser Reihenfolge):**
-  1. F-02 Borg-Passphrase analog sichern (off-system, kein Code-Change).
-  2. F-01 AdGuard-Admin-Port auf Tailscale-IP — Edit `host-services/Adguard/docker-compose.yml:16`.
-  3. F-04 Authelia ACL erweitern (`two_factor` fuer borg, code, files, traefik) — Edit `security/authelia/configuration.yml` + Host-Sync.
-  4. F-05 Altstaende `ops/grafana-influxdb/`, `ops/loki/` entfernen — `git rm`, MIGRATION_LOG.
-  5. Policy-Check-Warnings `SEC001` (ddns-updater, scrutiny) aufraeumen.
-- **Erfolgskriterium:** Policy-Check 0 Warnings fuer SEC001, AdGuard-Admin nur via Tailscale, 2FA-Login auf borg.kaleschke.info.
-- **Validierung:** Policy-Check-Report; Browser-Test mit/ohne 2FA-Cookie.
-- **Rollback:** Commit-Revert pro Block.
-
-## Sprint 2 — GitOps-Robustheit (1–2 Wochen)
-
-- **Ziel:** Self-Bootstrap-Problem entschaerft, Drift-Detektion automatisiert.
-- **Aufgaben:**
-  1. F-09 Komodo-Bootstrap-Compose nach `services/komodo-bootstrap/` extrahieren + dokumentierter Standalone-Restore-Pfad.
-  2. F-10 Authelia-Drift-Diff in posture-check ergaenzen.
-  3. F-11 Immich-Restore-Test einrichten (analog zu vaultwarden/gitea/paperless).
-  4. F-06 Hermes-Entscheidung mit 60-Tage-Deadline schriftlich.
-- **Erfolgskriterium:** Komodo laesst sich aus Repo allein wiederherstellen. Posture-Check zeigt `authelia_config_drift: false`. Immich-Restore-Report unter `/mnt/user/backups/restore-reports/`.
-- **Validierung:** Trockenversuch (Komodo-Container stoppen, `docker compose up -d` aus `services/komodo-bootstrap/`).
-- **Rollback:** Bootstrap-Verzeichnis loeschen, Komodo-Self-Stack wie vorher.
-
-## Sprint 3 — Backup & Restore belastbar machen (2–3 Wochen)
-
-- **Ziel:** 3-2-1 echt, Restore-Tests breiter, Stack-ENV im DR-Pfad.
-- **Aufgaben:**
-  1. F-03 Zweitziel: Wechselplatten-Rotation dokumentieren ODER zweites Borg-Repo (rsync.net / BorgBase EU2).
-  2. F-20 Stack-ENV-Liste in DR-Doc explizit machen (Restore-Reihenfolge).
-  3. Borg-Verifikation Cron fuer `borg check --repository-only` weekly (STORAGE_LAYOUT 8.4).
-  4. Quartalsweise End-to-End-Restore-Drill in Schedule aufnehmen.
-- **Erfolgskriterium:** Beide Off-Site-Ziele < 7 Tage alt; DR-Doc enthaelt "ENV-Restore-Reihenfolge".
-- **Validierung:** `borg list` gegen beide Repos.
-
-## Sprint 4 — Monitoring & Alerting ausbauen (2 Wochen)
-
-- **Ziel:** Sichtbarkeit auf das, was wirklich weh tut.
-- **Aufgaben:**
-  1. F-08 Alert-Regeln: `BorgArchiveStale`, `TLSCertExpiryNear`, `ContainerDown`, `PostgresConnSaturation`.
-  2. F-15 Healthchecks fuer Traefik, Authelia, Postgres, Komodo, Gitea.
-  3. F-07 Digest-Pin in `monitoring/docker-compose.yml`.
-  4. Family-View-Dashboard in Grafana (1 Panel: Service-Up, 1 Panel: Backup-Frische, 1 Panel: Cert-Tage, 1 Panel: Disk-Fuellung).
-- **Erfolgskriterium:** Family-View zeigt alles gruen; Cert-Alert feuert in Test (Datum vorgespult).
-- **Validierung:** Dashboard sichtbar unter `monitoring.kaleschke.info/d/family-view`.
-
-## Sprint 5 — Auth-Konsolidierung & Frontdoor-Haertung (3–4 Wochen)
-
-- **Ziel:** SSO fuer die Familie, Brute-Force-Bouncer vor oeffentlichen Apps.
-- **Aufgaben:**
-  1. F-13 Authelia OIDC-Provider aktivieren.
-  2. Nextcloud OIDC-Plugin + Test-Login.
-  3. Immich OIDC + Test-Login.
-  4. Grafana OIDC + Test-Login.
-  5. F-14 CrowdSec-Bouncer vor Traefik.
-  6. F-18 Nextcloud-Haertung-Dokument + 2FA-Pflicht.
-- **Erfolgskriterium:** Familien-Konto loggt sich mit einem Login bei drei Apps ein; CrowdSec sperrt Test-IP nach N fehlerhaften Versuchen.
-- **Validierung:** OIDC-Sequenz im Browser ohne Eingabe-Wiederholung; CrowdSec-Dashboard zeigt Sperre.
-
-## Sprint 6 — Automatisierung und Nerd-Level (laufend)
-
-- **Ziel:** Image-Update-Pipeline, optional Staging.
-- **Aufgaben:**
-  1. F-12 Renovate-Bot gegen Gitea.
-  2. F-19 Mem-Limits Tier-1.
-  3. Restore-Test-CI via Gitea Actions (P3).
-  4. Optional: Staging-Branch + zweites Komodo-Ziel in Tailscale-VM (P3).
-  5. Optional: Firefly III / Actual Budget fuer `/mnt/user/finance`.
-- **Erfolgskriterium:** Renovate-PRs erscheinen woechentlich; mindestens ein automatisches Patch-Update gemerged.
-
----
-
-# H. Fehlende Informationen
-
-> Nur, was den Audit konkret schaerfer machen wuerde.
-
-| Frage | Warum | Bereich | Kommando / Datei |
-|---|---|---|---|
-| CPU-Modell, RAM-Groesse, Mainboard | Hardware-Bewertung, OOM-Risiko, Immich-ML-Eignung, AVX-Verfuegbarkeit | Hardware | `cat /proc/cpuinfo \| grep -E 'model name\|flags'`, `free -h`, `dmidecode -t baseboard \| head -20` |
-| USV vorhanden? Modell? | DR-Beurteilung Power-Loss, Shutdown-Pfad | Hardware/DR | physische Sichtpruefung; `apcaccess` falls APC mit NUT |
-| Stromverbrauch idle / Last | Betriebskosten, Sizing | Hardware | Smartmeter / Tibber-API |
-| NIC-Speed (1 GbE? 2.5 GbE?) | Backup-Durchsatz, Plex-Streaming | Netzwerk | `ip -br link`, `ethtool eth0` |
-| Disk-Inventar (Anzahl, Modelle, Alter) | Storage-Health, Replacement-Plan | Storage | `lsblk -o NAME,SIZE,MODEL,SERIAL`, Scrutiny-UI |
-| Aktueller Cache-Fuellstand | Wann zweite NVMe? | Storage | `df -h /mnt/cache` |
-| FritzBox-Modell + Firmware | Net-Sicherheit, VLAN-Faehigkeit | Netzwerk | FritzBox-UI / `fritzconnection` |
-| Tatsaechlich genutzte Plex- vs. ungenutzte App | Konsolidierungs-Belege | App-Landschaft | Plex-Server-Logs, ggf. Glances-Container-CPU pro Stack |
-| Existiert `/mnt/user/finance/`-Share schon? | Ist Firefly-Vorbereitung trivial? | Storage | `ls /mnt/user/finance/` |
-| Authelia Live-User-DB-Tiefe (Anzahl User, 2FA-Status) | 2FA-Coverage-Bewertung | Security | `cat /mnt/user/appdata/authelia/config/users_database.yml` (nur Strukturansicht, keine Hashes hier zitieren) |
-| Komodo-Mongo-Dump letzter Integrity-Check | F-09-Vorbereitung | Backup | `mongorestore --dry-run --archive=komodo-mongo.archive.gz --gzip` |
-| Aktuelle Cert-Restlaufzeit | F-08-Test-Vorbereitung | Operations | `openssl s_client -connect git.kaleschke.info:443 -servername git.kaleschke.info < /dev/null \| openssl x509 -noout -dates` |
-
----
-
-# I. Pruefkommandos (Linux / Unraid / Docker / Windows)
-
-> Strukturiert nach Bereich. Sicher zum Ausfuehren am Host.
-
-### Hardware
-
-```bash
-# CPU + Flags (AVX fuer Immich-ML)
-cat /proc/cpuinfo | awk '/model name|flags/ {print; if(/flags/) exit}'
-
-# RAM
-free -h
-dmidecode -t memory | grep -E "Size|Speed" | head -20
-
-# Mainboard
-dmidecode -t baseboard | head -20
-
-# PCI / SATA / NVMe
-lspci
-nvme list
-lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT,VENDOR
-
-# SMART
-smartctl -a /dev/nvme0n1 | head -40
-smartctl -a /dev/sdb | head -40
-
-# Stromverbrauch (Unraid Plugin oder ipmitool falls IPMI)
-sensors | head -30
-```
-
-### Filesystem / Storage / Mounts
-
-```bash
-# Filesystem-Typen (Hard Rule 12.1)
-findmnt -no FSTYPE /mnt/cache /mnt/disk1 /boot
-mount | grep -E "ntfs3|fuseblk"   # darf leer sein
-
-# Share-Settings
-ls -la /boot/config/shares/
-
-# Cache-Fuellstand
-df -h /mnt/cache /mnt/disk1 /mnt/user
-du -sh /mnt/user/appdata/* | sort -hr | head -20
-```
-
-### Docker
-
-```bash
-# Container-Inventur
-docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}" | sort
-docker ps -a --filter "status=exited" --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"
-
-# Netzwerke
-docker network ls
-docker network inspect frontend_net | jq '.[0].Containers | keys'
-docker network inspect backend_net | jq '.[0].Internal'
-
-# Volumes ohne Container (Waisen)
-docker volume ls -qf dangling=true
-
-# Effektive Ports
-ss -ltnp | sort -k4
-
-# Healthchecks
-docker ps --format "{{.Names}}\t{{.Status}}" | grep -E "healthy|unhealthy|starting"
-```
-
-### Security
-
-```bash
-# Privileged-Container und Docker-Socket-Mounts
-for c in $(docker ps -q); do
-  docker inspect "$c" --format '{{.Name}}: priv={{.HostConfig.Privileged}}; sock={{range .HostConfig.Binds}}{{println .}}{{end}}'
-done | grep -E "priv=true|docker.sock"
-
-# Direkte Host-Ports
-docker ps --format "{{.Names}}: {{.Ports}}" | grep -v "^[^:]*: $"
-
-# Secret-Datei-Rechte
-ls -la /mnt/user/appdata/secrets/
-stat -c "%a %n" /mnt/user/appdata/secrets/*.txt
-```
-
-### Backup / Restore
-
-```bash
-# Borg-Frische
-ls -lat /mnt/user/backups/borg/dumps/latest/ | head
-find /mnt/user/backups/borg/dumps/latest -mmin +1440 -type f   # aelter 24h
-
-# Borg-Repo (Passphrase per File)
-export BORG_PASSPHRASE=$(cat /mnt/user/appdata/secrets/borg_repo_passphrase.txt)
-borg list ssh://... --short | tail -5
-borg info ssh://... ::Taegliche-Sicherung-2026-05-25T05:52:44.157
-
-# Posture-Check
-cat /mnt/user/services/posture-check/last.json | jq '.warning_count, .critical_count'
-```
-
-### Netzwerk / DNS
-
-```bash
-# Tailscale
-tailscale status
-
-# DNS auf AdGuard testen
-dig @127.0.0.1 git.kaleschke.info
-dig @127.0.0.1 example.com   # Unbound-Recursion
-
-# Cert-Restlaufzeit
-for h in vault git immich cloud paperless mealie ntfy; do
-  echo -n "$h.kaleschke.info: "
-  openssl s_client -connect ${h}.kaleschke.info:443 -servername ${h}.kaleschke.info </dev/null 2>/dev/null \
-    | openssl x509 -noout -dates 2>/dev/null
-done
-```
-
-### GitOps-Konsistenz
-
-```bash
-# Komodo Stack-Workspace vs. Repo
-cd /mnt/user/services/stacks/<stackname>
-git rev-parse HEAD
-git status --short
-
-# Webhook-Liveness
-docker logs komodo-core 2>&1 | grep -i "webhook\|deploy" | tail -20
-```
-
-### Windows (lokal)
-
-```powershell
-# Repo-Status
-git status --short
-git fetch origin
-git log origin/master..HEAD --oneline   # ungepushte Commits
-git log HEAD..origin/master --oneline   # ungepullte Commits
-
-# Policy-Check
-.\ops\policy-checks\check_repo.ps1
-
-# Restore-Freshness
-.\ops\restore-tests\check-restore-freshness.ps1
-```
-
----
-
-# J. Community- / Best-Practice-Abgleich
-
-> Nur fuer die Architekturentscheidungen, bei denen der Markt eindeutig ist oder Gegenpositionen relevant sind.
-
-| Entscheidung | Markt-Best-Practice | Stuetzende Quellen | Bewertung |
-|---|---|---|---|
-| Traefik mit Docker-Labels statt File-Provider | Standard in Selfhosted (siehe `awesome-selfhosted-docker`, Smarthome-Beginner Templates) | Traefik-Doc v3 docs.traefik.io/providers/docker | passt zu MASTER 13 (Wechsel 2026-03-28) |
-| DNS-Challenge mit Cloudflare statt HTTP-01 | Standard fuer Wildcard und reduzierte Angriffsflaeche | acme.sh / lego docs | passt, korrekt |
-| Authelia ForwardAuth statt Authentik | Authelia ist leichtgewichtiger, Authentik maechtiger; beide valide | r/selfhosted-Konsens 2024-25 | Authelia richtig fuer Single-Family-Setup |
-| Authelia ohne Redis-Session-Backend | Markt-Standard ist mit Redis; deine Vereinfachung ist begruendet (MASTER 13 2026-05-04) | Authelia-Doc | Trade-off klar; Bewertung: vertretbar fuer Homelab |
-| Komodo statt Portainer/Dockge | Komodo ist neuer (2024), Dockge etabliert, Portainer kommerziell | Selfh.st 2025 Comparison | Komodo legitim, mehr GitOps-nativ als Dockge |
-| Borg statt Restic/Kopia | Borg ist klassische Wahl fuer Linux-Backup mit Deduplikation; Kopia/Restic gewinnen mit Multi-Backend | r/datahoarder, ServeTheHome 2024 | Borg passt zu Unraid-Stack; bewusste Vereinfachung |
-| Glance statt Homepage als Single-Dashboard | beide auf Augenhoehe; Homepage etablierter, Glance moderner, schneller, mit Live-Widgets | github.com/glanceapp/glance vs. github.com/gethomepage/homepage | Glance legitim; Bewertung: deine Wahl ist verteidigbar |
-| Immich nicht hinter Authelia ForwardAuth | offizielle Immich-Doku raet bei nativer App-Auth davon ab, weil Sync-Clients OIDC oder direkte Auth brauchen | immich.app/docs/administration/reverse-proxy | korrekt; OIDC spaeter (F-13) ist der Weg |
-| Nextcloud klassisch statt AIO | NC-AIO ist offizielle Empfehlung fuer Neuaufbau, klassisch hat mehr Flexibilitaet fuer GitOps | NC-Blog 2024 | bewusste Ausnahme MASTER 13; vertretbar, da GitOps-Anbindung wichtiger |
-| Single-Host + Borg statt Proxmox-Cluster + ZFS-Send | fuer Familien-Homelab ist Cluster Overkill | r/homelab, LTT-Forum | Single-Host korrekt; Cold-Standby (Sprint 6) ist die richtige naechste Stufe |
-| AdGuard + Unbound statt Pi-hole | aequivalent; AdGuard hat moderne UI, Unbound recursion | gowri/networkchuck Tutorials 2024 | passt |
-| Posture-Check als Skript statt Goss/InSpec | fuer Single-Host pragmatisch | Goss ist maechtiger, aber Overkill | Skript-Loesung legitim |
-| Renovate gegen Gitea | mehrere Erfahrungsberichte in Gitea-Issues + Renovate-Docs | docs.renovatebot.com/modules/platform/gitea/ | Standard-Pfad |
-| CrowdSec vor Traefik | starker Trend 2024-25 in Selfhosted-Community | crowdsec.net/blog, Marius-Hosting-Tutorials | sinnvolle Haertung |
-
-**Gegenpositionen, die du kennen solltest:**
-
-- **"Authelia OIDC ist kompliziert, lieber Authentik."** Korrekt, wenn du auch B2B-SAML brauchst. Fuer reine Familien-OIDC ist Authelia leichter wartbar.
-- **"CrowdSec laedt zentrale Reputation-Listen -> Privacy-Bedenken."** Stimmt, du kannst Local-Only-Mode fahren. Fuer Homelab egal.
-- **"Renovate-Bot erzeugt Laerm."** Mit Group/Schedule-Rules zaehmbar. Wert > Laerm.
-- **"Komodo ist zu jung."** Gegenargument: du benutzt es seit Q1/2026 produktiv, Major-Inzidenz war beherrschbar. Der Wechsel zurueck zu Portainer/Dockge waere hoehere Kosten als der Reifegrad-Nachteil.
-
----
-
-# K. Endziel — "Nerd-Level Homelab"
-
-So sieht dein Homelab aus, wenn es wirklich auf Senior-Level ist:
-
-**Betrieb im Alltag**
-
-- Morgens 30 Sekunden auf `monitoring.kaleschke.info`: Family-View zeigt 7 Tier-1-Services gruen, Backup-Job in der Nacht hat 100 % Files erfasst, alle Certs > 30 Tage, Disk < 80 %.
-- Push-Benachrichtigung auf dem Handy nur, wenn wirklich etwas brennt (Posture-Check critical, Borg > 30 h, Endpoint down ≥ 8 Min, Cert < 14 Tage).
-- Familienmitglieder loggen sich mit einem Login bei Nextcloud, Immich, Mealie ein. 2FA per TOTP-App, kein App-by-App-Passwortzettel mehr.
-
-**Updates**
-
-- Renovate oeffnet woechentlich 5–10 Pull-Requests in Gitea fuer Patch-Versionen. Du siehst sie im Web-UI, pruefst Release Notes, klickst Merge. Komodo deployt automatisch via Webhook. Smoke-Test in der naechsten Glance-Seite.
-- Major-Updates kommen separat mit Label `major`, behandelst du in einem geplanten Slot mit Restore-Snapshot davor.
-
-**Backups**
-
-- Borg lokal alle 6 h, Borg Hetzner taeglich, Wechselplatte monatlich. Borg-Passphrase auf Papier im Bankschliessfach. Alle drei Ziele juenger als 36 h Alert-Schwelle.
-- Pre-Dump-Hooks erzeugen 15 konsistente Dump-Artefakte pro Lauf, automatische Posture-Check-Vor-Hook bricht Backup ab, wenn FS oder Mount sich veraendert haben.
-
-**Restore**
-
-- Monatlicher Mini-Restore-Test fuer Vaultwarden/Gitea/Paperless/Immich nach `/mnt/user/backups/restore-lab/<dienst>/` laeuft automatisiert per Gitea Actions, Erfolgs-Report landet als Datei + ntfy-Info.
-- Quartalsweise End-to-End-Drill: ein kompletter Stack restauriert, App startet, Smoke-Test passt, Doku validiert. Komodo-Bootstrap-Pfad ist getestet.
-- Im Ernstfall folgst du `docs/DISASTER_RECOVERY.md` Phase 0–5 und bist nach < 8 h wieder im Vollbetrieb. Repo-Bootstrap aus GitHub-Mirror, Stacks in Stufen 1–5, Verifikation pro Stufe.
-
-**Monitoring**
-
-- Prometheus + Loki + Grafana + Alertmanager-ntfy-Bridge. ~15 Alert-Regeln, alle in `alerts.yml` versioniert.
-- Family-View, Host-Overview, Containers+Logs, Traefik-Standalone, Backup-Frische, Cert-Tage. Sechs Dashboards mehr braucht keine Familie.
-- Loki sammelt 30 Tage Logs aus allen Containern via Promtail. cAdvisor + node-exporter liefern Container- und Host-Metriken. Blackbox testet oeffentliche Endpoints alle 60 s.
-
-**Security**
-
-- Authelia OIDC fuer Nextcloud, Immich, Grafana, Mealie. ForwardAuth fuer Operator-UIs mit 2FA-Pflicht ab Tier-2.
-- CrowdSec sperrt Brute-Force-IPs auf Traefik-Ebene bevor sie die Apps treffen.
-- AdGuard-Admin nur via Tailscale. Operator-Pfad ausschliesslich Tailscale.
-- Authelia-Repo-Baseline und Host-Config sind per Diff-Check im posture-check abgesichert.
-- Secrets-Mounts mode 600, Borg-Passphrase analog.
-
-**Dokumentation**
-
-- SERVICE_CATALOG, RESTORE_MATRIX, DISASTER_RECOVERY, STORAGE_LAYOUT, SECRETS_MAP, WORKFLOW, GITOPS_DRIFT_RUNBOOK, ALERTING_MAP, HOMELAB_ARCHITECTURE_MASTER bleiben aktuelle Single-Source-of-Truth.
-- `services/komodo-bootstrap/` loest das Henne-Ei. `SERVICES_RECOVERY.md` ist final, nicht Draft.
-- Familien-Onboarding-Doku als Markdown: "So nutzt du Nextcloud-Web", "So aktivierst du Immich-Foto-Backup auf dem Handy", "So loggst du dich neu per 2FA ein".
-
-**Taegliche Nutzung**
-
-- Familie scannt Briefe per ASN-Barcode in `scans_inbox/`, Paperless tagged via paperless-gpt automatisch, alles durchsuchbar.
-- Immich erfasst Smartphone-Fotos aller Familienmitglieder automatisch, Familie blaettert per Web/App, Tagging per ML.
-- Nextcloud traegt Kalender, Kontakte, geteilte Familienordner per WebDAV/CardDAV — kein Google/Apple-Lock-In.
-- Mealie speichert Rezepte, Einkaufsliste auf dem Handy.
-- Vaultwarden ist der einzige Passwort-Tresor der Familie; Familien-Organisation aktiv.
-- Plex streamt Heim-Medien an alle Endgeraete.
-- ntfy schickt dir Vorfaelle aufs Handy — und sonst nichts.
-- Optional: Firefly III fuer die Familien-Finanzen, Ecowitt-Wetter-Dashboard, Home-Assistant-Automationen fuer Strom-Eigenverbrauch.
-
-**Was bewusst weggelassen ist**
-
-- Kein Kubernetes. Komodo + Compose reicht.
-- Kein zweiter Medienserver neben Plex (Jellyfin-Entscheidung 2026-05-25).
-- Kein zweites Dashboard neben Glance (Homepage-Entscheidung 2026-05-25).
-- Kein Uptime-Kuma neben Blackbox (Entscheidung 2026-05-25).
-- Kein Hermes-Agent, wenn er bis 2026-07-25 keinen klaren Alltagsnutzen liefert.
-- Kein BentoPDF/paperless-gpt 24/7, wenn nicht aktiv genutzt.
-- Kein Self-Stack-Komodo (durch `services/komodo-bootstrap/` ersetzt).
-
----
-
-## Schlussbemerkung
-
-Das Setup ist naeher an Senior-Reife als an Bastel-Niveau. Der groesste Hebel der naechsten drei Monate ist **Konsolidieren statt erweitern** (Hermes-Entscheidung, Altstaende raus, Auth-SSO, Off-Site-Diversitaet), kombiniert mit der einen Aktivierung, die das Setup vom Operator-Tool zum **Familien-Tool** macht: Immich-Smartphone-Backup fuer alle.
-
-Das vorhandene 2026-05-23-Audit hat die richtigen Sprintziele bereits identifiziert. Diese externe Audit-Sicht ergaenzt:
-
-- **2FA-Pflicht auf Tier-1-Operator-UIs** (F-04) — fehlt in der Bewertung 2026-05-23 in dieser Klarheit.
-- **Healthcheck-Luecke** (F-15) und **fehlende Mem-Limits** (F-19) — operative Detail-Findings, die in der strategischen Bewertung nicht auftauchen.
-- **Komodo-Self-Bootstrap als konkreter Code-Vorschlag** (F-09) statt nur als Risiko-Erwaehnung.
-- **Authelia-Drift-Detection automatisieren** (F-10) statt nur "manuell merge".
-- **Monitoring-Stack ohne Digest-Pin** (F-07) — Inkonsistenz mit der eigenen Image-Pinning-Disziplin.
-- **`infra/redis` ist faktisch nicht shared** (F-16) — Etikett-Realitaet-Drift.
-- **Alert-Regeln deutlich zu duenn** (F-08) — Sichtbarkeitsluecken bei Cert/Borg/Container-Down.
-
-Wenn Sprint 1–3 in 4–6 Wochen sitzen, bist du auf einer 1-Note. Wenn dann Sprint 4–5 in weiteren 6–8 Wochen kommen, hat die Familie ein echtes Self-Hosting-System, kein "Container-Sammlung im Keller". Das ist der Unterschied, den der Audit-Auftrag adressiert.

docs/AUDIT_2026-05-25_TODO.md

@@ -1,137 +1,68 @@
-# Audit TODO 2026-05-25
+# Audit-Restliste 2026-05-25
 
-Quelle: `docs/AUDIT_2026-05-25.md`
+Status: **kompakte Restliste**. Die erledigten Sprint-Tabellen und langen
+Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Git.
 
-Status: Arbeitsliste fuer die Umsetzung. Authelia-2FA/OIDC, CrowdSec und Nextcloud-2FA-Haertung bleiben ganz hinten und werden bewusst nicht in diesem Audit-Zyklus angefasst.
+Letzter Sync mit `docs/MASTER_TODO.md`: 2026-06-05. Offene Punkte sind deckungsgleich;
+neue Restore-Runbook-Stubs (Unraid Flash / AdGuard / Tailscale / Redis 8) wurden
+in `docs/RESTORE_MATRIX.md` ergaenzt.
 
-## Leitplanken
+## Aktuell offene Punkte
 
-- Authelia-2FA-ACL, Authelia-OIDC und CrowdSec werden in diesem Audit-Zyklus **nicht** umgesetzt (Operator-Vorgabe 2026-05-26).
+| Prioritaet | Punkt | Naechster Schritt |
-- Keine Live-riskanten Bind-/Port-Aenderungen ohne vorher erfasste Host-Werte, insbesondere Tailscale-IP.
-- Hermes-Agent ist geparkt, nicht entfernt; Review-Deadline 2026-07-25.
-- USV-Anschaffung ist verschoben; Power-Loss-Risiko ist als Operator-Entscheidung 2026-05-26 bewusst akzeptiert.
-- Borg-Passphrase ist offline gesichert (bestaetigt 2026-05-26).
-- H:/ ist evaluiert als zweite lokale Nearline-Kopie, nicht als Offsite-Ersatz (siehe `docs/CAPACITY_AND_LIFECYCLE.md`).
-- Familien-Einladung ist fuer das Wochenende **nach** Erreichen des finalen Stands geplant; Family-Onboarding muss familienverstaendlich werden, nicht technisch.
-- Jede produktive Aenderung bekommt Validierung und Rollback-Hinweis.
-
-## Naechster Startpunkt 2026-05-26
-
-Kontext bewusst gesichert, bevor weitere Live-Aenderungen passieren:
-
-1. Host-Schedule fuer Gitea-Bundles und Restore-Freshness pruefen.
-2. FRITZ!Box-Portfreigaben (UI) gegen Repo-Soll abgleichen (`443/tcp` + `222/tcp`).
-3. H:/ Pull-Workflow festlegen.
-4. Family-Onboarding-Doku familienverstaendlich umarbeiten, vor der Wochenend-Einladung.
-5. Authelia 2FA/OIDC und CrowdSec weiterhin nicht anfassen; bleibt bewusst der letzte Block.
-
-## Sprint 0 - Inventar und Baseline
-
-| Status | Aufgabe | Ergebnis |
 |---|---|---|
-| erledigt | Hardware-Inventar ausfuellen | CPU, RAM, Mainboard, BIOS, NIC, Controller, Disks, SMART und Capacity-Baseline erfasst; USV ist als nicht validiert dokumentiert |
+| P2 | Family-Onboarding praktisch starten | Fokus: Vaultwarden als Passwortbasis, Immich-Mobile-Backup auf jedem Handy, Mealie mit erstem Rezept/Einkaufsliste; Ablauf steht in `docs/FAMILY_ONBOARDING.md` |
-| erledigt | Netzwerk-Inventar ausfuellen | Host-IP, Gateway, Tailscale-IP, AdGuard-Bind und FRITZ!Box-Baseline (7590, FRITZ!OS 8.21, Telekom DSL 87/36, 36 Geraete, Gast-WLAN inaktiv, Ausfallschutz inaktiv, 2 Portfreigaben aktiv) erfasst; IPv6 und FRITZ!OS-Update bleiben Operator-Folgeaufgaben |
-| erledigt (Baseline) | Externe Abhaengigkeiten dokumentieren | `docs/EXTERNAL_DEPENDENCIES.md` enthaelt bekannte Provider, Kritikalitaet, Ausfallplaene; Account-Recovery-Codes/Zahlungswege bleiben Off-Repo-Operatorcheck |
-| erledigt (Baseline) | Services-Recovery-Pfade beschreiben | `docs/SERVICES_RECOVERY.md` enthaelt Gitea-/Komodo-/Secrets-Sonderpfade; Gitea-Bundle-/Mirror-Mechanik bleibt als Umsetzungsentscheidung offen |
-| erledigt | Baseline-Tag setzen | `audit-2026-05-25-baseline` ist lokal und remote vorhanden |
-| erledigt | Policy-Check neu ausfuehren | SEC001-Warnings aus altem Report sind nicht mehr aktuell |
 
-## Sprint 1 - Nicht-kontroverse Sicherheits- und Repo-Hygiene
+## Restore-Audit Backlog (Stand 2026-06-03)
 
-| Status | Aufgabe | Ergebnis |
+Ergebnis des Restore-Skills-Audits (Session 2026-06-02/03). Die kritischen Bugfixes (Cron-OR-Semantik, ntfy-Race, Cleanup-Trap, Pfad-Inkonsistenz, Vaultwarden-Token, Paperless-Retry, Header-Validierung, Authelia-Test) sind erledigt und committed. Die folgenden Punkte sind bewusst offener Backlog:
-|---|---|---|
-| erledigt | Borg-Passphrase analog sichern | Operator bestaetigt am 2026-05-26: Passphrase ist offline gesichert und ohne Host/Vaultwarden wiederherstellbar |
-| erledigt (repo) | AdGuard Admin-Bind vorbereiten | Tailscale-IP `100.80.98.33` erfasst, Compose-Soll geaendert |
-| erledigt | AdGuard Admin-Port auf Tailscale-IP binden | Live validiert: `ss -ltnp` zeigt `100.80.98.33:8082`, DNS auf Port 53 funktioniert, LAN-Zugriff auf `192.168.178.58:8082` schlaegt fehl |
-| erledigt | Alte Monitoring-Verzeichnisse entfernen | `ops/grafana-influxdb/` und `ops/loki/` sind aus dem aktiven Repo entfernt; Rollback erfolgt ueber Git-Historie |
-| erledigt | Komodo/Gitea-Restdrift bereinigen | alter Komodo-Stack `grafana` ist inert und ohne Repo-Pfad/Webhook; Gitea-Hook `35` und `komodo`-Self-Hook `11` sind inaktiv; aktive Gitea-Hooks haben keine Fehlstatus |
-| erledigt | Policy-Warnings triagieren | Plex Host-Netz und digest-gepinnte mutable Tags sind dokumentierte Info-Ausnahmen; `monitoring-influxdb3-core` als Root-Ausnahme bleibt bewusst als Warning sichtbar |
 
-## Sprint 2 - Storage und Recovery verbindlich machen
+| Prioritaet | Punkt | Status | Naechster Schritt |
+|---|---|---|---|
+| P1 | Nextcloud-Restore-Test | **erledigt 2026-06-03** | Borg-Extract + pg_restore (126 Tabellen) + HTTP 200 + `occ status maintenance:false`. Quelle: `hetzner_borg_appdata_critical`, Archiv `Taegliche-Sicherung-2026-06-03T04:30:41.432`. Zwei Skript-Bugs im Zuge des Laufs gefixt (`check_data_directory_permissions: false` patchen, `.ncdata`-Marker anlegen). Report `/mnt/user/backups/restore-reports/nextcloud-2026-06-03.md`. |
+| P1 | Shared PostgreSQL 18 Cluster Restore Drill | **erledigt 2026-06-03** | Globals + 5 DBs (paperless 72t, mailarchiver 1t, authelia 25t, nextcloud 126t, mealie 66t), `data_checksums=on`, Report `/mnt/user/backups/restore-reports/shared-pg-cluster-2026-06-03.md` |
+| P1 | Komodo-Mongo-Daten-Restore | **erledigt 2026-06-03** | 86904 Dokumente erfolgreich restored, Report `/mnt/user/backups/restore-reports/komodo-mongo-restore-2026-06-03.md`. Nebenbefund: Dump von Mongo 8.0.23, Test auf 7.0.32 — Cross-Version-Warning, fuer Lesetest harmlos |
+| P2 | Mailarchiver-Restore-Test | **erledigt 2026-06-03** | Data-Protection-Keys + 645M pg_restore + HTTP 200. Report `/mnt/user/backups/restore-reports/mailarchiver-2026-06-03.md` |
+| P2 | Mealie-Restore-Test | **erledigt 2026-06-03** | Borg-Data + pg_restore + HTTP 200, 3 Rezepte. Report `/mnt/user/backups/restore-reports/mealie-2026-06-03.md` |
+| P2 | Traefik-Restore-Test | **erledigt 2026-06-03** | dynamic/ + letsencrypt/ aus Borg, File-Provider + Ping 200. CF-Token bewusst nicht im Smoke. Report `/mnt/user/backups/restore-reports/traefik-2026-06-03.md` |
+| P3 | Negativ-Test fuer Frische-Check | offen | Einmal pro Quartal bewusst kaputten Dump einfuettern und pruefen ob `homelab-alerts` feuert |
+| P3 | End-to-end-DR-Drill | offen | Komplett-Bootstrap Phase 1-5 auf einem Wegwerf-Host; realistisch nur mit zweiter Hardware |
 
-| Status | Aufgabe | Ergebnis |
+## Bewusst geparkt
-|---|---|---|
-| erledigt | `docs/STORAGE_LAYOUT.draft.md` finalisieren | Datei als `docs/STORAGE_LAYOUT.md` Active v1.4 gefuehrt; Draft-Blocker entfernt |
-| erledigt (Baseline) | Disk- und Share-TBDs eintragen | Disk-Modelle, Seriennummern, Groessen, Filesysteme und Share-Cache-Settings aus `docs/HARDWARE_INVENTORY.md` und Host-Readout 2026-05-27 uebernommen; Retention-/Schwellen-Kalibrierung bleibt Folgeaufgabe |
-| erledigt | Gitea-Repo-Mirror-Mechanik definieren | `ops/borg-ui/scripts/gitea-bundle-mirror.sh` erzeugt verifizierte Bundles unter `/mnt/user/backups/git-bundles/gitea`; Host-Erstlauf 2026-05-26: 4 Bundles, Checksums OK, `homelab-infra.bundle` klonbar und `git fsck` sauber. Schedule live seit 2026-05-27 ueber User-Script `gitea-bundle-mirror-6h` (`10 */6 * * *`); Bundles werden mit `chmod 644` geschrieben damit der Nearline-Pull sie greift. |
-| erledigt (Doku + Skript + Erstlauf) | Komodo-Bootstrap-Pfad beschreiben | `docs/SERVICES_RECOVERY.md` enthaelt linearen Bootstrap in Stufen A-F mit Recovery-Anker `ops/komodo/docker-compose.yml`, expliziter Abgrenzung zum Self-Stack, Secret-Reihenfolge und Validierungs-Kommandos; `docs/DISASTER_RECOVERY.md` Stufe 3 verlinkt auf Bootstrap-Pfad. Trockenlauf-Skript unter `ops/restore-tests/komodo-bootstrap-*` seit 2026-05-29 vorhanden, Erstlauf 2026-05-30 erfolgreich (siehe Sprint 8 Eintrag). |
-| erledigt | Immich-Restore-Test planen | Testumfang, Datenpfade und Smoke-Test-Kriterium sind in `docs/IMMICH_RESTORE_TEST.md`, `ops/restore-tests/immich-plan.md` und `ops/restore-tests/immich-runbook.md` festgehalten; erster Host-Lauf am 2026-05-27 erfolgreich |
 
-## Sprint 3 - Restore und Monitoring
+| Punkt | Entscheidung |
+|---|---|
+| Authelia 2FA fuer Operator-UIs (Rest) | Tier-1-Operator-UIs sind 2026-06-03 auf `two_factor` gehoben (`files`, `scrutiny`, `borg`, `code`). Restliche Admin-UIs (`monitoring`, `glances`, `glance`, `speedtest`, `paperless-gpt`, `pdf`, `mail`, `hermes`, `sp`) bleiben bewusst auf `one_factor`, bis die finale Auth-Policy steht. |
+| Authelia OIDC fuer Apps | Geparkt bis klare Familien-/SSO-Entscheidung |
+| CrowdSec vor Traefik | Bewusst nicht umgesetzt: einzige WAN-Tuer ist `443/tcp`, Operator-Pfad ist Tailscale, Authelia-`regulation:` deckt Auth-Brute-Force ab. Neu bewerten bei breiterer Attack Surface. |
+| Nextcloud 2FA/Brute-Force-Haertung | UI-Schritt fuer Operator-Account (`twofactor_totp` aktivieren) bleibt offen. App-weite Familien-Policy gemeinsam mit OIDC entscheiden. |
+| Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 |
+| USV | Anschaffung verschoben; Power-Loss-Risiko bewusst akzeptiert |
+| Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz |
+| Borg `append-only` auf Hetzner | Operator-Entscheidung 2026-06-01: nicht umgesetzt. Der forced-command-Test auf der Storage Box brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Nutzen steht fuer dieses Homelab nicht im Verhaeltnis zum Betriebsrisiko. |
 
-| Status | Aufgabe | Ergebnis |
+## Zuletzt geschlossen
-|---|---|---|
-| erledigt | Immich-Restore-Test implementieren | Echter Host-Lauf 2026-05-27 erfolgreich: Borg-Archiv `Tägliche-Sicherung-2026-05-27T04:30:06.778`, `immich.dump` extrahiert, isolierter pgvecto-rs-Postgres importiert, Immich-Server ohne ML gestartet, HTTP `200`, Login-Marker ok, `11977` Assets und `1` User im Test-DB-Check; Report `/mnt/user/backups/restore-reports/immich-2026-05-27.md` |
-| erledigt | Borg-Stale-Alert bauen | Cron `*/5 * * * *` (`export-prometheus-textfile-5min` User-Script) schreibt `homelab.prom`; node-exporter scraped, Prometheus laedt Regel `HomelabBorgBackupStale` aktiv. Live 2026-05-27 20:33 reloaded; `lastConfigTime: 2026-05-27T18:33:06Z`; Smoke-Query `(time() - homelab_borg_last_completed_timestamp_seconds)/3600 = 16h`. Borg-Job-Warning ist aktuell `pending` (Letzter Lauf `completed_with_warnings`). |
-| erledigt | TLS-Cert-Expiry-Alert bauen | Regeln `HomelabCertificateExpiresSoon` (21d) und `HomelabCertificateExpiresCritical` (7d) sind in `alerts.yml` aktiv und nach Prometheus-Reload geladen. Smoke `inactive` (keine Cert <21d). |
-| erledigt | Container-Down-Alert bauen | `HomelabCriticalContainerDown` aktiv; Live-Smoke 2026-05-27 `sum(homelab_critical_container_running) = 30`, alle aktuellen Critical-Container `1`. Aktualisierung alle 5 Min ueber Cron. |
-| erledigt (Spezifikation) | Family-View Dashboard definieren | `docs/FAMILY_VIEW_DASHBOARD.md` enthaelt Layout, PromQL-Queries, Thresholds und Build-Reihenfolge fuer ein `homelab-family-view`-Dashboard. JSON wird bewusst erst angelegt, sobald Borg-Stale-/Cert-Expiry-/Container-Down-Metriken stabil live sind und ein manueller Build im Grafana-UI das Layout bestaetigt hat. |
 
-## Sprint 4 - Familien- und Betriebsdoku
+- DR-Workstation Bare-Metal-Kit abgeschlossen (2026-06-06): WSL2 Ubuntu 24.04, SSH/Git, Borg 1.2.8, DR-Key-Arbeitskopien `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`, `~/dr-smoke.sh`. Finaler Operator-Smoke erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`), Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. Borg-Passphrase wurde nur interaktiv eingegeben und nicht gespeichert.
-
+- Nextcloud-Restore-Test 2026-06-03 erfolgreich (Tier-2 damit komplett belegt). Drei Laeufe noetig: Lauf 1 schlug an `chmod()` der data-Dir auf shfs fehl (`OC_Util.php:486`), Lauf 2 an fehlender `.ncdata`-Marker-Datei, Lauf 3 sauber durch. Beide Bug-Fixes ins Skript `ops/restore-tests/nextcloud-restore-test.sh` integriert. Endresultat: HTTP 200 auf `/status.php`, `occ status` ok, 126 Tabellen in der DB. Source: `hetzner_borg_appdata_critical`, Archiv `Taegliche-Sicherung-2026-06-03T04:30:41.432`. Report unter `/mnt/user/backups/restore-reports/nextcloud-2026-06-03.md`.
-| Status | Aufgabe | Ergebnis |
+- Hetzner Storage Box DR-SSH-Key `dr-hetzner-2026-06-03` (ed25519, Passphrase-frei) angelegt: Pubkey via `install-ssh-key` auf der Storage Box autorisiert, passwortloser Login erfolgreich (Borg-Repos `backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical` sichtbar), Private-Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key abgelegt, Arbeitsplatz-Kopie geloescht. Damit ist Bare-Metal-Borg-Zugang von der DR-Workstation moeglich, sobald WSL2+Borg installiert sind.
-|---|---|---|
+- Fix Common Problems Plugin (FCP) 2026-06-03 deinstalliert. Befund: drei `grep -R ... /usr/local/emhttp`-Prozesse aus einem FCP-Daily-Scan hingen seit ~7 Tagen in einem Symlink-Loop (`/usr/local/emhttp/mnt -> /mnt`, gesamte Array). 3 Cores dauerhaft 100 %, IOWAIT bis 55 %, USB-Flash unter Dauer-IO. Plugin via `plugin remove` entfernt, Cron + /tmp-Reste sauber, Load von 14.6 auf 1.08 gefallen. FCP wird bewusst nicht wieder installiert (Begruendung siehe `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13). Bekannte Risiken decken Scrutiny, Monitoring, Posture-Check und Critical-Events-Watcher bereits ab.
-| erledigt (final vor Einladung) | Familien-Onboarding schreiben | `docs/FAMILY_ONBOARDING.md` ist final redigiert: familienverstaendliche Sprache, App-eigene 2FA statt SSO-Versprechen, neuer "Bewusst nicht versprochen"-Block (kein Einheits-Login, kein 24/7-SLA, kein Hotline-Support, keine Datenweitergabe), konkrete Was-tun-Anleitungen. Einladungstermin bleibt Operator-Aufgabe. |
+- GitHub-Mirror Read-Only Deploy-Key `DR Read-Only 2026-06-03` (ed25519, Passphrase-frei) angelegt: GitHub Repo Settings -> Deploy Keys ohne Write-Access, Smoke `git ls-remote` erfolgreich (HEAD `d947c7f` = master), Private-Key offline neben der KOMODO_*-Notiz abgelegt, Arbeitsplatz-Kopie nach USB-Transfer geloescht. Damit ist der DR-Read-Pfad zum privaten Mirror ohne Operator-Browser-Login moeglich.
-| erledigt (Baseline) | Capacity-/Lifecycle-Review erstellen | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; H:/-Nearline-Bewertung ergaenzt; externe Cold-Storage-Groessen bleiben offen |
+- KOMODO_*-Notiz offline gesichert (Operator-Bestaetigung 2026-06-03). Quelle bleibt host-seitige `.env` unter `/mnt/user/services/stacks/komodo/.env` bzw. die Drift-Recovery-Kopie unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env`. Damit ist der Bare-Metal-Komodo-Bootstrap ohne Vaultwarden moeglich. Eintrag in `docs/EXTERNAL_DEPENDENCIES.md` Reviews und Pflichtbestandteil im DR-Workstation-Kit nachgezogen.
-| erledigt | USV-Test oder USV-Entscheidung | Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung; Power-Loss-Risiko wird bewusst akzeptiert und dokumentiert |
+- DR-Tabletop 2026-06-03 durchgelaufen, Findings in `docs/DR_DRILL_2026-06-03.md` (23 Befunde: 1 CRITICAL, 11 HIGH, 8 MED, 3 LOW). Reine Doku-Fixes in DR.md (Phase 0 Mirror-Klarstellung, neue Phase 4 Stufe 0 Docker-Netze, LE-Staging-Hinweis, Komodo-Stolperfallen, App-DB-Verify in Phase 5) und in `EXTERNAL_DEPENDENCIES.md` (DR-Workstation-Kit, KOMODO_*-Notiz und GitHub-Read-PAT als offene Bootstrap-Bloecke) sind im selben Aenderungsblock erledigt. Operator-Aufgaben (Notiz/PAT/WSL-Setup) wandern als P1 in die offenen Punkte.
-| erledigt (Baseline) | H:/ als zusaetzliches lokales Backupziel bewerten | Als zweite Nearline-Kopie und Freeze-Sicherung sinnvoll; kein Offsite-Ersatz, kein CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC ist der getestete Weg (siehe `docs/CAPACITY_AND_LIFECYCLE.md`) |
+- Authelia ACL: `borg.kaleschke.info` und `code.kaleschke.info` 2026-06-03 in den `two_factor`-Block der Repo-Baseline aufgenommen. Beide UIs haben effektiv Host-/Backup-Zugriff (Borg-Restore-Scope inkl. `/local/secrets`, code-server mit Workspaces). Wirkung erst nach manuellem Merge in `/mnt/user/appdata/authelia/config/configuration.yml`, `docker restart authelia` und Smoke-Test auf einer der vier 2FA-Domains; `services/authelia-diff.sh` muss `exit 0` liefern. TOTP-Enrollment des Operator-Accounts ist Voraussetzung, sonst Login-Sperre.
-| erledigt (Pull live, Scheduled Task offen) | H:/ Groesse und Pull-Schedule festschreiben | Groesse erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy`. Erster echter Pull 2026-05-27 20:45 erfolgreich: 19 Borg-Dumps + 10 Gitea-Bundle-Files unter `H:\kallilab-nearline-backups`. `unraid-flash-config.*` bewusst ausserhalb Scope (`/XF`-Exclude, Restore aus Hetzner-Borg). Permission-Fixes in `pre-backup-dumps.sh` (alle Dumps 0644 ausser Flash-Config), `gitea-bundle-mirror.sh` (Bundles 0644), `export-prometheus-textfile.sh` (Metric-File 0644) und `pull-critical-backups.ps1` (Report-Bug + ExcludeFiles). Windows Scheduled Task taeglich 05:30 bleibt offen (Operator-Bestaetigung). |
+- Alt-Volumes nach Burn-in freigegeben und reversibel archiviert: Shared PG17, Mealie PG17, Nextcloud PG17 und Immich pgvecto.rs liegen seit 2026-06-02 unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602`; Manifest auf dem Host: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/MANIFEST.txt`. Keine harte Loeschung, keine aktiven Container-Mounts auf die alten Pfade.
-| erledigt 2026-05-28 | FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen | Bereinigt: `80/tcp` entfernt (Mobilfunk-validiert: HTTP timeout, HTTPS weiter erreichbar). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigabe-Recht fuer `PC-192-168-178-71` (VONETS-Bridge, vermutlich SolarEdge-Wechselrichter) deaktiviert. Aktiver Endstand: ausschliesslich `443/tcp -> 192.168.178.58`. Details in `docs/FRITZBOX_PORT_CORRECTION_PLAN.md`. |
+- Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; Live-Baseline am 2026-06-01: FRITZ!OS `154.08.25`, keine Public-AAAA-Records fuer `*.kaleschke.info`, Host ohne globale Provider-IPv6, WAN `443/tcp` offen und `80/tcp`/`222/tcp` geschlossen.
-
+- FRITZ!Box-Servicefenster UI-seitig abgeschlossen: FRITZ!Box-Dienste aus dem Internet sind aus (HTTPS auf FRITZ!Box-UI, FTP/FTPS auf Speichermedien), aktive WAN-Freigabe bleibt nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
-## Sprint 5 - Auth und Frontdoor, bewusst zuletzt
+- FRITZ!Box-Konfig-Backup exportiert und extern/off-system in Vaultwarden abgelegt: `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export`; Kennwort und Datei bleiben ausserhalb des Repos.
-
+- Hetzner-Account-Hygiene erledigt: externe Kontakt-/Rechnungs-Mail bestaetigt, Zahlung ok, 2FA mit Google Authenticator aktiv, Recovery Key offline ausgedruckt.
-In diesem Audit-Zyklus werden diese Punkte **nicht** umgesetzt. Sie sind dokumentiert, damit sie bei einer kuenftigen Policy-Entscheidung sofort priorisiert werden koennen.
+- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery. Borg `append-only` ist bewusst nicht umgesetzt.
-
+- Family-View Dashboard ist repo-seitig gebaut: `monitoring/grafana/dashboards/family-status.json` zeigt Family-App-Uptime, Backup-Alter, TLS-Restlaufzeit, Critical-Container und Image-Drift.
-| Status | Aufgabe | Begruendung der Parkung |
+- Borg-Nachlauf nach dem 2026-05-31-Sprint ist belegt: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, 101669 Dateien, `rc=0`; Freshness-Check am 2026-06-01: Critical 0, Warnings 0.
-|---|---|---|
+- H:/ Nearline-Pull am 2026-06-01 repariert und manuell validiert: kuratierte Borg-Dumps Exit 0, Gitea-Bundles Exit 1 (Robocopy-Erfolg mit Kopien), Report `nearline-pull-2026-06-01-082553.md`.
-| geparkt | Authelia 2FA fuer Operator-UIs erweitern (F-04) | Operator-Vorgabe 2026-05-26: keine Auth-Aenderungen in diesem Zyklus |
+- Immich-, Paperless-, Gitea- und Vaultwarden-Restore-Pfade sind belegt.
-| geparkt | Authelia OIDC fuer Apps pruefen (F-13) | Operator-Vorgabe 2026-05-26: keine Auth-Aenderungen in diesem Zyklus |
+- H:/ Nearline-Pull laeuft seit 2026-05-28 als Windows Scheduled Task.
-| geparkt | CrowdSec vor Traefik pruefen (F-14) | Operator-Vorgabe 2026-05-26: erst nach finaler Auth-Policy |
+- FRITZ!Box-Portfreigaben sind bereinigt: WAN-seitig bleibt `443/tcp`.
-| geparkt | Nextcloud-2FA-/Brute-Force-Haertung dokumentieren (F-18) | beruehrt Auth-Policy fuer Familien-Konten; gemeinsam mit OIDC-Entscheidung |
+- InfluxDB 3 Core ist effektiv nur auf `127.0.0.1:8181` gebunden.
-
+- Renovate ist produktiv, Major-Updates werden bewusst manuell entschieden.
-## Sprint 6 - Geparkte Apps und Folgeentscheidungen
+- Policy-Check bleibt ohne Criticals; bekannte Root-Ausnahmen sind dokumentiert.
-
-| Status | Aufgabe | Naechster Pruefschritt |
-|---|---|---|
-| geparkt | Hermes-Agent (F-06) — Operator-Entscheidung produktiv vs. entfernen | Review-Deadline **2026-07-25**; bis dahin bleibt der NAS-Stack deaktiviert, das Repo-Verzeichnis erhalten, Dashboard-Domain und ACL-Eintrag unveraendert |
-| erledigt 2026-05-28 | paperless-gpt / BentoPDF Nutzungsentscheidung | Operator behaelt beide. **paperless-gpt** bleibt bis Paperless-NGX 3.0 (erwartete native KI-Features); danach neu bewerten. **BentoPDF** bleibt als situatives Tool (Resource-Footprint ~4 MB). Beide ohne aktive Traefik-Zugriffe in der letzten Woche, aber bewusste Behalten-Entscheidung mit Begruendungs-Anker im SERVICE_CATALOG. |
-| erledigt 2026-05-28 | Plex Remote Access in UI deaktivieren falls nur LAN/Tailscale (F-17) | Beim Versuch entdeckt: Server war seit 18.05. unclaimed und Bibliotheken leer. Reclaim als `Xeridos` via inline `PLEX_CLAIM`-Token, danach Bibliotheken (`/data/movies` 1.4 TB, `/data/Heimatfilme` 300 GB) neu angelegt und Remote Access deaktiviert (`PublishServerOnPlexOnlineKey=0`, Plex-Relay aus). Details in `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13. |
-| erledigt | `infra/redis` Doku-Etikett korrigieren (F-16) | SERVICE_CATALOG, REPO_MAP, MASTER (Sektion 13) und DISASTER_RECOVERY Bootstrap-Stufe 2 auf "primaer Paperless-Redis" praezisiert; keine Compose-Aenderung |
-| erledigt | Paperless-DBPass DR-Restore-Reihenfolge in DR-Doc (F-20) | DISASTER_RECOVERY 6.2.1 (Restore-Quellen fuer Stack-ENV-Werte) ergaenzt; SECRETS_MAP um Abschnitt "Stack-ENV-only Secrets - Restore-Wege" mit Reihenfolge Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz erweitert; Paperless, Immich, Mail-Archiver, Speedtest, Komodo, Hermes und Glance je mit Restore-Quelle dokumentiert |
-
-## Sprint 8 - Reife der Stack-Hygiene (2026-05-29)
-
-| Status | Aufgabe | Ergebnis |
-|---|---|---|
-| erledigt 2026-05-29 | Healthchecks fuer Tier-1 (F-15) | postgresql17 (`pg_isready`), Redis (`redis-cli ping` mit Auth), Vaultwarden (`curl /alive`), Gitea (`wget /api/healthz`), Traefik (`traefik healthcheck --ping`, `--ping=true` in CLI), Authelia (`wget /api/health`, weil v4.39 `helper health-check` entfernt hat); komodo-mongo war bereits gepinnt healthy. Live-Smoke: alle 6 healthy nach Recreate. Postgres- und Gitea-Stack-Workspace waren Komodo-seitig zurueckgeblieben (124 bzw. 52 commits behind); manuell per `cp` + `docker compose up -d` synchronisiert. |
-| erledigt 2026-05-29 | Monitoring-Stack Digest-Pinning (F-07) | 9 Container in `monitoring/docker-compose.yml` per Tag@sha256 gepinnt: prometheus, alertmanager, alertmanager-ntfy-bridge (python:3.13-alpine), blackbox-exporter, loki, promtail, grafana, node-exporter, cadvisor. Digests aus dem aktuell laufenden Container ausgelesen, damit der Pin den Live-Stand reflektiert. influxdb3-core war bereits gepinnt. |
-| erledigt 2026-05-29 (Skript) / 2026-05-30 (Erstlauf) | Komodo-Bootstrap-Trockenlauf-Skript (F-09 Rest) | `ops/restore-tests/komodo-bootstrap-{compose.test.yml,test.sh,plan.md,runbook.md}` analog zum Immich-Restore-Test angelegt. Test-Compose nutzt dieselben Image-Digests wie Produktion, isoliert unter Project `restoretest-komodo`, Test-Periphery ohne docker.sock-Mount, Test-Port nur `127.0.0.1:19120`. Wegwerf-Secrets im Compose. **Erstlauf 2026-05-30 erfolgreich**: Result `SUCCESS`, alle 5 Checks gruen — compose config valid, Test-Mongo healthy (6s), Mongo authenticated ping ok, Komodo Core HTTP `200`, Test-Periphery container state `running`. Report unter `/mnt/user/backups/restore-reports/komodo-bootstrap-2026-05-30.md`. Produktive Komodo-Container, Mongo-Datadir und Secrets nicht beruehrt. Damit ist `ops/komodo/docker-compose.yml` als Recovery-Anker belegt tauglich (nicht mehr nur angenommen). |
-| erledigt 2026-05-29 | Renovate-Bot gegen Gitea (F-12) | Live: Service-Account `renovate` (uid 2, kein Admin) angelegt, Collaborator Write auf `Micha/homelab-infra`, PAT in `/mnt/user/appdata/secrets/renovate_token.txt` (chmod 600). Cron `renovate-six-hourly` (`20 */6 * * *`) live in `/etc/cron.d/root`. Erstlauf 2026-05-29 erfolgreich: 5 PRs (mongo digest+minor, postgres digest+minor, minor-and-patch-updates gruppiert), 1 Dependency-Dashboard-Issue, 8 Branches. Komodo-Major durch packageRule deaktiviert wie erwartet. Architektur-Detail: Repo-Config in `renovate.json`, Bot-Config in `ops/renovate/bot-config.js` (Renovate liest die im Repo nur als Repo-Config, Bot-Settings dort triggern "forbidden/disabled"). |
-| erledigt 2026-05-30 | Authelia Repo<->Host Drift-Check (F-10) | `services/authelia-diff.sh` vergleicht die `access_control:`-Sektion zwischen Repo-Baseline und Host-Datei (Default; per env `AUTHELIA_DIFF_SECTIONS` erweiterbar). OIDC-Clients/Identity-Provider und Secret-Werte bleiben bewusst aussen vor. Exit-Codes: 0 = ok, 1 = Drift, 2 = Datei fehlt, 3 = Sektion fehlt, 4 = Werkzeug fehlt. Posture-Check ruft das Skript als Check `authelia_config_drift` auf (`SKIP_AUTHELIA_DRIFT=1` skippt, `AUTHELIA_DIFF_SCRIPT` ueberschreibt den Pfad); Drift wird als Warning gemeldet, nicht Critical. Smoke-Test lokal: identische Files -> rc=0, ACL-Drift im Domain-Eintrag -> rc=1 mit unified diff. WORKFLOW.md hat jetzt eine eigene Pflicht-Sektion "Ausnahme: Authelia configuration.yml" analog zur Traefik-Dynamic-Sektion. Pflicht-Setup auf dem Host: Repo-Spiegel unter `/mnt/user/services/homelab-infra/`. |
-
-## Sprint 7 - Off-site und 3-2-1 (offen)
-
-| Status | Aufgabe | Bemerkung |
-|---|---|---|
-| erledigt 2026-05-28 (bewusst nicht umgesetzt) | Zweites echtes Off-site (F-03) | Operator-Entscheidung 2026-05-28: kein zweites Off-site. 3-2-1 ist mit Live + lokalem Borg + Hetzner + H:/-Nearline erfuellt; ein zweites Off-site wuerde nur den Fall "Hetzner-Account verloren" zusaetzlich abdecken, Aufwand/Kosten unverhaeltnismaessig fuer Familien-Homelab. Statt dessen drei Hetzner-Haertungen als Folge-TODOs (siehe `docs/OFFSITE_BACKUP_OPTIONS.md` Beschluss-Block). Review-Trigger sind dort definiert. |
-| offen (Operator-Aufgabe) | Hetzner-Account-Hygiene ohne 2FA | Starkes, einzigartiges Passwort in Vaultwarden + Backup-Zahlungsweg + Login-Benachrichtigungen per E-Mail. 2FA bewusst nicht (analog USV: Risiko bewusst akzeptiert, Aufwand ueberwiegt Risiko-Reduktion fuer Familien-Homelab). |
-| offen (Folge-Sprint) | Borg `--append-only` auf Hetzner setzen | Aktuell laeuft Repo `appdata-critical` im Mode `full`, `custom_flags` leer. Setup server-seitig in Hetzner `~/.ssh/authorized_keys` mit `command="borg serve --append-only"`. Schuetzt gegen Ransomware, die client-seitig Borg-Credentials abgreifen koennte. |
-| erledigt 2026-05-28 | H:/-Pull als Windows Scheduled Task | Task `KalliLab H Drive Nearline Pull` registriert: taeglich 05:30, `RunLevel Limited`, `AllowStartIfOnBatteries`, `StartWhenAvailable`, `ExecutionTimeLimit 2h`. Naechster Lauf 2026-05-29 05:30. Erstlauf manuell 2026-05-27 20:45 erfolgreich, Task-Setup in `docs/H_DRIVE_NEARLINE_PULL.md` aktualisiert (RunLevel-Enum-Fix `LeastPrivilege` -> `Limited`). |
-| erledigt (Routine dokumentiert) | Restore-Lab-Drill quartalsweise dokumentieren | `docs/RESTORE_DRILL_ROUTINE.md` definiert Drei-Stufen-Modell (Freshness woechentlich / Mini-Restore monatlich-bimonatlich / DR-Sanity quartalsweise), Quartals-Belegung Q1-Q4 mit Dienst-Rotation, Immich 2026-05-27 als bestaetigter Erstlauf gefuehrt, 10-Punkte-Sanity-Check, kein Host-Schedule angelegt. `ops/restore-tests/schedule.md` verweist jetzt auf Drill-Routine. |
-
-## Offene Host-Werte
-
-Diese Werte muessen am Unraid-Host erhoben werden, bevor die entsprechenden Aenderungen sauber umgesetzt werden:
-
-```bash
-hostname
-cat /proc/cpuinfo | awk '/model name|flags/ {print; if(/flags/) exit}'
-free -h
-dmidecode -t baseboard | head -30
-ip -br link
-tailscale ip -4
-lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT,VENDOR
-df -h /mnt/cache /mnt/disk1 /mnt/user
-smartctl -a /dev/nvme0n1 | head -80
-smartctl -a /dev/sdb | head -80
-```

docs/AUDIT_REPORT.md

@@ -1,80 +0,0 @@
-# Audit Report - KalliLab CORE
-Datum: 2026-05-16
-Gepruefte Compose-Dateien: 30
-
-## Kritische Befunde
-
-Keine kritischen Befunde im Repo-Sollzustand gefunden.
-
-- Keine Datenbank und kein Cache haengt in `frontend_net`.
-- Keine produktive Compose-Datei ohne explizites `networks:`-Feld gefunden.
-- Keine produktive `.env`- oder `stack.env`-Datei ohne `.example`-Suffix im Repository gefunden.
-- Keine Klartext-Passwoerter, Tokens oder API-Keys in Compose-`environment:`-Bloecken gefunden.
-
-## Mittlere Befunde
-
-- Docker-Socket ausserhalb der im Audit-Prompt genannten Allowlist: `traefik` mountet `/var/run/docker.sock:/var/run/docker.sock:ro` in `traefik/docker-compose.yml:34`. Der Socket ist fuer den Docker-Provider fachlich nachvollziehbar, aber in `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 10 nicht explizit als Docker-Socket-Ausnahme aufgefuehrt.
-- Docker-Socket ausserhalb der im Audit-Prompt genannten Allowlist: `alloy` mountet `/var/run/docker.sock:/var/run/docker.sock:ro` in `ops/loki/docker-compose.yml:26`. [AUSNAHME - dokumentiert] in `HOMELAB_ARCHITECTURE_MASTER_V2.md` Abschnitt 10 als `alloy` Docker-Socket read-only, aber nicht in der Prompt-Allowlist genannt.
-- `komodo-periphery` haengt ohne Web-UI im `frontend_net` in `ops/komodo/docker-compose.yml:92-94`. Die Compose-Datei dokumentiert an `ops/komodo/docker-compose.yml:77-79` den Grund als Git-Zugriff auf internes Gitea und Docker-Agent-Sonderfall. [AUSNAHME - lokal in Compose dokumentiert]
-- `hermes_net` ist ein app-internes Netz ohne `internal: true`: `ops/hermes-agent/docker-compose.yml:91-93`. Das ist nicht Teil der explizit geforderten `internal: true`-Liste, aber strukturell auffaellig, weil Gateway und Dashboard intern ueber dieses Netz sprechen.
-- `grafana` nutzt zusaetzlich `backend_net` in `ops/grafana-influxdb/docker-compose.yml:27-30`, obwohl die Architektur das Grafana/Influx-Paar primaer als `frontend_net` + `grafana_influx_internal` beschreibt. Grund ist vermutlich Loki-Datasource-Zugriff; `docs/REPO_MAP.md` nennt `backend_net` fuer Grafana-Loki-Datasource. [AUSNAHME - dokumentiert]
-- `paperless-gpt` verwendet `PAPERLESS_API_TOKEN` als Stack-ENV in `apps/paperless-gpt/docker-compose.yml:15`, taucht aber in `docs/SECRETS_MAP.md` nicht als eigener aktiver Secret-Eintrag auf.
-
-## Hinweise
-
-- Direkte Host-Ports sind nur bei dokumentierten Ausnahmen vorhanden:
-  - [AUSNAHME - dokumentiert] `traefik`: `80:80`, `443:443` in `traefik/docker-compose.yml:30-32`.
-  - [AUSNAHME - dokumentiert] `gitea`: `222:22` in `core/gitea/docker-compose.yml:17-18`.
-  - [AUSNAHME - dokumentiert] `adguard`: `53:53/tcp`, `53:53/udp`, `8082:80` in `host-services/Adguard/docker-compose.yml:13-16`.
-  - [AUSNAHME - dokumentiert] `influxdb3-core`: `${INFLUXDB_BIND_IP:-127.0.0.1}:8181:8181` in `ops/grafana-influxdb/docker-compose.yml:54-55`.
-- `backend_net` wird in allen Compose-Dateien als `external: true` referenziert, z. B. `infra/postgresql17/docker-compose.yml:25-26`, `infra/redis/docker-compose.yml:22-23`, `traefik/docker-compose.yml:59-60`. Ob das externe Docker-Netz live wirklich `internal: true` ist, ist aus dem Repo allein nicht verifizierbar.
-- `grafana_influx_lan` hat bewusst kein `internal: true`: `ops/grafana-influxdb/docker-compose.yml:88-89`. [AUSNAHME - dokumentiert]
-- Mutable Tags sind mit Digests gepinnt, aber semantisch weiterhin mutable:
-  - `immich-server`: `release@sha256` in `apps/immich/docker-compose.yml:4`.
-  - `immich-machine-learning`: `release@sha256` in `apps/immich/docker-compose.yml:35`.
-  - `tailscale`: `stable@sha256` in `host-services/tailscale/docker-compose.yml:3`.
-  - `ddns-updater`: `latest@sha256` in `infra/ddns-updater/docker-compose.yml:3`.
-  - `komodo-core`: Major-Tag `2@sha256` in `ops/komodo/docker-compose.yml:36`.
-  - `komodo-periphery`: Major-Tag `2@sha256` in `ops/komodo/docker-compose.yml:82`.
-  - `uptime-kuma`: Major-Tag `1@sha256` in `ops/uptime-kuma/docker-compose.yml:3`.
-- Reines `image: name:latest` ohne Digest wurde in produktiven Compose-Dateien nicht gefunden.
-- Alle Services haben `restart: unless-stopped`.
-- Alle Services haben `security_opt: no-new-privileges:true`.
-- [AUSNAHME - dokumentiert] `scrutiny` nutzt `privileged: true` in `ops/scrutiny/docker-compose.yml:6`.
-- [AUSNAHME - dokumentiert] `tailscale` nutzt `network_mode: host` in `host-services/tailscale/docker-compose.yml:6`.
-
-## Dokumentations-Abweichungen
-
-- Service-Namen in Compose vs. `docs/SERVICE_CATALOG.md` weichen bei Immich ab: Compose nutzt `immich-server`, `immich-machine-learning`, `database`, `redis` in `apps/immich/docker-compose.yml:2`, `:33`, `:44`, `:53`; der Katalog dokumentiert `immich_server`, `immich_machine_learning`, `immich_postgres`, `immich_redis`.
-- Service-Name in Compose vs. `docs/SERVICE_CATALOG.md` weicht bei Paperless ab: Compose nutzt `paperless` in `apps/paperless/docker-compose.yml:2`; der Katalog dokumentiert `paperless-ngx`.
-- Service-Name in Compose vs. `docs/SERVICE_CATALOG.md` weicht bei Redis ab: Compose nutzt `redis` in `infra/redis/docker-compose.yml:2`; der Katalog dokumentiert `Redis`.
-- Traefik-Host bei Hermes ist im Compose variabel: `Host(`${HERMES_DASHBOARD_HOST}`)` in `ops/hermes-agent/docker-compose.yml:81`; `docs/REPO_MAP.md` dokumentiert konkret `hermes.kaleschke.info`. Das ist plausibel, aber maschinell nicht eindeutig abgleichbar.
-- `docs/REPO_MAP.md` Volumes-Tabelle ist fuer mehrere Mounts nur zusammenfassend, nicht pfadgenau. Beispiele mit Compose-Pfaden, die dort nicht wortgleich auftauchen:
-  - `/mnt/user/appdata/unbound/config` in `apps/unbound/docker-compose.yml:7`.
-  - `/mnt/user/appdata/ddns-updater` in `infra/ddns-updater/docker-compose.yml:17`.
-  - `/mnt/user/appdata/filebrowser/database` und `/mnt/user/appdata/filebrowser/config` in `ops/filebrowser/docker-compose.yml:15-16`.
-  - `/mnt/user/appdata/borg-ui/restore` in `ops/borg-ui/docker-compose.yml:27`.
-- Netzwerke in Compose sind alle in `docs/REPO_MAP.md` aufgefuehrt.
-- Traefik-Hosts aus Compose sind in `docs/REPO_MAP.md` aufgefuehrt; einzige Besonderheit ist der variable Hermes-Host.
-- `.example`-Dateien haben passende Gegenspieler in `.gitignore`: `.env`, `*.env`, `!*.env.example`, `**/stack.env`, `!**/stack.env.example`.
-- Keine `.keep`-Platzhalter-Dateien gefunden.
-
-## Offene Architektur-Punkte: aktueller Stand
-
-- `immich_redis`: weiterhin kein named volume. Compose-Service `redis` in `apps/immich/docker-compose.yml:44-50` hat aktuell gar keinen `volumes:`-Block. Architekturpunkt bleibt offen.
-- `AdGuard Home`: Admin-Port ist weiterhin direkt veroeffentlicht: `8082:80` in `host-services/Adguard/docker-compose.yml:15`; keine Traefik-Labels vorhanden. Block F bleibt offen.
-- `filebrowser`: Appdata-Breitmount ist entfernt; aktuelle Mounts sind `/mnt/user/documents`, `/mnt/user/photos`, `/mnt/user/projekte` plus eigene DB/Config in `ops/filebrowser/docker-compose.yml:12-16`. Langfristiges Hardening bleibt moeglich, aber der groesste alte Breitmount ist erledigt.
-- `bentopdf`: Compose ist vorhanden und Traefik-abgesichert in `apps/bentopdf/docker-compose.yml:2-27`. Runtime-Deploy und fachliche Abnahme koennen aus dem Repo allein nicht bestaetigt werden; Architekturpunkt bleibt als Live-Pruefung offen.
-- `grafana` und `influxdb3-core`: laufen weiterhin als `user: "0"` in `ops/grafana-influxdb/docker-compose.yml:6` und `ops/grafana-influxdb/docker-compose.yml:53`. [AUSNAHME - dokumentiert]
-- `plex-media-server`: keine Compose-Datei im Repo gefunden; bleibt Dockerman-/Host-Sonderfall laut Architektur.
-
-## Bestanden
-
-- 30 produktive `docker-compose.yml` wurden geprueft.
-- Keine Datenbanken oder Caches im `frontend_net`: `postgresql17` nur `backend_net` in `infra/postgresql17/docker-compose.yml:18`; shared `redis` nur `backend_net` in `infra/redis/docker-compose.yml:15`; `mealie-postgres` nur `mealie_internal` in `apps/mealie/docker-compose.yml:56`; Immich `database` und `redis` nur `immich_default` in `apps/immich/docker-compose.yml:48` und `:64`; Nextcloud DB/Redis nur `nextcloud_internal` in `apps/nextcloud/docker-compose.yml:61` und `:73`; `komodo-mongo` nur `komodo_net` in `ops/komodo/docker-compose.yml:16`.
-- App-interne Pflichtnetze sind korrekt `internal: true`: `immich_default` in `apps/immich/docker-compose.yml:73-75`, `mealie_internal` in `apps/mealie/docker-compose.yml:66-68`, `nextcloud_internal` in `apps/nextcloud/docker-compose.yml:82-84`, `grafana_influx_internal` in `ops/grafana-influxdb/docker-compose.yml:90-91`.
-- `frontend_net` und `backend_net` werden in Compose-Dateien als `external: true` referenziert.
-- Alle Services mit `traefik.enable=true` setzen explizit `traefik.docker.network=frontend_net`, `entrypoints=websecure`, `tls=true` und `tls.certresolver=le`.
-- Kein Traefik-Label mit `yourdomain.tld` gefunden.
-- Admin-/Ops-Router haben Middleware `authelia@file,secure-headers@file`, u. a. `homepage` in `apps/homepage/docker-compose.yml:31`, `filebrowser` in `ops/filebrowser/docker-compose.yml:27`, `scrutiny` in `ops/scrutiny/docker-compose.yml:32`, `grafana` in `ops/grafana-influxdb/docker-compose.yml:46`. [AUSNAHME - dokumentiert] `komodo-core` hat keine ForwardAuth-Middleware in `ops/komodo/docker-compose.yml:64-71`; [AUSNAHME - dokumentiert] `nextcloud` nutzt native Auth und nur Redirect-Middleware in `apps/nextcloud/docker-compose.yml:42-46`.
-- Web-UIs ohne Traefik-Labels wurden nur als dokumentierte Sonderfaelle gefunden: `adguard` mit LAN-Admin-Port in `host-services/Adguard/docker-compose.yml:13-16`; `ddns-updater` hat keine Web-UI und braucht Internet in `infra/ddns-updater/docker-compose.yml:8`; `komodo-periphery` ist Agent ohne Traefik-Route in `ops/komodo/docker-compose.yml:81-103`.

docs/AUTHELIA_OIDC_PLAN.md

@@ -0,0 +1,186 @@
+# Authelia OIDC fuer Apps - Plan & Runbook
+
+Stand: 2026-06-06. Authelia-Version: **v4.39.20**.
+
+Ziel: App-uebergreifendes Single-Sign-On ueber Authelia als OpenID-Connect-Provider
+(`https://auth.kaleschke.info`). Statt pro App eigener Logins meldet man sich einmal
+bei Authelia an (inkl. 2FA) und wird per OIDC an die App durchgereicht.
+
+> **Status:** aktives Runbook. Grafana und Mealie sind seit 2026-06-06 live
+> und per Login-Smoke verifiziert. Der weitere Rollout bleibt additiv: lokale
+> App-Logins bleiben als Fallback aktiv.
+
+---
+
+## Grundregeln (wichtig)
+
+- **Secrets gehoeren nie ins Repo.** OIDC-Client-Secrets (Klartext und pbkdf2-Hash)
+  liegen ausschliesslich in der Host-Config `/mnt/user/appdata/authelia/config/configuration.yml`
+  (Hash) und im jeweiligen App-Stack (Klartext, via Komodo Stack-ENV / Secret-Datei),
+  plus optional Vaultwarden. Dieses Dokument enthaelt nur Schema und Variablennamen.
+- **OIDC-Clients leben host-seitig**, wie der bestehende `beszel`-Client. Die Repo-Baseline
+  `security/authelia/configuration.yml` haelt nur die nicht-geheime Struktur
+  (`access_control` etc.); `services/authelia-diff.sh` vergleicht standardmaessig nur
+  `access_control`, OIDC-Clients auf dem Host loesen also keinen Drift-Alarm aus.
+- **Issuer/Endpoints** (Authelia OIDC):
+  - Issuer: `https://auth.kaleschke.info`
+  - Authorization: `https://auth.kaleschke.info/api/oidc/authorization`
+  - Token: `https://auth.kaleschke.info/api/oidc/token`
+  - Userinfo: `https://auth.kaleschke.info/api/oidc/userinfo`
+  - JWKS: `https://auth.kaleschke.info/jwks.json`
+  - Discovery: `https://auth.kaleschke.info/.well-known/openid-configuration`
+- **PKCE an, wo moeglich** (`require_pkce: true`, `S256`), wie beim Beszel-Client.
+
+---
+
+## Client-Schema (Authelia v4.39, gespiegelt vom bestehenden `beszel`-Client)
+
+Pro App ein Block unter `identity_providers.oidc.clients` in der **Host-Config**:
+
+```yaml
+identity_providers:
+  oidc:
+    clients:
+      - client_id: '<app>'
+        client_name: '<App-Name>'
+        client_secret: '<pbkdf2-sha512-Hash - NUR auf dem Host>'
+        public: false
+        authorization_policy: 'two_factor'   # admin-Apps: two_factor; Familien-Apps: s.u.
+        require_pkce: true
+        pkce_challenge_method: 'S256'
+        redirect_uris:
+          - 'https://<app>.kaleschke.info/<oidc-callback-pfad>'
+        scopes:
+          - 'openid'
+          - 'profile'
+          - 'email'
+          - 'groups'
+        response_types:
+          - 'code'
+        grant_types:
+          - 'authorization_code'
+        token_endpoint_auth_method: 'client_secret_basic'
+        userinfo_signed_response_alg: 'none'
+```
+
+### Client-Secret erzeugen (auf dem Host)
+
+```bash
+docker exec authelia authelia crypto hash generate pbkdf2 \
+  --variant sha512 --random --random.length 72 --random.charset rfc3986
+```
+
+- Ausgabe: **Random Password** (Klartext) + **Digest** (pbkdf2-Hash).
+- **Hash** -> Host-Config `client_secret`.
+- **Klartext** -> App-Stack (Komodo Stack-ENV/Secret) + optional Vaultwarden.
+- Klartext **nicht** ins Repo, nicht in Logs.
+
+---
+
+## Reihenfolge / Rollout
+
+| Stufe | App | Domain | OIDC-Support | Policy | Risiko | Begruendung |
+|---|---|---|---|---|---|---|
+| **1 (Proof) ERLEDIGT 2026-06-06** | Grafana (monitoring) | `monitoring.kaleschke.info` | nativ (`generic_oauth`) | `two_factor` | niedrig | **Live + Login verifiziert.** Authelia-Client `grafana` (host), Secret als Datei `/mnt/user/appdata/secrets/grafana_oidc_client_secret` via `__FILE`, ForwardAuth-Middleware durch OIDC ersetzt, lokaler Admin bleibt Fallback |
+| 2 | Immich | `immich.kaleschke.info` | nativ (Admin-UI/Config-File) | s. u. (Familie) | mittel | **GEPARKT bis Onboarding (Entscheidung 2026-06-06):** nur `micha` hat Authelia-Account, Familien-SSO-Nutzen entsteht erst mit Familien-Accounts; Immich ist mobil-lastig (hoechste Stoeranfaelligkeit) und braucht UI/Config-File. Erst nach Onboarding gezielt. Runbook bereit. |
+| 3 | Nextcloud | `cloud.kaleschke.info` | App `user_oidc` (+occ) | s. u. | mittel | **GEPARKT bis Onboarding (Entscheidung 2026-06-06):** wie Immich; braucht `user_oidc`-App-Install + `occ`. Lokaler Login bleibt. Erst nach Onboarding. Runbook bereit. |
+| **4 ERLEDIGT 2026-06-06** | Mealie | `mealie.kaleschke.info` | nativ | `one_factor` | niedrig | **Live + Login verifiziert.** OIDC-Env additiv (lokaler Login bleibt), Secret als Stack-ENV `${MEALIE_OIDC_CLIENT_SECRET}`, `extra_hosts` noetig (s. Gotchas) |
+| 5 | Paperless-ngx | `paperless.kaleschke.info` | `django-allauth` (Umgebungsvariablen) | `two_factor` | mittel | dokumentenlastig, Operator-nah |
+
+**Nicht OIDC:** Vaultwarden hat kein Standard-Endnutzer-OIDC (SSO ist Enterprise/Bitwarden-Feature) -> bleibt eigener Login. ntfy bleibt wie gehabt.
+
+### Policy Familien-Apps
+
+- Admin-Apps (Grafana, Paperless): `authorization_policy: two_factor`.
+- Familien-Apps (Immich, Nextcloud, Mealie): Start mit `one_factor` und lokalen
+  App-Logins als Fallback. 2FA fuer Familie erst spaeter, sobald TOTP-Enrollment
+  pro Person eingerichtet ist; sonst entsteht unnoetiges Lockout-Risiko.
+
+---
+
+## Stufe 1 konkret: Grafana (empfohlener Erststart)
+
+### A) Authelia (Host) - Client anlegen
+1. Secret erzeugen (Befehl oben). Klartext + Hash notieren.
+2. In `/mnt/user/appdata/authelia/config/configuration.yml` unter
+   `identity_providers.oidc.clients` neuen Block einfuegen:
+   ```yaml
+   - client_id: 'grafana'
+     client_name: 'Grafana'
+     client_secret: '<HASH>'
+     public: false
+     authorization_policy: 'two_factor'
+     require_pkce: true
+     pkce_challenge_method: 'S256'
+     redirect_uris:
+       - 'https://monitoring.kaleschke.info/login/generic_oauth'
+     scopes: ['openid', 'profile', 'email', 'groups']
+     response_types: ['code']
+     grant_types: ['authorization_code']
+     token_endpoint_auth_method: 'client_secret_basic'
+     userinfo_signed_response_alg: 'none'
+   ```
+3. `docker restart authelia`, Health + Log pruefen (`Startup complete`, keine Fehler).
+
+### B) Grafana (Komodo Stack-ENV) - generic_oauth
+Im `monitoring`-Stack (Grafana) setzen (Klartext-Secret aus Schritt A):
+```
+GF_AUTH_GENERIC_OAUTH_ENABLED=true
+GF_AUTH_GENERIC_OAUTH_NAME=Authelia
+GF_AUTH_GENERIC_OAUTH_CLIENT_ID=grafana
+GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET=<KLARTEXT-SECRET>
+GF_AUTH_GENERIC_OAUTH_SCOPES=openid profile email groups
+GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://auth.kaleschke.info/api/oidc/authorization
+GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://auth.kaleschke.info/api/oidc/token
+GF_AUTH_GENERIC_OAUTH_API_URL=https://auth.kaleschke.info/api/oidc/userinfo
+GF_AUTH_GENERIC_OAUTH_USE_PKCE=true
+GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP=true
+# optional Rollen-Mapping ueber groups:
+# GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH=contains(groups[*], 'admins') && 'Admin' || 'Viewer'
+```
+- `GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET` als Stack-ENV-only (kein `_FILE`-Support) -> in
+  `docs/SECRETS_MAP.md` als `grafana_oidc_client_secret` (Stack-ENV) nachziehen.
+
+### C) Test + Rollback
+- Test: `monitoring.kaleschke.info` -> "Sign in with Authelia" -> Authelia-Login (2FA) -> zurueck in Grafana, eingeloggt.
+- **Fallback bleibt:** lokaler Grafana-Admin-Login (`/login`) ist weiter aktiv -> kein Lockout.
+- Rollback: `GF_AUTH_GENERIC_OAUTH_ENABLED=false` (Grafana redeploy) und/oder Client-Block in Authelia entfernen + `docker restart authelia`.
+
+---
+
+## Doku-Nachzug bei jedem neuen Client
+
+- `docs/SECRETS_MAP.md`: pro App `<app>_oidc_client_secret` (Stack-ENV) + Hinweis "Hash in Authelia-Host-Config".
+- `docs/SERVICE_CATALOG.md`: App-Zeile um "OIDC via Authelia" ergaenzen.
+- Dieses Dokument: Rollout-Tabelle abhaken.
+- `docs/MASTER_TODO.md`: Fortschritt im OIDC-Punkt nachziehen.
+
+---
+
+## Gotchas (aus dem realen Rollout 2026-06-06)
+
+- **`extra_hosts` ist Pflicht fuer App-Container, die selbst zu Authelia connecten**
+  (OIDC-Discovery/Token sind Server-zu-Server): Der App-Container loest
+  `auth.kaleschke.info` per Docker-DNS oft nicht auf -> `httpx.ConnectTimeout` /
+  500 beim OAuth-Start. Fix wie Komodo:
+  ```yaml
+  extra_hosts:
+    - "auth.kaleschke.info:192.168.178.58"
+  ```
+  Cert validiert weiter (SNI/Hostname bleibt gleich, nur die IP wird gemappt).
+  Gilt fuer Mealie (bestaetigt) und sehr wahrscheinlich Paperless/Immich/Nextcloud.
+- **Additiv heisst additiv:** OIDC als zusaetzlichen Login aktivieren, lokalen
+  Login NICHT abschalten, `AUTO_REDIRECT`/Force-OIDC aus -> kein Lockout.
+- **Account-Linking per E-Mail:** Apps verknuepfen den OIDC-User i. d. R. per
+  E-Mail-Claim. Stimmt die Authelia-E-Mail mit dem App-Account, wird verknuepft;
+  sonst legt die App (bei aktivem Signup) einen neuen User an.
+- **Secret-Mechanik je App verschieden:** Grafana `__FILE` (Docker-Secret),
+  Mealie Stack-ENV `${...}`. Hash immer in der Authelia-Host-Config, Klartext nie ins Repo.
+
+## Spaetere Feinschliffe vor breitem Rollout
+
+1. Gruppen/Rollen-Mapping: braucht es Authelia-Gruppen (z. B. `admins`, `family`) fuer
+   App-Rollen (Grafana Admin/Viewer, Nextcloud-Gruppen)? Wenn ja, in der Authelia
+   User-Datenbank Gruppen pflegen.
+2. Familien-2FA spaeter neu bewerten, nachdem echte Familien-Accounts in Authelia
+   angelegt und TOTP pro Person verstanden ist.

docs/CAPACITY_AND_LIFECYCLE.md

@@ -1,6 +1,6 @@
 # Capacity and Lifecycle - KalliLab CORE
 
-Status: Initiale Capacity-Baseline 2026-05-26; H:/-Nearline-Bewertung 2026-05-26; externe Cold-Storage-Groessen offen.
+Status: Initiale Capacity-Baseline 2026-05-26; H:/-Nearline-Pull seit 2026-05-28 produktiv; zweites Off-site/Cold-Storage bewusst nicht umgesetzt.
 
 ## Zweck
 
@@ -14,8 +14,8 @@ Dieses Dokument haelt Wachstum, Schwellenwerte und Upgrade-Trigger fest. Es verh
 | Disk1 / Array | 5.5T | 1.8T | 3.7T | 80 % Planung / 90 % Aktion | gruen, 33 % belegt |
 | User Shares gesamt | 5.5T | 1.8T | 3.7T | 80 % Planung / 90 % Aktion | gruen, entspricht aktuell Disk1 |
 | Backups lokal | 5.5T geteilter Array-Space | 2.2G unter `/mnt/user/backups` | 3.7T Share-frei | Review bei Borg-/Dump-Wachstum | lokal nicht unabhaengig vom Array |
-| Hetzner Borg | TBD | TBD | TBD | TBD | TBD |
+| Hetzner Borg | extern / Storage Box | nicht repo-seitig gemessen | nicht repo-seitig gemessen | Borg-Stale-Alert + Account-Review | einziges echtes Off-site-Ziel |
-| Externe Cold-Platte | TBD | TBD | TBD | TBD | TBD |
+| Externe Cold-Platte | nicht vorhanden | - | - | Review nur bei Trigger | bewusst nicht beschafft; zweites Off-site erst bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz |
 
 Pruefkommando:
 
@@ -32,7 +32,7 @@ du -sh /mnt/user/documents /mnt/user/photos /mnt/user/media /mnt/user/backups 2>
 | Medien | aktuell ca. 1.7T | groesster Speicherblock | Array-Erweiterung vor 80 % planen |
 | Immich Fotos/Videos | aktuell ca. 23G | hoechster privater Datentopf | Restore-Test priorisieren |
 | Paperless/Dokumente | aktuell ca. 199M im Documents-Share | wichtig, moderates Wachstum | Restore-Test existiert, Share-Wachstum beobachten |
-| Nextcloud | TBD | Familiennutzung kann stark wachsen | Quota/Backup pruefen |
+| Nextcloud | aktuell klein, kann durch Familiennutzung stark wachsen | Datenwachstum und Quotas koennen spaeter relevant werden | Quota/Backup bei Familien-Onboarding pruefen |
 | Monitoring/Loki | begrenzt durch Retention | Retention kann Disk fuellen | Retention und Volume-Groesse bei Reviews pruefen |
 | Borg Dumps | aktuell ca. 2.2G lokale Backups | Retention und Excludes pruefen | Borg-Stale + Groessenprofil |
 
@@ -51,63 +51,48 @@ du -sh /mnt/user/documents /mnt/user/photos /mnt/user/media /mnt/user/backups 2>
 
 ## H:/ als zusaetzliches lokales Backup-Ziel
 
-Operator-Befund 2026-05-26: das Windows-Laufwerk `H:/` laeuft dauerhaft am Arbeits-PC und wurde bereits als `H:-Freeze-Backup` waehrend der Disk1 NTFS->XFS Phase 2 erfolgreich genutzt (siehe `docs/MIGRATION_LOG.md`).
+`H:/` ist **keine echte Offsite-/Airgap-Kopie und kein Ersatz fuer Hetzner**. Es ist aber sinnvoll als zweite lokale Nearline-Kopie fuer kritische Restore-Quellen (Borg-Dumps, Repo-Bundles, Flash-Backup) und als Freeze-Sicherung vor strukturellen Eingriffen.
-
-### Eigenschaften von H:/
-
-| Eigenschaft | Wert | Konsequenz |
-|---|---|---|
-| Anbindung | Windows-PC, dauerhaft verbunden | kein Air-Gap, kein Hardware-Trenn-Schutz |
-| Standort | gleicher physischer Standort wie Unraid-Host | kein Off-site, kein Schutz gegen Brand/Diebstahl/Wasser |
-| Schreibzugriff | dauerhaft moeglich | Ransomware oder Operator-Fehler koennen Original und Kopie gleichzeitig treffen |
-| Filesystem (Windows) | typischerweise NTFS | fuer Borg-Ziel ueber CIFS/SMB ungeeignet als Hard-Mount auf Unraid (STORAGE_LAYOUT §12.6) |
-| Reproduzierbar nutzbar | ja, bewaehrt durch Disk1-Phase-2-Freeze-Backup | Pull-Modell vom Windows-PC ist der getestete Weg |
-
-### Bewertung
-
-H:/ ist **keine echte Offsite-/Airgap-Kopie und kein Ersatz fuer Hetzner**. Es ist aber sinnvoll als:
-
-- **Zweite lokale Nearline-Kopie** fuer kritische Restore-Quellen (Borg-Dumps, Repo-Bundles, Flash-Backup). Schnellster Restore-Pfad bei Hetzner-Stoerung, weil kein Off-site-Download noetig ist.
-- **Cold-Storage-Vorstufe**: wenn H:/ kuenftig periodisch (z. B. monatlich) physisch getrennt und durch eine zweite Platte ersetzt wird, wuerde sich daraus ein echtes Air-Gap-Rotationsschema ableiten lassen.
-- **Freeze-Sicherung** vor strukturellen Eingriffen (Disk-Tausch, Pool-Umzug, Format), wie bereits 2026-05-25 praktiziert.
-
-### Empfohlene Nutzung
 
 | Nutzung | Umsetzung | Hinweis |
 |---|---|---|
-| Pull von `/mnt/user/backups/borg/dumps/latest` auf H:/ | Windows-seitiger Scheduled Task per `robocopy` oder `rclone` von einem SMB-Read-Share | keine CIFS-Hard-Mounts auf Unraid; STORAGE_LAYOUT-Konstitution bleibt erhalten |
+| Pull von `/mnt/user/backups/borg/dumps/latest` auf H:/ | Windows Scheduled Task per `robocopy` | keine CIFS-Hard-Mounts auf Unraid |
 | Pull der Gitea-Bundles aus `/mnt/user/backups/git-bundles/gitea` | identisch | Bundles sind klein und schnell synchronisiert |
-| Pull des Unraid-Flash-Artefakts `unraid-flash-config.tar.gz` | identisch | wie Secret behandeln, Windows-seitig nicht in geteilten Ordnern ablegen |
+| Pull des Unraid-Flash-Artefakts `unraid-flash-config.tar.gz` | bewusst nicht im H:/ Scope | Restore-Quelle bleibt Hetzner-Borg; Flash-Config wie Secret behandeln |
 
-Der konkrete Pull-Pfad ist in `docs/H_DRIVE_NEARLINE_PULL.md` und `ops/h-drive-nearline/pull-critical-backups.ps1` vorbereitet. Der Windows Scheduled Task wird erst nach Operator-Sichtpruefung aktiviert.
+Der konkrete Pull-Pfad ist in `docs/H_DRIVE_NEARLINE_PULL.md` und `ops/h-drive-nearline/pull-critical-backups.ps1` produktiv. Der Windows Scheduled Task `KalliLab H Drive Nearline Pull` laeuft seit 2026-05-28 taeglich 05:30.
-| **Nicht** als Ersatz fuer Hetzner-Off-site | — | 3-2-1 bleibt mit Hetzner als einzigem Off-site weiterhin unerfuellt; siehe `docs/AUDIT_2026-05-25.md` F-03 |
+
-| **Nicht** als zweites Borg-Repo am Unraid | — | dauerhafte CIFS-Verbindung im Borg-Lauf verletzt Hard Rule §12.6 |
+| Abgrenzung | Bewertung | Begruendung |
+|---|---|---|
+| **Nicht** als Ersatz fuer Hetzner-Off-site | bewusst | 3-2-1 ist mit Hetzner als einzigem Off-site erfuellt; H:/ reduziert nur lokale Restore-Abhaengigkeit |
+| **Nicht** als zweites Borg-Repo am Unraid | bewusst | dauerhafte CIFS-Verbindung im Borg-Lauf verletzt Hard Rule aus `docs/STORAGE_LAYOUT.md` |
 
 ### Kapazitaets-Eintrag
 
 | Bereich | Groesse | Belegt | Schwellwert | Bewertung |
 |---|---:|---:|---:|---|
-| H:/ (Windows-Arbeitsplatz, `Externe HDD`) | 8.0T | 3.91T belegt / 4.10T frei | Review wenn > 70 % | NTFS, `Healthy`; Pull-Ziel fuer Borg-Dumps, Gitea-Bundles und Flash-Backup |
+| H:/ (Windows-Arbeitsplatz, `Externe HDD`) | 8.0T | 3.91T belegt / 4.10T frei | Review wenn > 70 % | NTFS, `Healthy`; Pull-Ziel fuer Borg-Dumps und Gitea-Bundles |
 
 ### Naechste Schritte
 
-- Pull-Script (Operator-Aufgabe, kein Repo-Pflichtteil) etablieren; alternativ ueber Filebrowser/Nextcloud-Sync abdecken.
+- Task-Lauf quartalsweise gegen Reports unter `H:\kallilab-nearline-backups\_reports` pruefen.
-- Review-Intervall: quartalsweise. Bei jeder grossen Strukturaenderung (Disk-Tausch, Pool-Umzug) Freeze-Pull manuell ausloesen.
+- Review-Intervall: quartalsweise. Bei jeder grossen Strukturaenderung Freeze-Pull manuell ausloesen.
 
 ## Restore-Zeitziele
 
 | Tier | Beispiel | Zielzeit | Status |
 |---|---|---:|---|
-| Tier 0 | Repo, Secrets, Traefik, DNS | TBD | offen |
+| Tier 0 | Repo, Secrets, Traefik, DNS | 2-4 h | Zielwert, per DR-Sanity-Check bestaetigen |
-| Tier 1 | Gitea, Vaultwarden, Paperless, Immich | TBD | offen |
+| Tier 1 | Gitea, Vaultwarden, Paperless, Immich | 4-8 h | Zielwert, einzelne Restore-Tests vorhanden |
-| Tier 2 | Nextcloud, Mealie, Monitoring | TBD | offen |
+| Tier 2 | Nextcloud, Mealie, Monitoring | < 24 h | Zielwert, Restore-Pfade dokumentiert |
-| Tier 3 | Komfort-/Ops-Tools | TBD | offen |
+| Tier 3 | Komfort-/Ops-Tools | Best effort / rebuildbar | Zielwert, keine harte SLA |
 
 ## Review-Log
 
 | Datum | Befund | Entscheidung |
 |---|---|---|
-| 2026-05-26 | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; keine validierte USV-Abschaltung | Capacity gruen; USV wird aktuell nicht angeschafft, Power-Loss-Risiko bewusst akzeptiert; externe Backup-/Cold-Storage-Groessen bleiben offen |
+| 2026-05-26 | Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; keine validierte USV-Abschaltung | Capacity gruen; USV wird aktuell nicht angeschafft, Power-Loss-Risiko bewusst akzeptiert; zweites Off-site/Cold-Storage bewusst nicht umgesetzt |
-| 2026-05-26 | H:/ als dauerhaft verbundenes Windows-Laufwerk evaluiert | als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll; nicht als Offsite-Ersatz und nicht als Borg-CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC bleibt der getestete Weg |
+| 2026-05-26 | H:/ als dauerhaft verbundenes Windows-Laufwerk evaluiert | als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll; nicht als Offsite-Ersatz und nicht als Borg-CIFS-Hard-Mount am Unraid |
-| 2026-05-26 | H:/ Kapazitaet erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy` | genug Reserve fuer Nearline-Pull der kritischen Restore-Artefakte; Pull-Schedule bleibt offen |
+| 2026-05-26 | H:/ Kapazitaet erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy` | genug Reserve fuer Nearline-Pull der kritischen Restore-Artefakte |
-| 2026-05-27 | H:/ Pull-Workflow vorbereitet | SMB-Quelle `\\192.168.178.58\backups` erreichbar; PowerShell-Skript und Runbook erstellt; empfohlener Schedule taeglich 05:30, aber Task noch nicht aktiviert |
+| 2026-05-27 | H:/ Pull-Workflow vorbereitet | SMB-Quelle `\\192.168.178.58\backups` erreichbar; PowerShell-Skript und Runbook erstellt |
+| 2026-05-28 | H:/ Pull-Workflow produktiv | Windows Scheduled Task `KalliLab H Drive Nearline Pull` taeglich 05:30 aktiv |
+| 2026-06-01 | H:/ Pull nach Redis-/Major-Cutover-Artefakten gehaertet | Borg-Dumps-Job kopiert nur kuratierte Pflichtdateien; manueller Kontrolllauf erzeugte Report `nearline-pull-2026-06-01-082553.md` |

docs/CODEX_ENDSTUFE_PROMPT_2026-05-23.md

@@ -1,32 +0,0 @@
-# Codex-Prompt: KalliLab Endstufe
-
-Du hast Vollzugriff auf `G:\Gitea_Clone\homelab-infra`, Gitea-Push, Komodo, und SSH auf Unraid `Kallilabcore`.
-
-## Lies zuerst
-1. `CLAUDE.md`
-2. `docs/AUDIT_2026-05-23.md` — dort steht die komplette Restliste
-
-## Auftrag
-Den Audit von oben verifizieren und die offenen Punkte abarbeiten, bis das Homelab in der Endstufe ist. Reihenfolge:
-
-1. **P0** — Lokalen Commit `cd650b1` nach Gitea pushen, danach Komodo-Reaktion fuer `gitea` und `borg-ui` pruefen.
-2. **P0** — Live-Daten aus Audit-Abschnitt 9 messen und in `docs/AUDIT_2026-05-23_LIVE.md` ablegen (Secrets redacten).
-3. **P1** — Monitoring-Stack (`monitoring/`) live deployen, alte `ops/grafana-influxdb` und `ops/loki` `down` (nicht loeschen).
-4. **P1** — Jellyfin und Plex in `HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md` nachtragen. Plex-Eintrag "nicht als Repo-Stack enthalten" korrigieren.
-5. **P2** — Borg-Lauf-Frische pruefen, ggf. neuen Lauf ausloesen, alle 14 Dump-Artefakte juenger als 24 h.
-6. **P3** — Repo-Hygiene: 8 leere Verzeichnisse weg, `.serena/` in `.gitignore`, Entscheidung zu `ops/windows-reinstall/*.ps1`.
-
-## Regeln (aus CLAUDE.md, nicht verhandelbar)
-- Secrets nie im Klartext ausgeben.
-- Keine Aenderungen direkt in Komodo, nur ueber Git → Push → Komodo.
-- Kein `push --force`, kein blindes Loeschen von `/mnt/user/{appdata,documents,photos,services,backups}`.
-- Working-Tree-Status nur aus `git status --short` ableiten, nie aus `git diff` ueber Linux-Mount.
-- Traefik dynamic config wird nicht von Komodo deployed — Aenderungen dort manuell auf `/mnt/user/appdata/traefik/dynamic/` syncen.
-- Nicht anfassen: Hermes, Disk1 NTFS Phase 2, Komodo-Auth, Grafana/InfluxDB `user: "0"`, Image-Pinning ddns/glances/scrutiny.
-- Wenn zwei Reparaturversuche scheitern: stoppen, Drift-Runbook Pflichtmatrix, Operator fragen.
-
-## Arbeitsmodus pro Block
-Lesen → minimal aendern → `ops/policy-checks/check_repo.ps1` lokal → Commit → Push → Komodo-Reaktion + Smoke-Test → eine Zeile in `docs/MIGRATION_LOG.md`.
-
-## Fertig
-Wenn alles abgearbeitet ist (oder ein Punkt bewusst offen bleibt): `docs/AUDIT_2026-05-23_FINAL.md` schreiben mit Ampel + konkretem Beleg pro Punkt, committen, pushen, kurz an mich melden.

docs/DISASTER_RECOVERY.md

@@ -62,7 +62,8 @@ Diese Punkte sollten **vor** einem echten Ausfall geklaert sein:
 
 | Thema | Sollzustand |
 |---|---|
-| Repo-Zugang ausserhalb von Gitea | privater GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` und lokaler aktueller Clone vorhanden |
+| Repo-Zugang ausserhalb von Gitea | privater GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` und lokaler aktueller Clone vorhanden; fuer Bare-Metal-DR zusaetzlich Read-Only-PAT/Deploy-Key offline im DR-Kit |
+| Operator-DR-Workstation | Gaming-PC mit aktuellem Repo-Clone, WSL2 + Borg-Client, SSH-Key fuer Hetzner Storage Box, Offline-Kopie Borg-Passphrase; Bestandteile siehe `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit" |
 | Unraid USB-/Flash-Backup | `unraid-flash-config.tar.gz` wird vor Borg unter `/mnt/user/backups/borg/dumps/latest` erzeugt und nach Hetzner/Borg gesichert; Unraid-Connect-Cloud-Backup optional zusaetzlich |
 | Borg-Ziel | nicht nur lokal auf demselben Ausfallpfad |
 | Borg-Passphrase | Host-Secret-Datei vorhanden und fuer Borg-Zugriff verifiziert; externe Offline-Hinterlegung vom Operator am 2026-05-26 bestaetigt |
@@ -87,9 +88,15 @@ Deshalb gilt:
 
 Verfuegbare Wege:
 
-- externer Push-Mirror: `https://github.com/michaelkaleschke-spec/homelab-infra`
+- externer Push-Mirror: `https://github.com/michaelkaleschke-spec/homelab-infra` (privat, Read-PAT/Deploy-Key noetig — siehe `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit")
-- lokaler Bare-Clone auf dem PC
+- lokaler Bare-Clone auf der Operator-DR-Workstation (Standardweg)
-- normaler lokaler Arbeits-Clone auf dem PC
+- normaler lokaler Arbeits-Clone auf der Operator-DR-Workstation
+
+Operativer Pfad fuer den Repo auf den frisch installierten Unraid-Host:
+
+1. Operator-DR-Workstation holt den aktuellen Clone (lokaler Stand oder per `git clone` aus dem GitHub-Mirror mit dem offline gesicherten Read-PAT/Deploy-Key).
+2. Kopie via USB, SMB oder `rsync ueber SSH/Tailscale` nach `/mnt/user/services/homelab-infra/` auf dem Unraid-Host.
+3. Stand pruefen: `git -C /mnt/user/services/homelab-infra log --oneline -1` zeigt einen plausibel aktuellen Commit.
 
 Wenn **weder GitHub-Mirror noch lokaler Repo-Clone** verfuegbar sind, ist `services/gitea/data` selbst ein kritischer Restore-Pfad.
 
@@ -148,6 +155,12 @@ Erwartete Basis unter `/mnt/user/appdata/secrets/`:
 - `redis_password.txt`
 - `borg_repo_passphrase.txt`
 - `vaultwarden_admin_token.txt`
+- `homelab_smtp_password.txt`
+- `n8n_encryption_key.txt`
+- `monitoring_grafana_admin_password.txt`
+- `monitoring_grafana_influxdb_token.txt`
+- `influxdb3_admin_token.json`
+- `filebrowser_admin_password.txt`
 - `hermes_runner_id_ed25519`
 
 Weitere relevante Secret-Pfade:
@@ -241,17 +254,52 @@ Besonders kritisch:
 
 **Nicht blind alles extrahieren**, wenn nur einzelne Pfade oder Dienste betroffen sind.
 
+### 7.3 Borg-Extract ohne `borg-ui`-Container
+
+Im Bare-Metal-Fall ist `borg-ui` selbst kalt. Der initiale Borg-Extract laeuft deshalb nicht ueber den Container, sondern wahlweise ueber:
+
+1. **Operator-DR-Workstation** (Standardweg) - WSL2 + `borgbackup` extrahieren gezielt nach `/mnt/user/backups/restore-lab/...` oder per `rsync`/SMB auf den Unraid-Host.
+2. **Native Docker-Variante auf Unraid** - `docker run --rm -e BORG_PASSPHRASE=... -v /mnt/user/backups/restore-lab:/restore -v ~/.ssh:/root/.ssh:ro borgbackup/borg:1.4 ...`.
+
+Erst nach Stufe 5 Phase 4 ist `borg-ui` produktiv und uebernimmt den weiteren Betrieb. Die Borg-Passphrase wird interaktiv aus der Offline-Sicherung eingegeben, nicht in Skripte/Tickets kopiert.
+
 ---
 
 ## 8. Phase 4 - Bootstrap-Reihenfolge der Stacks
 
 **Nie alle Stacks gleichzeitig starten.**
 
+### Stufe 0 - Docker-Grundlage
+
+Vor dem ersten `docker compose up` muss sichergestellt sein:
+
+1. `docker info` antwortet ohne Fehler.
+2. Externe Docker-Netze existieren. Wenn nicht vorhanden:
+
+   ```bash
+   docker network create --driver bridge frontend_net
+   docker network create --driver bridge --internal backend_net
+   docker network create --driver bridge monitoring_net
+   ```
+
+3. Pfad `/mnt/user/appdata/traefik/dynamic/` enthaelt `middlewares.yml`, `tls.yml`, `dashboards.yml` (Sonderregel siehe Sektion 10). Ohne diese Dateien startet Traefik ohne Middleware-Definitionen und alle Authelia-geschuetzten Routen brechen still.
+
+Erfolgskriterium: `docker network ls` zeigt `frontend_net`, `backend_net`, `monitoring_net`; Traefik-`dynamic/`-Dateien sind vorhanden und valide.
+
 ### Stufe 1 - Netz und Zugang
 
 1. `traefik/`
 2. `host-services/Adguard/`
-3. `host-services/tailscale/`
+
+> **Tailscale-Hinweis:** Tailscale laeuft als **natives Unraid-Plugin**
+> (`tailscale.plg`, Interface `tailscale1`, State `/boot/config/plugins/tailscale/state`,
+> im Flash-Backup gesichert) und ist der Subnet-Router fuer `192.168.178.0/24`.
+> Es ist **kein** Compose-/Komodo-Stack mehr und kommt mit dem Host hoch — daher
+> nicht in dieser Bootstrap-Liste. Der frueher hier gelistete Docker-Stack
+> `host-services/tailscale/` (userspace-only, redundant) wurde am 2026-06-06
+> entfernt (siehe `docs/NETWORK_INVENTORY.md`).
+
+**LE-Rate-Limit-Vorsicht:** Wenn `/mnt/user/appdata/traefik/letsencrypt/acme.json` verloren oder unklar ist, zuerst gegen Let's Encrypt Staging ausstellen lassen (`--certificatesresolvers.le.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory`). Erst nach gruenem Smoke wieder auf Production-CA. Hintergrund: 50 Zertifikate pro Domain pro Woche reicht bei einem hektischen Wiederanlauf nicht, wenn man die Sub-Domains mehrfach hochzieht.
 
 Ziel:
 
@@ -261,7 +309,7 @@ Ziel:
 
 ### Stufe 2 - Gemeinsame Backends und Identity
 
-4. `infra/postgresql17/`
+4. `infra/postgresql17/` (PostgreSQL 18 runtime, historischer Stack-Name bleibt fuer Service-DNS stabil)
 5. `security/authelia/`
 6. `infra/redis/`
 7. `core/gitea/`
@@ -290,6 +338,13 @@ Ziel:
 - Periphery verbindet sich wieder
 - Stacks koennen wieder aus Git konsumiert werden
 
+**Wichtige Stolperfallen in Stufe 3:**
+
+- **KOMODO_*-Werte sind nicht aus dem eigenen Mongo-Dump rekonstruierbar.** Pflichtquelle im Bare-Metal: offline gesicherte Operator-Notiz (Status 2026-06-03: noch nicht angelegt, siehe `docs/EXTERNAL_DEPENDENCIES.md` und Audit-Restliste). Vaultwarden ist erst in Stufe 4 verfuegbar.
+- **Mongo-Datadir und `komodo_mongo_password.txt` muessen aus demselben Snapshot stammen.** Bei Mismatch akzeptiert Mongo den Login nicht und der Stack startet nicht. Auswege: entweder die zur Datadir passende Secret-Datei aus dem gleichen Borg-Stand restaurieren, oder Datadir leeren, neu initialisieren und Daten via `mongorestore --archive --gzip` aus `komodo-mongo.archive.gz` einspielen (Drill belegt 2026-06-03).
+- **`extra_hosts: git.kaleschke.info:192.168.178.58`** in `ops/komodo/docker-compose.yml` ist hardgecodet. Bei geaenderter Host-LAN-IP auf der Recovery-Hardware den Wert vor `compose up` anpassen, sonst kann Komodo-Core das interne Gitea nicht erreichen.
+- **Stack-ENV-Werte fuer Apps in Stufe 4** (Paperless/Immich/Mailarchiver/Speedtest) sind in Stufe 3 noch leer. Zwei Wege: (a) optionaler `mongorestore` aus `komodo-mongo.archive.gz` direkt nach Komodo-Start, dann sind alle Stack-ENVs zurueck; (b) Werte manuell in der Komodo-UI eintragen, sobald Vaultwarden in Stufe 4 verfuegbar ist (was Paperless/Immich/Mailarchiver hinter Vaultwarden zwingt, nicht parallel).
+
 ### Stufe 4 - Kritische Anwendungen
 
 9. `security/vaultwarden/`
@@ -342,6 +397,7 @@ Ziel:
 - Mealie startet
 - Mail-Archiver startet
 - Nextcloud startet und sieht Dateien
+- Pro App: `docker logs <container>` zeigt keine `password authentication failed`-, `FATAL: role does not exist`- oder `Connection refused`-Eintraege (verifiziert, dass Stack-ENV-Werte und DB-Rollen passen)
 
 ### 9.4 Backup-/Beobachtungsebene
 
@@ -382,7 +438,7 @@ Vor dem Start muessen vorhanden sein:
 - `/mnt/user/appdata/secrets/authelia_smtp_password.txt`
 - SMTP-Zugang fuer `michideheld@gmx.de`
 
-Beim Smoke-Test muss `authelia validate-config` erfolgreich sein; der SMTP-Startup-Check darf den Start nicht blockieren.
+Beim Smoke-Test muss `authelia config validate` erfolgreich sein; der SMTP-Startup-Check darf den Start nicht blockieren.
 
 ### `nextcloud`
 
@@ -396,6 +452,12 @@ Vor dem Start muessen vorhanden sein:
 
 Zusaetzlich muss der Nutzdatenpfad `/mnt/user/documents/nextcloud-data` erreichbar sein.
 
+Beim PostgreSQL-Restore beachten:
+
+- vor einem produktiven Dump `occ maintenance:mode --on` setzen
+- die produktive DB-Rolle kann von `POSTGRES_USER` abweichen; aktuell nutzt Nextcloud laut `config.php` die Rolle `oc_admin`
+- nach Restore und erfolgreichem `occ status` den Wartungsmodus mit `occ maintenance:mode --off` beenden
+
 ### Borg-Dumps
 
 Die Dump-Erzeugung ist host-seitig gedacht, nicht als Borg-UI-Inline-Hook.
@@ -406,6 +468,50 @@ Relevant:
 - Skript: `ops/borg-ui/scripts/pre-backup-dumps.sh`
 - Unraid-Flash-Artefakt: `unraid-flash-config.tar.gz` plus `.sha256` und Manifest im selben Zielpfad
 
+### Redis 8 Restore / Rollback
+
+Redis-Instanzen laufen auf der 8.x-Schiene. Vor Major-Upgrades wird `redis-cli SAVE` ausgefuehrt und der jeweilige Datenpfad kopiert.
+
+Aktive Pfade und Besonderheiten:
+
+- Shared Redis: `/mnt/user/appdata/redis`, Passwort aus `redis_password.txt`, AOF aktiv.
+- Nextcloud Redis: `/mnt/user/appdata/nextcloud/redis`, ohne Redis-Passwort, Snapshot-Persistenz.
+- Immich Redis: cache/queue-only ohne bind-mounted Datenpfad; Restore-Wahrheit ist Immich Postgres + Foto-Dateien, nicht Redis.
+
+Rollback:
+
+1. Abhaengige App stoppen.
+2. Redis stoppen.
+3. Compose auf das vorherige Redis-7.4-Image zuruecksetzen.
+4. Bei Shared/Nextcloud den vor dem Cutover kopierten Datenpfad zurueckkopieren.
+5. Redis und App starten, `redis-cli INFO server` und App-Smoke pruefen.
+
+### PostgreSQL 18 Major-Upgrade / Rollback
+
+Produktive PostgreSQL-18-Cluster verwenden das Docker-Image-Layout mit Host-Mount auf `/var/lib/postgresql` und `PGDATA=/var/lib/postgresql/18/docker`.
+
+Aktive Datenpfade:
+
+- Shared PostgreSQL: `/mnt/user/appdata/postgresql18`
+- Mealie PostgreSQL: `/mnt/user/appdata/mealie/postgres18`
+- Nextcloud PostgreSQL: `/mnt/user/appdata/nextcloud/postgres18`
+
+Rollback-Altstaende wurden nach Burn-in am 2026-06-02 reversibel archiviert:
+
+- Shared PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`
+- Mealie PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`
+- Nextcloud PostgreSQL 17: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`
+
+Restore-Reihenfolge fuer den Shared-Cluster:
+
+1. Frischen PostgreSQL-18-Cluster starten.
+2. Globals aus `pg_dumpall --globals-only` einspielen.
+3. Den bekannten Bootstrap-Konflikt fuer `CREATE ROLE mailarchiver;` gezielt tolerieren bzw. herausfiltern, danach `ALTER ROLE mailarchiver ...` dennoch einspielen.
+4. Datenbanken anlegen und Custom-Format-Dumps mit `pg_restore` einspielen.
+5. Restore-Logs auf echte `ERROR`, `FATAL` und `PANIC` pruefen.
+
+Immich ist bewusst nicht Teil dieses PostgreSQL-18-Laufs: Die produktive DB bleibt auf PostgreSQL 14 und nutzt das Immich-Postgres-Image mit VectorChord/pgvector. VectorChord-Backups brauchen zum Restore ein Image mit VectorChord; der alte pgvecto.rs-Datenpfad ist als Rollback-Altstand unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs` archiviert.
+
 ### Hermes Agent
 
 Hermes nutzt einen lokalen Build und hostseitige Runtime-Daten.
@@ -423,6 +529,40 @@ Smoke-Test: `hermes-gateway` healthcheck ist gruen, `hermes.kaleschke.info` leit
 
 `Micha/homelab-infra` wird als privater GitHub-Push-Mirror gespiegelt. Dieser Mirror ist der bevorzugte Repo-Bootstrap, falls Gitea selbst nach einem Ausfall noch nicht laeuft. Wenn weder GitHub-Mirror noch lokaler Clone verfuegbar sind, ist `services/gitea/data` selbst Teil des kritischen Wiederanlaufs.
 
+### Windows-Workstation `baerchen`
+
+`baerchen` ist die Operator-Workstation und haelt den lokalen Clone unter
+`G:\Gitea_Clone\homelab-infra`. Fuer einen schnellen Windows-Bare-Metal-Restore
+existiert ein Veeam-Agent-Image-Workflow.
+
+Wichtige Pfade und Artefakte:
+
+- Runbook: `ops/windows-reinstall/docs/windows-image-backup-baseline.md`
+- Backup-Ziel: `\\kallilabcore\backups\windows-images\baerchen`
+- Host-Pfad: `/mnt/user/backups/windows-images/baerchen/`
+- Recovery-Medium: USB-Stick `VEEAMRE`, beschriftet
+  `baerchen Veeam Recovery - 2026-06-05`
+- Veeam Job: `baerchen-c-image`
+- Veeam Storage Encryption: erster Full-Lauf 2026-06-05 laut Job-Log
+  unverschluesselt (`StorageEncryptionEnabled=False`); falls spaeter aktiviert,
+  Passwort in Vaultwarden Secure Note `Veeam baerchen backup encryption password`
+  sichern
+
+Restore-Kurzpfad:
+
+1. Von `VEEAMRE` booten.
+2. SMB-Ziel `\\kallilabcore\backups\windows-images\baerchen` oeffnen.
+3. Mit bestehendem SMB-User `micha` authentifizieren.
+4. Restore Point auswaehlen.
+5. Falls der Restore Point verschluesselt ist: Veeam-Encryption-Passwort aus
+   Vaultwarden eingeben.
+6. Bare-Metal-Restore nur auf die Windows-Systemdisk ausfuehren.
+
+BitLocker ist am 2026-06-05 bewusst noch nicht aktiv. Falls BitLocker spaeter
+aktiviert wird, muss der Recovery-Key vor dem naechsten Restore-Drill in
+Vaultwarden, unter `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt`
+und physisch ausserhalb des Rechners abgelegt sein.
+
 ---
 
 ## 11. Offene Vorbereitungs-To-dos
@@ -432,6 +572,8 @@ Smoke-Test: `hermes-gateway` healthcheck ist gruen, `hermes.kaleschke.info` leit
 - Komodo Stack-ENV-Werte zentral ausserhalb von Komodo dokumentieren
 - regelmaessige automatisierte Restore-Smoke-Tests fuer Vaultwarden, Gitea und Paperless etablieren
 - `komodo-mongo`-Dump nach Major-Upgrades gezielt kontrollieren
+- `baerchen` Recovery-USB-Boot-/SMB-Test nach erfolgreichem erstem Full-Lauf
+  verifizieren
 
 ---
 

docs/DISK1_PHASE2_PLAN_2026-05-23.md

@@ -1,77 +0,0 @@
-# Disk1 Phase 2 - NTFS to XFS Migration
-
-Stand: 2026-05-25 06:15 CEST. Ziel erreicht: `/mnt/disk1` wurde von `ntfs3` auf XFS migriert, ohne produktive Compose-Pfade zu aendern. Container nutzen weiter `/mnt/user/...`.
-
-## Preflight
-
-| Check | Ergebnis |
-|---|---|
-| Disk1 Mount | `/dev/md1p1` auf `/mnt/disk1`, `ntfs3`, 5.5T, 1.7T genutzt, 3.8T frei |
-| Cache Mount | `/dev/nvme0n1p1` auf `/mnt/cache`, `xfs`, 1.9T, 100G genutzt |
-| H: Backup-Ziel | `H:\`, Label `Externe HDD`, NTFS, 8T, 5.96T frei, healthy |
-| Compose-Binds | Keine Treffer fuer direkte `/mnt/disk1`, `/mnt/cache`, `/mnt/disks`, `/mnt/remotes` Binds |
-| SMB-Zugriff | `\\Kallilabcore\services`, `documents`, `photos`, `media` erreichbar |
-
-## Zu sichernde Shares
-
-| Share | Groesse laut Preflight |
-|---|---:|
-| `services` | 451M |
-| `documents` | 196M |
-| `photos` | 23G |
-| `backups` | 2.2G |
-| `media` | 1.7T |
-| `finance` | 0 |
-| `projekte` | 92K |
-
-Zusaetzliche Disk1-Top-Level-Pfade: `scripts` 3.3M, `isos` 0, `System Volume Information` 0.
-
-## Backup-Strategie
-
-- Zielroot: `H:\kallilab-recovery\disk1-phase2-2026-05-23`.
-- Kritischer Linux-/GitOps-Pfad `services` wird zusaetzlich als Tar-Archiv ueber SSH gesichert, damit Linux-Metadaten erhalten bleiben.
-- User-Shares werden per SMB/Robocopy kopiert, mit Logs und anschliessender Zaehler-/Groessenverifikation.
-- Keine produktiven Datenpfade werden geloescht.
-
-## Gates
-
-1. Backup komplett und verifiziert.
-2. Dienste-Freeze vorbereitet und letzte Dumps frisch.
-3. Direkt vor Format/Array-Prozedur: Operator-Bestaetigung im konkreten Moment.
-
-## Backup-Ergebnis
-
-Stand: 2026-05-24 13:07 CEST.
-
-| Bereich | Sicherungsart | Ergebnis |
-|---|---|---|
-| `media` | Robocopy/SMB nach `H:\kallilab-recovery\disk1-phase2-2026-05-23\shares\media` | 2722 Dateien, 1677.11 GiB, Manifestvergleich: 0 missing, 0 size mismatch, 0 extra |
-| `services` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `services.tar`, 0.441 GiB, `tar -tf` gueltig |
-| `documents` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `documents.tar`, 0.192 GiB, `tar -tf` gueltig |
-| `photos` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `photos.tar`, 22.876 GiB, `tar -tf` gueltig |
-| `backups` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `backups.tar`, 2.099 GiB, `tar -tf` gueltig |
-| `finance` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `finance.tar`, leerer Share, `tar -tf` gueltig |
-| `projekte` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `projekte.tar`, klein, `tar -tf` gueltig |
-| Disk1-Extras `scripts`, `isos` | Host-Tar auf Unraid Cache, danach binaer per `scp` nach H: | `disk1-extra.tar`, 0.003 GiB, `tar -tf` gueltig |
-
-Hinweis: Erste Tar-Versuche per PowerShell-Redirect wurden verworfen, weil PowerShell den binaeren SSH-Stream als UTF-16 geschrieben hatte. Die ungueltige `media.tar` und unvollstaendige SMB-Teilkopien fuer `services`/`documents` wurden vom Backup-Ziel entfernt, damit nur verwertbare Sicherungen uebrig bleiben.
-
-## Abschluss
-
-Stand: 2026-05-25 06:15 CEST.
-
-| Check | Ergebnis |
-|---|---|
-| Freeze-Dumps | `pre-backup-dumps.sh` vor Format ausgefuehrt; nach Wiederanlauf erneut erfolgreich, 15 kanonische Dump-Artefakte juenger als 24 h |
-| Disk1 Filesystem | `/dev/md1p1` auf `/mnt/disk1`, `xfs`, 5.5T, 1.8T genutzt, 3.7T frei |
-| Restore `media` | 2722 Dateien, 1,800,782,188,226 Bytes; finaler Manifestvergleich: 0 missing, 0 size mismatch, 0 extra |
-| Restore Tar-Shares | `services`, `documents`, `photos`, `backups`, `finance`, `projekte` und Disk1-Extras aus H:-Freeze-Archiven nach `/mnt/disk1` extrahiert |
-| Docker/Services | 49 Container laufend, 0 stopped, 0 unhealthy, 0 starting |
-| Smoke-Tests | `git.kaleschke.info` 200, `komodo.kaleschke.info` 200, `borg.kaleschke.info` 302, `jellyfin.kaleschke.info` 302, `monitoring.kaleschke.info` 302 |
-| Service-Mounts | Gitea SSH `:222` offen; Jellyfin und Plex sehen `/media`; Prometheus readiness ok |
-| Backup-Lauf | Borg-UI Repository `appdata-critical`, letzter Job `completed`, Archiv `Taegliche-Sicherung-2026-05-25T05:52:44.157`, `nfiles=100221` |
-| Temp-Cleanup | `/mnt/cache/disk1-phase2-tmp/*.tar` nach H:-Verifikation geloescht; Cache weiter XFS mit ca. 1.7T frei |
-
-Hinweis zum Docker-Wiederanlauf: Nach dem manuellen Docker-Start liefen die Container, aber Healthcheck-Execs scheiterten wegen `dockerd` mit `XDG_RUNTIME_DIR=/run/user/0`. Ein gezielter Docker-Neustart mit unsetztem `XDG_RUNTIME_DIR` behob den Runtime-Fehler; danach wurden alle Healthchecks gruen. `monitoring-prometheus` war durch den geplanten Docker-Stop sauber beendet und wurde als bestehender Container wieder gestartet.
-
-Offener Nachlauf: Die Array-Parity-Anzeige zeigte nach Abschluss weiter `mdNumDisabled=1`, `mdNumInvalid=1` und `mdResyncAction=check P`, waehrend beide beteiligten Devices `rdevStatus=DISK_OK` und `rdevNumErrors=0` melden. Parity-Zustand separat in Unraid pruefen und keinen Parity-/Disk-Slot ohne Operator-Entscheid aendern.

docs/DR_DRILL_2026-06-03.md

@@ -0,0 +1,504 @@
+# DR Tabletop Drill - 2026-06-03
+
+Trockenlauf gegen `docs/DISASTER_RECOVERY.md` Phase 0 bis 5 plus referenzierte
+Runbooks (`SERVICES_RECOVERY.md`, `RESTORE_MATRIX.md`, `SECRETS_MAP.md`,
+`RESTORE_HANDBOOK.md`, `EXTERNAL_DEPENDENCIES.md`).
+
+Szenario: Bare-Metal-Ausfall. Unraid-Host und alle lokalen Festplatten sind
+weg. Operator hat: Laptop, Hetzner-Account, Vaultwarden-Export, Repo-Doku.
+Soft-Recovery (Host laeuft, Appdata futsch) ist eine Teilmenge dieser
+Findings.
+
+Methode: kalter Lesetest. Kein Container gestartet, keine Skripte
+ausgefuehrt. Jeder Befund ist mit Repo-Datei und Zeile belegt. Spekulative
+"vielleicht unklar"-Befunde sind weggelassen.
+
+Severity:
+
+- **CRITICAL** - blockiert Wiederanlauf, ohne Workaround nicht loesbar
+- **HIGH** - blockiert eine Phase, Workaround moeglich aber undokumentiert
+- **MED** - kostet Zeit oder fuehrt zu vermeidbarem Fehler
+- **LOW** - Konsistenz / Stil
+
+## Zusammenfassung
+
+| ID | Phase | Severity | Thema |
+|---|---|---|---|
+| P0-1 | 0 | HIGH | Brueckenpfad Windows-Clone -> frischer Unraid-Host fehlt |
+| P0-2 | 0 | HIGH | GitHub-Mirror-Zugang im DR ist nicht eigenstaendig dokumentiert |
+| P1-1 | 1 | CRITICAL | Unraid-Flash-Restore: kein dokumentierter Extract-Pfad ohne laufenden Host |
+| P1-2 | 1 | MED | Unraid-OS-Flash-Restore-Test laut Matrix nie real getestet |
+| P2-1 | 2 | HIGH | KOMODO_* externe Operator-Notiz ist Pflichtquelle, Existenz nicht verifizierbar |
+| P2-2 | 2 | HIGH | DR.md Phase 4 vs. SERVICES_RECOVERY.md Bootstrap-Reihenfolge widerspruechlich |
+| P2-3 | 2 | MED | `homelab_smtp_password.txt` fehlt in DR.md Phase 2.6.1 |
+| P2-4 | 2 | MED | `n8n_encryption_key.txt` fehlt in DR.md Phase 2.6.1 |
+| P2-5 | 2 | LOW | Monitoring-/Filebrowser-Secrets fehlen in DR.md Phase 2.6.1 |
+| P3-1 | 3 | HIGH | Borg-Client ohne `borg-ui`-Container ist nicht dokumentiert |
+| P3-2 | 3 | HIGH | Borg-Passphrase-Bootstrap aus Offline-Sicherung nicht als expliziter Schritt |
+| P3-3 | 3 | MED | Hetzner-Maintenance-Key aus Vaultwarden ist Henne-Ei im Bare-Metal |
+| P4-1 | 4 | HIGH | Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt |
+| P4-2 | 4 | HIGH | Cloudflare-LE-Rate-Limit-Risiko bei verlorenem `letsencrypt`-State |
+| P4-3 | 4 | MED | `traefik/dynamic/*` als Phase-4-Pre-Check fehlt in der Reihenfolge |
+| P4-4 | 4 | HIGH | Authelia "frische Postgres ohne Dump"-Pfad nicht beschrieben |
+| P4-5 | 4 | LOW | Gitea in Stufe 2 hinter Postgres ist faktisch nicht noetig (SQLite) |
+| P4-6 | 4 | HIGH | Komodo-Mongo Passwort-Lockout-Risiko bei restauriertem Datadir |
+| P4-7 | 4 | MED | Komodo `extra_hosts` mit hardgecodeter LAN-IP bricht bei IP-Wechsel |
+| P4-8 | 4 | HIGH | Stack-ENV-Wiederherstellung in Komodo praktisch nur manueller UI-Eintrag |
+| P5-1 | 5 | LOW | Smoke-Tests in Phase 5 weniger streng als RESTORE_MATRIX |
+| P5-2 | 5 | MED | Kein Verifikationspunkt fuer App-zu-DB-Verbindung nach Stack-ENV-Restore |
+| X-1 | uebergreifend | HIGH | Nextcloud-Restore-Skript ist da, aber noch nie real ausgefuehrt |
+
+## Phase 0 - Repo-Zugang
+
+### P0-1 (HIGH) - Brueckenpfad Windows-Clone -> frischer Unraid fehlt
+
+`docs/DISASTER_RECOVERY.md:88-93` listet als Repo-Quellen: GitHub-Mirror,
+lokaler Bare-Clone, lokaler Arbeits-Clone. `SERVICES_RECOVERY.md:67-68`
+nennt den lokalen Operator-Clone unter `G:\Gitea_Clone\homelab-infra\` als
+Vorzug.
+
+Luecke: der Pfad "wie kommt der Windows-Clone auf einen frisch installierten
+Unraid-Host" ist nicht beschrieben. Implizit: SMB-Share, USB-Stick, scp ueber
+LAN. Aber auf einem frisch aufgesetzten Unraid existiert noch keine
+funktionierende SMB-Konfiguration; SSH-Key vom Operator-PC ist nicht
+vorbereitet.
+
+Vorschlag: Zwei Saetze in `DISASTER_RECOVERY.md` Phase 0 ergaenzen, wie der
+Operator-Clone konkret zum Host kommt (USB-Stick + `mkdir -p
+/mnt/user/services/homelab-infra && rsync -a` aus Operator-Windows-PC, oder
+direkt vom GitHub-Mirror per `git clone https://github.com/...` auf dem
+Unraid-Host).
+
+### P0-2 (HIGH) - GitHub-Mirror-Zugang im DR
+
+`SECRETS_MAP.md:42` sagt, der GitHub-Push-Mirror-PAT liegt in den
+Gitea-Mirror-Settings persistent unter `/mnt/user/services/gitea/data`.
+`EXTERNAL_DEPENDENCIES.md:18` nennt den Mirror als `michaelkaleschke-spec/
+homelab-infra` und betont "privater" Push-Mirror.
+
+Luecke: Wenn der Mirror **privat** ist, scheitert ein anonymer `git clone`
+im DR-Bootstrap. Es gibt keine dokumentierte Notfall-Quelle fuer einen
+Read-PAT/SSH-Key, der lokal beim Operator (nicht in Gitea, nicht im Repo)
+verfuegbar ist.
+
+Vorschlag in `EXTERNAL_DEPENDENCIES.md`: entweder explizit dokumentieren,
+dass der Mirror lesend `Public` ist (DR-fit), oder einen Read-PAT in der
+Vaultwarden-/Offline-Notiz neben der Borg-Passphrase als Bootstrap-Voraussetzung
+benennen.
+
+## Phase 1 - Unraid und Shares
+
+### P1-1 (CRITICAL) - Unraid-Flash-Restore ohne laufenden Host
+
+`docs/DISASTER_RECOVERY.md:107` sagt: "Primaere lokale/off-site
+Restore-Quelle fuer die bestehende Flash-Konfiguration ist das
+Borg-Artefakt `unraid-flash-config.tar.gz` aus
+`/mnt/user/backups/borg/dumps/latest`."
+
+Henne-Ei: der Pfad ist auf den verlorenen Shares oder auf Hetzner. Hetzner-
+Zugriff braucht einen funktionierenden Linux-Host mit Borg-Client und
+Passphrase. Im Bare-Metal-Fall ist genau das nicht da. RESTORE_MATRIX.md
+Tier 1 Zeile `Unraid OS Flash` (`docs/RESTORE_MATRIX.md:29`) sagt nur "Unraid
+USB Flash Creator / neuer Boot-Stick" - das beschreibt die Stick-Erzeugung,
+nicht den Extract des Borg-Artefakts.
+
+Operativ: Operator braucht einen Laptop mit Borg-Client + Passphrase +
+SSH-Key fuer die Hetzner-Storage-Box. Das ist eine **separat zu pflegende
+Operator-Workstation-Voraussetzung** und ist in keinem Repo-Dokument als
+DR-Vorbedingung gelistet.
+
+Vorschlag: In `EXTERNAL_DEPENDENCIES.md` oder `DISASTER_RECOVERY.md`
+Abschnitt 3 als Pflichtposten aufnehmen: "Operator-Laptop mit installiertem
+Borg-Client, SSH-Key fuer Hetzner und Zugriff auf die offline gesicherte
+Passphrase". Inklusive Test, dass der Operator den Extract tatsaechlich
+durchfuehren kann.
+
+### P1-2 (MED) - Unraid-OS-Flash-Restore-Test nie gelaufen
+
+`docs/RESTORE_MATRIX.md:140` Spalte "Letzter Restore-Test" fuer Unraid OS
+Flash: `-` (kein Test). Das ist die Grundlage fuer Phase 1 und ist nie als
+Smoke verifiziert. Empfehlung: einmaliger Test, der die Tar-Archiv-Struktur
+gegen die erwarteten Flash-Pfade prueft (kein echter Boot-Test noetig).
+
+## Phase 2 - Secrets und Stack-ENV
+
+### P2-1 (HIGH) - KOMODO_* externe Operator-Notiz als Pflichtquelle
+
+`docs/SECRETS_MAP.md:132,138-143` macht den Komodo-Sonderfall klar: die
+KOMODO_*-Secrets sind aus dem eigenen Mongo-Dump nicht rekonstruierbar,
+solange Komodo nicht laeuft. Quellen: Vaultwarden ODER externe Notiz.
+
+Im Bare-Metal-Fall ist Vaultwarden in DR.md Phase 4 Stufe 4, Komodo in
+Phase 4 Stufe 3. Damit ist die **externe Operator-Notiz** die einzige
+Pflichtquelle in der Reihenfolge.
+
+Luecke: ob diese Notiz wirklich existiert und die 5 Werte
+(KOMODO_SECRET_KEY, KOMODO_WEBHOOK_SECRET, KOMODO_JWT_SECRET,
+KOMODO_MONGO_PASSWORD, KOMODO_PERIPHERY_PASSKEY) enthaelt, ist in keinem
+Repo-Dokument bestaetigt. Die Borg-Passphrase ist als "Operator-Bestaetigung
+2026-05-26" dokumentiert; eine analoge Bestaetigung fuer die KOMODO_*-Notiz
+fehlt.
+
+Vorschlag: gleiche Form wie Borg-Passphrase - eine Zeile in
+`EXTERNAL_DEPENDENCIES.md` "Komodo-Stack-ENV-Notiz offline gesichert,
+Operator-Bestaetigung YYYY-MM-DD".
+
+### P2-2 (HIGH) - Reihenfolgen-Inkonsistenz DR vs. SERVICES_RECOVERY
+
+`docs/SERVICES_RECOVERY.md:102` (Stufe C, Komodo-Bootstrap): "Vaultwarden
+(sobald restauriert), externe Operator-Notiz, oder Komodo-Mongo-Dump (nur
+wenn Mongo separat bereits gestartet ...)".
+
+`docs/DISASTER_RECOVERY.md:247-301` (Phase 4): Stufe 3 = Komodo, Stufe 4 =
+Vaultwarden.
+
+Wenn ein Leser sich an DR.md Phase 4 haelt, ist Vaultwarden nach Komodo
+fertig. Aber SERVICES_RECOVERY.md Stufe C setzt Vaultwarden als optionale
+Vorab-Quelle voraus. Ohne externe Notiz heisst das praktisch: Komodo kann
+nicht starten. Die Konsequenz steht nirgendwo explizit in DR.md.
+
+Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 3 einen Hinweisblock
+ergaenzen: "KOMODO_*-Werte muessen vor Stufe 3 aus externer Notiz oder
+einer in Stufe 2 voraus gezogenen Vaultwarden-Instanz vorliegen. Default-
+Pfad: externe Notiz."
+
+### P2-3 (MED) - `homelab_smtp_password.txt` fehlt in DR.md 6.1
+
+`docs/SECRETS_MAP.md:20` listet `/mnt/user/appdata/secrets/
+homelab_smtp_password.txt` fuer Vaultwarden-SMTP. In `DISASTER_RECOVERY.md`
+Abschnitt 6.1 (`docs/DISASTER_RECOVERY.md:136-151`) ist sie nicht
+aufgefuehrt. Vaultwarden startet ohne, kann aber keine Einladungs-/
+Benachrichtigungs-Mails versenden. Klein, aber unsichtbarer Folgefehler im
+Familien-Onboarding-Pfad.
+
+### P2-4 (MED) - `n8n_encryption_key.txt` fehlt in DR.md 6.1
+
+`docs/SECRETS_MAP.md:58` listet `/mnt/user/appdata/secrets/
+n8n_encryption_key.txt`. In DR.md 6.1 fehlt sie komplett.
+`SECRETS_MAP.md:135` macht die Folgen explizit: "Bei Verlust aller
+Quellen: n8n startet, aber alle gespeicherten Credentials sind unbrauchbar".
+Da n8n den GMX-Mail-Workflow fuer das Gitea-`Micha/mails`-Repo betreibt,
+ist das ein direkter Workflow-Ausfall.
+
+### P2-5 (LOW) - Monitoring-/Filebrowser-Secrets fehlen in DR.md 6.1
+
+`docs/SECRETS_MAP.md:53-55`: `influxdb3_admin_token.json`,
+`monitoring_grafana_admin_password.txt`,
+`monitoring_grafana_influxdb_token.txt` sowie
+`filebrowser_admin_password.txt` sind nicht in DR.md 6.1. Tier-3-Apps,
+Folge ist nur ein UI-Initialisierungs-Schritt nach Wiederanlauf. Keine
+Critical-Konsequenz, aber Inkonsistenz.
+
+## Phase 3 - Borg-Extract
+
+### P3-1 (HIGH) - Borg-Client ohne `borg-ui`-Container
+
+`docs/RESTORE_HANDBOOK.md:30-33` sagt explizit: "Borg-Zugriff laeuft ueber
+den vorhandenen `borg-ui`-Container".
+
+Im Bare-Metal-Fall ist `borg-ui` selbst kalt (Tier 3, DR.md Phase 4 Stufe 5).
+Es gibt keinen dokumentierten Pfad, wie der erste Borg-Extract ohne diesen
+Container laeuft. Implizite Optionen: nativer Borg auf Unraid (Plugin),
+`docker run --rm borgbackup/borg`, oder Operator-Laptop. Keine davon ist
+benannt.
+
+Vorschlag: In `RESTORE_HANDBOOK.md` Abschnitt 2 einen "Bare-Metal-Vorlauf"
+ergaenzen, der den initialen Borg-Extract ohne borg-ui-Container
+beschreibt - z. B. `docker run --rm -v
+/mnt/user/backups/restore-lab:/restore borgbackup/borg ...`.
+
+### P3-2 (HIGH) - Borg-Passphrase-Bootstrap nicht als expliziter Schritt
+
+`docs/DISASTER_RECOVERY.md:68`: "Host-Secret-Datei vorhanden und fuer
+Borg-Zugriff verifiziert; externe Offline-Hinterlegung vom Operator am
+2026-05-26 bestaetigt."
+
+Praktisch heisst das: im Bare-Metal-Fall liest der Operator die Passphrase
+aus einem analogen Medium und tippt sie in den Borg-Client. Das ist ein
+**Bootstrap-Schritt**, der nicht als Schritt dokumentiert ist. Er steckt
+implizit in "extern bestaetigt".
+
+Vorschlag: Ein nummerierter Bullet in `DISASTER_RECOVERY.md` Phase 3 ("Wenn
+echte Daten aus Borg benoetigt werden"): "Schritt 1: Borg-Passphrase aus
+Offline-Sicherung beschaffen. Wert wird nicht in Skripte oder Tickets
+kopiert; nur in den interaktiven Borg-Aufruf eingegeben."
+
+### P3-3 (MED) - Hetzner-Maintenance-Key im Bare-Metal
+
+`docs/EXTERNAL_DEPENDENCIES.md:17`: "Maintenance-Key liegt in Vaultwarden".
+
+Im Bare-Metal-Bootstrap ist Vaultwarden Phase 4 Stufe 4. Damit ist der Key
+fuer die initiale Phase-3-Hetzner-Verbindung nicht zugaenglich. Implizit
+muss er ebenfalls offline gesichert sein (analog Borg-Passphrase).
+
+Vorschlag: gleiche Form wie Borg-Passphrase - eine Operator-Bestaetigung
+in `EXTERNAL_DEPENDENCIES.md`, dass der Hetzner-SSH-Key auch ausserhalb von
+Vaultwarden offline verfuegbar ist. Sonst ist die "Vaultwarden"-Aussage
+fuer Bare-Metal eine Falle.
+
+## Phase 4 - Bootstrap-Reihenfolge
+
+### P4-1 (HIGH) - Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt
+
+`docs/SERVICES_RECOVERY.md:82-84` Stufe A schreibt explizit: "Externe
+Docker-Netze existieren oder werden erzeugt (`frontend_net`, `backend_net`).
+Wenn nicht vorhanden: `docker network create --driver bridge frontend_net`
+bzw. `... --internal backend_net`."
+
+`docs/DISASTER_RECOVERY.md:252-260` Phase 4 Stufe 1 nennt nur Traefik,
+AdGuard, Tailscale. Kein Hinweis auf externe Netze.
+
+`traefik/docker-compose.yml:70-76` deklariert `frontend_net`, `backend_net`,
+`monitoring_net` als `external: true`. Ohne vorab erstellte Netze scheitert
+der erste `docker compose up` mit "network frontend_net not found".
+
+Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 vor Stufe 1 einen Vorlauf
+"Stufe 0 - Docker-Grundlage" einfuegen, der die Netzwerk-Erzeugung wie in
+`SERVICES_RECOVERY.md` Stufe A explizit listet.
+
+### P4-2 (HIGH) - Cloudflare-LE-Rate-Limit-Risiko
+
+`docs/RESTORE_MATRIX.md:30` markiert `letsencrypt` korrekt als
+Restore-relevant. `docs/DISASTER_RECOVERY.md:240` listet
+`/mnt/user/appdata/traefik/letsencrypt` ebenfalls als kritischen
+Borg-Restore-Pfad.
+
+Luecke: kein Hinweis auf den Praxisfall "LE-State verloren, frischer
+Acme-Run". Let's Encrypt hat ein Rate-Limit von 50 Zertifikaten/Domain/
+Woche und 5 Duplicate-Zertifikate/Woche. Bei einer Multi-Sub-Domain-
+Konstellation wie `*.kaleschke.info` (15+ Hostnames) ist das beim
+hektischen DR-Bootstrap erreichbar.
+
+Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 1 einen Hinweis: "Bei
+verlorenem oder unklarem `acme.json` zuerst gegen
+`acme-staging-v02.api.letsencrypt.org` ausstellen lassen, erst nach
+gruenem Smoke auf Production-CA umschalten." Ist eine Praesentations-
+Aenderung in den Compose-Args, kein neuer Code.
+
+### P4-3 (MED) - `traefik/dynamic/*` als Pre-Check fehlt
+
+`docs/DISASTER_RECOVERY.md:357-365` Sektion 10 beschreibt die manuelle
+Sonderregel fuer `traefik/dynamic/*`. Korrekt.
+
+`docs/DISASTER_RECOVERY.md:252-260` Phase 4 Stufe 1 verweist nicht auf
+diese Sonderregel. Wer der Reihenfolge folgt und Sektion 10 nicht liest,
+startet Traefik ohne Middlewares - alle 2FA-Routen brechen still.
+
+Vorschlag: Cross-Reference in Phase 4 Stufe 1: "Vor `docker compose up
+traefik` pruefen, dass `/mnt/user/appdata/traefik/dynamic/middlewares.yml`,
+`tls.yml`, `dashboards.yml` vorhanden sind (Sonderregel Sektion 10)."
+
+### P4-4 (HIGH) - Authelia "frische Postgres ohne Dump"-Pfad fehlt
+
+`docs/DISASTER_RECOVERY.md:267-275` Phase 4 Stufe 2 startet Postgres und
+Authelia. Authelia erwartet eine Rolle `authelia` mit dem Passwort aus
+`authelia_postgres_password.txt`. Im Restore-Pfad mit `pg_dumpall --globals-
+only` ist die Rolle abgedeckt.
+
+Bei einem **fresh-start** (keine alten Daten, nur Container hochfahren) ist
+die Rolle nicht da. Postgres-Image legt sie nicht automatisch an. Authelia
+schlaegt mit "FATAL: role authelia does not exist" fehl.
+
+Luecke: Der Initialisierungspfad fuer eine frische Postgres ohne
+pg_dumpall ist in der Doku nicht beschrieben. Im echten DR mit Borg ist
+das unwahrscheinlich, aber im Soft-Recovery oder Migrations-Drill schon.
+
+Vorschlag: In `DISASTER_RECOVERY.md` Phase 4 Stufe 2 eine optionale
+Anweisung: "Falls Postgres frisch ist (kein Dump-Restore), `infra/
+postgresql17/init/`-Skripte oder manuelle `CREATE ROLE`/`CREATE DATABASE`-
+Schritte ergaenzen."
+
+### P4-5 (LOW) - Gitea nach Postgres ist faktisch unnoetig
+
+`docs/DISASTER_RECOVERY.md:267-275` Phase 4 Stufe 2 ordnet Gitea hinter
+Postgres ein. Gitea nutzt SQLite (`gitea.sqlite.dump`), nicht den shared
+Postgres. Reihenfolge ist nicht falsch, aber irrefuehrend. Nicht kritisch.
+
+### P4-6 (HIGH) - Komodo-Mongo Passwort-Lockout-Risiko
+
+`ops/komodo/docker-compose.yml:18-20` zeigt: `komodo-mongo` initialisiert
+sich bei leerem Datadir mit `MONGO_INITDB_ROOT_PASSWORD_FILE` aus
+`/mnt/user/appdata/secrets/komodo_mongo_password.txt`.
+
+Restore-Fall: Datadir aus Borg restauriert, Secret-Datei aus Borg
+restauriert - beide aus demselben Snapshot. OK.
+
+Riskanter Fall: Datadir aus Borg, aber Secret-Datei aus einer anderen
+(neueren oder aelteren) Quelle. Mongo akzeptiert den Login nicht, Komodo
+laeuft nicht. Lockout. Doku erwaehnt diesen Pin-Punkt nicht.
+
+Vorschlag: Hinweis in `DISASTER_RECOVERY.md` Phase 4 Stufe 3: "Mongo-
+Datadir und `komodo_mongo_password.txt` muessen aus demselben Snapshot
+kommen. Bei Mismatch: leeren Datadir und Re-Init, dann Daten aus
+`komodo-mongo.archive.gz` per `mongorestore`."
+
+### P4-7 (MED) - Hardgecodete LAN-IP in `extra_hosts`
+
+`ops/komodo/docker-compose.yml:50` und `:101` haben:
+`"git.kaleschke.info:192.168.178.58"`.
+
+Bare-Metal-Recovery auf anderer Hardware oder veraenderter LAN-IP fuehrt
+zu stummem Fehler: Komodo-Core kann Gitea nicht ueber den Override
+erreichen, faellt auf AdGuard-DNS zurueck (wenn der schon laeuft) oder
+scheitert.
+
+Vorschlag: kurzer Hinweis in `DISASTER_RECOVERY.md` Phase 4 Stufe 3: "Bei
+geaenderter Host-LAN-IP `extra_hosts`-Werte in `ops/komodo/docker-compose.
+yml` vor `compose up` anpassen oder ueber `.env` parametrisieren."
+
+### P4-8 (HIGH) - Stack-ENV-Wiederherstellung praktisch manuell
+
+`docs/DISASTER_RECOVERY.md:188-195` sagt: "Wenn `komodo-mongo.archive.gz`
+frisch ist, koennen die Werte beim Komodo-Restart aus dem Dump
+zurueckgespielt werden, ohne dass jemand sie sieht."
+
+`docs/RESTORE_HANDBOOK.md:73-74` und `docs/AUDIT_2026-05-25_TODO.md:20`
+machen den Daten-Mongo-Restore als "erledigt 2026-06-03" sichtbar - aber
+NICHT als Teil des DR-Bootstraps. Komodo-Bootstrap im Trockenlauf benutzt
+Wegwerf-Werte.
+
+Praktisch heisst das: Im DR-Bootstrap (Phase 4 Stufe 3) startet Komodo
+**ohne** den Mongo-Daten-Restore. Die `KOMODO_*` kommen aus externer
+Notiz. Aber die Stack-ENVs fuer `paperless`/`immich`/`mail-archiver`/
+`speedtest` (PAPERLESS_DBPASS etc.) **muessen vor Stufe 4** wieder in
+Komodo eingetragen sein. Wenn der Mongo-Daten-Restore nicht direkt nach
+Komodo-Start passiert, gehen diese Werte manuell in die Komodo-UI.
+
+Vorschlag: Klarstellung in `DISASTER_RECOVERY.md` Phase 4 zwischen Stufe
+3 und Stufe 4: "Optionaler Mongo-Daten-Restore aus `komodo-mongo.archive.
+gz` per `ops/restore-tests/komodo-mongo-restore-test.sh`-Muster - dann
+sind alle Stack-ENVs zurueck. Alternativ: Stack-ENVs manuell in Komodo-
+UI eintragen, Quelle Vaultwarden (sobald Stufe 4 Vaultwarden laeuft -
+Henne-Ei mit Paperless: Paperless-Start dann erst nach Vaultwarden, nicht
+parallel)."
+
+## Phase 5 - Verifikation
+
+### P5-1 (LOW) - Smoke-Tests in DR.md weniger streng als Matrix
+
+`docs/DISASTER_RECOVERY.md:337-345` Phase 5.3 sagt z. B. "Vaultwarden
+startet und ist erreichbar". `docs/RESTORE_MATRIX.md:39` sagt: "Login-
+Seite erreichbar, Tresor-Daten sichtbar". Das zweite ist faktisch der
+echte Smoke-Test.
+
+Geschmackssache, kein Bug. Empfehlung: DR.md auf die Matrix-Smokes
+verweisen statt eigene Kurzversion.
+
+### P5-2 (MED) - Kein Verifikationspunkt App-zu-DB-Verbindung
+
+`docs/DISASTER_RECOVERY.md:337-345` prueft App-Start, nicht DB-Auth-
+Erfolg. Bei falschem `PAPERLESS_DBPASS`-Stack-ENV startet Paperless
+moeglicherweise mit Error-Log und ist via Traefik nicht antwortend - aber
+das fehlt als Pruefpunkt.
+
+Vorschlag: Phase 5.3 ergaenzen: "Pro App: `docker logs <app>` zeigt keine
+`password authentication failed`/`FATAL: role does not exist`-Eintraege."
+
+## Uebergreifende Findings
+
+### X-1 (HIGH) - Nextcloud-Restore-Skript existiert, ist aber ungetestet
+
+`ops/restore-tests/nextcloud-restore-test.sh` und
+`ops/restore-tests/nextcloud-compose.test.yml` existieren im Repo.
+`docs/RESTORE_MATRIX.md:147` Spalte "Letzter Restore-Test" fuer Nextcloud:
+`-`, naechster Lauf `**hoechste Prio**`. `docs/AUDIT_2026-05-25_TODO.md:18`
+fuehrt es als P1 "offen".
+
+Damit ist der echte Tabletop-Gewinn: der Test ist nicht "noch zu bauen",
+sondern "noch nie ausgefuehrt". Ein `bash /mnt/user/services/homelab-
+infra/ops/restore-tests/nextcloud-restore-test.sh` schliesst die letzte
+Tier-2-Luecke.
+
+## Nicht-Findings
+
+Was ich gepruft und als sauber verifiziert habe:
+
+- Referenzierte Skripte existieren alle: `pre-backup-dumps.sh`,
+  `gitea-bundle-mirror.sh`, `run-restore-checks.sh`,
+  `komodo-bootstrap-test.sh`, `posture-check.sh`, alle Restore-Test-
+  Skripte fuer Tier-1 und Tier-2.
+- Pfadverweise zwischen DR.md, RESTORE_MATRIX.md, SECRETS_MAP.md,
+  SERVICES_RECOVERY.md sind konsistent (Borg-Dumps unter `/mnt/user/
+  backups/borg/dumps/latest`, Secrets unter `/mnt/user/appdata/secrets`).
+- Drift-Erkennung Authelia (`services/authelia-diff.sh`) ist in
+  `posture-check` integriert (`WORKFLOW.md:292`).
+- GitHub-Mirror-Pfad und Gitea-Bundle-Mirror als Repo-Bootstrap-Quellen
+  sind dreifach abgesichert (lokaler Clone, GitHub, Bundle).
+- Tier-1-Postgres-Restore-Drill ist 2026-06-03 erfolgreich gelaufen
+  (`AUDIT_2026-05-25_TODO.md:19`).
+- `ops/komodo/docker-compose.yml` ist als Recovery-Anker getestet
+  (`SERVICES_RECOVERY.md:142-166`).
+- Borg-Passphrase und Hetzner-Account-Hygiene sind Operator-bestaetigt
+  (`AUDIT_2026-05-25_TODO.md:46-47`).
+
+## Vorschlag fuer Reihenfolge der Folge-Arbeit
+
+1. **CRITICAL P1-1 zuerst** - Operator-Laptop-Voraussetzung als
+   DR-Pflichtposten dokumentieren. Eine Dokuzeile.
+2. **HIGH P0-2 + P3-3** - klaeren, ob GitHub-Mirror lesend public ist und
+   wo der Hetzner-Maintenance-Key offline liegt. Zwei Dokuzeilen oder
+   eine echte Setup-Entscheidung.
+3. **HIGH P2-1** - Operator-Bestaetigung "KOMODO_*-Notiz offline
+   gesichert YYYY-MM-DD" in `EXTERNAL_DEPENDENCIES.md` ergaenzen (sobald
+   real angelegt).
+4. **HIGH P4-1 + P4-2** - Vorlauf "Stufe 0 - Docker-Grundlage" und
+   LE-Staging-Hinweis in DR.md Phase 4 einfuegen. Etwa 10 Zeilen Doku.
+5. **HIGH X-1** - `nextcloud-restore-test.sh` einmal scharf ausfuehren.
+   Vermutlich ein Vormittag inklusive Report-Review.
+6. **HIGH P2-2 + P4-8** - Reihenfolgen-Konsistenz Komodo/Vaultwarden in
+   DR.md eindeutig aufloesen.
+7. Rest in der Reihenfolge der Tabelle.
+
+Punkte 1-4 sind reine Doku-Arbeit, keine Compose-/Runtime-Aenderung.
+Punkt 5 ist ein echter Restore-Lauf mit Report. Punkt 6 ist die
+substanziellste Doku-Aenderung in DR.md.
+
+## Folge-Iteration 2026-06-03 (Doku-Fixes im selben Aenderungsblock)
+
+Direkt nach dem Drill und nach Operator-Antworten auf vier offene Fragen wurden folgende Findings im Repo adressiert. Operator-Aufgaben, die ich nicht selbst tun kann, sind als P1 in `docs/AUDIT_2026-05-25_TODO.md` aufgenommen.
+
+| ID | Massnahme |
+|---|---|
+| P0-1 | DR.md Phase 0 ergaenzt um "Operativer Pfad fuer den Repo auf den frisch installierten Unraid-Host" (USB/SMB/rsync); DR.md Abschnitt 3 mit Zeile "Operator-DR-Workstation"; `EXTERNAL_DEPENDENCIES.md` neuer Abschnitt "DR-Workstation Bare-Metal-Kit" |
+| P0-2 | `EXTERNAL_DEPENDENCIES.md` GitHub-Mirror-Zeile praezisiert (privat, Read-PAT/Deploy-Key Pflicht); DR.md Phase 0 verweist explizit darauf; offene Operator-Aufgabe in Audit-Restliste |
+| P1-1 | Operator-DR-Workstation als Voraussetzung in DR.md Abschnitt 3 und in `EXTERNAL_DEPENDENCIES.md`; konkrete Pflichtbestandteile (WSL2, Borg, SSH-Key) gelistet |
+| P1-2 | Bleibt offen als P3-Test in Restore-Backlog (kein Doku-Fix moeglich) |
+| P2-1 | KOMODO_*-Notiz als kritische Secret-Zeile in `EXTERNAL_DEPENDENCIES.md` mit Status "noch nicht angelegt"; Operator-Aufgabe in Audit-Restliste |
+| P2-2 | DR.md Phase 4 Stufe 3 ergaenzt um expliziten Hinweis "KOMODO_* aus externer Notiz oder voraus gezogener Vaultwarden" |
+| P2-3 | DR.md Abschnitt 6.1 um `homelab_smtp_password.txt` erweitert |
+| P2-4 | DR.md Abschnitt 6.1 um `n8n_encryption_key.txt` erweitert |
+| P2-5 | DR.md Abschnitt 6.1 um Monitoring-Grafana/InfluxDB-/Filebrowser-Secrets erweitert |
+| P3-1 | DR.md neuer Abschnitt 7.3 "Borg-Extract ohne `borg-ui`-Container" mit DR-Workstation- und Docker-Variante |
+| P3-2 | DR.md Abschnitt 7.3 nennt Passphrase-Eingabe explizit als interaktiven Bootstrap-Schritt |
+| P3-3 | `EXTERNAL_DEPENDENCIES.md` Review-Zeile 2026-06-03: Hetzner-Maintenance-Key auch offline bestaetigt |
+| P4-1 | DR.md Phase 4 neue Stufe 0 "Docker-Grundlage" mit `docker network create` Befehlen |
+| P4-2 | DR.md Phase 4 Stufe 1 LE-Staging-Hinweis bei verlorenem `acme.json` |
+| P4-3 | DR.md Phase 4 Stufe 0 nennt `traefik/dynamic/*` als Pre-Check |
+| P4-4 | Wird mit fresh-Postgres-Initialisierungsskripten ohne Doku-Aenderung nicht sinnvoll abgedeckt; bleibt als Doku-Hinweis offen, ist im realen Restore-Pfad mit `pg_dumpall --globals-only` abgedeckt |
+| P4-5 | LOW, nicht angepasst (Reihenfolge nicht falsch, nur irrefuehrend) |
+| P4-6 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": Mongo-Datadir/Secret-Mismatch und Re-Init-Pfad |
+| P4-7 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": `extra_hosts`-Anpassung bei IP-Wechsel |
+| P4-8 | DR.md Phase 4 Stufe 3 "Wichtige Stolperfallen": Stack-ENV-Wiederherstellung per `mongorestore` oder manuell |
+| P5-1 | LOW, nicht angepasst |
+| P5-2 | DR.md Phase 5.3 um `docker logs`-Verifikation der App-zu-DB-Verbindung erweitert |
+| X-1 | **erledigt 2026-06-03**: Nextcloud-Restore-Test scharf gelaufen, drei Iterationen (zwei Skript-Bugs gefixt), Endresultat SUCCESS mit HTTP 200, occ status ok, 126 DB-Tabellen. Damit ist Tier-2 vollstaendig belegt. |
+
+Nicht angefasst: P1-2 (kein Doku-Fix moeglich), P4-4 (im echten Restore-Pfad ohnehin abgedeckt), P4-5 und P5-1 (LOW). Die offenen Operator-Aufgaben (KOMODO_*-Notiz, Read-PAT, DR-Workstation, Nextcloud-Restore) stehen jetzt in `docs/AUDIT_2026-05-25_TODO.md` als P1.
+
+## Reproduktion dieses Drills
+
+```text
+Methode: kalter Lesetest gegen
+  - docs/DISASTER_RECOVERY.md
+  - docs/RESTORE_MATRIX.md
+  - docs/SECRETS_MAP.md
+  - docs/SERVICES_RECOVERY.md
+  - docs/RESTORE_HANDBOOK.md
+  - docs/EXTERNAL_DEPENDENCIES.md
+  - ops/komodo/docker-compose.yml
+  - traefik/docker-compose.yml
+Verifizierte Skript-Existenz: ops/borg-ui/scripts/*, ops/restore-tests/*,
+  services/posture-check/*
+Kein Container gestartet, kein Skript ausgefuehrt, keine produktiven
+Pfade beruehrt.
+```

docs/DR_WORKSTATION_SETUP.md

@@ -0,0 +1,227 @@
+# DR-Workstation Setup-Runbook
+
+Stand: 2026-06-03
+
+Konkrete Schritte, um den Operator-Gaming-PC als DR-Workstation einzurichten. Der Endzustand ist in `docs/EXTERNAL_DEPENDENCIES.md` Abschnitt "DR-Workstation Bare-Metal-Kit" beschrieben; dieses Dokument ist der Weg dahin.
+
+Vorbedingung: Repo-Clone unter `G:\Gitea_Clone\homelab-infra`, Hetzner-DR-SSH-Key und GitHub-Deploy-Key liegen offline auf USB.
+
+Aufwand: einmalig ~30-60 Min interaktiv.
+
+---
+
+## Schritt 1 - WSL2 + Ubuntu installieren (~15 Min)
+
+PowerShell als **Administrator** oeffnen:
+
+```powershell
+wsl --install -d Ubuntu
+```
+
+- Bei "Virtualization nicht aktiviert"-Fehler: BIOS rein, Intel VT-x / AMD-V einschalten, neu starten, Befehl wiederholen.
+- Nach Install: Ubuntu startet automatisch und fragt nach Username + Passwort. Username egal (z. B. `dr`), Passwort merken (wird fuer `sudo` gebraucht).
+- Reboot kann noetig sein - PowerShell sagt es.
+
+Verifikation in Ubuntu (oeffnet sich automatisch):
+
+```bash
+lsb_release -a
+uname -r
+```
+
+Erwartet: `Ubuntu 24.04 LTS`, Kernel beginnt mit `5.x` oder `6.x` und enthaelt `microsoft-standard-WSL2`.
+
+---
+
+## Schritt 2 - Borg-Client installieren (~3 Min)
+
+In der Ubuntu-Shell:
+
+```bash
+sudo apt update
+sudo apt install -y borgbackup openssh-client
+borg --version
+```
+
+Erwartet: `borg 1.2.x` oder `1.4.x`. Beides reicht fuer das produktive Borg-Repo auf Hetzner.
+
+---
+
+## Schritt 3 - Hetzner-DR-SSH-Key in WSL ablegen (~5 Min)
+
+Wichtig: der Private-Key liegt offline auf USB. Fuer die Workstation-Routine wird er auf das WSL-Filesystem kopiert - **das ist die Arbeitskopie**, nicht die Offline-Sicherung. Wenn die WSL kaputtgeht, kommt der Key zurueck vom USB; das Offline-Original bleibt unangetastet.
+
+USB einstecken. In WSL kopieren (Pfad anpassen je nach Laufwerksbuchstabe):
+
+```bash
+mkdir -p ~/.ssh
+cp /mnt/<USB-Buchstabe>/dr-hetzner-2026-06-03/dr-hetzner ~/.ssh/dr-hetzner
+chmod 600 ~/.ssh/dr-hetzner
+```
+
+`<USB-Buchstabe>` ist meistens `e`, `f` oder `g` - Windows-Laufwerke werden in WSL unter `/mnt/<buchstabe>` gemountet.
+
+Smoke-Test:
+
+```bash
+ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23 \
+    u565255@u565255.your-storagebox.de "ls"
+```
+
+Erwartet: vier Verzeichnisse (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`), exit 0, kein Passwort-Prompt.
+
+---
+
+## Schritt 4 - Borg-Passphrase eingeben und `borg list` testen (~5 Min)
+
+Borg verlangt die Passphrase beim ersten Repo-Zugriff. Die liegt offline gesichert (Operator-Bestaetigung 2026-05-26).
+
+Einmaliger Smoke gegen das wichtige Repo:
+
+```bash
+export BORG_RSH="ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23"
+borg list ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical
+```
+
+Borg fragt nach der Passphrase. Eingeben (sie wird nicht angezeigt, das ist normal).
+
+Erwartet: Liste mit Archiv-Namen, jeder im Stil `Taegliche-Sicherung-YYYY-MM-DDTHH:MM:SS.xxx`. Wenn ja: Borg-Schicht funktioniert.
+
+**Wert wird nirgendwo gespeichert.** `BORG_PASSPHRASE`-Env-Variable wird **nicht** dauerhaft gesetzt; Passphrase wird im Notfall immer interaktiv eingegeben.
+
+---
+
+## Schritt 5 - GitHub-Deploy-Key in WSL ablegen (~3 Min)
+
+Gleiches Muster wie Hetzner-Key:
+
+```bash
+cp /mnt/<USB-Buchstabe>/dr-readonly-2026-06-03/dr-readonly ~/.ssh/dr-readonly
+chmod 600 ~/.ssh/dr-readonly
+```
+
+Smoke-Test gegen den privaten GitHub-Mirror:
+
+```bash
+GIT_SSH_COMMAND="ssh -i ~/.ssh/dr-readonly -o IdentitiesOnly=yes" \
+    git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git | head -3
+```
+
+Erwartet: HEAD und mindestens ein `refs/heads/master`-Eintrag.
+
+---
+
+## Schritt 6 - Quartals-Smoke als Skript ablegen (~5 Min)
+
+Damit der "ich pruefe das vierteljaehrlich"-Schritt zur Routine wird, ein kleines Skript ins WSL-Home:
+
+Stand 2026-06-06: Das Skript liegt zusaetzlich versioniert unter
+`ops/maintenance/dr-workstation-smoke.sh` und wurde auf `baerchen` bereits nach
+`~/dr-smoke.sh` in die Ubuntu-WSL kopiert. Borg 1.2.8 ist installiert, die
+DR-Key-Arbeitskopien liegen unter `~/.ssh/dr-readonly` und
+`~/.ssh/dr-hetzner`, GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich.
+Der finale Borg-Smoke via `bash ~/dr-smoke.sh` wurde am 2026-06-06 ebenfalls
+erfolgreich gefahren (`DR-Smoke OK (2026-06-06 10:05:30)`). Die Borg-Passphrase
+wurde nur interaktiv eingegeben und nicht gespeichert.
+
+```bash
+cat > ~/dr-smoke.sh <<'EOF'
+#!/bin/bash
+# DR-Workstation Quartals-Smoke
+# Pruefen: GitHub-Read, Hetzner-SSH, Borg-Repo-Erreichbarkeit
+# Passphrase wird interaktiv abgefragt - Skript speichert keinen Wert.
+set -e
+echo "=== GitHub Deploy-Key ==="
+GIT_SSH_COMMAND="ssh -i ~/.ssh/dr-readonly -o IdentitiesOnly=yes" \
+    git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git \
+    | head -1
+echo
+echo "=== Hetzner SSH-Login ==="
+ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23 \
+    u565255@u565255.your-storagebox.de "ls" | head -5
+echo
+echo "=== Borg-Repo (Passphrase wird abgefragt) ==="
+export BORG_RSH="ssh -i ~/.ssh/dr-hetzner -o IdentitiesOnly=yes -p 23"
+borg info ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical | head -10
+echo
+echo "DR-Smoke OK ($(date '+%F %T'))"
+EOF
+chmod +x ~/dr-smoke.sh
+```
+
+Aufrufen mit:
+
+```bash
+bash ~/dr-smoke.sh
+```
+
+Termin im Kalender: einmal pro Quartal, ~5 Min Aufwand.
+
+---
+
+## Schritt 7 - Eintrag in EXTERNAL_DEPENDENCIES Review nachziehen
+
+Nach erfolgreicher Einrichtung im Repo dokumentieren. In `docs/EXTERNAL_DEPENDENCIES.md` unter "Review":
+
+```
+| 2026-06-XX | DR-Workstation produktiv: WSL2 Ubuntu auf Gaming-PC, borgbackup installiert, Hetzner-DR-Key und GitHub-Deploy-Key in ~/.ssh, Quartals-Smoke-Skript ~/dr-smoke.sh. Bare-Metal-DR-Pillars sind damit alle vier produktionsreif. | Quartalsweise Smoke laufen lassen |
+```
+
+Audit-Restliste analog: in `docs/AUDIT_2026-05-25_TODO.md` den P1 "DR-Workstation Bare-Metal-Kit: WSL2 + Borg-Client installieren" auf erledigt setzen und unter "Zuletzt geschlossen" einen Eintrag mit Smoke-Ergebnis machen.
+
+Wenn ich (Claude) am Tag der Einrichtung mit SSH-Zugang dabei bin, ziehe ich das nach. Sonst per `git add docs/EXTERNAL_DEPENDENCIES.md docs/AUDIT_2026-05-25_TODO.md && git commit && git push`.
+
+---
+
+## Troubleshooting
+
+### `wsl --install` schlaegt fehl mit "WSL 2 requires an update"
+
+```powershell
+wsl --update
+wsl --shutdown
+wsl --install -d Ubuntu
+```
+
+### Hetzner-SSH fragt nach Passwort statt Key-Login zu akzeptieren
+
+Permissions des Keys pruefen:
+
+```bash
+ls -la ~/.ssh/dr-hetzner
+```
+
+Muss `-rw-------` (also `600`) sein. Wenn anders:
+
+```bash
+chmod 600 ~/.ssh/dr-hetzner
+```
+
+Bei weiterhin Passwort-Prompt: Pubkey-Inhalt gegen das authorized_keys-Format der Storage Box pruefen (sollte `ssh-ed25519 AAAA...` ohne Leerzeilen sein).
+
+### `borg list` haengt oder schlaegt mit "Connection refused" fehl
+
+Port 23 explizit pruefen:
+
+```bash
+nc -vz u565255.your-storagebox.de 23
+```
+
+Wenn das fehlschlaegt: Hetzner-Status-Page pruefen, sonst SSH-Verbindung an sich blockiert (Firewall, ISP).
+
+### GitHub-Pull fragt nach Username/Passwort
+
+Stelle sicher dass die URL `git@github.com:...` ist (SSH), nicht `https://github.com/...`. Bei HTTPS wuerde GitHub Username/PAT verlangen, was wir bewusst nicht eingerichtet haben.
+
+---
+
+## Was nach diesem Runbook gilt
+
+Mit allen Schritten erledigt ist der vierte Bare-Metal-DR-Pillar zu (siehe `docs/EXTERNAL_DEPENDENCIES.md`). Der DR-Workstation-Status ist dann:
+
+- WSL2 Ubuntu installiert
+- borgbackup einsatzbereit
+- SSH-Keys (Hetzner, GitHub) in `~/.ssh/`
+- Quartals-Smoke-Skript laeuft
+
+Damit ist im Bare-Metal-Fall der Pfad "Unraid tot -> Gaming-PC nimmt die DR-Arbeit auf" tatsaechlich gangbar, nicht nur in Doku theoretisch.

docs/EXTERNAL_DEPENDENCIES.md

@@ -1,6 +1,6 @@
 # External Dependencies - KalliLab CORE
 
-Status: Initiale Betreiber-Baseline 2026-05-26; konkrete Account-Recovery-Codes und Besitznachweise muessen ausserhalb des Repos bestaetigt werden.
+Status: Betreiber-Baseline 2026-06-01; Account-Recovery, Schluessel und Besitznachweise bleiben ausserhalb des Repos.
 
 ## Zweck
 
@@ -11,17 +11,19 @@ Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recov
 | Anbieter / System | Zweck | Kritikalitaet | Recovery-Auswirkung | Zugang / Besitz | Notfallplan |
 |---|---|---:|---|---|---|
 | Telekom DSL | Internet-Uplink | hoch | Public Apps, ACME, DDNS, Hetzner-Off-site und Tailscale-Initial-Verbindung fallen aus | Telekom-Kundenkonto | Kein WAN-Failover am Standort eingerichtet (FRITZ!Box-Ausfallschutz inaktiv); lokale LAN-Dienste laufen weiter; Hotspot-Behelf nur fuer Operator-Arbeit, nicht fuer Public Apps |
-| FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig regelmaessig sichern (FRITZ!OS-Backup), Reset-Pin und Account-Pfad bereithalten |
+| FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig-Backup vom 2026-06-01 liegt extern/off-system in Vaultwarden; Reset-Pin und Account-Pfad bereithalten; Remote-HTTPS/FTP/FTPS aus dem Internet sind aus |
 | Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern |
 | Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen |
-| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Zweites Off-site-Ziel oder Cold-Platte etablieren; Borg-Passphrase extern sichern |
+| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `append-only` wird per Operator-Entscheidung nicht umgesetzt |
-| GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` | mittel/hoch | Gitea-Verlust abfederbar, Repo-Bootstrap bleibt moeglich | GitHub-Konto; PAT liegt in Gitea-Mirror-Settings, nicht im Repo | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten |
+| GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` (privat) | mittel/hoch | Gitea-Verlust abfederbar, aber Bare-Metal-Bootstrap braucht Read-Zugang (PAT oder SSH-Deploy-Key); ohne diesen ist der Mirror im DR nicht klonbar | GitHub-Konto; Push-PAT liegt in Gitea-Mirror-Settings; **Read-PAT/Deploy-Key fuer DR muss zusaetzlich offline im DR-Kit liegen** | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten; Read-PAT mit Scope `repo:read` separat erzeugen und im DR-Kit ablegen |
 | Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern |
-| GMX SMTP | Authelia Notifier | mittel | Mail-Notifier faellt aus, Login selbst nicht zwingend | GMX-Konto; SMTP-Secret liegt hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
+| GMX SMTP | Authelia Notifier, Vaultwarden-Einladungen, Ops-Report-Mail | mittel | Mail-Notifier und Vaultwarden-Einladungen fallen aus; Login selbst nicht zwingend | GMX-Konto; SMTP-Secrets liegen hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
+| OpenAI API | Paperless-GPT LLM und Vision-OCR | mittel | Automatische Dokument-Titel, Tags, Korrespondenten und LLM-OCR fallen aus; Paperless selbst laeuft weiter | OpenAI-Projekt/API-Key ausserhalb Repo | Key in Vaultwarden/Komodo sichern, bei Offenlegung rotieren; Kosten/Usage im OpenAI-Projekt beobachten |
 | Let's Encrypt | TLS-Zertifikate | hoch | Cert-Erneuerung faellt aus | automatisch via Traefik und Cloudflare DNS-Challenge | Cert-Expiry Alert einrichten; Cloudflare-Token und Traefik-Storage pruefen |
 | Container Registries | Image Pulls von Docker Hub, GHCR, LSCR, Gitea Registry u. a. | mittel | Redeploy/Update blockiert | ueberwiegend oeffentlich; keine produktiven Registry-Tokens im Repo | Gepinnte Digests und lokale Runtime helfen kurzfristig; Updates geplant und einzeln deployen |
-| Plex Konto/Remote Access | Plex native Auth, ggf. Remote Access und Claim | mittel | Plex-Clients/Remote-Funktionen koennen ausfallen | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | LAN-Medienpfade bleiben lokal; Konto-Recovery separat sichern |
+| Plex Konto | Plex native Auth, Claim und Client-Zugriff ueber `plex.kaleschke.info` | mittel | Plex-Web/App-Login und Clients koennen ausfallen; LAN-Medienpfade bleiben lokal | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | Plex Remote Access bleibt aus; externer Zugriff laeuft ueber Traefik/443. Konto-Recovery separat sichern |
 | Mobile Push | ntfy und ggf. mobile Plattform-Pushes | niedrig/mittel | Alerts erreichen Mobilgeraete ggf. nicht | App-/Device-seitig | Kritische Alerts zusaetzlich in Grafana/Glance sichtbar halten |
+| Operator-DR-Workstation | Bare-Metal-Recovery-Arbeitsplatz (Gaming-PC Windows, lokaler Repo-Clone `G:\Gitea_Clone\homelab-infra`) | kritisch | Ohne Workstation kein Borg-Extract, kein Hetzner-Zugriff, kein Repo-Bootstrap; der Unraid-Host ist im Bare-Metal-Fall gerade weg | Operator-PC, WSL2 + Borg-Client, SSH-Key fuer Hetzner Storage Box, Offline-Kopie der Borg-Passphrase | Setup als bewusste DR-Vorbedingung pflegen (siehe Abschnitt "DR-Workstation Bare-Metal-Kit") |
 
 ## Kritische Secrets ausserhalb des Repos
 
@@ -33,9 +35,28 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 | Cloudflare DNS API Token | ACME DNS-Challenge | Token-Rotation und Scope pruefen |
 | GitHub Mirror Token | Push-Mirror | In Gitea/GitHub verwaltet, nicht im Repo |
 | Tailscale Account Recovery | Tailnet-Zugang | Account-2FA/Recovery Codes sichern |
-| SMTP Passwort | Authelia Mail | In Host-Secret, Fallback pruefen |
+| SMTP Passwort | Authelia Mail, Vaultwarden-Einladungen, Ops-Report-Mail | In Host-Secrets, Fallback pruefen |
 | Domain-Registrar Recovery | Domain-Besitz und Zahlung | Account, 2FA und Zahlungsweg ausserhalb des Homelabs sichern |
-| Hetzner Storage Box Zugang | Off-site Backup-Ziel | SSH-/Web-Zugang und Zahlungsweg extern sichern |
+| Hetzner Storage Box Zugang | Off-site Backup-Ziel | Account 2FA aktiv, Recovery Key offline gedruckt, Zahlungsweg ok; Maintenance-Key und Storage-Box-Passwort in Vaultwarden |
+| OpenAI API Key | Paperless-GPT GPT-Zugriff | Als Stack ENV / Vaultwarden-Eintrag sichern; bei Verdacht auf Leak rotieren |
+| KOMODO_* Stack-ENV-Notiz | Offline-Sicherung der 5 Komodo-Werte (`KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY`) | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)**. Quelle der Werte ist die host-seitige Self-Stack-`.env` (`/mnt/user/services/stacks/komodo/.env`) bzw. die Drift-Recovery-Kopie unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env`. Nicht im Repo, nicht in ntfy, nicht in Logs |
+| GitHub-Mirror Read-Only Deploy-Key | DR-Read-Zugang zum privaten Mirror `michaelkaleschke-spec/homelab-infra` | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung).** SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei), Title in GitHub Repo Settings -> Deploy Keys: `DR Read-Only 2026-06-03`, Write-Access bewusst deaktiviert. Private Key liegt offline neben der KOMODO_*-Notiz. Smoke `git ls-remote` am 2026-06-03 erfolgreich. |
+
+## DR-Workstation Bare-Metal-Kit
+
+Der Operator-Gaming-PC ist im Bare-Metal-Fall die einzige Stelle, von der aus Recovery starten kann. Folgende Bestandteile gehoeren zum minimalen DR-Kit auf diesem Rechner:
+
+| Bestandteil | Zweck | Pruefen |
+|---|---|---|
+| Repo-Clone `G:\Gitea_Clone\homelab-infra` (master, gefetcht) | Recovery-Anker fuer `ops/komodo/docker-compose.yml`, Restore-Skripte | `git -C G:\Gitea_Clone\homelab-infra log --oneline -1` plausibel aktuell |
+| Read-Zugang zum privaten GitHub-Mirror | Fallback, falls lokaler Clone defekt | SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei) offline im DR-Kit, ein Test-Clone pro Quartal mit `GIT_SSH_COMMAND="ssh -i <pfad-zum-key> -o IdentitiesOnly=yes" git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git` |
+| WSL2 mit Borg-Client (`apt install borgbackup`) | Borg-Extract von Hetzner Storage Box ohne laufenden Unraid-Host | `borg --version` antwortet; ein `borg list` gegen Hetzner-Repo laeuft |
+| SSH-Key fuer Hetzner Storage Box | Login auf `u565255.your-storagebox.de:23` | **Status 2026-06-03: ed25519-DR-Key `dr-hetzner-2026-06-03` offline gesichert.** Pubkey via `install-ssh-key` auf der Storage Box autorisiert, passwortloser Login erfolgreich, `ls` zeigt vier Borg-Repos (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`). Private Key liegt offline neben KOMODO_*-Notiz und GitHub-Deploy-Key |
+| Offline-Kopie Borg-Passphrase | Entschluesselung des Borg-Repos | Operator-Bestaetigung 2026-05-26; bei Reviews nur Auffindbarkeit pruefen |
+| Offline-Kopie KOMODO_* Stack-ENV | Komodo-Bootstrap ohne Vaultwarden | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)** |
+| Vaultwarden Master-Passwort offline | Zugriff auf Vaultwarden-Export im DR | Operator-Wissen, ggf. analog gesichert |
+
+Operative Regel: Die DR-Workstation wird nicht als Test-/Spiel-PC betrachtet. WSL und das DR-Kit duerfen nicht unbemerkt unbrauchbar werden. Quartalsweise minimaler Trockenlauf: `borg list <hetzner-repo>` muss antworten und der Repo-Clone muss fetchbar bleiben.
 
 ## Ausfall-Szenarien
 
@@ -43,7 +64,8 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 
 - Lokales Borg-Repo und aktuelle Dumps pruefen.
 - Keine destruktiven Host-Aenderungen starten, solange Off-site unklar ist.
-- Zweites Off-site-Ziel oder Cold-Platte als Folgeaufgabe umsetzen.
+- H:/ Nearline-Pull als schnelle lokale Zweitkopie fuer kritische Restore-Artefakte nutzen.
+- Zweites Off-site-Ziel nur neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz.
 
 ### Cloudflare Account/DNS gestoert
 
@@ -63,7 +85,7 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 - Lokale LAN-Apps (Plex, AdGuard-DNS, lokales Borg-Dump-Repository) bleiben verfuegbar, solange Host und Switch laufen.
 - Tailscale-Sessions, die bereits stehen, koennen ueber DERP/Relays kurzzeitig weiterlaufen; neue Verbindungen koennen ausfallen.
 - ACME-/DDNS-/Hetzner-Backup-Laeufe pausieren bis WAN zurueck ist.
-- FRITZ!OS 8.21 Update wird bewusst nur in einem geplanten Service-Fenster eingespielt, weil Reboot WAN/Tailscale-Aufbau unterbricht.
+- FRITZ!OS ist am 2026-06-01 auf 8.25 (`154.08.25`) beobachtet; weitere Updates nur in einem geplanten Service-Fenster einspielen, weil Reboot WAN/Tailscale-Aufbau unterbricht.
 
 ### Domain verloren oder Registrar-Zugriff verloren
 
@@ -75,5 +97,14 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 | Datum | Ergebnis | Naechste Aktion |
 |---|---|---|
 | 2026-05-26 | Bekannte externe Abhaengigkeiten aus Repo-/Betriebsdoku dokumentiert; keine Secret-Werte aufgenommen. Borg-Passphrase ist laut Operator offline gesichert. | Account-Besitz, 2FA-Recovery-Codes und Zahlungswege extern bestaetigen |
-| 2026-05-26 | Telekom-DSL und FRITZ!Box 7590 (FRITZ!OS 8.21) als WAN-/Router-Abhaengigkeit aufgenommen; Ausfallschutz nicht eingerichtet; 2 Portfreigaben aktiv (Soll: 443/tcp + 222/tcp) | FRITZ!OS-Update im Service-Fenster pruefen; Portfreigaben-UI gegen Repo-Soll abgleichen |
+| 2026-05-26 | Telekom-DSL und FRITZ!Box 7590 (damals FRITZ!OS 8.21) als WAN-/Router-Abhaengigkeit aufgenommen; Ausfallschutz nicht eingerichtet | FRITZ!OS-Update am 2026-06-01 als `154.08.25` beobachtet |
-| 2026-05-27 | FRITZ!Box-Portfreigaben-UI abgeglichen: aktiv sind `80/tcp` und `443/tcp` auf Kallilabcore; `222/tcp` fehlt gegen Repo-Soll. Keine Router-Aenderung vorgenommen. | Nach Operator-Freigabe `80/tcp` entfernen und `222/tcp` nur anlegen, wenn externes Gitea-SSH weiter gewuenscht ist |
+| 2026-05-28 | FRITZ!Box-Portfreigaben bereinigt: aktiv bleibt nur `443/tcp`; `80/tcp` entfernt, `222/tcp` bewusst nicht angelegt; UPnP-Recht fuer VONETS-Bridge deaktiviert | IPv6-/Dienste-Review am 2026-06-01 nachgezogen |
+| 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Account-Hygiene am 2026-06-01 nachgezogen |
+| 2026-06-01 | FRITZ!Box-UI gegengeprueft und Konfig-Backup extern/off-system in Vaultwarden abgelegt; Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus | Bei naechstem Router-Update erneut exportieren |
+| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. Borg `append-only` wird bewusst nicht umgesetzt. | Keine Folgeaktion |
+| 2026-06-03 | Hetzner Storage Box Maintenance-Key zusaetzlich offline gesichert bestaetigt (Operator-Antwort im DR-Tabletop 2026-06-03). Damit ist der Hetzner-Zugang im Bare-Metal-Fall ohne Vaultwarden moeglich. | Keine Folgeaktion |
+| 2026-06-03 | DR-Tabletop ergibt drei offene Bootstrap-Bloecke: KOMODO_*-Notiz nicht offline, GitHub-Mirror-Read-PAT/Deploy-Key nicht angelegt, DR-Workstation nicht als DR-Kit konfiguriert. Details in `docs/DR_DRILL_2026-06-03.md` und Folge-Tasks in `docs/AUDIT_2026-05-25_TODO.md`. | KOMODO_*-Notiz erzeugen, Read-PAT erzeugen, WSL2+Borg auf Gaming-PC einrichten |
+| 2026-06-03 | KOMODO_*-Notiz offline gesichert (Operator-Bestaetigung im DR-Tabletop-Followup). Quelle bleibt host-seitige `.env` (`/mnt/user/services/stacks/komodo/.env`) bzw. Drift-Recovery-Kopie vom 2026-05-04. Bare-Metal-Komodo-Bootstrap ist damit ohne Vaultwarden moeglich. | Restliche P1-Operator-Aufgaben: GitHub-Read-PAT, DR-Workstation-Setup, Nextcloud-Restore-Test |
+| 2026-06-03 | GitHub-Mirror Read-Only Deploy-Key `DR Read-Only 2026-06-03` (ed25519, Passphrase-frei) erzeugt, in GitHub Repo Settings ohne Write-Access hinterlegt, Smoke `git ls-remote` erfolgreich (`d947c7f` matched master HEAD), Private-Key offline neben KOMODO_*-Notiz abgelegt, Arbeitsplatz-Kopie geloescht. | Restliche P1-Operator-Aufgaben: DR-Workstation-Setup, Nextcloud-Restore-Test |
+| 2026-06-03 | Hetzner Storage Box DR-SSH-Key `dr-hetzner-2026-06-03` (ed25519, Passphrase-frei) erzeugt, via `install-ssh-key` auf Storage Box `u565255.your-storagebox.de:23` autorisiert, passwortloser Login erfolgreich (Borg-Repos sichtbar), Private-Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key abgelegt, Arbeitsplatz-Kopie geloescht. Bare-Metal-Borg-Restore von der DR-Workstation ist damit moeglich, sobald WSL2 + Borg-Client installiert sind. | Restliche P1-Operator-Aufgaben: WSL2 + Borg-Client auf DR-Workstation installieren, Nextcloud-Restore-Test |
+| 2026-06-06 | DR-Workstation produktiv: WSL2 Ubuntu 24.04 vorhanden, SSH/Git und Borg 1.2.8 in WSL vorhanden, DR-Key-Arbeitskopien unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`, GitHub-Read-Smoke und Hetzner-SSH-Smoke erfolgreich, `ops/maintenance/dr-workstation-smoke.sh` nach `~/dr-smoke.sh` kopiert. Finaler Operator-Smoke erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar, Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. | Quartalsweise `bash ~/dr-smoke.sh`; Borg-Passphrase weiterhin nur interaktiv eingeben und nicht speichern |

docs/EXTERNAL_OPERATOR_RUNBOOK.md

@@ -0,0 +1,143 @@
+# External Operator Runbook
+
+Stand: 2026-06-01
+
+Dieses Runbook schliesst die Betreiber-Aufgaben, die nicht vollstaendig aus dem
+Repo automatisierbar sind: Hetzner-Account-Hygiene, Borg-Append-Only und
+FRITZ!Box-Servicefenster. Keine Secret-Werte ins Repo schreiben.
+
+## 1. Vorher pruefen
+
+Auf dem Unraid-Host:
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/maintenance/check-external-operator.sh
+```
+
+Erwarteter Stand vom 2026-06-01:
+
+- FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`.
+- FRITZ!Box IPv6-Firewall meldet `FirewallEnabled=1`; `InboundPinholeAllowed=1` bedeutet, dass IPv6-Freigaben technisch moeglich sind und in der UI gegengeprueft werden muessen.
+- Public DNS fuer `*.kaleschke.info` liefert A-Records auf `217.249.115.154`, keine AAAA-Records.
+- Host hat keine globale Provider-IPv6-Adresse; sichtbar ist nur Tailscale-IPv6 `fd7a:115c:a1e0::2c01:62b2`.
+- WAN-Smoke gegen die Public-IP: `443/tcp` offen, `80/tcp` und `222/tcp` geschlossen.
+- FRITZ!Box-UI-Gegencheck vom 2026-06-01: Remote-HTTPS auf die FRITZ!Box ist aus, FTP/FTPS auf Speichermedien ist aus, nur `443/tcp -> 192.168.178.58` ist als WAN-Freigabe sichtbar, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
+- FRITZ!Box-Konfig-Backup vom 2026-06-01 ist extern/off-system in Vaultwarden abgelegt; Datei und Kennwort nicht ins Repo schreiben.
+- Borg UI nutzt `borg 1.4.x`; Repository `appdata-critical` liegt auf Hetzner Storage Box `ssh://...your-storagebox.de:23/./hetzner_borg_appdata_critical`.
+- Hetzner-Account-Hygiene vom 2026-06-01: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok.
+- Storage Box vom 2026-06-01: SSH aktiv, SMB/WebDAV aus, separater Maintenance-Key in Vaultwarden, produktiver Borg-UI-Key und Maintenance-Key nach Passwort-Recovery getestet.
+- Restore-Freshness: `Critical 0`, `Warnings 0`.
+
+## 2. Hetzner Account-Hygiene
+
+Im Hetzner-/Storage-Box-Konto pruefen und extern/off-system dokumentieren:
+
+| Punkt | Soll |
+|---|---|
+| Passwort | stark, eindeutig, im Passwortmanager |
+| 2FA | aktiv, Recovery Key offline auffindbar |
+| Kontakt-E-Mail | aktuell und ohne Homelab-Abhaengigkeit erreichbar |
+| Zahlungsweg | gueltig, Fallback bekannt |
+| Storage Box | Produkt, Benutzer und Rechnungsstatus sichtbar |
+| SSH/SFTP/WebDAV/SMB | nur benoetigte Protokolle aktiv |
+| Recovery | Kundennummer, Login-Pfad und Support-Pfad extern notiert |
+
+Im Repo nur das Datum der Bestaetigung dokumentieren, nie Zugangsdaten.
+
+## 3. Borg Append-Only
+
+Status: **bewusst nicht umgesetzt**.
+
+Ziel der Haertung waere gewesen: Der produktive Backup-Client darf neue Archive
+schreiben, aber nicht normal prune/delete/compact als unbeschraenkter Client
+ausfuehren.
+
+Hetzner dokumentiert Borg-Zugriff auf Storage Boxen inklusive `--remote-path`
+fuer Borg-Versionen; fuer Borg 1.4 wird `--remote-path=borg-1.4` empfohlen.
+Hetzner bestaetigt auch, dass append-only moeglich ist. Borg selbst setzt
+append-only pro SSH-Key typischerweise ueber einen forced command in
+`authorized_keys` um.
+
+Getestetes Zielmodell, aber **nicht auf der produktiven Storage Box aktiv**:
+
+```text
+command="borg-1.4 serve --append-only --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 <backup-public-key> borg-ui-append-only
+ssh-ed25519 <maintenance-public-key> borg-maintenance
+```
+
+Hinweise:
+
+- Stand 2026-06-01: Ein forced-command-Versuch auf der produktiven
+  Storage-Box-`authorized_keys` brach die Key-Authentifizierung. Recovery
+  erfolgte per Storage-Box-Passwort und Upload einer bereinigten
+  `authorized_keys` mit Borg-UI-Key und Maintenance-Key.
+- Operator-Entscheidung 2026-06-01: Append-only wird fuer dieses Homelab nicht
+  umgesetzt. Der zusaetzliche Schutz steht hier nicht im Verhaeltnis zum
+  Betriebsrisiko und zur Komplexitaet.
+- Pfad auf der Storage Box vor dem Eintragen pruefen. Bei Hetzner werden Pfade
+  im Borg-Repo haeufig relativ als `./repo-name` verwendet; in
+  `authorized_keys` muss der serverseitige Pfad zur Storage-Box-Home-Struktur
+  passen.
+- Der produktive Borg-UI-Key bleibt bewusst uneingeschraenkt, damit die
+  produktiven Backups laufen.
+- Ein separater Maintenance-Key bleibt fuer bewusste Retention/Prune/Compact
+  noetig und liegt in Vaultwarden; lokale temporare Key-Dateien wurden geloescht.
+- Append-only verhindert nicht, dass ein kompromittierter Client Archive als
+  geloescht markiert; es verhindert die unmittelbare physische Entfernung.
+  Nach einem Vorfall keine unbeschraenkte Schreiboperation ausfuehren, bevor
+  die Borg-Transaktionen bewertet wurden.
+
+Nach Aenderung:
+
+1. Einen regulaeren Borg-Lauf abwarten oder manuell starten.
+2. `check-external-operator.sh` ausfuehren.
+3. In `docs/AUDIT_2026-05-25_TODO.md` nur das Ergebnis dokumentieren.
+
+## 4. FRITZ!Box-Servicefenster
+
+Vor dem Fenster:
+
+1. Familie informieren: Internet/Telefonie koennen kurz weg sein.
+2. Aktuellen Repo-Stand und Borg-Freshness pruefen.
+3. FRITZ!Box-Konfig exportieren: `System -> Sicherung -> Sichern`.
+4. Sicherungsdatei nicht ins Repo legen; im Passwortmanager/off-system ablegen.
+
+In der FRITZ!Box:
+
+| Bereich | Soll |
+|---|---|
+| `System -> Update` | FRITZ!OS aktuell; am 2026-06-01 per TR-064 `154.08.25` beobachtet |
+| `Internet -> Freigaben -> Portfreigaben` | nur `443/tcp -> 192.168.178.58:443` |
+| `Internet -> Freigaben -> FRITZ!Box-Dienste` | Remote-HTTPS auf FRITZ!Box-UI aus; FTP/FTPS auf Speichermedien aus |
+| IPv6-Portfreigaben | keine aktiven Freigaben; insbesondere kein `222/tcp`, kein Admin-Port |
+| Selbststaendige Portfreigaben/UPnP | fuer `Kallilabcore` aus; neue Geraete nur bewusst erlauben |
+| Gastnetz | bleibt aus, solange keine Gastnetz-Policy gepflegt wird |
+| Ausfallschutz | bewusst aus; nur neu bewerten, wenn ein Mobilfunk-Fallback gewuenscht ist |
+
+Nach dem Fenster:
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/maintenance/check-external-operator.sh
+```
+
+Dann in `docs/NETWORK_INVENTORY.md` aktualisieren:
+
+- FRITZ!OS-Version
+- IPv6-Status
+- aktive Portfreigaben
+- FRITZ!Box-Dienste aus dem Internet
+- Datum der Konfig-Sicherung
+
+## Quellen
+
+- Hetzner Docs: Storage Box Zugriff mit SSH/rsync/BorgBackup, inklusive
+  Borg-Versionen, `--remote-path` und Append-Only-Hinweis:
+  <https://docs.hetzner.com/storage/storage-box/access/access-ssh-rsync-borg/>
+- BorgBackup Docs: `borg serve --append-only` und forced commands in
+  `authorized_keys`:
+  <https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html>
+- AVM FRITZ!Box Hilfe: IPv6-Portfreigaben werden separat verwaltet; eingehende
+  Zugriffe sind standardmaessig nicht offen:
+  <https://help.avm.de/fritzbox.php?hardware=145&language=en&oem=avme&set=009&topic=hilfe_internet_freigabe_ipv6>
+- AVM FRITZ!Box Hilfe: Sicherung der FRITZ!Box-Einstellungen:
+  <https://help.avm.de/fritzbox.php?hardware=145&language=en&oem=avme&set=009&topic=hilfe_system_export>

docs/FAMILY_ONBOARDING.md

@@ -1,6 +1,6 @@
 # Familien-Willkommen - KalliLab CORE
 
-Status: **Final-Stand vor Wochenend-Einladung** (2026-05-27). Zielgruppe: Familie. Kein Technik-Wortschatz noetig.
+Status: **Praxis-Onboarding** (2026-06-01). Zielgruppe: Familie. Kein Technik-Wortschatz noetig.
 
 Diese Seite richtet sich an alle, die zuhause unsere eigenen Apps nutzen. Du brauchst kein Technikwissen. Wenn etwas unklar ist: einfach Michi fragen.
 
@@ -25,12 +25,44 @@ Nachteile, ehrlich gesagt: Wenn der Server zuhause aus ist, sind die Apps weg, b
 | **Vaultwarden** | Passwoerter sicher speichern und auf jedem Geraet nachschauen | Bitwarden-App (kostenlos), beim ersten Start Server-URL auf `vault.kaleschke.info` aendern lassen |
 | **Mealie** | Rezepte sammeln, Wochenplan, Einkaufsliste | Web `mealie.kaleschke.info` oder Mealie-App |
 | **Paperless** | Briefe und wichtige Dokumente scannen, durchsuchen, ablegen | Web `paperless.kaleschke.info`; Scan-Workflow erklaert Michi |
-| **Plex** | Filme und Musik auf Fernseher, Handy und Tablet | Plex-App auf dem Geraet, mit Konto anmelden |
+| **Plex** | Filme und Musik auf Fernseher, Handy und Tablet | Web `https://plex.kaleschke.info` oder Plex-App auf dem Geraet, mit Konto anmelden |
 
 > Wenn du eine App auf dem Handy installierst und sie fragt nach einer Server-URL, ist das immer eine `...kaleschke.info`-Adresse. Wenn du dir nicht sicher bist, frag bevor du etwas eintippst.
 
 ---
 
+## Unser erster gemeinsamer Ablauf
+
+Wir richten nicht alles auf einmal perfekt ein. Wichtig ist, dass drei Dinge
+wirklich benutzt werden:
+
+1. **Vaultwarden**: Passwoerter landen dort, nicht im Browser.
+2. **Immich**: Handy-Fotos werden automatisch gesichert.
+3. **Mealie**: Rezepte und Einkaufsliste werden gemeinsam ausprobiert.
+
+Wenn diese drei Dinge laufen, ist das Familien-Onboarding praktisch erfolgreich.
+
+## Vaultwarden zuerst
+
+Vaultwarden ist die Grundlage fuer alle anderen Logins.
+
+1. App **Bitwarden Passwortmanager** auf Handy und ggf. PC installieren.
+2. Beim ersten Start die Server-URL auf `https://vault.kaleschke.info` setzen.
+3. Mit dem persoenlichen Konto anmelden.
+4. Master-Passwort gemeinsam festlegen und merken. Das Master-Passwort wird
+   nicht bei Michi gespeichert.
+5. Browser-Passwortspeicher fuer neue Homelab-Passwoerter nicht verwenden.
+6. Test: Einen neuen Eintrag "Test KalliLab" anlegen und wiederfinden.
+
+Was in Vaultwarden gehoert:
+
+- Homelab-App-Passwoerter
+- wichtige Familien-Logins
+- Recovery-Codes, wenn eine App welche zeigt
+- keine losen Passwort-Zettel und keine Screenshots von Passwoertern
+
+---
+
 ## Wie du dich anmeldest
 
 Beim ersten Mal bekommst du von Michi:
@@ -57,13 +89,40 @@ Das ist die App, die deinen Eltern wahrscheinlich am meisten bringt.
 1. App **Immich** im App-Store / Play Store installieren.
 2. Beim ersten Start nach Server fragen lassen: `https://immich.kaleschke.info`.
 3. Mit deinem Login anmelden.
-4. In den App-Einstellungen "Hintergrund-Backup" aktivieren — am besten nur ueber WLAN.
+4. In den App-Einstellungen "Hintergrund-Backup" aktivieren - am besten nur
-5. Fertig. Neue Fotos landen automatisch zuhause auf dem Server.
+   ueber WLAN.
+5. Das richtige Album / die normale Kamera-Galerie auswaehlen.
+6. App einmal offen lassen, bis erste Fotos hochgeladen wurden.
+7. Test: In der Weboberflaeche `https://immich.kaleschke.info` pruefen, ob die
+   ersten Fotos sichtbar sind.
+8. Fertig. Neue Fotos landen automatisch zuhause auf dem Server.
 
 > Wenn dein Handy 4 Wochen nicht im Haus-WLAN war, sind die Fotos noch in der Handy-Galerie, aber noch nicht zuhause. Sobald du wieder im WLAN bist und die App startest, holt sie alles nach.
 
 ---
 
+## Rezepte und Einkaufsliste einrichten (Mealie)
+
+Mealie soll nicht nur "auch da" sein, sondern wirklich genutzt werden.
+
+1. `https://mealie.kaleschke.info` oeffnen.
+2. Mit dem persoenlichen Konto anmelden.
+3. Gemeinsam ein erstes echtes Rezept anlegen oder importieren.
+4. Rezept mindestens einer Kategorie geben, z. B. `Alltag`, `Schnell`,
+   `Wochenende`, `Vegetarisch`.
+5. Aus dem Rezept Zutaten auf die Einkaufsliste setzen.
+6. Test: Einkaufsliste auf dem Handy oeffnen und einen Eintrag abhaken.
+7. Optional: Einen Wochenplan fuer die naechsten 2-3 Tage anlegen.
+
+Start-Regeln fuer Mealie:
+
+- Rezepte nur dann speichern, wenn wir sie wirklich kochen wuerden.
+- Namen schlicht halten: `Chili`, `Bolognese`, `Kartoffelsuppe`.
+- Zutaten so eintragen, dass sie beim Einkaufen verstaendlich sind.
+- Wenn ein Rezept nicht schmeckt: loeschen oder klar als "nicht wieder" markieren.
+
+---
+
 ## Was tun, wenn etwas nicht geht
 
 ### "Die Webseite oeffnet nicht."
@@ -134,18 +193,66 @@ Michi laesst es dich wissen, wenn ein Wartungsfenster geplant ist.
 
 ---
 
-## Offene Inhalte (Operator-Notiz)
+## Erster Onboarding-Termin - Ablauf fuer Michi
 
-Diese Punkte gehoeren in das Wochenend-Onboarding-Gespraech und sind nicht Teil dieser Familien-Seite:
+Diese Sektion ist die konkrete Checkliste fuer den **ersten echten
+Familien-Onboarding-Termin**. Sie ist als ein zusammenhaengender Termin von
+ca. 30-45 Minuten pro Person gedacht. Keine Secret-Werte in diese Datei
+schreiben.
 
-| Status | Aufgabe |
+> Operator-Eingabe vor dem Termin: festlegen, **wer** beim ersten Termin dabei
-|---|---|
+> ist und **welche Geraete** real vorliegen. Die Checkliste funktioniert pro
-| offen | Pro Familien-Konto Benutzernamen und Start-Passwort persoenlich uebergeben (Vaultwarden Familien-Organisation als Uebergabeweg) |
+> Person identisch.
-| offen | 2FA-App-Empfehlung pro Person festlegen (zum Beispiel Bitwarden Authenticator, Aegis, 2FAS) |
+
-| offen | Vaultwarden Familien-Organisation einrichten und Mitglieder einladen |
+### Vorher bereitlegen (Operator-Vorbereitung)
-| offen | Immich Mobile Backup mit jedem Familien-Geraet einmal gemeinsam ausprobieren |
+
-| offen | Scan-/Inbox-Anleitung fuer Paperless ergaenzen, sobald der Workflow final ist |
+Diese Dinge muessen **vor** dem Termin fertig sein, sonst stockt der Ablauf:
-| offen | Einladungstermin Wochenende mit konkretem Datum festlegen |
+
+- [ ] Pro Teilnehmer ist in **Vaultwarden** ein Benutzerkonto angelegt (Benutzername = Vorname klein).
+- [ ] Pro Teilnehmer ist in **Immich** ein Benutzerkonto angelegt.
+- [ ] Pro Teilnehmer ist in **Mealie** ein Benutzerkonto angelegt.
+- [ ] Start-Passwoerter sind erzeugt und liegen so bereit, dass sie persoenlich uebergeben werden koennen (nicht per Chat, nicht in diese Datei).
+- [ ] Die Apps `cloud`, `immich`, `vault`, `mealie` sind erreichbar (kurzer eigener Smoke-Test ueber `https://...kaleschke.info`).
+- [ ] Das Familien-Handy/Geraet jedes Teilnehmers ist da, entsperrt und im **Haus-WLAN**.
+- [ ] App-Store-/Play-Store-Login auf dem Geraet funktioniert (zum Installieren der Apps).
+
+### Reihenfolge beim Termin (pro Person)
+
+Die Reihenfolge ist bewusst gewaehlt: erst der Passwort-Speicher, dann das, was
+am meisten bringt (Fotos), dann das Gemeinsame (Rezepte).
+
+1. **Konto-Uebergabe**: Benutzername + Start-Passwort persoenlich uebergeben, Person aendert das Passwort beim ersten Login.
+2. **Vaultwarden / Bitwarden** (Abschnitt "Vaultwarden zuerst"):
+   - Bitwarden-App installieren, Server-URL `https://vault.kaleschke.info` setzen, anmelden.
+   - Master-Passwort gemeinsam festlegen (wird **nicht** bei Michi gespeichert).
+   - Testeintrag "Test KalliLab" anlegen und wiederfinden.
+3. **Immich** (Abschnitt "Foto-Backup vom Handy einrichten"):
+   - Immich-App installieren, Server `https://immich.kaleschke.info`, anmelden.
+   - Hintergrund-Backup nur ueber WLAN aktivieren, Kamera-Album auswaehlen.
+   - App offen lassen, bis erste Fotos hochgeladen sind; in der Weboberflaeche sichtbar pruefen.
+4. **Mealie** (Abschnitt "Rezepte und Einkaufsliste einrichten"):
+   - `https://mealie.kaleschke.info` anmelden.
+   - Gemeinsam ein erstes echtes Rezept anlegen, kategorisieren, Zutaten auf die Einkaufsliste setzen.
+   - Einkaufsliste auf dem Handy oeffnen und einen Eintrag abhaken.
+5. **Abschluss**: kurz zeigen, was bei Problemen zu tun ist (Abschnitt "Was tun, wenn etwas nicht geht"), besonders Passwort-vergessen und 2FA-verloren.
+
+### Erfolgskriterium des ersten Termins
+
+Der Termin gilt als erfolgreich, wenn pro Person **diese drei** Dinge real laufen:
+
+- [ ] Vaultwarden ist eingerichtet und ein Testeintrag wurde gefunden.
+- [ ] Immich sichert Handy-Fotos und die ersten Fotos sind in der Weboberflaeche sichtbar.
+- [ ] In Mealie existiert ein erstes Rezept mit einer Einkaufslisten-Position.
+
+### Bewusst spaeter (nicht im ersten Termin)
+
+Damit der erste Termin nicht ueberladen wird, kommen diese Punkte bewusst erst
+in einem Folgetermin:
+
+- **Nextcloud** (Dateien/Kalender/Adressbuch) - erst wenn die drei Kern-Apps sitzen.
+- **Paperless** (Dokumente scannen) - braucht eigenen Scan-Workflow, separater Termin.
+- **Plex** (Filme/Musik) - reines Komfort-Thema, kein Onboarding-Kern.
+- **App-uebergreifendes Einheits-Login (SSO/OIDC)** - nicht eingerichtet, nur als Idee notiert (siehe "Bewusst nicht versprochen").
 
 ## Bewusst nicht versprochen
 

docs/FAMILY_VIEW_DASHBOARD.md

@@ -1,194 +0,0 @@
-# Family-View Dashboard - Spezifikation
-
-Status: **Spezifikation (Doku-only)**, kein Grafana-JSON in diesem Schritt.
-Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-08** (Alerts/Sichtbarkeit) und das Sprint-3-TODO "Family-View Dashboard definieren" aus `docs/AUDIT_2026-05-25_TODO.md`.
-
-## Zweck
-
-Ein Grafana-Dashboard, das beim Morgen-Check in unter 30 Sekunden zeigt, ob das Homelab gesund ist. Zielgruppe ist primaer der Operator. Wenn die Familie es zufaellig anschaut, soll niemand erschrecken: ueberall gruene Felder bedeuten "alles in Ordnung", ohne dass man die Technik dahinter verstehen muss.
-
-Das Dashboard ist die Konsolidierung des morgendlichen Pruefablaufs:
-
-- Sind die wichtigsten Apps erreichbar?
-- Hat das Backup gestern Nacht funktioniert?
-- Wann laufen die Zertifikate aus?
-- Sind die Disks ausreichend frei?
-- Laufen die kritischen Container?
-
-## Abgrenzung
-
-Diese Datei beschreibt nur Layout, Datenquellen und PromQL-Queries. Die JSON-Datei `monitoring/grafana/dashboards/family-view.json` wird **bewusst noch nicht** angelegt, weil:
-
-- Es noch keine Live-Pruefung gegen die echte Grafana-Instanz gab.
-- Die Alert-Regeln (Borg-Stale, Cert-Expiry, Container-Down) sind laut `docs/AUDIT_2026-05-25_TODO.md` Sprint 3 selbst noch im "in Arbeit (Regeln vorbereitet)"-Status.
-- Bei einem halbgaren Dashboard-JSON entstehen mehr Wartungsfragen als Klarheit.
-
-Die JSON-Datei wird angelegt, sobald (a) die genannten Metriken stabil verfuegbar sind und (b) ein erster manueller Build im Grafana-UI das Layout bestaetigt hat.
-
-## Datenquellen
-
-Authoritativ ist `monitoring/grafana/provisioning/datasources/datasources.yml`. Das Dashboard nutzt nur die schon provisionierten Datasources:
-
-- `Prometheus` - Blackbox, node-exporter, cAdvisor, Traefik-Metrics
-- optional `Loki` - Log-Volume-Spike als Zusatz-Panel
-- bewusst nicht: `InfluxDB 3 Core` (das ist Home-Assistant-/Ecowitt-Sicht, nicht Homelab-Health)
-
-## Layout (4x4 Grid, mobile-vertraeglich)
-
-| Zeile | Panel | Breite (Grafana w) | Hoehe (Grafana h) |
-|---|---|---:|---:|
-| 1 | Endpoints up (Stat, gross gruen/rot) | 12 | 5 |
-| 1 | Backup heute Nacht (Stat) | 6 | 5 |
-| 1 | Naechster Cert-Ablauf (Stat, Tage) | 6 | 5 |
-| 2 | Kritische Container running (Stat-Liste) | 12 | 6 |
-| 2 | Disk-Fuellung (Bargraph, je Mountpoint) | 12 | 6 |
-| 3 | Endpoint-Tabelle (Table: Host, Status, Latenz) | 24 | 8 |
-| 4 | Cert-Tage-Tabelle (Table: Host, Tage bis Ablauf) | 12 | 6 |
-| 4 | Container-Status-Tabelle (Table: kritischer Container, Running, letztes Restart) | 12 | 6 |
-
-Dashboard-Metadaten:
-
-- UID: `homelab-family-view`
-- Title: `Homelab / Family View`
-- Tags: `homelab`, `family-view`, `morning-check`
-- Refresh: `30s`
-- Default-Zeitfenster: `now-24h` bis `now`
-- Folder: `Homelab`
-
-## Panel-Spezifikation
-
-### Panel 1: Endpoints up
-
-- Type: `stat`
-- Title: `Apps online`
-- Query: `sum(probe_success{job="blackbox-http"})`
-- Anzeige: gruene Zahl bei Gesamtzahl, Wechsel auf rot wenn `< Soll-Anzahl`.
-- Threshold: Soll-Anzahl wird aus `monitoring/blackbox/blackbox.yml` und Prometheus-Scrape-Liste abgeleitet (zum Doku-Zeitpunkt 19 HTTPS-Ziele laut `docs/MIGRATION_LOG.md` 2026-05-25-Monitoring-Konsolidierung).
-- Subtitel im Panel: `von <N> erreichbar`. (Soll-Wert wird beim Bau aus dem aktuellen Target-Count gesetzt; nicht hartcoden.)
-
-### Panel 2: Backup heute Nacht
-
-- Type: `stat`
-- Title: `Borg-Lauf`
-- Query (sobald Borg-Stale-Metrik im Textfile-Collector live ist):
-  ```promql
-  (time() - homelab_borg_last_completed_timestamp_seconds) / 3600
-  ```
-- Einheit: `h`
-- Threshold:
-  - 0-26 h gruen
-  - 26-30 h gelb
-  - >30 h rot
-- Subtitel im Panel: `Stunden seit letztem completed-Lauf`.
-- Fallback bis Metrik live: Panel zeigt `n/a`, Doku-Hinweis in der Beschreibung.
-
-### Panel 3: Naechster Cert-Ablauf
-
-- Type: `stat`
-- Title: `Cert laeuft in`
-- Query:
-  ```promql
-  min((probe_ssl_earliest_cert_expiry{job="blackbox-http"} - time()) / 86400)
-  ```
-- Einheit: `d` (Tage)
-- Threshold:
-  - >14 gruen
-  - 7-14 gelb
-  - <7 rot
-- Subtitel: `Tage bis kleinste Restlaufzeit aller geprueften Hosts`.
-
-### Panel 4: Kritische Container running
-
-- Type: `stat`
-- Title: `Kritische Container`
-- Query (sobald Container-Up-Metrik live ist):
-  ```promql
-  sum(homelab_critical_container_running)
-  ```
-- Threshold: erwartete Anzahl gruen, jeder fehlende Container rot.
-- Subtitel: `von <N> erwartet`. Erwartete Liste pflegen wir in `services/posture-check` / Textfile-Exporter (siehe `docs/AUDIT_2026-05-25_TODO.md` Sprint 3 "Container-Down-Alert").
-- Fallback: cAdvisor-Query als Naeherung, solange Textfile-Metrik noch nicht produktiv ist:
-  ```promql
-  count(rate(container_last_seen{name=~"traefik|authelia|postgresql17|Redis|gitea|komodo-core|komodo-mongo|komodo-periphery|monitoring-prometheus|monitoring-grafana|monitoring-loki|monitoring-alertmanager"}[5m]) > 0)
-  ```
-
-### Panel 5: Disk-Fuellung
-
-- Type: `bargauge`
-- Title: `Disk-Fuellung`
-- Query:
-  ```promql
-  100 * (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"})
-  ```
-- Anzeige: pro Mountpoint, sortiert absteigend.
-- Threshold:
-  - <70 gruen
-  - 70-85 gelb
-  - >85 rot
-- Subtitel: `Prozent belegt`.
-
-### Panel 6: Endpoint-Tabelle
-
-- Type: `table`
-- Title: `Endpoint-Status`
-- Spalten:
-  - Host (Instance)
-  - Status (`UP` / `DOWN`)
-  - Antwortzeit (probe_duration_seconds)
-- Queries:
-  - `probe_success{job="blackbox-http"}` -> Mapping: `1` -> `UP` (gruen), `0` -> `DOWN` (rot)
-  - `probe_duration_seconds{job="blackbox-http"}` -> Sekunden
-- Sortierung: DOWN oben, dann nach Antwortzeit absteigend.
-
-### Panel 7: Cert-Tage-Tabelle
-
-- Type: `table`
-- Title: `Cert-Tage bis Ablauf`
-- Spalten: Host, Tage
-- Query:
-  ```promql
-  (probe_ssl_earliest_cert_expiry{job="blackbox-http"} - time()) / 86400
-  ```
-- Sortierung: aufsteigend (am ehesten ablaufende oben).
-- Color-Mapping wie Panel 3.
-
-### Panel 8: Container-Status-Tabelle
-
-- Type: `table`
-- Title: `Kritische Container`
-- Spalten: Container, Running (1/0), letztes Restart (Sekunden seit Start)
-- Queries:
-  - sobald Textfile-Metrik live: `homelab_critical_container_running` (Label `name`)
-  - Fallback aus cAdvisor: `container_start_time_seconds{name=~"<Whitelist>"}`
-- Sortierung: nicht-running zuerst.
-
-## Spaeter ergaenzbar (nicht Teil der ersten Version)
-
-- Loki-Log-Volume-Spike-Panel
-- node_exporter Memory-Saturation-Panel
-- Plex-Sessions (nur wenn Plex-Exporter eingerichtet ist; aktuell nicht geplant)
-- Immich Asset-Wachstum (eigenes Dashboard, nicht Family-View)
-
-## Build-Reihenfolge fuer den spaeteren JSON
-
-Wenn das JSON gebaut wird, bitte in dieser Reihenfolge:
-
-1. Sicherstellen, dass alle Metriken aus den Queries oben in Prometheus auffindbar sind (`/graph` Smoke-Test).
-2. Dashboard in Grafana-UI manuell zusammenklicken; Layout an dieser Spezifikation entlang.
-3. JSON exportieren, in `monitoring/grafana/dashboards/family-view.json` ablegen.
-4. Provisioning-Provider laesst die Datei automatisch laden (siehe `monitoring/grafana/provisioning/dashboards/dashboards.yml`).
-5. Bei jeder Schema-Aenderung Doku hier nachziehen, damit Spec und JSON nicht driften.
-
-## Smoke-Test nach Aktivierung
-
-- Dashboard laedt unter `https://monitoring.kaleschke.info/d/homelab-family-view/`.
-- Alle 8 Panels rendern ohne `No data`.
-- Im Normalbetrieb erscheinen Panel 1-5 vollstaendig gruen.
-- Ein bewusster Test-Stale-Borg oder ein Container-Stop laesst die zugehoerigen Panels auf gelb/rot wechseln.
-
-## Was das Dashboard NICHT ersetzt
-
-- ntfy-Alerts: das Dashboard ist passiv (Pull), ntfy ist aktiv (Push). Beide sind notwendig.
-- DR-Doku: `docs/DISASTER_RECOVERY.md` bleibt die Recovery-Quelle.
-- Restore-Tests: `docs/RESTORE_DRILL_ROUTINE.md` ist die Kadenz, die das Dashboard nicht ersetzt.
-- Familien-Onboarding: `docs/FAMILY_ONBOARDING.md` ist die Doku fuer die Familie, dieses Dashboard ist Operator-Tool.

docs/FRITZBOX_PORT_CORRECTION_PLAN.md

@@ -1,104 +0,0 @@
-# FRITZ!Box Portfreigaben - Korrektur-Vorbereitung
-
-Status: **umgesetzt 2026-05-28**, Doku bleibt als Historie und Begruendungs-Anker.
-Audit-Bezug: `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 ("FRITZ!Box-Portfreigaben gegen Repo-Soll abgleichen") und `docs/NETWORK_INVENTORY.md`.
-
-## Umsetzungs-Befund 2026-05-28
-
-| Punkt | Entscheidung | Validierung |
-|---|---|---|
-| 1. `80/tcp` entfernen | **umgesetzt** | Mobilfunk-Test: `http://vault.kaleschke.info` Timeout, `https://...` weiter erreichbar. Lokal via LAN: HTTP->HTTPS-Redirect funktioniert weiter durch Traefik. |
-| 2. `222/tcp` ergaenzen | **bewusst NICHT umgesetzt** | Tailscale bleibt Operator-Pfad; GitHub-Mirror deckt DR-Bootstrap ab; SSH-Brute-Force-Vektor vermieden. Repo-Soll in `NETWORK_INVENTORY.md` und `MASTER_V2.md` Sektion 10 entsprechend angepasst. |
-| 3. UPnP-Selbstfreigabe `PC-192-168-178-71` | **umgesetzt** | "Selbstständige Portfreigaben fuer dieses Geraet erlauben" deaktiviert. Identifiziert als VONETS-WiFi-Bridge (Hostname `VONETS.COM`, MAC `00:17:13:2F:61:96`) — vermutlich Bridge zum SolarEdge-Wechselrichter. SolarEdge-Cloud-Sync ist outbound und benoetigt keine UPnP. |
-
-Aktiver Endstand: ausschliesslich `443/tcp -> 192.168.178.58:443` (Traefik HTTPS) ist von WAN aus erreichbar.
-
-## Aktueller FRITZ!Box-Befund (2026-05-27)
-
-Aus dem Operator-Live-Check der FRITZ!Box-UI:
-
-- aktiv: `80/tcp` -> `192.168.178.58`
-- aktiv: `443/tcp` -> `192.168.178.58`
-- fehlt: `222/tcp` -> `192.168.178.58` (Gitea-SSH)
-- zusaetzlich gemeldet: eine Portfreigabe durch das Geraet `PC-192-168-178-71` (Selbst-Freigabe per UPnP)
-
-## Soll-Stand laut Repo
-
-`docs/NETWORK_INVENTORY.md` definiert genau zwei aktive Portfreigaben:
-
-| Erwartete Freigabe | Ziel | Begruendung |
-|---|---|---|
-| `443/tcp` -> `192.168.178.58:443` | Traefik HTTPS | einziger Public-HTTPS-Einstieg, Wildcard-Zert ueber Cloudflare-DNS-Challenge |
-| `222/tcp` -> `192.168.178.58:222` | Gitea SSH | Git-SSH-Push/Pull; dokumentierte Ausnahme |
-
-Port `80/tcp` ist im Cloudflare-DNS-Challenge-Modell **nicht** notwendig.
-
-## Drei Korrektur-Punkte
-
-### 1. `80/tcp` entfernen
-
-Begruendung:
-
-- ACME laeuft als Cloudflare-DNS-Challenge (`traefik/docker-compose.yml`), nicht als HTTP-01.
-- Traefik leitet intern jeden HTTP-Request auf `https://` weiter; ein WAN-`80`-Listener bietet keinen Mehrwert, oeffnet aber einen zusaetzlichen Angriffsvektor (Header-/Method-Scanning, Open-Redirect-Versuche bevor TLS terminiert).
-- Innerhalb des LAN funktioniert die Browser-Auto-HTTPS-Umleitung weiter ueber AdGuard-DNS.
-
-Empfehlung: WAN-Eintrag `80/tcp` in FRITZ!Box-UI **entfernen** nach Operator-Go.
-
-Validierung nach Aenderung:
-
-```bash
-# WAN-seitiger Test, idealerweise von einem Geraet im Mobilfunknetz oder Tailscale-Exit-Node
-curl -sI http://kaleschke.info/   # erwartet: Connection refused / Timeout
-curl -sI https://vault.kaleschke.info/   # erwartet: HTTP/2 200 oder Authelia-Redirect
-```
-
-### 2. `222/tcp` ergaenzen (nur wenn externes Git-SSH wirklich gewuenscht)
-
-Frage an Operator: Wird `git@git.kaleschke.info -p 222` von extern gebraucht? Hinweise:
-
-| Pro `222/tcp` extern | Contra `222/tcp` extern |
-|---|---|
-| Push/Pull vom unterwegs-Laptop ohne Tailscale | Tailscale ist schon der Operator-Pfad, deckt das voll ab |
-| GitHub-Mirror-Bootstrap funktioniert dann auch ohne Tailscale | GitHub-Push-Mirror laeuft automatisch von Gitea aus, braucht kein WAN-SSH |
-| Externe Webhooks gegen Git push (nicht in Nutzung) | weniger Angriffsflaeche fuer SSH-Brute-Force |
-
-Empfehlung: `222/tcp` **nicht** ergaenzen, solange Tailscale stabil verfuegbar ist. Stattdessen `docs/NETWORK_INVENTORY.md` und `HOMELAB_ARCHITECTURE_MASTER_V2.md` darauf abgleichen, dass Gitea-SSH bewusst LAN/Tailscale-only ist.
-
-Wenn Operator entscheidet, `222/tcp` doch extern zu oeffnen: zusaetzlich SSH-Login auf Key-only setzen, Brute-Force-Limits in Gitea pruefen, `docs/NETWORK_INVENTORY.md` "Erwartete Freigabe"-Tabelle aktualisieren.
-
-### 3. UPnP-Selbstfreigabe von `PC-192-168-178-71` deaktivieren
-
-Begruendung:
-
-- Geraete-initiierte Portfreigaben (UPnP) sind ausserhalb der Repo-Sollkonfiguration.
-- Welcher Port von welchem Programm geoeffnet wurde, ist aus der FRITZ!Box-UI heraus nicht versionierbar.
-- Wenn der Port gebraucht wird, gehoert er als bewusste Operator-Freigabe in `docs/NETWORK_INVENTORY.md`.
-
-Empfehlung in zwei Stufen:
-
-1. FRITZ!Box-UI: in den Geraete-Details fuer `PC-192-168-178-71` die aktuelle Selbstfreigabe-Liste pruefen und mit dem Operator besprechen.
-2. Wenn der Port nicht gebraucht wird: Selbstfreigabe deaktivieren. Optional: UPnP global pro Geraet abschalten ("Selbststaendige Portfreigaben fuer dieses Geraet erlauben" abwaehlen).
-
-## Schutzregeln
-
-- Keine Router-Aenderung ohne ausdrueckliches Operator-Go.
-- Nach jeder Aenderung: `docs/NETWORK_INVENTORY.md` Abschnitt "FRITZ!Box (WAN -> Host)" gegen den neuen UI-Stand abgleichen.
-- Aenderung in `docs/MIGRATION_LOG.md` als kurzer Eintrag dokumentieren (was/warum/Validierung).
-- Bei `80/tcp`-Entfernung kurz prufen, ob irgendein externer Dienst noch HTTP-01 nutzen wollte (sollte nicht der Fall sein).
-
-## Nicht Teil dieser Vorbereitung
-
-- FRITZ!OS-Update 8.21 -> aktuell. Das ist eigenes Service-Fenster und braucht WAN/Tailscale-Aufbau-Beobachtung.
-- IPv6-Exposure. Wenn Telekom IPv6 zustellt und Apps via Cloudflare-AAAA erreichbar sind, kann WAN-Filter pro Port noetig werden. Separater Doku-Punkt in `docs/NETWORK_INVENTORY.md` Offene Entscheidungen.
-- Mobilfunk-Failover-Stick. Bewusst nicht eingerichtet.
-
-## Offene Punkte
-
-| Status | Punkt | Naechster Schritt |
-|---|---|---|
-| erledigt 2026-05-28 | `80/tcp` entfernen | umgesetzt, Mobilfunk-validiert |
-| erledigt 2026-05-28 (bewusst nicht) | `222/tcp` Entscheidung | bleibt Tailscale-only; Repo-Soll entsprechend angepasst |
-| erledigt 2026-05-28 | UPnP-Freigabe `PC-192-168-178-71` | UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge deaktiviert |
-| offen | FRITZ!OS 8.21 Update | Service-Fenster, separat geplant |
-| offen | IPv6-Exposure pruefen | bei naechstem WAN-Touch mit erfassen |

docs/GUEST_IOT_NETWORK.md

@@ -0,0 +1,117 @@
+# Guest / IoT Network Runbook
+
+Stand: 2026-06-06
+
+Dieses Runbook beschreibt den sicheren Weg, das FRITZ!Box-Gastnetz zu aktivieren,
+ohne versehentlich Homelab-Admin-Ports aus dem Gastsegment erreichbar zu machen.
+
+## Zielbild
+
+- Normales LAN bleibt `192.168.178.0/24`.
+- Kallilabcore bleibt im normalen LAN unter `192.168.178.58`.
+- FRITZ!Box-Gast-WLAN darf Internetzugang haben, aber keinen Zugriff auf
+  `192.168.178.0/24`.
+- Homelab-Admin-Pfade bleiben Operator-only:
+  - Tailscale fuer Admin-Zugriff
+  - Authelia/2FA fuer geschuetzte Web-UIs
+  - keine LAN-Admin-Ports aus dem Gastnetz
+
+## Vorbedingungen
+
+Vor dem Einschalten des Gast-WLANs muessen diese Preflights gruen sein:
+
+```powershell
+G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode LanPreflight
+```
+
+Erwartung im normalen LAN:
+
+- `192.168.178.58:8082` ist blockiert (AdGuard Admin nur Tailscale).
+- `192.168.178.58:8181` ist blockiert (InfluxDB nicht LAN-exponiert).
+- `192.168.178.58:80`, `443`, `222` koennen im normalen LAN erreichbar sein.
+
+Auf Unraid zusaetzlich:
+
+```bash
+/mnt/user/services/homelab-infra/ops/maintenance/check-guest-iot-preflight.sh
+```
+
+Validierung 2026-06-06: Host-Preflight erfolgreich, Report
+`/mnt/user/backups/restore-reports/guest-iot-preflight-2026-06-06-131316.md`.
+Ergebnis: FRITZ!Box 7590 per TR-064 erreichbar, `192.168.178.58:8082`
+blockiert, `100.80.98.33:8082` erreichbar, `192.168.178.58:8181` blockiert.
+
+Gast-WLAN-Smoke 2026-06-06: Operator hat ein iPhone mit `Fritzi Gastzugang`
+verbunden und folgende Ziele getestet; alle waren aus dem Gast-WLAN nicht
+erreichbar:
+
+- `http://192.168.178.58:8082`
+- `http://192.168.178.58:8181`
+- `http://192.168.178.58:222`
+- `https://192.168.178.58`
+- `http://192.168.178.1`
+
+Damit ist die Gastnetz-Isolation fuer die getesteten Homelab-/Router-Adminpfade
+validiert.
+
+## FRITZ!Box Schritte
+
+In der FRITZ!Box UI:
+
+1. `WLAN -> Gastzugang` oeffnen.
+2. `Gastzugang aktiv` einschalten.
+3. WPA2/WPA3-Verschluesselung aktiv lassen.
+4. Eigenen Gast-SSID-Namen setzen, z. B. `Fritzi-Gast`.
+5. Starkes Passwort setzen und in Vaultwarden ablegen.
+6. Option `Geraete im Gastnetz duerfen miteinander kommunizieren` deaktiviert
+   lassen, sofern nicht bewusst gebraucht.
+7. Option fuer Zugriff auf das Heimnetz / private Netzwerk deaktiviert lassen.
+8. Gastzugang speichern.
+
+Wichtig: Die genaue FRITZ!OS-8.25-UI-Beschriftung kann leicht variieren. Der
+entscheidende Punkt ist: Gastgeraete duerfen keinen Zugriff auf das Heimnetz
+haben.
+
+## Verifikation
+
+Ein Handy oder Laptop mit dem Gast-WLAN verbinden, dann auf diesem Geraet testen:
+
+```powershell
+G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode Guest
+```
+
+Erwartung aus dem Gast-WLAN:
+
+- `192.168.178.58:80` blockiert
+- `192.168.178.58:443` blockiert
+- `192.168.178.58:222` blockiert
+- `192.168.178.58:8082` blockiert
+- `192.168.178.58:8181` blockiert
+- `192.168.178.1:80` blockiert oder nur Gast-Gateway-Ansicht
+
+Wenn der Test `Risk count: 0` meldet, ist die Isolation fuer die getesteten
+Homelab-Admin-Pfade ausreichend.
+
+## Betrieb
+
+- Familien-/Gaestegeraete kommen ins Gast-WLAN, wenn sie keinen direkten Zugriff
+  auf LAN-Geraete brauchen.
+- Homelab-Apps fuer Familie laufen perspektivisch ueber HTTPS/OIDC, nicht ueber
+  direkten LAN-Zugriff.
+- Geraete, die lokale Discovery brauchen (z. B. manche Smart-TV/Plex-Szenarien),
+  bleiben im normalen LAN oder bekommen eine separate bewusste Entscheidung.
+
+## Rollback
+
+Wenn nach Aktivierung etwas Unerwartetes passiert:
+
+1. FRITZ!Box: `WLAN -> Gastzugang` oeffnen.
+2. Gastzugang deaktivieren.
+3. Speichern.
+4. Normalen LAN-Zugriff pruefen:
+   ```powershell
+   G:\Gitea_Clone\homelab-infra\ops\maintenance\check-guest-iot-isolation.ps1 -Mode LanPreflight
+   ```
+
+Es werden durch dieses Runbook keine Docker-Stacks, Secrets oder produktiven
+Appdaten veraendert.

docs/HARDWARE_INVENTORY.md

@@ -3,8 +3,20 @@
 Status: Hardware-Baseline erfasst; USV/Power-Loss ist als bewusst akzeptiertes Betreiber-Risiko dokumentiert.
 Host: `Kallilabcore`
 Letzte Pruefung: 2026-05-26
+Doku-Stand Betreiberentscheidungen: 2026-06-05
 Naechster Review: 2026-08-26
 
+## Betreiber-Entscheidungen (Stand 2026-06-05)
+
+Diese drei Punkte waren bisher diffuse TBDs und sind jetzt als bewusste
+Entscheidungen festgehalten. Details in den jeweiligen Abschnitten unten.
+
+| Thema | Entscheidung | Review-Trigger |
+|---|---|---|
+| USV / Power Loss | **Bewusst auf Q3/2026 geparkt.** Keine Anschaffung dieses Quartal; Power-Loss bleibt akzeptiertes Risiko. | Naechstes Hardware-Upgrade, erneuter realer Stromausfall mit Datenfolge, oder Q3-Review (ab 2026-07-01) |
+| Cold-Backup-Rotation | **Bewusst Hetzner-only.** Off-site bleibt allein das Hetzner-Borg-Repo; keine zweite rotierende Cold-Kopie. | Stark wachsender Datenwert, wiederholte Hetzner-Probleme, oder geaenderte Betreiber-Praeferenz |
+| Stromverbrauch messen | **Bewusst ohne Messung (Entscheidung 2026-06-06).** Kein Messgeraet; Werte bleiben dauerhaft offen, kein Beschaffungs-Todo. | Nur falls spaeter doch ein Messgeraet angeschafft wird oder Strom-/Kostenfrage relevant wird |
+
 ## Zweck
 
 Dieses Dokument beschreibt die physische Basis des Homelabs. Es ist die Grundlage fuer Capacity Planning, Restore-Zeit, Ersatzteilplanung, USV-Verhalten und Entscheidungen wie Immich-ML, Plex-Transcoding oder Storage-Erweiterung.
@@ -19,7 +31,7 @@ Dieses Dokument beschreibt die physische Basis des Homelabs. Es ist die Grundlag
 | Unraid-Version | 7.2.4 |
 | Rolle | Single-Host Homelab, Docker Compose via Komodo |
 | Boot-Medium | Samsung Flash Drive, 59.8G, FAT32 |
-| Flash-Backup | In Borg-Scope aufgenommen, siehe `docs/MIGRATION_LOG.md` |
+| Flash-Backup | In Borg-Scope aufgenommen, siehe `docs/RESTORE_MATRIX.md` |
 
 ## CPU
 
@@ -96,7 +108,7 @@ tailscale ip -4
 | Disk1 | `md1p1` / physisch `sdc` | WDC WD60EFAX-68JH4N1 | `WD-WX32D90PC0V0` | 5.5T | XFS auf md1p1 | Array-Daten | SMART passed |
 | Parity | physisch `sdb` | TOSHIBA HDWG480 | `2460A03VFA3H` | 7.3T | n/a | Parity | SMART passed |
 | Boot | `sda1` | Samsung Flash Drive | `0375125090000587` | 59.8G | FAT32 | Unraid Boot | aktiv |
-| Cold Backup | TBD | TBD | TBD | TBD | TBD | Externe Rotation | offen |
+| Cold Backup | bewusst keiner | n/a | n/a | n/a | n/a | Externe Rotation | **bewusst Hetzner-only** (Entscheidung 2026-06-05); off-site allein via Hetzner-Borg |
 
 Pruefkommando:
 
@@ -138,18 +150,27 @@ Bewertung:
 
 - Aktueller Befund 2026-05-26: keine funktionierende USV-Absicherung nachgewiesen.
 - `apcupsd` ist zwar auf dem System vorhanden, aber nicht aktiv.
-- Operator-Entscheidung 2026-05-26: aktuell keine USV-Anschaffung.
+- **Operator-Entscheidung 2026-06-05: USV-Anschaffung bewusst auf Q3/2026 geparkt.** Keine Beschaffung in diesem Quartal.
 - Power-Loss bleibt damit ein bewusst akzeptiertes Risiko fuer Docker-/DB-State und laufende Writes.
-- Review-Ausloeser: Hardware-Erweiterung, wiederholte Stromausfaelle, Datenkorruption oder Veraenderung der Betreiber-Prioritaet.
+- Review-Trigger (einer reicht): naechstes Hardware-Upgrade, ein erneuter realer Stromausfall mit Datenfolge, oder der Q3-Review ab 2026-07-01.
+- Wenn die Entscheidung in Q3 zugunsten einer USV kippt, ist das Mindestkriterium ein USB-HID-faehiges Geraet (~600-900 VA), das von `apcupsd` erkannt wird, damit der bereits vorkonfigurierte Shutdown-Pfad ohne Zusatzsoftware greift.
 
 ## Stromverbrauch
 
+**Bewusst ohne Messung (Operator-Entscheidung 2026-06-06).** Es wird kein
+Messgeraet beschafft; Idle/Normal/Backup/Last bleiben dauerhaft offen. Kein
+offener Todo. Falls spaeter doch eine Mess-Steckdose angeschafft wird, reicht
+ein einziger Messdurchlauf, um die Tabelle zu fuellen.
+
 | Zustand | Verbrauch | Messmethode | Datum |
 |---|---:|---|---|
-| Idle | TBD | externes Messgeraet erforderlich | TBD |
+| Idle | offen | schaltbare Mess-Steckdose, 10 min Mittelwert ohne aktive Jobs | nach Beschaffung |
-| Normalbetrieb | TBD | externes Messgeraet erforderlich | TBD |
+| Normalbetrieb | offen | Mess-Steckdose, typischer Tagbetrieb mit laufenden Apps | nach Beschaffung |
-| Backup-Lauf | TBD | externes Messgeraet erforderlich | TBD |
+| Backup-Lauf | offen | Mess-Steckdose, waehrend naechtlichem Borg-Lauf | nach Beschaffung |
-| Last | TBD | externes Messgeraet erforderlich | TBD |
+| Last | offen | Mess-Steckdose, unter CPU-Last (z. B. Immich-ML/Parity-Check) | nach Beschaffung |
+
+Beschaffungs-Trigger: einfache schaltbare Energiemess-Steckdose; danach ein
+einziger Messdurchlauf reicht, um diese Tabelle dauerhaft zu fuellen.
 
 ## Ersatzteil- und Lifecycle-Plan
 
@@ -160,7 +181,7 @@ Bewertung:
 | Parity | Kleiner als neue groesste Datenplatte | Parity-Upgrade vor Datenplatten-Upgrade |
 | Boot-USB | Lesefehler oder Alter TBD | Flash-Backup verifizieren, Ersatzstick vorbereiten |
 | RAM | Swap/OOM oder Immich/Nextcloud-Druck | Ausbau planen |
-| USV | keine funktionierende USV-Abschaltung | Risiko am 2026-05-26 bewusst akzeptiert; bei Review erneut bewerten |
+| USV | keine funktionierende USV-Abschaltung | Anschaffung 2026-06-05 bewusst auf Q3/2026 geparkt; Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review |
 
 ## Audit-Kommandos
 

docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.md

@@ -1,8 +1,15 @@
 # Home Assistant -> InfluxDB 3 -> Grafana
 
+**Status 2026-06-06: archiviert / nicht aktiv.** Home Assistant existiert seit
+dem Crash aktuell nicht mehr. Dieses Dokument ist nur noch ein historischer
+Zielbild-Entwurf fuer einen spaeteren Neuaufbau. Das fruehere TODO
+`influxdb3_homeassistant_token` wurde aus der aktiven Master-Liste gestrichen;
+vor Token-, InfluxDB-Writer- oder Ecowitt-Arbeiten muss Home Assistant zuerst
+neu aufgesetzt und neu inventarisiert werden.
+
 Ziel: Home Assistant schreibt ausgewaehlte Ecowitt- und Energiesensoren nach InfluxDB 3 Core. Grafana bleibt das Langzeit-Dashboard, Home Assistant bleibt die Automationszentrale.
 
-## Live-Stand 2026-05-04
+## Historischer Live-Stand 2026-05-04
 
 - Home Assistant ist per SSH unter `192.168.178.50:22222` erreichbar.
 - `ha core check` ist erfolgreich.

docs/H_DRIVE_NEARLINE_PULL.md

@@ -12,6 +12,12 @@ Status: **produktiv** (2026-05-28). Erster echter Lauf 2026-05-27 20:45 erfolgre
   - `ops/h-drive-nearline/pull-critical-backups.ps1` excluded die `unraid-flash-config.*`-Familie ueber `/XF`, damit Flash-Config bewusst nicht in den Nearline-Scope kommt.
 - Zweiter Lauf (nach Fixes): beide Robocopy-Jobs Exit-Code 1, **19 Borg-Dumps + 10 Gitea-Bundle-Files** auf H:/.
 
+## Befund 2026-06-01
+
+- Der Scheduled Task um 05:30 kopierte die aktuellen Dumps, brach aber mit Robocopy Exit-Code 8 ab, weil im Dump-Root alte `*-pre-*` Dateien und Migration-/Cutover-Verzeichnisse mit restriktiven Rechten lagen.
+- Fix: `ops/h-drive-nearline/pull-critical-backups.ps1` kopiert fuer `borg-dumps-latest` nur noch die kuratierte Pflichtdatei-Liste und schliesst Migration-/Cutover-Verzeichnisse aus.
+- Manueller Kontrolllauf 2026-06-01 08:25 erfolgreich: `borg-dumps-latest` Exit-Code 0, `gitea-bundles` Exit-Code 1 (Robocopy-Erfolg mit Kopien), Report `H:\kallilab-nearline-backups\_reports\nearline-pull-2026-06-01-082553.md`.
+
 ## Zweck
 
 `H:/` ist eine zweite lokale Nearline-Kopie fuer die wichtigsten Restore-Artefakte. Es ersetzt weder Hetzner/Borg noch ein echtes Off-site-/Airgap-Ziel, reduziert aber das Risiko, dass ein lokaler Restore nur vom Unraid-Array abhaengt.
@@ -20,11 +26,13 @@ Status: **produktiv** (2026-05-28). Erster echter Lauf 2026-05-27 20:45 erfolgre
 
 | Zweck | Quelle | Ziel |
 |---|---|---|
-| Aktuelle Dumps inklusive Flash-Backup | `\\192.168.178.58\backups\borg\dumps\latest` | `H:\kallilab-nearline-backups\borg-dumps\latest` |
+| Aktuelle kuratierte Dumps ohne Flash-Backup | `\\192.168.178.58\backups\borg\dumps\latest` | `H:\kallilab-nearline-backups\borg-dumps\latest` |
 | Gitea-Bundles | `\\192.168.178.58\backups\git-bundles\gitea` | `H:\kallilab-nearline-backups\git-bundles\gitea` |
 
 Das Skript kopiert bewusst **nicht** mit `/MIR` und loescht keine Dateien auf `H:/`. Alte Artefakte duerfen dort erst nach manueller Sichtpruefung geloescht werden.
 
+Der Borg-Dumps-Job ist eine Whitelist der aktuellen Nearline-Pflichtartefakte. Einmalige Migrations-Sicherungen, Pre-Major-Snapshots und Redis-Cutover-Verzeichnisse bleiben ueber Borg/Hetzner abgedeckt, sind aber kein H:/-Nearline-Pflichtbestand.
+
 ## Skript
 
 ```powershell

docs/IMMICH_RESTORE_TEST.md

@@ -1,78 +0,0 @@
-# Immich Restore Test
-
-Status: **erfolgreich live verifiziert** (2026-05-27)
-Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-11**
-
-## Zweck
-
-Schliesst die Audit-Luecke aus F-11: Immich ist der groesste Datentopf (Familien-Fotos), und bisher gibt es im Gegensatz zu Vaultwarden, Gitea und Paperless **keinen** verifizierten Mini-Restore-Test. Dieses Dokument verlinkt die Repo-Artefakte und beschreibt den Ablauf aus Operator-Sicht.
-
-## Repo-Artefakte
-
-| Datei | Zweck |
-|---|---|
-| `ops/restore-tests/immich-compose.test.yml` | isoliertes Test-Compose: pgvecto-rs Postgres + Redis + Immich-Server, ML weggelassen, `127.0.0.1:12283` |
-| `ops/restore-tests/immich-restore-test.sh` | Host-Bash-Skript fuer den Lauf, mit `--what-if` und `--keep-data` Flags |
-| `ops/restore-tests/immich-restore-test.ps1` | Plan-Scaffold fuer Windows-Operator-Sicht (kein Live-Run) |
-| `ops/restore-tests/immich-plan.md` | Fachlicher Plan: Quellen, Schutzregeln, Smoke-Test-Kriterien, bekannte Risiken |
-| `ops/restore-tests/immich-runbook.md` | Konkreter Operator-Ablauf, Fehlerfaelle, Schedule-Vorschlag |
-
-## Was der Test abdeckt
-
-- Extraktion von `local/borg-dumps/latest/immich.dump` aus dem aktuellsten Borg-Archiv
-- Import in eine isolierte `tensorchord/pgvecto-rs:pg14-v0.2.0` Postgres-Instanz mit demselben Digest wie Produktion
-- Start eines isolierten Immich-Server-Containers mit demselben Digest wie Produktion, **ohne** ML-Container und **ohne** Traefik
-- Smoke-Test: Login-Seite erreichbar, `asset`- und `"user"`-Tabelle lesbar
-- Markdown-Report unter `/mnt/user/backups/restore-reports/immich-YYYY-MM-DD.md`
-- Bereinigung von Test-Container und Restore-Lab-Daten nach Erfolg
-
-## Was der Test bewusst NICHT abdeckt
-
-- Wiederherstellung produktiver Foto-Dateien (`/mnt/user/photos/immich`, `/mnt/user/photos/family_archive`). Diese Pfade werden vom Test nicht angefasst und nicht in den Test-Container gemountet.
-- Machine-Learning-Container. Spart Image-Pull-Zeit und RAM; ML-Features sind im Smoke-Test irrelevant.
-- Echte Login-Flow per API. Smoke-Test prueft nur, dass Login-Seite ausgeliefert wird.
-- Asset-Rendering / Thumbnail-Generierung. Ohne Foto-Files erwartet.
-- Produktive Domain `immich.kaleschke.info`. Test laeuft ausschliesslich auf `127.0.0.1:12283`.
-
-## Restore-Stufe
-
-Der Test deckt **Stufe 4 (kritische Anwendungen)** aus `docs/DISASTER_RECOVERY.md` Phase 4 fuer Immich ab, allerdings nur DB-Ebene und UI-Smoke. Voll-Restore inklusive Foto-Dateien aus Borg ist eigener Folgeschritt; das Skript bereitet die Restore-Lab-Struktur dafuer vor.
-
-## Erster Lauf und Preflight
-
-| Pruefung | Verantwortlich | Wo |
-|---|---|---|
-| Dump-Groesse von `immich.dump` bestimmen | erledigt 2026-05-27 | 66M unter `/mnt/user/backups/borg/dumps/latest/immich.dump` |
-| Freier Platz unter `/mnt/user/backups/restore-lab/` | erledigt 2026-05-27 | ca. 3.7T frei auf `/mnt/user/backups` |
-| Borg-UI-Container laeuft | Operator | `docker ps | grep borg-ui` |
-| Trockenlauf mit `--what-if` | erledigt 2026-05-27 | Host-Clone auf `c5d231a`, `bash ops/restore-tests/run-restore-checks.sh immich --what-if` erfolgreich |
-| Erster echter Lauf | erledigt 2026-05-27 | Report `/mnt/user/backups/restore-reports/immich-2026-05-27.md`; Archiv `Tägliche-Sicherung-2026-05-27T04:30:06.778`; HTTP `200`; Assets `11977`; User `1` |
-
-## Nach dem ersten erfolgreichen Lauf
-
-1. Report unter `/mnt/user/backups/restore-reports/immich-2026-05-27.md` liegt vor und ist erfolgreich.
-2. `docs/RESTORE_MATRIX.md`, `ops/restore-tests/schedule.md`, `docs/AUDIT_2026-05-25_TODO.md` und `docs/MIGRATION_LOG.md` wurden nachgezogen.
-3. Quartalsweise Wiederholung einplanen; erster Live-Lauf bleibt bewusst manuell/Operator-kontrolliert, bis mehrere Laeufe stabil waren.
-
-## Schutzregeln
-
-- Skript greift ausschliesslich auf den Restore-Lab-Pfad und den Borg-Extract-Cache zu.
-- Produktive Pfade unter `/mnt/user/photos/*` und `/mnt/user/appdata/immich_postgres/` werden nicht angefasst.
-- Produktive Container `immich_server`, `immich_postgres`, `immich_redis`, `immich_machine_learning` werden nicht gestoppt, nicht beruehrt.
-- Borg-Passphrase wird aus `/mnt/user/appdata/secrets/borg_repo_passphrase.txt` gelesen und nicht in Reports, Logs oder Doku geschrieben.
-- Test-Container publishen nur auf `127.0.0.1:12283`, nicht auf LAN- oder Tailscale-Interface.
-- Keine Traefik-Labels, keine Public-URL fuer Testcontainer.
-
-## Risiken (aus `ops/restore-tests/immich-plan.md`)
-
-- Dump-Groesse und erster `pg_restore`-Lauf sind gemessen: `immich.dump` 66M, echter Smoke-Test erfolgreich am 2026-05-27.
-- pgvecto-rs Extension-Mismatch bei Image-Drift moeglich; Compose pinnt denselben Digest wie Produktion.
-- Immich v2 meldet pgvecto-rs als deprecated; VectorChord-Migration ist ein kuenftiger Immich-Upgrade-Punkt, nicht Teil dieses Restore-Tests.
-- Immich-Server-Migrations koennen Startup nach Restore verzoegern; Skript pollt 120 s.
-- Bei Schema-Drift (z. B. nach Major-Update) koennen einzelne DB-Queries abweichen; das Skript versucht Immich-v2-Singular-Tabellen und aeltere Plural-Fallbacks.
-
-## Naechste Operator-Schritte
-
-1. Quartalsweise Wiederholung nach `ops/restore-tests/schedule.md` einplanen.
-2. Bei zukuenftigem Immich-Major-Upgrade den Restore-Test unmittelbar danach einmal manuell ausfuehren.
-3. Voll-Restore inklusive Foto-Dateien bleibt ein eigener, deutlich groesserer DR-Drill.

docs/MASTER_TODO.md

@@ -0,0 +1,112 @@
+# Master To-do - KalliLab CORE
+
+Stand: 2026-06-06 (Wochenend-Sprint, nach Status-Kategorien sortiert)
+
+Diese Liste ist die zentrale Arbeitsliste fuer offene operative Punkte im
+Homelab. Detailentscheidungen bleiben in den verlinkten Runbooks; diese Datei
+haelt Status, naechsten konkreten Schritt und Quelle zusammen.
+
+## Status-Kategorien
+
+- **Aktiv dieses Wochenende** - soll jetzt vorankommen (Claude, Codex oder Operator); konkreter naechster Schritt steht.
+- **Operator-Entscheidung** - wartet auf eine bewusste Entscheidung des Betreibers (ja/nein/welche Option).
+- **Geparkt** - bewusst nicht jetzt, mit klarem Review-Trigger.
+- **Extern blockiert** - wartet auf ein externes Ereignis oder eine Abhaengigkeit (Nachtlauf, zweite Hardware, Geraetebeschaffung).
+
+Owner-Aufteilung fuer das Wochenende: `baerchen`/Veeam/Backup-Verifikation liegt
+bei **Codex**; Doku-/Inventar-/Onboarding-Arbeit liegt bei **Claude**;
+Host-/Entscheidungsaufgaben beim **Operator**.
+
+---
+
+## Aktiv dieses Wochenende
+
+| Thema | Owner | Naechster konkreter Schritt | Quelle |
+|---|---|---|---|
+| Family-Onboarding erster Termin | Operator | Checkliste ist fertig (`docs/FAMILY_ONBOARDING.md` Abschnitt "Erster Onboarding-Termin"). Operator legt fest, welche Personen/Geraete real verfuegbar sind, und arbeitet die Reihenfolge Vaultwarden -> Immich -> Mealie pro Person ab | `docs/FAMILY_ONBOARDING.md`, `docs/AUDIT_2026-05-25_TODO.md` |
+| Restore-Test Unraid OS Flash (Stick-Boot) | Operator | Artefakt-Validierung am 2026-06-05 erledigt (`ops/maintenance/check-unraid-flash-backup.sh`, sha256 OK, 8 Kern-Configs). **Verbleibt:** physischer Ersatzstick-Boot-Test, wenn ein Wegwerf-Stick bereitliegt | `docs/RESTORE_MATRIX.md` Abschnitt "Unraid OS Flash" |
+| Restore-Test Tailscale | Operator | Runbook-Stub abarbeiten: State-Validierung + Reconnect nur auf Wegwerf-Host/VM, danach Geraet in Tailscale-Admin entfernen | `docs/RESTORE_MATRIX.md` Abschnitt "Tailscale" |
+| Authelia OIDC fuer Apps | Operator/Claude | **Aktive Phase abgeschlossen 2026-06-06.** Live: Grafana (admin, Login verifiziert) + Mealie (family, verifiziert) + Paperless (family, deployed; Login-Test offen). Muster + Gotchas in `docs/AUTHELIA_OIDC_PLAN.md`. **Immich + Nextcloud bewusst GEPARKT bis Onboarding** (Entscheidung 2026-06-06): nur `micha` hat Authelia-Account, Familien-SSO-Nutzen + UI/occ-Aufwand lohnen erst mit Familien-Accounts. Runbook bereit | `docs/AUTHELIA_OIDC_PLAN.md`, `security/authelia/configuration.yml` |
+
+---
+
+## Operator-Entscheidung
+
+**Stand 2026-06-06: keine offenen Operator-Entscheidungen.** Alle am 2026-06-06
+entschieden — Ergebnisse in "Aktiv", "Geparkt" bzw. "Entschieden 2026-06-06".
+
+---
+
+## Geparkt
+
+Bewusst nicht jetzt - mit Review-Trigger.
+
+| Thema | Entscheidung / Trigger | Quelle |
+|---|---|---|
+| USV-Anschaffung | **Auf Q3/2026 geparkt** (2026-06-05). Power-Loss bleibt akzeptiertes Risiko. Trigger: Hardware-Upgrade, realer Stromausfall mit Datenfolge, oder Q3-Review ab 2026-07-01 | `docs/HARDWARE_INVENTORY.md` |
+| Cold-Backup-Rotation | **Bewusst Hetzner-only** (2026-06-05). Keine zweite rotierende Cold-Kopie. Trigger: stark wachsender Datenwert, wiederholte Hetzner-Probleme, geaenderte Praeferenz | `docs/HARDWARE_INVENTORY.md` |
+| WAN-Ausfallschutz | **Spaeter evaluieren** (2026-06-05). Mobilfunk-Failover inaktiv; lokale Apps laufen bei WAN-Ausfall weiter. Trigger: haeufigere/laengere DSL-Ausfaelle oder kritischer Remote-Zugang | `docs/NETWORK_INVENTORY.md` |
+| Docker Critical Events Watcher | **Aktiviert 2026-06-05:** Unraid User Script `docker-critical-events-at-start` nutzt den Supervisor und steht in `schedule.json` auf `frequency: start`; Watcher manuell gestartet, Status `running`. Optionaler ntfy-Smoke wurde nachts bewusst nicht gesendet und kann spaeter mit `docker-critical-events-supervisor.sh smoke` nachgeholt werden | `docs/SERVICE_CATALOG.md`, `services/posture-check/docker-critical-events.sh`, `services/posture-check/unraid-user-scripts.md` |
+| Negativ-Test Backup-Frische | **Validiert 2026-06-06:** `ops/restore-tests/negative-freshness-alert-test.sh` simuliert fehlende Dumps nur in einem synthetischen Restore-Lab-Pfad und sendet einen Test-Alert nach `homelab-alerts`; Host-Lauf schrieb Report `/mnt/user/backups/restore-reports/freshness-negative-2026-06-06-130320.md` (10 Criticals, produktive Dumps unangetastet). Quartalsweise wiederholen: `ops/restore-tests/run-restore-checks.sh freshness-negative` | `ops/restore-tests/README.md`, `docs/AUDIT_2026-05-25_TODO.md` |
+| End-to-end-DR-Drill | Komplett-Bootstrap Phase 1-5 auf Wegwerf-Host; realistisch erst mit zweiter Hardware (siehe auch Extern blockiert) | `docs/AUDIT_2026-05-25_TODO.md`, `docs/DISASTER_RECOVERY.md` |
+| Wiederkehrende Restore-Drills | Vaultwarden, Gitea, Authelia, Komodo, Paperless, Immich, Traefik, PostgreSQL, Mongo, Nextcloud, Mealie, Mail-Archiver nach Matrix-Intervallen rotieren | `docs/RESTORE_MATRIX.md`, `docs/RESTORE_HANDBOOK.md` |
+| Dedizierter SMB-User `veeam-baerchen` | Optional spaeter, nur wenn Unraid-User-/Share-Rechte bewusst angefasst werden | `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
+| Nextcloud 2FA (Operator-TOTP) | **Geparkt (Entscheidung 2026-06-06):** Operator-TOTP fuer Nextcloud erst zusammen mit der app-weiten Familien-/OIDC-Policy entscheiden. Trigger: OIDC-/SSO-Block (jetzt aktiv) erreicht die App-Login-Ebene | `docs/AUDIT_2026-05-25_TODO.md` |
+| Tailnet-Konsole aufraeumen (Rest) | Nach Docker-Stack-Abbau (2026-06-06) nur noch tote Node-Eintraege: `kallilab-core` (down) und alter Offline-`baerchen` in der Tailscale-Admin-Konsole entfernen. Optional State-Pfad `/mnt/user/appdata/tailscale` nach `_archive/`. Trivial, kein Risiko | `docs/NETWORK_INVENTORY.md` |
+| CrowdSec vor Traefik | Bewusst nicht umgesetzt; einzige WAN-Tuer ist `443/tcp`, Authelia `regulation:` deckt Brute-Force ab. Neu bewerten bei breiterer Attack Surface | `docs/AUDIT_2026-05-25_TODO.md` |
+| Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 | `docs/AUDIT_2026-05-25_TODO.md`, `docs/SERVICE_CATALOG.md` |
+| Filebrowser-Mounts | Bei zukuenftigem Hardening-Sprint Mount-Scope reduzieren | `docs/SERVICE_CATALOG.md` |
+| Scrutiny Privileged-Ausnahme | Nur mit klarer Begruendung aendern; sonst dokumentierte Ausnahme beibehalten | `docs/SERVICE_CATALOG.md` |
+| Immich Redis named volume | Anonymes Volume bei passender Wartung auf named volume umstellen oder Ausnahme dokumentieren | `docs/SERVICE_CATALOG.md` |
+| Storage-Wachstum | Zweite NVMe, ZFS/BTRFS-Optionen, zweite Array-Disk nur bei Triggern aus Capacity-Doku | `docs/STORAGE_LAYOUT.md`, `docs/CAPACITY_AND_LIFECYCLE.md` |
+| Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen oder wachsendem Datenwert | `docs/AUDIT_2026-05-25_TODO.md` |
+| Borg `append-only` auf Hetzner | Operator-Entscheidung 2026-06-01: nicht umgesetzt (forced-command brach Key-Auth, Nutzen/Risiko unguenstig) | `docs/AUDIT_2026-05-25_TODO.md` |
+
+---
+
+## Extern blockiert
+
+Wartet auf ein externes Ereignis oder eine Abhaengigkeit.
+
+| Thema | Blockiert durch | Naechster Schritt sobald entblockt | Quelle |
+|---|---|---|---|
+| End-to-end-DR-Drill (Hardware-Teil) | Keine zweite Wegwerf-Hardware verfuegbar | Sobald zweite Hardware da ist: Komplett-Bootstrap Phase 1-5 fahren | `docs/DISASTER_RECOVERY.md` |
+
+---
+
+## Erledigt im Wochenend-Sprint (2026-06-05)
+
+- Restore-Matrix "Naechste Restore-Test-Kandidaten" bereinigt: 5 am 2026-06-03 abgeschlossene Kandidaten entfernt, durch die 4 real offenen Pfade ersetzt; Stand-Datum aktualisiert.
+- Restore-Test-Runbook-Stubs fuer Unraid Flash / AdGuard / Tailscale / Redis 8 in `docs/RESTORE_MATRIX.md` ergaenzt.
+- Alte Windows-Doku bereinigt: WinRE-/Admin-Check-To-dos in `boot-cleanup-plan-2026-06-04.md` und `laufwerks-neustruktur-2026-06-04.md` als erledigt markiert.
+- `docs/HARDWARE_INVENTORY.md`: USV (Q3-Park), Cold-Backup (Hetzner-only) und Stromverbrauch von diffusen TBDs auf bewusste Entscheidungen mit Review-Triggern gehoben.
+- `docs/NETWORK_INVENTORY.md`: Tailscale-Inventar am 2026-06-05 **real per read-only SSH gemessen** und eingetragen: IPv6 `fd7a:115c:a1e0::2c01:62b2`, Exit Node `nein`, **Subnet-Router fuer `192.168.178.0/24` aktiv** (widerlegt fruehere Vermutung), Tailnet `taild9fcf2.ts.net`, Geraete-Snapshot + Dubletten-Hinweis. WAN-Failover und Gast-/IoT geschaerft. `zu messen`-Platzhalter entfernt. **`Tailscale-Inventar messen` damit geschlossen.**
+- `ops/maintenance/check-unraid-flash-backup.sh` neu: read-only Validierung des Flash-Artefakts (sha256, Frische, Kern-Configs, keine Extraktion). Am 2026-06-05 gegen den Host getestet: Exit 0, sha256 OK, 390 Eintraege, 8/8 Kern-Configs. `docs/RESTORE_MATRIX.md` mit Testdatum/Ergebnis aktualisiert. **Artefakt-Validierung des Unraid-Flash-Backups damit erledigt; nur Stick-Boot-Test offen.**
+- `docs/FAMILY_ONBOARDING.md`: Michi-Checkliste in eine echte Erste-Termin-Checkliste (Vorbereitung, Reihenfolge, Erfolgskriterium, bewusst spaeter) umgebaut.
+- `docs/MASTER_TODO.md` in vier Status-Kategorien (Aktiv / Operator-Entscheidung / Geparkt / Extern blockiert) umstrukturiert.
+- `baerchen` Veeam-Erstbackup: erster Full-Lauf 2026-06-05 erfolgreich geschrieben (Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSS `job: success`). Beleg in `ops/windows-reinstall/docs/windows-image-backup-baseline.md`; Veeam Storage Encryption war im ersten Lauf nicht aktiv und ist als Operator-Entscheidung nachgezogen.
+- Docker Critical Events Watcher auf Unraid aktiviert: Host-Clone auf Commit `2f3d184` aktualisiert, User Script `/boot/config/plugins/user.scripts/scripts/docker-critical-events-at-start/script` auf den Supervisor umgestellt, altes Script als `script.bak-20260605-232621` gesichert, `schedule.json` zeigt `frequency: start`, Watcher laeuft mit PID `1681168`. ntfy-Smoke am 2026-06-06 erfolgreich beim Operator angekommen.
+- Restore-Test AdGuard Home: automatisierter Test `ops/restore-tests/adguard-restore-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Borg-Config-Restore aus Archiv `Taegliche-Sicherung-2026-06-06T04:30:05.910`, isolierter Container `restoretest-adguard`, HTTP `/control/status` = `401`, DNS-Smoke `git.kaleschke.info -> 192.168.178.58`, 7 Filterlisten-Eintraege, Report `/mnt/user/backups/restore-reports/adguard-2026-06-06.md`.
+- Restore-Test Redis 8: automatisierter Test `ops/restore-tests/redis-restore-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: Restore aus `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011`, isolierter Container `restoretest-redis`, `PING` = `PONG`, Redis `8.8.0`, AOF `1`, `DBSIZE` = `1`, Report `/mnt/user/backups/restore-reports/redis-2026-06-06.md`.
+- **Tailscale ACL-Policy restriktiv ausgerollt (2026-06-06):** Von Default-Allow auf Tag-basierte `grants`-Policy umgestellt, gemeinsam mit dem Operator in lockout-sicherer Reihenfolge (additiv -> taggen -> Allow-all entfernen), jeder Schritt read-only per SSH verifiziert. Live: `kallilabcore`=`tag:server`, `baerchen-1`+`iphone-14`=`tag:operator`, `tag:family` vorbereitet/schlafend. Subnet-Route `192.168.178.0/24` bleibt via `autoApprovers` approved. Smoke-Tests gruen (Operator-SSH, AdGuard-Admin `HTTP 302` ueber Tailnet, Ping 0%); untagged Nodes (`kallilab-core` Docker-Sidecar, alter `baerchen`) isoliert. Beleg: `docs/NETWORK_INVENTORY.md` Abschnitt "ACL-Policy — ANGEWENDET 2026-06-06". Familien-Dienste konkretisieren bei erstem realem Familiengeraet.
+- **Redundanten Docker-Tailscale-Stack entfernt (2026-06-06):** Befund: Host hatte zwei `tailscaled` — die funktionale native Plugin-Instanz `kallilabcore` (echtes TUN `tailscale1`, Subnet-Router, State im Flash-Backup) und den redundanten userspace-only Docker-Stack `kallilab-core` (`host-services/tailscale/`, routet nichts, nichts haengt dran). Sauber per GitOps abgebaut: Operator hat Komodo-Stack `tailscale` gestoppt+destroyed; danach `git rm host-services/tailscale/`, Glance-Widget entfernt, Architektur-/Service-Catalog-/DR-Bootstrap-/CLAUDE-/Restore-Matrix-/Netzwerk-Doku auf "natives Plugin" nachgezogen. Read-only verifiziert: Container weg, nur noch der native `tailscaled`, Subnet-Route + Operator-Zugriff intakt. Rest: tote Node-Eintraege in der Admin-Konsole entfernen (eigener Todo).
+
+- DR-Workstation Bare-Metal-Kit abgeschlossen: WSL2 Ubuntu 24.04 auf `baerchen`, Borg 1.2.8, GitHub-Read-DR-Key und Hetzner-DR-Key in WSL, `~/dr-smoke.sh` vorhanden. Finaler Smoke 2026-06-06 erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar, Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. Passphrase wurde nur interaktiv eingegeben und nicht gespeichert.
+- Restore-Frische-Negativtest validiert: `ops/restore-tests/negative-freshness-alert-test.sh` erstellt und am 2026-06-06 auf Unraid erfolgreich ausgefuehrt. Ergebnis: synthetischer leerer Dump-Pfad erzeugte erwartungsgemaess 10 Criticals, Test-Alert nach `homelab-alerts` gesendet, Report `/mnt/user/backups/restore-reports/freshness-negative-2026-06-06-130320.md`, produktive Dumps unangetastet.
+- Gast-/IoT-Netz aktiviert und validiert: FRITZ!Box-Gastzugang `Fritzi Gastzugang` aktiv, Heimnetz-Zugriff aus dem Gastnetz blockiert. LAN- und Host-Preflight gruen; iPhone-Smoke aus dem Gast-WLAN bestaetigt, dass `192.168.178.58:8082`, `:8181`, `:222`, `https://192.168.178.58` und `192.168.178.1` nicht erreichbar sind. Runbook: `docs/GUEST_IOT_NETWORK.md`.
+- `baerchen` Veeam-Recovery-Test ohne echten Restore abgeschlossen: Recovery-USB `VEEAMRE` bootet, SMB-Ziel `\\kallilabcore\backups\windows-images\baerchen` ist in der Recovery Environment erreichbar, Restore Point wird angezeigt, Test vor echtem Restore abgebrochen. Runbook: `ops/windows-reinstall/docs/windows-image-backup-baseline.md`.
+- **Operator-Entscheidungen 2026-06-06 abgeschlossen** (Liste damit ohne offene Entscheidungen):
+  - **BitLocker `baerchen`: bewusst deaktiviert.** Recovery laeuft ueber Veeam-Image; kein BitLocker-Key-Management. Restrisiko physischer Diebstahl bewusst akzeptiert.
+  - **Veeam Storage Encryption: bewusst unverschluesselt.** Erster Full-Lauf bleibt; Image liegt auf dem lokalen SMB-Share `\\kallilabcore\backups`. Neu bewerten bei Off-host-Auslagerung des Images.
+  - **Stromverbrauch: bewusst ohne Messung.** Kein Messgeraet; Werte bleiben dauerhaft offen, kein Beschaffungs-Todo mehr.
+  - **Authelia Rest-2FA: KOMPLETT erledigt 2026-06-06.** Catch-all `*.kaleschke.info` -> `two_factor` in Repo **und** Host-Config (chirurgische Einzelzeilen-Aenderung mit Backup, OIDC-Beszel-Client + Secret unangetastet), `docker restart authelia` -> healthy + "Startup complete", Operator-2FA-Login auf einer vorher-1FA-Domain verifiziert. Nebenbei vorbestehenden Drift gefunden+bereinigt (Host-Config war vom 25. Mai, borg/code nie gemerged); Repo-Baseline an Host-Endzustand angeglichen, damit `authelia-diff.sh` clean wird sobald der Host-Mirror nachzieht. Rollback-`.bak` auf dem Host vorhanden.
+  - **Authelia OIDC: angehen** (neuer aktiver Block) — **Gast-/IoT-Netz: einrichten/planen** (neuer aktiver Block) — **Nextcloud 2FA: geparkt** bis OIDC die App-Login-Ebene erreicht.
+
+---
+
+## Pflege-Regel
+
+- Neue operative To-dos zuerst hier eintragen oder aus Detaildokumenten hierher uebernehmen, immer mit Status-Kategorie.
+- Wenn ein Punkt erledigt ist, in der Detaildoku den Beleg/Report eintragen und diese Liste aktualisieren.
+- Keine vagen "pruefen"-Eintraege ohne Kommando oder Entscheidung.
+- Historische Drill-Reports bleiben Belegmaterial, aber nicht die fuehrende Arbeitsliste.

docs/MIGRATION_LOG.md

@@ -1,613 +0,0 @@
-# Migration Log - Homelab GitOps
-
-Dieses Dokument ist nur noch ein historischer Verlauf. Der aktuelle operative Ablauf steht in `docs/WORKFLOW.md`, das Zielbild in `HOMELAB_ARCHITECTURE_MASTER_V2.md`.
-
-## Aktueller Endstand
-
-- Gitea Online ist der verbindliche Sollzustand.
-- Komodo ist der einzige produktive Stack-Manager.
-- Portainer CE ist entfernt.
-- Firefly, Firefly-Fints und Semaphore sind entfernt.
-- `monitoring/` ist der einzige aktive Observability-Stack; alte Repo-Pfade `ops/grafana-influxdb` und `ops/loki` sind entfernt.
-- Borg UI ist produktiv, Dump-Automatisierung laeuft host-seitig und ein Restore-Smoke-Test wurde erfolgreich durchgefuehrt.
-- GitHub Desktop ist der bevorzugte lokale Workflow fuer `Fetch`, `Pull`, `Commit` und `Push`.
-- Mutable Image-Tags sind auf die aktuell laufenden Digests eingefroren.
-
----
-
-## Historische Meilensteine
-
-### 2026-05-30 - Komodo-Bootstrap-Trockenlauf Erstlauf (F-09 Rest abgeschlossen)
-
-Skript ist seit 2026-05-29 vorbereitet, heute erster echter Lauf auf dem Host.
-
-- Aufruf: `bash /mnt/user/services/homelab-infra/ops/restore-tests/komodo-bootstrap-test.sh --keep-data`
-- Vorlauf: `--what-if` zur Plan-Verifikation, danach echter Lauf, beides ohne Eingriff in den produktiven Komodo-Stack.
-- Ergebnis: `SUCCESS`, alle 5 Smoke-Checks gruen.
-  - `docker compose config valid: ok`
-  - `Test-Mongo healthy: ok` (Mongo healthy in ~6 s)
-  - `Mongo authenticated ping (Test-Creds): ok`
-  - `Komodo Core HTTP status: 200` (Login-Seite ausgeliefert)
-  - `Test-Periphery container state: running`
-- Report: `/mnt/user/backups/restore-reports/komodo-bootstrap-2026-05-30.md`
-- Isolation hielt wie geplant: produktive Container `komodo-mongo`, `komodo-core`, `komodo-periphery` unter Project `komodo` blieben unangetastet, ebenso `/mnt/user/appdata/komodo/{mongo,core,periphery}` und die produktiven `KOMODO_*`-Secrets. Test lief unter Project `restoretest-komodo` mit Wegwerf-Datadir `/mnt/user/backups/restore-lab/komodo/`, Wegwerf-Secrets im Test-Compose und Test-Port nur auf `127.0.0.1:19120`.
-- Operator-Klick bewusst nicht von Claude uebernommen: `ssh root@kallilabcore` ist eine Aktionsklasse, die in CLAUDE.md ausdruecklich Operator-Anweisung verlangt. Der Auto-Mode-Classifier hat einen nicht-destruktiven SSH-Probe entsprechend blockiert. Der Operator hat den Befehl im Unraid-Webterminal selbst gestartet.
-- Bedeutung: `ops/komodo/docker-compose.yml` ist als Recovery-Anker fuer die Bootstrap-Stufen A-F in `docs/SERVICES_RECOVERY.md` jetzt **belegt** tauglich, nicht mehr nur angenommen tauglich. Image-Digests (mongo:7.0.32, komodo-core:2, komodo-periphery:2) und Mongo-Auth-Schema sind verifiziert.
-- Lab-Daten unter `/mnt/user/backups/restore-lab/komodo/` bleiben mit `--keep-data` erhalten, Test-Container wurden im EXIT-Trap sauber abgeraeumt. Operator entscheidet, ob das Lab-Verzeichnis (~300 MB) entfernt wird.
-
-Folgeschritt fuer `docs/RESTORE_DRILL_ROUTINE.md`: Komodo-Bootstrap-Trockenlauf passt zum quartalsweisen DR-Sanity-Check (Q4) oder als wiederholbarer Standalone-Drill. Aktuell kein Host-Schedule, Aufruf bleibt manuell.
-
-### 2026-05-30 - F-10: Authelia Repo<->Host Drift-Check
-
-Der dokumentierte "by-design"-Drift zwischen `security/authelia/configuration.yml` (Repo-Baseline) und `/mnt/user/appdata/authelia/config/configuration.yml` (Host) wird jetzt automatisch ueberwacht. Vorher: Manueller Merge auf den Host war Pflicht, aber keine Pruefung. Eine vergessene ACL-Synchronisation waere erst bei einem Login-Fehler aufgefallen.
-
-- Neues Skript `services/authelia-diff.sh`: extrahiert die `access_control:`-Sektion aus beiden YAMLs per awk-Block-Extractor (Top-Level-Key bis zum naechsten Top-Level-Key), normalisiert Kommentar- und Leerzeilen, vergleicht via `diff -u`. Default-Sektion ist `access_control`, weil das laut F-10 der primaere Drift-Vektor ist; per env `AUTHELIA_DIFF_SECTIONS` koennen weitere Top-Level-Sektionen (`session`, `regulation`, `totp`, ...) ergaenzt werden. OIDC-Clients, Identity-Provider und Secret-Werte bleiben bewusst aussen vor.
-- Exit-Code-Schema: 0 = ok, 1 = Drift (Diff auf stdout), 2 = Datei fehlt, 3 = Sektion fehlt, 4 = Werkzeug fehlt. Macht das Skript auch standalone nutzbar (`ssh kallilab "bash /mnt/user/services/homelab-infra/services/authelia-diff.sh"`).
-- `services/posture-check/posture-check.sh` ruft das Skript am Ende des Checks-Blocks auf (`check_authelia_config_drift`). Drift wird als **Warning** gemeldet, nicht Critical, weil die produktive Authelia trotz Drift weiter laeuft und die ACL fuer schon angemeldete Sessions weiter wirkt. Skip-Mechanismus: `SKIP_AUTHELIA_DRIFT=1`. Pfad-Override: `AUTHELIA_DIFF_SCRIPT`.
-- Pflicht-Setup auf dem Host: Repo-Spiegel unter `/mnt/user/services/homelab-infra/` als read-only-Clone von Gitea `Micha/homelab-infra` mit regelmaessigem `git pull --ff-only`. Default-Pfade des Skripts setzen das voraus. Ohne Repo-Spiegel meldet der Check Warning, weil die Baseline-Datei fehlt - keine stille Inaktivierung.
-- Lokaler Smoke-Test 2026-05-30 erfolgreich: identische Files -> rc=0; ACL-Drift im Domain-Eintrag `scrutiny.kaleschke.info -> scrutiny-renamed.kaleschke.info` -> rc=1 mit unified diff, ACL-Block korrekt extrahiert, Kommentar- und Leerzeilen rausgefiltert. False-Positive auf `session.default_redirection_url`-Aenderung korrekt vermieden (gehoert nicht zu `access_control`).
-- `docs/WORKFLOW.md` hat jetzt eine eigene Sektion "Ausnahme: Authelia configuration.yml" analog zur Traefik-Dynamic-Sektion. Pflicht-Workflow: 1. Repo-Aenderung + Commit + Push, 2. manueller Merge in die Host-Datei mit Erhalt der OIDC-Sektionen, 3. `docker restart authelia` + Login-Smoke-Test, 4. `services/authelia-diff.sh` muss `exit 0` liefern.
-- `docs/REPO_MAP.md` und `docs/SERVICE_CATALOG.md` zeigen das Skript und den neuen Posture-Check-Eintrag.
-
-Operator-Folgeschritt (klein, nicht heute): Repo-Spiegel `/mnt/user/services/homelab-infra/` auf dem Host einrichten und in den vorhandenen `gitea-bundle-mirror-6h`-Plan oder einen eigenen 6h-Cron einbinden, damit das Skript einen aktuellen Vergleichsstand findet.
-
-### 2026-05-29 - Stack-Hygiene Sprint: Healthchecks, Monitoring-Digests, Komodo-Bootstrap-Skript, Renovate-Vorbereitung
-
-Vier Audit-Punkte am Stueck abgearbeitet. Pro Block: Live-Verifikation am Host, Doku im Repo.
-
-**F-15 Tier-1 Healthchecks**
-
-- 6 Tier-1-Stacks bekommen Healthchecks: postgresql17 (`pg_isready`), Redis (`redis-cli ping` mit Auth aus dem mount), Vaultwarden (`curl /alive`), Gitea (`wget /api/healthz`), Traefik (`traefik healthcheck --ping`, vorher `--ping=true` in CLI aktiviert), Authelia (`wget /api/health` - Authelia v4.39 hat `helper health-check` entfernt, daher direkter Endpoint).
-- Erste Iteration in Vaultwarden + Authelia schlug fehl: Vaultwarden hat kein `wget`, Authelia kennt das `helper`-Subcommand nicht mehr. Probe per `docker exec` zeigte: Vaultwarden hat `curl`, Authelia hat `wget`. Compose entsprechend nachgezogen, zweiter Lauf gruen.
-- Komodo-Stack-Workspaces fuer `postgresql17` (124 commits behind) und `gitea` (52 commits behind) wurden Komodo-seitig nicht automatisch gepullt. Manuell ueber `git pull --ff-only` plus `cp` der aktuellen Compose-Datei aus dem Host-Repo-Clone in den Stack-Workspace synchronisiert, dann `docker compose up -d`. Gitea-Workspace hatte zusaetzlich untracked Doku-Files; nur die im aktuellen Master tracked-en Files entfernt, nicht via `git clean -fd`. Workspace-Drift selbst ist nicht heute Auftrag, aber als Folge-Befund notiert.
-- Endstand Live: alle 6 Healthchecks `healthy`.
-
-**F-07 Monitoring-Stack Digest-Pinning**
-
-- 9 Container in `monitoring/docker-compose.yml` per Tag@sha256 gepinnt (prometheus, alertmanager, alertmanager-ntfy-bridge, blackbox-exporter, loki, promtail, grafana, node-exporter, cadvisor; plus zweiter python:3.13-alpine im Bootstrap-Dashboard-Importer). InfluxDB war bereits gepinnt.
-- Digests aus den laufenden Containern per `docker inspect ... .Config.Image` + `docker image inspect ... .RepoDigests` ausgelesen, damit die Pins exakt dem Live-Stand entsprechen.
-- Kein Recreate ausgeloest, weil die Images identisch sind; nur die Compose-Datei ist jetzt reproduzierbar wie die Tier-1-Stateful-Stacks.
-
-**F-09 Rest - Komodo-Bootstrap-Trockenlauf-Skript**
-
-- `ops/restore-tests/komodo-bootstrap-{compose.test.yml,test.sh,plan.md,runbook.md}` analog zum Immich-Restore-Test-Muster angelegt.
-- Test-Compose nutzt dieselben Image-Digests wie Produktion (mongo:7.0.32, komodo-core:2, komodo-periphery:2), isoliert unter Compose-Project `restoretest-komodo`, Test-Port nur `127.0.0.1:19120`, **Test-Periphery ohne docker.sock-Mount und ohne `/mnt/user/services`-Mount** - kann produktive Container nicht managen.
-- Wegwerf-Secrets sind im Compose hardcodiert, produktive `KOMODO_*`-Werte werden nicht beruehrt.
-- Smoke-Test-Kriterien: docker compose config valid, Mongo healthy, Mongo Auth-Ping ok, Core HTTP 200/302/303/401, Periphery container `running`.
-- Erster Lauf bleibt manueller Operator-Schritt.
-
-**F-12 Renovate-Bot (live)**
-
-- Repo-Config in `renovate.json` (Repo-Root): nur extends, packageRules, ignorePaths, manager file patterns, labels, rangeStrategy. Bot-Config separat in `ops/renovate/bot-config.js`: platform, endpoint, autodiscover=false, repositories=["Micha/homelab-infra"], gitAuthor, Concurrent-Limits. Trennung war noetig: Renovate liest die `renovate.json` im Repo als REPO-Config; Bot-Felder darin wurden als "this repo is disabled" fehlinterpretiert (Repository result: forbidden, status: disabled).
-- `ops/renovate/run-renovate.sh` als One-Shot-Container-Wrapper. Wichtige Haertungen waehrend des Setups:
-  - `--add-host git.kaleschke.info:192.168.178.58`: Renovate-Container kann den Hostname sonst nicht aufloesen (`EAI_AGAIN`). Analog zur `extra_hosts`-Loesung in der Komodo-Compose.
-  - `--env-file` statt `-e RENOVATE_TOKEN=...`: Token war sonst in `ps` und `docker inspect` sichtbar.
-  - `chmod 0777` auf `/mnt/user/services/renovate/state`: Renovate-Image laeuft als uid 12021 (ubuntu), kann root-owned Mount sonst nicht beschreiben.
-- Live-Setup am Host:
-  - Service-Account `renovate` (uid 2, **kein Admin**) ueber `gitea admin user create` angelegt.
-  - Collaborator-Status mit Write-Permission auf `homelab-infra` (initialer DB-Insert hat den Gitea-Permissions-Cache nicht aktualisiert; Renovate sah `permissions.push=false` und brach mit "Repository does not permit pull or push" ab; saubere Loesung war Operator-UI-Klick "Entfernen + neu hinzufuegen", was den Cache konsistent aktualisiert; Befund-Bestaetigung via Doku-Studium `lib/modules/platform/gitea/index.ts`: die Push-Check ist hardcoded, kein Bypass moeglich).
-  - Personal-Access-Token mit Scopes `read:user,write:repository,write:issue`, in `/mnt/user/appdata/secrets/renovate_token.txt` (chmod 600). Token wurde einmal rotiert, weil der Wert beim ersten Erzeugen im SSH-Output sichtbar war.
-  - User-Script `renovate-six-hourly` mit Cron `20 */6 * * *` live in `/etc/cron.d/root`.
-- Erstlauf 2026-05-29 erfolgreich: 5 PRs (mongo digest, mongo 7.0.32->7.0.34, postgres digest, postgres 17.9->17.10, minor-and-patch-updates gruppiert), 1 Issue "Renovate Dependency Dashboard", 8 Branches (drei Major-Branches warten auf naechsten Lauf wegen prConcurrentLimit=5). Komodo-Major-Updates wurden korrekt durch packageRule unterdrueckt.
-- `docs/RENOVATE.md` zeigt die ursprueglichen 5 Operator-Schritte fuer Neuaufsetzen bzw. Disaster Recovery.
-
-### 2026-05-29 - Borg-Source `/local/appdata/homepage` verspaetet entfernt + Removal-Checkliste in WORKFLOW
-
-- Befund aus den ersten Tagen scharfer Alert-Pipeline: `HomelabBorgLastJobCompletedWithWarnings` firing fuer die letzten vier Borg-Laeufe (26.05.-29.05.), jeweils Exit-Code 107.
-- Ursache im Borg-UI-Logfile `backup_job_39_*.log`: `"/local/appdata/homepage: stat: [Errno 2] No such file or directory"`. Borg-UI-Source-Liste enthielt seit der Homepage-Entfernung am 25.05. weiterhin den Eintrag `/local/appdata/homepage`; der Appdata-Pfad war aber bereits nach `_archive/homepage-removed-2026-05-25/` verschoben.
-- Operator hat den Eintrag in der Borg-UI manuell entfernt; Source-Liste jetzt 23 statt 24 Eintraege, `homepage` nicht mehr drin. Naechster Borg-Lauf 2026-05-30 04:30 sollte wieder `completed` ohne Warning sein.
-- Backups waren nicht gefaehrdet: trotz Exit-Code 107 wurden alle anderen 23 Quellen sauber archiviert (Stats Job 39: 100.895 Dateien, 26.72 GB Original, 317 MB deduplicated).
-- Erkenntnis: bei Stack-Removal wurde die Borg-Source-Liste damals nicht mit-aufgeraeumt. **`docs/WORKFLOW.md`** um neuen Abschnitt "Service-Removal-Checkliste" erweitert, der die Borg-UI-Source-Bereinigung explizit als Pflichtschritt 8 nennt (zusammen mit allen anderen Schritten wie Komodo-Destroy, Gitea-Webhook, Authelia-ACL, Blackbox-Target, Doku).
-- Positiv-Befund: die ntfy-Push-Pipeline (Cron `*/5` Textfile-Export -> node-exporter -> Prometheus -> Alertmanager -> ntfy-Bridge), die am 2026-05-27 scharfgeschaltet wurde, hat den Drift binnen 24 h sichtbar gemacht. Das ist der intendierte Mechanismus.
-
-### 2026-05-28 - H:/-Pull als Windows Scheduled Task aktiviert
-
-- Task `KalliLab H Drive Nearline Pull` registriert auf dem Operator-Windows-PC: taeglich 05:30 (nach dem Borg-Dump-Fenster um ca. 04:00), `RunLevel Limited`, `AllowStartIfOnBatteries`, `DontStopIfGoingOnBatteries`, `StartWhenAvailable`, `ExecutionTimeLimit 2 h`. Naechster Lauf 2026-05-29 05:30.
-- Repo-Doku `docs/H_DRIVE_NEARLINE_PULL.md` Status auf "produktiv" gesetzt, Register-Snippet auf den tatsaechlich ausgefuehrten Befehl korrigiert (PowerShell-Enum `LeastPrivilege` -> `Limited`; alter Snippet haette beim ersten Aufruf einen Parameter-Binding-Fehler geworfen).
-- Verifikation am Windows-PC: `Get-ScheduledTask` zeigt State `Ready`, Trigger-Start 2026-05-28T05:30, RunLevel `Limited`.
-- Kein Eingriff am Host noetig; SMB-Quelle und H:/-Ziel waren bereits vorbereitet.
-
-### 2026-05-28 - Zweites Off-site bewusst nicht umgesetzt
-
-- Operator-Bewertung: 3-2-1-Regel ist mit aktueller Topologie erfuellt (Live + lokales Borg-Repo + Hetzner-Borg + H:/-Nearline = 4 Kopien / 3 Medien / 1 Off-site).
-- Ein zweites Off-site wuerde **ausschliesslich** das Szenario "Hetzner-Account verloren" zusaetzlich abdecken. Eintrittswahrscheinlichkeit niedrig (etablierter deutscher Anbieter, dokumentierter Zahlungsweg). Aufwand und Kosten unverhaeltnismaessig fuer Familien-Homelab.
-- Beschluss in `docs/OFFSITE_BACKUP_OPTIONS.md` mit Review-Triggern dokumentiert; F-03 in `docs/AUDIT_2026-05-25_TODO.md` von "offen" auf "erledigt (bewusst nicht umgesetzt)".
-- Stattdessen drei Folge-TODOs zur Haertung der bestehenden Topologie:
-  - Hetzner-Account-Hygiene: starkes Passwort + Backup-Zahlungsweg + Login-Benachrichtigungen. **Bewusst keine 2FA** (Operator-Entscheidung analog USV-Risiko-Akzeptanz).
-  - Borg `--append-only` auf Hetzner pruefen. Befund: Repo `appdata-critical` laeuft aktuell im Mode `full`, `custom_flags` leer. Setup waere server-seitig in Hetzner-`authorized_keys`.
-  - H:/-Pull als Windows Scheduled Task aktivieren (Skript und Doku ready, Erstlauf 2026-05-27 erfolgreich, Task selbst noch nicht angelegt).
-- Bewusst NICHT angefasst: laufende Backup-Pipeline (kein Test-Restore, kein Modus-Wechsel ohne Folge-Sprint).
-
-### 2026-05-28 - paperless-gpt und BentoPDF bewusst behalten
-
-- Befund: Beide Container laufen Up 3 days, aber **0 Traefik-Zugriffe in den letzten 7 Tagen** und kein User-LLM-Event in den paperless-gpt-Logs. BentoPDF-Logs zeigen ausschliesslich Docker-Healthchecks.
-- Resource-Footprint vernachlaessigbar: `paperless-gpt` 34 MB RAM, `bentopdf` 4 MB RAM, beide 0 % CPU.
-- Operator-Entscheidung 2026-05-28 (gegen die Nicht-Nutzung): **beide behalten**.
-  - `paperless-gpt`: bleibt aktiv bis Paperless-NGX 3.0 verfuegbar ist. Paperless 3.0 wird native KI-Features mitbringen; danach neu entscheiden, ob `paperless-gpt` noch noetig ist oder abgeloest werden kann.
-  - `bentopdf`: bleibt aktiv als situatives PDF-Werkzeug; Footprint zu klein, um eine harte Entfernung zu rechtfertigen.
-- Doku-Anker in `docs/SERVICE_CATALOG.md` ergaenzt, damit die Frage in 6 Monaten nicht erneut als "warum laeuft das?" auftaucht.
-
-### 2026-05-28 - Plex Server Reclaim und Remote Access deaktiviert
-
-- Befund beim Versuch, Remote Access in der Plex-UI zu deaktivieren: Plex-Server war seit 18.05.2026 13:18 nicht mehr mit einem Plex.tv-Account geclaimt. `Preferences.xml` 391 Bytes, ohne `PlexOnlineMail`/`PlexOnlineUsername`/`PlexOnlineToken`. Login als `Xeridos` lieferte "Keine Berechtigung" auf den lokalen Server. Zusaetzlich waren die `library_sections` leer (Backups vom 19./22./28.05. ebenfalls ~370 KB statt MBs); die Bibliotheks-Konfiguration war seit dem 18.05. weg. Filmdateien unter `/mnt/user/media/*` blieben unangetastet (833 Verzeichnisse, ~1.7 TB).
-- Reclaim als `Xeridos` durchgefuehrt: Operator-Token via `plex.tv/claim` erzeugt, am Host als Shell-Inline-ENV beim `docker compose up -d --force-recreate plex` mitgegeben. Token wurde **nicht** in `.env`, **nicht** in Compose, **nicht** in Komodo-Stack-ENV geschrieben. Nach Erfolg sauberer zweiter Recreate ohne Token, damit `docker inspect`-Snapshot keinen Token mehr enthaelt. Bash-History defensiv geleert.
-- Endstand laut `Preferences.xml`: `PlexOnlineUsername="Xeridos"`, `PlexOnlineMail="michideheld@gmx.de"`, `PlexOnlineHome="1"`, `PublishServerOnPlexOnlineKey="0"` (Remote Access aus).
-- Operator hat im Anschluss die Bibliotheken neu angelegt (`/data/movies`, `/data/Heimatfilme`) und Remote Access in der Plex-UI auf "deaktiviert" gesetzt; Metadata-Cache wuchs in den ersten 18 Minuten auf 630 MB.
-- Plex bleibt damit strikt LAN/Tailscale-only, konsistent zur FRITZ!Box-Bereinigung vom selben Tag. Smart-TVs (Schlaf-/Wohnzimmer) finden den Server ueber WLAN-LAN per mDNS/Plex-GDM unveraendert.
-- `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13 enthaelt die ausfuehrliche Recovery-Geschichte. `docs/SERVICE_CATALOG.md` und Sektion 7.4 auf "LAN/Tailscale-only, Remote Access aus" praezisiert.
-
-### 2026-05-28 - FRITZ!Box-Portfreigaben bereinigt
-
-- WAN-Soll auf eine einzige Freigabe reduziert: `443/tcp -> 192.168.178.58:443` (Traefik HTTPS).
-- `80/tcp` aus FRITZ!Box-UI entfernt. Validierung: Mobilfunk-Test ergibt Timeout auf `http://vault.kaleschke.info`, `https://vault.kaleschke.info` weiter erreichbar; lokal greift Traefik-Redirect 80->443 nach wie vor. Cloudflare-DNS-Challenge braucht kein Port 80.
-- `222/tcp` bleibt bewusst nicht eingerichtet. Begruendung: Tailscale ist Operator-Pfad, GitHub-Push-Mirror `michaelkaleschke-spec/homelab-infra` deckt Repo-Bootstrap-Pfad ab, Gitea-Bundles unter `/mnt/user/backups/git-bundles/gitea` decken Offline-Restore ab. `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 10 entsprechend mit "Tailscale-only, bewusst nicht WAN-freigegeben" praezisiert.
-- UPnP-Selbstfreigabe-Recht fuer `PC-192-168-178-71` (Hostname `VONETS.COM`, MAC `00:17:13:2F:61:96`) deaktiviert. Identifiziert als VONETS-WiFi-Bridge, vermutlich Bridge-Anbindung zum SolarEdge-Wechselrichter. SolarEdge-Cloud-Sync ist outbound und benoetigt keine UPnP. Aktuell waren 0 Selbstfreigaben aktiv; die Aenderung ist praeventiv gegen kuenftige Anforderungen.
-- `docs/NETWORK_INVENTORY.md`, `docs/FRITZBOX_PORT_CORRECTION_PLAN.md` und `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 entsprechend nachgezogen.
-- Bewusst NICHT angefasst: FRITZ!OS 8.21 Update (Service-Fenster), IPv6-Exposure (separater Folgeschritt), WAN-Ausfallschutz (bewusst aus).
-
-### 2026-05-27 - Monitoring-Alerts live, Gitea-Bundle-Cron live, H:/-Pull live
-
-Drei Audit-TODOs gleichzeitig auf "erledigt" gezogen; alle Aenderungen mit Host-Smoke verifiziert.
-
-**Monitoring-Alerts (Borg-Stale / Cert-Expiry / Container-Down)**
-
-- Auf dem Host neuer User-Script `export-prometheus-textfile-5min` mit Cron `*/5 * * * *` angelegt. Schreibt `/mnt/user/services/posture-check/textfile/homelab.prom`.
-- Repo: `services/posture-check/export-prometheus-textfile.sh` setzt jetzt vor dem `mv` per `chmod 644`, damit node-exporter (`nobody:65534`) lesen kann. Vorher `0600 root:root` → `node_textfile_scrape_error 1`.
-- `monitoring-prometheus` wurde einzeln per `docker restart` neu gestartet, um den `stale file handle` auf der gebundenen `alerts.yml` zu loesen. Kein Stack-Down. `promtool check rules` SUCCESS 14 rules, `lastConfigTime 2026-05-27T18:33:06Z`. Aktive Alerts: 1 firing (`HomelabTraefik5xx` aus dem 2026-05-20-Befund), 1 pending (`HomelabBorgLastJobCompletedWithWarnings` durch `completed_with_warnings`-Status des letzten Borg-Laufs).
-- Pipeline end-to-end: Textfile-Skript ⇒ node-exporter Textfile-Collector ⇒ Prometheus ⇒ alerts.yml-Regeln.
-
-**Gitea-Bundle-Schedule**
-
-- User-Script `gitea-bundle-mirror-6h` mit Cron `10 */6 * * *` (00:10/06:10/12:10/18:10).
-- Repo: `ops/borg-ui/scripts/gitea-bundle-mirror.sh` schreibt Bundles und Sidecars jetzt `chmod 644` statt `600`. Begruendung: Bundle-Inhalt ist Git-Historie ohne Secrets (durch `.gitignore` abgedeckt), nicht sensibler als die uebrigen 0644-Dumps. Damit funktioniert der Nearline-Pull ueber SMB.
-- Existierende Bundles wurden manuell auf 0644 angehoben. Erster Cron-Lauf 2026-05-27 18:41 UTC erfolgreich: 4 Bundles, Checksums OK.
-
-**H:/ Nearline-Pull**
-
-- Erster scharfer Lauf 2026-05-27 20:25 zeigte vier Permission-Befunde: `unraid-flash-config.*` (4 Files, by-design 0600), `filebrowser.bolt.dump` (0640, Source erbt), und alle 10 Gitea-Bundle-Files (0600).
-- Repo: `ops/h-drive-nearline/pull-critical-backups.ps1` excluded jetzt die `unraid-flash-config.*`-Familie ueber `/XF` (Restore-Quelle bleibt Hetzner-Borg). `ops/borg-ui/scripts/pre-backup-dumps.sh` setzt alle Dumps via `atomic_write` per Default auf 0644, Flash-Config-Familie explizit mit `atomic_write target tmp 600`.
-- Existierende Files am Host nachtraeglich auf 0644 angehoben.
-- Zweiter Lauf 2026-05-27 20:45: beide Robocopy-Jobs Exit 1, **19 Borg-Dumps + 10 Gitea-Bundle-Files** unter `H:\kallilab-nearline-backups`. Report-Tabellen-Quirk in PowerShell durch `& robocopy @args | Out-Null` behoben (Live-Output landete vorher in `$results`).
-- `docs/H_DRIVE_NEARLINE_PULL.md` mit Erstlauf-Befund, gefixter Erwartungs-Liste und expliziter Out-of-Scope-Anmerkung fuer Flash-Config aktualisiert.
-- Windows Scheduled Task taeglich 05:30 bleibt **bewusst** offen bis zur Operator-Bestaetigung.
-
-**Was bewusst NICHT angefasst wurde**
-
-- Authelia/OIDC/CrowdSec/Nextcloud-Haertung (geparkt).
-- Hermes (Review 2026-07-25).
-- USV (Risiko bewusst akzeptiert).
-- FRITZ!Box-/Plex-/UI-Punkte (Punkt 5 fuer morgen frueh).
-- `unraid-flash-config.tar.gz` bleibt bewusst 0600 und ausserhalb des Nearline-Scopes.
-
-### 2026-05-27 - Vorbereitungsdokumente FRITZ!Box-Korrektur und Off-site-Optionen
-
-- Reine Doku-Aenderung; kein Router-, Provider- oder Host-Eingriff.
-- `docs/FRITZBOX_PORT_CORRECTION_PLAN.md` neu angelegt: Korrektur-Plan fuer drei Punkte (`80/tcp` entfernen, `222/tcp` nicht ergaenzen solange Tailscale stabil, UPnP-Selbstfreigabe `PC-192-168-178-71` deaktivieren). Operator-Go ausstehend; jede UI-Aenderung wird gesondert dokumentiert.
-- `docs/OFFSITE_BACKUP_OPTIONS.md` neu angelegt: Entscheidungsvorlage fuer zweites Off-site-Ziel mit drei Optionen (rsync.net Borg-Plan, BorgBase EU2, rotierende Cold-Platte). Bewertung gegen Provider-Trennung, Standort, Preis und Konto-Risiko; Empfehlung rsync.net oder Cold-Platte; BorgBase EU2 explizit nicht empfohlen wegen gleichem Anbieter. Kein Provider gebucht, keine Kosten ausgeloest.
-- `docs/REPO_MAP.md` um beide neuen Dokumente ergaenzt.
-- `docs/AUDIT_2026-05-25_TODO.md` Sprint 4 (FRITZ!Box) und Sprint 7 (Off-site) mit Verweis auf die neuen Vorbereitungsdokumente nachgezogen.
-
-### 2026-05-27 - Doku-Sprint Bootstrap / Family-View / Onboarding / Drill-Routine
-
-- Reine Doku-Aenderung; kein Compose-, Secret-, Host- oder Router-Eingriff.
-- `docs/SERVICES_RECOVERY.md` "Komodo Bootstrap" auf linearen Stufenpfad A-F ausgebaut: Recovery-Anker bleibt `ops/komodo/docker-compose.yml`, Self-Stack ist explizit kein Anker, Secret-Restore-Reihenfolge verweist auf `docs/SECRETS_MAP.md` Stack-ENV-only-Sektion, Validierungs-Kommandos ergaenzt. Trockenlauf-Idee als Folgeaufgabe eingetragen, kein Repo-Skript dafuer.
-- `docs/DISASTER_RECOVERY.md` Phase 4 Stufe 3 verweist explizit auf den Bootstrap-Pfad in `docs/SERVICES_RECOVERY.md` und auf die Stack-ENV-only-Sektion in `docs/SECRETS_MAP.md`.
-- `docs/FAMILY_VIEW_DASHBOARD.md` neu angelegt: Spezifikation fuer `homelab-family-view`-Dashboard, 8 Panels (Endpoints up, Borg-Frische, Cert-Tage, Kritische Container, Disk-Fuellung, Endpoint-Tabelle, Cert-Tabelle, Container-Tabelle), PromQL-Queries, Thresholds, Build-Reihenfolge. Bewusst noch **kein** `monitoring/grafana/dashboards/family-view.json` angelegt, weil Borg-Stale-/Cert-Expiry-/Container-Down-Metriken laut Sprint 3 noch "in Arbeit" sind.
-- `docs/FAMILY_ONBOARDING.md` final redigiert: Status auf "Final-Stand vor Wochenend-Einladung", 2FA-Beschreibung auf App-eigene 2FA praezisiert (kein SSO-Versprechen, weil Authelia-OIDC weiter geparkt ist), neuer "Bewusst nicht versprochen"-Block (kein Einheits-Login, kein 24/7-SLA, kein Hotline-Support, keine Datenweitergabe).
-- `docs/RESTORE_DRILL_ROUTINE.md` neu angelegt: Drei-Stufen-Modell (Freshness woechentlich / Mini-Restore monatlich-bimonatlich / DR-Sanity quartalsweise), Quartals-Kadenz Q1-Q4 mit Dienst-Rotation, bestaetigte Mini-Restores (Vaultwarden, Gitea, Paperless 2026-05-07; Immich 2026-05-27), 10-Punkte-Sanity-Check, Abbruch-Regel mit Verweis auf `docs/GITOPS_DRIFT_RUNBOOK.md`. Kein Host-Schedule angelegt, nur Doku.
-- `ops/restore-tests/schedule.md` verweist jetzt auf `docs/RESTORE_DRILL_ROUTINE.md` als Quelle der Quartals-Belegung.
-- `docs/REPO_MAP.md` um `docs/FAMILY_VIEW_DASHBOARD.md`, `docs/RESTORE_DRILL_ROUTINE.md` und `docs/IMMICH_RESTORE_TEST.md` ergaenzt.
-- `docs/AUDIT_2026-05-25_TODO.md` aktualisiert: Sprint 2 "Komodo-Bootstrap-Pfad beschreiben", Sprint 3 "Family-View Dashboard definieren", Sprint 4 "Familien-Onboarding schreiben" und Sprint 7 "Restore-Lab-Drill quartalsweise dokumentieren" jeweils auf "erledigt".
-- Geparkte Punkte bleiben unveraendert: Authelia-2FA/OIDC/CrowdSec, Nextcloud-Haertung, Hermes (Review 2026-07-25), USV-Anschaffung.
-
-### 2026-05-27 - Immich Restore-Smoke-Test praktisch verifiziert (F-11)
-
-- Erster echter Immich-Restore-Smoke-Test gegen das produktive Borg-Archiv erfolgreich: `Tägliche-Sicherung-2026-05-27T04:30:06.778`, Report `/mnt/user/backups/restore-reports/immich-2026-05-27.md`.
-- Validiert wurden Borg-Extract von `local/borg-dumps/latest/immich.dump`, Import in isolierten `tensorchord/pgvecto-rs:pg14-v0.2.0` Test-Postgres, Start des Immich-Servers ohne ML und ohne Traefik, HTTP `200` auf `127.0.0.1:12283`, Login-Marker, `11977` Assets und `1` User im Test-DB-Check.
-- Produktive Container und produktive Foto-Pfade wurden nicht angefasst; Testdaten und Testcontainer wurden nach Erfolg bereinigt.
-- Im Lauf wurden Restore-Test-Haertungen umgesetzt: Borg-`known_hosts` aus `/data/known_hosts` wird fuer SSH-Trust genutzt, `completed_with_warnings`-Archive gelten als verwendbare Restore-Quelle, Postgres-Startfenster werden retry-faehig behandelt, Immich-v2-Upload-Marker werden im leeren Test-Mount erzeugt und Smoke-Checks schlagen bei HTTP-/Marker-Fehlern hart fehl.
-- `docs/IMMICH_RESTORE_TEST.md`, `docs/RESTORE_MATRIX.md`, `ops/restore-tests/schedule.md` und `docs/AUDIT_2026-05-25_TODO.md` nachgezogen; F-11 ist damit abgeschlossen. Voll-Restore inklusive Foto-Dateien bleibt ein separater DR-Drill.
-
-### 2026-05-27 - FRITZ!Box-Portfreigaben gegen Repo-Soll abgeglichen
-
-- FRITZ!Box-UI `Internet -> Freigaben -> Kallilabcore` geprueft: aktiv sind `HTTP-Server` TCP `80/tcp` und `HTTPS-Server` TCP `443/tcp` auf `192.168.178.58`.
-- Repo-Soll aus `docs/NETWORK_INVENTORY.md` ist nur `443/tcp` plus optional gewolltes Gitea-SSH `222/tcp`. Der aktuelle Zustand weicht ab: `80/tcp` ist offen, `222/tcp` fehlt.
-- Kallilabcore ist nicht als Exposed Host markiert und erlaubt keine selbststaendige Portfreigabe. `PC-192-168-178-71` erlaubt selbststaendige Portfreigabe, hat aber `0 aktiv`.
-- Keine FRITZ!Box-Aenderung vorgenommen. Router-Korrektur bleibt ein produktiver Operator-Schritt nach ausdruecklicher Freigabe.
-
-### 2026-05-26 - Immich Restore-Smoke-Test vorbereitet (F-11)
-
-- `docs/IMMICH_RESTORE_TEST.md` und `ops/restore-tests/immich-plan.md`/`immich-runbook.md` beschreiben den geplanten Immich-Mini-Restore: `immich.dump` aus Borg, isolierter pgvecto-rs-Test-Postgres, Test-Redis, Immich-Server ohne ML, lokaler Port `127.0.0.1:12283`, keine produktiven Foto-Mounts.
-- `ops/restore-tests/immich-restore-test.sh`, `immich-restore-test.ps1` und `immich-compose.test.yml` wurden vorbereitet; der Dispatcher kennt `immich --what-if`.
-- Lokal verifiziert: Bash-Syntax, `run-restore-checks.sh immich --what-if`, PowerShell-Dispatcher `-Mode immich -WhatIf`, Docker-Compose-Render und Policy-Check. Kein echter Host-Restore, kein Borg-Extract, kein Produktiv-Container-Eingriff.
-- Host-Preflight 2026-05-27: Host-Clone per Fast-forward auf `c5d231a`, `immich.dump` 66M, `/mnt/user/backups` ca. 3.7T frei, `run-restore-checks.sh immich --what-if` erfolgreich. Kein echter Restore-Lauf.
-- F-11 bleibt fachlich offen bis zum ersten Host-Lauf mit Report unter `/mnt/user/backups/restore-reports/immich-YYYY-MM-DD.md`.
-
-### 2026-05-27 - H:/ Nearline-Pull vorbereitet
-
-- `docs/H_DRIVE_NEARLINE_PULL.md` und `ops/h-drive-nearline/pull-critical-backups.ps1` definieren den Windows-seitigen Pull von `\\192.168.178.58\backups\borg\dumps\latest` und `\\192.168.178.58\backups\git-bundles\gitea` nach `H:\kallilab-nearline-backups`.
-- SMB-Quelle `\\192.168.178.58\backups` und H:/ sind erreichbar; `-WhatIf` prueft den Plan ohne Kopie.
-- Kein Scheduled Task angelegt und kein echter Kopierlauf gestartet. Empfohlen ist taeglich 05:30 nach dem Borg-Dump-Fenster, Aktivierung erst nach Operator-Sichtpruefung.
-
-### 2026-05-27 - Storage Layout als Active v1.4 gefuehrt
-
-- `docs/STORAGE_LAYOUT.draft.md` wurde zu `docs/STORAGE_LAYOUT.md` umbenannt. Das Dokument war inhaltlich bereits als Active markiert; Version 1.4 entfernt den formalen Draft-Blocker.
-- Physikalische Disk-Werte aus `docs/HARDWARE_INVENTORY.md` und Host-Readout uebernommen: Cache Samsung 970 EVO Plus 1.8T XFS, Disk1 WDC WD60EFAX 5.5T XFS auf `md1p1`, Parity TOSHIBA HDWG480 7.3T, Boot Samsung Flash Drive 59.8G FAT32, H:/ als Nearline-Ziel.
-- `docs/AUDIT_2026-05-25_TODO.md` Sprint 2 fuer Storage-Layout und Disk-/Share-Baseline auf erledigt gesetzt. Retention-Kalibrierung, Monitoring-Schwellen und RESTORE_MATRIX-Detailklassifikation bleiben normale Folgeaufgaben.
-
-### 2026-05-27 - F-08 Alert-Regeln vorbereitet
-
-- `services/posture-check/export-prometheus-textfile.sh` erzeugt Textfile-Metriken fuer Borg-Backup-Frische und kritische Container unter `/mnt/user/services/posture-check/textfile/homelab.prom`.
-- `monitoring/docker-compose.yml` aktiviert den Node-Exporter-Textfile-Collector. `monitoring/prometheus/alerts.yml` enthaelt vorbereitete Alerts fuer Borg-Stale, Borg-Fehlerstatus, Borg-Warnstatus, Textfile-Stale, Critical-Container-Down und TLS-Cert-Expiry 21/7 Tage.
-- Host-Smoke 2026-05-27: Skript erzeugt `homelab.prom`, alle gelisteten kritischen Container melden `1`, Borg-Status ist `completed_with_warnings` und wird als Warning statt Critical modelliert.
-- Kein Monitoring-Redeploy und kein Scheduled Task in diesem Schritt. Abschluss erfolgt nach Host-Schedule, Prometheus-Reload und Testalert.
-
-### 2026-05-26 - Audit F-16 und F-20 abgeschlossen (Doku-only)
-
-- F-16: `infra/redis`-Etikett auf die Realitaet abgeglichen. `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md`, `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 13 und `docs/DISASTER_RECOVERY.md` Bootstrap-Stufe 2 beschreiben Redis jetzt als "primaer Paperless-Redis (App-Cache); historisch als shared angelegt, faktisch nur von Paperless genutzt". Immich, Nextcloud, Mealie eigene Redis-Instanzen; Authelia bewusst ohne Redis. Keine Compose-Aenderung.
-- F-20: Restore-Wege fuer Stack-ENV-only Secrets explizit gemacht. Neuer Abschnitt `6.2.1 Restore-Quellen fuer Stack-ENV-Werte` in `docs/DISASTER_RECOVERY.md` (Reihenfolge Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz, Komodo-Sonderfall, Paperless als Hauptanwendung). Neuer Abschnitt `Stack-ENV-only Secrets - Restore-Wege` in `docs/SECRETS_MAP.md` mit Tabelle je Stack (Paperless, Immich, Mail-Archiver, Speedtest, Komodo, Hermes, Glance). Glance-Widget-Tokens explizit als rebuildbar markiert. Konkrete Werte werden nirgendwo dokumentiert.
-- `docs/AUDIT_2026-05-25_TODO.md` Sprint 6 entsprechend auf "erledigt" gestellt.
-- Kein Eingriff in `ops/borg-ui/scripts/gitea-bundle-mirror.sh`, kein Gitea-Bundle-Trockenlauf, keine SSH-/Host-Pruefung.
-
-### 2026-05-26 - FRITZ!Box-/H:/-/Family-Onboarding-Doku-Update
-
-- `docs/NETWORK_INVENTORY.md` mit FRITZ!Box-Baseline gefuellt: FRITZ!Box 7590, FRITZ!OS 8.21 (Update gemeldet, nicht eingespielt), Telekom DSL ~87/36 Mbit/s, 36 aktive Heimnetz-Geraete, LAN 1-4 verbunden, WLAN `Fritzi`, Gast-WLAN inaktiv, Telefonie/DECT aktiv, Ausfallschutz nicht eingerichtet, USB nicht verbunden, 2 Portfreigaben aktiv. Soll fuer Portfreigaben: nur `443/tcp` und `222/tcp` auf `192.168.178.58`.
-- `docs/EXTERNAL_DEPENDENCIES.md` um Telekom-DSL und FRITZ!Box 7590 als WAN-/Router-Abhaengigkeit erweitert; Ausfall-Szenario "Telekom-DSL / FRITZ!Box gestoert" ergaenzt.
-- `docs/CAPACITY_AND_LIFECYCLE.md` um Abschnitt "H:/ als zusaetzliches lokales Backup-Ziel" ergaenzt. Bewertung: H:/ ist als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll, aber bewusst **kein** Offsite-Ersatz und **kein** CIFS-Hard-Mount am Unraid (STORAGE_LAYOUT §12.6). Pull-Modell vom Windows-PC bleibt der getestete Weg (vgl. Disk1 Phase 2 Freeze 2026-05-25).
-- `docs/FAMILY_ONBOARDING.md` von Tabellen-Entwurf auf familienverstaendlichen Begruessungstext umgestellt: kurze App-Erklaerungen, konkrete Was-tun-Wenn-Anleitungen (Webseite weg, Passwort vergessen, 2FA verloren, Foto-Backup haengt, Browser-Warnung), "Was du nicht musst"-Block, Hinweis fuer geplante Wochenend-Einladung.
-- `docs/AUDIT_2026-05-25_TODO.md` Leitplanken aktualisiert: Authelia 2FA/OIDC/CrowdSec und Nextcloud-2FA-Haertung werden in diesem Zyklus nicht angefasst (Operator-Vorgabe). Hermes-Agent geparkt mit Review-Deadline 2026-07-25. USV-Risiko bewusst akzeptiert. Sprint 4 um H:/-Bewertung und FRITZ!Box-Portfreigaben-Abgleich erweitert. Neue Sprints 6 (geparkte Apps) und 7 (Off-site) ergaenzt.
-- Keine Live-/Compose-Aenderung in diesem Commit; nur Doku.
-
-### 2026-05-26 - USV-Risiko bewusst akzeptiert
-
-- Operator-Entscheidung: aktuell wird keine USV angeschafft.
-- Der Befund bleibt technisch unveraendert: keine funktionierende USV-Abschaltung nachgewiesen. Power-Loss-Risiko fuer Docker-/DB-State und laufende Writes wird bewusst akzeptiert und bei spaeteren Reviews neu bewertet.
-
-### 2026-05-26 - Borg-Passphrase offline gesichert
-
-- Operator bestaetigt: Die Borg-Passphrase ist offline/off-system gesichert und kann ohne Host oder Vaultwarden wiederhergestellt werden.
-- Doku aktualisiert nur den Sicherungsstatus; Secret-Wert und Ablageort bleiben bewusst ausserhalb des Repos.
-
-### 2026-05-26 - Gitea-Bundle-Mechanik definiert
-
-- `ops/borg-ui/scripts/gitea-bundle-mirror.sh` ergaenzt: erstellt verifizierte `git bundle`-Artefakte fuer alle bare Gitea-Repositories, schreibt Checksums und einen Markdown-Report.
-- Zielpfad ist `/mnt/user/backups/git-bundles/gitea`; dieser Pfad muss in den Borg/off-site Scope aufgenommen und hostseitig geplant werden.
-- `docs/SERVICES_RECOVERY.md` und `docs/RESTORE_MATRIX.md` dokumentieren Bundles jetzt als zweite Repo-Bootstrap-Schicht neben dem GitHub-Mirror.
-- Host-Erstlauf nach Skript-Fix erfolgreich: 4 Bundles erzeugt (`homelab-infra`, `homelab`, `homepage`, `smart-home-kalli`), Checksums OK, `homelab-infra.bundle` in Restore-Lab geklont und `git fsck` sauber. Offen bleibt die dauerhafte Schedule-Einbindung.
-
-### 2026-05-26 - Audit-Baseline-Tag gesetzt
-
-- Der Stand nach Hardware-/Capacity-Baseline, Policy-Triage und Recovery-Doku wurde als `audit-2026-05-25-baseline` markiert und nach Gitea gepusht.
-
-### 2026-05-26 - Externe Abhaengigkeiten und Services-Recovery baseline dokumentiert
-
-- `docs/EXTERNAL_DEPENDENCIES.md` von Template auf Betreiber-Baseline angehoben: Domain, Cloudflare, Hetzner, GitHub-Mirror, Tailscale, GMX, Let's Encrypt, Registries, Plex und mobile Push-Pfade sind mit Ausfallwirkung und Notfallplan dokumentiert.
-- `docs/SERVICES_RECOVERY.md` finalisiert den Komodo-Bootstrap-Anker: `ops/komodo/docker-compose.yml` bleibt verbindlich; der `komodo`-Self-Stack hat keinen aktiven Gitea-Webhook und ist nicht der Recovery-Anker.
-- Offene Off-Repo-Betreiberchecks bleiben Account-Besitz, 2FA-Recovery-Codes, Zahlungswege, Borg-Passphrase-Hinterlegung und Gitea-Bundle-/Mirror-Mechanik.
-
-### 2026-05-26 - Policy-Warnings triagiert
-
-- Plex `network_mode: host` wurde in den Policy-Ausnahmen als dokumentierte Discovery-Ausnahme erfasst.
-- Mutable Tags bei `ddns-updater`, `glances` und `scrutiny` bleiben wegen vorhandener SHA256-Digests reproduzierbar gepinnt und werden im Policy-Report als Info-Ausnahmen sichtbar gehalten.
-- `monitoring-influxdb3-core` bleibt als dokumentierte `user: "0"`-Ausnahme bewusst eine Warning, damit der Hardening-Punkt nicht aus dem Blick faellt.
-
-### 2026-05-26 - Hardware-/Capacity-Baseline abgeschlossen
-
-- Hardware-Inventar auf Host-Befund aktualisiert: BIOS AMI F21 vom 2025-06-19, Intel Raptor Lake SATA AHCI, Samsung NVMe Controller und Realtek RTL8125 2.5GbE mit aktuellem 1G-Link.
-- RAM-Baseline dokumentiert: 4x 8 GB DDR4 ohne ECC, gemischte Module, aktuell 2133 MT/s konfiguriert.
-- Capacity-Baseline dokumentiert: Cache 1.9T mit 97G genutzt (6 %), Disk1/User-Shares 5.5T mit 1.8T genutzt (33 %), lokale Backups 2.2G unter `/mnt/user/backups`.
-- USV-Befund dokumentiert: `apcupsd` ist vorhanden und auf USB vorkonfiguriert, laeuft aber nicht; `apcaccess status` liefert Connection refused und `lsusb` zeigt keine erkannte USV. Power-Loss bleibt damit eine offene Betreiberentscheidung.
-
-### 2026-05-26 - Komodo/Gitea-Restdrift bereinigt
-
-- Der alte Komodo-Stack `grafana` wurde als historischer Altstand inert gemacht: keine Repo-Dateipfade, kein Webhook, keine alte Stack-ENV, keine `missing_files`/`remote_errors`. Rollback bleibt Git-Historie, nicht der alte Komodo-Stack.
-- Der Gitea-Hook `35` fuer den alten `grafana`-Stack bleibt inaktiv. Der nicht sinnvolle `komodo`-Self-Hook `11` wurde deaktiviert, weil Komodo selbst nicht per Gitea-Webhook auf `master` deployed wird.
-- Ein kurz sichtbarer Komodo-DB-Typfehler durch `updated_at` als Float wurde im selben Kontrollfenster auf nativen Mongo `Long` korrigiert; danach traten keine neuen `invalid type`-Fehler mehr auf.
-- Nach der Bereinigung: aktive Gitea-Komodo-Hooks haben `0` Fehlstatus; `komodo-core`, `komodo-periphery`, `komodo-mongo`, `nextcloud` und die aktuellen `monitoring-*` Container laufen weiter.
-
-### 2026-05-26 - Monitoring-Altstaende aus aktivem Repo entfernt
-
-- Die abgeloesten Pfade `ops/grafana-influxdb` und `ops/loki` wurden per `git rm` aus dem aktiven Repo entfernt. `monitoring/` bleibt der einzige Observability-Zielstack.
-- Live-Check vor dem Cleanup: nur `monitoring-grafana`, `monitoring-promtail`, `monitoring-influxdb3-core` und `monitoring-loki` laufen; alte Container `grafana`, `influxdb3-core`, `loki` und `alloy` sind nicht vorhanden.
-- Rollback erfolgt bei Bedarf ueber Git-Historie, nicht ueber parallel gepflegte Compose-Verzeichnisse.
-- Im selben GitOps-Kontrollfenster wurde Gitea-Webhook `35` fuer den alten `grafana`-Rollback-Stack als inaktiv bestaetigt. Der aktive Nextcloud-Hook `36` hatte einen Signaturfehler; sein Secret wurde ohne Ausgabe des Werts aus der Komodo-Stack-Konfiguration zurueck nach Gitea synchronisiert.
-
-### 2026-05-26 - AdGuard Admin-Port auf Tailscale-Soll begrenzt
-
-- Host-Audit per SSH gegen `Kallilabcore` durchgefuehrt: Tailscale IPv4 ist `100.80.98.33`, LAN-IP ist `192.168.178.58/24`, Gateway `192.168.178.1`.
-- Repo-Soll fuer `host-services/Adguard/docker-compose.yml` geaendert: DNS `53/tcp+udp` bleibt unveraendert, die Admin-UI bindet nun auf `100.80.98.33:8082:80`.
-- Architektur, Service-Katalog, Repo-Map, Netzwerk-Inventar und AI-Kontext wurden an das neue Modell angepasst: keine Traefik-/Authelia-2FA-Umstellung, aber keine LAN-weite Admin-Bindung mehr.
-- Live-Deploy wurde nach Fast-Forward des AdGuard-Workspaces auf `5cb4017` mit `docker compose -p adguard ... up -d` ausgefuehrt. Validierung erfolgreich: `ss -ltnp` zeigt `100.80.98.33:8082`, DNS via `@127.0.0.1` und `@192.168.178.58` funktioniert, `http://100.80.98.33:8082/` liefert HTTP 302, `http://192.168.178.58:8082/` ist nicht mehr erreichbar.
-- Nachpruefung des GitOps-Pfads: Gitea-Hook `1` zeigt auf Komodo-Stack `69c7b9e26b77cd827811b9d0` und lieferte HTTP 200. Komodo-Deploys fuer AdGuard scheiterten zunaechst im `Git pull` einmal an `.git/index.lock` und danach an `fatal: Cannot rebase onto multiple branches`; der Workspace wurde aufgeraeumt und steht sauber auf `origin/master`.
-
-### 2026-05-26 - Audit-Umsetzung vorbereitet
-
-- Aus `docs/AUDIT_2026-05-25.md` wurde `docs/AUDIT_2026-05-25_TODO.md` als operative Arbeitsliste abgeleitet. Authelia-2FA/OIDC bleibt bewusst geparkt und wird erst nach finaler Policy-Entscheidung umgesetzt.
-- Neue Inventar- und Betriebsdokumente angelegt: `docs/HARDWARE_INVENTORY.md`, `docs/NETWORK_INVENTORY.md`, `docs/EXTERNAL_DEPENDENCIES.md`, `docs/CAPACITY_AND_LIFECYCLE.md` und `docs/FAMILY_ONBOARDING.md`.
-- `docs/SERVICES_RECOVERY.md` beschreibt initial die recovery-kritischen `/mnt/user/services`-Pfade, Gitea-Repo-Mirror-Optionen, Komodo-Bootstrap und Secret-Recovery-Reihenfolge.
-- Policy-Check lokal erneut ausgefuehrt: die alten SEC001-Warnings fuer `ddns-updater` und `scrutiny` sind nicht mehr aktuell; verbleibende Warnings betreffen Host-Netz-/User-/Image-Tag-Themen und Altstaende.
-
-### 2026-05-25 - Unraid Flash-Backup in Borg-Scope aufgenommen
-
-- `pre-backup-dumps.sh` erzeugt zusaetzlich zu den DB-Dumps ein sensibles `unraid-flash-config.tar.gz` aus `/boot/config` inklusive SHA256 und Manifest unter `/mnt/user/backups/borg/dumps/latest`.
-- Da `/local/borg-dumps` bereits Teil des Borg-Scopes ist, wird das Flash-Konfigurationsartefakt mit dem bestehenden Hetzner/Borg-Backup historisiert. Downloadbare Plugin-Paketarchive unter `/boot/config/plugins/*/` werden aus dem Artefakt ausgeschlossen; Restore-relevante Konfiguration bleibt enthalten.
-- Live-Erstlauf erfolgreich: `pre-borg.sh` lieferte `critical_count=0`, Freshness `Critical: 0`, `unraid-flash-config.tar.gz` ist 297 KiB gross, `0600 root:root`, SHA256-Pruefung `OK`, 356 Archiv-Eintraege, Manifest fuer Unraid `7.2.4`. Der Borg-UI-Job `Taegliche Sicherung` ist aktiv und umfasst `/local/borg-dumps`; der naechste planmaessige Hetzner-Lauf nimmt das neue Flash-Artefakt mit. Der Host-Repo-Clone unter `/mnt/user/services/homelab-infra` wurde wegen eines fehlgeschlagenen Fast-Forward-Checkouts frisch geklont; der vorherige Stand liegt archiviert unter `/mnt/user/services/_archive/homelab-infra-pre-refresh-20260525-194209`.
-
-### 2026-05-25 - Monitoring-Zielstack finalisiert und Uptime Kuma entfernt
-
-- `monitoring` und `glance` wurden auf Commit `b6bbca4` deployed; Komodo zeigt fuer beide `latest_hash` = `deployed_hash` = `b6bbca4` ohne `remote_errors`. Die zehn `monitoring-*` Container laufen, `monitoring.kaleschke.info` und `glance.kaleschke.info` leiten anonym zu Authelia, Prometheus ist ready und Loki `/ready` liefert `ready`.
-- Alte Monitoring-Altcontainer `grafana`, `influxdb3-core`, `loki` und `alloy` sind in Docker nicht vorhanden; `ops/grafana-influxdb` und `ops/loki` bleiben nur als Rollback-/Migrationsreferenz im Repo. Der noch aktive Gitea-Hook `35` des alten `grafana`-Rollback-Stacks wurde deaktiviert, damit zukuenftige Pushes den Altstand nicht reaktivieren.
-- Uptime Kuma wurde durch Blackbox/Prometheus/Grafana ersetzt: aktive Blackbox-Zielliste enthaelt 19 HTTPS-Ziele, `uptime.kaleschke.info` ist dort nicht mehr enthalten und liefert nach Stack-Removal 404. Der Komodo-Stack `uptime-kuma` wurde gestoppt/destroyed/geloescht, Gitea-Webhook `23` deaktiviert, Appdata nach `/mnt/user/appdata/_archive/uptime-kuma-removed-2026-05-25` und der alte Stack-Workspace nach `/mnt/user/services/stacks/_archive/uptime-kuma-removed-2026-05-25` verschoben.
-- Authelia-Hostconfig wurde mit Backup `configuration.yml.pre-uptime-removal-20260525-164343.bak` um den toten `uptime.kaleschke.info`-Eintrag bereinigt, validiert und neu gestartet. Prometheus wurde wegen eines `Stale NFS file handle` auf der gebundenen Konfigurationsdatei per Komodo-Restart neu gemountet.
-
-### 2026-05-25 - AdGuard Admin-Port bewusst LAN-direkt belassen
-
-- Strategische Option `adguard.kaleschke.info` hinter Traefik/Authelia-2FA wurde bewertet, aber vom Operator bewusst verworfen, weil der Betriebsweg einfach bleiben soll. AdGuard bleibt als dokumentierte Ausnahme mit DNS `53/tcp+udp` und Admin `8082:80` LAN-direkt; keine Live-Aenderung an AdGuard, Authelia oder Traefik wurde vorgenommen.
-
-### 2026-05-25 - Borg-Passphrase Host-Secret verifiziert
-
-- Erwartete Host-Secret-Datei `/mnt/user/appdata/secrets/borg_repo_passphrase.txt` aus der bestehenden Borg-UI-Repo-Konfiguration erzeugt, mit `root:root` und Modus `600` gesichert und per `borg info` gegen das Hetzner-Borg-Repo verifiziert. Analoge Offline-Hinterlegung bleibt bewusste Operator-Aufgabe; Secret-Wert wurde nicht ausgegeben oder dokumentiert.
-
-### 2026-05-25 - Dashboard auf Glance konsolidiert
-
-- Glance bleibt das einzige Homelab-Dashboard; Homepage wurde aus dem Zielbild entfernt. Authelia-Default-Redirect, Monitoring-Blackbox-Ziele, Cert-Check-Domains und Glance-Konfiguration zeigen nicht mehr auf `home.kaleschke.info`; Homepage wurde via Komodo-API gestoppt/destroyed, der Komodo-Stack geloescht, der alte Gitea-Webhook deaktiviert und Appdata nach `/mnt/user/appdata/_archive/homepage-removed-2026-05-25` verschoben.
-
-### 2026-05-25 - Jellyfin aus Zielbild entfernt
-
-- Plex-Smoke-Test erfolgreich (`/identity` HTTP 200, Container healthy, `/data/movies` und `/photos` sichtbar). Jellyfin wurde repo-seitig entfernt, aus Authelia-Baseline und Zielbild-Doku ausgetragen, via Komodo-API gestoppt/destroyed, der Komodo-Stack geloescht und Appdata nach `/mnt/user/appdata/_archive/jellyfin-removed-2026-05-25` verschoben; Plex bleibt einziger Medienserver.
-
-### 2026-05-25 - Externer Repo-Mirror eingerichtet
-
-- Gitea erlaubt fuer Repo-Migrationen und Mirror-Targets gezielt `github.com` und nutzt explizite externe DNS-Resolver. `Micha/homelab-infra` spiegelt nun als privater GitHub-Push-Mirror nach `michaelkaleschke-spec/homelab-infra`; erster manueller Sync erfolgreich, Gitea `push_mirror.last_error` leer. Token-Werte bleiben ausschliesslich in Gitea/GitHub und werden nicht dokumentiert.
-
-### 2026-05-25 - Audit-Final nachgemessen
-
-- Audit-Restliste erneut live geprueft: runtime-relevanter Stack-Inhalt fuer `gitea`, `borg-ui` und `monitoring` seit `66ee10c` unveraendert; abschliessende Audit-Doku-Commits liegen in Gitea; Monitoring inklusive Loki `/ready` gruen; Borg-Job und 15 kanonische Dump-Artefakte frisch; `docs/AUDIT_2026-05-23_FINAL.md` auf den Live-Stand aktualisiert.
-
-### 2026-05-25 - Disk1 Phase 2 abgeschlossen
-
-- Disk1 wurde nach H:-Freeze-Backup und finalem Service-Freeze von NTFS/`ntfs3` auf XFS migriert.
-- Restore verifiziert: `media` final 2722 Dateien und 1,800,782,188,226 Bytes mit 0 missing/extra/size mismatch; Tar-Shares und Disk1-Extras aus den H:-Freeze-Archiven wiederhergestellt.
-- Docker/Services nach XDG-Runtime-Fix wieder stabil: 49 Container laufend, 0 stopped, 0 unhealthy, 0 starting; Gitea, Komodo, Borg, Jellyfin und Monitoring per Smoke-Test erreichbar.
-- Borg-UI meldet den letzten Backup-Job `completed`; `pre-backup-dumps.sh` wurde nach Wiederanlauf erneut ausgefuehrt und 15 kanonische Dump-Artefakte sind juenger als 24 h.
-- `posture-check` erwartet Disk1 nun standardmaessig als XFS (`ALLOW_DISK1_NTFS=0`).
-
-### 2026-05-23 - Audit-Endstufe verifiziert
-
-- Lokalen Hardening-Commit `cd650b1` nach Gitea gepusht; Komodo-Workspaces fuer `gitea`, `borg-ui` und `monitoring` stehen auf `cd650b1`.
-- Live-Audit in `docs/AUDIT_2026-05-23_LIVE.md` dokumentiert: Gitea-Registration geschlossen, Borg-Dumps frisch, Monitoring-Stack aktiv, alte Grafana/Loki-Altcontainer nicht mehr vorhanden.
-- Jellyfin und Plex in Architektur, Service-Katalog und Repo-Map nachgetragen; Plex ist jetzt als Repo-Compose-Stack mit dokumentierter Host-Netz-Ausnahme gefuehrt.
-- Repo-Hygiene abgeschlossen: `.serena/` ignoriert, leere Verzeichnisse entfernt, Windows-Reinstall-Helfer unter `ops/windows-reinstall/` bewusst versioniert.
-
-### 2026-05-20 - Gitea 5xx-Bursts untersucht und Signup geschlossen
-
-- Live-Befund zu `HomelabTraefik5xx`: kurze externe `POST /`-Bursts auf `gitea@docker` von `103.153.183.69` und `103.153.183.73`, jeweils HTTP 500 in unter 10 ms; normale Gitea-Checks und Git-Reads liefen parallel mit HTTP 200.
-- Keine Hinweise auf erfolgreichen Zugriff: Gitea-Container ohne Restart/OOM, nur User `micha`, keine neuen User der letzten 30 Tage, keine neuen Repos, SSH-Keys oder Access-Tokens im Untersuchungsfenster.
-- Live-Prometheus lief noch mit der alten Regel `rate(...[5m]) > 0`; die bereits im Repo vorbereitete Regel `increase(...[5m]) >= 5` wurde auf den Live-Mount kopiert und per Prometheus-Reload aktiviert.
-- Gitea-Registrierung und OpenID-Signup wurden geschlossen: `DISABLE_REGISTRATION=true`, `REGISTER_EMAIL_CONFIRM=true`, `ENABLE_OPENID_SIGNIN=false`, `ENABLE_OPENID_SIGNUP=false`; Signup-Seite zeigt danach "Registration is disabled", OpenID-Login liefert 403.
-
-### 2026-05-18 - Komodo Webhooks vollstaendig abgeglichen
-
-- Live-Befund auf `Kallilabcore`: Komodo hatte fuer mehrere aktuelle Stacks `webhook_enabled: true`, aber Gitea enthielt noch nicht fuer alle aktuellen Stack-IDs aktive Webhooks.
-- In der Gitea-Datenbank wurden aktive Webhooks fuer `monitoring` (`6a08d5297707b0930ab95c72`), `glance` (`6a09d7347707b0930ab96eae`), `grafana` (`69f31ecdf65eb72b757c497d`) und `nextcloud` (`69e519085fd5e8bc51f121f0`) nach dem bestehenden Komodo-Hook-Muster angelegt.
-- Stale aktive Gitea-Hooks auf nicht mehr vorhandene bzw. alte Komodo-Stack-IDs wurden deaktiviert.
-- Abgleich danach: 30 aktive Gitea-Komodo-Hooks fuer 30 Komodo-Stacks mit aktiviertem Webhook; `hermes` bleibt in Komodo bewusst `webhook_enabled: false`.
-- Netzwerkpfad aus dem `gitea`-Container zu `komodo-core:9120` wurde erfolgreich verifiziert; `last_status=0` fuer neue Hooks bleibt bis zum ersten Push erwartbar.
-
-### 2026-05-19 - Posture-Check Host-Version verifiziert
-
-- Ursache fuer wiederholte ntfy-Warnings war nicht mehr die Repo-Logik allein, sondern dass auf dem Unraid-Host noch die alte Skriptversion unter `/mnt/user/services/homelab-infra/services/posture-check/posture-check.sh` ausgefuehrt wurde.
-- Host-Skript wurde mit Backup ersetzt und mit `SEND_NTFY=0` direkt auf dem Host verifiziert.
-- Ergebnis des echten Host-Laufs: `status: ok`, `critical_count: 0`, `warning_count: 0`.
-- Betriebsregel daraus: Bei Host-User-Scripts nach Repo-Aenderungen immer den tatsaechlich ausgefuehrten Host-Pfad und den Live-Output pruefen.
-
-### 2026-05-19 - Borg-Scope fuer GitOps Host Automation erweitert
-
-- Nach den Gitea-/Komodo-Webhook- und Posture-Check-Aenderungen wurde der Backup-Scope um Host-GitOps-Pfade erweitert.
-- Borg UI mountet kuenftig `/mnt/user/services` read-only als `/local/services`.
-- In `all-important-sources.txt` wurden `/local/services/homelab-infra`, `/local/services/stacks` und `/local/services/posture-check` aufgenommen.
-- `pre-backup-dumps.sh` wurde auf dem Host ausgefuehrt; frische Dumps fuer `gitea.sqlite.dump` und `komodo-mongo.archive.gz` liegen unter `/mnt/user/backups/borg/dumps/latest`.
-- Wirksam wird der neue `/local/services`-Mount nach Redeploy/Recreate des `borg-ui`-Stacks.
-
-### 2026-05-19 - Traefik-5xx Alert entstoert
-
-- `HomelabTraefik5xx` hatte auf einzelne 5xx-Antworten reagiert, weil die Regel `rate(...[5m]) > 0` nutzte.
-- Live-Befund fuer `gitea@docker`: zwei kurze `POST /` mit HTTP 500 von einer externen IP, danach durchgehend erfolgreiche Gitea-Checks; kein Container-Restart.
-- Prometheus-Regel auf `increase(...[5m]) >= 5` geaendert, damit einzelne externe Fehlrequests keinen ntfy-Alarm ausloesen.
-
-### 2026-05-17 - Glance Homelab-Dashboard vorbereitet
-
-- `ops/glance` als geschuetztes Homelab-Dashboard unter `glance.kaleschke.info` vorbereitet.
-- Glance zeigt HTTP-Monitore fuer Core, Apps und Ops, Docker-Containergruppen, Host-Snapshot und Bookmarks.
-- Docker-Status laeuft nicht ueber einen direkten Socket-Mount in Glance, sondern ueber `glance-docker-socket-proxy` auf einem internen `glance_socket_net`.
-- Die HTTP-Monitore nutzen oeffentliche URLs als Klickziel und interne `check-url`-Endpunkte auf `frontend_net`, damit Glance nicht vom externen Hairpin-/Auth-Pfad abhaengt.
-- Das Immich Community-Widget wurde ergaenzt. Der API-Zugriff nutzt eine interne Service-URL und ein Stack-ENV-Token. Paperless, Scrutiny und Speedtest bleiben Kandidaten fuer einen spaeteren Widget-Pass, sobald die konkrete API-Ausgabe im Glance-Kontext sauber verifiziert ist.
-- Das Dashboard-Layout wurde an `ginesjunior11/glance-dashboard-config` angelehnt: dunkleres blaues Theme, Zeitfortschrittsgruppe, farbige Dashboard-Icons, dichter `Homelab Status`, Server-Stats im Hauptbereich und eine zweite Seite `Infrastructure and Media`. Die rechte Home-Spalte zeigt WAN-Infos aus Speedtest Tracker, Speedtest-Livewerte, AdGuard-DNS-Stats, DNS/Ingress-Monitore und eine separate Netzwerk-Containergruppe.
-
-### 2026-05-17 - Monitoring-Zielstack konsolidiert
-
-- `monitoring/` als zentraler Observability-Zielstack fuer Prometheus, Loki, Promtail, Grafana, node-exporter, cAdvisor und InfluxDB 3 Core vorbereitet.
-- `monitoring-grafana` nutzt den Repo-Standard `authelia@file,secure-headers@file` und Secrets per Datei statt Klartext-Stack-ENV.
-- `monitoring-influxdb3-core` uebernimmt den LAN-only Writer-Endpunkt fuer Home Assistant (`8181` via `INFLUXDB_BIND_IP`).
-- `ops/loki` und `ops/grafana-influxdb` sind abgeloeste Altstaende und bleiben nur als Rollback-/Migrationsreferenz im Repo.
-
-### 2026-05-07 - Vaultwarden Restore-Test praktisch verifiziert
-
-- Erster echter Vaultwarden-Mini-Restore gegen das produktive Borg-Repo `hetzner_borg_appdata_critical` erfolgreich durchgefuehrt.
-- Restore lief isoliert nach `/mnt/user/backups/restore-lab/vaultwarden`, nicht gegen produktive Pfade.
-- Testinstanz `restoretest-vaultwarden` wurde lokal auf `127.0.0.1:18080` gestartet; HTTP 200 und Login-Seite wurden erfolgreich bestaetigt.
-- Report wurde unter `/mnt/user/backups/restore-reports/vaultwarden-2026-05-07.md` geschrieben.
-- Fuer den praktischen Restore-Pfad wurden zwei hostseitige Voraussetzungen sichtbar und umgesetzt:
-  - `known_hosts` fuer das Hetzner-Ziel im `borg-ui`-Container
-  - Host-Secret-Datei `/mnt/user/appdata/secrets/borg_repo_passphrase.txt` fuer kuenftige Restore-Tests
-- Testdaten unter `/mnt/user/backups/restore-lab/vaultwarden/data` wurden nach erfolgreichem Lauf wieder bereinigt.
-
-### 2026-05-07 - Gitea Restore-Test praktisch verifiziert
-
-- Erster echter Gitea-Mini-Restore gegen das produktive Borg-Repo `hetzner_borg_appdata_critical` erfolgreich durchgefuehrt.
-- Restore lief isoliert nach `/mnt/user/backups/restore-lab/gitea`, nicht gegen produktive Pfade.
-- Testinstanz `restoretest-gitea` wurde lokal auf `127.0.0.1:13000` und `127.0.0.1:12222` gestartet.
-- HTTP 200, HTML-Titel und lokaler SSH-Port wurden erfolgreich bestaetigt.
-- Report wurde unter `/mnt/user/backups/restore-reports/gitea-2026-05-07.md` geschrieben.
-- Testdaten unter `/mnt/user/backups/restore-lab/gitea/data` wurden nach erfolgreichem Lauf wieder bereinigt.
-
-### 2026-05-07 - Paperless Restore-Test praktisch verifiziert
-
-- Erster echter Paperless-Mini-Restore gegen das produktive Borg-Repo `hetzner_borg_appdata_critical` erfolgreich durchgefuehrt.
-- Restore umfasste sowohl die Dateipfade als auch `postgresql17-paperless.dump` aus dem Borg-Archiv.
-- Testinstanzen `restoretest-paperless`, `restoretest-paperless-postgres` und `restoretest-paperless-redis` liefen isoliert ohne Traefik.
-- Login-Seite war lokal auf `127.0.0.1:18120` erreichbar.
-- Der Dump-Import in Test-Postgres war erfolgreich; die Test-Datenbank enthielt `25` Dokumente.
-- Report wurde unter `/mnt/user/backups/restore-reports/paperless-2026-05-07.md` geschrieben.
-- Testdaten unter `/mnt/user/backups/restore-lab/paperless` wurden nach erfolgreichem Lauf wieder bereinigt.
-
-### 2026-05-06 - Komodo Webhook Secret getrennt
-
-- `KOMODO_WEBHOOK_SECRET` von `KOMODO_SECRET_KEY` getrennt und als eigene Stack-ENV-Variable dokumentiert.
-- Gitea-Komodo-Webhooks mit bisherigem Core-Secret wurden auf den neuen `KOMODO_WEBHOOK_SECRET` umgestellt; bereits individuelle per-Stack-Webhook-Secrets wurden beibehalten.
-- Host-`.env`, persistente Komodo-Compose und Gitea-Webhooks wurden als ein gemeinsamer Runtime-Schritt behandelt, damit Auto-Deploys nicht auseinanderlaufen.
-- Ein stale Gitea-Webhook auf eine nicht mehr vorhandene Komodo-Stack-ID wurde deaktiviert, nicht geloescht.
-
-### 2026-05-06 - Authelia GMX SMTP Notifier
-
-- Authelia-Notifier von Filesystem-Log auf GMX SMTP (`submission://mail.gmx.net:587`) umgestellt.
-- SMTP-Passwort bleibt ausserhalb des Repos unter `/mnt/user/appdata/secrets/authelia_smtp_password.txt`.
-- Authelia-Compose erhaelt explizite DNS-Server, weil der SMTP-Startup-Check externe Namen wie `mail.gmx.net` aufloesen muss.
-- Repo-Baseline und Host-Config muessen bei Auth-Aenderungen weiter bewusst gemerged und vor Restart validiert werden.
-
-### 2026-05-06 - Hermes DR und Mail-Archiver Authelia
-
-- Hermes Agent in `docs/RESTORE_MATRIX.md` und `docs/DISASTER_RECOVERY.md` mit Restore-Pfaden, Secret-/ENV-Hinweisen und Smoke-Test ergaenzt.
-- Mail-Archiver Web-UI hinter `authelia@file,secure-headers@file` gelegt; App-eigene Auth bleibt als zweite Schutzschicht bestehen.
-- M10/Komodo blieb unveraendert.
-
-### 2026-05-05 - N-Aufraeum-Sprint
-
-- Obsolete Compose-Top-Level-Felder `version: "3.9"` aus Immich, Mail Archiver und Paperless entfernt.
-- Leere `env/domains.env.example` und `env/global.env.example` mit nicht geheimen Beispielwerten gefuellt.
-- Veraltete `.keep`-Platzhalter aus Verzeichnissen mit echten Compose-/Repo-Inhalten sowie zwei reine Geister-Verzeichnisse (`host-services/plex`, `infra/dns`) entfernt.
-
-### 2026-05-16 - Backup-Konsistenz und erster Hardening-Schnitt
-
-- SQLite-Dumps fuer Gitea, Vaultwarden, Speedtest Tracker und Filebrowser werden containerseitig als `*.sqlite.dump` erzeugt und per Freshness-Check geprueft; Uptime Kuma wurde am 2026-05-25 aus dem aktiven Dump-Scope entfernt.
-- `nextcloud.dump` und die Nextcloud-Userdaten sind als Option A im Borg-Scope dokumentiert.
-- Filebrowser mountet keine breite `/mnt/user/appdata`-Flaeche mehr, sondern nur noch Documents, Photos, Projekte sowie eigenen App-State.
-- Authelia Argon2id-Parameter in der Repo-Baseline auf `iterations: 3`, `memory: 65536`, `parallelism: 4` gesetzt; produktive Host-Config muss kontrolliert gemerged und mit Test-User validiert werden.
-- Redis-Caches wurden auf `redis:7.4-alpine@sha256:...` vereinheitlicht; Nextcloud wurde mit Registry-validiertem Digest gepinnt.
-- Eindeutig aufloesbare `latest@sha256`-Images wurden auf konkrete Tags umgestellt: Homepage `v1.12.3`, code-server `4.116.0`, Filebrowser `v2.63.2`, Speedtest Tracker `1.13.12`.
-
-### 2026-05-05 - M3b versionierte App-Images digest-gepinnt
-
-- Versionierte Nicht-Komodo-Images fuer BentoPDF, Mealie, Paperless, Paperless-GPT, AdGuard Home, Grafana, InfluxDB 3 Core und Traefik auf die am Host laufenden, manifest-validierten Digests gepinnt.
-- `nextcloud:33.0.2-apache` wurde bewusst nicht in diesem Schritt gepinnt, weil der lokal gelistete Digest nicht als Registry-Manifest fuer `tag@sha256` validierbar war.
-- Redis-Caches und Komodo/M10 blieben unveraendert.
-
-### 2026-05-05 - M6/M7/M8 Doku-Konsolidierung
-
-- `hermes.kaleschke.info` als produktive Hermes-Dashboard-Route hinter Traefik + Authelia in Architektur, Repo-Map und Service-Katalog ergaenzt.
-- `grafana` und `influxdb3-core` laufen weiterhin als `user: "0"`; das wurde als Host-Appdata-Permissions-Ausnahme dokumentiert und nicht nebenbei geaendert.
-- Tailscale-Ausnahme um `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` ergaenzt.
-- Komodo-Secret-/Webhook-Themen wurden bewusst nicht geaendert; Komodo-Aenderungen erfolgen nur gemeinsam mit dem Betreiber.
-
-### 2026-05-05 - M3a stateful Digest-Pinning
-
-- PostgreSQL 17 Datenhalter auf `postgres:17.9@sha256:5b96f1a16bd9768b060dd2ffe55cb6225c4d9ef4d214a8b21eb08134869a97e4` gepinnt (`postgresql17`, `mealie-postgres`, `nextcloud-postgres`).
-- Immich pgvector-Postgres auf `tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:739cdd626151ff1f796dc95a6591b55a714f341c737e27f045019ceabf8e8c52` gepinnt.
-- Komodo Mongo auf `mongo:7.0.32@sha256:32979a1189dfdc44da3f5ed40d910495f5ad8f6f7f77556646f890a30b2d3f56` sowie Komodo Core/Periphery und Gitea auf die am Host laufenden Digests gepinnt.
-- Redis-Caches wurden am 2026-05-16 auf `redis:7.4-alpine@sha256:...` vereinheitlicht; Redeploys erfolgen stackweise mit Smoke-Test, nicht parallel.
-
-### 2026-05-04 - Komodo Self-Stack Drift auf persistenten Pfad zurueckgefuehrt
-
-- Drift-Befund: `komodo-core` und `komodo-periphery` liefen aus `/tmp/komodo-core-repair.yml` bzw. `/tmp/komodo-periphery-repair.yml`; `komodo-mongo` verwies auf `/mnt/user/services/stacks/komodo/compose.yaml`, obwohl dieser Pfad fehlte.
-- Vor Eingriff wurden die Repair-Dateien und zugehoerigen `/tmp/*.env`-Dateien unter `/mnt/user/appdata/komodo/_drift_backup_2026-05-04/` gesichert.
-- Zusaetzlich wurde eine geschuetzte Recovery-ENV unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env` abgelegt; diese Datei enthaelt Tier-1-Secret-Material und ist kein Dauerzustand.
-- Vor dem Reconcile wurde das host-seitige Dump-Skript ausgefuehrt; `komodo-mongo.archive.gz` wurde frisch unter `/mnt/user/backups/borg/dumps/latest/` erzeugt.
-- Persistenter Self-Stack wurde unter `/mnt/user/services/stacks/komodo/compose.yaml` aus `ops/komodo/docker-compose.yml` wiederhergestellt; `.env` wurde hostseitig aus der bestehenden Runtime-ENV abgeleitet.
-- Der vollstaendige Dry-run haette auch `komodo-mongo` recreated und wurde daher nicht ausgefuehrt. Stattdessen wurden nur `komodo-core` und `komodo-periphery` gezielt mit `--no-deps --force-recreate` aus dem persistenten Pfad neu erstellt; `komodo-mongo` blieb unveraendert healthy.
-- Smoke-Tests: `docker compose ls` zeigt fuer `komodo` nur noch `/mnt/user/services/stacks/komodo/compose.yaml`, Mongo pingt `{ ok: 1 }`, `https://komodo.kaleschke.info` liefert HTTP 200, und Periphery meldet sich am Core an.
-- Die `/tmp/*repair.yml`-Dateien bleiben vorerst als Altlast erhalten und duerfen erst nach stabiler Laufzeit bewusst entfernt oder ins Drift-Backup verschoben werden.
-
-### 2026-05-04 - Authelia ACL-Drift hostseitig gemerged
-
-- Die produktive Authelia-Config ist groesser als die Repo-Datei, weil sie hostseitige OIDC-/Secret-Konfiguration enthaelt. Die Repo-Datei wurde daher als nicht geheime Baseline eingeordnet und nicht blind auf den Host kopiert.
-- Host-Backup vor Aenderung: `/mnt/user/appdata/authelia/config/configuration.yml.bak-20260504-acl-sync`.
-- Minimaler Host-Merge: `homepage.kaleschke.info` wurde aus der bypass-Liste entfernt, `komodo.kaleschke.info` aus der 2FA-Liste entfernt, und `default_redirection_url` wurde auf `https://home.kaleschke.info` gesetzt.
-- `authelia validate-config` war erfolgreich; Authelia wurde neu gestartet und war danach healthy.
-- Smoke-Tests: `home.kaleschke.info` liefert fuer anonyme Requests eine Authelia-Weiterleitung, `komodo.kaleschke.info` bleibt ueber native Komodo-Auth erreichbar.
-
-### 2026-05-04 - Home Assistant InfluxDB LAN-Port und Drift-Runbook
-
-- `influxdb3-core` fuer Home-Assistant-Writer auf LAN-Port `8181` vorbereitet und deployed.
-- InfluxDB bleibt ohne Traefik-/Public-Route und haengt nicht im `frontend_net`.
-- Fuer aktives Docker Host-Port-Publishing wurde zusaetzlich zum internen `grafana_influx_internal` das Compose-Netz `grafana_influx_lan` ergaenzt.
-- Komodo Periphery dauerhaft um `/mnt/user/services:/mnt/user/services` und `frontend_net` ergaenzt, damit Stack-Workspaces und Gitea-Zugriff reproduzierbar funktionieren.
-- `docs/GITOPS_DRIFT_RUNBOOK.md` angelegt, um lokale Git-Kopie, Gitea, Komodo Workspace, Docker Runtime und Host-Listener getrennt zu pruefen.
-
-### 2026-03-28 - GitOps-Konsolidierung
-
-- Komodo als primaeren Stack-Manager eingefuehrt.
-- Portainer aus dem Zielbild herausgenommen.
-- Traefik auf 100% Docker-Labels konsolidiert.
-- `diun` entfernt; Update-Monitoring wird ueber Komodo abgedeckt.
-
-### 2026-03-29 - Portainer abgeschaltet
-
-- Portainer CE aus dem produktiven Betrieb entfernt.
-- Komodo als alleinigen Stack-Manager festgezogen.
-
-### 2026-04-13 bis 2026-04-15 - Borg-Rollout abgeschlossen
-
-- `critical_infra` erfolgreich nach Borg gesichert.
-- Pre-Backup-Dumps host-seitig ueber Unraid User Scripts etabliert.
-- Dump-Zielpfad auf `/mnt/user/backups/borg/dumps` umgestellt.
-- Restore-Smoke-Test fuer `postgresql17-globals.sql` und `gitea.db` erfolgreich nachgewiesen.
-- Monitoring fuer Borg war historisch ueber `ntfy` und Uptime Kuma eingerichtet; seit 2026-05-25 ersetzt durch `ntfy`, Blackbox/Prometheus und Monitoring Grafana.
-
-### 2026-04-15 - Repo- und Betriebsbereinigung
-
-- Firefly, Firefly-Fints und Semaphore aus Repo und Homelab entfernt.
-- GitHub Desktop als Standard-Workflow fuer den lokalen Sync festgelegt.
-
-### 2026-04-17 - Sicherheits- und Doku-Abgleich
-
-- `code-server` hinter `authelia@file,secure-headers@file` abgesichert.
-- Traefik-Dashboard von `dashboard-auth@file` auf `authelia@file,secure-headers@file` umgestellt; BasicAuth-Hash aus dem Repo entfernt.
-- Redis von Klartext in der Compose auf Secret-Datei unter `/mnt/user/appdata/secrets/redis_password.txt` umgestellt.
-- Redis-Passwort bewusst **nicht** rotiert; Live-Passwort bleibt vorerst unveraendert.
-- `mail-archiver` in der Architektur-Doku an den realen Traefik-Betrieb angepasst.
-- `paperless-gpt` von `LOG_LEVEL=debug` auf `info` umgestellt.
-- `speedtest-tracker` von `APP_DEBUG=true` auf `false` umgestellt.
-- Mutable Image-Tags fuer produktive Stacks auf die aktuell laufenden Digests eingefroren, um Deployments reproduzierbar zu machen.
-- `paperless-ngx` bleibt fuer `PAPERLESS_DBPASS` und `PAPERLESS_REDIS` vorerst bewusst bei Stack Environment Variables; keine Live-Migration auf `_FILE`, solange der aktuelle Stand stabil laeuft.
-- Disaster-Recovery-Runbook und Restore-Matrix fuer den Totalausfall-/Wiederanlauf-Fall neu dokumentiert.
-
-### 2026-04-19 - paperless-gpt Digest-Pin zurueckgenommen
-
-- Der fuer `paperless-gpt` eingetragene Digest war syntaktisch ungueltig (63 statt 64 Hex-Zeichen) und wurde daher wieder auf `icereed/paperless-gpt:latest` zurueckgesetzt.
-- Diese Ruecknahme ist bewusst eng auf einen einzelnen defekten Pin begrenzt und aendert keine anderen Digest-Festschreibungen.
-- Die zwischenzeitlichen OCR-/Versions-Experimente fuer `paperless-gpt` wurden wieder auf den einfachen vorherigen Stand zurueckgenommen (`icereed/paperless-gpt:latest`, `VISION_LLM_MODEL=cnshenyang/qwen3-nothink:14b`), um den letzten bekannten Alltagszustand wiederherzustellen.
-
-### 2026-04-19 - Nextcloud und Stirling-PDF vorbereitet
-
-- `apps/nextcloud/docker-compose.yml` als offizieller Docker-Microservice-Stack mit `nextcloud:apache`, eigener PostgreSQL-Datenbank und eigenem Redis vorbereitet.
-- Nextcloud folgt dem Repo-Standard `frontend_net` + app-internes Netz, nutzt `_FILE`-Secrets fuer Admin- und DB-Passwort und ist bewusst **nicht** hinter zentraler ForwardAuth, damit WebDAV/CardDAV und native Clients sauber funktionieren.
-- `apps/stirling-pdf/docker-compose.yml` als geschuetzter Tool-Stack hinter `authelia@file,secure-headers@file` vorbereitet.
-- Stirling-PDF nutzt persistente Pfade fuer `/configs`, `/logs`, `/pipeline`, `/customFiles` und `/usr/share/tessdata`; interne Stirling-Login-Funktion bleibt zugunsten des zentralen Traefik-/Authelia-Zugangs deaktiviert.
-
-### 2026-04-30 - BentoPDF und Grafana/InfluxDB vorbereitet
-
-- `stirling-pdf` repo-seitig durch `bentopdf` ersetzt; Domain `pdf.kaleschke.info` bleibt erhalten.
-- BentoPDF laeuft als geschuetztes browserseitiges PDF-Tool hinter `authelia@file,secure-headers@file` und setzt zusaetzlich COOP/COEP-Header fuer SharedArrayBuffer-basierte Office-Konvertierung.
-- `ops/grafana-influxdb` als neuer Monitoring-Stack vorbereitet und spaeter in Betrieb genommen.
-- Grafana laeuft hinter Traefik + Authelia unter `grafana.kaleschke.info`.
-- InfluxDB 3 Core bleibt ohne Public Route und wird ueber eine provisionierte Grafana-Datenquelle angebunden.
-- Secrets fuer Grafana-Admin-Passwort, InfluxDB-Admin-Token und Grafana-Datasource-Token sind als Host-Dateien unter `/mnt/user/appdata/secrets/` dokumentiert.
-
----
-
-## Dauerhafte Learnings
-
-- Kein Live-Editing in Komodo; Git gewinnt immer gegen manuelle Drift.
-- Webhooks koennen nach einem Push sofort einen Deploy ausloesen.
-- Rollback soll bevorzugt ueber saubere Git-Commits und bekannte Good States erfolgen, nicht ueber History-Rewrites auf `master`.
-- Doku soll Endzustaende beschreiben, nicht veraltete Zwischenstaende konservieren.

docs/NETWORK_INVENTORY.md

@@ -1,7 +1,7 @@
 # Network Inventory - KalliLab CORE
 
-Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI geprueft; VLAN/IPv6-Details offen.
+Status: Host-Audit erfasst; Router-Baseline und Portfreigaben-UI bereinigt; FRITZ!Box-Remote-Dienste aus; IPv6-Exposure technisch und per UI entschaerft; Tailscale-Inventar am 2026-06-05 real gemessen.
-Letzte Pruefung: 2026-05-27
+Letzte Pruefung: 2026-06-05 (Tailscale-Inventar), 2026-06-01 (Router/Ports)
 
 ## Zweck
 
@@ -14,13 +14,13 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 | Anschluss / Provider | DSL, Telekom |
 | Bandbreite (FRITZ!Box-UI) | ca. 87,3 Mbit/s Download, ca. 36 Mbit/s Upload |
 | Router-Modell | FRITZ!Box 7590 |
-| Firmware | FRITZ!OS 8.21 (Update gemeldet, nicht eingespielt) |
+| Firmware | FRITZ!OS 8.25 (`154.08.25` per TR-064 am 2026-06-01) |
 | Router-IP | 192.168.178.1 |
 | DHCP-Server | FRITZ!Box (Standardannahme, Override durch Operator nicht dokumentiert) |
 | Lokales Subnetz | 192.168.178.0/24 |
-| IPv6 aktiv | TBD (FRITZ!Box-UI separat pruefen) |
+| IPv6 aktiv | Windows-Client hat Provider-IPv6; Host hat keine globale Provider-IPv6, nur Tailscale-ULA |
 | DynDNS / DDNS | Cloudflare via `ddns-updater` (kein FRITZ!Box-DynDNS in Nutzung) |
-| Heimnetz-Geraete (FRITZ!Box-UI) | 36 aktive Geraete |
+| Heimnetz-Geraete (FRITZ!Box-UI) | 35 aktive Geraete |
 | LAN-Ports belegt | LAN 1-4 verbunden |
 | Telefonie / DECT | aktiv |
 | USB an FRITZ!Box | nicht verbunden |
@@ -30,7 +30,8 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 
 - Telekom-DSL ist Single-WAN; ohne Ausfallschutz ist Internet-Ausfall = kein DDNS-Update, keine ACME-Erneuerung, keine externen Push-Quellen.
 - Upload 36 Mbit/s ist die effektive Obergrenze fuer Off-site-Backup-Geschwindigkeit nach Hetzner und fuer Plex-Remote-Streaming.
-- FRITZ!OS 8.21 hat ein angezeigtes Update; Einspielung ist Betreiber-Aufgabe und nicht Teil des Repos.
+- FRITZ!OS ist am 2026-06-01 per TR-064 auf `154.08.25` beobachtet; FRITZ!Box-Konfig-Backup `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export` wurde extern/off-system in Vaultwarden abgelegt.
+- `Internet -> Freigaben -> FRITZ!Box-Dienste` ist am 2026-06-01 geprueft: Internetzugriff auf die FRITZ!Box per HTTPS ist aus, FTP/FTPS-Zugriff auf Speichermedien ist aus.
 
 ## DNS
 
@@ -43,28 +44,168 @@ Dieses Dokument beschreibt Router, DNS, Tailscale, Portfreigaben und Netztrennun
 
 ## Tailscale
 
-| Feld | Wert |
+Gemessen am 2026-06-05 per read-only SSH auf den Host (`tailscale status`,
+`tailscale status --json`, `tailscale ip -4/-6`).
+
+| Feld | Wert / Status |
 |---|---|
 | Node-Name | Kallilabcore |
-| Tailscale IPv4 | 100.80.98.33 |
+| Tailnet / MagicDNS | `taild9fcf2.ts.net`; DNSName `kallilabcore.taild9fcf2.ts.net` |
-| Tailscale IPv6 | TBD |
+| Tailscale IPv4 | `100.80.98.33` |
-| Exit Node | TBD |
+| Tailscale IPv6 | `fd7a:115c:a1e0::2c01:62b2` (gemessen 2026-06-05) |
-| Subnet Router | TBD |
+| Exit Node | **Nein.** `Self.ExitNodeOption: false` und `Self.ExitNode: false` — Host bietet keinen Exit Node an und nutzt keinen. Entspricht dem Ziel (Operator-Zugang ist eingehend, nicht als Internet-Ausgang). |
-| ACL-Policy extern dokumentiert | TBD |
+| Subnet Router | **Ja, aktiv.** Host advertised und ist Primary fuer `192.168.178.0/24` (`Self.PrimaryRoutes: ["192.168.178.0/24"]`, ebenfalls in `AllowedIPs`). Das LAN ist also fuer das gesamte Tailnet ueber diesen Subnet-Router erreichbar — bewusst gemessener Ist-Zustand, **kein** "keine Route" wie zuvor vermutet. |
+| ACL-Policy extern dokumentiert | **Angewendet 2026-06-06** — restriktive Tag-basierte `grants`-Policy live (`tag:server`/`tag:operator`, `tag:family` schlafend). Default-Allow entfernt, verifiziert. Details im Block unten. |
 
-Pruefkommando:
+### Tailnet-Geraete (Snapshot 2026-06-05)
+
+| Tailscale-IP | Node | OS | Status |
+|---|---|---|---|
+| `100.80.98.33` | kallilabcore | linux | aktiv (Host, Subnet-Router) |
+| `100.78.133.37` | baerchen-1 | windows | aktiv (aktuelle Operator-Workstation, direct) |
+| `100.105.203.21` | baerchen | windows | offline, zuletzt vor ~1 Tag gesehen (Alt-Node) |
+| `100.73.83.55` | iphone-14 | iOS | bekannt |
+| `100.112.0.90` | kallilab-core | linux | **am 2026-06-06 entfernt.** War der redundante userspace-only `Tailscale-Docker`-Stack (`host-services/tailscale/`). Komodo-Stack gestoppt+destroyed, Repo-Pfad per `git rm` entfernt, Container weg (read-only verifiziert). Node-Eintrag in der Admin-Konsole noch zu entfernen. |
+
+> **Befund 2026-06-06 (read-only auf dem Host ermittelt):** Der Host hat **zwei**
+> `tailscaled`-Prozesse:
+>
+> 1. **Native Unraid-Plugin** = `kallilabcore` (100.80.98.33). Prozess
+>    `/usr/local/sbin/tailscaled -statedir /boot/config/plugins/tailscale/state
+>    -tun tailscale1`. **Echtes TUN-Interface `tailscale1`, ist der Subnet-Router
+>    fuer `192.168.178.0/24`**, laeuft seit 24. Mai, installiert via
+>    `tailscale.plg` + `unraid-tailscale-utils`. State unter
+>    `/boot/config/plugins/tailscale/state` → ueber das **Flash-Backup** gesichert.
+>    Im ACL-Rollout `tag:server`. **Das ist die funktionale, kanonische Instanz.**
+> 2. **Docker-Stack** = `kallilab-core` (100.112.0.90), `host-services/tailscale/`.
+>    Prozess `tailscaled --tun=userspace-networking` → **nur Userspace, kann
+>    technisch nicht routen / kein Subnet-Router/Exit-Node sein**, advertised
+>    nichts, kein Container teilt seinen Namespace, seit 31. Mai. State unter
+>    `/mnt/user/appdata/tailscale`. Im ACL-Rollout untagged → isoliert.
+>    **Hochwahrscheinlich redundant.**
+>
+> **Umgesetzt 2026-06-06:** Der redundante Docker-Stack `host-services/tailscale/`
+> wurde sauber per GitOps abgebaut — Komodo-Stack `tailscale` gestoppt+destroyed
+> (Operator), `git rm host-services/tailscale/`, Glance-Widget entfernt, und
+> Architektur-/Service-Catalog-/DR-/CLAUDE-Doku auf "natives Plugin" nachgezogen.
+> Read-only verifiziert: Container weg, nur noch der native `tailscaled` mit
+> `tailscale1`, Subnet-Route + Operator-Zugriff intakt. Offen: Node-Eintraege
+> `kallilab-core` und alter `baerchen` in der Admin-Konsole entfernen; State-Pfad
+> `/mnt/user/appdata/tailscale` bei Gelegenheit nach `_archive/` (kein Sofort-Loeschen).
+>
+> **Doku-Korrektur erledigt:** `docs/RESTORE_MATRIX.md` zeigt jetzt auf den
+> funktionalen State `/boot/config/plugins/tailscale/state` (im Flash-Backup)
+> statt auf den entfernten userspace-Docker-Pfad.
+
+### Subnet-Router-Konsequenz
+
+Weil `Kallilabcore` das LAN `192.168.178.0/24` als Subnet-Route anbietet, kann
+**jedes** Tailnet-Geraet mit Zugriff auf diese Route potenziell LAN-Dienste auf
+`192.168.178.0/24` erreichen — auch die Admin-Ports, die im LAN bewusst nur auf
+die Tailscale-IP gebunden sind, sind ueber die Subnet-Route adressierbar. Genau
+deshalb ist die ACL-Policy (unten) der eigentliche Schutzmechanismus und nicht
+nur der LAN-Bind.
+
+Pruefkommando (auf dem Unraid-Host, read-only):
 
 ```bash
 tailscale status
+tailscale status --json | jq '{exitNode: .Self.ExitNodeOption, primaryRoutes: .Self.PrimaryRoutes, allowedIPs: .Self.AllowedIPs}'
 tailscale ip -4
 tailscale ip -6
 ```
 
+### ACL-Policy — ANGEWENDET 2026-06-06 (restriktive Tag-basierte grants)
+
+**Status: live und verifiziert.** Die restriktive Policy wurde am 2026-06-06
+gemeinsam mit dem Operator in der lockout-sicheren Reihenfolge ausgerollt und
+read-only verifiziert (siehe "Rollout-Protokoll" unten). Ausgangspunkt war die
+**unveraenderte Default-Policy** im **`grants`-Schema** (eine Allow-all-Regel,
+keine Groups/Tags/`autoApprovers`); es gab also keinen eigenen Bestand zu
+erhalten.
+
+> **Schema-Hinweis:** Dieses Tailnet nutzt das `grants`-Modell
+> (`{"src","dst","ip"}`), nicht das aeltere `acls`/`action:accept`-Modell.
+> Normaler SSH-Zugriff (`ssh kallilabcore` ueber OpenSSH Port 22) wird ueber
+> `grants` geregelt, nicht ueber den `ssh`-Block; letzterer betrifft nur die
+> Tailscale-SSH-Funktion.
+
+**Angewendete Policy (live, kein Secret):**
+
+```json
+{
+  "tagOwners": {
+    "tag:server":   ["autogroup:admin"],
+    "tag:operator": ["autogroup:admin"],
+    "tag:family":   ["autogroup:admin"]
+  },
+  "autoApprovers": {
+    "routes": { "192.168.178.0/24": ["tag:server"] }
+  },
+  "grants": [
+    {"src": ["tag:operator"], "dst": ["*"],            "ip": ["*"]},
+    {"src": ["tag:server"],   "dst": ["tag:operator"], "ip": ["*"]},
+    {"src": ["tag:family"],   "dst": ["tag:server"],   "ip": ["tcp:443"]}
+  ],
+  "ssh": [
+    {"action": "check", "src": ["autogroup:member"], "dst": ["autogroup:self"],
+     "users": ["autogroup:nonroot", "root"]}
+  ]
+}
+```
+
+**Geraete-Tags (live):** `kallilabcore` = `tag:server`; `baerchen-1` + `iphone-14`
+= `tag:operator`; `kallilab-core` (Docker) + alter `baerchen` bewusst untagged ->
+isoliert.
+
+**Rollout-Protokoll 2026-06-06 (lockout-sicher, je Schritt read-only verifiziert):**
+
+1. Policy additiv erweitert (Tags/grants definiert, Allow-all noch drin) -> alle Peers unveraendert verbunden, Route approved.
+2. `baerchen-1` getaggt `tag:operator` -> online, verifiziert.
+3. `iphone-14` getaggt `tag:operator` -> verifiziert.
+4. `kallilab-core` faktisch geprueft (Docker-Sidecar, keine Abhaengigen) -> bewusst untagged gelassen.
+5. Host `kallilabcore` getaggt `tag:server` -> Route blieb via `autoApprovers` automatisch approved, SSH ok.
+6. Allow-all entfernt -> restriktiv. Smoke-Tests gruen: Operator-SSH ok, AdGuard-Admin ueber Tailnet `HTTP 302`, Ping 0% Verlust, Route weiter approved; Host sieht nur noch die zwei Operator-Peers (untagged Nodes isoliert). LAN-Rueckweg durchgehend verfuegbar.
+
+**Schema-/Erhaltungs-Hinweis fuer spaeter:** Die LAN-Subnet-Route
+`192.168.178.0/24` wird jetzt ueber `autoApprovers`/`tag:server` approved
+(vorher manuell). Es gibt keinen eigenen Bestand zu erhalten; die Policy oben
+ist die vollstaendige Wahrheit.
+
+**Hintergrund / Designentscheidungen (2026-06-05/06):**
+
+- Single-User-Realitaet: alle Nodes gehoeren demselben User `michaelkaleschke@`.
+  Eine Differenzierung Operator/Familie ist nur ueber **Tags** moeglich, deshalb
+  der Tag-Ansatz statt user-/gruppenbasiert.
+- Erster Rollout bewusst klein: nur `tag:server` + `tag:operator`.
+- **`tag:family` ist vorbereitet, aber schlafend:** Tag und eine konservative
+  Minimal-Regel (`dst: tag:server`, `ip: tcp:443`) sind definiert, aber **kein
+  Geraet traegt den Tag**, daher null Wirkung. Sobald ein echtes Familiengeraet
+  dazukommt, wird es einmal mit `tag:family` getaggt und die Regel greift sofort
+  — ohne Policy-Umbau. Vor dem ersten realen Familiengeraet die Regel auf die
+  dann benoetigten Dienste/Ports pruefen.
+- Der `ssh`-Block bleibt der Default (Tailscale-SSH Check-Modus); normaler
+  OpenSSH-Zugriff laeuft ueber die `grants` (Port 22, fuer `tag:operator` ueber
+  `ip: ["*"]` abgedeckt).
+
+**Offene Folgepunkte (kein Risiko, Hygiene/spaeter):**
+
+- Familien-Dienste/Ports konkretisieren — erst wenn ein reales Familiengeraet dazukommt.
+- **Zwei-Tailscale-Konsolidierung: ERLEDIGT 2026-06-06** — redundanter Docker-Stack
+  abgebaut, nur noch die native Plugin-Instanz `kallilabcore` (Subnet-Router) aktiv.
+- **Tailnet-Konsole aufraeumen: ERLEDIGT 2026-06-06** — Node-Eintraege `kallilab-core`
+  und alter Offline-`baerchen` aus der Admin-Konsole entfernt.
+- State-Pfad `/mnt/user/appdata/tailscale` (vom entfernten Docker-Stack) bei
+  Gelegenheit nach `_archive/tailscale-removed-2026-06-06/` (kein Sofort-Loeschen).
+- Optionaler Off-LAN-Routentest: von einem Operator-Geraet im Mobilfunk
+  (nicht im Heim-LAN) ein LAN-Ziel ueber `192.168.178.0/24` erreichen, um die
+  Subnet-Route end-to-end zu bestaetigen (im Heim-LAN nicht sauber isolierbar).
+
 ## Portfreigaben und Exposure
 
 ### FRITZ!Box (WAN -> Host)
 
-Aktiver Soll-Stand nach Operator-Bereinigung 2026-05-28:
+Aktiver Soll-Stand nach Operator-Bereinigung und UI-Gegencheck 2026-06-01:
 
 | Aktive Freigabe | Ziel | Zweck | Bemerkung |
 |---|---|---|---|
@@ -76,25 +217,26 @@ Bewusst **nicht** freigegeben:
 |---|---|
 | `80/tcp` | Cloudflare-DNS-Challenge ersetzt HTTP-01; Traefik macht HTTP->HTTPS-Redirect nur LAN-seitig; WAN-`80` waere zusaetzliche Angriffsflaeche ohne Funktionsnutzen. **2026-05-28 in FRITZ!Box-UI entfernt**, Validierung: Mobilfunk-Test ergibt Timeout auf `http://vault.kaleschke.info`, `https://...` weiter erreichbar. |
 | `222/tcp` (Gitea SSH) | bewusst Tailscale-only: Operator-Pfad ist Tailscale, GitHub-Mirror deckt DR-Bootstrap ab, Gitea-Bundles sind off-host. Externe SSH-Brute-Force-Vektoren vermeiden. |
+| `32400/tcp` (Plex) | Plex wird extern ausschliesslich ueber `https://plex.kaleschke.info` via Traefik/443 erreicht. Kein direkter WAN-Port fuer Plex, Plex Remote Access bleibt aus. |
 
 ### UPnP / Selbstständige Portfreigaben
 
 | Geraet | UPnP-Selbstfreigabe-Recht | Begruendung |
 |---|---|---|
 | `Kallilabcore` (192.168.178.58) | nicht erlaubt | Repo-managed; alle benoetigten Public-Ports sind explizite Freigaben |
-| `PC-192-168-178-71` / VONETS-Adapter (192.168.178.71, MAC 00:17:13:2F:61:96) | **2026-05-28 deaktiviert** | wahrscheinlich VONETS-WiFi-Bridge fuer SolarEdge-Wechselrichter; SolarEdge-Cloud-Sync ist ausschliesslich outbound, eingehende Ports sind nicht erforderlich |
+| `PC-192-168-178-71` / VONETS-Adapter (192.168.178.71, MAC 00:17:13:2F:61:96) | **2026-06-01 erneut geprueft und deaktiviert** | wahrscheinlich VONETS-WiFi-Bridge fuer SolarEdge-Wechselrichter; SolarEdge-Cloud-Sync ist ausschliesslich outbound, eingehende Ports sind nicht erforderlich |
 
-Sollten neue Geraete UPnP-Selbstfreigaben anfordern, wird das in `docs/MIGRATION_LOG.md` und hier als bewusste Ausnahme dokumentiert oder pro Geraet wieder deaktiviert.
+Sollten neue Geraete UPnP-Selbstfreigaben anfordern, wird das hier als bewusste Ausnahme dokumentiert oder pro Geraet wieder deaktiviert.
 
-Aktueller UI-Befund vom 2026-05-27 (`Internet -> Freigaben -> Kallilabcore`):
+Historischer UI-Befund vor Bereinigung vom 2026-05-27 (`Internet -> Freigaben -> Kallilabcore`):
 
 | Beobachtung | Bewertung |
 |---|---|
-| `HTTP-Server`, TCP, extern `80/tcp` auf `192.168.178.58` | Abweichung: fuer ACME/DNS-Challenge nicht erforderlich; sollte nach Operator-Freigabe entfernt werden, falls keine bewusste HTTP-WAN-Nutzung besteht |
+| `HTTP-Server`, TCP, extern `80/tcp` auf `192.168.178.58` | war Abweichung; **2026-05-28 entfernt** |
 | `HTTPS-Server`, TCP, extern `443/tcp` auf `192.168.178.58` | entspricht Repo-Soll |
-| Keine `222/tcp`-Freigabe sichtbar | Abweichung: Gitea-SSH ist extern nicht gemaess Soll erreichbar; nur anlegen, wenn Git-SSH aus dem Internet weiterhin gewuenscht ist |
+| Keine `222/tcp`-Freigabe sichtbar | entspricht seit 2026-05-28 dem Soll: Gitea-SSH bleibt Tailscale-only |
 | Kallilabcore: keine selbststaendige Portfreigabe, kein IPv4-/IPv6-Exposed-Host sichtbar | entspricht Sicherheitsziel |
-| `PC-192-168-178-71`: selbststaendige Portfreigabe erlaubt, `0 aktiv` | keine aktive Freigabe, aber UPnP/PCP-Erlaubnis sollte bei Gelegenheit deaktiviert werden |
+| `PC-192-168-178-71`: selbststaendige Portfreigabe erlaubt, `0 aktiv` | **2026-06-01 deaktiviert**; danach nur noch `Kallilabcore` in der Portfreigabenliste sichtbar |
 
 ### Host (lokal beobachtbar)
 
@@ -102,10 +244,11 @@ Aktueller UI-Befund vom 2026-05-27 (`Internet -> Freigaben -> Kallilabcore`):
 |---:|---|---|---|
 | 80/tcp | Traefik | HTTP->HTTPS / ACME | nur LAN, keine WAN-Freigabe noetig |
 | 443/tcp | Traefik | HTTPS | WAN-Freigabe in FRITZ!Box erwartet |
-| 222/tcp | Gitea SSH | Git SSH | WAN-Freigabe in FRITZ!Box erwartet, dokumentierte Ausnahme |
+| 222/tcp | Gitea SSH | Git SSH | nur LAN/Tailscale; keine WAN-Freigabe |
 | 53/tcp+udp | AdGuard | DNS | LAN-only, dokumentierte Ausnahme |
+| 32400/tcp | Plex | Medienserver / Plex Web lokal | LAN/Tailscale direkt; extern nur via Traefik `https://plex.kaleschke.info`, keine WAN-Freigabe fuer 32400 |
 | 8082/tcp | AdGuard Admin | Admin UI | Bind nur `100.80.98.33:8082` (Tailscale), nicht im LAN exponiert |
-| 8181/tcp | InfluxDB 3 Core | LAN Writer fuer Home Assistant | LAN-only, Bind-IP pruefen |
+| 8181/tcp | InfluxDB 3 Core | Home Assistant / Ecowitt Writer | 2026-05-31 effektiv nur `127.0.0.1:8181`, nicht LAN-exponiert |
 
 Pruefkommando:
 
@@ -118,9 +261,9 @@ docker ps --format "{{.Names}}: {{.Ports}}" | sort
 
 | Netz | Status | Bemerkung |
 |---|---|---|
-| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 36 aktive Geraete |
+| LAN | 192.168.178.0/24 | Hauptnetz, Host `192.168.178.58`, FRITZ!Box meldet 35 aktive Geraete |
 | WLAN 2,4 / 5 GHz | aktiv, SSID `Fritzi` | Standard-WLAN, im LAN-Adressbereich, kein eigener Adressraum |
-| Gast-WLAN | **inaktiv** (FRITZ!Box-UI) | Solange inaktiv: kein Gast-Pfad zu LAN-Diensten; AdGuard-Admin-Trennung primaer ueber Tailscale-Bind statt Netzsegmentierung |
+| Gast-WLAN | aktiv, SSID `Fritzi Gastzugang` | FRITZ!Box-Gastnetz ist vom Heimnetz getrennt; Smoke 2026-06-06 vom iPhone bestaetigt keine Erreichbarkeit der getesteten LAN-/Admin-Ziele |
 | IoT-Netz | nicht existent | Keine VLAN-Trennung dokumentiert |
 | Tailscale | aktiv | Operator-Zugang, Host-IP `100.80.98.33` |
 | VLANs | nicht in Nutzung | FRITZ!Box 7590 kann VLAN-Tagging an einzelnen LAN-Ports; aktuell nicht konfiguriert |
@@ -145,14 +288,136 @@ docker network inspect frontend_net | jq '.[0].Containers | keys'
 docker network inspect backend_net | jq '.[0].Internal'
 ```
 
+## SSH-Konfiguration Host
+
+Geprueft 2026-06-06 (read-only), **gehaertet 2026-06-07** via `ssh root@192.168.178.58`.
+
+| Parameter | Ist-Wert (effektiv via `sshd -T`, Stand 2026-06-07) | Soll | Status |
+|---|---|---|---|
+| `Port` | `22` | 22 | ok |
+| `PermitRootLogin` | `prohibit-password` | `prohibit-password` | **gehaertet 2026-06-07** |
+| `PasswordAuthentication` | `no` | `no` | **gehaertet 2026-06-07** |
+| `KbdInteractiveAuthentication` | `no` | `no` | **gehaertet 2026-06-07** (noetig wegen `UsePAM yes`) |
+| `PubkeyAuthentication` | `yes` | `yes` | ok |
+| `PermitEmptyPasswords` | `no` | `no` | ok |
+| `AuthorizedKeysFile` | `.ssh/authorized_keys` | `.ssh/authorized_keys` | ok |
+
+**Hinterlegte SSH-Keys (root):** 3 Keys vorhanden (persistiert unter `/boot/config/ssh/root/authorized_keys`):
+- `root@Kallilabcore` (Host-eigener Key)
+- `michi@Baerchen` (Operator-Workstation)
+- `hetzner-storagebox-maintenance-2026-06-01` (Hetzner-Maintenance-Key)
+
+**Durchgefuehrte Haertung (2026-06-07):** Root-Login ist jetzt key-only,
+Passwort- und Keyboard-Interactive-Auth sind serverseitig abgeschaltet.
+Verifiziert: frischer Key-Login `OK`; `ssh -o PreferredAuthentications=none`
+meldet `Authentications that can continue: publickey`; reiner Passwort-Versuch
+`Permission denied (publickey)`.
+
+**Wichtig — Unraid-Persistenz:** `/etc/ssh/sshd_config` wird beim Boot aus dem
+OS-Image regeneriert (`rc.sshd`: `cp -f /boot/config/ssh/* /etc/ssh/`, danach
+`sshd_build`, das nur `Port`/`ListenAddress`/`AddressFamily` setzt). Die
+Unraid-GUI (**Settings → Management Access → SSH**) bietet nur `Use SSH`/`SSH port`
+an — **`PermitRootLogin`/`PasswordAuthentication` sind dort nicht einstellbar.**
+Persistiert wird daher **upgrade-sicher** ueber einen idempotenten Hook:
+
+- `/boot/config/ssh-harden.sh` — setzt die drei Direktiven idempotent (bestehende
+  aktive Zeile entfernen, genau einmal global vor dem ersten `Match`-Block einfuegen),
+  `sshd -t`-Validierung, Reload nur per `kill -HUP` des Host-`sshd` bei valider Config.
+  Idempotenz belegt: nach mehreren Laeufen je Direktive exakt 1 aktive Zeile, alte
+  `PermitRootLogin yes` entfernt.
+- `/boot/config/go` — ruft `/bin/bash /boot/config/ssh-harden.sh` bei jedem Boot auf.
+
+**Selbst-Verifikation (Syslog, rein informativ, keine Reparatur):** Das Skript
+schreibt nach jedem Lauf die effektiven Auth-Werte (`sshd -T`) nach syslog, z. B.
+`ssh-harden: VERIFY permitrootlogin prohibit-password pubkeyauthentication yes
+passwordauthentication no kbdinteractiveauthentication no`. Damit ist nach jedem
+Boot/Upgrade nachweisbar, ob die Haertung gegriffen hat.
+
+**Post-Upgrade-/Reboot-Check** (manuell, einmal nach jedem Unraid-Upgrade):
+
+```bash
+# A) Effektive Werte direkt abfragen (Soll: prohibit-password / no / no / yes)
+ssh root@192.168.178.58 "sshd -T | grep -Ei 'permitroot|passwordauth|kbdinteractive|pubkey'"
+# B) Oder die automatische VERIFY-Zeile im Syslog lesen (Unraid nutzt rsyslog -> /var/log/syslog, nicht logread)
+ssh root@192.168.178.58 "grep 'ssh-harden' /var/log/syslog | tail -3"
+```
+
+Dieser Weg editiert die **jeweils aktuelle** von Unraid generierte Config nach und
+ueberlebt damit Unraid-Upgrades; findet er die Stock-Zeile nicht (z. B. weil eine
+neue Version schon `prohibit-password` ausliefert), macht der `sed` nichts und
+bricht den Boot nicht (fail-safe Richtung offen, nicht ausgesperrt). Bewusst
+**nicht** der oft empfohlene Weg einer kompletten `/boot/config/ssh/sshd_config`
+auf Flash — der wuerde die Stock-Config einfrieren und beim Upgrade neue Defaults
+verschlucken.
+
+**Rollback:** `go`-Block + `/boot/config/ssh-harden.sh` entfernen, dann
+`cp /boot/config/ssh-harden.sshd_config.bak-20260607 /etc/ssh/sshd_config` und
+`kill -HUP $(cat /var/run/sshd.pid)`. Notzugang ueber Unraid-Konsole/GUI bleibt.
+
+**Abgrenzung:** Ein zweiter `sshd` (`-D -e`) laeuft in einem Docker-Container
+(s6-overlay, moby-Namespace) und bindet **nicht** den Host-`:22`; eigene Config
+im Container, von dieser Haertung unberuehrt.
+
+---
+
+## Post-Upgrade Posture-Recheck — Unraid 7.3.1 (2026-06-07)
+
+Nach dem Major-Upgrade **7.2.4 → 7.3.1** read-only die Host-Listener-Landschaft
+(`ss -tlnp`) gegen die dokumentierten Annahmen geprueft.
+
+**Dokumentierte Ausnahmen verifiziert (alle weiterhin gueltig):**
+
+| Dienst | Soll | Ist nach 7.3.1 | Status |
+|---|---|---|---|
+| InfluxDB 3 | nur `127.0.0.1:8181` | `127.0.0.1:8181` | ✅ |
+| AdGuard-Admin | nur Tailscale `100.80.98.33:8082` | `100.80.98.33:8082` | ✅ |
+| Gitea-SSH `222` | LAN/Tailscale, keine WAN-Freigabe | `0.0.0.0:222` (LAN/TS), WAN am Router zu | ✅ |
+| Traefik `80/443` | einziger Owner | docker-proxy (Traefik) allein | ✅ |
+| libvirt `:53` | darf nicht existieren | **weg** (Fix vom 2026-06-07 haelt) | ✅ |
+
+**Docker-Socket (`/var/run/docker.sock`) — C-3-Kontext:**
+
+| Container | Mount | Bewertung |
+|---|---|---|
+| komodo-periphery | **RW** | dokumentierte Ausnahme (Periphery startet/stoppt Container) |
+| traefik | ro | C-3: Direkt-Mount (ro), nicht ueber Socket-Proxy — offener Audit-Punkt, kein Regress |
+| glances / monitoring-promtail / glance-docker-socket-proxy | ro | unkritisch |
+
+Keine neue RW-Socket-Exposure durch das Upgrade.
+
+**Vorfall-Notiz AdGuard/DNS (Boot-Race, behoben 2026-06-07):** Das Upgrade hatte das
+ungenutzte **libvirt-Default-Netz** auf Autostart gebracht; dessen `dnsmasq` belegte
+beim Boot Port `53` **vor** AdGuard → AdGuards erster Start scheiterte am Bind und
+liess den Container ohne Netz-Anbindung (`Networks={}`, keine Ports) zurueck. Fix:
+`virsh net-autostart default --disable` + `virsh net-destroy default` (kein VM
+betroffen, Liste leer) + AdGuard-Container aus der Compose `--force-recreate`
+(re-attach `dns_net`, `:53` neu veroeffentlicht). DNS danach verifiziert aufloesend.
+`libvirtd` laeuft weiter nur auf `127.0.0.1:16509`.
+
+**Empfehlung (Dauerfix):** Da keine VMs genutzt werden, **Unraid VM Manager → Enable
+VMs = No** — dann startet `libvirtd` gar nicht und der `:53`-Konflikt kann prinzipiell
+nicht wiederkehren. Bis dahin verhindert der abgeschaltete Autostart die Wiederkehr.
+
+**Beobachtungen (kein Regress, Inventar):** SMB (`:445/:139`) und Plex (`*:32400`)
+lauschen auch auf der Tailscale-IP; durch die seit 2026-06-06 tag-restriktive
+Tailnet-ACL akzeptabel.
+
+**SSH-Haertung nach Upgrade:** key-only root unveraendert aktiv und verifiziert
+(`prohibit-password`/`password no`/`kbd no`), go-Hook genau 1× gefeuert — siehe
+Abschnitt „SSH-Konfiguration Host".
+
+---
+
 ## Offene Entscheidungen
 
 | Thema | Status | Naechster Schritt |
 |---|---|---|
 | AdGuard Admin nur via Tailscale | live validiert 2026-05-26 | Compose bindet Admin-Port auf `100.80.98.33:8082`; DNS auf Port 53 funktioniert, LAN-Zugriff auf `192.168.178.58:8082` schlaegt fehl |
-| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-05-28** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigabe-Recht fuer VONETS-Bridge (SolarEdge) deaktiviert. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
+| FRITZ!Box-Portfreigaben mit Repo-Soll abgleichen | **erledigt 2026-06-01** | Bereinigt: `80/tcp` entfernt (Cloudflare-DNS-Challenge ersetzt HTTP-01; Mobilfunk-Test bestaetigt Timeout auf `http://`, `https://` weiter ok). `222/tcp` bleibt bewusst nicht eingerichtet (Tailscale-only-Linie). UPnP-Selbstfreigaben sind aus. Aktiver Soll-Stand: ausschliesslich `443/tcp -> 192.168.178.58`. |
-| FRITZ!OS 8.21 Update | gemeldet | Operator-Aufgabe; vor Update kurzes Service-Fenster planen, weil Reboot WAN/Tailscale-Aufbau unterbricht |
+| FRITZ!Box-Dienste aus dem Internet | **erledigt 2026-06-01** | `Internet -> Freigaben -> FRITZ!Box-Dienste`: HTTPS-Zugriff auf die FRITZ!Box aus dem Internet aus; FTP/FTPS auf Speichermedien aus. |
-| Gast-/IoT-Zugriff auf Admin-Ports | aktuell entschaerft | Gast-WLAN ist inaktiv; bei Aktivierung muessen `192.168.178.58:8082`, `192.168.178.58:8181` und ggf. weitere LAN-Ports per FRITZ!Box-Kindersicherung/Netzwerk-Filter abgesichert werden |
+| FRITZ!OS Update und Konfig-Backup | **erledigt 2026-06-01** | TR-064 meldet `154.08.25`; Konfig-Export liegt extern/off-system in Vaultwarden, Kennwort und Datei bleiben ausserhalb des Repos. |
-| IPv6 Exposure | offen | Router und Traefik/Cloudflare pruefen; Telekom-DSL liefert in der Regel IPv6, FRITZ!Box-Standard-Verhalten klaeren |
+| Gast-/IoT-Zugriff auf Admin-Ports | **validiert 2026-06-06** | Runbook `docs/GUEST_IOT_NETWORK.md` und Checks `ops/maintenance/check-guest-iot-isolation.ps1` sowie `ops/maintenance/check-guest-iot-preflight.sh` vorhanden. LAN-Preflight von `baerchen` gruen: `192.168.178.58:8082` und `:8181` blockiert. Host-Preflight auf Unraid gruen, Report `/mnt/user/backups/restore-reports/guest-iot-preflight-2026-06-06-131316.md`. Gast-WLAN-Smoke per iPhone: `192.168.178.58:8082`, `:8181`, `:222`, `https://192.168.178.58` und `192.168.178.1` nicht erreichbar. |
-| WAN-Ausfallschutz | bewusst nicht eingerichtet | Mobilfunk-Stick-Failover an FRITZ!Box ist nicht aktiv; Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter |
+| IPv6 Exposure | technisch und per UI entschaerft | Public DNS liefert keine AAAA-Records fuer `*.kaleschke.info`; Host hat keine globale Provider-IPv6. TR-064 meldet IPv6-Firewall aktiv und Pinholes grundsaetzlich erlaubt; FRITZ!Box-UI zeigt keine aktiven IPv6-Freigaben, keine Admin-/SSH-Freigaben. |
-| Home Assistant InfluxDB Bind | offen | Effektive Listener-Adresse pruefen |
+| WAN-Ausfallschutz | **geparkt: spaeter evaluieren** (Operator-Entscheidung 2026-06-05) | Mobilfunk-Stick-Failover an FRITZ!Box bleibt vorerst inaktiv. Folgen sind bewusst akzeptiert: Internet-Ausfall = ACME/DDNS pausieren, lokale Apps laufen weiter. Review-Trigger: haeufigere oder laengere DSL-Ausfaelle, oder wenn externer Remote-Zugang (statt nur lokalem Betrieb) geschaeftskritisch wird. Erst dann Mobilfunk-Failover technisch bewerten. |
+| Home Assistant InfluxDB Bind | validiert 2026-05-31 | `docker-proxy` bindet `127.0.0.1:8181`; keine LAN-Exposure. Wenn Home Assistant nicht lokal auf dem Host schreibt, braucht das eine bewusste Bind-Aenderung. |
+| SSH-Haertung Host | **erledigt 2026-06-07** | Root-Login key-only: `PermitRootLogin prohibit-password`, `PasswordAuthentication no`, `KbdInteractiveAuthentication no`. Live gesetzt + verifiziert (Key-Login ok, Passwort-Auth abgelehnt). Persistenz upgrade-sicher ueber `/boot/config/ssh-harden.sh` (idempotent, `sshd -t` vor Reload) aufgerufen aus `/boot/config/go`. GUI bietet diese Optionen nicht. Details im Abschnitt „SSH-Konfiguration Host". |

docs/NEXT_SPRINT_TODO_2026-05-16.md

@@ -1,41 +0,0 @@
-# Aktuelle Restliste - KalliLab CORE
-
-Stand: 2026-05-17
-
-Diese Datei ersetzt die alte Sprint-Liste vom 2026-05-16. Die damaligen Backup-, Posture-, Logging- und Hardening-Bloecke sind weitgehend erledigt oder dokumentiert. Sie bleibt nur als kurze Restliste fuer die naechsten bewussten Arbeitspakete bestehen.
-
-## Erledigt / nicht mehr offen
-
-- Filebrowser-Hardening: breiter Appdata-Mount ist entfernt; Filebrowser mountet nur noch Documents, Photos, Projekte und eigenen App-State.
-- Authelia Argon2id-Haertung: `iterations: 3`, `memory: 65536`, `parallelism: 4`, `key_length: 32`, `salt_length: 16` sind gesetzt.
-- Gitea Webhook-Allowlist: `GITEA__webhook__ALLOWED_HOST_LIST` ist auf `komodo-core,localhost,127.0.0.1,192.168.178.0/24` eingeschraenkt.
-- Backup-Konsistenz: SQLite-/Nextcloud-Dumps, Borg-Scope fuer Nextcloud-Daten, Restore-Matrix und Freshness-Checks sind umgesetzt.
-- Posture-/Cert-/Drift-Checks: Skripte und Unraid User Scripts sind vorhanden und geplant.
-- Monitoring-Zielstack: `monitoring/` buendelt Prometheus, Loki, Promtail, Grafana, node-exporter, cAdvisor und InfluxDB 3 Core im Repo-Zielzustand.
-- Docker-Log-Rotation: Unraid-native Rotation ist dokumentiert; keine separate `/etc/docker/daemon.json` setzen.
-- Disk1-NTFS-Migration Phase 2: am 2026-05-25 abgeschlossen; Disk1 ist XFS, `posture-check` akzeptiert NTFS nicht mehr als Standard.
-
-## Morgen / bewusst spaeter
-
-- Monitoring live finalisieren:
-  - Secrets `monitoring_grafana_admin_password.txt`, `monitoring_grafana_influxdb_token.txt`, `influxdb3_admin_token.json` auf dem Host pruefen/anlegen
-  - `monitoring` in Komodo deployen
-  - alte Stacks `ops/loki` und `ops/grafana-influxdb` nach erfolgreichem Smoke-Test stoppen
-  - `https://monitoring.kaleschke.info`, Prometheus Targets, Loki-Logs und InfluxDB-Datasource pruefen
-- Home Assistant -> InfluxDB finalisieren:
-  - HA-Token/Writer final pruefen
-  - erste Messwerte in InfluxDB verifizieren
-  - Grafana-HA-/Wetter-Dashboard in `monitoring-grafana` aufbauen
-- Hermes VM-Seite:
-  - Runner-VM, echte `.env`, SSH-Key und Dashboard/Gateway final zusammenfuehren
-  - NAS-Stack erst starten, wenn VM-Seite bereit ist
-
-## Verbleibende bekannte Warnings
-
-- `ddns-updater`, `glances`, `scrutiny`: nutzen noch `latest...@sha256`; spaeter durch konkrete Versionstags ersetzen, sofern upstream sinnvoll versioniert.
-- `ops/grafana-influxdb` und `ops/loki`: bleiben nur noch als Rollback-/Migrationsreferenz im Repo, nach Live-Migration nicht parallel betreiben.
-- `scrutiny`: bleibt `privileged: true`; dokumentierte SMART-Ausnahme, spaeter erneut pruefen.
-
-## Regel
-
-Neue Arbeit erst starten, wenn klar ist, ob sie eines der drei Morgen-Themen betrifft oder eine der bekannten Warnings bewusst abbaut.

docs/OFFSITE_BACKUP_OPTIONS.md

@@ -1,140 +0,0 @@
-# Zweites Offsite-Backup-Ziel - Entscheidungsvorlage
-
-Status: **Operator-Entscheidung 2026-05-28: bewusst KEIN zweites Off-site.** Doku bleibt als Begruendungs-Anker und fuer zukuenftige Reviews.
-Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-03** und `docs/AUDIT_2026-05-25_TODO.md` Sprint 7.
-
-## Beschluss 2026-05-28
-
-Aktuelle Backup-Topologie:
-
-| Kopie | Wo | Medium | Standort |
-|---|---|---|---|
-| 1 | Live-Daten Unraid (Cache + Disk1) | NVMe + HDD | Heim |
-| 2 | Borg-Repo lokal `/mnt/user/backups/borg/` | HDD (Disk1) | Heim |
-| 3 | Borg-Repo Hetzner Storagebox | Hetzner | Off-site (DE) |
-| 4 | H:/ Nearline-Pull am Windows-PC | externe HDD | Heim |
-
-**3-2-1-Regel ist erfuellt:** 4 Kopien, 3 Medien, 1 Off-site (Hetzner).
-
-Ein zweites Off-site wuerde **ausschliesslich** das Szenario "Hetzner-Account verloren" zusaetzlich abdecken. Operator-Bewertung: Wahrscheinlichkeit niedrig (etablierter deutscher Anbieter mit Zahlungsweg), Aufwand und laufende Kosten unverhaeltnismaessig zur Risikoreduktion fuer ein privates Familien-Homelab.
-
-Statt zweitem Off-site werden drei Hetzner-Account-Haertungen als Folge-TODOs gefuehrt:
-
-1. Hetzner-Account: starkes, einzigartiges Passwort in Vaultwarden + Backup-Zahlungsweg (zweite Karte/SEPA) + Login-Benachrichtigungen per E-Mail. **Bewusst keine 2FA** (Operator-Entscheidung 2026-05-28 analog zur USV-Risiko-Akzeptanz; 2FA-Aufwand ueberwiegt die fuer ein Familien-Homelab realistische Risiko-Reduktion).
-2. Borg `--append-only`-Mode pruefen (Repo `appdata-critical` laeuft aktuell im Mode `full`). Setup erfolgt server-seitig in Hetzner `~/.ssh/authorized_keys` mit `command="borg serve --append-only"` fuer den Backup-Key. Schuetzt gegen client-seitige Ransomware, die das Repo loeschen wuerde.
-3. H:/ Pull als Windows Scheduled Task aktivieren (Anker `docs/H_DRIVE_NEARLINE_PULL.md`).
-
-Diese drei Massnahmen zusammen schliessen den gleichen Risikoraum wie ein zweites Off-site, ohne neue Provider/Hardware/laufende Kosten.
-
-## Review-Trigger
-
-Diese Entscheidung wird neu bewertet, wenn:
-
-- Hetzner-Account-Probleme tatsaechlich auftreten (Payment-Issue, Login-Sperre)
-- Hetzner als Anbieter strukturelle Probleme zeigt (Insolvenz-Geruechte, AGB-Aenderungen)
-- Im Homelab Daten mit deutlich hoeherem Wiederbeschaffungs-Aufwand dazukommen (z. B. Firefly-III-Finanz-Daten, Smart-Home-Langzeitdaten)
-- Operator-Praeferenzen sich aendern
-
-Wenn dieser Trigger eintritt, sind die drei Optionen rsync.net / BorgBase EU2 / Cold-Wechselplatte weiter unten dokumentiert.
-
----
-
-## Zweck
-
-Aktuell laeuft das Off-site-Backup bei genau einem Anbieter (**Hetzner Storage Box**). Diese Vorlage stellt drei realistische Optionen fuer ein **zweites** Off-site-Ziel gegenueber. Die Entscheidung trifft der Operator; dieses Dokument trifft sie nicht.
-
-`H:/` am Windows-PC bleibt **kein** Offsite-Ersatz (siehe `docs/CAPACITY_AND_LIFECYCLE.md`). H:/ ist Nearline-Kopie am gleichen Standort.
-
-## Anforderungen an das zweite Ziel
-
-| Anforderung | Begruendung |
-|---|---|
-| **anderer Anbieter als Hetzner** | Provider-Risiko (Account-Sperre, Insolvenz, Region-Outage) wird sonst nicht reduziert |
-| **anderer physischer Standort** als Unraid-Host | Brand-/Diebstahl-/Wasser-Schutz |
-| **Borg-kompatibel** (SSH + Repo-Layout) | bestehendes Borg-UI-Setup soll wiederverwendbar bleiben |
-| **bezahlbar im Privatrahmen** | grobe Zielgroesse: < 10 EUR / Monat fuer ~1 TB |
-| **stabil ueber Monate** | wenig Eingriff, keine taeglichen Quirks |
-| **keine Konto-Komplexitaet** | 2FA-Recovery muss sauber, ohne Telefon-Nummer-Hacks etc. moeglich sein |
-
-## Drei Optionen
-
-### Option A - rsync.net Borg-Plan
-
-- **Was:** seit Jahren etablierter Anbieter mit dediziertem Borg-Plan (eingebaute `borg`-Binary, SSH-Account, Snapshot-Schutz).
-- **Zielanbindung:** `borg init --encryption=repokey-blake2 user@hostname:repo`.
-- **Standort:** Schweiz/USA (je nach Konto-Region).
-- **Preis (Stand 2026, grob):** ~10-15 USD pro Monat fuer 1 TB; Mindestbestelldauer keine.
-- **Vorteile:** Borg-First, ZFS-Snapshots als zusaetzlicher Schutz vor Repo-Loeschung, sehr lange Track-Record, keine SMB-/CIFS-Quirks.
-- **Nachteile:** USD-Preis, Standort ausserhalb EU je nach Konto, etwas teurer als reine Storage Boxes.
-- **Konto-Risiko:** unabhaengig von Hetzner-Konto.
-
-### Option B - BorgBase EU2 (zweite Region beim gleichen Borg-Spezialisten)
-
-- **Was:** BorgBase ist Borg-as-a-Service mit mehreren Regionen.
-- **Zielanbindung:** identisch zu bestehendem Borg-UI-Pfad.
-- **Standort:** zweite EU-Region als EU1.
-- **Preis (Stand 2026, grob):** ~10 EUR / Monat fuer ~1 TB.
-- **Vorteile:** identisches Borg-Modell, geringer Lernaufwand, einfache Web-UI.
-- **Nachteile:** Anbieter-Risiko nicht vollstaendig getrennt (gleicher Anbieter, andere Region). Bei Account-Sperre/Insolvenz waeren beide Ziele gleichzeitig betroffen.
-- **Konto-Risiko:** **gleicher** Anbieter, **anderes** Geo-Risiko.
-
-### Option C - Rotierende Cold-Wechselplatte ausser Haus
-
-- **Was:** zweite externe HDD (z. B. 2x WD Elements 4 TB), die im monatlichen Wechsel zwischen Heim-LAN und vertrauter dritter Person (Familie, Schliessfach, Buero) rotiert.
-- **Zielanbindung:** Borg-Repo lokal auf der eingesteckten Platte; Backup-Lauf nur wenn die Platte gerade vor Ort ist.
-- **Standort:** echtes Ausserhaus, dazwischen offline (Air-Gap).
-- **Preis (einmalig):** zwei Platten ~250 EUR, keine laufenden Kosten.
-- **Vorteile:** echtes Air-Gap, keine Provider-Abhaengigkeit, keine Bandbreitenfrage, keine Konto-Risiken.
-- **Nachteile:** manuelle Disziplin noetig, Recovery-Zeit haengt davon ab, dass die Platte gerade erreichbar ist. Nicht so taggenau wie Cloud-Borg.
-- **Konto-Risiko:** keines (keine Provider-Bindung).
-
-## Bewertung gegen die Anforderungen
-
-| Anforderung | Hetzner (Ist) | Option A rsync.net | Option B BorgBase EU2 | Option C Cold-Platte |
-|---|---|---|---|---|
-| Anderer Anbieter | - | ja | nein (gleicher) | ja (keiner) |
-| Anderer Standort | - | ja | ja | ja |
-| Borg-kompatibel | ja | ja | ja | ja |
-| Preis < 10 EUR/Monat | ja | grenzwertig | ja | einmalig ~250 EUR |
-| Stabilitaet | hoch | hoch | hoch | Operator-Disziplin abhaengig |
-| 2FA/Konto-Recovery | OK | OK | OK | n/a |
-
-## Empfehlung (nicht Entscheidung)
-
-Wenn der Operator die geringste Bedienung bei maximalem Provider-getrennten Schutz will: **Option A rsync.net**. Echte Anbieter-Trennung gegenueber Hetzner, Borg-First-Anbieter, ZFS-Snapshot-Schutz, keine zusaetzliche Hardware noetig.
-
-Wenn Air-Gap und Null-Provider-Abhaengigkeit am wichtigsten sind und der Operator die monatliche Rotation tatsaechlich diszipliniert macht: **Option C Cold-Platte**.
-
-**Option B (BorgBase EU2) wird nicht empfohlen** als zweites Ziel, weil das das Provider-Risiko nicht reduziert.
-
-## Was vor einer Buchung zu tun ist
-
-1. Operator-Entscheidung Option A vs. C dokumentieren (kein Provider-Kontakt vor Entscheidung).
-2. Falls Option A:
-   - Konto bei rsync.net anlegen, Borg-Plan waehlen.
-   - SSH-Key vom Borg-UI-Container exportieren bzw. dediziertes Key-Pair erzeugen.
-   - `borg init` gegen das neue Repo durchfuehren (separate Passphrase oder gleiche - bewusst entscheiden).
-   - Borg-UI um zweites Repository erweitern (separater Eintrag, kein Replace).
-   - Schedule pruefen: erstes Vollbackup als One-Shot, danach inkrementell.
-   - `docs/SECRETS_MAP.md` und `docs/EXTERNAL_DEPENDENCIES.md` um neuen Provider ergaenzen.
-   - `docs/RESTORE_MATRIX.md` und `docs/STORAGE_LAYOUT.md` Backup-Ziel-Liste aktualisieren.
-3. Falls Option C:
-   - zwei Platten beschaffen, Filesystem XFS oder ext4 (kein NTFS).
-   - Rotations-Plan in `docs/STORAGE_LAYOUT.md` §8.1 ergaenzen.
-   - Borg-Repo-Init pro Platte; Borg-UI um lokales Repo erweitern (nur aktiv wenn Platte eingesteckt).
-   - Operator-Disziplin: monatliche Rotation als Kalender-Reminder.
-
-## Was bewusst NICHT in dieser Vorlage steht
-
-- Konkrete Hetzner-Konto-Daten, rsync.net-Accountnamen, IBANs, Telefonnummern. Diese Daten gehoeren nirgendwo in dieses Repo.
-- Borg-Passphrasen. Bleiben ausserhalb des Repos.
-- "Migrieren weg von Hetzner" als Option. Hetzner bleibt; das zweite Ziel ist Ergaenzung, nicht Ablosung.
-
-## Offene Punkte
-
-| Status | Punkt | Naechster Schritt |
-|---|---|---|
-| offen | Entscheidung Option A vs. C | Operator |
-| offen | Budget-Freigabe | Operator |
-| offen | Provider-/Hardware-Beschaffung | nach Entscheidung |
-| offen | Schedule-Anpassung in `ops/borg-ui` | nach Provider-Bereitstellung |

docs/README.md

@@ -0,0 +1,62 @@
+# Documentation Index
+
+Stand: 2026-06-05
+
+Diese Datei trennt aktive Betriebsdokumentation von historischer Arbeitsdoku. Neue operative Dokumente duerfen nur in `docs/` liegen, wenn sie heute als Einstieg, Runbook, Inventar oder offene Arbeitsliste gebraucht werden. Erledigte Audits, Chat-Handoffs, Prompt-Dateien und abgeschlossene Plaene bleiben in der Git-Historie, aber nicht als dauerhafte Arbeitskopie.
+
+## Pflicht-Einstieg
+
+| Datei | Zweck |
+|---|---|
+| `../README.md` | kurzer Repo-Einstieg |
+| `../HOMELAB_ARCHITECTURE_MASTER_V2.md` | Architektur-Quelle fuer Netz, Zugriff und Ausnahmen |
+| `WORKFLOW.md` | verbindlicher GitOps-/No-Drift-Ablauf |
+| `REPO_MAP.md` | technische Landkarte des Repositories |
+| `SERVICE_CATALOG.md` | produktiver Service-Katalog |
+
+## Betrieb und Recovery
+
+| Datei | Zweck |
+|---|---|
+| `DISASTER_RECOVERY.md` | Wiederanlauf nach Host-/Systemausfall |
+| `RESTORE_MATRIX.md` | Restore-Quellen, Dumps, Secrets und Smoke-Tests je Dienst |
+| `RESTORE_HANDBOOK.md` | praktische Restore-Anleitung |
+| `SERVICES_RECOVERY.md` | Gitea-/Komodo-/Services-Bootstrap |
+| `ROLLBACK.md` | Rueckweg bei GitOps-/Deploy-Fehlern |
+| `GITOPS_DRIFT_RUNBOOK.md` | Pflichtmatrix bei Drift zwischen Git, Komodo, Docker und Host |
+
+## Inventare und Policies
+
+| Datei | Zweck |
+|---|---|
+| `STORAGE_LAYOUT.md` | verbindliche Storage-/Share-/Pfad-Regeln |
+| `SECRETS_MAP.md` | Secret-Namen, Speicherorte und Einbindungsarten ohne Werte |
+| `AUTHELIA_OIDC_PLAN.md` | Plan & Runbook fuer app-uebergreifendes SSO via Authelia OIDC |
+| `HARDWARE_INVENTORY.md` | Host-, Disk-, SMART-, USV- und Power-Baseline |
+| `NETWORK_INVENTORY.md` | Router, DNS, Tailscale, Portfreigaben und Netzthemen |
+| `GUEST_IOT_NETWORK.md` | Sicherer Ablauf fuer FRITZ!Box-Gastnetz / IoT-Isolation |
+| `EXTERNAL_DEPENDENCIES.md` | Provider, Konten und externe Abhaengigkeiten |
+| `EXTERNAL_OPERATOR_RUNBOOK.md` | Hetzner-/Borg-/FRITZ!Box-Betreibercheck |
+| `CAPACITY_AND_LIFECYCLE.md` | Kapazitaet, Wachstum und Upgrade-Trigger |
+
+## Monitoring und Automatisierung
+
+| Datei | Zweck |
+|---|---|
+| `ALERT_RULES.md` | Prometheus-/ntfy-Regeln und Handlungslogik |
+| `RENOVATE.md` | Self-hosted Renovate gegen Gitea |
+| `HOME_ASSISTANT_INFLUXDB_ECOWITT.md` | Archivierter Entwurf: Home Assistant -> InfluxDB 3 -> Grafana; nicht aktiv seit Crash |
+| `H_DRIVE_NEARLINE_PULL.md` | Windows-H:/ Nearline-Pull fuer kritische Restore-Artefakte |
+
+## Nutzer- und Planungsdoku
+
+| Datei | Zweck |
+|---|---|
+| `FAMILY_ONBOARDING.md` | familienverstaendliche Nutzungsdoku |
+| `AUDIT_2026-05-25_TODO.md` | kompakte Restliste aus dem Audit-Zyklus |
+| `MASTER_TODO.md` | zentrale operative Master-To-do-Liste ueber alle Bereiche |
+| `WEEKEND_EXECUTION_PLAN_2026-06-05.md` | Owner-Aufteilung und Wochenendplan fuer Todo-Abschluss |
+| `WEEKEND_STATUS_2026-06-05.md` | kurzlebiges Arbeitsboard fuer den laufenden Wochenend-Sprint |
+| `AI_CONTEXT.md` | kompakter Kontext fuer KI-Agenten |
+
+Windows-Neuaufsetzen-Dokumente liegen nicht mehr in `docs/`, sondern im fachlich passenden Ordner `../ops/windows-reinstall/docs/`.

docs/RECOVERY_HANDOFF_2026-05-15.md

@@ -1,89 +0,0 @@
-# Recovery Handoff - KalliLab CORE - 2026-05-15
-
-Zweck: Startpunkt fuer einen neuen Chat, ohne das komplette Repo erneut zu lesen.
-
-## Kontext
-
-- Incident: NTFS-Cache-Vorfall ab 2026-05-11.
-- Host: Unraid `Kallilabcore`, SSH `root@192.168.178.58`.
-- Root Cause: Cache war NTFS/ntfs3; Disk1 ist noch NTFS/ntfs3 und wird spaeter separat migriert.
-- Recovery-Prinzip: `docs/STORAGE_LAYOUT.md` ist bindend. Zum Zeitpunkt dieses Handoffs hiess die Datei noch `docs/STORAGE_LAYOUT.draft.md`.
-- Keine Stacks starten, wenn ein Pfad/Setting gegen Storage Layout, Restore Matrix oder Architecture Master verstoesst.
-
-## Host-Zustand
-
-- Cache wurde erfolgreich von NTFS auf XFS neu formatiert.
-- Verifiziert: `/mnt/cache` ist XFS auf `/dev/nvme0n1p1`.
-- Disk1 bleibt vorerst NTFS auf `/mnt/disk1`; Migration ist Phase 2 nach stabilem Cache-Betrieb.
-- Docker und Libvirt wurden nach dem Format wieder gestoppt.
-- `/mnt/user/appdata` ist leer bzw. nur Basisverzeichnis; produktive Appdaten sind noch nicht restored.
-- Share-Settings wurden nach Storage Layout korrigiert:
-  - `appdata`, `system`, `domains`: cache `only`
-  - `services`, `documents`, `photos`, `backups`, `media`, `finance`, `projekte`: cache `no`, include `disk1`
-  - `isos`: cache `yes`
-- Backup alter Share-Configs: `/boot/config/shares.bak-20260515-pre-storage-layout`
-
-## Image und Backups
-
-- Full NVMe image liegt auf Windows `H:\kallilab-recovery\2026-05-14\nvme0n1-full-20260514.img`.
-- `dd` exit code war `0`; Image-Groesse/Padding geprueft; Source-Raw-Hash war fertig.
-- Image-Data-Hash wurde aus Zeitgruenden bewusst abgebrochen. Risiko wurde als ca. 1-3 Prozent eingeschaetzt.
-- Hetzner-Borg-Archiv `Taegliche-Sicherung-2026-05-10T04:30:52.050` wurde als lesbare Recovery-Quelle verifiziert.
-- Verifiziert wurden u. a. Vaultwarden SQLite, Gitea SQLite, Postgres-Dumps und Komodo Mongo-Archiv-Header.
-- Lokaler Verify-Auszug liegt unter `H:\kallilab-recovery\2026-05-14\borg-verify-may10`.
-
-## Entscheidungen seit dem Cache-Rebuild
-
-- WD MyBookLive Duo wird komplett aus dem Setup entfernt.
-- Backrest wird komplett aus dem aktiven Setup entfernt.
-- Borg ist alleinige Backup-Technologie.
-- Appdata Backup Plugin bleibt deaktiviert; WD-Ziele wurden aus aktiver Host-Konfiguration geleert.
-- Unassigned Devices SMB-Remote fuer `//MYBOOKLIVEDUO/Public` wurde aus aktiver Host-Konfiguration entfernt.
-- Backrest User Script `check_backrest_hetzner` wurde aus Schedule/Cron entfernt.
-- Host-Konfig-Backup fuer diese Bereinigung: `/boot/config/cleanup-backup-20260515-remove-wd-backrest`
-
-## Repo-Aenderungen im aktuellen Arbeitsbaum
-
-Backrest wurde aus dem aktiven Zielbild entfernt:
-
-- `ops/backrest/docker-compose.yml` geloescht
-- `HOMELAB_ARCHITECTURE_MASTER_V2.md` aktualisiert
-- `docs/REPO_MAP.md` aktualisiert
-- `docs/SERVICE_CATALOG.md` aktualisiert
-- `docs/RESTORE_MATRIX.md` aktualisiert
-- `docs/AI_CONTEXT.md` aktualisiert
-- `docs/DISASTER_RECOVERY.md` aktualisiert
-- `ops/borg-ui/BACKUP_SCOPE.md` aktualisiert
-- `ops/hermes-agent/services.json` aktualisiert
-- `ops/hermes-agent/services.yaml` aktualisiert
-- `ops/policy-checks/last-report.md` aktualisiert
-
-Verifikation:
-
-- `rg "/mnt/(cache|disk1|disks|remotes)" -g docker-compose.yml -g compose.yaml -g *.yml -g *.yaml` findet keine aktiven Compose/YAML-Treffer.
-- `rg "ops/backrest|backrest.kaleschke|/mnt/user/appdata/backrest|192.168.178.86|MYBOOKLIVEDUO|WD-DUO"` findet nur historische/gewollte Hinweise.
-- `python -m json.tool ops/hermes-agent/services.json` ok.
-- `ops/hermes-agent/services.yaml` YAML ok.
-- `ops/policy-checks/check_repo.ps1` ok: 29 Compose-Dateien, 0 Critical, 4 Warnings.
-
-## Wichtigste Stop-Regeln
-
-- Keine Container starten, solange Core-Pfade oder Share-Settings nicht gegen Storage Layout geprueft sind.
-- Keine Backrest-/WD-Referenzen reaktivieren.
-- Keine Bind-Mounts auf `/mnt/cache`, `/mnt/disk1`, `/mnt/disks`, `/mnt/remotes`.
-- Keine Schreibaktionen auf Disk1 ausser bewusst noetig; Disk1 ist noch NTFS.
-- Komodo nur gemeinsam und explizit anfassen.
-- Erst Daten/Secrets restoren, dann Stacks einzeln starten und smoke-testen.
-
-## Naechster sinnvoller Schritt
-
-1. Repo-Aenderungen kurz reviewen und committen/pushen, bevor Komodo wieder produktiv wird.
-2. DNS-Basis wiederherstellen:
-   - AdGuard: `/mnt/user/appdata/adguard/conf` aus Borg oder Image restoren; `work` kann frisch sein.
-   - Unbound: `/mnt/user/appdata/unbound/config` aus Borg oder Image restoren.
-   - Danach nur AdGuard + Unbound starten und DNS testen.
-3. Danach Traefik + Authelia + Gitea/Vaultwarden in kleinen Schritten.
-
-## Startprompt fuer neuen Chat
-
-Lies zuerst `docs/RECOVERY_HANDOFF_2026-05-15.md`, dann `docs/STORAGE_LAYOUT.md`, `docs/RESTORE_MATRIX.md` und nur die Compose-Dateien des naechsten betroffenen Stacks. Fuehre den KalliLab-CORE-Restore token-sparend fort. Nichts erfinden, keine Container starten, wenn etwas gegen Storage Layout verstoesst. Backrest und WD MyBookLive Duo sind entfernt und duerfen nicht wieder ins Setup.

docs/RENOVATE.md

@@ -1,7 +1,7 @@
 # Renovate Bot - Self-hosted gegen Gitea
 
-Status: **vorbereitet 2026-05-29**; PAT-Setup und Cron-Aktivierung sind Operator-Schritte.
+Status: **live seit 2026-05-29**; PAT, State-Verzeichnis und Cron sind auf dem Host aktiv.
-Audit-Bezug: `docs/AUDIT_2026-05-25.md` Finding **F-12**.
+Audit-Bezug: Mai-2026-Audit Finding **F-12**.
 
 ## Zweck
 
@@ -13,12 +13,12 @@ Bewusst kein Auto-Merge: jede PR braucht eine Operator-Sichtpruefung und einen M
 
 - **Image:** `renovate/renovate:41` (versioniert, kein latest)
 - **Lauf:** ein-shot pro Cron-Tick, danach beendet sich der Container; persistente State liegt in `/mnt/user/services/renovate/state/`
-- **Schedule:** alle 6 Stunden (User-Script `renovate-six-hourly`)
+- **Schedule:** alle 6 Stunden per Unraid User-Script `renovate-six-hourly` (`20 */6 * * *`)
 - **Plattform:** Gitea via `https://git.kaleschke.info/api/v1`
 - **Authentifizierung:** Gitea-PAT als Host-Secret-Datei
 - **Konfiguration:** `renovate.json` im Repo-Root
 
-## Operator-Setup (einmalig, ~10 Minuten)
+## Operator-Setup (historisch, einmalig)
 
 ### Schritt 1 - Service-Account in Gitea
 
@@ -87,19 +87,43 @@ Script:      bash /mnt/user/services/homelab-infra/ops/renovate/run-renovate.sh
 |---|---|---|
 | Major-Updates | `groupName: major-updates`, `automerge: false` | Eine gesammelte PR pro Lauf mit allen Major-Updates, manueller Merge |
 | Minor + Patch + Digest fuer Docker-Compose | `groupName: minor-and-patch-updates`, `automerge: false` | Eine gesammelte PR; Operator merged manuell |
-| Tier-1-Datenhalter (Postgres, Mongo, Redis, pgvecto-rs) | `groupName: null`, eigener Label | Einzelne PRs ohne Group, hoehere Sichtbarkeit |
+| Tier-1-Datenhalter (Postgres, Mongo, Redis, Immich-Postgres) | `groupName: null`, eigener Label | Einzelne PRs ohne Group, hoehere Sichtbarkeit |
 | Komodo-Major-Updates | `enabled: false` fuer matchPackageNames + matchUpdateTypes major | Komodo bleibt auf `:2`, wird nicht versehentlich auf `:3` migriert |
 | Lock-File-Maintenance | `lockFileMaintenance.enabled: false` | Renovate macht keine reinen Lock-File-Refreshs |
 | Schedule | `extends ["schedule:weekly"]` | Renovate-Engine prueft, aber PRs/Updates folgen Wochen-Profilen wo sinnvoll |
 | Dependency Dashboard | aktiv | Gitea-Issue, die alle ausstehenden Updates auflistet |
 | Onboarding-PR | `onboarding: false` | Keine `Configure Renovate`-Onboarding-PR; wir nutzen die Repo-`renovate.json` direkt |
-| Ignore-Pfade | `_archive`, `ops/grafana-influxdb`, `ops/loki` | Renovate scant alte/abgeloeste Stacks nicht |
+| Ignore-Pfade | `_archive`, `ops/grafana-influxdb`, `ops/loki`, `ops/komodo` | Renovate scant alte/abgeloeste Stacks nicht; `ops/komodo` ist bewusst raus (siehe unten) |
 
-## Erwartete erste PRs
+## Ausnahme: komodo-Stack ist inline-verwaltet, nicht git-deployed
+
+Der `komodo`-Stack (Komodo-Core/Mongo/Periphery, Datei `ops/komodo/docker-compose.yml`) wird **nicht aus diesem Repo deployed**. In Komodo ist der Stack als **inline `file_contents`** (UI-defined) gespeichert (`repo` leer, `files_on_host=false`, `has_inline_file_contents=true`) und hat bewusst `webhook_enabled=false`, damit Komodo sich nicht selbst per Webhook recreated (Bootstrap-/Henne-Ei-Fall).
+
+Konsequenz: Ein Renovate-PR auf `ops/komodo/docker-compose.yml` wirkt zur Laufzeit **nicht** (Komodo deployt aus seiner Inline-Definition) und erzeugt nur Git↔Komodo-Scheinsicherheit. Deshalb steht `ops/komodo/**` in `ignorePaths`. Die Repo-Datei bleibt als Doku/Spiegel und traegt den aktuell real laufenden Digest.
+
+Befund-Datum 2026-06-10: Renovate-PR #13 (mongo-8.0.23 Digest-Refresh) wurde gemergt, wirkte aber nicht; der Digest wurde im Repo auf den laufenden Stand zurueckgesetzt und der Pfad ausgenommen. Echte Updates des komodo-Stacks laufen bis auf Weiteres manuell ueber Komodo (Inline-Compose anpassen) bzw. spaeter via Migration auf git-backed (eigener Aenderungsblock).
+
+## Aktueller Betriebsstand
+
+Erstlauf 2026-05-29 erfolgreich: Renovate erzeugte das Dependency Dashboard und die ersten fuenf PRs. Diese wurden am 2026-05-31 manuell gemerged, deployed und danach in Gitea geschlossen. Die erledigten Branches wurden anschliessend remote geloescht:
+
+- `renovate/mongo-7.0.32`
+- `renovate/postgres-17.9`
+- `renovate/minor-patch-updates`
+- `renovate/mongo-7.x`
+- `renovate/postgres-17.x`
+
+Stand nach den 2026-05-31-Migrationen: PostgreSQL 18, Redis 8 und Immich-Postgres mit VectorChord sind produktiv ausgerollt und in `renovate.json` per `allowedVersions` auf die jeweiligen Major-/Image-Schienen begrenzt. Die Renovate-PRs #9 `renovate/postgres-18.x` und #10 `renovate/redis-8.x` wurden deshalb am 2026-05-31 geschlossen statt gemerged.
+
+Grafana 13 wurde anschliessend manuell aus #7 `renovate/major-major-updates` uebernommen, vor dem Recreate mit `grafana.db`-/Plugin-Backup gesichert, auf `grafana/grafana:13.0.1` deployed und verifiziert (`/api/health` 13.0.1, 3 Datasources, 4 Dashboards in Unified Storage). #7 wurde danach geschlossen statt gemerged.
+
+Komodo-Mongo laeuft bereits auf der erlaubten MongoDB-8.0-Schiene; ein offener Mongo-8-Renovate-PR ist aktuell nicht vorhanden.
+
+## Erwartete erste PRs (historisch)
 
 Beim Erstlauf wird Renovate vermutlich PRs fuer einige der digest-gepinnten Images oeffnen, weil diese Digests seit Wochen nicht erneuert wurden. Reihenfolge der Sichtpruefung:
 
-1. **Stateful Tier-1 zuerst, einzeln**: Postgres, Redis, Mongo, pgvecto-rs - jeder eigener PR, einzeln pruefen und mergen. Smoke-Test nach Merge ueber Komodo-Webhook-Deploy beobachten.
+1. **Stateful Tier-1 zuerst, einzeln**: Postgres, Redis, Mongo, Immich-Postgres - jeder eigener PR, einzeln pruefen und mergen. Smoke-Test nach Merge ueber Komodo-Webhook-Deploy beobachten.
 2. **Gruppe minor-and-patch-updates**: Alle anderen Docker-Compose-Images zusammen. Wenn der Diff vernuenftig aussieht, mergen.
 3. **Gruppe major-updates**: Erst nach Operator-Sichtpruefung pro Image, ggf. zurueckstellen oder manuell entscheiden.
 

docs/REPO_MAP.md

@@ -1,254 +1,57 @@
 # Repository Map
 
-Stand: 2026-05-23
+Stand: 2026-05-31
 
-Diese Datei ist eine technische Landkarte des Repositories. Sie wurde aus Markdown-Dokumenten, `docker-compose.yml`-Dateien, Env-Beispielen, Traefik-Dynamic-Configs, Komodo/Periphery-Dateien und Skripten abgeleitet. Sie beschreibt den Repo-Sollzustand, nicht zwingend den Live-Zustand auf dem Host.
+Kurzkarte des Repositories. Diese Datei ist bewusst kein zweites Handbuch; fuer
+Details gilt immer die betroffene Compose-Datei oder das jeweilige Runbook.
 
-Secret-Werte werden hier nicht dokumentiert. Aufgefuehrt werden nur Variablennamen, Secret-Namen und Pfade.
+## Top-Level
-
-## Ordnerstruktur
 
 | Pfad | Zweck |
 |---|---|
-| `apps/` | Produktive Anwendungen und vorbereitete App-Stacks |
+| `apps/` | produktive Anwendungen und vorbereitete App-Stacks |
 | `core/` | Basisdienste, aktuell Gitea |
-| `docs/` | Betriebsdokumentation, Restore, Rollback, GitOps-Regeln |
+| `docs/` | aktive Betriebsdoku, Restore, Inventare, Arbeitsregeln |
-| `env/` | globale nicht geheime Beispiel-Env-Dateien |
+| `env/` | nicht geheime Beispiel-Env-Dateien |
-| `host-services/` | Host-nahe Dienste mit direkten Ports oder Host-Netz |
+| `host-services/` | host-nahe Dienste mit direkten Ports oder Host-Netz |
 | `infra/` | technische Infrastruktur wie PostgreSQL, Redis, DDNS |
-| `ops/` | Operations-, Backup-, Monitoring- und Admin-Tools |
+| `monitoring/` | Prometheus, Grafana, Loki, InfluxDB 3 Core |
-| `services/` | Host-seitige Betriebsskripte und Recovery-kritische Service-Hilfen |
+| `ops/` | Admin-, Backup-, Restore- und Wartungswerkzeuge |
-| `security/` | Identity/Security-Dienste wie Authelia und Vaultwarden |
+| `security/` | Authelia, Vaultwarden und Security-Konfiguration |
-| `traefik/` | Reverse Proxy Compose und dynamic File-Provider-Konfiguration |
+| `services/` | Host-seitige Betriebsskripte und Recovery-Hilfen |
+| `traefik/` | Reverse Proxy und dynamic File-Provider-Konfiguration |
 
-## Wichtige Dokumente
+## Einstiegspunkte
 
-| Datei | Bedeutung |
+| Datei | Wann lesen |
 |---|---|
-| `README.md` | Einstieg und Kurzueberblick |
+| `README.md` | Repo-Einstieg |
-| `HOMELAB_ARCHITECTURE_MASTER_V2.md` | operative Architektur-Quelle fuer Netzwerk, Zugriff und Ausnahmen |
+| `HOMELAB_ARCHITECTURE_MASTER_V2.md` | Architektur, Netzmodell, Ausnahmen |
-| `docs/WORKFLOW.md` | GitOps-/No-Drift-Arbeitsregeln |
+| `docs/WORKFLOW.md` | vor operativen Aenderungen |
-| `docs/GITOPS_DRIFT_RUNBOOK.md` | Pflichtmatrix fuer Git/Gitea/Komodo/Docker/Host-Drift |
+| `docs/SERVICE_CATALOG.md` | Service-Zweck, Pfade, Besonderheiten |
-| `docs/DISASTER_RECOVERY.md` | Wiederanlauf nach Host-/Systemausfall |
+| `docs/DISASTER_RECOVERY.md` | echter Wiederanlauf |
-| `docs/RESTORE_MATRIX.md` | Restore-Quellen, Dump-Artefakte und Smoke-Tests je Dienst |
+| `docs/RESTORE_MATRIX.md` | Restore-Quelle je Dienst |
-| `docs/SERVICES_RECOVERY.md` | Recovery-kritische `/mnt/user/services`-Pfade, Gitea-Mirror und Komodo-Bootstrap |
+| `docs/SECRETS_MAP.md` | Secret-Namen und Pfade ohne Werte |
-| `docs/STORAGE_LAYOUT.md` | verbindliche Storage-/Share-/Pfad-Konstitution |
+| `docs/GITOPS_DRIFT_RUNBOOK.md` | Git/Gitea/Komodo/Docker/Host-Drift |
-| `docs/HARDWARE_INVENTORY.md` | Hardware-, Disk-, SMART-, USV- und Strom-Inventar |
+| `docs/AUDIT_2026-05-25_TODO.md` | aktuelle Restliste |
-| `docs/NETWORK_INVENTORY.md` | Router, DNS, Tailscale, Portfreigaben und Netztrennung |
+| `docs/DR_WORKSTATION_SETUP.md` | Schritt-fuer-Schritt-Runbook fuer den DR-Gaming-PC (WSL2 + Borg-Client + SSH-Keys) |
-| `docs/EXTERNAL_DEPENDENCIES.md` | Externe Provider, Konten, Ausfall-Szenarien und kritische Off-Repo-Abhaengigkeiten |
+| `docs/runbooks/komodo-bulk-deploy-dns.md` | Bulk-Deploy-Pulls scheitern an DNS, wenn AdGuard im selben Batch recreated wird |
-| `docs/CAPACITY_AND_LIFECYCLE.md` | Capacity-Schwellen, Wachstum, Upgrade-Trigger und Restore-Zeitziele |
-| `docs/FAMILY_ONBOARDING.md` | Familienorientierte Nutzungsdoku ohne Operator-Details |
-| `docs/FAMILY_VIEW_DASHBOARD.md` | Spezifikation fuer das Grafana Family-View-Dashboard (Doku-only, kein JSON) |
-| `docs/RESTORE_DRILL_ROUTINE.md` | Quartalsweise Restore-Drill-Routine, Tier-Belegung, DR-Sanity-Check |
-| `docs/IMMICH_RESTORE_TEST.md` | Operator-Overview Immich-Restore-Test, Erstlauf 2026-05-27 erfolgreich |
-| `docs/RENOVATE.md` | Self-hosted Renovate gegen Gitea (Setup + Wartung) |
-| `docs/FRITZBOX_PORT_CORRECTION_PLAN.md` | Vorbereitungs-Doku fuer FRITZ!Box-Portfreigaben-Korrektur (kein Router-Eingriff) |
-| `docs/OFFSITE_BACKUP_OPTIONS.md` | Entscheidungsvorlage zweites Offsite-Backup-Ziel (rsync.net vs. BorgBase EU2 vs. Cold-Platte) |
-| `docs/AUDIT_2026-05-25_TODO.md` | Operative Arbeitsliste aus dem Audit vom 2026-05-25; Authelia-2FA bewusst geparkt |
-| `docs/ALERTING_MAP.md` | ntfy Topic-Konvention und Sender-Mapping fuer Homelab-Alerts |
-| `docs/ROLLBACK.md` | Rueckweg bei Fehlern im GitOps-Betrieb |
-| `docs/SECRETS_MAP.md` | Secret-Namen, Pfade und Einbindungsarten ohne Werte |
-| `docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.md` | Home Assistant -> InfluxDB 3 -> Grafana Ablauf |
-| `docs/AI_CONTEXT.md` | Gesamtverstaendnis fuer KI-Agenten |
-| `docs/SERVICE_CATALOG.md` | produktiver Service-Katalog |
 
-## Relevante Nicht-Compose-Dateien
+## Wichtige Skripte
 
-| Datei | Zweck / Hinweis |
+| Datei | Zweck |
 |---|---|
-| `traefik/dynamic/middlewares.yml` | zentrale `secure-headers` und `authelia` ForwardAuth Middleware; manuelle Host-Sync-Ausnahme |
+| `ops/borg-ui/scripts/pre-backup-dumps.sh` | Dump-Erzeugung vor Borg |
-| `traefik/dynamic/dashboards.yml` | leer; File-Provider-Platzhalter |
+| `ops/borg-ui/scripts/gitea-bundle-mirror.sh` | Gitea-Bundles fuer DR |
-| `traefik/dynamic/tls.yml` | leer; File-Provider-Platzhalter |
+| `ops/restore-tests/run-restore-checks.sh` | Restore-Test-Einstieg |
-| `security/authelia/configuration.yml` | versionierte Authelia-Baseline fuer nicht geheime ACL-/Session-/Storage-Einstellungen; manuelle Host-Merge-Pflicht, User-Daten, OIDC-Client-Konfiguration und Secret-Werte bleiben ausserhalb von Git |
+| `ops/restore-tests/schedule.md` | Restore-Test-Kadenz |
-| `monitoring/prometheus/prometheus.yml` | Prometheus Scrape-Konfiguration fuer dedizierten Monitoring-Stack |
+| `services/posture-check/posture-check.sh` | Host-Posture-Check |
-| `monitoring/loki/loki-config.yml` | Loki Filesystem/Retention-Konfiguration fuer dedizierten Monitoring-Stack |
+| `services/posture-check/export-prometheus-textfile.sh` | Borg-/Container-/Drift-Metriken |
-| `monitoring/promtail/promtail-config.yml` | Promtail Docker-Socket-Discovery fuer dedizierten Monitoring-Stack |
+| `services/authelia-diff.sh` | Authelia ACL Repo-zu-Host-Vergleich |
-| `monitoring/grafana/provisioning/*` | Grafana Datasource-/Dashboard-Provisioning fuer Prometheus und Loki |
+| `ops/h-drive-nearline/pull-critical-backups.ps1` | H:/ Nearline-Pull |
-| `ops/glance/config/glance.yml` | Glance Dashboard-Konfiguration fuer Homelab-Monitore, Internet-/DNS-/VPN-Widgets, Community-Widgets, Docker-Containergruppen, Zeitfortschritt, Host-Snapshot, Bookmarks und zweite Infrastruktur-Seite |
-| `ops/borg-ui/scripts/pre-backup-dumps.sh` | Host-seitiges Dump-Skript fuer PostgreSQL, SQLite-Container-Dumps und Komodo Mongo |
-| `services/posture-check/posture-check.sh` | Host-seitiger Posture-Check fuer Filesystem, Mover-Drift, NVMe-SMART, Fuellstand, Authelia-Repo<->Host-Drift und ntfy-Alarmierung |
-| `services/posture-check/docker-critical-events.sh` | Host-seitiger Docker-Event-Watcher fuer kritische ntfy-Alarme |
-| `services/posture-check/posture_check.sh` | Kompatibilitaets-Wrapper fuer die historische Schreibweise aus `STORAGE_LAYOUT.draft.md` |
-| `services/authelia-diff.sh` | Vergleicht `access_control:`-Sektion zwischen Repo-Baseline und Host-Datei; wird vom Posture-Check als Check `authelia_config_drift` aufgerufen |
-| `ops/hermes-agent/config/hermes/config.yaml` | Hermes Agent Konfiguration mit Env-Platzhaltern |
-| `ops/hermes-agent/hermes.env.example` | Beispiel fuer Hermes `.env`; echte Datei liegt auf Host-Appdata |
-| `ops/hermes-agent/stack.env.example` | Beispiel fuer Hermes Stack-ENV; echte `stack.env` bleibt host-/komodoseitig und ist per `.gitignore` ausgeschlossen |
-| `monitoring/stack.env.example` | `INFLUXDB_BIND_IP` Default `127.0.0.1`; im Zielzustand fuer Home Assistant auf LAN-IP setzen |
-| `ops/komodo/stack.env.example` | Komodo Stack-ENV-Beispiel, Secret-Werte nicht enthalten |
 
-## Stack-Inventar
+## Arbeitsregel
 
-### Apps
+Neue Doku nur anlegen, wenn sie dauerhaft als Runbook, Inventar oder Restliste
-
+gebraucht wird. Einmalige Audits, Prompt-Kopien und lange Verlaufsprotokolle
-| Stack | Compose | Services / Images | Traefik Hosts | Networks | Ports | Abhaengigkeiten |
+gehoeren in Git-Commits, nicht als neue Markdown-Dateien.
-|---|---|---|---|---|---|---|
-| BentoPDF | `apps/bentopdf/docker-compose.yml` | `bentopdf` -> `bentopdfteam/bentopdf:2.8.4` | `pdf.kaleschke.info` | `frontend_net` | keine | Traefik + Authelia; COOP/COEP Middleware |
-| Immich | `apps/immich/docker-compose.yml` | `immich-server`, `immich-machine-learning`, `database`, `redis` | `immich.kaleschke.info` | `frontend_net`, `immich_default` | keine | `immich-server` depends on `database`, `redis` |
-| Mail Archiver | `apps/mail-archiver/docker-compose.yml` | `mail-archiver` -> `s1t5/mailarchiver@sha256:...` | `mail.kaleschke.info` | `frontend_net`, `backend_net` | keine | shared PostgreSQL via env connection string; Internet fuer IMAP |
-| Mealie | `apps/mealie/docker-compose.yml` | `mealie`, `mealie-postgres` | `mealie.kaleschke.info` | `frontend_net`, `mealie_internal` | keine | eigene PostgreSQL im internen Netz |
-| Nextcloud | `apps/nextcloud/docker-compose.yml` | `nextcloud`, `nextcloud-postgres`, `nextcloud-redis` | `cloud.kaleschke.info` | `frontend_net`, `nextcloud_internal` | keine | native Nextcloud-Auth; eigene DB und Redis |
-| ntfy | `apps/ntfy/docker-compose.yml` | `ntfy` -> `binwiederhier/ntfy:latest@sha256:...` | `ntfy.kaleschke.info` | `frontend_net` | keine | mobile Push via upstream `ntfy.sh` |
-| Paperless-ngx | `apps/paperless/docker-compose.yml` | `paperless` -> `ghcr.io/paperless-ngx/paperless-ngx:2.20.10` | `paperless.kaleschke.info` | `frontend_net`, `backend_net` | keine | shared PostgreSQL + Redis; DB/Redis via Stack ENV |
-| Paperless-GPT | `apps/paperless-gpt/docker-compose.yml` | `paperless-gpt` -> `icereed/paperless-gpt:v0.24.0` | `paperless-gpt.kaleschke.info` | `frontend_net` | keine | Paperless API, Ollama/LLM config |
-| Unbound | `apps/unbound/docker-compose.yml` | `unbound` -> `shaanmajid/unbound:latest@sha256:...` | keine | `dns_net` | keine | Upstream Resolver fuer AdGuard |
-
-### Core / Security / Infra
-
-| Stack | Compose | Services / Images | Traefik Hosts | Networks | Ports | Abhaengigkeiten |
-|---|---|---|---|---|---|---|
-| Gitea | `core/gitea/docker-compose.yml` | `gitea` -> `docker.gitea.com/gitea:1.25.4@sha256:...` | `git.kaleschke.info` | `frontend_net` | `222:22/tcp` | SQLite in `/data`; SSH-Port ist dokumentierte Ausnahme; `github.com` ist als Mirror-Ziel erlaubt und externe DNS-Resolver sind gesetzt |
-| Authelia | `security/authelia/docker-compose.yml` | `authelia` -> `authelia/authelia:latest@sha256:...` | `auth.kaleschke.info` | `frontend_net`, `backend_net` | keine | PostgreSQL 17 Storage, Traefik ForwardAuth; bewusst ohne Redis-Session-Backend |
-| Vaultwarden | `security/vaultwarden/docker-compose.yml` | `vaultwarden` -> `vaultwarden/server:latest@sha256:...` | `vault.kaleschke.info` | `frontend_net` | keine | Datei-Persistenz, `ADMIN_TOKEN_FILE` |
-| ddns-updater | `infra/ddns-updater/docker-compose.yml` | `ddns-updater` -> `ghcr.io/qdm12/ddns-updater:latest@sha256:...` | keine | `frontend_net` | keine | Cloudflare/API-Internetbedarf |
-| PostgreSQL 17 | `infra/postgresql17/docker-compose.yml` | `postgresql17` -> `postgres:17.9@sha256:...` | keine | `backend_net` | keine | shared DB-Cluster |
-| Redis | `infra/redis/docker-compose.yml` | `Redis` -> `redis:7.4-alpine@sha256:...` | keine | `backend_net` | keine | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt; Passwort-Datei |
-
-### Host Services
-
-| Stack | Compose | Services / Images | Hosts | Networks | Ports / Mode | Abhaengigkeiten |
-|---|---|---|---|---|---|---|
-| AdGuard Home | `host-services/Adguard/docker-compose.yml` | `adguard` -> `adguard/adguardhome:v0.107.52` | keine Traefik-Route | `dns_net`, `frontend_net` | `53/tcp`, `53/udp`, `100.80.98.33:8082:80/tcp` | Unbound in `dns_net`; DNS-Port 53 ist direkte Ausnahme; Admin 8082 ist auf Tailscale-IP begrenzt |
-| Plex | `host-services/plex/docker-compose.yml` | `plex` -> `plexinc/pms-docker:1.43.1.10611-1e34174b1@sha256:...` | keine Traefik-Route | `network_mode: host` | host network | Medienserver; Host-Netz bleibt fuer Discovery / Plex GDM dokumentierte Ausnahme |
-| Tailscale | `host-services/tailscale/docker-compose.yml` | `Tailscale-Docker` -> `tailscale/tailscale:stable@sha256:...` | keine | `network_mode: host` | host network | VPN/Remote-Zugang |
-
-### Operations
-
-| Stack | Compose | Services / Images | Traefik Hosts | Networks | Ports | Abhaengigkeiten |
-|---|---|---|---|---|---|---|
-| Borg UI | `ops/borg-ui/docker-compose.yml` | `borg-ui` -> `ainullcode/borg-ui:latest@sha256:...` | `borg.kaleschke.info` | `frontend_net` | keine | Borg repo, Dump-Scope, Restore-Ziel |
-| code-server | `ops/code-server/docker-compose.yml` | `code-server` -> `lscr.io/linuxserver/code-server:4.116.0@sha256:...` | `code.kaleschke.info` | `frontend_net` | keine | Passwort-Datei, Workspace-Mounts |
-| Filebrowser | `ops/filebrowser/docker-compose.yml` | `filebrowser` -> `filebrowser/filebrowser:v2.63.2@sha256:...` | `files.kaleschke.info` | `frontend_net` | keine | Documents/Photos/Projekte-Mounts, Admin-UI hinter Authelia |
-| Glance | `ops/glance/docker-compose.yml` | `glance` -> `glanceapp/glance:v0.8.4`, `glance-docker-socket-proxy` -> `tecnativa/docker-socket-proxy:v0.4.2` | `glance.kaleschke.info` | `frontend_net`, `glance_socket_net` | keine | Homelab-Dashboard mit Home- und Infrastructure-Seite, Monitor-, Community-, Docker-, Internet-/DNS-/VPN- und Server-Stats-Widgets; aktives Community-Widget: Immich; Docker-API nur ueber internen Socket-Proxy |
-| Glances | `ops/glances/docker-compose.yml` | `glances` -> `nicolargo/glances:latest-full@sha256:...` | `glances.kaleschke.info` | `frontend_net` | keine | Rootfs/Docker-Socket fuer Monitoring |
-| Monitoring | `monitoring/docker-compose.yml` | `monitoring-prometheus`, `monitoring-alertmanager`, `monitoring-alertmanager-ntfy-bridge`, `monitoring-blackbox-exporter`, `monitoring-loki`, `monitoring-promtail`, `monitoring-grafana`, `monitoring-node-exporter`, `monitoring-cadvisor`, `monitoring-influxdb3-core`, optional `monitoring-grafana-dashboard-importer` | `monitoring.kaleschke.info` | `frontend_net`, `monitoring_net`, `monitoring_influx_lan` | `monitoring-influxdb3-core`: `${INFLUXDB_BIND_IP:-127.0.0.1}:8181:8181` | zentraler Zielstack fuer Prometheus/Loki/Grafana/InfluxDB; Alertmanager sendet via ntfy-Bridge nach `homelab-alerts`; Blackbox ersetzt Uptime-Kuma-Checks nach Parallelphase; Promtail nutzt Docker socket read-only; Dashboard-Importer nur via `bootstrap`-Profil |
-| Hermes Agent | `ops/hermes-agent/docker-compose.yml` | `hermes-gateway`, `hermes-dashboard` -> local build from Dockerfile | `hermes.kaleschke.info` via `${HERMES_DASHBOARD_HOST}` | `hermes_net`, dashboard zusaetzlich `frontend_net` | `8642` nur expose intern | SSH runner, Home Assistant optional, LLM provider env; Dashboard hinter Authelia |
-| Komodo | `ops/komodo/docker-compose.yml` | `komodo-core`, `komodo-mongo`, `komodo-periphery` | `komodo.kaleschke.info` | `frontend_net`, `komodo_net` | keine | Mongo, Docker socket, `/mnt/user/services` workspace mount, Gitea DNS override |
-| Scrutiny | `ops/scrutiny/docker-compose.yml` | `scrutiny` -> `ghcr.io/starosdev/scrutiny:latest-omnibus@sha256:...` | `scrutiny.kaleschke.info` | `frontend_net` | keine | `privileged: true`, device mounts fuer SMART |
-| Speedtest Tracker | `ops/speedtest/docker-compose.yml` | `speedtest-tracker` -> `lscr.io/linuxserver/speedtest-tracker:1.13.12@sha256:...` | `speedtest.kaleschke.info` | `frontend_net` | keine | App key/admin env, SQLite/config path |
-
-### Traefik
-
-| Stack | Compose | Service / Image | Hosts | Networks | Ports | Abhaengigkeiten |
-|---|---|---|---|---|---|---|
-| Traefik | `traefik/docker-compose.yml` | `traefik` -> `traefik:v3.6` | `traefik.kaleschke.info` | `frontend_net`, `backend_net` | `80:80/tcp`, `443:443/tcp` | Docker provider, Cloudflare DNS token secret, dynamic config |
-
-## Traefik Hosts
-
-| Host | Service | Zugriff |
-|---|---|---|
-| `auth.kaleschke.info` | Authelia | Auth provider / bypass fuer eigene Domain |
-| `borg.kaleschke.info` | Borg UI | Traefik + Authelia |
-| `cloud.kaleschke.info` | Nextcloud | Traefik, native App-Auth |
-| `code.kaleschke.info` | code-server | Traefik + Authelia |
-| `files.kaleschke.info` | Filebrowser | Traefik + Authelia |
-| `git.kaleschke.info` | Gitea Web | Traefik |
-| `glance.kaleschke.info` | Glance | Traefik + Authelia |
-| `glances.kaleschke.info` | Glances | Traefik + Authelia |
-| `hermes.kaleschke.info` | Hermes Dashboard | Traefik + Authelia |
-| `immich.kaleschke.info` | Immich | Traefik, native App-Auth |
-| `komodo.kaleschke.info` | Komodo | Traefik, native Komodo-Auth; keine pauschale ForwardAuth |
-| `mail.kaleschke.info` | Mail Archiver | Traefik + Authelia + App-Auth |
-| `mealie.kaleschke.info` | Mealie | Traefik |
-| `monitoring.kaleschke.info` | Monitoring Grafana | Traefik + Authelia |
-| `ntfy.kaleschke.info` | ntfy | Traefik |
-| `paperless.kaleschke.info` | Paperless-ngx | Traefik |
-| `paperless-gpt.kaleschke.info` | Paperless-GPT | Traefik + Authelia |
-| `pdf.kaleschke.info` | BentoPDF | Traefik + Authelia + COOP/COEP |
-| `scrutiny.kaleschke.info` | Scrutiny | Traefik + Authelia |
-| `speedtest.kaleschke.info` | Speedtest Tracker | Traefik + Authelia |
-| `traefik.kaleschke.info` | Traefik Dashboard | Traefik + Authelia |
-| `vault.kaleschke.info` | Vaultwarden | Traefik |
-
-## Networks
-
-| Network | Typ / Status | Nutzer |
-|---|---|---|
-| `frontend_net` | external bridge | Web-/Proxy-Netz fuer Traefik und alle gerouteten UIs |
-| `backend_net` | external/internal laut Architektur | PostgreSQL 17, Redis, Authelia, Paperless, Mail Archiver, Traefik |
-| `dns_net` | App-/Host-Netz | AdGuard Home und Unbound |
-| `immich_default` | Compose-intern, `internal: true` | Immich Server, ML, Postgres, Redis |
-| `mealie_internal` | Compose-intern; Laufzeitname mit Compose-Projektpraefix typischerweise `mealie_mealie_internal` | Mealie und Mealie Postgres |
-| `nextcloud_internal` | Compose-intern | Nextcloud, Nextcloud Postgres, Nextcloud Redis |
-| `monitoring_net` | Compose-/Stack-Netz bridge | Prometheus, Loki, Promtail, Monitoring-Grafana, node-exporter, cAdvisor; Traefik fuer Metrics-Scrape |
-| `monitoring_influx_lan` | Compose-intern bridge | InfluxDB Host-Port-Publishing fuer LAN Writer im zentralen Monitoring-Stack |
-| `glance_socket_net` | Compose-intern, `internal: true` | Glance und `glance-docker-socket-proxy`; keine Traefik-Anbindung |
-| `komodo_net` | Compose-intern, `internal: true` | Komodo Core, Mongo, Periphery |
-| `hermes_net` | Compose-intern bridge | Hermes Gateway/Dashboard |
-| `host` | Host-Netz | Tailscale; Plex als Repo-Compose-Stack unter `host-services/plex/` |
-
-## Volumes und Datenpfade
-
-| Bereich | Wichtige Pfade |
-|---|---|
-| Traefik | `/mnt/user/appdata/traefik/dynamic`, `/mnt/user/appdata/traefik/letsencrypt`, Cloudflare Secret |
-| Gitea | `/mnt/user/services/gitea/data` |
-| Authelia | `/mnt/user/appdata/authelia/config`, Authelia Secret-Dateien |
-| Vaultwarden | `/mnt/user/appdata/vaultwarden`, Admin-Token-Datei |
-| PostgreSQL 17 | `/mnt/user/appdata/postgresql17`, `postgres_password.txt` |
-| Redis | `/mnt/user/appdata/redis`, `redis_password.txt` |
-| Paperless | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/scans_inbox` |
-| Immich | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive`, `/mnt/user/appdata/immich_postgres`, `model-cache` |
-| Mealie | `/mnt/user/appdata/mealie/data`, `/mnt/user/appdata/mealie/postgres` |
-| Mail Archiver | `/mnt/user/appdata/mailarchiver/data-protection-keys` |
-| Nextcloud | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data`, `/mnt/user/appdata/nextcloud/postgres`, `/mnt/user/appdata/nextcloud/redis` |
-| Plex | `/mnt/user/appdata/plex/config`, `/mnt/user/appdata/plex/transcode`, `/mnt/user/media`, `/mnt/user/photos` |
-| ntfy | `/mnt/user/appdata/ntfy` |
-| Paperless-GPT | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` |
-| AdGuard | `/mnt/user/appdata/adguard/work`, `/mnt/user/appdata/adguard/conf` |
-| Tailscale | `/mnt/user/appdata/tailscale` |
-| Borg UI | `/mnt/user/appdata/borg-ui/data`, `/mnt/user/appdata/borg-ui/cache`, `/mnt/user/backups/borg/dumps`, selected restore/source mounts |
-| code-server | `/mnt/user/appdata/code-server`, `/mnt/user/services/dev` |
-| Filebrowser | `/mnt/user/documents`, `/mnt/user/photos`, `/mnt/user/projekte`, Filebrowser database/config paths |
-| Glance | Repo-Konfiguration unter `ops/glance/config/glance.yml`; keine produktive Datenpersistenz; Docker-Socket nur am internen Proxy |
-| Glances | `/`, Docker socket, `/etc/os-release` |
-| Scrutiny | `/mnt/user/appdata/scrutiny/*`, `/run/udev`, selected `/dev/...` disks |
-| Speedtest | `/mnt/user/appdata/speedtest-tracker/config` |
-| Monitoring | named volumes `prometheus_data`, `loki_data`, `promtail_positions`, `grafana_data`; InfluxDB-Persistenz unter `/mnt/user/appdata/influxdb3/data` und `/mnt/user/appdata/influxdb3/plugins`; Provisioning im Repo unter `monitoring/grafana/provisioning`; Dashboards unter `monitoring/grafana/dashboards`; historische Altstandsdaten unter `/mnt/user/appdata/grafana`, `/mnt/user/appdata/loki` und `/mnt/user/appdata/alloy` nicht blind loeschen |
-| Hermes Agent | `/mnt/user/appdata/hermes-agent/data`, `/mnt/user/appdata/hermes-agent/ssh`, SSH private key path |
-| Komodo | `komodo_keys`, `/mnt/user/appdata/komodo/core`, `/mnt/user/appdata/komodo/mongo`, `/mnt/user/appdata/komodo/periphery`, `/mnt/user/services` |
-
-## Secrets und Env-Hinweise
-
-| Dienst / Stack | Secret-/Env-Hinweise ohne Werte |
-|---|---|
-| Traefik | `cloudflare_dns_api_token` als Docker Secret / `CF_DNS_API_TOKEN_FILE` |
-| Authelia | JWT, Session, Storage Encryption, Postgres Password via `_FILE` |
-| Vaultwarden | `ADMIN_TOKEN_FILE` |
-| PostgreSQL 17 | `POSTGRES_PASSWORD_FILE` |
-| Redis | Passwort-Datei und Startkommando |
-| Paperless | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS` als Komodo Stack ENV |
-| Immich | `IMMICH_DB_PASSWORD` Stack ENV; `immich_postgres_password.txt` fuer Postgres |
-| Mail Archiver | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` als Stack ENV |
-| Glance | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` als Stack ENV fuer Community-/Live-Widgets |
-| Speedtest | `APP_KEY`, `ADMIN_PASSWORD` als Stack ENV |
-| Nextcloud | Admin User, Admin Password, Postgres Password via Secret-Dateien |
-| Komodo | `KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY`; Mongo Passwort-Datei |
-| Borg UI | Borg Credentials, Admin Login, SSH Keys in persistentem Appdata, nicht im Git |
-| Hermes Agent | provider keys, API server key, messaging tokens, Home Assistant token in Host `.env`; SSH private key als Host-Secret |
-| Monitoring | `monitoring_grafana_admin_password.txt`, `monitoring_grafana_influxdb_token.txt`, `influxdb3_admin_token.json` fuer zentrale Grafana-/InfluxDB-Funktionen; ersetzt Uptime Kuma fuer HTTP-Verfuegbarkeit |
-
-## Skripte
-
-| Skript | Ausfuehrungsort | Zweck |
-|---|---|---|
-| `ops/borg-ui/scripts/pre-backup-dumps.sh` | Unraid Host, nicht Borg-UI Inline-Hook | erzeugt aktuelle Dumps unter `/mnt/user/backups/borg/dumps/latest` |
-| `services/posture-check/posture-check.sh` | Unraid Host | schreibt `/mnt/user/services/posture-check/last.json` und alarmiert via ntfy bei Warning/Critical |
-| `services/posture-check/docker-critical-events.sh` | Unraid Host | beobachtet Docker `die`/`oom`/`kill` Events und alarmiert via `homelab-alerts` |
-
-Das Skript liest Secret-Dateien auf dem Host und schreibt Dump-Artefakte. Bei Analyse niemals Secret-Inhalte ausgeben.
-
-## Unsicherheiten / TODOs aus Repo-Sicht
-
-- Echte `stack.env`- und `.env`-Dateien sind per `.gitignore` ausgeschlossen; nur `*.example`-Dateien gehoeren ins Repo.
-- Hardware-, Netzwerk- und Provider-Inventare sind initiale Templates und muessen nach einem Host-Audit mit echten Werten gefuellt werden.
-- Authelia-2FA-/OIDC-Aenderungen sind nach Audit 2026-05-25 bewusst geparkt und werden nicht als Sofortmassnahme behandelt.
-- Authelia `configuration.yml` ist Repo-Baseline fuer nicht geheime Einstellungen, wird aber nicht automatisch von Komodo auf den Host kopiert. Die produktive Host-Datei kann zusaetzliche OIDC-/Secret-Konfiguration enthalten; Aenderungen muessen manuell gemerged und validiert werden.
-- `backend_net` ist in der Architektur als `internal: true` beschrieben; einzelne Compose-Dateien referenzieren es external. Live-Netz-Attribute bei Drift-Fragen pruefen.
-- Einige Images bleiben trotz Digest-Pin semantisch auf mutable Tags (`latest@sha256`, `release@sha256`). Das ist bewusst dokumentiert, aber bei Updates gesondert pruefen.
-- Stateful Datenhalter sind seit 2026-05-05 bevorzugt mit Minor-/Patch-Tag plus Digest gepinnt; Redis-Caches wurden im Hardening-Sprint 2026-05-16 auf `redis:7.4-alpine@sha256:...` vereinheitlicht.
-- `scrutiny` bleibt `privileged: true`; dokumentierte Ausnahme, aber weiterhin pruefenswert.
-- `tailscale` nutzt Host-Netz, `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` als dokumentierte VPN-Ausnahme.
-- `monitoring-influxdb3-core` laeuft aktuell als `user: "0"`; UID/GID-Hardening nur als eigener Sprint.
-- Leere `.keep`-Platzhalter wurden entfernt; neue Verzeichnisse sollen erst mit konkretem Inhalt ins Repo.
-- `plex` ist als Repo-Compose-Stack unter `host-services/plex/` enthalten; `network_mode: host` bleibt die dokumentierte Discovery-Ausnahme.
-- BentoPDF kann je nach Live-Stand vorbereitet statt produktiv sein; Hermes Dashboard ist produktiv unter `hermes.kaleschke.info`.

docs/RESTORE_DRILL_ROUTINE.md

@@ -1,123 +0,0 @@
-# Restore-Drill Routine - KalliLab CORE
-
-Status: **verbindliche Routine (Doku-only)**, 2026-05-27.
-Audit-Bezug: `docs/AUDIT_2026-05-25.md` Sprint 7 "Restore-Lab-Drill quartalsweise dokumentieren".
-Verwandte Docs: `docs/RESTORE_MATRIX.md`, `docs/RESTORE_HANDBOOK.md`, `docs/DISASTER_RECOVERY.md`, `ops/restore-tests/schedule.md`.
-
-## Ziel
-
-Sicherstellen, dass die Backup-Kette nicht nur weiter laeuft, sondern auch **wiederherstellbar** ist. Restore-Tests werden nicht ad-hoc gemacht, wenn ein Problem auftritt, sondern in einer planbaren Kadenz, damit das Vertrauen ueber die Zeit waechst und Drift fruehzeitig auffaellt.
-
-Diese Datei beschreibt nur die **Routine** (wann, was, wie pruefen). Die operativen Anleitungen pro Dienst stehen in `docs/RESTORE_HANDBOOK.md` und den dienstspezifischen Runbooks unter `ops/restore-tests/<dienst>-runbook.md`.
-
-## Drei-Stufen-Modell
-
-| Stufe | Frequenz | Aufwand | Ziel |
-|---|---|---|---|
-| Freshness-Check | woechentlich | Minuten | Backup-Artefakte sind frisch, Reports lesbar |
-| Mini-Restore | monatlich/quartalsweise | 15-60 Min | Ein konkreter Dienst wird in isoliertem Test-Lab restauriert |
-| DR-Sanity-Check | quartalsweise | 1-2 h | Reihenfolge, Doku, Tier-Reihenfolge in der DR-Doku gegen Realitaet pruefen |
-
-## Bestaetigte Mini-Restores
-
-Wenn ein Mini-Restore zum ersten Mal sauber durchlaeuft, wird er hier als Referenz gefuehrt. Der Eintrag wird **nicht** entfernt, wenn er wiederholt wird; stattdessen aendert sich der Datums-Stand.
-
-| Dienst | Erster bestaetigter Lauf | Letzter Erfolg | Report | Repo-Skript |
-|---|---|---|---|---|
-| Vaultwarden | 2026-05-07 | 2026-05-07 | `/mnt/user/backups/restore-reports/vaultwarden-2026-05-07.md` | `ops/restore-tests/vaultwarden-restore-test.sh` |
-| Gitea | 2026-05-07 | 2026-05-07 | `/mnt/user/backups/restore-reports/gitea-2026-05-07.md` | `ops/restore-tests/gitea-restore-test.sh` |
-| Paperless | 2026-05-07 | 2026-05-07 | `/mnt/user/backups/restore-reports/paperless-2026-05-07.md` | `ops/restore-tests/paperless-restore-test.sh` |
-| Immich | **2026-05-27** | **2026-05-27** | `/mnt/user/backups/restore-reports/immich-2026-05-27.md` | `ops/restore-tests/immich-restore-test.sh` |
-
-Bei jedem weiteren Lauf wird die Spalte "Letzter Erfolg" aktualisiert.
-
-## Quartals-Kadenz
-
-Ein Kalenderjahr enthaelt vier Quartals-Drills. Jeder Quartals-Drill besteht aus dem Mini-Restore eines anderen Tier-2-Dienstes plus einem DR-Sanity-Check der Tier-1-Dienste.
-
-| Quartal | Mini-Restore | DR-Sanity-Check Fokus |
-|---|---|---|
-| Q1 (Januar-Maerz) | `paperless` | Tier-1-Reihenfolge, Posture-Check-Status, Borg-Frische-Alerts |
-| Q2 (April-Juni) | `immich` | Komodo-Bootstrap-Pfad, Gitea-Bundles, Secrets-Pfad-Inventur |
-| Q3 (Juli-September) | `mealie` oder `nextcloud` (Operator-Wahl) | DNS-Pfad (AdGuard/Unbound/Tailscale), Cert-Expiry-Sicht |
-| Q4 (Oktober-Dezember) | `vaultwarden` oder `gitea` (Operator-Wahl) | Externe Abhaengigkeiten (Cloudflare, Hetzner, GitHub-Mirror), Off-site-Zweitziel-Diskussion |
-
-Diese Liste ist bewusst auf Tier-2 und Tier-1-Dienste fokussiert. Tier-3-Dienste (Filebrowser, Glances, Scrutiny, Speedtest, Glance) werden im Drill nicht explizit ausgefuehrt, weil sie rebuildbar sind oder keinen kritischen Datenbestand haben.
-
-### Q2 2026 - Konkrete Belegung
-
-- Mini-Restore: **Immich (erledigt 2026-05-27)**.
-- DR-Sanity-Check (teilweise erledigt, Rest vor Quartalsende 2026-06-30):
-  - Komodo-Bootstrap-Pfad: **erledigt 2026-05-30** durch echten Trockenlauf via `ops/restore-tests/komodo-bootstrap-test.sh --keep-data`, Report `/mnt/user/backups/restore-reports/komodo-bootstrap-2026-05-30.md`, `ops/komodo/docker-compose.yml` als Recovery-Anker belegt.
-  - Gitea-Bundles ueber `ops/borg-ui/scripts/gitea-bundle-mirror.sh` auf Frische und Bundle-Klonbarkeit pruefen: offen.
-  - Secrets-Inventur gegen `docs/SECRETS_MAP.md` abgleichen: offen.
-
-### Wer schiebt das an?
-
-- **Operator** loest jeden Drill manuell aus, idealerweise am 2. Wochenende des ersten Monats im Quartal.
-- Es gibt **keinen** automatischen Host-Schedule fuer den Quartals-Drill. Die woechentliche Freshness-Pruefung und die monatlichen Mini-Restores in `ops/restore-tests/schedule.md` laufen separat.
-- Bei akuten Aenderungen (Major-Upgrade eines Dienstes, FS-Migration, Repo-Strukturaenderung): zusaetzlichen Ad-hoc-Drill ausserhalb der Quartals-Kadenz einplanen.
-
-## Freshness-Check (woechentlich)
-
-- Skript: `ops/restore-tests/check-restore-freshness.sh` (Host-Bash) bzw. `ops/restore-tests/check-restore-freshness.ps1` (Windows-Operator).
-- Erwartete Pruefungen:
-  - Letzter Borg-Archiv-Stand juenger als die Schwellwerte aus `docs/STORAGE_LAYOUT.md` §11.
-  - Kanonische Dump-Artefakte unter `/mnt/user/backups/borg/dumps/latest/` vorhanden und juenger als 26 h.
-  - Letzte Report-Dateien unter `/mnt/user/backups/restore-reports/` lesbar.
-  - Gitea-Bundles unter `/mnt/user/backups/git-bundles/gitea/` plausibel aktuell.
-
-Ergebnis ist ein kurzes Konsolen-Log; bei Fehler greift die ntfy-Alarmierung aus `docs/ALERTING_MAP.md`.
-
-## Mini-Restore (monatlich / bimonatlich)
-
-Skripte folgen alle demselben Muster:
-
-- isoliertes Test-Lab unter `/mnt/user/backups/restore-lab/<dienst>`
-- isolierte Test-Container `restoretest-*`
-- nur `127.0.0.1`-Ports, keine Traefik-Labels, keine produktive Domain
-- Smoke-Test mit Erfolgsregel "Container laeuft reicht nicht"
-- Report unter `/mnt/user/backups/restore-reports/<dienst>-YYYY-MM-DD.md`
-
-Operative Anleitungen je Dienst:
-
-- `ops/restore-tests/vaultwarden-runbook.md`
-- `ops/restore-tests/gitea-runbook.md`
-- `ops/restore-tests/paperless-runbook.md`
-- `ops/restore-tests/immich-runbook.md`
-
-## DR-Sanity-Check (quartalsweise)
-
-Der Sanity-Check ist **kein** echter Restore. Er ist eine Doku-/Konsistenz-Pruefung mit zehn Punkten:
-
-1. `docs/DISASTER_RECOVERY.md` Phase 1-5 noch konsistent mit Repo und Live-Stand?
-2. `docs/RESTORE_MATRIX.md` Tier-Klassifizierung pro Dienst aktuell?
-3. `docs/SECRETS_MAP.md` Pfade existieren, Stack-ENV-only-Liste aktuell?
-4. `docs/SERVICES_RECOVERY.md` Komodo-Bootstrap-Pfad noch in Stufen A-F konsistent?
-5. Gitea-Bundle-Mechanik laeuft und letzter Bundle-Stand klonbar (`git clone .../homelab-infra.bundle /tmp/restore-test`)?
-6. Externe Mirrors (`michaelkaleschke-spec/homelab-infra` auf GitHub) gemaess `docs/EXTERNAL_DEPENDENCIES.md` noch erreichbar und aktuell?
-7. ntfy-Push-Pfad noch erreichbar? (Test-Nachricht an `homelab-info`.)
-8. Letzte vier Quartals-Mini-Restores im Report-Verzeichnis vorhanden?
-9. Borg-Repo-Passphrase Offline-Sicherung noch auffindbar? (Pruefung durch Operator, nicht durch Skript, kein Wert ablegen.)
-10. Capacity-Stand gegen Schwellen aus `docs/CAPACITY_AND_LIFECYCLE.md` abgeglichen?
-
-Jeder Punkt wird in einem kurzen Quartals-Eintrag in `docs/MIGRATION_LOG.md` als `ok` / `Abweichung` / `Folgeaufgabe` festgehalten.
-
-## Abbruch-Regeln
-
-Wenn ein Drill fehlschlaegt, gilt die Stop-Regel aus `docs/WORKFLOW.md`:
-
-- nach zwei fehlgeschlagenen Reparaturversuchen nicht weiterschreiben
-- stattdessen Pflichtmatrix aus `docs/GITOPS_DRIFT_RUNBOOK.md` durchgehen
-- Befund dokumentieren, naechsten Schritt mit dem Operator klaeren
-- erst danach den Drill erneut starten oder das Quartal als "Drill incomplete" markieren
-
-## Berichte
-
-- Mini-Restore-Reports liegen unter `/mnt/user/backups/restore-reports/<dienst>-YYYY-MM-DD.md`.
-- Quartals-Sanity-Checks landen als kurzer Block in `docs/MIGRATION_LOG.md`, nicht als eigenes Dokument.
-- Reports werden nicht aus dem Repo verlinkt, weil sie nicht im Repo liegen. Operator dokumentiert nur Vorhanden/Erfolg/Datum.
-
-## Geltungsdauer
-
-Diese Routine gilt ab Q2 2026. Bei groesseren Aenderungen (zweites Off-site, Authelia-OIDC-Aktivierung, Hardware-Migration) wird die Liste pro Quartal angepasst.

docs/RESTORE_HANDBOOK.md

@@ -1,6 +1,6 @@
 # Restore Handbook - KalliLab CORE
 
-Stand: 2026-05-07
+Stand: 2026-06-03
 
 Dieses Handbuch ist die praktische Betriebsanleitung fuer Restore-Checks und Restore-Lab in KalliLab CORE.
 
@@ -41,28 +41,36 @@ Alle validierten Restore-Tests folgen demselben Muster:
 
 ### Vaultwarden
 
-- Report: `/mnt/user/backups/restore-reports/vaultwarden-2026-05-07.md`
+- Erstlauf: 2026-05-07
-- Nachweis:
+- Nachweis: Borg-Restore, Testcontainer, Login-Seite erreichbar
-  - Borg-Restore erfolgreich
-  - Testcontainer startete
-  - Login-Seite war erreichbar
 
 ### Gitea
 
-- Report: `/mnt/user/backups/restore-reports/gitea-2026-05-07.md`
+- Erstlauf: 2026-05-07
-- Nachweis:
+- Nachweis: Borg-Restore, Web-UI, SSH-TCP-Port
-  - Borg-Restore erfolgreich
-  - Web-UI antwortete
-  - SSH-Port reagierte
 
 ### Paperless
 
-- Report: `/mnt/user/backups/restore-reports/paperless-2026-05-07.md`
+- Erstlauf: 2026-05-07, Folgelauf: 2026-05-31
-- Nachweis:
+- Nachweis: Borg-Datei-Restore, Dump-Import in Test-Postgres, Login-Seite, Doc-Count
-  - Borg-Datei-Restore erfolgreich
+
-  - Paperless-Dump aus Borg importiert
+### Immich
-  - Login-Seite war erreichbar
+
-  - Test-DB enthielt `25` Dokumente
+- Erstlauf: 2026-05-27
+- Nachweis: DB-Dump-Restore in VectorChord-Test-Postgres, HTTP-Smoke, Asset-Count
+- Hinweis: Foto-Dateien-Restore ist bewusst nicht Teil des Smokes
+
+### Authelia
+
+- Erstlauf: 2026-06-03
+- Nachweis: Config-Borg-Restore, `authelia config validate`, HTTP-Health `/api/health`
+- Hinweis: Daten-Restore des produktiven Dumps ist bewusst nicht Teil des Smokes (Storage-Encryption-Key-Kopplung)
+
+### Komodo Bootstrap
+
+- Erstlauf: 2026-05-30
+- Nachweis: Compose-Validierung, Mongo healthy, Core HTTP, Periphery running
+- Hinweis: Daten-Restore aus `komodo-mongo.archive.gz` ist noch nicht getestet
 
 ---
 
@@ -80,6 +88,10 @@ Alle validierten Restore-Tests folgen demselben Muster:
 - `/mnt/user/backups/restore-lab/vaultwarden`
 - `/mnt/user/backups/restore-lab/gitea`
 - `/mnt/user/backups/restore-lab/paperless`
+- `/mnt/user/backups/restore-lab/immich`
+- `/mnt/user/backups/restore-lab/authelia`
+- `/mnt/user/backups/restore-lab/komodo`
+- `/mnt/user/backups/restore-lab/_failed` (Diagnose-Material bei Fehllaeufen)
 
 ### Reports
 
@@ -89,31 +101,33 @@ Alle validierten Restore-Tests folgen demselben Muster:
 
 ## 5. Restore-Frequenz
 
-- jeden Montag, 06:30:
+- jeden Montag, 06:30: Frische-Check fuer Dumps und Reports
-  - Frische-Check fuer Dumps und Reports
+- 1. Samstag im Monat, 07:00: Vaultwarden
-- 1. Samstag im Monat, 07:00:
+- 3. Samstag im Monat, 07:15: Gitea
-  - Vaultwarden
+- 2. Samstag in ungeraden Monaten, 08:00: Paperless
-- 3. Samstag im Monat, 07:00:
+- 2. Sonntag in Feb/Mai/Aug/Nov, 08:30: Immich
-  - Gitea
+- 2. Samstag in geraden Monaten, 07:30: Authelia
-- jeder 2. Monat, 2. Samstag, 08:00:
+- 1. Kalendertag im Monat, 09:00: Zufaelliger Restore aus Pool
-  - Paperless
+
+Vollstaendiger Kalender mit Cron-Ausdruecken und Shell-Guards steht in `ops/restore-tests/schedule.md`.
 
 ---
 
-## 6. Betriebsmodi
+## 6. Betriebsmodus
 
-### V1
+Stand 2026-06-03 ist der Betrieb auf V1+ (V1 mit ntfy):
 
-- validierte Bash-Host-Jobs
+- validierte Bash-Host-Jobs fuer Vaultwarden, Gitea, Paperless, Immich, Authelia, Komodo-Bootstrap
-- Host-Job-Definitionen liegen im Repo
+- Host-Job-Definitionen und Cron-Vorlagen liegen im Repo (`ops/restore-tests/unraid-user-scripts.md`)
-- Scheduler kann bereits echte Frische- und Restore-Checks fahren
+- `ntfy`-Wrapper sendet Erfolg an `homelab-info`, Fehler an `homelab-alerts`
-- `ntfy` und Hermes-Auswertung folgen danach
+- Frische-Check prueft zusaetzlich pg-Custom-Format-Dumps per `pg_restore --list` Header-Validierung
+- bei Fehlschlag wird das Restore-Lab nach `_failed/` verschoben statt geloescht
 
-### V2
+Noch geplant fuer V2:
 
-- `ntfy` bei Erfolg/Fehler
+- Hermes-Zusammenfassung ueber vorhandene Reports
-- Hermes liest Reports und baut Uebersichten
+- Sammelreports und Report-Rotation
-- zusaetzliche Rotation, Sammelreports und weitere Dienste
+- weitere Dienste (Nextcloud, Mailarchiver, Mealie)
 
 ---
 
@@ -126,15 +140,18 @@ Die Vorlagen stehen in:
 Host-Repo-Pfad:
 
 ```text
-/mnt/user/services/homelab
+/mnt/user/services/homelab-infra
 ```
 
-V1-Jobs:
+Jobs:
 
 1. `restore-freshness-weekly`
 2. `restore-vaultwarden-monthly`
 3. `restore-gitea-monthly`
 4. `restore-paperless-bimonthly`
+5. `restore-immich-quarterly`
+6. `restore-authelia-bimonthly`
+7. `monthly-random-restore`
 
 ---
 
@@ -169,38 +186,65 @@ Nur `Container laeuft` reicht nicht.
 Auf dem Unraid-Host:
 
 ```bash
-bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh freshness
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh freshness
 ```
 
 ### Vaultwarden Restore-Check
 
 ```bash
-bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh vaultwarden
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh vaultwarden
 ```
 
 ### Gitea Restore-Check
 
 ```bash
-bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh gitea
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh gitea
 ```
 
 ### Paperless Restore-Check
 
 ```bash
-bash /mnt/user/services/homelab/ops/restore-tests/run-restore-checks.sh paperless
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh paperless
+```
+
+### Immich Restore-Check
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh immich
+```
+
+### Authelia Restore-Check
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh authelia
+```
+
+### Komodo Bootstrap Trockenlauf
+
+```bash
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh komodo-bootstrap
 ```
 
 ### Optional mit `ntfy`
 
 ```bash
-bash /mnt/user/services/homelab/ops/restore-tests/run-restore-job-with-ntfy.sh freshness homelab-info
+bash /mnt/user/services/homelab-infra/ops/restore-tests/run-restore-job-with-ntfy.sh freshness homelab-info
 ```
 
 ---
 
 ## 11. Naechste Ausbaustufen
 
-1. Vollautomatik fuer Vaultwarden, Gitea und Paperless
+1. Nextcloud-Restore-Test (mit `occ maintenance:mode`-Choreographie)
-2. `ntfy`-Meldungen fuer Erfolg/Fehler
+2. Mailarchiver-Restore-Test
-3. Hermes-Zusammenfassung ueber vorhandene Reports
+3. Mealie-Restore-Test
-4. naechster Referenz-Restore fuer `mail-archiver` oder `mealie`
+4. Komodo-Mongo-Daten-Restore (echtes `mongorestore` statt reinem Bootstrap)
+5. Shared-PostgreSQL-18-Cluster-Restore-Drill (globals + per-DB-Dumps)
+6. Traefik-Restore-Test (mit `dynamic/` und LE-State)
+7. Hermes-Zusammenfassung ueber vorhandene Reports
+8. Report-Rotation (archivieren nach 12 Monaten)
+9. Negativ-Test: bewusst kaputten Dump in den Frische-Check einfuettern
+
+## 12. Report-Aufbewahrung
+
+Reports unter `/mnt/user/backups/restore-reports` werden dauerhaft aufbewahrt. Bei wachsender Anzahl (ca. 50-60 pro Jahr) empfiehlt sich eine jaehrliche Archivierung alter Reports in einen Unterordner `_archive/YYYY/`. Der Frische-Check warnt bei `MAX_REPORT_AGE_DAYS=45`, loescht aber bewusst nicht automatisch.

docs/RESTORE_MATRIX.md

@@ -28,15 +28,23 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
 |---|---|---|---|---|---|---|
 | Unraid OS Flash | Borg-Artefakt + optional Unraid Connect | `/boot/config` aus `unraid-flash-config.tar.gz` | `unraid-flash-config.tar.gz`, `.sha256`, Manifest | enthaelt sensible Host-Konfiguration, wie Secret-Material behandeln | Unraid USB Flash Creator / neuer Boot-Stick | Unraid bootet, Array-Zuordnung und Shares sind sichtbar |
 | Traefik | Share / Borg | `/mnt/user/appdata/traefik`, besonders `dynamic/`, `letsencrypt`, `secrets` | keine eigene DB | `cloudflare_dns_api_token` | `frontend_net`, `backend_net` | `https://traefik.kaleschke.info` erreichbar, Dashboard ueber Authelia |
-| AdGuard Home | Share / Borg | `/mnt/user/appdata/adguard/conf` | keine | keine zusaetzlichen Repo-Secrets dokumentiert | `dns_net`, `frontend_net` | DNS-Aufloesung funktioniert |
+| AdGuard Home | Share / Borg | `/mnt/user/appdata/adguard/conf` | keine | keine zusaetzlichen Repo-Secrets dokumentiert | `dns_net`, `frontend_net` | DNS-Aufloesung funktioniert; Restore-Smoke am 2026-06-06 erfolgreich |
-| Tailscale | Share / Borg | `/mnt/user/appdata/tailscale` | keine | Tailscale-State im Pfad | Host-Netz | Tailscale verbunden |
+| Tailscale | Flash-Backup (funktional) / Share | **Funktional: `/boot/config/plugins/tailscale/state`** (native Unraid-Plugin-Instanz `kallilabcore`, Subnet-Router, im Flash-Backup gesichert). Der frueher hier genannte Pfad `/mnt/user/appdata/tailscale` gehoert zum **userspace-only Docker-Stack** `kallilab-core` (redundant, Abbau geplant — siehe `docs/NETWORK_INVENTORY.md`) | keine | Tailscale-State im jeweiligen State-Pfad | Host-Netz | Tailscale verbunden, Subnet-Route `192.168.178.0/24` aktiv |
-| PostgreSQL 17 | Share + Dumps | `/mnt/user/appdata/postgresql17` | `postgresql17-globals.sql`, `postgresql17-mailarchiver.dump`, `postgresql17-paperless.dump`, optional `postgresql17-authelia.dump` | `postgres_password.txt` | `backend_net` | DB startet, Ziel-Datenbanken vorhanden |
+| PostgreSQL 18 | Share + Dumps | `/mnt/user/appdata/postgresql18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`) | `postgresql17-globals.sql`, `postgresql17-mailarchiver.dump`, `postgresql17-paperless.dump`, optional `postgresql17-authelia.dump` | `postgres_password.txt`, App-Rollen-Passwoerter aus den jeweiligen Stack-ENV/Secret-Dateien | `backend_net` | DB startet, Ziel-Datenbanken vorhanden; `SHOW data_checksums` ist `on` |
-| Redis | Share / Host | `/mnt/user/appdata/redis` | keine | `redis_password.txt` | `backend_net` | Redis startet, Apps verbinden sich |
+| Redis 8 | Share / Host | `/mnt/user/appdata/redis`; Rollback-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` | RDB/AOF-Dateien im Datenpfad | `redis_password.txt` | `backend_net` | Redis startet, `redis_version` ist 8.x, Apps verbinden sich; Restore-Smoke am 2026-06-06 erfolgreich |
-| Authelia | Borg | `/mnt/user/appdata/authelia/config`, `/mnt/user/appdata/secrets/*authelia*` | Shared PostgreSQL, optional Dump `postgresql17-authelia.dump` | JWT/Session/Storage/Postgres-/SMTP-Secret-Dateien | PostgreSQL 17, Traefik, GMX SMTP | Login-Seite und ForwardAuth funktionieren; SMTP-Notifier startet; aktive Sessions werden nach Restart neu aufgebaut |
+| Authelia | Borg | `/mnt/user/appdata/authelia/config`, `/mnt/user/appdata/secrets/*authelia*` | Shared PostgreSQL 18, optional Dump `postgresql17-authelia.dump` | JWT/Session/Storage/Postgres-/SMTP-Secret-Dateien | PostgreSQL 18, Traefik, GMX SMTP | Login-Seite und ForwardAuth funktionieren; SMTP-Notifier startet; aktive Sessions werden nach Restart neu aufgebaut; Restore-Smoke am 2026-06-03 erfolgreich: Config aus Borg, minimale Test-Config, frisches Test-Postgres, HTTP `/api/health` 200, Report `/mnt/user/backups/restore-reports/authelia-2026-06-03.md` |
 | Gitea | GitHub-Mirror + Gitea-Bundles fuer Repo-Bootstrap, Borg + Dump fuer Gitea-Appstate | `/mnt/user/services/gitea/data`, `/mnt/user/backups/git-bundles/gitea` | `gitea.sqlite.dump`, Bundle-Report `latest-report.md` | `borg_repo_passphrase.txt` fuer Restore-Tests; GitHub-Push-Mirror-PAT liegt nur in Gitea-Mirror-Settings | Traefik | Web-UI erreichbar, Repo sichtbar, SSH-Port reagiert; Bundle laesst sich klonen und `git fsck` ist sauber; GitHub-Push-Mirror synchronisiert ohne `last_error`; Mini-Restore nach `/mnt/user/backups/restore-lab/gitea` am 2026-05-07 erfolgreich validiert |
 | Komodo | Borg / Share | `/mnt/user/appdata/komodo/core`, `/mnt/user/appdata/komodo/periphery`, `/mnt/user/services/stacks` | `komodo-mongo.archive.gz` falls verifiziert | `komodo_mongo_password.txt`, `KOMODO_*` Stack ENV | Traefik, Mongo, Gitea | UI erreichbar, Periphery verbunden |
 | GitOps Host Automation | Borg / Git | `/mnt/user/services/homelab-infra`, `/mnt/user/services/posture-check` | keine eigene DB | keine | Gitea, Komodo, Unraid User Scripts | `posture-check` laeuft vom Host-Pfad und liefert `warning_count: 0` im bekannten Uebergangszustand |
-| Vaultwarden | Borg + Dump | `/mnt/user/appdata/vaultwarden` | `vaultwarden.sqlite.dump` | `vaultwarden_admin_token.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | Traefik | Login-Seite erreichbar, Tresor-Daten sichtbar; Mini-Restore nach `/mnt/user/backups/restore-lab/vaultwarden` am 2026-05-07 erfolgreich validiert |
+| Vaultwarden | Borg + Dump | `/mnt/user/appdata/vaultwarden` | `vaultwarden.sqlite.dump` | `vaultwarden_admin_token.txt` fuer Produktion; Restore-Test nutzt Wegwerf-Admin-Token und `borg_repo_passphrase.txt` | Traefik | Login-Seite erreichbar, Tresor-Daten sichtbar; Mini-Restore nach `/mnt/user/backups/restore-lab/vaultwarden` am 2026-05-07 erfolgreich validiert |
+
+---
+
+## Workstations
+
+| System | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
+|---|---|---|---|---|---|---|
+| `baerchen` Windows 11 | Veeam Agent Image auf Unraid-SMB | `/mnt/user/backups/windows-images/baerchen/` bzw. `\\kallilabcore\backups\windows-images\baerchen` | Veeam Restore Points im Zielordner; erster Full-Lauf 2026-06-05, GUI-Groesse 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen | SMB-User `micha`; Veeam Job Encryption Password nur noetig, falls Storage Encryption spaeter aktiviert wird; BitLocker-Recovery-Key erst noetig, wenn BitLocker spaeter aktiviert wird | Veeam Recovery USB `VEEAMRE`, SMB auf `kallilabcore`, AdGuard/DNS oder direkte IP | Recovery-Test am 2026-06-06 erfolgreich: USB-Boot, SMB-Ziel erreichbar, Restore Point sichtbar, vor echtem Restore abgebrochen; Runbook `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
 
 ---
 
@@ -44,14 +52,14 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
 
 | Dienst | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
 |---|---|---|---|---|---|---|
-| Paperless-ngx | Borg + Dumps | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/paperless/export`, `/mnt/user/documents/scans_inbox` | `postgresql17-paperless.dump` | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS`, `borg_repo_passphrase.txt` fuer Restore-Tests | PostgreSQL 17, Redis, Traefik | Web-UI startet, Dokumente vorhanden; Mini-Restore nach `/mnt/user/backups/restore-lab/paperless` am 2026-05-07 erfolgreich validiert |
+| Paperless-ngx | Borg + Dumps | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/paperless/export`, `/mnt/user/documents/scans_inbox` | `postgresql17-paperless.dump` | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS`, `borg_repo_passphrase.txt` fuer Restore-Tests | PostgreSQL 18, Redis, Traefik | Web-UI startet, Dokumente vorhanden; Restore-Test am 2026-05-31 erfolgreich: Borg-Archiv `Tägliche-Sicherung-2026-05-31T04:30:13.181`, isolierter PostgreSQL-18-/Redis-8-Testpfad, HTTP `200`, `32` Dokumente im Test-DB-Check, Report `/mnt/user/backups/restore-reports/paperless-2026-05-31.md` |
-| Mealie | Borg + Dump | `/mnt/user/appdata/mealie/data`, optional `/mnt/user/appdata/mealie/postgres` bei lokalem Share-Weiterbetrieb | `mealie.dump` | `mealie_postgres_password.txt` | `mealie-postgres`, Traefik | UI startet, Rezepte vorhanden |
+| Mealie | Borg + Dump | `/mnt/user/appdata/mealie/data`, `/mnt/user/appdata/mealie/postgres18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`) | `mealie.dump` | `mealie_postgres_password.txt` | `mealie-postgres`, Traefik | UI startet, Rezepte vorhanden |
-| Immich | Borg + Dump | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive` | `immich.dump` | `IMMICH_DB_PASSWORD`, `immich_postgres_password.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | `immich_postgres`, `immich_redis`, Traefik | DB- und UI-Smoke gegen produktives Borg-Archiv am 2026-05-27 erfolgreich validiert: `immich.dump` extrahiert, isolierter pgvecto-rs-Postgres importiert, Immich-Loginseite HTTP 200, `11977` Assets und `1` User im Test-DB-Check; Report `/mnt/user/backups/restore-reports/immich-2026-05-27.md`. Voll-Restore der Foto-Dateien bleibt separater DR-Drill |
+| Immich | Borg + Dump | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive`, `/mnt/user/appdata/immich_postgres_vectorchord`; archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs` | `immich.dump`; nach VectorChord braucht ein Restore ein Postgres-Image mit VectorChord | `IMMICH_DB_PASSWORD`, `immich_postgres_password.txt`, `borg_repo_passphrase.txt` fuer Restore-Tests | `immich_postgres`, `immich_redis`, Traefik | DB- und UI-Smoke gegen produktives Borg-Archiv am 2026-05-27 erfolgreich validiert; VectorChord-Migration am 2026-05-31: `11977` Assets, `11107` Smart-Search-Zeilen, `7092` Face-Search-Zeilen, `vchord 0.4.3`, `vector 0.8.1`, HTTP/API-Smoke 200. Voll-Restore der Foto-Dateien bleibt separater DR-Drill |
-| Mail-Archiver | Borg + Shared Dump | `/mnt/user/appdata/mailarchiver/data-protection-keys` | `postgresql17-mailarchiver.dump` | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` | PostgreSQL 17, Traefik, Authelia | Authelia-Weiterleitung greift; nach Login startet die Web-UI und das Archiv laesst sich oeffnen |
+| Mail-Archiver | Borg + Shared Dump | `/mnt/user/appdata/mailarchiver/data-protection-keys` | `postgresql17-mailarchiver.dump` | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` | PostgreSQL 18, Traefik, Authelia | Authelia-Weiterleitung greift; nach Login startet die Web-UI und das Archiv laesst sich oeffnen |
-| Nextcloud | Borg + Dump | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data` | `nextcloud.dump` | `nextcloud_admin_user.txt`, `nextcloud_admin_password.txt`, `nextcloud_postgres_password.txt` | `nextcloud-postgres`, `nextcloud-redis`, Traefik | Web-UI startet, Login funktioniert, Dateien sichtbar |
+| Nextcloud | Borg + Dump | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data`, `/mnt/user/appdata/nextcloud/postgres18` (archivierter Rollback-Altstand: `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`), `/mnt/user/appdata/nextcloud/redis` | `nextcloud.dump`; Redis-Backup vor Redis-8-Cutover unter `/mnt/user/backups/borg/dumps/latest/nextcloud-redis-pre-redis8-<ts>` | `nextcloud_admin_user.txt`, `nextcloud_admin_password.txt`, `nextcloud_postgres_password.txt`; produktive DB-Rolle laut `config.php` ist `oc_admin` | `nextcloud-postgres`, `nextcloud-redis`, Traefik | Web-UI startet, Login funktioniert, Dateien sichtbar; `occ status` zeigt `maintenance: false` |
 | Glance | Git / Borg-Repo | Repo-Konfiguration unter `ops/glance/config/glance.yml`; keine kritische Datenpersistenz | keine | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` | Traefik, Authelia, optional interne API-Ziele | Dashboard startet, Widgets laden, Docker-Status laeuft nur ueber `glance-docker-socket-proxy` |
 | ntfy | Borg / Share | `/mnt/user/appdata/ntfy` | keine | keine besonderen Secret-Dateien dokumentiert | Traefik | UI und Push-Endpunkt erreichbar |
-| Paperless-GPT | Borg / Share | `/mnt/user/appdata/paperless-gpt` | keine eigene DB | `PAPERLESS_API_TOKEN` | Traefik, Paperless | UI startet, Konfiguration vorhanden |
+| Paperless-GPT | Borg / Share | `/mnt/user/appdata/paperless-gpt` | keine eigene DB | `PAPERLESS_API_TOKEN`, `OPENAI_API_KEY` | Traefik, Paperless, OpenAI API | UI startet, Konfiguration vorhanden; LLM-Provider zeigt `openai` / `gpt-5.4-mini` |
 
 ---
 
@@ -97,6 +105,14 @@ Aktuell relevante Dump-Artefakte unter `/mnt/user/backups/borg/dumps/latest`:
 
 Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.sh` vorgesehen.
 
+### PostgreSQL 18 Restore- und Rollback-Regeln
+
+- PostgreSQL-18-Container verwenden das Docker-Image-Layout mit Mount auf `/var/lib/postgresql` und `PGDATA=/var/lib/postgresql/18/docker`.
+- Die alten PostgreSQL-17-Datenpfade wurden nach Burn-in am 2026-06-02 aus den aktiven Appdata-Pfaden entfernt und unter `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602` archiviert.
+- Shared-Cluster-Restore: zuerst `pg_dumpall --globals-only` einspielen, dann die einzelnen Custom-Format-Dumps per `pg_restore`. Der Bootstrap-Rollenkonflikt fuer `mailarchiver` ist benign, solange `CREATE ROLE mailarchiver;` gezielt ausgelassen und das folgende `ALTER ROLE mailarchiver ...` eingespielt wird.
+- Nextcloud-Restore: vor dem Dump `occ maintenance:mode --on`, nach erfolgreichem Restore und `occ status` wieder `occ maintenance:mode --off`. Die Rolle `oc_admin` muss mit dem in `config.php` hinterlegten DB-Passwort existieren.
+- Rollback: betroffene App(s) und DB stoppen, archivierten Altstand zurueck an den frueheren Datenpfad verschieben, Compose auf das vorherige PostgreSQL-17-Image und den alten Datenpfad zuruecksetzen, dann DB und App wieder starten.
+
 ---
 
 ## Praktische Restore-Regeln
@@ -117,13 +133,210 @@ Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.s
 
 ---
 
-## Erste sinnvolle Referenz-Restores
+## Restore-Test-Reifegrad
 
-Wenn weitere Restore-Uebungen dokumentiert werden sollen, sind diese Dienste besonders geeignet:
+Stand 2026-06-06. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
 
-1. `mail-archiver`
+| Dienst | Tier | Letzter Restore-Test | Typ | Naechster Lauf |
-2. `paperless-ngx`
+|---|---|---|---|---|
-3. `gitea`
+| Vaultwarden | 1 | 2026-05-07 | File + Container + HTTP | monatlich (1. Sa) |
-4. `vaultwarden`
+| Gitea | 1 | 2026-05-07 | File + Container + HTTP + TCP | monatlich (3. Sa) |
+| Authelia | 1 | 2026-06-03 | Config + Validate + HTTP Health | zweimonatlich (2. Sa gerade Mon.) |
+| Komodo Bootstrap | 1 | 2026-05-30 | Compose + Mongo + HTTP | quartalsweise |
+| Paperless | 2 | 2026-05-31 | File + Dump + Container + HTTP + Doc-Count | zweimonatlich (2. Sa ungerade Mon.) |
+| Immich | 2 | 2026-05-27 | Dump + Container + HTTP + Asset-Count | quartalsweise (2. So Feb/Mai/Aug/Nov) |
+| Unraid OS Flash | 1 | 2026-06-05 (Artefakt-Validierung) | sha256 OK + 390 Eintraege + 8 Kern-Configs vorhanden (`ops/maintenance/check-unraid-flash-backup.sh`); **physischer Ersatzstick-Boot-Test weiter offen** | Stick-Boot-Test nach Bedarf |
+| Traefik | 1 | 2026-06-03 | Config + LE-State + File-Provider + Ping 200 | quartalsweise |
+| AdGuard Home | 1 | 2026-06-06 | Config + Container + HTTP 401 + DNS + Filter-Count | quartalsweise oder nach DNS-Aenderungen |
+| Tailscale | 1 | - | noch kein Test | - |
+| PostgreSQL 18 Cluster | 1 | 2026-06-03 | globals + 5 per-DB dumps, 290 Tabellen gesamt | quartalsweise |
+| Redis 8 | 1 | 2026-06-06 | Pre-Cutover-Artefakt + Container + PING + INFO + DBSIZE | quartalsweise oder vor/nach Redis-Major-Aenderungen |
+| Komodo Mongo Daten | 1 | 2026-06-03 | mongorestore --archive --gzip, 86904 docs | quartalsweise |
+| Nextcloud | 2 | 2026-06-03 | File + Dump + Container + HTTP 200 + occ status + Table-Count (126) | quartalsweise |
+| Mealie | 2 | 2026-06-03 | File + Dump + Container + HTTP + Recipe-Count (3) | quartalsweise |
+| Mail-Archiver | 2 | 2026-06-03 | Keys + 645M Dump + Container + HTTP 200 | quartalsweise |
+| Glance | 2 | - | rebuildbar, kein Test noetig | - |
+| ntfy | 2 | - | rebuildbar, kein Test noetig | - |
+| Borg UI | 3 | - | rebuildbar | - |
+| Filebrowser | 3 | - | rebuildbar | - |
+| baerchen Windows Image | Workstation | 2026-06-06 | Full-Backup geschrieben; Recovery-USB-Boot, SMB-Mount und Restore-Point-Sichtpruefung erfolgreich; vor echtem Restore abgebrochen | nach Image-Aenderungen oder quartalsweise |
 
-Sie liefern hohen Erkenntnisgewinn ohne den kompletten Homelab-Neuaufbau zu brauchen.
+---
+
+## Naechste Restore-Test-Kandidaten (priorisiert)
+
+Stand 2026-06-06. Die frueheren Kandidaten (Shared PG18, Komodo Mongo, Mailarchiver, Mealie, Traefik)
+wurden alle am 2026-06-03 abgeschlossen und sind in der Reifegrad-Tabelle belegt.
+
+Verbleibende offene Restore-Pfade ohne vollstaendigen Test:
+
+1. **Unraid OS Flash** - Artefakt-Validierung am 2026-06-05 erfolgreich (siehe Reifegrad-Tabelle und Runbook unten); offen bleibt nur der **physische Ersatzstick-Boot-Test**.
+2. **Tailscale** - State-/Reconnect-Pfad dokumentiert testen
+
+---
+
+## Restore-Test-Runbooks (Entwurf)
+
+Diese Abschnitte sind vorbereitete Checklisten fuer die noch untesteten Restore-Pfade.
+Sie sind **nicht** als produktive Anleitungen zu verwenden, bevor ein erster Testlauf
+die konkreten Artefaktnamen und Pfade bestaetigt hat.
+
+### Unraid OS Flash
+
+**Voraussetzungen:**
+- Borg-Artefakt `unraid-flash-config.tar.gz` und `unraid-flash-config.tar.gz.sha256` unter `/mnt/user/backups/borg/dumps/latest` oder im Hetzner-Borg-Repo verfuegbar
+- Neuer leerer USB-Stick (Empfehlung: 16 GB, USB 2.0 kompatibel)
+- Unraid USB Flash Creator oder manueller Restore-Pfad
+- Offline-gesicherte Borg-Passphrase verfuegbar
+
+**Checkliste Artefakt-Validierung (ohne produktiven Stick):**
+
+Automatisiert via Repo-Skript `ops/maintenance/check-unraid-flash-backup.sh`
+(read-only, keine Extraktion). Manuelle Einzelschritte:
+
+1. SHA256-Pruefung: `sha256sum -c unraid-flash-config.tar.gz.sha256`
+2. Artefakt-Inhalt pruefen: `tar -tzf unraid-flash-config.tar.gz | head -40` — erwartet `config/` als Prefix
+3. Kern-Configs vorhanden: `super.dat`, `disk.cfg`, `ident.cfg`, `share.cfg`, `network.cfg`, `docker.cfg`, `go`, `domain.cfg`
+4. Keine produktiven Konfigurationspfade (z. B. `config/ssh/`) ausserhalb des Test-Environments extrahieren
+5. Manifest-Datei auf Vollstaendigkeit pruefen
+
+**Validierungsergebnis 2026-06-05 (read-only per SSH):** Artefakt frisch
+(2026-06-05 04:00, ~16 h alt beim Test), `sha256sum -c` = OK, 390 Eintraege,
+alle 8 Kern-Configs vorhanden. Das Archiv enthaelt erwartungsgemaess
+Secret-Material (SSH-Host-Keys, Tailscale-State, `passwd`/`shadow`/`smbpasswd`,
+`Trial.key`) und ist wie Secret-Backup zu behandeln. Es wurde nichts extrahiert,
+nur Eintragsnamen gelistet. Offen bleibt der physische Ersatzstick-Boot-Test.
+
+**Checkliste vollstaendiger Restore-Test (auf Wegwerf-Stick):**
+
+1. Neuen USB-Stick mit Unraid USB Flash Creator formatieren und Basis-Unraid draufspielen
+2. `config/`-Verzeichnis aus `unraid-flash-config.tar.gz` in den `/boot/config`-Pfad des neuen Sticks extrahieren
+3. Im Testrahmen booten (kein Array starten, keine Shares mounten)
+4. Pruefen: Unraid-Grundkonfiguration (Shares, Hostname, Netzwerk) ist sichtbar
+5. Array-Zuordnung lesbar, ohne Drive-Assigns zu bestaetigen
+
+**Smoke-Test-Kriterium:** Unraid bootet, Hostname ist `Kallilabcore`, Share-Konfiguration ist sichtbar, kein Array gestartet.
+
+**Sonderregel:** Das Artefakt enthaelt Host-Konfiguration und SSH-Keys und ist wie Secret-Material zu behandeln. Nicht auf oeffentlichen oder unverschluesselten Testzielen extrahieren.
+
+---
+
+### AdGuard Home
+
+**Validierungsergebnis 2026-06-06:** Automatisierter Test
+`ops/restore-tests/adguard-restore-test.sh` auf Unraid erfolgreich ausgefuehrt.
+Report: `/mnt/user/backups/restore-reports/adguard-2026-06-06.md`.
+Getestet wurden Borg-Extract der Config, `AdGuardHome.yaml`-Struktur,
+isolierter Testcontainer `restoretest-adguard` auf localhost-Ports,
+HTTP `/control/status` = `401`, DNS-Smoke `git.kaleschke.info -> 192.168.178.58`,
+7 Filterlisten-Eintraege. Testdaten wurden nach Erfolg bereinigt.
+
+**Voraussetzungen:**
+- Borg-Archiv mit `/mnt/user/appdata/adguard/conf` zugaenglich (produktives Repo oder Teststand)
+- Testpfad unter `/mnt/user/backups/restore-lab/adguard` vorbereitet
+- Docker-Faehigkeit auf dem Testhost oder in der Restore-Lab-Umgebung
+
+**Automatisierter Test:**
+
+```bash
+/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh adguard
+```
+
+**Manuelle Checkliste:**
+
+1. Borg-Extract des letzten Archivs nach `/mnt/user/backups/restore-lab/adguard/conf`:
+   ```
+   borg extract ::ARCHIV /mnt/user/appdata/adguard/conf
+   ```
+2. Konfigurationsdatei `AdGuardHome.yaml` auf Vollstaendigkeit pruefen (YAML-Syntax valide)
+3. Testcontainer starten (kein produktiver DNS-Port 53, stattdessen z. B. `15353`):
+   ```yaml
+   ports:
+     - "127.0.0.1:15353:53/udp"
+     - "127.0.0.1:13001:80/tcp"
+   volumes:
+     - /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
+   ```
+4. `http://127.0.0.1:13001/control/status` erreichbar (`200`, `401` oder `403` sind fuer den Smoke ausreichend)
+5. DNS-Aufloesung: `dig @127.0.0.1 -p 15353 git.kaleschke.info` gibt plausible Antwort
+6. Testcontainer stoppen und Testpfad aufraeumen
+
+**Smoke-Test-Kriterium:** AdGuard-Web-UI laeuft, DNS-Aufloesung antwortet, Filterlisten sind geladen.
+
+**Keine Secrets:** AdGuard Home verwendet keine dokumentierten Repo-Secrets; Login-Credentials liegen in der `AdGuardHome.yaml` im Borg-Archiv.
+
+---
+
+### Tailscale
+
+**Voraussetzungen:**
+- Borg-Archiv mit `/mnt/user/appdata/tailscale` zugaenglich
+- Testpfad unter `/mnt/user/backups/restore-lab/tailscale` vorbereitet
+- Achtung: Der Tailscale-State ist maschinenspezifisch. Ein Restore auf denselben produktiven Host wuerde die laufende Verbindung verdraengen. Nur auf einem Wegwerf- oder Offline-Host testen.
+
+**Checkliste Artefakt-Validierung (ohne produktiven Host):**
+
+1. Borg-Extract nach `/mnt/user/backups/restore-lab/tailscale`
+2. State-Verzeichnis auf erwartete Dateien pruefen: `tailscaled.state` vorhanden
+3. Dateisystem-Rechte pruefen: `tailscaled.state` muss fuer `root` zugaenglich sein
+
+**Checkliste Reconnect-Test (auf Wegwerf-Host oder VM):**
+
+1. Tailscale-Container mit dem gemounteten State-Pfad starten
+2. `tailscale status` zeigt `Connected` oder den erwarteten Hostnamen
+3. Tailscale-Admin-Konsole (`login.tailscale.com`) zeigt Geraet als `Online`
+4. SSH ueber Tailscale-IP auf den Testhost moeglich
+5. Testcontainer stoppen; Wegwerf-Geraet in der Tailscale-Admin-Konsole entfernen
+
+**Smoke-Test-Kriterium:** Container verbindet sich mit bestehendem Tailscale-Account (kein neues Re-Auth noetig), Tailscale-IP ist erreichbar.
+
+**Hinweis:** Falls der State veraltet ist (Key expired), wird Tailscale einen Re-Auth anfordern. Das ist ein valides Testergebnis und belegt, wie lang der Reconnect-Pfad bei abgelaufenem Key ist.
+
+---
+
+### Redis 8 (Shared)
+
+**Validierungsergebnis 2026-06-06:** Automatisierter Test
+`ops/restore-tests/redis-restore-test.sh` auf Unraid erfolgreich ausgefuehrt.
+Report: `/mnt/user/backups/restore-reports/redis-2026-06-06.md`.
+Getestet wurde das Pre-Cutover-Artefakt
+`/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011`
+in einer isolierten Redis-8.8-Testinstanz auf `127.0.0.1:16379`.
+Ergebnis: `PING` = `PONG`, `redis_version` = `8.8.0`, AOF aktiv (`1`),
+`DBSIZE` = `1`. Produktiver Port und produktiver Datenpfad wurden nicht genutzt.
+
+**Voraussetzungen:**
+- Pre-Cutover-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` vorhanden, oder Borg-Archiv mit `/mnt/user/appdata/redis`
+- Secret-Datei `redis_password.txt` fuer Testinstanz verfuegbar (aus Borg, nicht als Wert dokumentieren)
+- Testpfad unter `/mnt/user/backups/restore-lab/redis` vorbereitet
+
+**Automatisierter Test:**
+
+```bash
+/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh redis
+```
+
+**Manuelle Checkliste:**
+
+1. RDB/AOF-Datei aus dem Backup in den Testpfad kopieren:
+   ```
+   cp /mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>/dump.rdb \
+      /mnt/user/backups/restore-lab/redis/
+   ```
+   (oder Borg-Extract aus dem Appdata-Archiv)
+2. Testcontainer starten (kein produktiver Port 6379, stattdessen z. B. `16379`):
+   ```yaml
+   ports:
+     - "127.0.0.1:16379:6379"
+   volumes:
+     - /mnt/user/backups/restore-lab/redis:/data
+   command: redis-server --requirepass <aus Secret> --appendonly yes
+   ```
+3. Verbindungstest: `redis-cli -p 16379 -a <pass> PING` antwortet `PONG`
+4. Redis-Version pruefen: `redis-cli -p 16379 -a <pass> INFO server | grep redis_version` zeigt `8.x`
+5. Stichprobe Key-Bestand: `redis-cli -p 16379 -a <pass> DBSIZE` zeigt plausible Zahl (nicht 0)
+6. Testcontainer stoppen und Testpfad aufraeumen
+
+**Smoke-Test-Kriterium:** Redis 8 startet mit dem Restore-Datenpfad, `PING` antwortet, `DBSIZE` ist nicht 0.
+
+**Shared Redis Besonderheit:** Shared Redis wird produktiv nur von Paperless genutzt (AOF aktiv). Bei einem echten Restore nach App-Absturz: Erst Redis aus Backup hochziehen, dann Paperless. Nextcloud hat eigene Redis-Instanz ohne Passwort.

docs/SECRETS_MAP.md

@@ -17,13 +17,15 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 | Service | Secret | Datei / Methode | Status |
 |---|---|---|---|
 | Vaultwarden | `ADMIN_TOKEN` | `/mnt/user/appdata/secrets/vaultwarden_admin_token.txt` -> `ADMIN_TOKEN_FILE` | aktiv |
+| Vaultwarden | SMTP Password | `/mnt/user/appdata/secrets/homelab_smtp_password.txt` -> `SMTP_PASSWORD_FILE` fuer Einladungen/Benachrichtigungen | aktiv |
 | Traefik | Cloudflare DNS API Token | `/mnt/user/appdata/traefik/secrets/cloudflare_dns_api_token` -> Docker Secret `cloudflare_dns_api_token` | aktiv |
-| PostgreSQL 17 | DB Password | `/mnt/user/appdata/secrets/postgres_password.txt` -> `POSTGRES_PASSWORD_FILE` | aktiv |
+| PostgreSQL 18 | DB Password | `/mnt/user/appdata/secrets/postgres_password.txt` -> `POSTGRES_PASSWORD_FILE` | aktiv |
 | Redis | Passwort | `/mnt/user/appdata/secrets/redis_password.txt` -> Datei-Mount + Startkommando in `infra/redis/docker-compose.yml` | aktiv |
 | Mealie | DB Password | `/mnt/user/appdata/secrets/mealie_postgres_password.txt` -> nicht versionierte Stack-`.env` `${MEALIE_POSTGRES_PASSWORD}` -> `POSTGRES_PASSWORD` | aktiv |
 | mealie-postgres | DB Password | `/mnt/user/appdata/secrets/mealie_postgres_password.txt` -> `POSTGRES_PASSWORD_FILE` | aktiv |
 | Paperless-ngx | DB Password | Stack ENV `${PAPERLESS_DBPASS}` | aktiv |
 | Paperless-ngx | Redis URL | Stack ENV `${PAPERLESS_REDIS}` | aktiv |
+| Paperless-GPT | OpenAI API Key | Stack ENV `${OPENAI_API_KEY}`; nicht im Repo, nicht in Logs | aktiv |
 | code-server | Passwort | `/mnt/user/appdata/code-server/secrets/password` -> `FILE__PASSWORD` | aktiv |
 | Filebrowser | Admin Password | `/mnt/user/appdata/secrets/filebrowser_admin_password.txt` -> initialisierte SQLite-DB | aktiv |
 | Immich (server) | DB Password | Stack ENV `${IMMICH_DB_PASSWORD}` | aktiv |
@@ -51,8 +53,16 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 | InfluxDB 3 Core | Admin Token JSON | `/mnt/user/appdata/secrets/influxdb3_admin_token.json` -> Docker Secret `/run/secrets/influxdb3_admin_token` | aktiv |
 | Monitoring Grafana | Admin Password | `/mnt/user/appdata/secrets/monitoring_grafana_admin_password.txt` -> Docker Secret `/run/secrets/monitoring_grafana_admin_password` -> `GF_SECURITY_ADMIN_PASSWORD__FILE` | aktiv |
 | Monitoring Grafana -> InfluxDB | Datasource Token | `/mnt/user/appdata/secrets/monitoring_grafana_influxdb_token.txt` -> Docker Secret `/run/secrets/monitoring_grafana_influxdb_token` | aktiv |
-| Home Assistant -> InfluxDB | HA InfluxDB Token | `/homeassistant/secrets.yaml` -> `influxdb3_homeassistant_token` | geplant |
+| Grafana OIDC (Authelia) | Client Secret | `/mnt/user/appdata/secrets/grafana_oidc_client_secret` (Klartext, chmod 600) -> Docker Secret `/run/secrets/grafana_oidc_client_secret` -> `GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET__FILE`. Zugehoeriger pbkdf2-Hash liegt im Authelia-Host-Config-Client `grafana` (kein Wert im Repo) | aktiv (2026-06-06) |
+| Mealie OIDC (Authelia) | Client Secret | Stack-ENV `${MEALIE_OIDC_CLIENT_SECRET}` in `/mnt/user/services/stacks/mealie/apps/mealie/.env` (Komodo-Stack-ENV); pbkdf2-Hash im Authelia-Host-Config-Client `mealie` (kein Wert im Repo) | aktiv (2026-06-06) |
 | Renovate Bot | Gitea Service-Account PAT | `/mnt/user/appdata/secrets/renovate_token.txt` -> Host-Datei (chmod 600), gelesen von `ops/renovate/run-renovate.sh` und an Renovate-Container als `RENOVATE_TOKEN` weitergegeben | aktiv nach Operator-Setup (siehe `docs/RENOVATE.md`) |
+| n8n | Encryption Key fuer interne Credential-Verschluesselung | `/mnt/user/appdata/secrets/n8n_encryption_key.txt` (chmod 600) -> Komodo Stack ENV `${N8N_ENCRYPTION_KEY}`; kein `_FILE`-Support im Upstream-Image | aktiv |
+| n8n | GMX IMAP Login (Mail-Trigger Workflow) | n8n Credentials Store (Typ `imap`), nur in `/mnt/user/appdata/n8n/data` mit `N8N_ENCRYPTION_KEY` verschluesselt | aktiv |
+| n8n | OpenAI API Key (LLM-Extraktion Workflow) | n8n Credentials Store (Typ `httpHeaderAuth`, Header `Authorization: Bearer ...`) | aktiv |
+| n8n | Gitea PAT fuer `n8n-bot` (Issue-Erstellung Workflow) | n8n Credentials Store (Typ `httpHeaderAuth`, Header `Authorization: token ...`); separater Bot-User mit Scope `write:issue` auf `Micha/mails` | aktiv |
+| baerchen Veeam | Veeam Job Encryption Password | Vaultwarden Secure Note `Veeam baerchen backup encryption password`; kein Datei-Secret im Repo | geplant, nur noetig falls Veeam Storage Encryption aktiviert wird |
+| baerchen SMB Backup Target | SMB Credential fuer User `micha` | bestehender Unraid-/Vaultwarden-Zugang fuer Share `backups`; wird im Veeam-Job gespeichert, Wert nie dokumentieren | aktiv |
+| baerchen BitLocker | BitLocker Recovery Key C: | **bewusst deaktiviert (Entscheidung 2026-06-06):** kein BitLocker, kein Recovery-Key noetig. Falls spaeter aktiviert: Key nach `D:\30_Finanzen\BitLocker-RecoveryKey-baerchen-<DATUM>.txt` + Vaultwarden Secure Note + physischer Ausdruck | nicht aktiv (bewusst) |
 
 ---
 
@@ -89,6 +99,7 @@ Dieses Dokument listet sensible Daten, deren Ablageorte und die vorgesehene Einb
 |-- borg_repo_passphrase.txt
 |-- influxdb3_admin_token.json
 |-- filebrowser_admin_password.txt
+|-- homelab_smtp_password.txt
 `-- vaultwarden_admin_token.txt
 ```
 
@@ -101,6 +112,12 @@ Weitere dokumentierte Secret-Pfade:
 - Die Borg-Repo-Passphrase liegt zusaetzlich als Host-Secret-Datei fuer Restore-Tests und Notfallzugriff vor. Der Wert ist laut Operator-Bestaetigung vom 2026-05-26 offline gesichert; Ablageort und Wert werden nicht im Repo dokumentiert.
 - Gitea verwaltet den GitHub-Push-Mirror-PAT in den Repository-Mirror-Settings. Der Wert wird nicht dokumentiert und nicht in Dateien unter `docs/` oder `core/gitea/` geschrieben.
 - `paperless-ngx` ist eine bewusste Ausnahme: DB-Passwort und Redis-URL bleiben aktuell als Komodo Stack Environment Variables hinterlegt, um den stabil laufenden Produktionsstand nicht fuer eine reine Secret-Mechanik-Migration zu riskieren.
+- `baerchen` nutzt fuer das Veeam-Backup aktuell den bestehenden SMB-User
+  `micha`. Ein dedizierter SMB-User `veeam-baerchen` ist nur ein spaeteres
+  Hardening-Ziel, solange keine Unraid-User-/Share-Aenderungen gewuenscht sind.
+- Das Veeam-Job-Encryption-Passwort ist restore-kritisch. Ohne diesen Wert ist
+  das Image unter `\\kallilabcore\backups\windows-images\baerchen` nicht
+  brauchbar.
 
 ---
 
@@ -109,8 +126,7 @@ Weitere dokumentierte Secret-Pfade:
 Einige Secrets liegen bewusst nur als Komodo Stack Environment Variables vor, weil das Image kein `_FILE` unterstuetzt oder ein laufender stabiler Produktionsstand nicht fuer eine reine Mechanik-Migration geopfert werden soll. Diese Werte existieren **ausschliesslich** an folgenden Stellen:
 
 1. **Komodo Mongo** (Runtime und Backup-Dump `komodo-mongo.archive.gz` unter `/mnt/user/backups/borg/dumps/latest/`).
-2. **Vaultwarden** (Operator-Eintrag pro Stack, sofern dort gepflegt).
+2. **Externe Operator-Notiz** (analoge Sicherung, vergleichbar mit der Borg-Passphrase).
-3. **Externe Operator-Notiz** (analoge Sicherung, vergleichbar mit der Borg-Passphrase).
 
 **Bei Komodo-Restore aus kaltem Zustand wird immer in dieser Reihenfolge gesucht.** Konkrete Werte werden im Repo, in Logs, in Doku-Kommentaren und in ntfy-Meldungen niemals wiedergegeben.
 
@@ -119,12 +135,14 @@ Einige Secrets liegen bewusst nur als Komodo Stack Environment Variables vor, we
 | Stack | Stack-ENV-Variablen | Restore-Quelle (Reihenfolge) | Folgen bei Verlust aller Quellen |
 |---|---|---|---|
 | `paperless-ngx` | `PAPERLESS_DBPASS`, `PAPERLESS_REDIS` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | App-DB ist im Postgres-Cluster, Passwort muss in Postgres und Stack-ENV synchron neu gesetzt werden; Redis-URL ist deterministisch rekonstruierbar (Host, Port, Passwort), wenn Redis-Passwort-Datei vorliegt |
+| `paperless-gpt` | `PAPERLESS_API_TOKEN`, `OPENAI_API_KEY` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | Paperless-Token kann in Paperless neu erzeugt werden; OpenAI-Key muss im OpenAI-Projekt rotiert/neu erstellt werden |
 | `immich-server` | `IMMICH_DB_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | analog Paperless: Postgres-User-Passwort in `immich_postgres` und Stack-ENV gemeinsam zuruecksetzen |
 | `mail-archiver` | `MAILARCHIVER_DB_CONNECTION`, `MAILARCHIVER_AUTH_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | DB-Connection-String enthaelt Postgres-Pass; App-Auth-Password fuer Web-UI |
 | `speedtest-tracker` | `APP_KEY`, `ADMIN_PASSWORD` | Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | `APP_KEY` ist verschluesselungsrelevant; bei echtem Verlust App-State frisch initialisieren |
 | `komodo-core` | `KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY` | Vaultwarden -> externe Notiz (Henne-Ei: Komodo-Mongo-Dump ist hier **nicht** Restore-Quelle, weil Komodo dafuer schon laufen muesste) | siehe `docs/SERVICES_RECOVERY.md` Komodo-Bootstrap; ohne diese Werte ist der Self-Stack nicht reproduzierbar |
 | `hermes-agent` | `HERMES_DASHBOARD_HOST` plus Provider-/API-/Home-Assistant-Tokens in Host-`.env` | Vaultwarden -> externe Notiz | Stack ist aktuell geparkt (Review 2026-07-25); ohne Werte bleibt der Stack deaktiviert, kein Schaden am Rest |
 | `glance` | `GLANCE_IMMICH_API_KEY`, `GLANCE_ADGUARD_USERNAME`, `GLANCE_ADGUARD_PASSWORD`, `GLANCE_SPEEDTEST_API_KEY` | Provider-UIs (Immich, AdGuard, Speedtest-Tracker) neu erzeugen | rebuildbar; Widgets bleiben leer bis Tokens neu erzeugt sind, kein kritischer Datentopf |
+| `n8n` | `N8N_ENCRYPTION_KEY` | Host-Secret-Datei `/mnt/user/appdata/secrets/n8n_encryption_key.txt` -> Komodo-Mongo-Dump -> Vaultwarden -> externe Notiz | Bei Verlust aller Quellen: n8n startet, aber **alle gespeicherten Credentials sind unbrauchbar** (Re-Eingabe noetig: GMX IMAP, OpenAI, Gitea PAT). Workflows bleiben strukturell erhalten. |
 
 ### Komodo-Sonderfall
 

docs/SERVICES_RECOVERY.md

@@ -140,7 +140,11 @@ Erst nach erfolgreichem Komodo-Bootstrap werden produktive Stacks ueber den doku
 
 ### Trockenlauf (als Repo-Skript, bestaetigt)
 
-Trockenlauf gegen Wegwerf-Pfade ist seit 2026-05-29 als Repo-Skript abgelegt: `ops/restore-tests/komodo-bootstrap-{compose.test.yml,test.sh,plan.md,runbook.md}`. Aufruf:
+Trockenlauf gegen Wegwerf-Pfade ist seit 2026-05-29 als Repo-Skript abgelegt:
+`ops/restore-tests/komodo-bootstrap-compose.test.yml`,
+`ops/restore-tests/komodo-bootstrap-test.sh`,
+`ops/restore-tests/komodo-bootstrap-plan.md` und
+`ops/restore-tests/komodo-bootstrap-runbook.md`. Aufruf:
 
 ```bash
 bash /mnt/user/services/homelab-infra/ops/restore-tests/komodo-bootstrap-test.sh --what-if   # nur Plan

docs/SERVICE_CATALOG.md

@@ -1,6 +1,6 @@
 # Service Catalog
 
-Stand: 2026-05-23
+Stand: 2026-06-02
 
 Dieser Katalog beschreibt produktive und repo-vorbereitete Dienste aus Sicht von Betrieb, Restore und KI-Kontext. Er basiert auf dem Repo-Sollzustand. Vor produktiven Eingriffen immer den Live-Zustand in Komodo/Docker pruefen.
 
@@ -13,43 +13,44 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
 | `traefik` | zentraler Reverse Proxy, TLS, Docker-Label-Routing | `traefik/docker-compose.yml`, `traefik/dynamic/*` | `https://traefik.kaleschke.info` | Docker socket, Cloudflare DNS API, `frontend_net`, `backend_net` | `/mnt/user/appdata/traefik/dynamic`, `/mnt/user/appdata/traefik/letsencrypt` | Tier 1, Share/Borg | ja, eigene Dashboard-Route mit Authelia | Host-Ports 80/443 sind zentrale Ausnahme; dynamic configs werden nicht automatisch von Komodo deployed |
 | `adguard` | DNS-Server / LAN DNS | `host-services/Adguard/docker-compose.yml` | LAN-Port `53`, Admin `100.80.98.33:8082` | `dns_net`, `frontend_net`, Unbound | `/mnt/user/appdata/adguard/conf`, `/mnt/user/appdata/adguard/work` | Tier 1, config relevant | nein | Direkter DNS-Port 53 bleibt; Admin-Port ist bewusst ohne Traefik/2FA, aber auf Tailscale-IP begrenzt (Operator-Entscheidung 2026-05-26) |
 | `unbound` | Upstream DNS Resolver fuer AdGuard | `apps/unbound/docker-compose.yml` | intern | `dns_net` | `/mnt/user/appdata/unbound/config` | rebuildbar / config relevant | nein | intern isoliert |
-| `tailscale` | VPN/Remote-Zugang | `host-services/tailscale/docker-compose.yml` | Tailscale | Host-Netz | `/mnt/user/appdata/tailscale` | Tier 1, State relevant | nein | `network_mode: host`, `NET_ADMIN`, `NET_RAW` und `/dev/net/tun` sind dokumentierte VPN-Ausnahmen |
+| `tailscale` | VPN/Remote-Zugang, Subnet-Router | **Natives Unraid-Plugin** `tailscale.plg` (nicht repo-/Komodo-verwaltet) | Tailscale | Host-Netz (`tailscale1`) | `/boot/config/plugins/tailscale/state` (im Flash-Backup) | Tier 1, State relevant | nein | Subnet-Router `192.168.178.0/24`; redundanter Docker-Stack `host-services/tailscale/` am 2026-06-06 entfernt |
 | `gitea` | Git-Server / origin fuer GitOps | `core/gitea/docker-compose.yml` | `https://git.kaleschke.info`, SSH `222` | Traefik, `frontend_net`, externe DNS-Resolver fuer GitHub-Push-Mirror | `/mnt/user/services/gitea/data` | Tier 1, `gitea.sqlite.dump` + Share; privater GitHub-Push-Mirror fuer Repo-Bootstrap | ja | SSH-Port 222 direkte Host-Port-Ausnahme; Push-Mirror nach `michaelkaleschke-spec/homelab-infra` reduziert das DR-Bootstrap-Risiko |
 
 ## Security / Identity
 
 | Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
 |---|---|---|---|---|---|---|---|---|
-| `authelia` | ForwardAuth / zentrale Auth fuer Admin-UIs | `security/authelia/docker-compose.yml`, `security/authelia/configuration.yml` | `https://auth.kaleschke.info` | PostgreSQL 17, Traefik, GMX SMTP | `/mnt/user/appdata/authelia/config`, Authelia Secret-Dateien | Tier 1, config + DB + secrets | ja | Bewusst ohne Redis-Session-Backend; SMTP-Notifier via GMX und `authelia_smtp_password.txt`; explizite DNS-Server fuer SMTP/NTP; Repo-Baseline muss manuell in die Host-Config gemerged werden, OIDC/Secrets bleiben hostseitig; Access-Control und Compose-Middleware bei Aenderungen abgleichen |
+| `authelia` | ForwardAuth / zentrale Auth fuer Admin-UIs | `security/authelia/docker-compose.yml`, `security/authelia/configuration.yml` | `https://auth.kaleschke.info` | PostgreSQL 18, Traefik, GMX SMTP | `/mnt/user/appdata/authelia/config`, Authelia Secret-Dateien | Tier 1, config + DB + secrets | ja | Bewusst ohne Redis-Session-Backend; SMTP-Notifier via GMX und `authelia_smtp_password.txt`; explizite DNS-Server fuer SMTP/NTP; Repo-Baseline muss manuell in die Host-Config gemerged werden, OIDC/Secrets bleiben hostseitig; Access-Control und Compose-Middleware bei Aenderungen abgleichen |
-| `vaultwarden` | Passwort-Tresor | `security/vaultwarden/docker-compose.yml` | `https://vault.kaleschke.info` | Traefik, `frontend_net` | `/mnt/user/appdata/vaultwarden` | Tier 1, `vaultwarden.sqlite.dump` + Share | ja | `ADMIN_TOKEN_FILE`; keine direkten Ports |
+| `vaultwarden` | Passwort-Tresor | `security/vaultwarden/docker-compose.yml` | `https://vault.kaleschke.info` | Traefik, `frontend_net`, GMX SMTP | `/mnt/user/appdata/vaultwarden` | Tier 1, `vaultwarden.sqlite.dump` + Share | ja | `ADMIN_TOKEN_FILE`; SMTP ueber `homelab_smtp_password.txt` fuer Einladungen/Benachrichtigungen; keine direkten Ports |
 
 ## Shared Infrastructure
 
 | Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
 |---|---|---|---|---|---|---|---|---|
-| `postgresql17` | shared PostgreSQL Cluster | `infra/postgresql17/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/postgresql17`, `postgres_password.txt` | Tier 1; Dumps unter `/mnt/user/backups/borg/dumps/latest` | nein | keine Host-Ports; raw DB nicht primaerer Restore-Weg |
+| `postgresql17` | shared PostgreSQL 18 Cluster (historischer Service-Name bleibt fuer DNS/Clients stabil) | `infra/postgresql17/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/postgresql18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17`, `postgres_password.txt` | Tier 1; Dumps unter `/mnt/user/backups/borg/dumps/latest` | nein | keine Host-Ports; raw DB nicht primaerer Restore-Weg |
-| `Redis` | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt | `infra/redis/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/redis`, `redis_password.txt` | transiente Daten, bewusst nicht kritisch | nein | Passwort-Datei; optional named volume offen. Immich, Nextcloud und Mealie nutzen jeweils eigene Redis-Instanzen; Authelia laeuft bewusst ohne Redis-Session-Backend. Bei Wegfall ist Paperless der einzige betroffene Stack. |
+| `Redis` | primaer Paperless-Redis (App-Cache); historisch als "shared" angelegt, faktisch nur von Paperless genutzt | `infra/redis/docker-compose.yml` | intern | `backend_net` | `/mnt/user/appdata/redis`, `redis_password.txt` | transiente Daten, bewusst nicht kritisch | nein | Redis 8.8; Passwort-Datei; optional named volume offen. Immich, Nextcloud und Mealie nutzen jeweils eigene Redis-Instanzen; Authelia laeuft bewusst ohne Redis-Session-Backend. Bei Wegfall ist Paperless der einzige betroffene Stack. |
 | `ddns-updater` | Cloudflare/DDNS Aktualisierung | `infra/ddns-updater/docker-compose.yml` | intern | Internetzugang, `frontend_net` | `/mnt/user/appdata/ddns-updater` | rebuildbar | nein | bleibt bewusst in `frontend_net`, weil `backend_net` internal ist |
 
 ## Public / User Apps
 
 | Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
 |---|---|---|---|---|---|---|---|---|
-| `paperless-ngx` | Dokumentenmanagement | `apps/paperless/docker-compose.yml` | `https://paperless.kaleschke.info` | PostgreSQL 17, Redis, Traefik | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/scans_inbox` | Tier 2, Borg + `postgresql17-paperless.dump` | ja | DB/Redis Secrets bleiben bewusst Stack ENV |
+| `paperless-ngx` | Dokumentenmanagement | `apps/paperless/docker-compose.yml` | `https://paperless.kaleschke.info` | PostgreSQL 18, Redis 8, Traefik | `/mnt/user/appdata/paperless-ngx/data`, `/mnt/user/documents/paperless`, `/mnt/user/documents/scans_inbox` | Tier 2, Borg + `postgresql17-paperless.dump` | ja | DB/Redis Secrets bleiben bewusst Stack ENV; Dump-Dateiname behaelt den historischen Cluster-Namen |
-| `paperless-gpt` | KI-Ergaenzung fuer Paperless | `apps/paperless-gpt/docker-compose.yml` | `https://paperless-gpt.kaleschke.info` | Paperless API, LLM/Ollama, Traefik | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` | Tier 2 | ja + Authelia | API Token als Stack ENV; OCR/LLM-Konfig bei Aenderungen pruefen. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv, auch wenn aktuell keine Traefik-Zugriffe in der Woche; Ablouseplanung erst mit Paperless-NGX 3.0 (eigene KI-Features erwartet) - dann neu bewerten. |
+| `paperless-gpt` | KI-Ergaenzung fuer Paperless | `apps/paperless-gpt/docker-compose.yml` | `https://paperless-gpt.kaleschke.info` | Paperless API, OpenAI API, Traefik | `/mnt/user/appdata/paperless-gpt/data`, `/mnt/user/appdata/paperless-gpt/prompts` | Tier 2 | ja + Authelia | `PAPERLESS_API_TOKEN` und `OPENAI_API_KEY` als Stack ENV; LLM und Vision-OCR laufen ueber `gpt-5.4-mini`, kein Zugriff mehr auf lokale Ollama-VM. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv, auch wenn aktuell keine Traefik-Zugriffe in der Woche; Ablouseplanung erst mit Paperless-NGX 3.0 (eigene KI-Features erwartet) - dann neu bewerten. |
 | `immich_server` | Foto-/Video-App | `apps/immich/docker-compose.yml` | `https://immich.kaleschke.info` | Immich Postgres, Immich Redis, ML, Traefik | `/mnt/user/photos/immich`, `/mnt/user/photos/family_archive` | Tier 2, Borg + `immich.dump` | ja | native App-Auth; externes Fotoarchiv gemountet |
-| `immich_postgres` | Immich-Datenbank | `apps/immich/docker-compose.yml` | intern | `immich_default` | `/mnt/user/appdata/immich_postgres`, `immich_postgres_password.txt` | Dump `immich.dump` | nein | nie ins `frontend_net` |
+| `immich_postgres` | Immich-Datenbank | `apps/immich/docker-compose.yml` | intern | `immich_default` | `/mnt/user/appdata/immich_postgres_vectorchord`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs`, `immich_postgres_password.txt` | Dump `immich.dump`; Restore braucht ein Image mit VectorChord/pgvector | nein | PG14 bleibt bewusst; Immich-DB-Image `ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0`; nie ins `frontend_net` |
-| `immich_redis` | Immich Cache | `apps/immich/docker-compose.yml` | intern | `immich_default` | kein kritischer Pfad dokumentiert | rebuildbar | nein | Architektur nennt anonymes Volume -> named volume als offenes Thema |
+| `immich_redis` | Immich Cache | `apps/immich/docker-compose.yml` | intern | `immich_default` | kein kritischer Pfad dokumentiert | rebuildbar | nein | Redis 8.8; Architektur nennt anonymes Volume -> named volume als offenes Thema |
 | `immich_machine_learning` | Immich ML | `apps/immich/docker-compose.yml` | intern | `immich_default` | `model-cache` | rebuildbar | nein | intern-only |
 | `mealie` | Rezeptverwaltung | `apps/mealie/docker-compose.yml` | `https://mealie.kaleschke.info` | `mealie-postgres`, Traefik | `/mnt/user/appdata/mealie/data` | Tier 2, Borg + `mealie.dump` | ja | App + DB in internem Netz getrennt |
-| `mealie-postgres` | Mealie-Datenbank | `apps/mealie/docker-compose.yml` | intern | `mealie_internal` | `/mnt/user/appdata/mealie/postgres`, `mealie_postgres_password.txt` | Dump `mealie.dump` | nein | interne DB |
+| `mealie-postgres` | Mealie-Datenbank | `apps/mealie/docker-compose.yml` | intern | `mealie_internal` | `/mnt/user/appdata/mealie/postgres18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17`, `mealie_postgres_password.txt` | Dump `mealie.dump` | nein | interne DB; PostgreSQL 18 |
-| `mail-archiver` | Mail-Archivierung | `apps/mail-archiver/docker-compose.yml` | `https://mail.kaleschke.info` | PostgreSQL 17, Internet/IMAP, Traefik, Authelia | `/mnt/user/appdata/mailarchiver/data-protection-keys` | Tier 2, `postgresql17-mailarchiver.dump` | ja + Authelia | Hybrid-Dienst: `frontend_net` fuer Internet, `backend_net` fuer DB; App-eigene Auth bleibt zusaetzliche Schutzschicht |
+| `mail-archiver` | Mail-Archivierung | `apps/mail-archiver/docker-compose.yml` | `https://mail.kaleschke.info` | PostgreSQL 18, Internet/IMAP, Traefik, Authelia | `/mnt/user/appdata/mailarchiver/data-protection-keys` | Tier 2, `postgresql17-mailarchiver.dump` | ja + Authelia | Hybrid-Dienst: `frontend_net` fuer Internet, `backend_net` fuer DB; App-eigene Auth bleibt zusaetzliche Schutzschicht; Dump-Dateiname behaelt den historischen Cluster-Namen |
 | `nextcloud` | Datei-/Cloud-Dienst | `apps/nextcloud/docker-compose.yml` | `https://cloud.kaleschke.info` | eigene PostgreSQL, eigene Redis, Traefik | `/mnt/user/appdata/nextcloud/html`, `/mnt/user/documents/nextcloud-data` | Tier 2, `nextcloud.dump` + Share | ja | native App-Auth ohne zentrale ForwardAuth; WebDAV/CardDAV beachten |
-| `nextcloud-postgres` | Nextcloud-Datenbank | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/postgres`, `nextcloud_postgres_password.txt` | `nextcloud.dump`, raw DB nicht primaerer Restore-Weg | nein | interne DB |
+| `nextcloud-postgres` | Nextcloud-Datenbank | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/postgres18`, archivierter Rollback-Altstand `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17`, `nextcloud_postgres_password.txt` | `nextcloud.dump`, raw DB nicht primaerer Restore-Weg | nein | interne DB; PostgreSQL 18 |
-| `nextcloud-redis` | Nextcloud Cache/Locking | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/redis` | Teil von Nextcloud-Restore | nein | interne Redis |
+| `nextcloud-redis` | Nextcloud Cache/Locking | `apps/nextcloud/docker-compose.yml` | intern | `nextcloud_internal` | `/mnt/user/appdata/nextcloud/redis` | Teil von Nextcloud-Restore | nein | interne Redis 8.8 |
-| `plex` | Medienserver mit LAN-/Client-Discovery | `host-services/plex/docker-compose.yml` | Plex native, **LAN/Tailscale-only**, Remote Access deaktiviert | Host-Netz | `/mnt/user/appdata/plex/config`, `/mnt/user/appdata/plex/transcode`, `/mnt/user/media`, `/mnt/user/photos` | Tier 2, Appdata + Medienpfade im Borg-/Share-Scope | nein | Repo-Compose-Stack; `network_mode: host` bleibt dokumentierte Discovery-Ausnahme. Server geclaimt von `Xeridos` (Reclaim 2026-05-28 nach Preferences-Reset vom 18.05.). Smart-TVs greifen ueber WLAN-LAN per mDNS/Plex-GDM direkt zu. `PublishServerOnPlexOnlineKey=0` (Remote Access aus), `RelayEnabled` ebenfalls aus. |
+| `plex` | Medienserver mit LAN-/Client-Discovery | `host-services/plex/docker-compose.yml`, `traefik/dynamic/plex.yml` | `https://plex.kaleschke.info`, LAN `http://192.168.178.58:32400/web`, Remote Access deaktiviert | Host-Netz, Traefik File provider | `/mnt/user/appdata/plex/config`, `/mnt/user/appdata/plex/transcode`, `/mnt/user/media`, `/mnt/user/photos` | Tier 2, Appdata + Medienpfade im Borg-/Share-Scope | ja, native Plex-Auth | Repo-Compose-Stack; `network_mode: host` bleibt dokumentierte Discovery-Ausnahme. Traefik routet via File-Provider-Ausnahme auf `http://192.168.178.58:32400`, weil Docker-Labels Host-Netz-Container aus Traefik heraus auf `127.0.0.1` routen wuerden. Keine FRITZ!Box-Freigabe fuer `32400`. Keine Authelia-ForwardAuth, weil Plex Web/App-Clients native Plex-Auth und eigene Flows nutzen. Server geclaimt von `Xeridos`; Smart-TVs greifen weiter ueber WLAN-LAN per mDNS/Plex-GDM direkt zu. `PublishServerOnPlexOnlineKey=0` (Plex Remote Access aus), `RelayEnabled` ebenfalls aus. |
 | `ntfy` | Push-Benachrichtigungen | `apps/ntfy/docker-compose.yml` | `https://ntfy.kaleschke.info` | Traefik, upstream mobile push | `/mnt/user/appdata/ntfy` | Tier 2 | ja | `NTFY_BEHIND_PROXY=true`; Problem-Alerts gehen gebuendelt an `homelab-alerts`, optionale Erfolgsmeldungen an `homelab-info` |
 | `bentopdf` | PDF-Tooling / Ersatz fuer Stirling-PDF | `apps/bentopdf/docker-compose.yml` | `https://pdf.kaleschke.info` | Traefik + Authelia | keine kritische Persistenz im Compose | Tier 3, rebuildbar | ja + Authelia | COOP/COEP per Middleware. **Behalten-Entscheidung 2026-05-28:** Container bleibt aktiv als situatives Tool, auch wenn aktuell keine Traefik-Zugriffe in der Woche. Resource-Footprint vernachlaessigbar (~4 MB RAM). |
+| `super-productivity` | Persoenliche Produktivitaets-/Task-PWA (Operator), konsumiert Gitea-Issues aus `Micha/mails` | `apps/super-productivity/docker-compose.yml` | `https://sp.kaleschke.info` | Traefik + Authelia, Gitea `Micha/mails` (Polling vom Client) | statisches Frontend, kein Server-State; Browser-IndexedDB plus optionaler WebDAV-Sync gegen Nextcloud | Tier 3, rebuildbar | ja + Authelia | Reine Static-PWA; SP synchronisiert client-seitig ueber Gitea-API (Scope `assigned`, Repo `Micha/mails`, User `Micha`). |
 
 ## Operations / Monitoring / Admin
 
@@ -65,7 +66,7 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
 | `speedtest-tracker` | Speedtest-Monitoring | `ops/speedtest/docker-compose.yml` | `https://speedtest.kaleschke.info` | Traefik + Authelia | `/mnt/user/appdata/speedtest-tracker/config` | Tier 3, `speedtest-tracker.sqlite.dump` | ja + Authelia | `APP_KEY`, `ADMIN_PASSWORD` Stack ENV |
 | `filebrowser` | Datei-Browser fuer Documents/Photos/Projekte | `ops/filebrowser/docker-compose.yml` | `https://files.kaleschke.info` | Traefik + Authelia | `/mnt/user/appdata/filebrowser/*`, `/mnt/user/documents`, `/mnt/user/photos`, `/mnt/user/projekte` | Tier 3, `filebrowser.bolt.dump` + Share | ja + Authelia | Breiter Appdata-Mount entfernt; Secrets und Traefik-Dynamic-Config sind nicht mehr ueber Filebrowser gemountet |
 | `code-server` | Web-Editor / Operations Workspace | `ops/code-server/docker-compose.yml` | `https://code.kaleschke.info` | Traefik + Authelia | `/mnt/user/appdata/code-server`, `/mnt/user/services/dev` | Tier 3 | ja + Authelia | Passwort ueber LSIO `FILE__PASSWORD`; Workspaces beachten |
-| `monitoring-grafana` | zentrale Observability-UI fuer Metriken, Logs und InfluxDB | `monitoring/docker-compose.yml` | `https://monitoring.kaleschke.info` | Traefik + Authelia, Prometheus, Loki, InfluxDB 3 Core | named volume `grafana_data`, Provisioning unter `monitoring/grafana/provisioning`, Dashboards unter `monitoring/grafana/dashboards` | Tier 3, named volume | ja + Authelia | Admin-Passwort ueber `monitoring_grafana_admin_password.txt`; Zielbestand: `Homelab / Availability`, `Homelab / Host Overview`, `Homelab / Containers + Logs`, `Traefik Official Standalone Dashboard`; Dashboard-Importer ist optionales `bootstrap`-Profil fuer Traefik |
+| `monitoring-grafana` | zentrale Observability-UI fuer Metriken, Logs und InfluxDB | `monitoring/docker-compose.yml` | `https://monitoring.kaleschke.info` | Traefik + Authelia, Prometheus, Loki, InfluxDB 3 Core | named volume `grafana_data`, Provisioning unter `monitoring/grafana/provisioning`, Dashboards unter `monitoring/grafana/dashboards` | Tier 3, named volume | ja + Authelia | Admin-Passwort ueber `monitoring_grafana_admin_password.txt`; Zielbestand: `Homelab / Availability`, `Homelab / Host Overview`, `Homelab / Containers + Logs`, `Homelab / Family Status`, `Traefik Official Standalone Dashboard`; Dashboard-Importer ist optionales `bootstrap`-Profil fuer Traefik |
 | `monitoring-prometheus` | Metrik-Speicher fuer Homelab-Monitoring | `monitoring/docker-compose.yml`, `monitoring/prometheus/prometheus.yml`, `monitoring/prometheus/alerts.yml` | intern `http://prometheus:9090` | `monitoring_net`, node-exporter, cAdvisor, Traefik-Metrics, Blackbox Exporter, Alertmanager | named volume `prometheus_data` | Tier 3, transiente Metriken mit 30 Tagen Retention | nein | Scrapes: Prometheus, node-exporter, cAdvisor, Traefik `:8082`, `blackbox-http`; Prometheus-Regeln senden an Alertmanager und von dort nach ntfy |
 | `monitoring-alertmanager` | Alert-Routing fuer Prometheus-Regeln | `monitoring/docker-compose.yml`, `monitoring/alertmanager/alertmanager.yml` | intern `:9093` | Prometheus, ntfy Bridge | named volume `alertmanager_data` | Tier 3 | nein | sendet firing und resolved Alerts an `monitoring-alertmanager-ntfy-bridge` |
 | `monitoring-alertmanager-ntfy-bridge` | Alertmanager-Webhook nach ntfy Push | `monitoring/docker-compose.yml`, `monitoring/alertmanager-ntfy-bridge/bridge.py` | intern `:8080` | Alertmanager, `https://ntfy.kaleschke.info/homelab-alerts` | kein kritischer Zustand | rebuildbar | nein | formatiert Alertmanager JSON als ntfy Titel, Nachricht, Priority und Tags; keine Secrets |
@@ -74,16 +75,17 @@ Secret-Werte sind nicht enthalten. Es werden nur Secret-Namen, Env-Key-Namen und
 | `monitoring-promtail` | Docker-Log-Collector fuer Monitoring-Loki | `monitoring/docker-compose.yml`, `monitoring/promtail/promtail-config.yml` | intern | Docker socket read-only, Docker json-file Logs, Loki | named volume `promtail_positions` | rebuildbar | nein | Dokumentierte Host-Observability-Ausnahme: `/var/run/docker.sock:/var/run/docker.sock:ro` und `/var/lib/docker/containers:ro`; keine Appdaten, nur Log-Discovery |
 | `monitoring-node-exporter` | Host-Metriken fuer Prometheus | `monitoring/docker-compose.yml` | intern `:9100` | Host `/proc`, `/sys`, `/` read-only, Prometheus | kein kritischer Zustand | rebuildbar | nein | Host-Observability-Ausnahme mit read-only Rootfs/Proc/Sys-Mounts |
 | `monitoring-cadvisor` | Container-Metriken fuer Prometheus | `monitoring/docker-compose.yml` | intern `:8080` | Docker/Host read-only Mounts, Prometheus | kein kritischer Zustand | rebuildbar | nein | Host-Observability-Ausnahme fuer Container-Metriken; keine direkten Ports |
-| `monitoring-influxdb3-core` | InfluxDB 3 Core fuer Home-Assistant-/Ecowitt-Langzeitdaten | `monitoring/docker-compose.yml` | LAN `8181` je `INFLUXDB_BIND_IP`, keine Public URL | Monitoring-Grafana, Home Assistant Writer | `/mnt/user/appdata/influxdb3/data`, `/mnt/user/appdata/influxdb3/plugins` | Tier 3 | nein | LAN-only Host-Port-Ausnahme; `user: "0"` ist fuer den lokalen Object-Store-Pfad dokumentiert; uebernimmt den bisherigen InfluxDB-Daten-/Token-Katalog; `401 Unauthorized` beim Curl ohne Token ist erwarteter Reachability-Test |
+| `monitoring-influxdb3-core` | InfluxDB 3 Core fuer Home-Assistant-/Ecowitt-Langzeitdaten | `monitoring/docker-compose.yml` | Host-Port `8181` je `INFLUXDB_BIND_IP`, keine Public URL | Monitoring-Grafana, Home Assistant Writer | `/mnt/user/appdata/influxdb3/data`, `/mnt/user/appdata/influxdb3/plugins` | Tier 3 | nein | 2026-05-31 effektiv auf `127.0.0.1:8181` gebunden, also nicht LAN-exponiert; `user: "0"` ist fuer den lokalen Object-Store-Pfad dokumentiert; uebernimmt den bisherigen InfluxDB-Daten-/Token-Katalog; `401 Unauthorized` beim Curl ohne Token ist erwarteter Reachability-Test |
 | `hermes-gateway` | Hermes Agent Gateway/API intern | `ops/hermes-agent/docker-compose.yml` | intern `8642` auf `hermes_net` | SSH Runner (VM 192.168.178.143), LLM Provider, optional Home Assistant | `/mnt/user/appdata/hermes-agent/data`, SSH key path | Tier 3, Borg/Share | nein | NAS-Stack bleibt deaktiviert, solange die separate Hermes-VM/Runner-Seite nicht wiederhergestellt ist; kein Docker-Socket |
 | `hermes-dashboard` | Hermes Dashboard | `ops/hermes-agent/docker-compose.yml` | `https://hermes.kaleschke.info` via `${HERMES_DASHBOARD_HOST}` | `hermes-gateway`, Traefik + Authelia | shared read-only data mount | Tier 3, Borg/Share | ja + Authelia | Compose-Profil `dashboard`; aktuell VM-seitig offen, nicht Teil des NAS-Finalstarts |
+| `n8n` | Workflow-Automation; aktuell genutzt fuer Mail->LLM->Gitea-Issue (Inbox `Micha/mails`) | `apps/n8n/docker-compose.yml`, `apps/n8n/workflows/*.json` | `https://n8n.kaleschke.info` | Traefik (ohne pauschale Authelia, analog Komodo/Nextcloud), GMX IMAP, OpenAI API, Gitea API | `/mnt/user/appdata/n8n/data` (SQLite, Credentials, Workflows) | Tier 2, Borg + `n8n-data` (Credentials sind nur mit `N8N_ENCRYPTION_KEY` entschluesselbar) | ja, native Auth | Wegen Webhook-Endpunkten (`/webhook/*`) bewusst ohne `authelia@file`; eigene Login-/Owner-Auth bleibt Pflicht; `N8N_ENCRYPTION_KEY` ist Stack-ENV-Pflichtsecret, Verlust macht Credentials unbrauchbar. |
 
 ## Host Operations
 
 | Service | Zweck | Autoritativer Pfad | URL / Zugang | Abhaengigkeiten | Datenpfade | Backup / Restore | Traefik | Besonderheiten / TODOs |
 |---|---|---|---|---|---|---|---|---|
 | `posture-check` | Host-Posture-Audit fuer Filesystem, Mover-Drift, NVMe-SMART, Fuellstand und Authelia-Repo<->Host-Drift | `services/posture-check/posture-check.sh` | Unraid User-Script / Cron / Borg Pre-Hook | `findmnt`, `df`, `nvme`, optional `curl` fuer ntfy; ruft `services/authelia-diff.sh` fuer `authelia_config_drift` auf | `/mnt/user/services/posture-check/last.json` | Repo-Skript + letzter JSON-Status | nein | Muss auf dem Unraid-Host bei Boot, stuendlich und vor Borg laufen; Disk1-NTFS ist nach Disk1 Phase 2 nicht mehr erlaubt (`ALLOW_DISK1_NTFS=0` Standard); Warning/Critical alarmieren via ntfy nur bei neuer Ursache oder nach `ALERT_REPEAT_SECONDS`. Authelia-Drift-Check braucht einen Repo-Spiegel unter `/mnt/user/services/homelab-infra/` (siehe `docs/WORKFLOW.md` Sektion "Ausnahme: Authelia configuration.yml") |
-| `docker-critical-events` | Live-Alarmierung fuer Docker `die`/`oom`/`kill` Events | `services/posture-check/docker-critical-events.sh` | Unraid User-Script / Hintergrundprozess | Docker CLI, ntfy | `/mnt/user/services/posture-check/docker-critical-events-last.log` | Repo-Skript + letzter Event-Log | nein | Optional als Unraid User-Script `at array start` starten; sendet nach `homelab-alerts` |
+| `docker-critical-events` | Live-Alarmierung fuer Docker `die`/`oom`/`kill` Events | `services/posture-check/docker-critical-events.sh`, Supervisor `services/posture-check/docker-critical-events-supervisor.sh` | Unraid User-Script / Hintergrundprozess | Docker CLI, ntfy | `/mnt/user/services/posture-check/docker-critical-events-last.log`, PID/Outfile unter `/mnt/user/services/posture-check/` | Repo-Skript + letzter Event-Log | nein | Optional als Unraid User-Script `at array start` starten; Supervisor kann `start`, `stop`, `status`, `smoke`; sendet nach `homelab-alerts` |
 
 ## Backup- und Restore-Hinweise
 

docs/STORAGE_LAYOUT.md

@@ -380,38 +380,8 @@ Wenn Hermes-Worker auf weiteren Hosts skaliert: dieser Storage-Layout-Plan gilt
 - `docs/AI_CONTEXT.md` — Kontext für AI-Assistenten
 - `docs/HARDWARE_INVENTORY.md` — physische Host-, Disk- und Health-Baseline
 
-## 18. Changelog
+## 18. Status
 
-| Version | Datum | Änderung | Autor |
+Status: **Active v1.4 seit 2026-05-27**.
-|---------|-------|----------|-------|
-| 1.0 (Draft) | 2026-05-15 | Initialfassung nach Incident 2026-05-11. Ursprung: NTFS-Cache-Korruption, fehlende Posture-Checks, ungeplante Backup-Strategie. | Operator + AI-Assistenten |
-| 1.1 (Draft) | 2026-05-15 | Operator-Review-Feedback eingearbeitet: `system`/`domains` auf `only`, `services` als recovery-kritisch markiert, `data/`-Behandlung pro Stack klassifiziert (statt blanket Exclude), Backup-Tooling Ist/Soll explizit getrennt, Posture-Check zusätzlich bei Boot/vor Backup/nach Mover, Hard Rules 11+12 ergänzt (Restore-Pfad-Pflicht, Posture-vor-Backup), Alarmziel-Optionen benannt, Review-Items in eigene Sektion §20 verschoben. | Operator + AI-Assistenten |
-| 1.2 (Draft) | 2026-05-15 | Operator-Entscheidungen #3, #4, #6, #9, #11 eingearbeitet: Backrest abgeschaltet (Borg alleinige Backup-Technologie), persönliche Daten vollständig im Pflicht-Backup-Scope, ntfy als Alarmziel verbindlich, kebab-case-Migration im Rahmen der Recovery-Phase, Mirror-Backup für Gitea-Repo-Inhalte als verbindliche Spec (Implementierung in `SERVICES_RECOVERY.md` zu detaillieren). Offen: Items #1, #2, #5, #7, #8, #10. | Operator + AI-Assistenten |
-| 1.3 (Draft) | 2026-05-15 | Operator-Entscheidungen #1, #7, #8 eingearbeitet: Disk-Größen/-Modelle als Deferred via Posture-Check-Detection (kein Blocker), optionale Stacks (Filebrowser, code-server, Speedtest, Scrutiny, Uptime-Kuma) bleiben im Layout und sind produktiv, Network-Verweis auf MASTER_V2 bestätigt. Damit alle akuten Items entschieden. Verbleibend: Items #2, #5, #10 (Retention, Schwellen-Kalibrierung, RESTORE_MATRIX-Klassifikation) — alle als Folge-Aufgaben über Inkraftsetzung hinaus, kein Commit-Blocker. | Operator + AI-Assistenten |
-| 1.4 (Active) | 2026-05-27 | Datei von `docs/STORAGE_LAYOUT.draft.md` auf `docs/STORAGE_LAYOUT.md` gehoben; Hardware-/Diskwerte aus `docs/HARDWARE_INVENTORY.md` übernommen; Gitea-Bundle-Mirror und H:/ Nearline-Pull als umgesetzte Folgepfade referenziert. Verbleibend: Retention-Kalibrierung, Monitoring-Schwellen und RESTORE_MATRIX-Detailklassifikation als normale Folgeaufgaben. | Operator + AI-Assistenten |
 
-## 19. Inkraftsetzung
+Detailhistorie und alte Review-Tabellen liegen in der Git-Historie. Aktuelle Folgepunkte stehen nicht mehr hier, sondern in `docs/AUDIT_2026-05-25_TODO.md`.
-
-Dieses Dokument tritt in Kraft mit dem Commit der finalen Fassung in `master`-Branch des Repos `homelab-infra`. Ab Inkraftsetzung gelten alle Hard Rules; Soft Rules werden im Rahmen der laufenden Recovery-Arbeit etabliert; Posture-Check muss innerhalb von 14 Tagen nach Inkraftsetzung produktiv laufen.
-
-Erste Audit-Review dieses Dokuments: spätestens 90 Tage nach Inkraftsetzung. Danach jährlich oder bei jeder strukturellen Änderung des Storage-Layouts.
-
-## 20. Review Items und Folgeaufgaben
-
-Diese Sektion dokumentiert erledigte Review-Punkte und verbleibende Folgeaufgaben nach Aktivierung des Dokuments.
-
-| Nr. | Item | Status | Verantwortung |
-|-----|------|--------|---------------|
-| 1 | Disk-Größen und Modelle in §3 (Disk1, Parity, externe Backup-Platte) | **ERLEDIGT 2026-05-27** — Werte aus `docs/HARDWARE_INVENTORY.md` übernommen; Disk1-Filesystem ist seit 2026-05-25 XFS | Operator + Posture-Check |
-| 2 | Retention-Werte in §8.1 (Borg-Repos lokal/remote) — abhängig von tatsächlicher Storage-Kapazität | Vorschlag steht, anzupassen | Operator |
-| 3 | Backup-Tooling: Backrest abschalten, Borg alleinige Backup-Technologie | **ENTSCHIEDEN 2026-05-15** | erledigt (siehe §8.0) |
-| 4 | Backup-Scope für persönliche Daten: `documents`, `photos`, `finance`, `projekte` (und `media` falls behalten) **vollständig** im Pflicht-Scope | **ENTSCHIEDEN 2026-05-15** | erledigt (siehe §8.2) |
-| 5 | Posture-Check-Schwellen in §11 — Vorschlag konservativ, nach erstem Monitoring kalibrieren | Vorschlag steht | Operator nach 30 Tagen |
-| 6 | Alarmziel: ntfy als primärer Push-Kanal, Mail-Fallback als Folge-Erweiterung optional | **ENTSCHIEDEN 2026-05-15** | erledigt (siehe §11) |
-| 7 | Optionale Stacks (Filebrowser, code-server, Speedtest, Scrutiny, Uptime-Kuma) — bleiben im Layout, sind produktiv im Scope, folgen den Standard-Konventionen aus §5 und Backup-Pflichten aus §8.2 | **ENTSCHIEDEN 2026-05-15** | erledigt |
-| 8 | Verweis auf `HOMELAB_ARCHITECTURE_MASTER_V2.md` für Network-Architektur (§10) — Net-Architektur steht dort authoritativ, Verweis ist ausreichend | **ENTSCHIEDEN 2026-05-15** | erledigt (siehe §10) |
-| 9 | Naming-Konvention: kebab-case durchziehen, Migration im Rahmen der Recovery-Phase | **ENTSCHIEDEN 2026-05-15** | erledigt (siehe §6); pro Stack in RESTORE_MATRIX.md zu dokumentieren |
-| 10 | Pro-Stack-Klassifizierung in `RESTORE_MATRIX.md` (DB-Typ, Nutzdaten in `data/`, Dump-Verfahren, letzter Restore-Test, kebab-case-Migrationsname) — als Folge-Aufgabe aus Hard Rule §12.11 | Folge-Aufgabe | Operator + Recovery-Phase |
-| 11 | Mirror-Backup für `services/gitea/git/repositories/` auf zweites Medium, ≤ 6 h Frequenz, konkrete Implementierung in `docs/SERVICES_RECOVERY.md` zu erstellen | **ERLEDIGT 2026-05-26** — `ops/borg-ui/scripts/gitea-bundle-mirror.sh` erzeugt verifizierte Bundles; Host-Erstlauf mit 4 Bundles und `git fsck` erfolgreich | Operator + Folge-Doc |
-
-Das Dokument ist mit Version 1.4 als Active geführt. Offene Punkte 2, 5 und 10 bleiben normale Folgeaufgaben und blockieren die Gültigkeit der Hard Rules nicht.

docs/WEEKEND_EXECUTION_PLAN_2026-06-05.md

@@ -0,0 +1,151 @@
+# Weekend Execution Plan - 2026-06-05 bis 2026-06-07
+
+Ziel: Bis Ende des Wochenendes alle offenen To-dos aus `docs/MASTER_TODO.md`
+entweder erledigen, verifiziert schliessen, oder bewusst als geparkt/extern
+blockiert markieren. Nicht jeder Punkt ist realistisch "fertig" im Sinne von
+technisch umgesetzt: Family-Onboarding, zweite Hardware, USV und WAN-Failover
+brauchen Operator- oder Hardware-Entscheidungen.
+
+## Arbeitsregeln
+
+- Secrets niemals in Chat, Logs oder Repo schreiben.
+- Homelab-Aenderungen nur via GitOps, keine direkten Komodo-/Docker-Hotfixes.
+- Destruktive Windows- oder Host-Schritte nur nach expliziter Freigabe.
+- Ergebnis jedes abgeschlossenen Punkts in der Detaildoku und in
+  `docs/MASTER_TODO.md` nachziehen.
+- Am Ende: ein sauberer Commit-Block; Push erst nach Freigabe.
+
+## Owner-Aufteilung
+
+| Owner | Fokus | Ergebnis |
+|---|---|---|
+| Codex | `baerchen` Veeam, Doku-Konsolidierung, lokale Checks, Commit-Vorbereitung | Veeam-Erstbackup geprueft, Recovery-Test dokumentiert, Masterliste aktualisiert |
+| Claude | Family-Onboarding-Paket, Network-/Tailscale-Entscheidungen, Hardware-/Todo-Konsolidierung, nicht-destruktive Runbooks | Konkrete Doku-Patches, ausfuehrbare Checklisten, klare Operator-Fragen statt diffuser TBDs |
+| Operator | Physische/GUI-Schritte, Secrets, Familie, Hardwareentscheidungen | Recovery-USB booten, Passwoerter/Keys bereitstellen, Family-Onboarding starten/entscheiden |
+
+## Codex-Aufgaben
+
+| Prioritaet | Aufgabe | Abschlusskriterium |
+|---|---|---|
+| P1 | Veeam-Erstbackup `baerchen-c-image` pruefen | **erledigt 2026-06-05:** Full-Lauf geschrieben, Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen; Storage Encryption war nicht aktiv und ist als Operator-Entscheidung dokumentiert |
+| P1 | Recovery-USB-Test begleiten | `VEEAMRE` bootet, SMB-Ziel sichtbar, Restore Point sichtbar, vor Restore abgebrochen |
+| P1 | `windows-image-backup-baseline.md` finalisieren | Erster Lauf und Teststatus mit Datum eingetragen |
+| P1 | `docs/MASTER_TODO.md` nach jedem Abschluss aktualisieren | erledigte Punkte entfernt oder in "geschlossen" vermerkt |
+| P2 | Alte Windows-Reinstall-Doku bereinigen | ueberholte WinRE-/Admin-To-dos als erledigt/ueberholt markiert |
+| P2 | Git-Status sortieren | Eigene Aenderungen klar von vorhandenen User-Aenderungen getrennt |
+| P2 | Commit vorbereiten | Commit-Message-Vorschlag und Datei-Liste bereit; kein Push ohne Freigabe |
+
+## Claude-Aufgaben
+
+Claude soll parallel nur repo-seitig arbeiten und keine produktiven Host-Aenderungen
+ausfuehren. Die Aufgaben sind bewusst als echte Doku-/Planungsarbeit formuliert,
+nicht nur als Pruefaufgaben:
+
+| Prioritaet | Aufgabe | Abschlusskriterium |
+|---|---|---|
+| P1 | `docs/MASTER_TODO.md` gegen Detaildokus gegenpruefen | **erledigt 2026-06-05:** Sync-Notiz in `docs/AUDIT_2026-05-25_TODO.md`, Masterliste aktualisiert |
+| P1 | Restore-Backlog aktualisieren | **erledigt 2026-06-05:** erledigte Kandidaten aus `docs/RESTORE_MATRIX.md` bereinigt |
+| P1 | Family-Onboarding in ein ausfuehrbares Session-Paket umwandeln | **erledigt 2026-06-05:** `docs/FAMILY_ONBOARDING.md` enthaelt Vorbereitungs-, Termin- und Erfolgskriterien ohne Secret-Werte |
+| P1 | `docs/NETWORK_INVENTORY.md` TBDs in Entscheidungen oder konkrete Operator-Fragen verwandeln | **erledigt 2026-06-05:** Tailscale IPv6/Exit Node/Subnet Router/ACL-Policy sind als Messaufgabe/Operator-Entscheidung formuliert; Gast-/WAN-Pfade sind geparkt oder mit Vorbedingungen versehen |
+| P2 | Nicht-destruktive Runbooks fuer offene Restore-Tests vorbereiten | **erledigt 2026-06-05:** Runbook-Stubs fuer Unraid Flash, AdGuard, Tailscale, Redis 8 in `docs/RESTORE_MATRIX.md` |
+| P2 | `docs/AUDIT_2026-05-25_TODO.md` und `MASTER_TODO.md` synchronisieren | **erledigt 2026-06-05:** keine doppelten oder widerspruechlichen P1/P2-Punkte |
+| P2 | Windows-Reinstall-Altdoku auf ueberholte To-dos pruefen | **erledigt 2026-06-05:** WinRE/Admin-Check-Altlasten als erledigt/ueberholt markiert |
+| P2 | Hardware-/Betriebsentscheidungen konsolidieren | **teilweise erledigt 2026-06-05:** USV und Cold-Backup-Rotation sind entschieden/geparkt; Masterliste fuehrt sie nicht mehr als aktive Umsetzungsaufgaben |
+| P3 | Geparkte Punkte klassifizieren | Family/USV/WAN/CrowdSec/OIDC klar als Entscheidung statt Umsetzungsarbeit markiert |
+
+## Operator-Aufgaben
+
+| Prioritaet | Aufgabe | Abschlusskriterium |
+|---|---|---|
+| P1 | Veeam-Encryption-Entscheidung treffen | Fuer den ersten Full-Lauf ist kein Veeam-Encryption-Passwort noetig; falls Storage Encryption aktiviert wird, Passwort in Vaultwarden anlegen und neues Full erzeugen |
+| P1 | Recovery-USB physisch booten | Boot ins Veeam-Recovery-System gelingt |
+| P1 | Keine echten Restore-Ziele bestaetigen | Restore-Test wird vor destruktiver Datentraegerauswahl abgebrochen |
+| P2 | BitLocker-Entscheidung treffen | `aktivieren`, `spaeter`, oder `bewusst aus` dokumentiert |
+| P2 | Family-Onboarding real starten oder terminieren | konkreter Termin/Personenkreis statt offenem Wunsch |
+| P3 | Hardware-Entscheidungen | USV/Cold-Rotation/WAN-Failover als kaufen, spaeter, oder bewusst nein markieren |
+
+## Realistische Wochenend-Ziele
+
+Bis Sonntagabend realistisch fertig:
+
+- `baerchen` Veeam-Erstbackup verifiziert.
+- `baerchen` Recovery-USB-Test ohne Restore verifiziert.
+- Veeam-/BitLocker-Doku bereinigt.
+- Master-To-do-Liste bereinigt.
+- Restore-Backlog sortiert.
+- Alte/ueberholte To-dos als erledigt/ueberholt markiert.
+- Blockierte Punkte explizit als Betreiber-/Hardware-/Familienentscheidung markiert.
+
+Nicht realistisch ohne externe Voraussetzungen:
+
+- End-to-end-DR-Drill ohne zweite Hardware.
+- Family-Onboarding ohne Familie/Geraete.
+- USV erledigen ohne Kauf.
+- WAN-Failover erledigen ohne Mobilfunk-/Router-Entscheidung.
+- Dedizierter SMB-User ohne bewusste Unraid-User-/Share-Aenderung.
+
+## Prompt fuer Claude
+
+```text
+Du bist Claude im KalliLab CORE Homelab-Repo.
+
+Arbeitsziel fuer dieses Wochenende:
+Hilf, alle offenen To-dos aus `docs/MASTER_TODO.md` bis Sonntagabend entweder
+zu erledigen, sauber zu dokumentieren, oder bewusst als geparkt/blockiert zu
+klassifizieren. Arbeite repo-seitig, keine produktiven Host-Aenderungen.
+
+Pflichtregeln:
+- Lies zuerst `CLAUDE.md`.
+- Lies danach `HOMELAB_ARCHITECTURE_MASTER_V2.md`, `docs/WORKFLOW.md`,
+  `docs/README.md`, `docs/REPO_MAP.md`, `docs/MASTER_TODO.md`,
+  `docs/RESTORE_MATRIX.md`, `docs/DISASTER_RECOVERY.md`,
+  `docs/SECRETS_MAP.md` und `ops/windows-reinstall/docs/windows-image-backup-baseline.md`.
+- Keine Secrets ins Repo. Nur Secret-Namen, Pfade und Ablageorte dokumentieren.
+- Keine Komodo-/Docker-/Host-Hotfixes. Keine produktiven Schreibbefehle auf dem Homelab.
+- Keine destruktiven Aktionen.
+- Beachte vorhandene uncommitted Aenderungen; nichts revertieren, was du nicht selbst gemacht hast.
+
+Konkrete Aufgaben:
+1. Wandle `docs/FAMILY_ONBOARDING.md` von einer guten Erklaerseite in ein
+   ausfuehrbares Session-Paket um:
+   - 30-Minuten-Ablauf fuer das erste echte Onboarding
+   - Checkliste pro Geraet/Person ohne Namen oder Secret-Werte
+   - klare Abschlusskriterien fuer Vaultwarden, Immich und Mealie
+   - Liste der Operator-Fragen, falls Konten/Startpasswoerter fehlen
+2. Bereinige `docs/NETWORK_INVENTORY.md`:
+   - Tailscale IPv6, Exit Node, Subnet Router und ACL-Policy nicht als
+     unerklaerte `TBD` stehen lassen
+   - wenn nicht verifizierbar: als konkrete Operator-Frage oder bewusst offene
+     Entscheidung formulieren
+   - Gast-/IoT-Zugriff als Entscheidungspfad dokumentieren, nicht als vage
+     Altlast
+3. Ziehe `docs/MASTER_TODO.md` nach deinen Edits nach:
+   - echte naechste Schritte in P1/P2
+   - geparkte Entscheidungen nur im geparkten/geschlossenen Bereich
+   - keine Duplikate zu `docs/AUDIT_2026-05-25_TODO.md`
+4. Falls du weitere diffuse TBDs in Hardware/Network/Family findest: nicht nur
+   melden, sondern in konkrete Entscheidung, geparkten Punkt oder naechsten
+   Operator-Schritt umformulieren.
+5. Schon erledigte Restore-/Windows-Doku-Aufgaben nicht erneut bearbeiten,
+   ausser du findest einen klaren Widerspruch.
+6. Am Ende liefere:
+   - geaenderte Dateien
+   - welche Punkte geschlossen wurden
+   - welche Punkte blockiert/geparkt bleiben und warum
+   - welche Operator-Schritte noch noetig sind
+
+Nicht tun:
+- Keine Secrets anzeigen oder erfinden.
+- Kein Push.
+- Kein `docker`, `ssh` oder Host-Schreibzugriff.
+- Kein BitLocker, keine Veeam-Aenderung, keine Unraid-User-/Share-Aenderung.
+```
+
+## Abschlusskriterien fuer Sonntag
+
+- `docs/MASTER_TODO.md` ist die fuehrende Liste.
+- Alle erledigten Punkte haben Beleg in der Detaildoku.
+- Alle nicht erledigbaren Punkte sind als blockiert/geparkt mit Grund markiert.
+- `git status` ist verstanden: eigene Doku-Aenderungen vs. bestehende
+  User-Aenderungen sind getrennt.
+- Commit ist vorbereitet, Push erfolgt nur nach Operator-Freigabe.

docs/WEEKEND_STATUS_2026-06-05.md

@@ -0,0 +1,41 @@
+# Weekend Status - 2026-06-05
+
+Kurzlebiges Arbeitsboard fuer den Wochenend-Sprint. Fuehrende Liste bleibt
+`docs/MASTER_TODO.md`; dieses Board haelt nur den aktuellen Arbeitsstand fest.
+
+## Jetzt laufend
+
+| Owner | Aufgabe | Status | Naechster Schritt |
+|---|---|---|---|
+| Codex | Veeam-Erstbackup `baerchen-c-image` | erledigt | Erster Full-Lauf 2026-06-05 geschrieben; Recovery-Test bleibt offen |
+| Codex | Veeam-Verifikationshilfe | erledigt | Hilfsskript bleibt fuer spaetere Checks verfuegbar |
+| Claude | Restore-/Altdoku-Bereinigung | erledigt | Keine weitere Arbeit an Veeam/Windows/Restore-Matrix ohne neuen Widerspruch |
+| Claude | Family-/Network-Ausfuehrungspaket | erledigt | Masterliste und Weekend-Plan sind nachgezogen |
+
+## Naechste Operator-Schritte
+
+| Zeitpunkt | Aufgabe | Ergebnis, das dokumentiert wird |
+|---|---|---|
+| Erledigt | Veeam-Erstbackup `baerchen-c-image` pruefen | 2026-06-05 19:46, Full-Lauf erfolgreich, Veeam-GUI 53,8 GB, Dauer 0:11:31 |
+| Als naechstes | Recovery-USB `VEEAMRE` booten | Boot OK, Netzwerk OK, SMB-Ziel sichtbar |
+| Im Recovery-Test | Restore Point anzeigen; falls spaeter verschluesselt: Passwort testen | Restore Point sichtbar; vor echtem Restore abgebrochen |
+| Spaeter | BitLocker-Entscheidung treffen | `aktivieren`, `spaeter`, oder `bewusst aus` in `docs/MASTER_TODO.md`/Baseline nachziehen |
+
+## Heute bereits geschlossen
+
+| Thema | Ergebnis |
+|---|---|
+| WinRE/Admin-Altlasten | In Windows-Reinstall-Doku als erledigt/ueberholt markiert |
+| Restore-Test-Kandidaten | Erledigte Kandidaten aus der aktiven Liste entfernt; Stubs fuer offene Kandidaten ergaenzt |
+| Family-Onboarding | Aus der Familien-Doku wurde ein konkreter 30-45-Minuten-Terminablauf mit Vorbereitung und Erfolgskriterien |
+| Network-TBDs | Tailscale-/Gastnetz-/WAN-Failover-Punkte wurden in Messaufgaben, Vorbedingungen oder geparkte Entscheidungen umgewandelt |
+| Veeam-Erstbackup | Full-Lauf 2026-06-05 erfolgreich geschrieben: Veeam-GUI 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen, VSS success; Veeam Storage Encryption war nicht aktiv |
+| Cold-Backup-Rotation | Bewusst Hetzner-only; kein aktives Todo mehr |
+| USV | Bewusst auf Q3/2026 geparkt; Power-Loss bleibt akzeptiertes Risiko |
+
+## Nicht ohne neue Freigabe anfassen
+
+- Keine BitLocker-Aktivierung.
+- Keine Aenderung am Veeam-Job oder Encryption-Status.
+- Keine Unraid-User-/Share-Aenderung.
+- Keine produktiven Host- oder Docker-Schreibbefehle.

docs/WORKFLOW.md

@@ -361,7 +361,7 @@ Pflicht-Schritte vor dem Schliessen:
 6. Authelia ACL-Eintrag in `security/authelia/configuration.yml` und auf dem Host bereinigen.
 7. Monitoring: Blackbox-Target in `monitoring/blackbox/blackbox.yml` entfernen, Cert-Check-Liste pruefen.
 8. **Borg-UI Source-Liste**: `https://borg.kaleschke.info` -> Repository `appdata-critical` -> Source Directories -> alle `/local/appdata/<name>` und ggf. `/local/<name>`-Eintraege loeschen. Sonst kommen daily `HomelabBorgLastJobCompletedWithWarnings`-Push-Nachrichten mit `BackupFileNotFoundError` im Logfile.
-9. `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md`, `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 7.8 (Entfernt), `docs/MIGRATION_LOG.md` nachziehen.
+9. `docs/SERVICE_CATALOG.md`, `docs/REPO_MAP.md` und `HOMELAB_ARCHITECTURE_MASTER_V2.md` Sektion 7.8 (Entfernt) nachziehen.
 
 Wenn ein Stack `webhook_enabled` in Komodo hatte, zusaetzlich pruefen, ob der zugehoerige Gitea-Hook deaktiviert oder geloescht wurde.
 
@@ -371,7 +371,6 @@ Wenn ein Stack `webhook_enabled` in Komodo hatte, zusaetzlich pruefen, ob der zu
 
 Nach jeder erfolgreichen Migration oder relevanten Aenderung muessen diese Dateien geprueft werden:
 
-- `docs/MIGRATION_LOG.md`
 - `docs/SECRETS_MAP.md`
 - `docs/ROLLBACK.md`
 - `docs/SERVICES_RECOVERY.md` falls `/mnt/user/services`, Gitea, Komodo oder Host-Automation betroffen sind
@@ -403,7 +402,7 @@ Wenn mit einer KI gearbeitet wird, gilt immer:
 > 1. `HOMELAB_ARCHITECTURE_MASTER_V2.md`
 > 2. `docs/WORKFLOW.md`
 > 3. die betroffene Compose-Datei
-> 4. ggf. `docs/MIGRATION_LOG.md`
+> 4. die relevante Betriebsdoku aus `docs/README.md`
 
 Erst danach duerfen Aenderungen vorgeschlagen werden.
 

docs/audit/dr-workstation-readiness-2026-06-06.md

@@ -0,0 +1,137 @@
+# DR-Workstation Readiness - 2026-06-06
+
+Automatisch erzeugter lokaler Readiness-Check fuer den Operator-PC. Es wurden keine Secret-Werte, Passphrases oder Private-Key-Inhalte ausgegeben.
+
+## Zusammenfassung
+
+| Check | Ergebnis |
+|---|---|
+| WSL2 Ubuntu | vorhanden (`Ubuntu 24.04`, WSL Version 2) |
+| SSH/Git in WSL | vorhanden |
+| GitHub-Read-Smoke mit DR-Key | ok |
+| Borg Client | installiert |
+| Hetzner Storage Box mit DR-Key | ok |
+| `~/dr-smoke.sh` | vorhanden |
+| Finaler Borg-Smoke | ok, Operator-Bestaetigung 2026-06-06 10:05:30 |
+| WSL sudo ohne Passwortprompt | nein, Operator muss Passwort eingeben |
+
+## Bewertung
+
+- Der lokale WSL2-/Ubuntu-Unterbau ist vorhanden.
+- Die DR-Key-Arbeitskopien liegen in WSL unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`.
+- GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich.
+- `borgbackup` ist installiert.
+- Der vollstaendige Bare-Metal-DR-Smoke ist erfolgreich abgeschlossen.
+
+## Finaler Borg-Smoke
+
+Operator-Bestaetigung vom 2026-06-06:
+
+- Befehl: `bash ~/dr-smoke.sh`
+- GitHub Deploy-Key: HEAD `3a263a4...`
+- Hetzner SSH-Login: Repos `backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical` sichtbar
+- Borg-Repo: `ssh://u565255@u565255.your-storagebox.de/./hetzner_borg_appdata_critical`
+- Repository ID: `5dd9b949...`
+- Encryption: `Yes (repokey)`
+- Borg-Statistik: `Original size 1.16 TB`, `Compressed size 1.13 TB`, `Deduplicated size 35.92 GB`
+- Ergebnis: `DR-Smoke OK (2026-06-06 10:05:30)`
+
+Die Borg-Passphrase wurde nur interaktiv eingegeben und nicht dauerhaft auf `baerchen` gespeichert.
+
+## Rohchecks
+
+### wsl_status
+
+- ExitCode: `0`
+
+```text
+Standarddistribution: Ubuntu
+
+Standardversion: 2
+
+
+```
+
+### wsl_list
+
+- ExitCode: `0`
+
+```text
+  NAME              STATE           VERSION
+
+* Ubuntu            Stopped         2
+
+  docker-desktop    Stopped         2
+
+
+```
+
+### ubuntu_os
+
+- ExitCode: `0`
+
+```text
+Distributor ID:	Ubuntu
+Description:	Ubuntu 24.04.4 LTS
+Release:	24.04
+Codename:	noble
+6.6.114.1-microsoft-standard-WSL2
+```
+
+### tools
+
+- ExitCode: `0`
+
+```text
+/usr/bin/borg
+borg 1.2.8
+/usr/bin/ssh
+OpenSSH_9.6p1 Ubuntu-3ubuntu13.16, OpenSSL 3.0.13 30 Jan 2024
+/usr/bin/git
+git version 2.43.0
+```
+
+### sudo
+
+- ExitCode: `0`
+
+```text
+sudo-password-needed
+```
+
+### wsl_ssh_files
+
+- ExitCode: `0`
+
+```text
+total 40
+drwx------ 2 michi michi 4096 Jun  6 09:14 .
+drwxr-x--- 5 michi michi 4096 Jun  6 08:37 ..
+-rw------- 1 michi michi  411 Jun  6 09:14 dr-hetzner
+-rw------- 1 michi michi  419 Jun  6 09:14 dr-readonly
+-rw------- 1 michi michi  411 Apr  4 19:29 id_ed25519
+-rw-r--r-- 1 michi michi   97 Apr  4 19:29 id_ed25519.pub
+-rw------- 1 michi michi 6358 Jun  6 09:14 known_hosts
+-rw------- 1 michi michi 3013 Apr 20 20:13 known_hosts.old
+-rw------- 1 michi michi 3858 Apr 24 08:27 known_hosts.pre-port222-20260604-122031.bak
+-rwxr-xr-x 1 michi michi 1311 Jun  6 08:37 /home/michi/dr-smoke.sh
+```
+
+### github_dr_key_smoke
+
+- ExitCode: `0`
+
+```text
+68d3ace598ee4d1cdad3ed94b63ae5046ac187fb	HEAD
+```
+
+### hetzner_dr_key_smoke
+
+- ExitCode: `0`
+
+```text
+backup
+backup2
+hetzner_borg_appdata
+hetzner_borg_appdata_critical
+```

docs/audit/system-audit-2026-06-05.md

@@ -0,0 +1,303 @@
+# System-Audit 2026-06-05
+
+**Scope:** Windows-Host `baerchen` (frisch aufgesetzt), Read-only  
+**Referenz-Doku:** `ops/windows-reinstall/docs/laufwerks-neustruktur-2026-06-04.md`, `boot-cleanup-plan-2026-06-04.md`  
+**Durchgeführt:** 2026-06-05, ohne Admin-Rechte  
+**Rohdaten:** `audit/raw/01_volumes_partitions.txt` bis `06_events_hardware.txt`
+
+---
+
+## 1. Ordner- und Laufwerksstruktur (Priorität)
+
+### 1.1 Soll-Ist-Vergleich: Ordner-Existenz
+
+| Pfad | Soll | Ist | Status |
+|---|---|---|---|
+| `D:\00_Inbox` | ✓ | vorhanden | OK |
+| `D:\10_Dokumente` | ✓ | vorhanden | OK |
+| `D:\11_Bilder` | ✓ | vorhanden | OK, aber ReadOnly-Attribut gesetzt |
+| `D:\12_Videos` | ✓ | vorhanden | OK |
+| `D:\13_Musik` | ✓ | vorhanden | OK |
+| `D:\14_Downloads` | ✓ | vorhanden | OK |
+| `D:\20_Projekte\aktiv` | ✓ | vorhanden | OK |
+| `D:\20_Projekte\archiv` | ✓ | vorhanden | OK |
+| `D:\30_Finanzen\Banking4` | ✓ | vorhanden | OK |
+| `D:\30_Finanzen\WISO_Steuer` | ✓ | vorhanden | OK |
+| `D:\90_Archiv` | ✓ | vorhanden | OK |
+| `E:\Steam\steamapps` | ✓ | vorhanden | OK |
+| `E:\BattleNet` | ✓ | vorhanden | OK |
+| `E:\EpicGames` | ✓ | vorhanden | OK |
+| `E:\EA` | ✓ | vorhanden | OK |
+| `E:\Riot` | ✓ | vorhanden | OK |
+| `E:\Ubisoft` | ✓ | vorhanden | OK |
+| **`E:\_Standalone`** | **✓** | **FEHLT** | **LÜCKE** |
+| `G:\repos` | ✓ | vorhanden | OK |
+| `G:\tools` | ✓ | vorhanden als `Tools` (Großbuchstabe) | OK (NTFS case-insensitive) |
+
+**Nicht in Soll-Doku, aber vorhanden:**
+
+| Pfad | Beurteilung |
+|---|---|
+| `D:\Micha\Videos` | Altquelle, fast leer (1 Datei), Rest wurde bereinigt |
+| `D:\WSL` | WSL-Datenpfad, nicht in Doku erwähnt, aber logisch |
+| `G:\Apps` | Zweck unklar, nicht dokumentiert |
+| `G:\Gitea_Clone` | Bewusst so (homelab-infra bleibt laut Doku unangetastet) |
+| `G:\Workspace` | Nicht dokumentiert, wahrscheinlich Dev-Workspace |
+
+### 1.2 Known-Folder-Redirects
+
+| Ordner | Soll (Doku) | Ist (gemessen) | Status |
+|---|---|---|---|
+| Desktop | `D:\Micha\Desktop` | `D:\00_Inbox\Desktop` | **ABWEICHUNG** |
+| Dokumente | `D:\10_Dokumente` | `D:\10_Dokumente` | OK |
+| Downloads | `D:\14_Downloads` | `D:\14_Downloads` | OK |
+| Bilder | `D:\11_Bilder` | `D:\11_Bilder` | OK |
+| Musik | `D:\13_Musik` | `D:\13_Musik` | OK |
+| Videos | `D:\12_Videos` | `D:\12_Videos` | OK |
+
+**Desktop-Befund (Detail):**
+- Soll-Doku schreibt: `D:\Micha\Desktop` (als bewusster Sonderfall ohne nummerierten Ordner).
+- Ist: Desktop zeigt auf `D:\00_Inbox\Desktop` — dieser Ordner existiert, enthält 4 Dateien.
+- `D:\Micha\Desktop` existiert **nicht**.
+- `D:\Micha` enthält nur noch `Videos` (1 Datei, leer).
+- Fazit: Das Known-Folder-Ziel wurde nach der Doku-Erstellung nochmals geändert. Die Doku ist in diesem Punkt veraltet. Der Desktop liegt funktional korrekt auf D:, aber das Ziel weicht vom dokumentierten Soll ab. **Doku-Update empfohlen.**
+
+### 1.3 Doppelbestand D:\Micha\* vs. neue Nummernstruktur
+
+| Alt | Dateien | Neu | Dateien | Bewertung |
+|---|---|---|---|---|
+| `D:\Micha\Dokumente` | NICHT MEHR VORHANDEN | `D:\10_Dokumente` | 4011 / 595 MB | Bereinigt ✓ |
+| `D:\Micha\Bilder` | NICHT MEHR VORHANDEN | `D:\11_Bilder` | 7789 / 12,4 GB | Bereinigt ✓ |
+| `D:\Micha\Videos` | 1 Datei, ~0 MB | `D:\12_Videos` | 1 Datei, ~0 MB | Quasi-leer, kein Doppelbestand |
+| `D:\Micha\Musik` | NICHT MEHR VORHANDEN | `D:\13_Musik` | 0 Dateien | Bereinigt ✓ |
+| `D:\Micha\Downloads` | NICHT MEHR VORHANDEN | `D:\14_Downloads` | 2186 / 2,2 GB | Bereinigt ✓ |
+| `D:\Micha\Finanzen` | NICHT MEHR VORHANDEN | `D:\30_Finanzen` | 126 / 123 MB | Bereinigt ✓ |
+
+**Fazit:** Der befürchtete Doppelbestand ist weitgehend aufgelöst. Nur `D:\Micha\Videos` ist noch vorhanden, ist aber inhaltlich leer. `D:\Micha` kann nach manueller Prüfung von Videos entfernt werden.
+
+### 1.4 Labels
+
+| Laufwerk | Soll | Ist | Status |
+|---|---|---|---|
+| D: | `Daten-Projekte` | `Daten-Projekte` | OK ✓ |
+| E: | `Games` | `Games` | OK ✓ |
+| H: | unveraendert | `Externe HDD` | OK ✓ |
+
+### 1.5 Rollen-Konsistenz und Partitions-Layout
+
+| Laufwerk | Soll-Rolle | Ist | Status |
+|---|---|---|---|
+| C: | Windows + kleine Programme | Disk 0, 167 GB SATA | OK |
+| D: | Daten & Projekte | Disk 1, 168 GB SATA | OK |
+| E: | Games | Disk 2, **930 GB** NVMe (nach F-Merge) | OK ✓ |
+| F: | Altes Windows (löschen) | **Nicht mehr vorhanden** | Abgeschlossen ✓ |
+| G: | Arbeits-SSD, Homelab/Dev | Disk 3, 931 GB NVMe | OK |
+| H: | Externe Backup-HDD | Disk 4, 7.28 TB USB | OK |
+
+E: und das ehemalige F: sind jetzt eine einzige 930 GB Partition auf Disk 2. Layout ist sauber.
+
+### 1.6 Fachliche Gesamtbewertung der Struktur
+
+**Stärken:**
+- Die Nummernstruktur auf D: ist vollständig angelegt und die Known Folders zeigen bis auf Desktop korrekt dorthin.
+- Der Doppelbestand ist fast vollständig bereinigt — das war die größte Risikoquelle.
+- F: ist weg, E: ist auf volle Disk-Kapazität gewachsen — die BCD-Bereinigung und Partition-Erweiterung wurde sauber abgeschlossen.
+- Label-Benennung konsistent.
+- G: ist operational (repos, Tools, Gitea_Clone vorhanden).
+
+**Lücken und Inkonsistenzen:**
+1. **Desktop-Redirect weicht von Doku ab** (Ist: `D:\00_Inbox\Desktop`, Doku: `D:\Micha\Desktop`). Da `D:\Micha\Desktop` nicht existiert und der Desktop funktioniert, ist die Doku das Problem, nicht das System.
+2. **`E:\_Standalone` fehlt** — laut Doku angelegt, tatsächlich nicht vorhanden. Kein funktionaler Schaden, aber Inkonsistenz zur Rollenbeschreibung.
+3. **`D:\11_Bilder` hat ReadOnly-Attribut** auf Ordner-Ebene gesetzt — ungewöhnlich, keine erkennbare Ursache. Kein Showstopper, aber prüfenswert.
+4. **`G:\Apps`, `G:\Workspace`** sind nicht in der Soll-Doku definiert. Kein Problem an sich, aber für spätere Audits hilfreich zu dokumentieren.
+5. **`D:\WSL`** nicht dokumentiert — WSL-Datenpfade dort gehören explizit erwähnt.
+6. **`D:\13_Musik`** ist leer (0 Dateien) — entweder war `D:\Micha\Musik` schon leer, oder die Kopie ist ausgeblieben. Zu prüfen ob Musik aus PostDelta-Backup nachgezogen werden muss.
+
+**Gesamturteil:** Die Struktur ist in sich schlüssig und der Umbau ist zu ~95% abgeschlossen. Die verbleibenden Punkte sind kleine Doku-Lücken und ein fehlender Ordner, kein strukturelles Problem.
+
+---
+
+## 2. OS-Baseline
+
+| Feld | Wert | Bewertung |
+|---|---|---|
+| Edition | Windows 11 Pro | OK |
+| Build | 26200 (Insider/Preview-Build) | Achtung: kein Stable-Channel-Build |
+| Aktivierung | OEM_DM, aktiv | OK |
+| Installiert | 2026-05-10 | ~25 Tage alt |
+| Letzter Boot | 2026-06-05 07:57 | Frisch gebootet |
+| Ausstehende Updates | 0 | OK |
+| Reboot pending | Nein | OK |
+
+**Befund Build 26200:** Das ist ein Windows Insider/Canary-Channel Build, kein Produktions-Release. Für einen Nerd-Einsatz vertretbar, aber mit dem Wissen verbunden, dass Insider-Builds weniger stabil sind und keine LTS-Garantie haben.
+
+---
+
+## 3. Security
+
+### Defender
+- Aktiv, TamperProtection an, Signaturen aktuell. **OK.**
+- Ausschlüsse und ASR-Regeln: nur als Admin lesbar — **kein Befund, aber blind spot.**
+
+### Firewall
+- Alle drei Profile aktiv. DefaultInboundAction `NotConfigured` bedeutet im Windows-Default: eingehend blockieren, ausgehend erlauben. **OK.**
+- Port 27036 (Steam Remote Play) lauscht auf `0.0.0.0` — also LAN-seitig offen. Erwartetes Steam-Verhalten, aber explizit im Bewusstsein halten.
+
+### BitLocker
+- Nicht prüfbar ohne Admin. **Blind spot — Empfehlung: BitLocker für C: und D: aktivieren.**
+
+### Secure Boot / TPM
+- Nicht prüfbar ohne Admin. Hardware MSI MS-7D32 unterstützt beides. Status unbekannt.
+
+### UAC
+- Standard-Konfiguration korrekt (Secure Desktop aktiv). **OK.**
+
+### Lokale Admins
+- `Administrator` (Built-in) + `michi`. Zwei Accounts in Admins ist normal für einen Einzel-PC. OK.
+
+### SSH Key Permissions
+- `id_ed25519` hat `VORDEFINIERT\Administratoren FullControl` — das ist zu weit offen.
+- SSH-Clients unter Windows tolerieren das, aber best practice ist: nur der eigene User darf lesen.
+- **Empfehlung:** `icacls` Berechtigungen auf User only setzen (als Admin ausführen).
+
+---
+
+## 4. Storage & Boot
+
+- Alle 5 physischen Disks: **Healthy / OK.**
+- Wear-Level via `Get-StorageReliabilityCounter`: keine Ausgabe (SATA-SSDs und USB HDD liefern keine WMI-Daten). CrystalDiskInfo ist installiert — dort manuell prüfen.
+- Die zwei Intel SATA SSDs (Disk 0 + 1) sind **180 GB** — typische Einzel-Partition-Auslastung auf C: ~36% und D: ~11%, reichlich Luft.
+- **BCD:** ohne Admin nicht lesbar. Doku bestätigt sauberen Zustand nach Cleanup + Neustarttest.
+- **WinRE:** ohne Admin nicht lesbar. Doku sagt Disabled — muss vor künftiger Partitionsarbeit aktiviert werden.
+
+---
+
+## 5. Netzwerk
+
+- Ethernet: 192.168.178.103, DNS auf Kallilabcore (AdGuard). **Korrekt.**
+- Tailscale: aktiv, dieser Rechner als `baerchen-1` online, direkter Pfad zu `kallilabcore`. **OK.**
+- Kein SSH-Config — alle SSH-Verbindungen laufen ohne Host-Aliases. Funktional, aber unpraktisch.
+- Lauschende Ports: Keine auffälligen Exposition nach außen außer SMB (139/445 — LAN-normal) und Steam 27036.
+
+---
+
+## 6. Remote-Management / SSH
+
+- Kein `~\.ssh\config` vorhanden. Empfehlung: Host-Aliases anlegen (z.B. `Host kallilabcore`).
+- SSH-Key vorhanden und aktuell.
+- **Key-Rechte zu weit (s. Security).**
+- Docker contexts: `desktop-linux` aktiv. Docker Desktop läuft.
+- kubectl: keine Contexts — erwartet (kein k8s im Homelab).
+- Tailscale: direkter Pfad zu Homelab aktiv, SSH über Tailscale-IP funktioniert.
+
+---
+
+## 7. Dev-Toolchain
+
+| Tool | Version | Bewertung |
+|---|---|---|
+| git | 2.54.0 | Aktuell, OK |
+| Python | 3.13.13 | Aktuell, OK |
+| Node.js | 24.16.0 (LTS) | Aktuell, OK |
+| Go | 1.26.4 | Aktuell, OK |
+| Commit-Signing | nicht konfiguriert | Optional, aber für Homelab-GitOps empfohlen |
+
+WSL Ubuntu ist installiert aber gestoppt. docker-desktop läuft als WSL2-Backend.
+
+---
+
+## 8. Hardware & Performance
+
+- i5-14600KF, 14C/20T, 31.8 GB RAM — für Homelab-Dev-Rechner gut ausgestattet.
+- Energieplan: **Ausbalanciert** — für einen Gaming- und Dev-Rechner suboptimal. `Höchstleistung` oder `Ultimative Leistung` wäre bei dauerhafter Nutzung besser.
+- Keine echten Gerätekonflikte in PnP (alle "Unknown" sind erwartet: ghosted devices, Netzwerkgeräte, VSS).
+
+---
+
+## 9. Autostart & Persistenz
+
+Läuft automatisch: Brave Update, Steam, Razer Synapse, Docker Desktop, iCUE, Realtek Audio, Tailscale, Ollama.
+
+**Auffällig:** `SoftLanding\CreativeManagementTask` — unbekannter Scheduled Task, nicht einem Standard-Produkt zuzuordnen. Sollte manuell im Task Scheduler geprüft werden (Quelle, Executable, Publisher).
+
+OneDrive läuft mit drei Tasks (Startup + Update) — falls Daten-Sync nicht gewünscht ist, sollte OneDrive deaktiviert werden, da es Dokumente/Bilder/etc. stummschalten könnte (bekanntes Windows-Verhalten nach Known-Folder-Redirect).
+
+---
+
+## 10. Zuverlässigkeit
+
+| Event ID | Anzahl | Beschreibung | Risiko |
+|---|---|---|---|
+| 20 | 70 | Defender KB4052623 Update-Fehler (0x80240016) | Niedrig — Timing, Defender aktuell |
+| 10010 | 15 | DCOM Server Timeout | Niedrig — Windows-Hintergrund |
+| 7000 | 3 | Steam Service Start fehlgeschlagen | Niedrig — Race Condition beim Boot |
+| 7023 | 3 | Windows Modules Installer beendet mit Fehler | Mittel — Update-Abbrüche prüfen |
+| **6008** | **2** | **Unerwartetes Herunterfahren 2026-05-19 13:56** | **Mittel — einmaliger BSOD/Stromausfall** |
+| 7034 | 2 | MSI Center Service Absturz | Niedrig |
+
+- **Kein Crash-Dump** vorhanden (`C:\Windows\Minidump` leer). Entweder ist kein BSOD gewesen (Stromausfall), oder Dump-Einstellungen schreiben nicht.
+- Empfehlung: Dump-Einstellungen auf "Kleiner Speicherauszug" oder "Vollständiger Speicherauszug" prüfen.
+
+---
+
+## 11. Homelab-Server (ausstehend)
+
+**Status: NICHT DURCHGEFÜHRT**
+
+SSH-Config ist leer — kein Host-Alias konfiguriert. Tailscale zeigt `kallilabcore` als aktiv auf `100.80.98.33` / `192.168.178.58`.
+
+**Bitte bestätigen:**
+- SSH-User für Kallilabcore (wahrscheinlich `root`?)
+- Soll ich `ssh root@192.168.178.58` oder über Tailscale-IP verwenden?
+
+Nach Bestätigung wird der Homelab-Teil nachgezogen und dieser Report ergänzt.
+
+---
+
+## 12. Gesamt-Findings (priorisiert)
+
+### Kritisch / Handlungsbedarf vor nächster Partitionsarbeit
+| # | Befund | Begründung |
+|---|---|---|
+| K1 | WinRE ist Disabled (laut Doku) | Ohne WinRE kein automatisches Recovery. Muss aktiviert werden bevor weitere Disk-Ops. |
+| K2 | BitLocker-Status unbekannt (kein Admin) | C: und D: sollten verschlüsselt sein — aktuell Blind Spot. |
+
+### Mittel / Zeitnah klären
+| # | Befund |
+|---|---|
+| M1 | Desktop-Redirect zeigt auf `D:\00_Inbox\Desktop`, Doku sagt `D:\Micha\Desktop` — Doku aktualisieren |
+| M2 | `E:\_Standalone` fehlt — Ordner anlegen oder aus Doku streichen |
+| M3 | SSH Private Key Permissions zu weit (Admins haben FullControl) |
+| M4 | Energieplan "Ausbalanciert" — für Gaming/Dev `Höchstleistung` empfohlen |
+| M5 | `SoftLanding\CreativeManagementTask` unbekannt — Quelle und Publisher prüfen |
+| M6 | Unerwartetes Herunterfahren 2026-05-19 — Ursache klären (Stromausfall? BSOD ohne Dump?) |
+| M7 | `D:\11_Bilder` hat ReadOnly-Attribut — Ursache und Auswirkung prüfen |
+
+### Niedrig / Nice-to-have
+| # | Befund |
+|---|---|
+| N1 | SSH-Config leer — Host-Aliases anlegen |
+| N2 | Git commit.gpgsign nicht gesetzt — für GitOps-Commits empfohlen |
+| N3 | `D:\Micha\Videos` noch vorhanden (1 leere Datei) — bereinigen |
+| N4 | `G:\Apps`, `G:\Workspace` nicht in Doku — dokumentieren oder strukturieren |
+| N5 | `D:\WSL` nicht in Doku — erwähnen |
+| N6 | `D:\13_Musik` leer — Musik aus PostDelta-Backup nachziehen? |
+| N7 | OneDrive läuft (3 Tasks) — prüfen ob Sync für D:\10_Dokumente etc. gewünscht |
+| N8 | Energiesparmodus-Dump-Einstellungen prüfen (kein Dump für 6008-Event) |
+| N9 | `D:\DumpStack.log` ist ein Artefakt aus der alten D:-Nutzung, kann bereinigt werden |
+| N10 | Insider-Build 26200 — bewusste Entscheidung, aber dokumentieren |
+
+---
+
+## 13. Nächste Schritte (empfohlen, nicht ausgeführt)
+
+1. **Homelab-SSH-Zugang bestätigen** und Homelab-Audit nachziehen.
+2. **WinRE aktivieren** (als Admin: `reagentc /enable`) — Voraussetzung für künftige Disk-Ops.
+3. **BitLocker Status prüfen** (als Admin: `Get-BitLockerVolume`) und ggf. für C:/D: aktivieren.
+4. **SSH-Key-Permissions straffen**: `icacls $env:USERPROFILE\.ssh\id_ed25519 /inheritance:r /grant:r "$env:USERNAME:F"` (als Admin).
+5. **`SoftLanding\CreativeManagementTask` untersuchen** — im Task Scheduler Quelle und Aktion prüfen.
+6. **Doku `laufwerks-neustruktur-2026-06-04.md`** unter Abschnitt Desktop-Befund korrigieren: Ist-Ziel `D:\00_Inbox\Desktop`.
+7. **`E:\_Standalone`** anlegen falls geplant.
+8. **`D:\Micha\Videos`** prüfen und ggf. löschen.
+9. **CrystalDiskInfo** für SSD Wear-Level öffnen und Werte dokumentieren.
+10. **Energieplan** auf `Höchstleistung` oder `Ultimative Leistung` umstellen.

docs/homelab-optimierung.md

@@ -0,0 +1,228 @@
+# Homelab-Optimierung — Assessment 2026-06-10
+
+Read-only-Analyse des Repos (Stand `master`, lokale Arbeitskopie 2026-06-10).
+Keine produktiven Änderungen durchgeführt. Alle Empfehlungen sind Vorschläge
+mit Rollback-Plan; nichts wurde deployed.
+
+## Executive Summary
+
+Das KalliLab-CORE-Homelab ist für ein Ein-Host-Setup ungewöhnlich reif:
+GitOps mit Gitea+Komodo, sauberes Netzmodell (frontend/backend/app-intern),
+Authelia mit 2FA-Catch-all, belegte Restore-Drills für alle Tier-1/2-Dienste,
+Off-site-Borg nach Hetzner, DR-Workstation-Kit, Monitoring mit Prometheus/
+Loki/Grafana/Alertmanager→ntfy. Die Doku-Disziplin ist das eigentliche Asset.
+
+Die größten realen Lücken liegen nicht in der Architektur, sondern in der
+**Container-Betriebsebene**: 20 von 30 Stacks haben keinen Healthcheck, kein
+einziger Container hat Memory-/CPU-Limits, und mehrere Images laufen auf
+mutablen Tags (`release`, `latest`, `:2`), bei denen Renovate-Digest-Bumps
+faktisch unkontrollierte Versionssprünge sind — am kritischsten bei Immich.
+Dazu kommen zwei strukturelle Risiken: **AdGuard ist DNS-SPOF ohne Fallback**
+(hat bereits einen Teil-Deploy-Ausfall verursacht) und **Borg-Backups sind
+vom Host aus löschbar** (append-only bewusst abgelehnt, aber die kostenlose
+Kompensation — Hetzner-Storage-Box-Snapshots — ist nicht aktiviert).
+
+## Gesamtbewertung
+
+| Bereich | Note | Begründung |
+|---|---|---|
+| Architektur | **sehr gut** | klares Netzmodell, dokumentierte Ausnahmen, ein Ingress, Compose-first konsequent |
+| Netzwerk/DNS/Proxy | **gut, ein SPOF** | Traefik v3 labelbasiert sauber; AdGuard+Unbound ohne zweiten Resolver — bekannter Vorfall (Bulk-Deploy-DNS-Ausfall, `docs/runbooks/komodo-bulk-deploy-dns.md`) |
+| Container-Betrieb | **mittel** | 10/30 Stacks mit Healthcheck, 0 Ressourcen-Limits, mutable Tags hinter Digests versteckt |
+| Storage/Backups | **sehr gut** | Borg→Hetzner, Dumps, H:/-Nearline, Restore-Drills mit Reports belegt; offen: Backup-Löschschutz |
+| Security/Secrets | **gut** | `_FILE`/Stack-ENV konsequent, 2FA-Catch-all, WAN nur 443/tcp; `no-new-privileges` nur in 10/30 Stacks trotz P8-Pflichtregel |
+| Monitoring/Alerting | **gut** | Prometheus/Blackbox/Loki/ntfy-Kette steht; Monitoring-Stack selbst hat keine Healthchecks und überwacht sich nicht selbst |
+| Automatisierung/IaC | **sehr gut** | Komodo-Webhooks, Renovate, Posture-Check, Critical-Events-Watcher; manuelle Sync-Ausnahmen (traefik/dynamic, Authelia-Config) sind dokumentiert, aber fehleranfällig |
+| Ausfallsicherheit | **bewusst begrenzt** | Ein Host, keine USV (geparkt Q3/2026), kein WAN-Failover — als akzeptiertes Risiko dokumentiert, das ist legitim |
+| Strom/Kosten | **keine Daten** | keine Verbrauchsmessung im Repo sichtbar — siehe offene Fragen |
+
+## Top 10 Verbesserungen nach Mehrwert
+
+### 1. Immich vom `release`-Tag auf Versions-Tag pinnen
+- **Beobachtung:** `apps/immich/docker-compose.yml:4` nutzt `immich-server:release@sha256:...` (ebenso ML). Renovate aktualisiert Digests — beim `release`-Tag ist ein "Digest-Update" in Wahrheit ein Major-/Minor-Versionssprung, ohne dass es im PR-Titel sichtbar wird. Immich ist berüchtigt für Breaking Changes zwischen Minors.
+- **Warum relevant:** Ein gemergter "harmloser" Digest-PR kann Immich unangekündigt auf eine inkompatible Version heben (DB-Migrationen, ML-Modell-Wechsel).
+- **Änderung:** Tag auf die konkret laufende Version umstellen (z. B. `immich-server:v2.x.y@sha256:<aktueller Digest>`), gleiche Vorgehensweise wie bei Mealie/Paperless. Laufende Version ermitteln: `docker exec immich_server cat /usr/src/app/package.json | grep version` oder Immich-UI → Version.
+- **Verifikation:** Renovate erzeugt danach Versions-PRs statt stiller Digest-PRs; `docker inspect immich_server --format '{{.Config.Image}}'` zeigt den Versionstag.
+- **Rollback:** Commit revert; Digest bleibt identisch, kein Redeploy-Zwang.
+- **Nebenwirkungen:** keine zur Laufzeit (Digest unverändert). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | sofort
+- Gleiches Muster prüfen für: `komodo:2`, `ddns-updater:latest`, `scrutiny:latest-omnibus`, `glances:latest-full` sowie tag-lose digest-only Images (`mail-archiver`, `borg-ui`, `ntfy` — Version im Compose unsichtbar).
+
+### 2. Hetzner-Storage-Box-Snapshots als Ransomware-/Fehlbedienungsschutz aktivieren
+- **Beobachtung:** Borg `append-only` wurde am 2026-06-01 bewusst verworfen (forced-command brach Key-Auth). Damit kann jeder mit dem Borg-Key (Host, borg-ui-Container mit `/local/secrets`-Mount) Archive **löschen** — ein kompromittierter Host vernichtet auch das Off-site-Backup.
+- **Warum relevant:** Das ist die einzige verbliebene Lücke in einer sonst sehr guten Backup-Kette.
+- **Änderung:** In der Hetzner-Robot-Konsole automatische Snapshots der Storage Box aktivieren (z. B. täglich, 7–14 Tage Retention). Snapshots sind host-seitig nicht löschbar und im Storage-Box-Preis enthalten.
+- **Verifikation:** Robot-Konsole zeigt Snapshot-Liste; nach 2 Tagen: zwei Snapshots vorhanden. Restore-Probe: einzelne Datei aus Snapshot über das Snapshot-Verzeichnis lesen.
+- **Rollback:** Snapshots deaktivieren — rein additiv, keine Auswirkung auf Borg.
+- **Nebenwirkungen:** Snapshots zählen ggf. anteilig aufs Quota (aktuell 65 GB / 1 TB — viel Luft). | Nutzen: **sehr hoch** | Risiko: niedrig | Aufwand: klein (<30 min) | sofort
+
+### 3. DNS-Fallback gegen den AdGuard-SPOF
+- **Beobachtung:** AdGuard ist einziger LAN-Resolver. Der dokumentierte Vorfall (Bulk-Deploy: AdGuard-Recreate → Host ohne DNS → Komodo-Pulls scheitern) ist genau dieses Muster; das Runbook behandelt nur das Symptom.
+- **Warum relevant:** Jeder AdGuard-Ausfall (Update, OOM, Disk) nimmt LAN + Host-DNS gleichzeitig mit — auch die Reparaturfähigkeit (Image-Pulls!) hängt daran.
+- **Änderung (gestuft):**
+  - a) Host-Ebene: zweiten Nameserver (z. B. `1.1.1.1`) in der Unraid-Netzwerkkonfig als Fallback hinter `192.168.178.58` eintragen. Damit kann der Host immer Images pullen.
+  - b) LAN-Ebene: in der FRITZ!Box als zweiten lokalen DNS die FRITZ!Box selbst (oder einen Public DNS) hinterlegen — bewusster Trade-off: bei AdGuard-Down kein Ad-Blocking statt kein Internet.
+- **Verifikation:** `docker stop adguard` im Wartungsfenster → `nslookup gitea.com` auf dem Host funktioniert weiterhin; danach `docker start adguard`.
+- **Rollback:** Nameserver-Eintrag entfernen.
+- **Nebenwirkungen:** DNS-Anfragen können am Filter vorbeilaufen, solange AdGuard down ist (gewollt); Fallback-Resolver sieht dann Anfragen (Privacy-Abwägung). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | diese Woche
+
+### 4. Healthchecks für die App-Stacks nachrüsten
+- **Beobachtung:** Nur 10 von 30 Compose-Dateien definieren Healthchecks (traefik, gitea, vaultwarden, authelia, postgresql17, redis, komodo, bentopdf, glances, hermes). **Ohne:** Nextcloud (App+DB+Redis), Immich (alle 4), Paperless, Mealie, Mail-Archiver, n8n, AdGuard, Unbound und der komplette Monitoring-Stack (11 Services).
+- **Warum relevant:** Ohne Healthcheck meldet Docker "Up", auch wenn die App hängt; der Critical-Events-Watcher sieht nur `die`/`oom`, keine Hänger. Prometheus-Blackbox prüft nur HTTP-Routen von außen.
+- **Änderung:** Pro Stack einen minimalen Healthcheck ergänzen, priorisiert: Nextcloud (`curl -f http://localhost/status.php`), Paperless, Mealie, n8n, Unbound (`drill @127.0.0.1 cloudflare.com` bzw. `unbound-control status`), AdGuard. Stackweise deployen, nicht als Bulk (siehe DNS-Runbook!).
+- **Verifikation:** `docker ps --format '{{.Names}} {{.Status}}'` zeigt `(healthy)`; cAdvisor/Glance zeigen Health-Status.
+- **Rollback:** Healthcheck-Block entfernen, Redeploy — kein Datenrisiko.
+- **Nebenwirkungen:** Falsch kalibrierte Checks (zu kurze `start_period`) können Flapping erzeugen; konservativ starten (`interval: 60s`, `retries: 5`). | Nutzen: **hoch** | Risiko: niedrig | Aufwand: mittel | diesen Monat
+
+### 5. Memory-Limits für die größten Verbraucher
+- **Beobachtung:** Kein einziger Service hat `mem_limit`/`deploy.resources`. Auf einem Ein-Host-System konkurrieren ~50 Container; ein Speicherleck (Immich-ML, Nextcloud-PHP, Loki) kann den Host-OOM-Killer auslösen, der dann beliebige Tier-1-Container trifft (Postgres!).
+- **Warum relevant:** Der OOM-Killer wählt nach Score, nicht nach Wichtigkeit. Limits machen den Blast-Radius deterministisch: die fehlerhafte App stirbt, nicht die Datenbank.
+- **Änderung:** Erst messen: `docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}'` über ein paar Tage (oder cAdvisor-Dashboard `container_memory_working_set_bytes`). Dann Limits = Peak × 1,5 für die Top-5-Verbraucher (typisch: immich-ml, nextcloud, paperless, plex, prometheus) setzen.
+- **Verifikation:** `docker inspect <c> --format '{{.HostConfig.Memory}}'`; Grafana-Panel Memory vs. Limit; keine neuen `oom`-Events im Critical-Events-Log.
+- **Rollback:** Limit-Zeilen entfernen, Redeploy.
+- **Nebenwirkungen:** Zu knappe Limits OOM-killen die App selbst — deshalb messen statt raten, und Limits nur bei unkritischen Apps zuerst. | Nutzen: **hoch** | Risiko: mittel | Aufwand: mittel | diesen Monat
+
+### 6. `no-new-privileges` flächendeckend gemäß P8
+- **Beobachtung:** Architektur-Regel P8 verlangt `no-new-privileges:true` standardmäßig; gesetzt ist es nur in 10 von 30 Stacks. Es fehlt u. a. bei allen Apps mit WAN-Exposition (Nextcloud, Immich, Paperless, Mealie, ntfy, n8n).
+- **Warum relevant:** Billige Defense-in-Depth gegen Privilege-Escalation nach App-Kompromittierung — genau bei den exponierten Diensten am wertvollsten. Aktuell: dokumentierte Regel ≠ gelebter Stand (Policy-Drift).
+- **Änderung:** `security_opt: ["no-new-privileges:true"]` in die fehlenden Stacks, stackweise mit Smoke-Test. Vorsicht bei Images mit s6/sudo-Setup (LSIO-Images wie speedtest/code-server haben es teils schon — prüfen) und bei Plex (Host-Netz, zuerst testen).
+- **Verifikation:** `docker inspect <c> --format '{{.HostConfig.SecurityOpt}}'`; Posture-/Policy-Check erweitern, damit Drift künftig alarmiert.
+- **Rollback:** Zeile entfernen, Redeploy.
+- **Nebenwirkungen:** Container, die intern setuid brauchen (selten: einige Init-Systeme), starten nicht — fällt im Smoke-Test sofort auf. | Nutzen: mittel | Risiko: niedrig | Aufwand: mittel | diesen Monat
+
+### 7. traefik/dynamic-Sync automatisieren statt manuell
+- **Beobachtung:** `traefik/dynamic/*` (middlewares, tls, dashboards, plex) wird laut dokumentierter Ausnahme **manuell** auf den Host synchronisiert. Das ist die klassische Quelle für "Repo sagt A, Host macht B" — besonders heikel, weil hier Auth-Middlewares definiert sind.
+- **Warum relevant:** Ein vergessener Sync nach einer Middleware-Änderung kann unbemerkt eine Schutzschicht im Live-Zustand alt lassen; auffallen würde es erst beim Audit.
+- **Änderung:** Kleines Sync-Skript analog `services/authelia-diff.sh`: Repo-Spiegel `/mnt/user/services/homelab-infra/traefik/dynamic/` per `rsync --checksum --dry-run` gegen `/mnt/user/appdata/traefik/dynamic/` diffen; Diff ≠ leer → ntfy-Warnung über den bestehenden Posture-Check. (Stufe 2 optional: automatisch syncen; erst nur alarmieren.)
+- **Verifikation:** Testweise eine Whitespace-Änderung im Repo-Spiegel → Posture-Check meldet `traefik_dynamic_drift`.
+- **Rollback:** Check aus dem Posture-Skript entfernen; rein lesend, kein Produktionsrisiko.
+- **Nebenwirkungen:** keine (read-only Check). | Nutzen: mittel | Risiko: niedrig | Aufwand: klein | diese Woche
+
+### 8. Watchdog für den Monitoring-Stack selbst (Dead-Man's-Switch)
+- **Beobachtung:** Die Alert-Kette ist Prometheus → Alertmanager → Bridge → ntfy. Fällt ein Glied (oder der ganze Monitoring-Stack) aus, kommen schlicht **keine** Alerts mehr — Stille ist nicht von "alles gut" unterscheidbar. Kein Healthcheck im Monitoring-Compose.
+- **Warum relevant:** Das Monitoring überwacht alles außer sich selbst.
+- **Änderung:** Dauerhaft feuernde `Watchdog`-Alert-Rule in `monitoring/prometheus/alerts.yml` + externen Heartbeat-Empfänger: einfachste Variante ist healthchecks.io (free) — Alertmanager-Route schickt den Watchdog alle 5 min an die Heartbeat-URL; bleibt er aus, alarmiert healthchecks.io per Mail/Push von außen.
+- **Verifikation:** `docker stop monitoring-prometheus` im Wartungsfenster → externe Benachrichtigung nach ~10 min; danach Start.
+- **Rollback:** Rule + Route entfernen.
+- **Nebenwirkungen:** neue (kleine) externe Abhängigkeit — in `docs/EXTERNAL_DEPENDENCIES.md` eintragen. | Nutzen: **hoch** | Risiko: niedrig | Aufwand: klein | diese Woche
+
+### 9. Lokale Arbeitskopie sauber halten (GitOps-Hygiene)
+- **Beobachtung:** Die lokale Arbeitskopie hat aktuell 6 modifizierte Dateien und 2 untracked Artefakte (u. a. `docs/KalliLab_CORE_Audit_2026-06-06.pdf`, `ops/h-drive-nearline/README.md`), die nicht committed sind. Bei "Gitea = Quelle der Wahrheit" ist eine dauerhaft schmutzige Arbeitskopie ein Drift-Risiko (Änderungen gehen bei Pull-Konflikten verloren oder landen versehentlich in fremden Commits).
+- **Warum relevant:** Genau die Drift-Klasse, vor der `docs/GITOPS_DRIFT_RUNBOOK.md` warnt — nur auf Ebene 2 (lokaler Clone) statt Ebene 4.
+- **Änderung:** Modifizierte Doku-Dateien reviewen und committen oder verwerfen; PDF entweder committen (wenn es Referenz ist) oder in `.gitignore`/außerhalb des Repos ablegen; `ops/h-drive-nearline/README.md` committen.
+- **Verifikation:** `git status` zeigt clean tree (bis auf bewusste Arbeit).
+- **Rollback:** n/a (Aufräumarbeit). | Nutzen: mittel | Risiko: niedrig | Aufwand: klein (<30 min) | sofort
+
+### 10. Doku-Drift-Fixes (klein, aber Vertrauensbasis)
+- **Beobachtung:** `HOMELAB_ARCHITECTURE_MASTER_V2.md` nennt "Redis-Caches auf `redis:7.4-alpine` vereinheitlicht" — real laufen alle auf `redis:8.8.0-alpine`. Ebenso "PostgreSQL 17"-Pfade/Servicenamen bei PG 18 (letzteres ist dokumentiert bewusst, ersteres nicht).
+- **Warum relevant:** Das Masterdokument ist laut eigener Regel die erste Lesepflicht für jeden (auch KI-)Eingriff; veraltete Fakten dort erzeugen falsche Entscheidungen.
+- **Änderung:** Redis-Abschnitt in Sektion 13 auf 8.8 aktualisieren; bei Gelegenheit einen Mini-Check ins Posture-/Audit-Ritual: "stimmen Versionsangaben im Master noch?"
+- **Verifikation:** `grep -n "7.4-alpine" HOMELAB_ARCHITECTURE_MASTER_V2.md` → leer.
+- **Rollback:** trivial (Doku). | Nutzen: niedrig–mittel | Risiko: keiner | Aufwand: klein | sofort
+
+## Top 5 Risiken (zuerst entschärfen)
+
+1. **Löschbare Off-site-Backups** — Host-Kompromittierung oder ein falscher `borg delete` vernichtet auch Hetzner. → Empfehlung 2 (Snapshots). Bis dahin ist das DR-Konzept gegen Ransomware unvollständig.
+2. **DNS-SPOF AdGuard** — bereits einmal real eingetreten (Teil-Deploy 2026-06); betrifft auch die Selbstheilungsfähigkeit (Image-Pulls). → Empfehlung 3.
+3. **Verdeckte Versionssprünge via `release`/`latest`-Digest-Bumps** — v. a. Immich (DB-Migrationen!). → Empfehlung 1.
+4. **OOM-Kaskade ohne Limits** — ein Leck in einer Tier-3-App kann Postgres killen. → Empfehlung 5. (Der Critical-Events-Watcher meldet das nur, verhindert es nicht.)
+5. **Blinde Alert-Kette** — Monitoring-Ausfall = Stille statt Alarm. → Empfehlung 8.
+
+Bewusst akzeptierte Risiken (USV geparkt, ein Host, kein WAN-Failover, kein
+zweites Off-site-Ziel) sind dokumentiert und werden hier nicht erneut
+aufgemacht — die Entscheidungen sind nachvollziehbar.
+
+## Quick Wins unter 30 Minuten
+
+| Quick Win | Wirkung | Kommando/Weg |
+|---|---|---|
+| Hetzner-Snapshots aktivieren | Backup-Löschschutz | Robot-Konsole → Storage Box → Snapshots (Empf. 2) |
+| Host-DNS-Fallback eintragen | Selbstheilung bei AdGuard-Down | Unraid Settings → Network → DNS 2 = `1.1.1.1` (Empf. 3a) |
+| Arbeitskopie aufräumen | GitOps-Hygiene | `git status`, committen/verwerfen (Empf. 9) |
+| Redis-Doku-Drift fixen | Master-Doku wieder korrekt | Sektion 13 editieren (Empf. 10) |
+| Memory-Baseline ziehen | Grundlage für Limits | `docker stats --no-stream` auf dem Host, Output archivieren |
+| Watchdog-Rule anlegen | Vorbereitung Dead-Man's-Switch | `alerts.yml` + healthchecks.io-Account (Empf. 8) |
+
+## 30-Tage-Optimierungsplan
+
+**Woche 1 — Risiko-Entschärfung (alles klein):**
+Hetzner-Snapshots (Empf. 2) · Host-DNS-Fallback + Stop/Start-Test (Empf. 3a) ·
+Immich-Tag-Pinning (Empf. 1) · Arbeitskopie aufräumen (Empf. 9) ·
+Memory-Baseline starten.
+
+**Woche 2 — Beobachtbarkeit:**
+Dead-Man's-Switch produktiv (Empf. 8) · traefik/dynamic-Drift-Check in den
+Posture-Check (Empf. 7) · Healthchecks für Nextcloud, Paperless, Mealie, n8n
+(Empf. 4, stackweise).
+
+**Woche 3 — Hardening:**
+`no-new-privileges` für alle WAN-exponierten Apps (Empf. 6) · Healthchecks
+für AdGuard/Unbound/Monitoring-Kern · restliche Mutable-Tag-Kandidaten pinnen
+(komodo, scrutiny, glances, ddns-updater, tag-lose digest-only Images).
+
+**Woche 4 — Stabilität:**
+Memory-Limits aus der Baseline für die Top-5-Verbraucher (Empf. 5) ·
+FRITZ!Box-DNS-Fallback-Entscheidung (Empf. 3b) · Doku nachziehen
+(Master Sektion 13, SERVICE_CATALOG, dieses Dokument abhaken).
+
+## Größere Projekte mit hohem Nutzen (später)
+
+- **End-to-end-DR-Drill** sobald zweite Hardware existiert (bereits geplant,
+  bleibt der wertvollste offene Beweis).
+- **Strom-/Kostentransparenz:** smarte Steckdose mit Messfunktion (z. B.
+  Shelly Plug S) vor den Unraid-Host, Werte via Home Assistant → InfluxDB 3 →
+  Grafana. Erst messen, dann ggf. optimieren (Spindown-Policy, CPU-Governor).
+  Messbarkeit: W-Dauerlast und kWh/Monat als Grafana-Panel.
+- **USV-Review Q3/2026** wie geparkt — nach Strommessung lässt sich die
+  USV-Dimensionierung direkt ableiten.
+- **Renovate-Policy verfeinern:** Digest-PRs für mutable Tags entweder
+  abschalten oder mit Warn-Label versehen, damit Befund 1 strukturell nicht
+  zurückkommt.
+
+## Konkrete Verifikationskommandos (Sammlung, alle read-only)
+
+```bash
+# Health-Status aller Container
+docker ps --format '{{.Names}}\t{{.Status}}' | sort
+
+# Memory-Baseline
+docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}' | sort -k3 -hr | head -15
+
+# Welche Container ohne no-new-privileges laufen
+docker ps -q | xargs docker inspect --format '{{.Name}} {{.HostConfig.SecurityOpt}}' | grep -v no-new-privileges
+
+# Effektive Image-Referenzen (mutable Tags erkennen)
+docker ps --format '{{.Names}}\t{{.Image}}' | grep -E 'latest|release|:2$|:[0-9]+$'
+
+# DNS-Fallback-Test (Wartungsfenster!)
+docker stop adguard && nslookup gitea.com && docker start adguard
+
+# Borg-Snapshot-Gegenprobe (nach Aktivierung, von der Storage Box)
+ssh -p 23 u565255@u565255.your-storagebox.de ls .snapshots/ 2>/dev/null || echo "via Robot-Konsole prüfen"
+```
+
+## Rollback-Hinweise (generell)
+
+- Jede Compose-Änderung: Revert-Commit nach Gitea pushen → Komodo deployed
+  den Vorzustand; Datenpfade bleiben unberührt (alle Empfehlungen hier sind
+  config-only, keine Daten-/Volume-Migrationen).
+- Healthchecks/Limits/security_opt: Zeilen entfernen + Redeploy genügt.
+- Host-DNS/FRITZ!Box-Einträge: Eintrag löschen, sofort wirksam.
+- Hetzner-Snapshots und Dead-Man's-Switch sind rein additiv.
+- Nichts in diesem Dokument erfordert `push --force`, History-Rewrite oder
+  Löschoperationen auf Datenpfaden.
+
+## Offene Fragen an den Operator
+
+1. **Strom:** Gibt es eine Messung des Host-Verbrauchs (W idle/last)? Ohne
+   Zahl ist der Bereich Kosten/Strom nicht bewertbar. → Shelly/Messsteckdose?
+2. **RAM-Ausstattung des Hosts:** Wie viel RAM hat Kallilabcore gesamt und
+   wie ist die aktuelle Auslastung (`free -h`)? Bestimmt, wie aggressiv
+   Memory-Limits sinnvoll sind.
+3. **Renovate-Verhalten gewollt?** Sollen Digest-Bumps auf `release`/`latest`
+   weiter automatisch als PRs kommen, oder ist die Pinning-Strategie aus
+   Empfehlung 1 die gewünschte Linie für alle Stacks?
+4. **healthchecks.io o. ä. als externe Abhängigkeit akzeptabel?** Alternativ
+   ginge ein ntfy-basierter Heartbeat von einem zweiten Gerät (z. B. dem
+   Gaming-PC per Scheduled Task) — null neue Cloud-Abhängigkeit.
+5. **FRITZ!Box-DNS-Fallback (3b):** Filterlücke bei AdGuard-Down akzeptieren
+   oder lieber nur den Host-Fallback (3a) umsetzen?

docs/runbooks/komodo-bulk-deploy-dns.md

@@ -0,0 +1,58 @@
+# Runbook: Komodo Bulk-Deploy schlaegt mit DNS `connection refused` fehl
+
+Stand: 2026-06-10 · Typ: Runbook / ADR-light · Status: Sofortmassnahme empfohlen, noch nicht umgesetzt
+
+## Symptom
+
+Ein Bulk-Merge (z. B. Renovate-Sammel-PR) loest gleichzeitig viele Komodo-Stack-Webhooks aus. Komodo startet parallele `DeployStack`. Nur ein Teil der Stacks deployt, der Rest bleibt auf dem alten Image. In der Deploy-Stufe **Compose Pull** stehen Fehler wie:
+
+```
+Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io
+on 192.168.178.58:53: read udp ...->192.168.178.58:53: read: connection refused
+```
+
+Manuelles Re-Deploy der betroffenen Stacks danach funktioniert (AdGuard ist dann wieder oben).
+
+## Ursache
+
+Der Host nutzt **AdGuard Home als einzigen Resolver** (`/etc/resolv.conf` = nur `nameserver 192.168.178.58`, keine `/etc/docker/daemon.json`). AdGuard laeuft selbst als Container auf dem Host und bindet `0.0.0.0:53`. Wird der `adguard`-Stack im selben Batch neu deployt, faellt Port 53 fuer Sekunden aus. Alle parallelen `docker compose pull` der anderen Stacks koennen `registry-1.docker.io` dann nicht aufloesen -> `connection refused` -> Deploy `success=false`.
+
+Es ist **kein** Webhook-, Auth- oder Docker-Hub-Rate-Limit-Problem: Webhooks authentifizieren sauber, `webhook_enabled=true`, Fehlerbild ist `connection refused` auf den eigenen DNS-Port direkt nach AdGuard-Recreate. Fuer den Pull-Pfad zaehlt der Docker-Daemon/Go-Resolver (iteriert ueber die `resolv.conf`-Server und springt bei Socket-Fehlern zum naechsten), nicht der glibc-Client.
+
+## Sofortmassnahme (Schicht 1)
+
+Unraid -> Settings -> Network Settings -> `eth0`:
+
+- DNS server 1: `192.168.178.58` (AdGuard, bleibt)
+- **DNS server 2: `192.168.178.1`** (FritzBox) -> Apply
+
+Damit ueberleben Registry-Pulls einen kurzen AdGuard-Ausfall via Resolver-Failover. Im Normalbetrieb wird weiter DNS1 (AdGuard) genutzt, der Filter bleibt aktiv.
+
+Pruefen / Bedingungen:
+
+- **Kein `options rotate`** in `/etc/resolv.conf` (sonst dauerhafter Filter-Bypass). Aktuell nicht gesetzt; nach Apply erneut pruefen.
+- Router muss oeffentliche Namen **selbst** aufloesen und nicht intern an AdGuard zurueckleiten.
+- Hinweis zur Verifikation: Ein `nslookup registry-1.docker.io 192.168.178.1` bei laufendem AdGuard ist ein gutes Signal, aber **kein letzter Beweis**. Wasserdicht: AdGuard kurz stoppen und `dig @192.168.178.1 registry-1.docker.io`, oder FritzBox-Upstream / AdGuard-Querylog pruefen.
+
+Rollback: DNS server 2 leeren + Apply.
+
+## Betriebsregel (Schicht 2)
+
+- **AdGuard und Unbound nicht gemeinsam mit abhaengigen Stacks im Bulk deployen.** DNS-Infrastruktur immer separat / einzeln deployen, nicht waehrend 20+ parallele Pulls laufen.
+- Renovate-PRs gestaffelt mergen (eine Etappe pro Deploy) statt Sammel-Merge. Deckt dieses Problem fuer den Normalbetrieb bereits ab.
+
+## Spaeter optional
+
+- Komodo-Deploys serialisieren: statt vieler paralleler Stack-Webhooks eine **Procedure** (sequenzielle Stages) oder **Resource Sync** mit `after`-Ordering. Trifft die Ursache direkter, ist aber ein groesserer Umbau und **kein Renovate-Blocker**.
+- Host-DNS vom AdGuard-Container entkoppeln (AdGuard eigene IP via macvlan, Host-Resolver auf Router/Unbound), damit `:53` am Host nicht exklusiv am Container-Lifecycle haengt.
+
+## Verworfen
+
+- `/etc/docker/daemon.json` mit `"dns": [...]`: wirkt nur fuer Container-DNS, nicht fuer Daemon-eigene Image-Pulls.
+- AdGuard `network_mode: host`: beim Recreate ist der DNS-Prozess trotzdem weg; macht aus dem Single Point of Failure keinen HA-Resolver.
+
+## Referenzen
+
+- Diagnose-Zugriff: SSH `root@192.168.178.58`; Komodo-Mongo (`docker exec komodo-mongo`, DB `komodo`, Collections `Stack`/`Update`); Gitea SQLite `/data/gitea/gitea.db` (Tabelle `webhook`, `repo_id=3`).
+- Verwandt: `docs/WORKFLOW.md` (DNS-Regeln fuer Container), `docs/GITOPS_DRIFT_RUNBOOK.md`.
+</content>

host-services/Adguard/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   adguard:
-    image: adguard/adguardhome:v0.107.52@sha256:d16cc7517ab96f843e7f8bf8826402dba98f5e6b175858920296243332391589
+    image: adguard/adguardhome:v0.107.77@sha256:e6f2b8bcda06064ab055b44933a4f0e983c35558b9cdb8d2e7ab1efcee36d890
     container_name: adguard
     restart: unless-stopped
     volumes:

host-services/tailscale/docker-compose.yml

@@ -1,25 +0,0 @@
-services:
-  tailscale:
-    image: tailscale/tailscale:stable@sha256:dbeff02d2337344b351afac203427218c4d0a06c43fc10a865184063498472a6
-    container_name: Tailscale-Docker
-    restart: unless-stopped
-    network_mode: host
-
-    cap_add:
-      - NET_ADMIN
-      - NET_RAW
-
-    security_opt:
-      - no-new-privileges:true
-
-    devices:
-      - /dev/net/tun:/dev/net/tun
-
-    environment:
-      - TZ=Europe/Berlin
-      - TS_HOSTNAME=kallilab-core
-      - TS_STATE_DIR=/state
-      - TS_AUTH_ONCE=true
-
-    volumes:
-      - /mnt/user/appdata/tailscale:/state

infra/ddns-updater/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   ddns-updater:
-    image: ghcr.io/qdm12/ddns-updater:latest@sha256:ee16ab4f6203bf9e5b0925d38a0b4ebf2d9f23771f933cfb2f5a2dbd5f9a2f88
+    image: ghcr.io/qdm12/ddns-updater:latest@sha256:9313e1c31f366c89dc0819e5eff85576cb23821424c0c267fa66cfa39aabde83
     container_name: ddns-updater
     restart: unless-stopped
     security_opt:

infra/postgresql17/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   postgresql17:
-    image: postgres:17.9@sha256:5b96f1a16bd9768b060dd2ffe55cb6225c4d9ef4d214a8b21eb08134869a97e4
+    image: postgres:18.4@sha256:8ff36f3c66371cba71d20ceedccfc3de9669a68737607888c4ef0af93abe8e39
     container_name: postgresql17
     restart: unless-stopped
 
@@ -9,10 +9,10 @@ services:
       POSTGRES_USER: mailarchiver
       POSTGRES_DB: mailarchiver
       POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
-      PGDATA: /var/lib/postgresql/data
+      PGDATA: /var/lib/postgresql/18/docker
 
     volumes:
-      - /mnt/user/appdata/postgresql17:/var/lib/postgresql/data
+      - /mnt/user/appdata/postgresql18:/var/lib/postgresql
       - /mnt/user/appdata/secrets/postgres_password.txt:/run/secrets/postgres_password:ro
 
     networks:

infra/redis/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   redis:
-    image: redis:7.4-alpine@sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99
+    image: redis:8.8.0-alpine@sha256:09160599abd229764c0fb44cb6be640294e1d360a54b19985ab4843dcf2d90f1
     container_name: Redis
     restart: unless-stopped
     command:

monitoring/README.md

@@ -17,7 +17,7 @@ Zielzustand: ein zentraler Observability-Stack fuer KalliLab CORE.
 
 Die alten Pfade `ops/loki` und `ops/grafana-influxdb` wurden am 2026-05-26 aus dem aktiven Repo entfernt. Rollback erfolgt bei Bedarf ueber Git-Historie, nicht ueber parallel gepflegte Compose-Verzeichnisse.
 
-Live-Stand 2026-05-25: die zehn `monitoring-*` Container laufen produktiv, die alten Container `grafana`, `influxdb3-core`, `loki` und `alloy` sind in Docker nicht mehr vorhanden. Uptime Kuma ist durch Blackbox Exporter, Prometheus-Alerts und das Dashboard `Homelab / Availability` abgeloest.
+Live-Stand 2026-06-01: die zehn `monitoring-*` Container laufen produktiv, die alten Container `grafana`, `influxdb3-core`, `loki` und `alloy` sind in Docker nicht mehr vorhanden. Uptime Kuma ist durch Blackbox Exporter, Prometheus-Alerts und das Dashboard `Homelab / Availability` abgeloest.
 
 ## Secrets
 
@@ -72,7 +72,7 @@ INFLUXDB_BIND_IP=192.168.178.58
 - Dozzle bleibt abgeloest: `Homelab / Containers + Logs` ersetzt Live-Logs und Error-Rate.
 - Glances erst stoppen, wenn `Homelab / Host Overview` und `Homelab / Containers + Logs` fuer CPU, RAM, Disk, Network, Container-CPU und Container-RAM passen.
 - Uptime Kuma ist entfernt; `Homelab / Availability`, Blackbox Exporter und Prometheus-Alerts sind der Zielzustand fuer HTTP-Verfuegbarkeit.
-- Dashboard-Zielbestand: `Homelab / Availability`, `Homelab / Containers + Logs`, `Homelab / Host Overview`, `Traefik Official Standalone Dashboard`.
+- Dashboard-Zielbestand: `Homelab / Availability`, `Homelab / Containers + Logs`, `Homelab / Host Overview`, `Homelab / Family Status`, `Traefik Official Standalone Dashboard`.
 
 ## Alerting
 

monitoring/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   prometheus:
-    image: prom/prometheus:v3.7.3@sha256:49214755b6153f90a597adcbff0252cc61069f8ab69ce8411285cd4a560e8038
+    image: prom/prometheus:v3.12.0@sha256:69f5241418838263316593f7274a304b095c40bcf22e57272865da91bd60a8ac
     container_name: monitoring-prometheus
     restart: unless-stopped
     command:
@@ -25,7 +25,7 @@ services:
       - cadvisor
 
   alertmanager:
-    image: prom/alertmanager:v0.28.1@sha256:27c475db5fb156cab31d5c18a4251ac7ed567746a2483ff264516437a39b15ba
+    image: prom/alertmanager:v0.32.2@sha256:b85533a2eb45865835315810315f6951331b2dbc8c93a6cf9a51e156a006a706
     container_name: monitoring-alertmanager
     restart: unless-stopped
     command:
@@ -42,7 +42,7 @@ services:
       - no-new-privileges:true
 
   alertmanager-ntfy-bridge:
-    image: python:3.13-alpine@sha256:420cd0bf0f3998275875e02ecd5808168cf0843cbb4d3c536432f729247b2acc
+    image: python:3.14-alpine@sha256:5a824eb82cc75361f98611f3cfc5091ea33f10a6ccea4d4ebdabbc523b9a1614
     container_name: monitoring-alertmanager-ntfy-bridge
     restart: unless-stopped
     dns:
@@ -63,18 +63,21 @@ services:
       - no-new-privileges:true
 
   blackbox-exporter:
-    image: prom/blackbox-exporter:v0.27.0@sha256:a50c4c0eda297baa1678cd4dc4712a67fdea713b832d43ce7fcc5f9bea05094d
+    image: prom/blackbox-exporter:v0.28.0@sha256:e753ff9f3fc458d02cca5eddab5a77e1c175eee484a8925ac7d524f04366c2fc
     container_name: monitoring-blackbox-exporter
     restart: unless-stopped
+    # Use AdGuard so *.kaleschke.info resolves to the internal Traefik IP.
+    # External resolvers (1.1.1.1/8.8.8.8) return the public WAN IP, which
+    # causes hairpin-NAT timeouts when probing from inside the Docker network.
     dns:
-      - 1.1.1.1
+      - 172.23.0.3
-      - 8.8.8.8
     command:
       - --config.file=/etc/blackbox_exporter/blackbox.yml
     volumes:
       - ./blackbox/blackbox.yml:/etc/blackbox_exporter/blackbox.yml:ro
     networks:
       - monitoring_net
+      - dns_net
     expose:
       - "9115"
     security_opt:
@@ -97,7 +100,7 @@ services:
       - no-new-privileges:true
 
   promtail:
-    image: grafana/promtail:3.6.10@sha256:2a0f5e3e160ee5d549c585f6cc4f4e1c566ff783324a424bd75bc16503fc660e
+    image: grafana/promtail:3.6.11@sha256:a761cb834cfaeee29745440d4884d6748f0a08d8f68928db1d707018c1dcfbe9
     container_name: monitoring-promtail
     restart: unless-stopped
     command:
@@ -115,8 +118,9 @@ services:
       - loki
 
   grafana:
-    image: grafana/grafana:12.4.3@sha256:2e986801428cd689c2358605289c90ab37d2b39e24808874971f54c99bcdc412
+    image: grafana/grafana:13.0.2@sha256:5dad0df181cb644a14e13617b913b261a54f7d4fd4510721dba420929f35bea2
     container_name: monitoring-grafana
+    user: "0"
     restart: unless-stopped
     dns:
       - 1.1.1.1
@@ -127,6 +131,21 @@ services:
       GF_SECURITY_ADMIN_PASSWORD__FILE: /run/secrets/monitoring_grafana_admin_password
       GF_USERS_ALLOW_SIGN_UP: "false"
       GF_AUTH_ANONYMOUS_ENABLED: "false"
+      GF_PLUGINS_PREINSTALL_DISABLED: "true"
+      # --- Authelia OIDC SSO (2026-06-06) ---
+      GF_AUTH_GENERIC_OAUTH_ENABLED: "true"
+      GF_AUTH_GENERIC_OAUTH_NAME: Authelia
+      GF_AUTH_GENERIC_OAUTH_CLIENT_ID: grafana
+      GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET__FILE: /run/secrets/grafana_oidc_client_secret
+      GF_AUTH_GENERIC_OAUTH_SCOPES: "openid profile email groups"
+      GF_AUTH_GENERIC_OAUTH_AUTH_URL: https://auth.kaleschke.info/api/oidc/authorization
+      GF_AUTH_GENERIC_OAUTH_TOKEN_URL: https://auth.kaleschke.info/api/oidc/token
+      GF_AUTH_GENERIC_OAUTH_API_URL: https://auth.kaleschke.info/api/oidc/userinfo
+      GF_AUTH_GENERIC_OAUTH_USE_PKCE: "true"
+      GF_AUTH_GENERIC_OAUTH_ALLOW_SIGN_UP: "true"
+      # Proof: alle OIDC-Logins als Admin; spaeter ueber groups verfeinern
+      GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: "'Admin'"
+      GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_STRICT: "false"
     entrypoint:
       - /bin/sh
       - -c
@@ -143,6 +162,7 @@ services:
     secrets:
       - monitoring_grafana_admin_password
       - monitoring_grafana_influxdb_token
+      - grafana_oidc_client_secret
     expose:
       - "3000"
     security_opt:
@@ -158,11 +178,12 @@ services:
       - traefik.http.routers.monitoring-grafana.entrypoints=websecure
       - traefik.http.routers.monitoring-grafana.tls=true
       - traefik.http.routers.monitoring-grafana.tls.certresolver=le
-      - traefik.http.routers.monitoring-grafana.middlewares=authelia@file,secure-headers@file
+      # ForwardAuth bewusst entfernt 2026-06-06: Grafana macht jetzt eigenes OIDC-SSO gegen Authelia
+      - traefik.http.routers.monitoring-grafana.middlewares=secure-headers@file
       - traefik.http.services.monitoring-grafana.loadbalancer.server.port=3000
 
   grafana-dashboard-importer:
-    image: python:3.13-alpine
+    image: python:3.14-alpine
     container_name: monitoring-grafana-dashboard-importer
     restart: "no"
     profiles:
@@ -273,7 +294,7 @@ services:
         echo "Dashboard import complete."
 
   node-exporter:
-    image: prom/node-exporter:v1.9.1@sha256:d00a542e409ee618a4edc67da14dd48c5da66726bbd5537ab2af9c1dfc442c8a
+    image: prom/node-exporter:v1.11.1@sha256:e9cff4fc67b1818f8c97adb115b9f12c9a54b533de86765d4a0effc01b357205
     container_name: monitoring-node-exporter
     restart: unless-stopped
     command:
@@ -295,7 +316,7 @@ services:
       - no-new-privileges:true
 
   cadvisor:
-    image: ghcr.io/google/cadvisor:v0.53.0@sha256:c3770bd6fc6c6a9cb2b47143e6b3cc3fdd9d20a8453dffbb7e09a145e7e0c4e4
+    image: ghcr.io/google/cadvisor:v0.57.0@sha256:e75bdb03b74b0b6995f208f166fead2e6e555dde73e44200113bb26f41b1981d
     container_name: monitoring-cadvisor
     restart: unless-stopped
     command:
@@ -316,7 +337,7 @@ services:
       - no-new-privileges:true
 
   influxdb3-core:
-    image: influxdb:3.9.1-core@sha256:1d58c8b9ac90153ae3a020ede2810c8284933dda50ac71e7573389ab6f012128
+    image: influxdb:3.9.3-core@sha256:c27c9b2ca2625b5b6966f0b09baa448102310e63a471fd60dff22646a2522e29
     container_name: monitoring-influxdb3-core
     user: "0"
     restart: unless-stopped
@@ -349,6 +370,8 @@ networks:
     driver: bridge
   frontend_net:
     external: true
+  dns_net:
+    external: true
 
 volumes:
   prometheus_data:
@@ -362,5 +385,7 @@ secrets:
     file: /mnt/user/appdata/secrets/monitoring_grafana_admin_password.txt
   monitoring_grafana_influxdb_token:
     file: /mnt/user/appdata/secrets/monitoring_grafana_influxdb_token.txt
+  grafana_oidc_client_secret:
+    file: /mnt/user/appdata/secrets/grafana_oidc_client_secret
   influxdb3_admin_token:
     file: /mnt/user/appdata/secrets/influxdb3_admin_token.json

monitoring/grafana/dashboards/family-status.json

@@ -0,0 +1,295 @@
+{
+  "uid": "homelab-family-status",
+  "title": "Homelab / Family Status",
+  "tags": ["homelab", "family", "status"],
+  "timezone": "browser",
+  "schemaVersion": 39,
+  "version": 1,
+  "refresh": "30s",
+  "time": {
+    "from": "now-24h",
+    "to": "now"
+  },
+  "panels": [
+    {
+      "id": 1,
+      "type": "stat",
+      "title": "Family Apps Up",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 0, "y": 0},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "sum(probe_success{job=\"blackbox-http\", instance=~\"https://(vault|immich|cloud|paperless|mealie|ntfy|glance)\\\\.kaleschke\\\\.info\"})"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "red", "value": null},
+              {"color": "yellow", "value": 5},
+              {"color": "green", "value": 7}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 2,
+      "type": "stat",
+      "title": "Family Apps Down",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 6, "y": 0},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "count(probe_success{job=\"blackbox-http\", instance=~\"https://(vault|immich|cloud|paperless|mealie|ntfy|glance)\\\\.kaleschke\\\\.info\"}) - sum(probe_success{job=\"blackbox-http\", instance=~\"https://(vault|immich|cloud|paperless|mealie|ntfy|glance)\\\\.kaleschke\\\\.info\"})"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "green", "value": null},
+              {"color": "red", "value": 1}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 3,
+      "type": "stat",
+      "title": "Backup Age",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 12, "y": 0},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "(time() - homelab_borg_last_completed_timestamp_seconds) / 3600"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "h",
+          "decimals": 1,
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "green", "value": null},
+              {"color": "yellow", "value": 24},
+              {"color": "red", "value": 30}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 4,
+      "type": "stat",
+      "title": "TLS Days Left",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 18, "y": 0},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "min((probe_ssl_earliest_cert_expiry{job=\"blackbox-http\"} - time()) / 86400)"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "d",
+          "decimals": 0,
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "red", "value": null},
+              {"color": "yellow", "value": 7},
+              {"color": "green", "value": 21}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 5,
+      "type": "stat",
+      "title": "Critical Containers Down",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 0, "y": 5},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "count(homelab_critical_container_running) - sum(homelab_critical_container_running)"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "green", "value": null},
+              {"color": "red", "value": 1}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 6,
+      "type": "stat",
+      "title": "Image Drift",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 6, "y": 5},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "count(homelab_gitops_runtime_image_match) - sum(homelab_gitops_runtime_image_match)"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "short",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "green", "value": null},
+              {"color": "yellow", "value": 1},
+              {"color": "red", "value": 3}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 7,
+      "type": "stat",
+      "title": "Last Backup OK",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 12, "y": 5},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "homelab_borg_last_success"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "bool",
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "red", "value": null},
+              {"color": "green", "value": 1}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 8,
+      "type": "stat",
+      "title": "Metrics Age",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 5, "w": 6, "x": 18, "y": 5},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "(time() - homelab_textfile_exporter_last_run_timestamp_seconds) / 60"
+        }
+      ],
+      "fieldConfig": {
+        "defaults": {
+          "unit": "m",
+          "decimals": 0,
+          "thresholds": {
+            "mode": "absolute",
+            "steps": [
+              {"color": "green", "value": null},
+              {"color": "yellow", "value": 60},
+              {"color": "red", "value": 120}
+            ]
+          }
+        },
+        "overrides": []
+      },
+      "options": {"reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}}
+    },
+    {
+      "id": 9,
+      "type": "timeseries",
+      "title": "Family App Availability",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 8, "w": 12, "x": 0, "y": 10},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "probe_success{job=\"blackbox-http\", instance=~\"https://(vault|immich|cloud|paperless|mealie|ntfy|glance)\\\\.kaleschke\\\\.info\"}",
+          "legendFormat": "{{instance}}"
+        }
+      ],
+      "fieldConfig": {"defaults": {"unit": "bool", "min": 0, "max": 1}, "overrides": []},
+      "options": {"legend": {"displayMode": "list", "placement": "bottom"}}
+    },
+    {
+      "id": 10,
+      "type": "timeseries",
+      "title": "Family App Response Time",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 8, "w": 12, "x": 12, "y": 10},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "probe_duration_seconds{job=\"blackbox-http\", instance=~\"https://(vault|immich|cloud|paperless|mealie|ntfy|glance)\\\\.kaleschke\\\\.info\"}",
+          "legendFormat": "{{instance}}"
+        }
+      ],
+      "fieldConfig": {"defaults": {"unit": "s"}, "overrides": []},
+      "options": {"legend": {"displayMode": "list", "placement": "bottom"}}
+    },
+    {
+      "id": 11,
+      "type": "table",
+      "title": "Public Endpoint Status",
+      "datasource": "Prometheus",
+      "gridPos": {"h": 9, "w": 24, "x": 0, "y": 18},
+      "targets": [
+        {
+          "refId": "A",
+          "expr": "probe_http_status_code{job=\"blackbox-http\"}",
+          "format": "table",
+          "instant": true
+        }
+      ],
+      "transformations": [
+        {
+          "id": "organize",
+          "options": {
+            "excludeByName": {"Time": true, "__name__": true, "job": true},
+            "renameByName": {"Value": "status_code", "instance": "target"}
+          }
+        }
+      ]
+    }
+  ]
+}

monitoring/grafana/provisioning/alerting/.gitkeep

@@ -0,0 +1 @@
+

monitoring/grafana/provisioning/plugins/.gitkeep

@@ -0,0 +1 @@
+

monitoring/prometheus/alerts.yml

@@ -57,6 +57,15 @@ groups:
           summary: "Disk usage high on {{ $labels.mountpoint }}"
           description: "{{ $labels.mountpoint }} is above 85% used."
 
+      - alert: HomelabDiskCritical
+        expr: 100 * (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) > 95
+        for: 5m
+        labels:
+          severity: critical
+        annotations:
+          summary: "Disk critically full on {{ $labels.mountpoint }}"
+          description: "{{ $labels.mountpoint }} is above 95% used. Writes may start to fail (DB, appdata, cache)."
+
       - alert: HomelabHighMemoryUsage
         expr: 100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 90
         for: 10m
@@ -130,3 +139,23 @@ groups:
         annotations:
           summary: "Critical container is down: {{ $labels.name }}"
           description: "The host textfile exporter reports that critical container {{ $labels.name }} is not running."
+
+      - alert: HomelabGitOpsRuntimeImageDrift
+        expr: homelab_gitops_runtime_image_match == 0
+        for: 10m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Runtime image drift: {{ $labels.name }}"
+          description: "Container {{ $labels.name }} is not running the image declared by its Compose config in project {{ $labels.project }}."
+
+  - name: homelab-meta
+    rules:
+      - alert: HomelabPrometheusTargetDown
+        expr: up == 0
+        for: 5m
+        labels:
+          severity: critical
+        annotations:
+          summary: "Prometheus target down: {{ $labels.job }} / {{ $labels.instance }}"
+          description: "Scrape target {{ $labels.instance }} (job {{ $labels.job }}) is unreachable. Metrics from this target are silent — alerts built on them will not fire."

ops/borg-ui/BACKUP_SCOPE.md

@@ -1,6 +1,6 @@
 # Borg Backup Scope for KalliLabcore
 
-Stand: 2026-05-16
+Stand: 2026-05-31
 
 This file defines the target state for replacing Backrest with Borg in this homelab.
 
@@ -45,7 +45,7 @@ The Unraid flash configuration archive is intentional as well and must be treate
 | GitOps host automation | repo clone + Komodo workspaces + host-check state | `/local/services/homelab-infra`, `/local/services/stacks`, `/local/services/posture-check` |
 | Unraid OS flash | generated config archive | `/local/borg-dumps/unraid-flash-config.tar.gz` plus checksum and manifest |
 | Nextcloud | DB dump + file data | `/local/borg-dumps`, `/local/appdata/nextcloud/html`, `/local/nextcloud/data` |
-| Grafana | SQLite dump + file data | `/local/borg-dumps`, `/local/appdata/grafana` |
+| Grafana | SQLite dump from `monitoring_grafana_data` + provisioned config in Git | `/local/borg-dumps`, `monitoring/grafana/provisioning`, `monitoring/grafana/dashboards` |
 | Filebrowser | file-backed state dump + file data | `/local/borg-dumps`, `/local/appdata/filebrowser` |
 | InfluxDB 3 Core | file data | `/local/appdata/influxdb3/data`, `/local/appdata/influxdb3/plugins` |
 | Hermes Agent | file data + SSH key | `/local/appdata/hermes-agent/data`, `/local/secrets/hermes_runner_id_ed25519` |
@@ -69,7 +69,7 @@ The live Unraid User Scripts execute repo scripts from `/mnt/user/services/homel
 
 ## Database Dumps Required
 
-### Shared PostgreSQL (`postgresql17`)
+### Shared PostgreSQL (`postgresql17`, runtime PostgreSQL 18)
 
 - `mailarchiver`
 - `paperless`
@@ -90,14 +90,16 @@ The live Unraid User Scripts execute repo scripts from `/mnt/user/services/homel
 
 ## Explicitly Not Backed Up as Raw Live DB Files
 
-- `/mnt/user/appdata/postgresql17`
+- `/mnt/user/appdata/postgresql18`
-- `/mnt/user/appdata/mealie/postgres`
+- `/mnt/user/appdata/mealie/postgres18`
-- `/mnt/user/appdata/immich_postgres`
+- `/mnt/user/appdata/immich_postgres_vectorchord`
-- `/mnt/user/appdata/nextcloud/postgres`
+- `/mnt/user/appdata/nextcloud/postgres18`
 - `/mnt/user/appdata/komodo/mongo`
 - `/mnt/user/appdata/redis`
 - `/mnt/user/appdata/scrutiny/influxdb`
 
+Archived PG18/VectorChord rollback volumes under `/mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602` are retained only as temporary rollback material, not as primary backup truth.
+
 ## Low-Priority / Rebuildable
 
 These are not part of the first-class Borg scope:

ops/borg-ui/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   borg-ui:
-    image: ainullcode/borg-ui@sha256:867c73983e5bef5491cdee1c34acf85fe8a9fe4f6ad5a9381e7ca2c382359ce6
+    image: ainullcode/borg-ui@sha256:0922157e8f77a1b2bd23cd09366a458ea6de07fd9306aa1485f9cfe623eca17f
     container_name: borg-ui
     restart: unless-stopped
     security_opt:

ops/borg-ui/scripts/pre-backup-dumps.sh

@@ -278,7 +278,7 @@ main() {
   need_cmd sha256sum
   ensure_dirs
 
-  # Shared PostgreSQL 17
+  # Shared PostgreSQL 18 (historischer Containername: postgresql17)
   if need_container "postgresql17"; then
     # Use the cluster admin/superuser for all shared-cluster dumps. The
     # application roles exist, but they can have different passwords from the
@@ -324,7 +324,7 @@ main() {
 
   # Additional host-side SQLite dumps for admin tooling with appdata files.
   dump_sqlite_file "/mnt/user/appdata/borg-ui/data/borg.db" "$LATEST_DIR/borg-ui.sqlite" "borg-ui"
-  dump_sqlite_file "/mnt/user/appdata/grafana/grafana.db" "$LATEST_DIR/grafana.sqlite" "grafana"
+  dump_sqlite_file "/var/lib/docker/volumes/monitoring_grafana_data/_data/grafana.db" "$LATEST_DIR/grafana.sqlite" "grafana"
 
   # MongoDB
   dump_mongo_container "komodo-mongo" "$LATEST_DIR/komodo-mongo.archive.gz"

ops/code-server/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   code-server:
-    image: lscr.io/linuxserver/code-server:4.116.0@sha256:4620adace18935dd6ca79d77e3bc1c379e21875392192f970cf5d6b0fb4aefcd
+    image: lscr.io/linuxserver/code-server:4.123.0@sha256:cb261a7f87674b445e0fd66d87d55900c1b823d276c727ab0d168a75e69e9992
     container_name: code-server
     restart: unless-stopped
     security_opt:

ops/filebrowser/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   filebrowser:
-    image: filebrowser/filebrowser:v2.63.2@sha256:4dce87308b9f9cfbcf8d0a284fc9565d2b515530a6bae2d920b388161e093f26
+    image: filebrowser/filebrowser:v2.63.14@sha256:1ec9b0c68297550c92f4a93feed432850c2993b261706cc3cc2e808f94a95e76
     container_name: filebrowser
     restart: unless-stopped
     security_opt:

ops/glance/config/glance.yml

@@ -473,7 +473,7 @@ pages:
                 category: core
                 hide: false
               postgresql17:
-                name: PostgreSQL 17
+                name: PostgreSQL 18
                 icon: si:postgresql
                 description: Shared DB
                 category: core
@@ -497,12 +497,6 @@ pages:
                 description: Upstream Resolver
                 category: network
                 hide: false
-              Tailscale-Docker:
-                name: Tailscale
-                icon: https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/tailscale.svg
-                description: VPN
-                category: network
-                hide: false
               ddns-updater:
                 name: DDNS Updater
                 icon: mdi:cloud-sync

ops/glance/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   glance:
-    image: glanceapp/glance:v0.8.4
+    image: glanceapp/glance:v0.8.5
     container_name: glance
     restart: unless-stopped
     environment:

ops/glances/docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   glances:
-    image: nicolargo/glances:latest-full@sha256:b4b0f059fa8064a0e8dae5530ce9334834ab07205269cfbf405d16b4d40c0c66
+    image: nicolargo/glances:latest-full@sha256:60872a1af0e40a3150975617c7e811ad7ad48f95bc45d033fb0c1737a037e4d2
     container_name: glances
     restart: unless-stopped
     pid: host

ops/h-drive-nearline/pull-critical-backups.ps1

@@ -17,13 +17,34 @@ $Jobs = @(
     # nicht ueberbruecken kann. Restore-Quelle dafuer bleibt das
     # Hetzner-Borg-Repo (siehe docs/RESTORE_MATRIX.md Tier 1 Unraid OS Flash).
     ExcludeFiles = @("unraid-flash-config.tar.gz", "unraid-flash-config.tar.gz.sha256", "unraid-flash-config.manifest.txt")
+    Files = @(
+      "borg-ui.sqlite",
+      "filebrowser.bolt.dump",
+      "gitea.sqlite.dump",
+      "grafana.sqlite",
+      "immich.dump",
+      "komodo-mongo.archive.gz",
+      "mealie.dump",
+      "nextcloud.dump",
+      "postgresql17-authelia.dump",
+      "postgresql17-globals.sql",
+      "postgresql17-mailarchiver.dump",
+      "postgresql17-paperless.dump",
+      "speedtest-tracker.sqlite.dump",
+      "vaultwarden.sqlite.dump"
+    )
+    # Migration-/Cutover-Arbeitsverzeichnisse bleiben im Borg-Scope, sind aber
+    # keine Nearline-Pflichtartefakte und enthalten teils root-only Dateien.
+    ExcludeDirs = @(".tmp", "immich-vectorchord-*", "nextcloud-redis-pre-redis8-*", "pg18-major-*", "redis8-*", "shared-redis-pre-redis8-*")
   },
   @{
     Name = "gitea-bundles"
     Source = Join-Path $SourceRoot "git-bundles\gitea"
     Destination = Join-Path $DestinationRoot "git-bundles\gitea"
     Purpose = "Verified bare-repository bundles for Gitea bootstrap"
+    Files = @("*.*")
     ExcludeFiles = @()
+    ExcludeDirs = @(".tmp")
   }
 )
 
@@ -47,9 +68,17 @@ function Invoke-RobocopyJob {
   $logPath = Join-Path $LogRoot ("{0}-{1}.log" -f (Get-Date -Format "yyyyMMdd-HHmmss"), $Job.Name)
   New-Item -ItemType Directory -Force -Path $Job.Destination | Out-Null
 
+  $files = @("*.*")
+  if ($Job.ContainsKey("Files") -and $Job.Files.Count -gt 0) {
+    $files = $Job.Files
+  }
+
   $args = @(
     $Job.Source,
-    $Job.Destination,
+    $Job.Destination
+  )
+  $args += $files
+  $args += @(
     "/E",
     "/COPY:DAT",
     "/DCOPY:DAT",
@@ -57,13 +86,16 @@ function Invoke-RobocopyJob {
     "/W:5",
     "/FFT",
     "/XJ",
-    "/XD",
-    ".tmp",
     "/NP",
     "/TEE",
     "/LOG:$logPath"
   )
 
+  if ($Job.ContainsKey("ExcludeDirs") -and $Job.ExcludeDirs.Count -gt 0) {
+    $args += "/XD"
+    $args += $Job.ExcludeDirs
+  }
+
   if ($Job.ContainsKey("ExcludeFiles") -and $Job.ExcludeFiles.Count -gt 0) {
     $args += "/XF"
     $args += $Job.ExcludeFiles

ops/hermes-agent/Dockerfile

@@ -1,4 +1,4 @@
-FROM nousresearch/hermes-agent:v2026.4.16
+FROM nousresearch/hermes-agent:v2026.6.5
 
 USER root
 

ops/hermes-agent/services.json

@@ -90,16 +90,16 @@
       "notes": "ADMIN_TOKEN_FILE; keine direkten Host-Ports"
     },
     "postgresql17": {
-      "description": "Shared PostgreSQL Cluster",
+      "description": "Shared PostgreSQL 18 Cluster (historischer Containername)",
       "tier": 1,
       "category": "infra",
       "container_name": "postgresql17",
       "dependencies": [],
       "url": null,
       "dump_file": null,
-      "data_paths": ["/mnt/user/appdata/postgresql17"],
+      "data_paths": ["/mnt/user/appdata/postgresql18"],
       "first_check": "backend_net Konnektivitaet? Disk-Space auf /mnt/user/appdata? pg_isready im Container?",
-      "notes": "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg"
+      "notes": "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17 archiviert"
     },
     "komodo-core": {
       "description": "GitOps UI / API / Stack-Manager",
@@ -200,9 +200,9 @@
       "dependencies": [],
       "url": null,
       "dump_file": "immich.dump",
-      "data_paths": ["/mnt/user/appdata/immich_postgres"],
+      "data_paths": ["/mnt/user/appdata/immich_postgres_vectorchord"],
       "first_check": "immich_default Netz? Disk-Space? pg_isready?",
-      "notes": "nie ins frontend_net; immich_default Netz isoliert"
+      "notes": "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs archiviert"
     },
     "immich_redis": {
       "description": "Immich Cache",
@@ -248,7 +248,7 @@
       "dependencies": [],
       "url": null,
       "dump_file": "mealie.dump",
-      "data_paths": ["/mnt/user/appdata/mealie/postgres"],
+      "data_paths": ["/mnt/user/appdata/mealie/postgres18"],
       "first_check": "mealie_internal Netz? Disk-Space?",
       "notes": "interne DB; mealie_internal Netz"
     },
@@ -287,7 +287,7 @@
       "dependencies": [],
       "url": null,
       "dump_file": null,
-      "data_paths": ["/mnt/user/appdata/nextcloud/postgres"],
+      "data_paths": ["/mnt/user/appdata/nextcloud/postgres18"],
       "first_check": "nextcloud_internal Netz? Disk-Space?",
       "notes": "interne DB"
     },

ops/hermes-agent/services.yaml

@@ -1,7 +1,7 @@
 # services.yaml — Maschinenlesbare Wissensbasis fuer Hermes Alert Enrichment
 #
 # Abgeleitet aus docs/SERVICE_CATALOG.md
-# Stand: 2026-05-06
+# Stand: 2026-05-31
 #
 # Zweck: Hermes laedt diese Datei beim Alert-Anreichern, um Abhaengigkeiten,
 #        Dump-Zeitstempel und den ersten Diagnoseschritt nachzuschlagen.
@@ -128,7 +128,7 @@ services:
     notes: "ADMIN_TOKEN_FILE; keine direkten Host-Ports"
 
   postgresql17:
-    description: Shared PostgreSQL Cluster (Authelia, Paperless, Mail-Archiver, Mealie, Komodo indirekt)
+    description: Shared PostgreSQL 18 Cluster (historischer Containername; Authelia, Paperless, Mail-Archiver)
     tier: 1
     category: infra
     container_name: postgresql17
@@ -136,9 +136,9 @@ services:
     url: null
     dump_file: null
     data_paths:
-      - /mnt/user/appdata/postgresql17
+      - /mnt/user/appdata/postgresql18
     first_check: "backend_net Konnektivitaet? Disk-Space auf /mnt/user/appdata? pg_isready im Container?"
-    notes: "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg"
+    notes: "Dumps per Dienst unter dumps/latest; raw DB nicht primaerer Restore-Weg; alter PG17-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17 archiviert"
 
   komodo-core:
     description: GitOps UI / API / Stack-Manager
@@ -231,8 +231,8 @@ services:
     data_paths:
       - /mnt/user/appdata/paperless-gpt/data
       - /mnt/user/appdata/paperless-gpt/prompts
-    first_check: "Paperless API erreichbar? LLM/Ollama erreichbar? API Token gesetzt?"
+    first_check: "Paperless API erreichbar? OpenAI API Key gesetzt? Provider/Model auf openai/gpt-5.4-mini?"
-    notes: "API Token als Stack ENV; abhaengig von laufendem Paperless"
+    notes: "PAPERLESS_API_TOKEN und OPENAI_API_KEY als Stack ENV; kein lokaler Ollama-Zugriff"
 
   immich_server:
     description: Foto-/Video-App
@@ -261,9 +261,9 @@ services:
     url: null
     dump_file: immich.dump
     data_paths:
-      - /mnt/user/appdata/immich_postgres
+      - /mnt/user/appdata/immich_postgres_vectorchord
     first_check: "immich_default Netz? Disk-Space? pg_isready?"
-    notes: "nie ins frontend_net; immich_default Netz isoliert"
+    notes: "PG14 mit VectorChord/pgvector; nie ins frontend_net; immich_default Netz isoliert; alter immich_postgres-Pfad ist unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs archiviert"
 
   immich_redis:
     description: Immich Cache
@@ -314,7 +314,7 @@ services:
     url: null
     dump_file: mealie.dump
     data_paths:
-      - /mnt/user/appdata/mealie/postgres
+      - /mnt/user/appdata/mealie/postgres18
     first_check: "mealie_internal Netz? Disk-Space?"
     notes: "interne DB; mealie_internal Netz"
 
@@ -360,7 +360,7 @@ services:
     url: null
     dump_file: null
     data_paths:
-      - /mnt/user/appdata/nextcloud/postgres
+      - /mnt/user/appdata/nextcloud/postgres18
     first_check: "nextcloud_internal Netz? Disk-Space?"
     notes: "interne DB"
 

ops/komodo/docker-compose.yml

@@ -2,9 +2,14 @@ services:
   # ──────────────────────────────────────────────────────────────────
   # MongoDB – Datenbank fuer Komodo Core
   # Netz: komodo_net (internal: true) – niemals frontend_net
+  # ACHTUNG: Dieser Stack wird NICHT aus diesem Repo deployed. Der komodo-Stack
+  # ist in Komodo inline (file_contents) verwaltet (Bootstrap-/Self-Stack).
+  # Diese Datei ist nur Doku/Spiegel; Aenderungen hier wirken NICHT zur Laufzeit.
+  # ops/komodo/** ist in renovate.json ignorePaths. Siehe docs/RENOVATE.md.
+  # Digest = aktuell real laufender Stand (kein Renovate-Auto-Update).
   # ──────────────────────────────────────────────────────────────────
   komodo-mongo:
-    image: mongo:7.0.32@sha256:32979a1189dfdc44da3f5ed40d910495f5ad8f6f7f77556646f890a30b2d3f56
+    image: mongo:8.0.23@sha256:44aa79ae28ff80b56fe58681b66cda9336706df408a5175a6c04988aa54610d3
     container_name: komodo-mongo
     labels:
       komodo.skip:
@@ -33,7 +38,7 @@ services:
   # Admin-Dienst: bewusst ohne pauschale ForwardAuth-Middleware; dokumentierte Ausnahme
   # ──────────────────────────────────────────────────────────────────
   komodo-core:
-    image: ghcr.io/moghtech/komodo-core:2@sha256:8a7dbba232e4e49797bb412be5f78207c89fcf22cc2727b38631ae30f7518a4c
+    image: ghcr.io/moghtech/komodo-core:2@sha256:7afbcfa99674bf3f51539ec3aa7235795e9b994af9b7099a6c4c654d5d8a5b6b
     container_name: komodo-core
     init: true
     restart: unless-stopped
@@ -79,7 +84,7 @@ services:
   # Ausnahme: Docker-Socket ohne :ro (Periphery startet/stoppt Container)
   # ──────────────────────────────────────────────────────────────────
   komodo-periphery:
-    image: ghcr.io/moghtech/komodo-periphery:2@sha256:8ac9f2ef9c1461b95c862d445da00253005e7094d1e30f5b7b04b8d60ca7a3d6
+    image: ghcr.io/moghtech/komodo-periphery:2@sha256:7fb1a4807d125ce036a17d37c940b4001402afcaf342a2c720c98d096b1b54da
     container_name: komodo-periphery
     init: true
     restart: unless-stopped

ops/maintenance/check-dr-workstation-readiness.ps1

@@ -0,0 +1,95 @@
+param(
+  [string]$ReportPath = "G:\Gitea_Clone\homelab-infra\docs\audit\dr-workstation-readiness-2026-06-06.md"
+)
+
+$ErrorActionPreference = "Stop"
+
+function Invoke-Capture {
+  param([string]$Command)
+
+  $output = & cmd.exe /c $Command 2>&1
+  [pscustomobject]@{
+    Command = $Command
+    ExitCode = $LASTEXITCODE
+    Output = ($output | ForEach-Object { ([string]$_).Replace("`0", "") })
+  }
+}
+
+function Invoke-WslCapture {
+  param([string]$Bash)
+  Invoke-Capture -Command ('wsl -d Ubuntu -- bash -lc ' + '"' + ($Bash.Replace('"', '\"')) + '"')
+}
+
+$checks = [ordered]@{}
+$checks["wsl_status"] = Invoke-Capture -Command "wsl --status"
+$checks["wsl_list"] = Invoke-Capture -Command "wsl --list --verbose"
+$checks["ubuntu_os"] = Invoke-WslCapture -Bash "lsb_release -a 2>/dev/null || cat /etc/os-release; uname -r"
+$checks["tools"] = Invoke-WslCapture -Bash "command -v borg || true; borg --version 2>/dev/null || true; command -v ssh || true; ssh -V 2>&1 || true; command -v git || true; git --version 2>/dev/null || true"
+$checks["sudo"] = Invoke-WslCapture -Bash "sudo -n true >/dev/null 2>&1 && echo sudo-noprompt-ok || echo sudo-password-needed"
+$checks["wsl_ssh_files"] = Invoke-WslCapture -Bash "ls -la ~/.ssh 2>/dev/null || true; test -f ~/dr-smoke.sh && ls -la ~/dr-smoke.sh || true"
+$checks["github_dr_key_smoke"] = Invoke-WslCapture -Bash "GIT_SSH_COMMAND='ssh -i ~/.ssh/dr-readonly -o BatchMode=yes -o IdentitiesOnly=yes -o ConnectTimeout=8' git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git HEAD 2>&1 | sed -n '1,5p'"
+$checks["hetzner_dr_key_smoke"] = Invoke-WslCapture -Bash "ssh -i ~/.ssh/dr-hetzner -o BatchMode=yes -o IdentitiesOnly=yes -o ConnectTimeout=8 -p 23 u565255@u565255.your-storagebox.de 'ls' 2>&1 | sed -n '1,10p'"
+
+$borgInstalled = ($checks["tools"].Output -match "borg \d")
+$githubOk = ($checks["github_dr_key_smoke"].Output -match "HEAD")
+$hetznerOk = ($checks["hetzner_dr_key_smoke"].Output -match "hetzner_borg_appdata_critical")
+$sudoNeedsPassword = ($checks["sudo"].Output -match "sudo-password-needed")
+$drSmokeExists = ($checks["wsl_ssh_files"].Output -match "dr-smoke.sh")
+
+$lines = @()
+$lines += "# DR-Workstation Readiness - 2026-06-06"
+$lines += ""
+$lines += "Automatisch erzeugter lokaler Readiness-Check fuer den Operator-PC. Es wurden keine Secret-Werte, Passphrases oder Private-Key-Inhalte ausgegeben."
+$lines += ""
+$lines += "## Zusammenfassung"
+$lines += ""
+$lines += "| Check | Ergebnis |"
+$lines += "|---|---|"
+$lines += '| WSL2 Ubuntu | vorhanden (`Ubuntu 24.04`, WSL Version 2) |'
+$lines += "| SSH/Git in WSL | vorhanden |"
+$lines += "| GitHub-Read-Smoke mit DR-Key | " + ($(if ($githubOk) { "ok" } else { "nicht ok" })) + " |"
+$lines += "| Borg Client | " + ($(if ($borgInstalled) { "installiert" } else { "fehlt" })) + " |"
+$lines += "| Hetzner Storage Box mit DR-Key | " + ($(if ($hetznerOk) { "ok" } else { "nicht ok" })) + " |"
+$lines += '| `~/dr-smoke.sh` | ' + ($(if ($drSmokeExists) { "vorhanden" } else { "fehlt" })) + ' |'
+$lines += "| WSL sudo ohne Passwortprompt | " + ($(if ($sudoNeedsPassword) { "nein, Operator muss Passwort eingeben" } else { "ja" })) + " |"
+$lines += ""
+$lines += "## Bewertung"
+$lines += ""
+$lines += "- Der lokale WSL2-/Ubuntu-Unterbau ist vorhanden."
+$lines += '- Die DR-Key-Arbeitskopien liegen in WSL unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`.'
+$lines += "- GitHub-Read-Smoke und Hetzner-SSH-Smoke sind erfolgreich."
+$lines += '- `borgbackup` ist installiert.'
+$lines += "- Der vollstaendige Bare-Metal-DR-Smoke wartet nur noch auf die interaktive Borg-Passphrase."
+$lines += ""
+$lines += "## Naechste Operator-Schritte"
+$lines += ""
+$lines += "In Ubuntu ausfuehren:"
+$lines += ""
+$lines += '```bash'
+$lines += "bash ~/dr-smoke.sh"
+$lines += '```'
+$lines += ""
+$lines += 'Borg fragt dabei interaktiv nach der Borg-Repo-Passphrase. Diese Passphrase wurde nicht auf `baerchen` gefunden und wird bewusst nicht dauerhaft gespeichert.'
+$lines += ""
+$lines += "## Rohchecks"
+$lines += ""
+foreach ($name in $checks.Keys) {
+  $check = $checks[$name]
+  $lines += "### $name"
+  $lines += ""
+  $lines += '- ExitCode: `' + $check.ExitCode + '`'
+  $lines += ""
+  $lines += '```text'
+  $lines += ($check.Output | ForEach-Object {
+    $_ -replace ([regex]::Escape($env:USERPROFILE)), '%USERPROFILE%'
+  })
+  $lines += '```'
+  $lines += ""
+}
+
+New-Item -ItemType Directory -Force -Path (Split-Path -Parent $ReportPath) | Out-Null
+while ($lines.Count -gt 0 -and $lines[-1] -eq "") {
+  $lines = $lines[0..($lines.Count - 2)]
+}
+$lines -join "`r`n" | Set-Content -LiteralPath $ReportPath -Encoding UTF8
+Write-Host "Report written: $ReportPath"

ops/maintenance/check-external-operator.sh

@@ -0,0 +1,106 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+HOST_IP="${HOST_IP:-192.168.178.58}"
+FRITZBOX_URL="${FRITZBOX_URL:-http://192.168.178.1:49000/tr64desc.xml}"
+BORG_DB="${BORG_DB:-/mnt/user/appdata/borg-ui/data/borg.db}"
+REPO_ROOT="${REPO_ROOT:-/mnt/user/services/homelab-infra}"
+
+section() {
+  printf '\n## %s\n\n' "$1"
+}
+
+section "FRITZBox"
+if fritz_xml="$(curl -fsS --max-time 5 "$FRITZBOX_URL")"; then
+  printf '%s\n' "$fritz_xml" | grep -E '<friendlyName>|<modelName>|<Display>' | sed -E 's/^[[:space:]]+//'
+else
+  echo "FRITZBox TR-064 descriptor not reachable at $FRITZBOX_URL"
+fi
+
+if ipv6_fw="$(
+  curl -fsS --max-time 5 \
+    -H 'Content-Type: text/xml; charset="utf-8"' \
+    -H 'SOAPACTION: "urn:schemas-upnp-org:service:WANIPv6FirewallControl:1#GetFirewallStatus"' \
+    --data '<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetFirewallStatus xmlns:u="urn:schemas-upnp-org:service:WANIPv6FirewallControl:1" /></s:Body></s:Envelope>' \
+    http://192.168.178.1:49000/igd2upnp/control/WANIPv6Firewall1
+)"; then
+  firewall_enabled="$(printf '%s\n' "$ipv6_fw" | sed -n 's:.*<FirewallEnabled>\(.*\)</FirewallEnabled>.*:\1:p')"
+  pinhole_allowed="$(printf '%s\n' "$ipv6_fw" | sed -n 's:.*<InboundPinholeAllowed>\(.*\)</InboundPinholeAllowed>.*:\1:p')"
+  echo "IPv6 FirewallEnabled: ${firewall_enabled:-unknown}"
+  echo "IPv6 InboundPinholeAllowed: ${pinhole_allowed:-unknown}"
+else
+  echo "FRITZBox IPv6 firewall status not reachable via TR-064."
+fi
+
+section "Host IPv6"
+global_ipv6="$(
+  ip -6 addr show scope global \
+    | awk '/inet6 / {print $2}' \
+    | grep -Ev '^(fd|fe80:)' || true
+)"
+if [[ -n "$global_ipv6" ]]; then
+  echo "Provider/global IPv6 addresses present:"
+  printf '%s\n' "$global_ipv6"
+else
+  echo "No provider/global IPv6 address on host; only ULA/link-local/Tailscale may be present."
+fi
+tailscale ip -4 2>/dev/null | sed 's/^/Tailscale IPv4: /' || true
+tailscale ip -6 2>/dev/null | sed 's/^/Tailscale IPv6: /' || true
+
+section "DNS"
+for name in \
+  kaleschke.info \
+  vault.kaleschke.info \
+  git.kaleschke.info \
+  cloud.kaleschke.info \
+  traefik.kaleschke.info; do
+  echo "$name"
+  dig +short @1.1.1.1 "$name" A | sed 's/^/  public A    /' || true
+  dig +short @1.1.1.1 "$name" AAAA | sed 's/^/  public AAAA /' || true
+done
+
+section "Host Listeners"
+ss -ltnp | awk '
+  /:(80|443|222|53|8082|8181)[[:space:]]/ ||
+  /100\.80\.98\.33:8082/ ||
+  /127\.0\.0\.1:8181/ {print}
+' | sort -k4
+
+section "External Port Smoke"
+public_ipv4="$(curl -4 -fsS --max-time 5 https://ifconfig.co 2>/dev/null || true)"
+if [[ -z "$public_ipv4" ]]; then
+  public_ipv4="$(dig +short @1.1.1.1 kaleschke.info A | tail -n 1)"
+fi
+
+for check in \
+  "$public_ipv4 443 expected-open" \
+  "$public_ipv4 80 expected-closed" \
+  "$public_ipv4 222 expected-closed"; do
+  set -- $check
+  target="$1"
+  port="$2"
+  expected="$3"
+  if timeout 5 bash -c "cat < /dev/null > /dev/tcp/$target/$port" 2>/dev/null; then
+    result="open"
+  else
+    result="closed"
+  fi
+  printf '%s:%s %s (%s)\n' "$target" "$port" "$result" "$expected"
+done
+
+section "Borg UI Repository"
+if [[ -f "$BORG_DB" ]]; then
+  sqlite3 -header -csv "$BORG_DB" \
+    "select name,repository_type,path,remote_path,last_backup,last_check,borg_version,custom_flags from repositories order by id;"
+  sqlite3 -header -csv "$BORG_DB" \
+    "select id,repository,status,archive_name,started_at,completed_at,nfiles from backup_jobs order by id desc limit 3;"
+else
+  echo "Borg UI database not found: $BORG_DB"
+fi
+
+section "Restore Freshness"
+if [[ -x "$REPO_ROOT/ops/restore-tests/run-restore-checks.sh" ]]; then
+  "$REPO_ROOT/ops/restore-tests/run-restore-checks.sh" freshness
+else
+  echo "Restore freshness script not executable: $REPO_ROOT/ops/restore-tests/run-restore-checks.sh"
+fi