Files
mission-control-v2/docs/STATUS.md
T
Hitonabi 6c8b6d81fe feat(2.0): Phase 2 — System/OS + Connect
System: services/system.py (psutil CPU/RAM/Disk, sysfs GPU/Temp guarded),
routers/system.py GET status + restart (Whitelist) + self-update (systemd-
USER, sudo-frei). Connect: services/connect.py (Cline/OpenCode/Zed/Continue/
Claude Code/Memory-MCP → Gateway model:auto, LAN-IP-Override), routers/
connect.py. Frontend: SystemView (Metrik-Bars) + ConnectView (Tool-Tabs,
Copy, IP-Override).

Lokal verifiziert: Backend-Smoke + Frontend-Build + Browser (System-Bars,
Connect-Snippets). Docs aktualisiert (README/STATUS/Plan).

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

3.3 KiB

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): noch nicht deployt (Phase 0 step 5 offen).

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 (Governance-UI, mcp_memory.py portiert, mcp_mc.py neu).
  • Phase 4 — Hermes-Schicht (hermes-webui Dienst, Brain=auto, Tools/MCP verdrahten). Braucht Box.
  • Phase 5 — Betrieb/Observability/Politur (Backup, LiteLLM-Traces, Health).
  • 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)

Nächster sinnvoller Schritt

Phase 3 (Memory + MCP) lokal bauen: Memory-Governance-UI, mcp_memory.py portieren (Shared SQLite), mcp_mc.py neu (Stack-Management-Tools für Hermes). Oder Box-Deploy einrichten (systemd-USER-Dienst, sudo-frei). Beim Box-Deploy: deploy/deploy.sh vorher auf User-Dienst umstellen (kein /opt/sudo).