Files
mission-control-v2/docs/STATUS.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

5.6 KiB
Raw Blame History

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) bleibt unangetastet bis zum Cutover.
  • Box (Bosgame, 192.168.178.151): MC2 LIVE auf :9001 als sudo-freier systemd-USER-Dienst (~/mission-control-v2, Update via deploy/deploy.sh). Verifiziert gegen echtes llama-swap: 6 Modelle inkl. Caps, GPU/GTT (133 GB) + Temps, Services-Health. Parallel zu v1 (unangetastet).

Phasen-Fortschritt

  • Phase 0 — Gerüst: FastAPI (/api/health,/api/models) + React/shadcn-Shell (Cmd+K, Dark, PWA). Verifiziert.
  • Phase 1 — Engine + Routing: Compute-Module (fit/caps/sources), Discover (live HF), Engine-Write (register + groups/Ko-Residenz), LiteLLM-Gateway-Config + Service, Frontend Modelle&Routing (Caps-Chips, Fit, Discover-Tab, Routing-View). Lokal verifiziert (Backend-Smoke + Frontend-Build + Browser).
  • Phase 2 — System/OS + Connect: System-Status (psutil CPU/RAM/Disk, sysfs GPU/Temp guarded), Wartung (restart/self-update als systemd-USER-Dienst, sudo-frei), Connect-Snippets (Cline/OpenCode/ Zed/Continue/Claude Code/Memory-MCP → Gateway model:auto + LAN-IP-Override). Lokal verifiziert.
  • Phase 3 — Memory + MCP: Memory-Service (SQLite/WAL, 5 Kategorien, Dedupe-Kurator), Router (CRUD/export/dedupe), mcp/mcp_memory.py (Guard-Beschreibungen gegen Loop) + mcp/mcp_mc.py NEU (Stack-Management-Tools für Hermes: list/discover/register/route/restart/status). Frontend MemoryView (Add/Filter/Suche/Delete/Aufräumen). Lokal verifiziert (CRUD+Dedupe; MCP syntax-OK).
  • [~] Phase 4 — Hermes-Schicht: MC-Seite (services/agent.py + /api/agent/status, AgentView mit Status-Tiles + „Hermes öffnen"), deploy/hermes-webui.service, Runbook docs/HERMES_SETUP.md. Box-Ausführung offen (hermes-webui installieren, Brain=auto, Tools/MCP verdrahten — Runbook).
  • Phase 5 — Betrieb/Observability/Politur: Backup (Memory-SQLite + Configs, retain 7; /api/system/backup + deploy/backup.sh), Services-Health (/api/system/services), Observability- Links (llama-swap /ui, Gateway), Theme-Toggle Hell/Dunkel. Lokal verifiziert.
  • Phase 6 — Cutover (/opt → v2, v1 aus). Braucht Box.
  • Offen aus Phase 0/1: Box-Deploy (Gitea-Repo da; Box-Setup als systemd-USER-Dienst noch offen), LiteLLM Complexity-Auto-Router gegen installierte Version verifizieren.

Lokal entwickeln/verifizieren

# Backend
cd backend && .venv/Scripts/python -m uvicorn app:app --port 9000
# Frontend (Dev)
cd frontend && npm run dev          # http://localhost:5173 (proxyt /api → :9000)
# Frontend (Build → wird vom Backend ausgeliefert, committet)
cd frontend && npm run build

API (Stand Phase 1)

  • GET /api/health — Status + engine/gateway reachable
  • GET /api/models — installierte Modelle inkl. capabilities
  • GET /api/discover[?force=1] — beste Modelle je Kategorie (live HF, Fit, Caps, recommended)
  • GET /api/fit?params_b=&quant=&ctx=&name= — Hardware-Fit-Schätzung
  • POST /api/models/register — GGUF als llama-swap-Modell eintragen (cmd + Rolle-Alias, optional jinja)
  • GET/PUT /api/groups — llama-swap-groups (Ko-Residenz swap:false)
  • GET /api/routing, PUT /api/routing/route — LiteLLM-Gateway-Mapping
  • GET /api/system/status — CPU/RAM/GPU/Disk/Temp
  • POST /api/system/restart (Whitelist), POST /api/system/self-update — Wartung (Box, sudo-frei)
  • GET /api/connect?host= — IDE-/Agent-Snippets (Gateway + Memory-MCP)
  • GET/POST/PUT/DELETE /api/memory[...] + /api/memory/export + /api/memory/dedupe — geteiltes Gedächtnis
  • mcp/mcp_memory.py (geteiltes Memory) + mcp/mcp_mc.py (Stack-Management für Hermes) — stdio-MCP
  • GET /api/agent/status — Hermes Gateway/WebUI-Erreichbarkeit + Verdrahtungs-Hinweise

Box-Stack LIVE (Phase 6 ausgeführt) — Stand & Cutover: siehe docs/CUTOVER.md

  • Modelle fast (Qwen3.6-35B-A3B) + heavy (Qwen3.5-122B-A10B) geladen & lauffähig.
  • Eingebauter Gateway :9001/v1 model: auto (fast↔heavy) — E2E verifiziert.
  • Hermes: Brain via Gateway, MCP (memory+stack) verdrahtet, Memory vereinheitlicht (v1-DB, 16 Einträge).
  • Offene Tuning-Punkte (kein Blocker): Hermes-Agent-Brain für die Loop (Qwen3.6 thrasht → coder empfohlen), SSH→Windows (Windows-seitig), nesquena-WebUI optional. Details: docs/CUTOVER.md.

Nächster sinnvoller Schritt (user-gated — braucht dich / Downloads / Entscheidungen)

Phasen 05 sind fertig und MC2 läuft live auf der Box (:9001). Es bleiben bewusst von dir auszulösende Schritte (schwere Downloads, Passwörter, Eingriff in die laufende v1/Hermes-Produktion):

  1. Hirne laden (~90 GB): Qwen3.6-35B-A3B (fast, --jinja) + Qwen3.5-122B-A10B (heavy) eintragen
    • Gruppe brains (swap:false). UI: Modelle & Routing → http://192.168.178.151:9001.
  2. LiteLLM-Gateway installieren/starten (docs/HERMES_SETUP.md §1), model:auto verifizieren.
  3. Hermes-Schicht verdrahten (docs/HERMES_SETUP.md): hermes-webui + Passwort, Brain=auto, Tools/MCP (mcp_mc+mcp_memory), SSH→Windows.
  4. Cutover (Phase 6): wenn v2 dir reicht — v1 stilllegen, v2 ggf. auf den Hauptport. (Aktuell läuft v2 risikofrei parallel auf :9001, v1 unangetastet.)