Files
mission-control-v2/docs/CUTOVER.md
T
Hitonabi 77b6dee02f docs(2.0): Phase 6d/e — Cutover-Readiness + Hermes-Tuning-Befunde
docs/CUTOVER.md: Box-Stack live (Modelle/Gateway/Hermes/Memory verifiziert),
bekannte Tuning-Punkte (Hermes-Kontext/Tool-Thrash NICHT brain-abhaengig →
Hands-on-Debug; SSH-Windows; nesquena optional), reversibler Cutover-Ablauf.
STATUS aktualisiert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-25 13:08:04 +02:00

38 lines
2.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 ~124249k Prompt-Tokens (→ 12 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.