Zum Inhalt

Seitenreview der Roadmap — 2026-08-24

Vorgehen: Kompletter kritischer Zweitdurchgang über 01-bestandsaufnahme.md + 02-zielbild-roadmap.md durch drei unabhängige Perspektiven: (1) eigener Tiefen-Reread, (2) Architektur-/Prozess-Review-Agent (frischer Blick, nur Dokumente), (3) Technik-Faktencheck-Agent (8 Kernannahmen per Web-Recherche mit Belegen verifiziert). Keine Server berührt. Ergebnis: Kein Befund kippt die Roadmap — aber 7 hohe und ~13 mittlere Findings schärfen sie deutlich. Alles Unstrittige ist bereits in 02 v2 eingearbeitet (Changelog unten); echte Diskussionspunkte stehen in §F.

A. Direkt korrigierte Dokumentfehler

  1. 02 E5 sagte „iCloud bleibt Sharing-Kanal bis E9" — gemeint ist E10 (Public-Immich). Korrigiert.
  2. 01 §8 enthielt den Leftover „Kein Lars-…-Zugang geplant" aus der Zeit vor der Klärung lars=Partner. Korrigiert.
  3. 01 Entscheidungstabelle nannte noch „Scanner→Syncthing→consume" — überholt (Scanner scannt direkt auf Share). Korrigiert.
  4. Widerspruch „Heizung VOR der Heizsaison" (Regel) vs. „E6 in Nov–Dez" (Kalender) → aufgelöst durch neues Mini-Epic E6a (§B3).

B. Die 7 wichtigsten Findings (hoch) → Änderungen in v2

B1 · Die E0-Abnahme maß nur Stille. „0 Fehlalarme in 7 Tagen" erfüllt auch eine tote Alarmkette (ntfy hatte subscribers=0 über 8 Tage!). → E0a-Abnahme verlangt jetzt Positiv-Nachweis: 1 injizierter Testalarm erreicht Robins iPhone, subscribers ≥ 1 dauerhaft, je gefixtem Defekt 1 provozierter Fehler.

B2 · Automerge + Auto-Deploy hätten scharf geschaltet, solange das Monitoring strukturell blind ist (E2 vor E3; ContainerDown feuert praktisch nie, kein externer Dead-Man). → Gestuft: Monitoring-Notpflaster schon in E1 (ContainerDown je Container, externer Dead-Man-Switch), Automerge startet patch-only, Minor-Automerge erst nach bestandener E3-Abnahme; stateful Apps (Immich, HA, Paperless, DBs) bleiben bei Minor manuell; Kuma/Healthchecks werden bei Renovate eingefroren (E3 ersetzt sie — tote Investition vermeiden).

B3 · Heizung wäre mitten in der Heizsaison gelandet. → Neues vorgezogenes Mini-Epic E6a „Heizung vor dem Winter" (Sept/Okt), mit Voraussetzungen Mosquitto-Auth (jetzt E0a) + Zigbee-Netz-Analyse + Hardware-Inventur in E0c (unklar, ob smarte Thermostate vorhanden sind — ggf. Bestellung VOR der Saison; → Frage §F2).

B4 · Bus-Faktor Robin war komplett unadressiert. Nach E5/E10 lägen die Familienfotos in Systemen, die nur Robin bedienen kann; Borg-Passphrase nur in Robins Proton Pass. → Neues E1-Pflicht-Item „Notfallzettel & Zugriffs-Teilung": Emergency-Access/geteilter Zugang für Borg-Passphrase + Kernzugänge, 1-Seiten-Runbook für Lars (Fotos erreichen, Heizung manuell, wer hilft), TRV-Handbetrieb dokumentiert. Abnahme: Lars spielt es einmal real durch. Hartes Gate vor E5-Abschluss und vor der iCloud-Kündigung (E10).

