Mission Control 2.0 — Status & Resume-Guide

So machst du jederzeit nahtlos weiter. Der vollständige Architektur-Plan liegt in C:\Users\TobisPC\.claude\plans\piped-cuddling-sloth.md (genehmigt).

Wo das Projekt lebt

Code: F:\Coding Stuff\mission-control-2 (Windows-Dev-PC) + Gitea-Remote https://git.tobisniceshomelab.ddnsfree.com/Hitonabi/mission-control-v2 (Branch main).
v1 (F:\Coding Stuff\mission-control) wird abgelöst (Cutover läuft, s.u.).
Box (Bosgame, 192.168.178.151): MC2 LIVE auf :9001 als sudo-freier systemd-USER-Dienst (~/mission-control-v2, Update via deploy/deploy.sh).

Gateway = builtin (NICHT LiteLLM)

LiteLLM verlangt Python <3.14; die Box hat nur 3.14 (uvloop+orjson scheitern). Der eingebaute Gateway (:9001/v1, OpenAI-kompatibel) liefert model:auto (kurz→fast, komplex→heavy) + Streaming und ist E2E verifiziert. Vertrag (OpenAI-API) bleibt austauschbar.

Phasen-Fortschritt

Phase 0 — Gerüst: FastAPI + React/shadcn-Shell (Cmd+K, Dark, PWA). Live auf Box.
Phase 1 — Engine + Routing: Compute (fit/caps/sources), Discover (live HF), Engine-Write (register + groups), builtin Gateway model:auto, Modelle&Routing-UI. Box-verifiziert.
Phase 2 — System/OS + Connect: Metriken, Dienste, Self-Update, Connect-Snippets → Gateway.
Phase 3 — Memory + MCP: Memory-UI, mcp_memory.py + mcp_mc.py (Stack-Management).
Phase 4 — Hermes-Schicht: Agent-Status + AgentView; Box: Hermes verdrahtet (eigenes Hirn, MCP memory+stack). hermes-webui (nesquena) = Block C offen.
Phase 5 — Betrieb/Politur: Backup, Services-Health, Observability-Links, Theme-Toggle.
W1–W8 (Audit-Arbeitspaket): Thrash-Fix, HF-Install, Rollen-UX, BEDIENUNG.md, Wartung. ✅
[~] Phase 6 — Cutover: läuft (s.u.). v1-Dashboard+Zombies weg; v1 :9000 Stop offen (User-sudo).

Hermes-Hirn (Entscheidung 2026-06-25)

Hermes hat ein eigenes festes Hirn = Hermes-4-14B (model.model: hermes, ttl 99999 = immer warm)

interne Delegation an heavy (Qwen3.5-122B) für harte Teilaufgaben. model:auto ist NUR Gateway/Vibe-Coding, nicht Hermes. Verifiziert: „bist du da?" → 3s, sauber, kein Thrash.

Box-Stand (Session 2026-06-25)

8 Modelle, Rollen sauber: 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). Legacy manager/reviewer-Aliase entfernt (Modelle bleiben per Realname ladbar).
Thrash behoben (war NICHT die Session): kaputte Tools global via agent.disabled_toolsets abgeschaltet (browser/vision/computer_use/image_gen/tts/video*/memory). Details: Memory hermes-thrash-rootcause-fix. hermes tools disable greift NICHT am api_server — nur die config.
Cutover teilweise: hermes-dashboard (:9119) disabled (killte 4 v1-MCP-Zombies); v1 mission-control.service (:9000) läuft noch → sudo systemctl disable --now mission-control.
MCP nutzt /opt/mission-control/.venv/bin/python (hat mcp-Modul) für v2-Skripte → /opt-Dir bleibt.

Nächste Schritte (siehe Plan „Nächste Schritte" + docs/CUTOVER.md)

Block C: nesquena hermes-webui (:8787) installieren → „Hermes öffnen" zeigt darauf.
Block E: Ko-Residenz hermes+fast (swap:false) testen, GTT beobachten.
User-sudo: v1 :9000 stoppen; sudoers für apt-get/reboot erweitern (OS-Update/Reboot).
Offen/user-seitig: SSH→Windows (OpenSSH am PC), v1-Passwort-Hygiene (Git-Historie).

Lokal entwickeln/verifizieren

cd backend && .venv/Scripts/python -m uvicorn app:app --port 9000   # Backend
cd frontend && npm run dev                                          # http://localhost:5173
cd frontend && npm run build                                        # Prod-Build (committet)

3.8 KiB Raw Blame History Unescape Escape