# Cutover — Stand & Anleitung

## Was auf der Box LÄUFT (verifiziert)
- **MC2** auf `:9001` (sudo-freier User-Dienst, `~/mission-control-v2`). Update: `deploy/deploy.sh`.
- **Modelle/Rollen:** `fast` = Qwen3.6-35B-A3B, `heavy` = Qwen3.5-122B-A10B, `coder` = Qwen3-Coder-30B,
  `vision` = Qwen3-VL-8B, `scout` = Qwen3-8B, `hermes` = Hermes-4-14B (immer warm, ttl 99999). Alle
  tool-fähig (`--jinja` wo nötig). Legacy `manager`/`reviewer` entfernt.
- **Gateway (eingebaut, `:9001/v1`, OpenAI-kompatibel):** `model: auto` → kurz/Standard = `fast`,
  lang/komplex = `heavy`. End-to-End verifiziert.
- **Hermes:** **eigenes festes Hirn = Hermes-4-14B** (`model.model: hermes`) + **Delegation an `heavy`**.
  `model:auto` ist NUR für Vibe Coding/IDEs, nicht Hermes. MCP verdrahtet: `mission-control-memory` +
  `mission-control-stack`. Verifiziert: „bist du da?" → 3s, sauber, kein Thrash.
- **Gedächtnis vereinheitlicht:** MC2 nutzt die bestehende DB (`mission-control-memory.db`) — geteilte
  „Verfassung" für Cockpit, Hermes, IDEs.
- **Cockpit-Features:** HF-Link/Suche-Install (W2), Rollen/ctx/löschen-UX (W3), Wartung (W8: OS/Engine-
  Update, Restart, Reboot, Logs, dyn. Modell-Upgrades), Bedien-Anleitung (BEDIENUNG.md + Hilfe-Link).

## Thrash-Fix (war der „Hermes ist dumm"-Grund)
Ursache war NICHT das Modell/die Session, sondern **kaputte/Cloud-Tools im Toolset** (browser ohne Chrome
→ Loop, vision auf Text, natives memory falsch aufgerufen). Global abgeschaltet über
`agent.disabled_toolsets` in `~/.hermes/config.yaml` (Achtung: `hermes tools disable` greift nur cli,
NICHT den api_server). Natives memory zusätzlich aus (`memory.memory_enabled:false`); geteiltes
Gedächtnis bleibt via MCP. Behaltene Tools: web/terminal/file/code_execution/skills/todo/session_search/
clarify/delegation/cronjob + 2 MCP.

## Cutover-Schritte
1. v2 läuft bereits auf `:9001` parallel — alles dort testen: `http://192.168.178.151:9001`.
2. Vibe-Coding-Tools auf den Gateway zeigen (Verbinden-Tab → `:9001/v1`, `model: auto`).
3. **v1 stilllegen** — bereits erledigt: `hermes-dashboard` (:9119) disabled (killte 4 v1-MCP-Zombies).
   **Noch offen (braucht dein sudo, NOPASSWD deckt nur `restart`):**
   ```
   sudo systemctl disable --now mission-control      # v1-Cockpit :9000 aus
   ```
   `llama-swap` (System) + `hermes-gateway` (User) bleiben — die nutzt v2 weiter.
4. Optional v2 auf den „Haupt"-Port legen — `MC_PORT` in der mc2-Unit.
5. Backup vorher: Cockpit → System → „Backup jetzt".

## Offene Tuning-/Setup-Punkte (kein Blocker)
1. **nesquena hermes-webui** (:8787) installieren (Plan Block C) → „Hermes öffnen" zeigt darauf statt :9119.
2. **Ko-Residenz** `hermes`+`fast` (swap:false, Plan Block E) — GTT beobachten, bei OOM-Nähe zurück.
3. **SSH→Windows** (voller PC-Zugriff): OpenSSH-Server am Windows-PC + Key `id_ed25519_hermes_agent`.
4. **sudoers erweitern** (`apt-get`, `reboot`) → OS-Update/Reboot klicki-bunti (Zeilen in BEDIENUNG.md).
5. **Delegation an heavy** ist konfiguriert; triggert modell-diskretionär bei echt harten Teilaufgaben.

> v1 bleibt bis zum `disable` lauffähig — Cutover ist reversibel (`sudo systemctl enable --now mission-control`).