B5 · E0 („~1 Woche", ~25 Posten) und E2 (6 Großbausteine) reproduzierten exakt das Liegenbleiber-Muster. → E0 in E0a/E0b/E0c, E2 in E2a–E2d geschnitten — jede Scheibe separat abschließbar (viele „fertig!"-Momente). NUT-Forensik auf 2 h getimeboxt (danach Workaround + Issue). Kalender ehrlich gestreckt (§ unten), fester Re-Schätz-Punkt nach E1. „SSD < 40 %" ist Richtwert, kein Blocker mehr (immich-import-Verifikation kann als E5-Issue laufen).

B6 · Host-OS-Lifecycle fehlte völlig. Renovate/doco-cd aktualisieren nur Container — niemand patcht die drei Ubuntu-Hosts, und NUC-22.04 erreicht April 2027 das Support-Ende. → Neuer E2b-Baustein „Host-Updates as Code" (unattended-upgrades, Reboot-Fenster, Reboot-Pending-Alert in E3) + terminierter Entscheid fürs 22.04→24.04-Upgrade.

B7 · Drei bekannte Backup-Fallen waren unbenannt. (a) Fotos liegen hinter einem NFS-Mount mit Ausfall-Historie — ist der Mount weg, sichert borgmatic „erfolgreich" ein leeres Verzeichnis → Mount-Guard ist jetzt E1-Pflicht (inkl. Test: Mount weg ⇒ Fehler statt leerem Archiv). (b) Offsite-Klumpenrisiko → StorageBox-Sub-Account je Host + automatische tägliche Snapshots (siehe Faktencheck D3 — der eigentliche Ransomware-Schutz; append-only gestrichen). (c) Sichern ≠ Wiederaufbauen → Rebuild-Runbook je Host als E1-Deliverable (der bootstrap.sh-Befund hatte keine Epic-Heimat); Restore-Probe jetzt quartalsweise wiederkehrend. Dazu: Dimensionierung nach iCloud-IST beider Bibliotheken (jetzt ablesen), beide Ziele (auch TR-004) auf Kapazität prüfen, Snapshots zählen gegen die Box-Kapazität → nicht auf Kante dimensionieren.

