mission-control-v2/docs/CUTOVER.md

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: 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.
• 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.

Bekannte Tuning-Punkte (vor „rundem" Cutover sinnvoll, kein Blocker)

1. Hermes thrasht / Kontext-Bloat (NICHT brain-abhängig): Auf simple Prompts feuert der Agent Fehl-Tools (vision_analyze auf Text → „Bild nicht gefunden", search_files-Schleife → Eigen-Guard blockt) und injiziert ~124–249k Prompt-Tokens (→ 1–2 min/Antwort). Getestet: mit auto→Qwen3.6 UND mit coder (Qwen3-Coder-30B) — gleiches Verhalten, also kein Modell-, sondern ein Hermes- Kontext/Session/Tool-Problem (vorbestehend = das „dumm/loop" aus v1). Hands-on-Debug nötig (mit dir): (a) Session zurücksetzen/frische Session-ID (akkumulierte History?), (b) unnötige Toolsets/Skills abschalten (hermes CLI / config toolsets/platform_toolsets), v.a. Vision-Tools für reine Text-Aufgaben, (c) Kontext-/History-Limits setzen, (d) Thinking für den Agenten aus. Das Brain steht auf auto (deine Vorgabe); das ist nicht die Ursache.
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).

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).

v1 bleibt bis dahin unangetastet und lauffähig — Cutover ist reversibel.