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>
Doku — Index, Lesereihenfolge, Pflegeregeln
Stand 24.09.2026. Das Projekt heißt „Homelab Orchestrator"; der Bereich für die KI-Box heißt „Box-Wart", der für den Proxmox-PC „Homelab". Bei Widerspruch gilt: Code vor Doku, wissen/STACK.md vor anderen Dokumenten, aktuelle Doku vor dem Archiv.
Lesereihenfolge
Frischer Agent:
- ../AGENTS.md: verbindliche Bau-Regeln.
- wissen/ARBEITSWEISE.md: wer der User ist, die Regeln, was wohin gehört.
- wissen/STACK.md: Maschinen, Dienste, Modelle, Automatik.
- ARCHITEKTUR.md: wie die Teile zusammenhängen.
- wissen/VERDIKTE.md: was entschieden ist.
- wissen/FALLEN.md: vor jeder Änderung an der Box.
- wissen/OFFENE-FAEDEN.md: was als Nächstes ansteht.
Betrieb und Störungen: BETRIEB.md, dann je nach Thema UPDATES.md, RADAR.md, WIEDERAUFBAU.md und ../deploy/jobs/README.md.
User: BEDIENUNG.md.
Die Dateien
| Datei | Für | Inhalt |
|---|---|---|
| BEDIENUNG.md | User | Oberfläche, Telegram-Nachrichten, was tun, wenn etwas hakt |
| ARCHITEKTUR.md | Agenten, Technik | Prozesse, Rollen und Partner-Instanz, Modell-Rollen, wer was schreibt, Meldeweg, Schnittstellen |
| BETRIEB.md | Agenten, Technik | Handgriffe, Meldungen, Wächter-Regeln, Deploy und Prüftor, Sicherung, Notfall |
| UPDATES.md | Agenten, Technik | Sonntags-Kette, Prüfungen, Festhalten und Freigeben, Handbetrieb |
| RADAR.md | Agenten, Technik | Modell-Radar, Prüfstand, Stack-Radar |
| WIEDERAUFBAU.md | Technik | die KI-Box von null; Anhang A: llama-swap-Unit |
| wissen/STACK.md | Agenten | Stand-Wahrheit: Maschinen, Dienste, Modelle, Automatik |
| wissen/VERDIKTE.md | Agenten | Entscheidungen mit Datum und Grund; Abschnitt „Überholt" |
| wissen/FALLEN.md | Agenten | Fallen mit Datum und Symptom |
| wissen/ARBEITSWEISE.md | Agenten | User-Profil, Regeln, Flächen |
| wissen/OFFENE-FAEDEN.md | alle | Fahrplan und die eine Liste offener Punkte |
| ../deploy/jobs/README.md | Agenten, Technik | Hermes-Jobs und Timer, Daily News |
Archiv
archiv/ hält historische Dokumente mit Datumspräfix. Sie werden nicht mehr gepflegt; Aussagen und Links darin
können veraltet sein.
| Datei | Inhalt |
|---|---|
2026-06-30-optimierungsplan.md |
Audit und Plan zu Rollen, Warm-Set und Durchsatz (Juni) |
2026-06-30-zeroclaw-poc-auftrag.md, …-ergebnis.md |
ZeroClaw-Test; Beleg für „Hermes bleibt" |
2026-06-30-lucy-tts-plan.md |
Stimmen-Strategie für Lucy (Juni) |
2026-07-02-autonomie-plan.md |
„Die Box wartet sich selbst", Etappen E1–E6 |
2026-07-02-komplett-review.md |
Review von MC2 und Lucy |
2026-07-06-antigravity-review-prompt.md |
Review-Auftrag für Gemini |
2026-07-10-gemini-briefing.md |
Notfall-Briefing für Gemini |
2026-07-10-zielbild-abloesung.md |
Richtungs-Entscheid vom 10.07. |
2026-07-15-umbauplan-abloesung.md |
Abschluss-Review vom 15.07. mit Gateway- und Steward-Auszug |
2026-07-19-uebergabe-drei-welten.md |
Übergabe des Umbaus vom 19.07. |
2026-07-21-skill-gitea-workflow.md |
Beschreibung des früheren Skills gitea-workflow |
2026-08-07-hermes-setup.md |
Hermes-Runbook aus der Anfangszeit |
2026-08-20-savepoint.md |
Stand-Seite vom 20.08. |
2026-08-20-referenzaufgabe-gedaechtnis-ausbau.md, 2026-08-20-referenz-check.sh |
Messlatte des Referenzlaufs (Ausbau des alten Gedächtnis-Dienstes) |
2026-08-21-hermes-werkzeuge.md |
Werkzeugsätze nach Bedarf; Kern steht in wissen/FALLEN.md |
2026-08-21-umbau-openchamber.md |
Aufbau der Coding-Bahn mit OpenChamber, Gitea-SSH |
2026-09-04-raphael-lucy-innere-stimme.md |
Lucy als innere Stimme (Entscheid 04.09.) |
2026-09-04-offene-faeden-alt.md |
Liste offener Punkte bis 04.09., mit den Lucy-Fäden |
gitea-host/ |
Notizen zum Gitea-Host |
hermes-api_server-vision-patch-verwaist.diff |
verwaister Patch am Hermes-api_server (Bilder), nur zur Erinnerung |
Ganz gelöschte Dokumente (STATUS, CUTOVER, UPGRADE, AUDIT_KICKOFF, die Kopien unter docs/memory/ u. a.) stehen in
der Git-Historie.
Pflegeregeln
- Eine Wahrheit je Thema: Stand →
wissen/STACK.md; Entscheidungen →wissen/VERDIKTE.md; Fallen →wissen/FALLEN.md; offene Punkte →wissen/OFFENE-FAEDEN.md(die einzige Liste, keine zweite anlegen); Abläufe →ARCHITEKTUR.md,BETRIEB.md,UPDATES.md,RADAR.md. - Verifizieren vor Behaupten: Jede Aussage gegen Code oder Messung prüfen. Stand-Angaben tragen ein Datum, am besten mit Commit. Was nicht geprüft ist, heißt „offen" oder „nicht geprüft".
- Doku folgt dem Code im selben Branch: Wer Units, Skripte, Routen, Meldungstexte oder Abläufe ändert, zieht die betroffenen Dokumente mit.
- Verdikte ändern sich nur mit neuem, belegtem Anlass (Messung, Release, User-Entscheid); das alte wandert mit Datum nach „Überholt".
- Fallen mit Datum und Symptom eintragen; Erledigtes streichen.
- Historisches mit eigenem Wissen nach
archiv/(PräfixJJJJ-MM-TT-), sonst löschen; die Git-Historie behält alles. - Sprache: Deutsch, knapp, Fakten statt Adjektive.
BEDIENUNG.mdin Alltagssprache ohne Fachjargon. - Keine Geheimnisse (Tokens, Passwörter, Chat-IDs) in die Doku; Sicherheitshinweise in einem Satz.
- Weg der Änderung: Branch →
bash deploy/pruefen.sh→ Merge. Auf der Box kommt die Doku mit dem nächsten Deploy an.