docs: sync status, hermes setup, and cutover docs with box reality

docs/CUTOVER.md

@@ -2,37 +2,44 @@
 
 ## Was auf der Box LÄUFT (verifiziert)
 - **MC2** auf `:9001` (sudo-freier User-Dienst, `~/mission-control-v2`). Update: `deploy/deploy.sh`.
-- **Modelle:** `fast` = Qwen3.6-35B-A3B (21 GB, lädt in ~6 s) + `heavy` = Qwen3.5-122B-A10B (77 GB,
-  lädt in ~32 s). Beide tool-fähig (`--jinja`). Plus die bestehenden coder/vision/scout.
+- **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 (short→fast, keyword→heavy lädt + antwortet).
-- **Hermes:** Brain = `model: auto` über den Gateway (provider `custom`, `:9001/v1`). MCP verdrahtet:
-  `mission-control-memory` + `mission-control-stack` (mcp_mc). Antwortet.
-- **Gedächtnis vereinheitlicht:** MC2 nutzt die bestehende v1-DB (`mission-control-memory.db`,
-  16 Einträge) — eine geteilte „Verfassung" für Cockpit, Hermes, IDEs.
+  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).
 
-## Bekannte Tuning-Punkte (vor „rundem" Cutover sinnvoll, kein Blocker)
-1. **Hermes-Thrash → BEHOBEN (W1).** Ursache war eine **vergiftete Dauer-Session** (mein Test hatte sie
-   mit einem Vision-Fehl-Lauf verseucht; Hermes fütterte sie jeden Zug erneut → ~249k Tokens, Vision-auf-
-   Text, Such-Schleifen). **Verifiziert:** frische Session = sauber & kohärent, **34k statt 249k**,
-   keine Fehl-Tools. Maßnahmen: `code_execution.max_tool_calls` 50→20 (Schleifen-Bremse); **History
-   unangetastet** (64 Sessions/1048 Msgs bleiben — Hermes' Gedächtnis). Sessions reseten ohnehin täglich
-   (4 Uhr) / nach 24 h idle; das WebUI nutzt pro Chat eine eigene Session. **Speed:** Gateway schaltet
-   auf der `fast`-Spur **Thinking aus** (Qwen3.6) → bare Gateway-Antwort ~10 s, direkt.
-   **Rest-Tuning (mit dir, optional):** Hermes' erste Nachricht dauert noch ~60–90 s wegen **34k Basis-
-   Kontext** (Tool-Schemas + 26 Skills) + Agent-Loop. Hebel: unnötige Toolsets/Skills prunen
-   (`config toolsets`/`platform_toolsets`, 26 Skills sichten) → schlankerer Prompt = schnellerer Agent.
-2. **SSH→Windows (voller PC-Zugriff):** Windows-seitig OpenSSH-Server aktivieren + Key
-   `id_ed25519_hermes_agent` autorisieren (vom Box-Host aus). Erst dann erreicht Hermes' Shell den PC.
-3. **hermes-webui (nesquena) standalone:** optional — aktuell läuft das eingebaute `hermes-dashboard`.
-   Für die reichere Oberfläche `docs/HERMES_SETUP.md` §3 (Port 8787, Passwort).
+## 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 (wenn v2 dir reicht)
-1. v2 läuft bereits auf `:9001` parallel — teste alles dort: `http://192.168.178.151:9001`.
-2. Vibe-Coding-Tools auf den Gateway zeigen (Verbinden-Tab liefert Snippets → `:9001/v1`, `model: auto`).
-3. **v1 stilllegen:** `systemctl --user stop hermes-dashboard` (nur wenn nesquena/anderes übernimmt) und
-   den alten Mission-Control-Dienst deaktivieren. llama-swap + hermes-gateway bleiben (von beiden genutzt).
-4. Optional v2 auf den „Haupt"-Port legen (z.B. 9000) — `MC_PORT` im Unit ändern.
-5. Backup vorher: Cockpit → System → „Backup jetzt" (sichert Memory-DB + Configs).
+## 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".
 
-> v1 bleibt bis dahin unangetastet und lauffähig — Cutover ist reversibel.
+## 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`).