HitonabiandClaude Opus 5.5
948e55e4f2
Tiefblauer Grund mit Lichtflecken in den Bereichsfarben, Glasflächen mit Lichtkante (flaeche), ruhigere Schrift (Überschriften normal geschrieben, Großbuchstaben nur als kleines Etikett) und dezente Bewegung. - Startseite neu: Geräte-Ring mit Gesamtlage, drei Eckwerte, Instrumente (8 Messringe), Bereichskarten mit Kacheln je Modell, Baustein und Gerät (Symbol, Zustandspunkt, Update direkt an der Kachel), Speicher/NAS, Zeitleisten „Als Nächstes“ und „Zuletzt eingespielt“. - Panel, Schildchen, Kennzahl, Verlaufslinie, Seitenleiste und Kopf im neuen Look — wirkt schon auf allen Seiten. - Symbole je Gerät (lib/geraetebild): Farbe des Bereichs, Zustände nur als Punkt. Vorbilder: Heimdall, Dashy, Homepage, umbrelOS, Pulse. Noch nicht ausgerollt (kein dist): erst nach dem Ja des Users. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Homelab Orchestrator
Ein Steuerpult fürs Heimnetz, das sich selbst wartet. Zwei Bereiche, eine Oberfläche:
- Box-Wart betreut die KI-Box (Bosgame M5, AMD Ryzen AI MAX+ 395, 128 GB gemeinsamer Speicher, llama.cpp über Vulkan): hält sie aktuell, passt auf sie auf und sucht bessere Modelle. Live seit 23.09.2026.
- Homelab soll den Proxmox-PC mit seinen Containern und Arcane (Docker) betreuen: offene Updates zeigen, per Knopf einspielen, danach die Erreichbarkeit prüfen. In Arbeit (Fahrplan).
Dieselbe Codebasis läuft als zwei Instanzen: auf der KI-Box (Rolle box) und später als Container auf dem
Proxmox-PC (Rolle homelab); beide prüfen sich gegenseitig. Repo, Dienste und Dateien tragen noch den alten Namen
„Mission Control 2" (mission-control-v2, mission-control-2, mc2-*). Alles läuft lokal, kein Cloud-Modell im
Datenpfad.
Oberfläche
Im Heimnetz http://192.168.178.151:9001, am PC oder am Handy.
| Seite | Inhalt |
|---|---|
| Start | Warnlampen, Instrumente (Speicher, Temperatur, Platte, Laufzeit), Checkliste mit den Hinweisen des Wächters und ihren Knöpfen, Flugplan (was lief, was kommt), Radar-Kasten |
| Updates | Bausteine Betriebssystem, Motor (llama.cpp), llama-swap und Hermes; Verlauf der Update-Läufe; Sicherungen |
| Modelle | Speicher, Rollen Hirn und Coder, wer die Modelle nutzt, Modell-Radar, Aufräumen, Modelle selbst suchen |
| oben rechts bzw. „Mehr" | Hermes-Dashboard, Dienste und Protokolle, Einstellungen |
Anleitung für den Alltag: docs/BEDIENUNG.md.
Was von allein läuft
- Wächter (jede Minute): Dienste, Timer, Hermes-Jobs, Kern, Platte, festgehaltene Updates und, sobald eingerichtet, die Partner-Instanz. Abgestürzte Dienste startet er selbst neu (höchstens 2× je Stunde), Rotes meldet er per Telegram.
- Updates sonntags 04:30: llama-swap → Motor → Hermes, danach Prüfung; rot → zurück und festhalten. Die Box startet nur sonntags zwischen 04:00 und 06:59 neu.
- Modell-Radar nachts 00:30–02:30: sucht Kandidaten für Hirn und Coder und testet höchstens einen pro Woche; übernommen wird nur per Knopf.
- Sicherung täglich gegen 03:30, 14 Stück, Kopie auf dem Proxmox-Host.
- Meldungen gehen an Telegram und in Lucys Briefkasten; nachts gesammelt, um 07:00 als eine Morgenmeldung, Dringendes sofort.
Alle Zeiten: docs/wissen/STACK.md, Abschnitt „Automatik".
Dienste und Ports (KI-Box)
| Port | Unit | Aufgabe |
|---|---|---|
9001 |
mission-control-2 |
Oberfläche, /api, /v1 für Lucy und OpenChamber, Hermes-Dashboard unter /hermes-ui/ |
9010 (nur lokal) |
mc2-gateway |
/v1-Datenpfad: model: auto, Bild-Weiche |
| – | mc2-steward |
Wächter und Re-Warm |
8080 |
llama-swap (System-Dienst) |
Modell-Router, startet je Modell einen llama-server |
8642 |
hermes-gateway |
Hermes Agent „Lucy", Telegram |
9119 |
hermes-builtin-ui |
Hermes-Dashboard |
8021 (nur lokal) |
lucy-stimme |
Lucys Stimme |
8650 (nur lokal) |
voice-service |
Spracherkennung (schläft seit 24.09.) |
7682 (nur lokal) |
box-console |
Web-Konsole (schläft seit 24.09.) |
Dazu die Timer mc2-radar, mc2-backup, mc2-morgenmeldung, mc2-autoupdate und projekte-sync. Die Unit-Dateien
liegen in deploy/.
Entwickeln
# Backend lokal auf :9000 (Windows)
cd backend
python -m venv .venv
.venv/Scripts/python -m pip install -r requirements.txt -r requirements-dev.txt
.venv/Scripts/python -m uvicorn app:app --port 9000
# Frontend (Vite leitet /api an :9000 weiter; MC_API_TARGET=http://192.168.178.151:9001 zeigt auf die Box)
cd frontend && npm ci && npm run dev
Vor jedem Push: bash deploy/pruefen.sh (Shell- und Python-Syntax, ruff check ., Importe, pytest backend/tests);
bei Frontend-Änderungen zusätzlich npm run lint, npm test und npm run build in frontend/, und das neue
frontend/dist mitcommitten, denn die Box baut kein Frontend. Gearbeitet wird auf einem Branch; main liegt auf
Gitea (ssh://gitea@192.168.178.153:2222/Hitonabi/mission-control-v2.git), danach auf der Box
bash ~/mission-control-v2/deploy/deploy.sh. Regeln für Agenten: AGENTS.md.
Doku
| Dokument | Für | Inhalt |
|---|---|---|
| docs/README.md | alle | Index, Lesereihenfolge, Pflegeregeln |
| docs/BEDIENUNG.md | User | Oberfläche und Telegram-Nachrichten |
| docs/ARCHITEKTUR.md | Agenten, Technik | Prozesse, Rollen, Datenwege, wer was schreibt |
| docs/BETRIEB.md | Agenten, Technik | Handgriffe, Meldungen, Wächter, Deploy, Sicherung, Notfall |
| docs/UPDATES.md | Agenten, Technik | Sonntags-Update, Festhalten, Freigeben |
| docs/RADAR.md | Agenten, Technik | Modell-Radar, Stack-Radar, Prüfstand |
| docs/WIEDERAUFBAU.md | Technik | die KI-Box von null aufbauen |
| docs/wissen/ | Agenten | Stand, Verdikte, Fallen, Arbeitsweise, offene Fäden |