Files
mission-control-v2/docs/STATUS.md
T
Hitonabi cff3f0b1a8 feat(2.0): Phase 1 — Engine + Routing (Herzstueck)
Backend-Services: fit/caps/sources (portiert), discover (live HF + Fit +
Caps + ranked recommendation), llama-swap write/register + groups (Ko-
Residenz swap:false), LiteLLM-Gateway-Config + gateway-Service (model:auto +
Fallbacks). Router: discover/fit/register/groups/routing; health zeigt
gateway_reachable. Frontend: Modelle&Routing mit Caps-Chips, Fit-Badges,
Discover-Tab (live), Routing-View.

Lokal verifiziert: Backend-Smoke (alle Endpunkte) + Frontend-Build +
Browser (Shell, Discover, Caps/Fit). Box-Verifikation offen.

Docs: README + docs/STATUS.md (Phasen-Tracker + Resume-Guide).

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

2.7 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 (Metriken, Dienste, Update/Self-Update, Connect-Snippets).
  • 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

Nächster sinnvoller Schritt

Phase 2 (System/OS + Connect) lokal bauen — oder Box-Deploy einrichten (systemd-USER-Dienst, sudo-frei). Beim Box-Deploy: deploy/deploy.sh vorher auf User-Dienst umstellen (kein /opt/sudo).