# Roadmap: sauberer KI-Host

## Phase 0 – Entscheidungen und Freigaben

- VPN-Nutzung mit der Universität abstimmen.
- Eindeutige Netze und Heim-WireGuard-Peer festlegen.
- Festplattenverschlüsselung und Remote-Unlock entscheiden.
- Repository- und Secret-Backup prüfen.

## Phase 1 – Grundsystem

- Debian 13 minimal und OpenSSH installieren.
- Firmware/BIOS und beide NVIDIA-Karten prüfen.
- Updates, Zeitsynchronisation und administrativen Zugang testen.

## Phase 2 – automatischer Bootstrap

- `config/install.env` ausfüllen.
- `install.sh` ausführen, bei Treiberinstallation neu starten und wiederholen.
- WireGuard-Peer zuhause ergänzen.
- Docker-, GPU- und Fail-Closed-Netztest bestehen.

## Phase 3 – Inferenz abnehmen

- Fast/Medium/Long mit derselben Testserie messen.
- Kontext, Prompt-Speed, Ausgabe-Speed und VRAM dokumentieren.
- RTX 3060 zuerst nur im Experimentalprofil testen.
- Erst nach Qualitäts- und Geschwindigkeitsvergleich Produktionswerte ändern.

## Phase 4 – optionale Fähigkeiten

- Zentrale MCP-Werkzeugebene gemäß `ARCHITECTURE.md` aufbauen.
- Schlanken `mcp-gateway` nur über WireGuard veröffentlichen.
- `web-mcp` als unabhängigen Standard-Werkzeugcontainer betreiben.
- Home Assistant als getrennte Read-/Write-Instanzen desselben Images.
- Den vorhandenen kompakten `homeassistant-admin-mcp` zum zentralen
  Streamable-HTTP-Werkzeugcontainer ausbauen. Er soll dem Modell kleine,
  eindeutige Werkzeuge anbieten und den nativen Home-Assistant-MCP intern als
  Datenquelle beziehungsweise Fallback verwenden, statt dessen sehr großen
  Werkzeugkatalog direkt an jedes Modell durchzureichen.
- YAML-Unterstützung für Home Assistant ergänzen: zunächst lesen und
  validieren; Änderungen ausschließlich über Diff/Vorschau, Sicherung,
  Konfigurationsprüfung und explizite Freigabe. Keine freie Host-Shell und kein
  ungeprüftes Überschreiben von Konfigurationsdateien.
- Den Admin-MCP anschließend gemeinsam für Open WebUI, Hermes und weitere
  Clients anbieten; Read-only und Write/Approval bleiben getrennte Profile.
- ARR als getrennte Read-/Write-Instanzen mit Preview/Approval.
- Unraid-Diagnose und bewusst aktivierbare Administration trennen.
- Terminal ausschließlich als isolierten `sandbox-mcp`, nie als Host-Shell.
- Open WebUI, Hermes und weitere Clients mit denselben zentralen Endpunkten
  verbinden und pro Chat nur benötigte Werkzeuggruppen aktivieren.
- Piper-TTS als eigener interner CPU-Container; Whisper oder Bildgenerierung
  bei Bedarf ebenfalls jeweils als eigener Container.

## Phase 5 – Betrieb

- Open-WebUI-Volume, Konfigurationen und Secrets verschlüsselt sichern.
- Image- und llama.cpp-Upgrades im Experimentalprofil testen.
- Logs ohne Prompts/Secrets, Metriken für GPU, RAM und Tokenraten.
- Recovery auf leerem Testsystem regelmäßig proben.

Fertig ist der Host erst, wenn er sich aus Repository und Secret-Backup neu
erzeugen lässt, das Uni-Netz keine KI-Ports sieht, ein Tunnelverlust
fail-closed ist und alle drei Profile den Standardbenchmark bestehen.