C. Weitere Nachschärfungen (mittel, in v2 eingearbeitet)

  • Sicherheit E0a: CF-DNS-Token wird rotiert, nicht nur verschoben (History behält ihn ja) · lldap-UI stand monatelang offen im Netz → IR-Check (Logs auf fremde Logins, Admin-PW-Rotation) · Quick-Wins nach Risiko statt Thema vorgezogen: Mosquitto-Auth #81, Open WebUI (erst Admin-Konto anlegen, DANN Signup zu — sonst Aussperrung), pkv-app #48 bekommt eine Issue-Heimat · DERP/STUN-Fix eingeplant (Direktverbindungs- Qualität = Lars' Foto-Uploads!) · BFG/History-Rewrite mit Host-Clones/doco-cd koordinieren.
  • E5 ehrlich umbenannt: „Immich wird Familien-Primärsystem" — der eigentliche Exit (Kündigung) ist E10. Kündigungs-Kriterien dort explizit: realer Test mit Dritt-Empfänger (sind Immich-Links für Oma/Freunde wirklich ok?) + Lars-Gate + externer Scan. E10-Design prüft, ob Public-Immich wirklich VLAN voraussetzt oder isoliert früher gehen kann.
  • Appliance-Konfig-Backups (UDM, UNAS, ESPHome, Zigbee-Coordinator + Netzwerk-Key — sonst heißt Coordinator-Tod: alles neu anlernen) in E1; UDM-Backup = hartes Eingangskriterium für E9.
  • Lars-Geräte ins Tailnet ist jetzt ein frühes eigenes Issue (Abnahme: 1 Woche unfallfreier Auto-Upload) — stand vorher nur in der Leitplanken-Tabelle, in keinem Epic.
  • doco-cd gehärtet: selbst digest-gepinnt & nie automerged (0.x!), Rollback-Drill (Revert→Redeploy) in der E2c-Abnahme, dokumentierter Exit-Pfad (manueller Deploy bleibt beschrieben), Socket-Exposition prüfen, Scheduled-Jobs-Feature meiden (offener Bug #1674).
  • Abnahmen geschärft: E4 = Nutzungsmetrik über 2–4 Wochen (llama-swap-Ladehistorie, beide Nutzer) statt „1 Aufgabe lief mal" · E9 = Erreichbarkeits-Testmatrix + Rollback-Kriterium · E10 = externer Port-/Vuln-Scan + Auth-Bypass-Test + CrowdSec-Nachweis VOR der Kündigung.
  • Session-Ritual bekommt einen Park-Ausstieg: „nicht fertig" ist legitim — 2-Min-Statuskommentar aufs Issue (Stand + nächster Schritt) zählt als sauberes Ende. Sonst stirbt das Ritual an seiner eigenen Strenge.
  • Issues lazy statt Board-Flut: Board führt Epics + nur das aktive Epic granular; die 01-Doku bleibt Backlog-Referenz (kein 50-Issue-Schock am Tag 1).
  • Immich-ML → aiserver wird fest in E4 evaluiert (VOR dem E5-Massenimport — der würde sonst die ML-Last auf den NUC mit 100 % Swap feuern, während 128 GB daneben idlen). D1 hängt jetzt am Trigger „~4 Wochen Stromdaten" statt am Kalender.
  • gitleaks/Secret-Scanning in prek+CI (E2a) — der Rückfallschutz gegen das 8-Klartext-Secrets-Problem fehlte in der CI-Liste · SMART/Disk-Health (NUC-SSD, TR-004 hinter USB-Bridge, UNAS) explizit in der E3-Designliste · Grafana-InfluxDB-Token-Bug bleibt bewusst offen bis E3 (Ablösung wird eh geprüft — jetzt dokumentiert statt vergessen) · doco-cd-Go-Live ändert die Betriebsregel „NUC-Writes macht Robin selbst" → Regel-/Memory-Update ist Teil der E2d-Abnahme · Design-Sessions enden mit geschnittenen Issues auf dem Board.

D. Faktencheck-Ergebnisse (8 Kernannahmen, mit Belegen geprüft)

# Annahme Ergebnis
D1 HA + OIDC ⚠️ Kein natives OIDC in HA-Core (Stand 2026). De-facto-Standard: Custom-Integration christiaangoossens/hass-oidc-auth (aktiv, v1.1.1 06/2026, Authelia-Guide, Companion-App via Device-Code-Flow). Forward-Auth vor HA bricht die Companion-App → ausgeschlossen. E8/E10 entsprechend umformuliert; vor E8 Stand neu prüfen (HA-Team kündigt eigene Lösung an).
D2 Gatus (E3-Favorit) ✅ External Endpoints + heartbeat.interval (seit v5.23, aktuell v5.36) = exakt der Backup-Dead-Man; ntfy nativ; alles YAML im Repo. Solo-Maintainer (Tempo 2026 verlangsamt, liefert aber).
D3 StorageBox-Schutz ⚠️ Append-only ist auf der StorageBox nicht serverseitig erzwingbar + kollidiert mit prune/compact → gestrichen. Automatische Snapshots sind der Schutz: read-only unter /.zfs/snapshot, per SSH/SFTP NICHT löschbar (getrennte Credential-Domäne Console/Robot), täglich + max. Slots (BX21/5TB = 20). Zählen gegen Kapazität!
D4 Immich-Semver ✅ Seit v2.0 offiziell Semver („breaking only in majors"); automerge patch+minor vertretbar (nächtliche DB-Dumps als Netz, Automerge-Fenster nach dem Backup-Lauf); Majors (~1/Jahr, aktuell →3.x) manuell mit Backup.
D5 doco-cd ✅ Polling/Infisical-EU/Apprise bestätigt, mehrere Stacks pro Host = Kern-Feature, kein Show-Stopper. Bleibt 0.x mit sehr hoher Kadenz + Bus-Faktor 1 → Härtungen aus §C. Scheduled-Jobs-Bug #1674 meiden.
D6 Headscale-OIDC ⚠️ Keine User-Migration möglich → alle ~5 Nodes neu registrieren (neue OIDC-User, ACLs prüfen). only_start_if_oidc_is_available ist per Default true → Start-Zirkel mit Authelia auf demselben Host → auf false + Startreihenfolge + Runbook. Break-Glass: Pre-Auth-Keys via CLI bleiben. node.expiry bewusst wählen (90–180 d).
D7 iOS-VPN + Foto-Backup ⚠️ Machbar, aber iOS-Hintergrund-Upload ist prinzipbedingt „holt nach" statt „sofort" (BGAppRefresh; App nie force-quitten; gelegentlich öffnen). E5-Abnahme entsprechend formuliert; E10 löst die VPN-Abhängigkeit später ohnehin.
D8 Paperless v3 KI ✅ v3 (07/2026) hat native KI (Titel/Tags/Typ/Datum + RAG-Chat) mit openai-like-Backend → llama-swap direkt anbindbar. paperless-gpt nur noch nötig, falls Vision-OCR gewünscht (natives Remote-OCR = nur Azure). E7-Rechercheauftrag damit im Kern erledigt → ein Container weniger.

E. Bewusst NICHT geändert (geprüft und für richtig befunden)

  • Reihenfolge-Grundgerüst (E1 vor allem Großen · Toil-Killer früh · VLAN vor Public · Familie sobald Fundament) hält.
  • Automerge + GitOps kommen — nur gestuft (B2), nicht gestrichen. doco-cd bleibt — nur gehärtet.
  • HC-SMTP-Fix in E0a lohnt trotz E3-Ablösung (2 Monate Interims-Alerting).
  • E5/E10-iCloud-Logik war konsistent (E5 = Primärwechsel, E10 = Kündigung) — nur Benennung/Tippfehler geschärft.
  • „Max. 1 aktives Bau-Epic" + überlappende Wartephasen: bestätigt, jetzt mit E6a als bewusster Ausnahme (klein, saisonkritisch).

F. Offene Punkte für Robin (bitte beim Gegenlesen mitentscheiden)

  1. homelab-external-Repo public lassen? (Katalog-Frage #8 — wurde in keiner Runde entschieden. Nach Rotation vertretbar, aber bewusst entscheiden: public = Lernen in der Öffentlichkeit, private = weniger Angriffsfläche/Scanner-Rauschen.)
  2. Heizungs-Hardware: Sind smarte Thermostate (TRVs) vorhanden — welche, wie viele Räume? Falls Kauf nötig: vor der Saison bestellen (E6a hängt daran).
  3. Automerge-Stufung ok? (patch sofort nach E2, minor erst nach bestandener E3-Abnahme, stateful-Apps manuell — leicht konservativer als deine Runden-Entscheidung.)
  4. Notfallzugang für Lars (B4): Proton-Pass-Emergency-Access, geteilter Bitwarden-Eintrag oder Papier im Ordner — was passt zu euch?
  5. Kalender-Streckung ok? (E0–E2 realistisch bis Ende Okt statt Ende Sept; iCloud-Kündigung ~Q2/27. Reihenfolge schlägt Termin — aber die Termine sollen ehrlich sein.)
  6. D1 früher (sobald ~4 Wochen Stromdaten da sind, ggf. parallel zu E5) statt Dez–Jan — ok?

G. Changelog 02 v1 → v2 (Kurzliste)

E0→E0a/E0b/E0c (+Positiv-Nachweis, Quick-Wins nach Risiko, NUT-Timebox, DERP/STUN, Heizungs-Inventur) · E1 +Mount-Guard, +Monitoring-Notpflaster (ContainerDown/Dead-Man), +Sub-Accounts & Snapshots, +Appliance-Backups, +Rebuild-Runbooks, +Notfallzettel/Lars-Gate, +Lars-Geräte-Issue, +Quartals-Probe, Dimensionierung nach iCloud-IST · E2→E2a–E2d (+gitleaks, +Host-Updates-as-Code, +doco-cd-Härtung, Automerge gestuft, Kuma/HC eingefroren, Regel-Update „Robin deployt") · E3 +SMART, +Reboot-Alert, Gatus-Favorit bestätigt · E4 Abnahme=Nutzungsmetrik, +Immich-ML-Eval · E5 umbenannt, E9→E10-Fix, iOS-Erwartungsmanagement, Lars-Gate · E6a Heizung vorgezogen; E6-Abnahme +Lars-Zufriedenheit · E7 auf v3-native-KI umgestellt · E8 hass-oidc-auth + Headscale-Vorkehrungen · E9 +UDM-Backup-Eingangskriterium, +Abnahme · E10 +Kündigungs-Kriterien/Scans, +VLAN-Entkopplungs-Prüfung · D1 trigger-basiert · Ritual +Park-Ausstieg, Issues lazy · Kalender gestreckt + Re-Schätz-Punkt nach E1.

H. Nachtrag: Robins Gegenlese-Punkte (24.08., während des Reviews)

H1 · „Claude-Code-Client gar nicht bedacht" — berechtigt. Der Laptop ist die Schaltzentrale des ganzen Betriebsmodells (Session-Ritual, Runbooks, Skills, Memory), war aber nur als verstreute E0-Stichpunkte drin — und zwei Lücken fehlten ganz: der Planungsordner selbst liegt unversioniert & ungesichert nur lokal, und niemand hat die Frage „Was liegt eigentlich NUR auf dem Laptop?" gestellt. → v2: eigene Leitplanke „Steuerstand" + ausgebauter E0c-Block (claude-code-setup als Single Source, ~/.claude inkl. Memory-Verzeichnis versionieren/sichern, Skill-Fix, HA-MCP, Planungs-Docs in die Doku-Drehscheibe, Laptop-Inventurfrage) + Dauerläufer „Steuerstand-Pflege". Die Werkzeug-Ebene wächst pro Epic mit (Abschluss-Ritual „Doku/Skill aktualisiert" deckt das ab — z.B. bringt E6 die ha-mcp-Anbindung mit).

H2 · „K8s unbeantwortet?" — Ist entschieden, und zwar von dir (Runde 0): bewusst kein K8s im Homelab (Migrationsaufwand + bräuchte ≥3 Nodes; K8s bleibt Lern-/Job-Thema, k3s-hetzner inaktiv). Stand als Leitplanke „Compose bleibt" schon in v1 — die Begründung ist in v2 jetzt sichtbar in der Tabelle. Wenn du das NICHT als final betrachtest, sag es — dann wird es ein expliziter D1-Prüfpunkt.

H3 · „Server neu sortieren — wo?" — Das ist genau D1 (Architektur-Review): bewusst datengetrieben NACH ein paar Wochen Strommessung (E3), damit die Diskussion NUC-vs-aiserver-vs-UNAS auf Zahlen statt Bauchgefühl steht. Im Review vorgezogen: D1 hängt jetzt am Trigger „~4 Wochen Stromdaten" (statt fix Dez–Jan) und die dickste Einzelfrage (Immich-ML auf den aiserver?) wird schon in E4 evaluiert, VOR dem E5-Massenimport. In v2 trägt D1 jetzt ausdrücklich den Titel-Zusatz „beantwortet die Frage Server-Neusortierung".

I. §F beantwortet (Robin, 24.08.) → 02 v3

Alle sechs offenen Punkte sind entschieden (Details + Wortlaut: 01 §8 „Gegenlesen-Runde"): Repo → privat · Heizung läuft seit 2 Saisons, E6a = Sensor-Integration statt Greenfield · Automerge-Stufung ✓ · Notfallzugang → Break-Glass-Konzept für alle Systeme (Form in E1-Design) · Kalender → keine Streckung, Jahresend-Ziel 2026 (mit Sicherheitsventil + Re-Schätz-Punkt) · D1 → vorgezogen (direkt nach E1, Placement-Fokus statt Stromdaten-Trigger; neu darin: die Externer-Server-Frage — Hetzner behalten / SaaS-Substitution / Anbieterwechsel, Kandidat hosting.de). Neu beantwortet außerdem: kein eigener APT-Mirror — stattdessen Ubuntu-Release-Harmonisierung (E2b).