HitonabiandClaude Opus 5.5
450c782ed3
Die Seite /homelab/snapshots (in der Seitenleiste nach „Updates“: Snapshots sind der Rückweg der Updates) zeigt je Gerät die Snapshots mit Zeitpunkt, Alter, Herkunft (vor Update / per Knopf / von Hand) und Beschreibung, beim PBS die Sicherungen des Orchestrators mit Größe. Knöpfe „Snapshot anlegen“, „Zurücksetzen“ und „Löschen“ gibt es nur für freigegebene Geräte und nur für mc2-Snapshots bzw. eigene Sicherungen; von Hand angelegte bleiben reine Ansicht. Die Rückfragen kommen vom Homelab-Teil (wie im Ziel-Modell); Zurücksetzen sagt vorher, was verloren geht und dass das Gerät neu startet. Am Handy (320–400 px) untereinander, ab md Knöpfe rechts, ab xl fünf Spalten. Entscheide: - Ausführer: kein neuer Befehl. Der Bericht bringt zusätzlich snapshot_details (snaptime, Beschreibung, eigen) und sicherung_details (ctime, Größe); snapshots und sicherungen bleiben unverändert. Keine Belegung je Snapshot — die kennt Proxmox bei LVM-Thin nicht, die Seite sagt das so. „snapshot“ nimmt einen Anlass (update oder knopf) und wählt damit eine feste Beschreibung, damit ein Snapshot auf Knopfdruck nicht „Vor einem Update“ heißt. Bis der neue Ausführer eingespielt ist, liest der Homelab-Teil den Zeitpunkt aus dem Namen. - Aktionen sind Läufe in homelab-laeufe.json (Mechanik aus updates.py): gleiche Sperren (START_SPERRE, je Gerät einer, SAMMELLAUF_SPERRE), Protokoll-Art „snapshot“ mit eigenen Titeln, der Wächter lässt ein Gerät im Zurücksetzen in Ruhe. Zusätzlich keine Aktion, solange irgendwo ein Update läuft: Der Ausführer arbeitet einen Auftrag nach dem anderen ab — hinter einem Update liefe die Aktion in ihr Zeitlimit und käme danach unbeobachtet doch noch dran. - Zurücksetzen prüft danach wie ein Update und meldet immer ([Homelab-Snapshot], bei Rot als Alarm); anlegen und löschen melden nur ihr Scheitern, das Ergebnis steht beim Gerät. Nicht im Update-Verlauf, nicht unter „Zuletzt eingespielt“. - Per Knopf angelegte Snapshots räumt kein grünes Update weg (updates._aufraeumen fragt snapshots.knopf_namen). - speicher.py: alle Snapshots in einem Vorschlag mit Verweis auf die Seite statt einer je Snapshot. - Nebenbei: Der Update-Verlauf stürzte bei einem Ergebnis ohne Eintrag ab (etwa „offen“ nach einem Docker-Probelauf); die Protokoll-Seite stürzte im Entwicklungsmodus ab (Konstante „Symbol“ gegen das Symbol.for des React Compilers); Auftragstitel „Alter Snapshot gelöscht“ heißt jetzt „Snapshot gelöscht“ (gelöscht wird auch von Hand). Tests: pytest test_homelab_snapshots.py (Ausführer-Details, Liste, Läufe mit nachgespieltem Ausführer, Sperren, Aufräumen, Schnittstelle), test_homelab_speicher.py; Vitest SnapshotListe, lib/snapshots, Speicher. Prüftor grün. 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 |