Merge branch 'wartung/einstellungen-stand-altreste' into wartung/restarbeiten

# Conflicts:
#	deploy/deploy.sh

docs/BEDIENUNG.md

@@ -41,8 +41,8 @@ Wichtige Knöpfe fragen vorher nach. Was du auslöst, bestätigt eine kurze Meld
 
 - Jede Zeile ist ein Baustein: Betriebssystem, Motor (llama.cpp), llama-swap, Hermes. Du siehst, was läuft, was neu
   wäre und was sich ändert.
-- Jeden Sonntag um 04:30 aktualisiert sich die Box von selbst; vorher sichert sie, danach prüft sie. Du musst nichts
-  tun.
+- Einmal pro Woche aktualisiert sich die Box von selbst, ab Werk sonntags um 04:30 (verschieben lässt es sich unter
+  Einstellungen → Update-Zeitfenster); vorher sichert sie, danach prüft sie. Du musst nichts tun.
 - „Nach Neuem suchen" schaut sofort nach. „Aktualisieren" spielt einen Baustein sofort ein, „Alles jetzt
   aktualisieren" alle nacheinander. Lucy ist dabei ein paar Minuten nicht erreichbar.
 - **Festgehalten:** Ging ein Update schief, hat die Box die alte Version zurückgeholt und hält den Baustein fest. Sie
@@ -69,6 +69,9 @@ Wichtige Knöpfe fragen vorher nach. Was du auslöst, bestätigt eine kurze Meld
 - **Weitere Einträge:** alle übrigen Modelle. „Modelle selbst suchen" findet Modelle auf Hugging Face und lädt sie.
 - **Aufräumen:** Modelle und Ordner, die gerade niemand nutzt, mit Größe und Hinweis. Die Box löscht nie von selbst.
   „Löschen" ist endgültig; zurück ginge es nur mit einem neuen Download.
+- **Altreste neben dem Betrieb** (unten im Aufräumen): Test-Ordner, alte Umgebungen, alte Arbeitskopien und
+  abgeschaltete Alt-Units, die nichts mehr nutzt. Die Box kennt sie aus einer festen Liste und zeigt nur, was noch da
+  ist und von keinem laufenden Dienst gebraucht wird. „Löschen" fragt nach und ist endgültig.
 
 ## Dienste und Protokolle
 
@@ -81,6 +84,20 @@ Absicht; die Android-App wird sie später wieder brauchen.
 
 - **Hugging-Face-Zugang:** nötig für gesperrte Modelle und für schnellere Downloads. Eintragen, speichern, bei Bedarf
   löschen.
+- **Meldungen:** „Test senden" schickt eine kurze Testmeldung an Telegram, je einen Knopf für die KI-Box und für den
+  Homelab-Teil. Sie geht über denselben Weg wie jede echte Meldung und als dringend, kommt also auch nachts sofort.
+  Darunter steht, ob sie raus ist (über Hermes oder direkt an Telegram) oder warum nicht, etwa „Zugangsdatei fehlt"
+  oder „Telegram lehnt ab". Höchstens ein Test alle 20 Sekunden.
+- **Update-Zeitfenster:** an welchem Wochentag und um welche Uhrzeit sich die Box aktualisiert (ab Werk Sonntag
+  04:30), dazu der nächste Lauf. Neu starten darf sie sich danach nur in den drei Stunden ab der vollen Stunde, also
+  ab Werk Sonntag 04:00–06:59. Am besten nachts nach der Sicherung (03:30) und vor der Morgenmeldung (07:00).
+  „Speichern" fragt nach. Ein Termin, der dadurch schon vorbei wäre, wird nicht nachgeholt; der erste Lauf ist der
+  nächste reguläre. Während eines Update-Laufs lässt sich das Fenster nicht ändern.
+- **Modell-Radar:** ob das Radar nachts nach besseren Modellen sucht. „Ausschalten" legt es schlafen, bis du es
+  wieder einschaltest; auch ein Deploy weckt es nicht. Ein Nachttest, der gerade läuft, endet noch. „Einschalten"
+  holt keinen verpassten Lauf nach, tagsüber lädt es also nichts.
+- **Software-Stand:** welche Version des Orchestrators auf der KI-Box und im Homelab-Teil läuft und seit wann. Laufen
+  beide mit verschiedenen Ständen, steht ein Hinweis darunter; der nächste Deploy der Box zieht den Homelab-Teil mit.
 - **Hermes-Dashboard:** öffnet die eigene Oberfläche von Hermes (Chat, Sitzungen, Cron-Jobs). Hermes fragt nach
   seiner eigenen Anmeldung.
 
@@ -96,8 +113,8 @@ Commander. Heute Nacht gab es …"). Sofort kommen nachts nur dringende Nachrich
 | „[Box-Update] Commander, die Wochenpflege der Box ist durch" | Sonntagsbericht, eine Zeile je Baustein | lesen |
 | „[Box-Update] … fehlgeschlagen … zurückgerollt … GEPINNT" | Update ging schief, die alte Version läuft wieder, der Baustein ist festgehalten | nichts nötig; bei Gelegenheit unter Updates „Freigeben" |
 | „[Box-Update] KRITISCH: …" (sofort, auch nachts) | Update und Rückweg sind gescheitert | Box ansehen (unten), Hilfe holen |
-| „[Box-Update] Neustart steht an … Wartungsfenster" | ein Neustart wartet auf Sonntag früh | nichts |
-| „[Box-Update] Die Box startet jetzt neu …" | geplanter Neustart am Sonntag früh | nichts; sie ist ein paar Minuten weg |
+| „[Box-Update] Neustart steht an … Wartungsfenster (…)" | ein Neustart wartet auf das Wartungsfenster (ab Werk Sonntag früh) | nichts |
+| „[Box-Update] Die Box startet jetzt neu …" | geplanter Neustart im Wartungsfenster | nichts; sie ist ein paar Minuten weg |
 | „[Box-Update] Sonntags-Update mit Fehler beendet" oder „Auto-Update abgebrochen" | der Update-Lauf selbst ist abgebrochen, nichts wurde eingespielt | Seite Updates ansehen, Hilfe holen |
 | „[Box-Problem] …" | der Wächter hat etwas Rotes gefunden | Startseite öffnen, in der Checkliste den Knopf drücken |
 | „[Box wieder ok] Erledigt: …" | das Problem ist weg | nichts |
@@ -105,6 +122,7 @@ Commander. Heute Nacht gab es …"). Sofort kommen nachts nur dringende Nachrich
 | „[Stack-Radar] …" (samstags) | Wochenbericht über die Box und Neuigkeiten | lesen |
 | Daily News (07:00, Text und Sprachnachricht) | die Nachrichten des Tages von Lucy | lesen oder hören |
 | „[Alarm] Deploy …" (sofort) | eine neue Version des Box-Warts ließ sich nicht einspielen, die alte läuft wieder | nichts sofort; Bescheid geben |
+| „[Test] Testmeldung aus den Einstellungen …" (sofort) | du hast unter Einstellungen „Test senden" gedrückt | nichts; der Meldeweg funktioniert |
 
 ## Wenn etwas hakt
 

docs/BETRIEB.md

@@ -17,7 +17,9 @@ curl -s http://127.0.0.1:9001/api/partner               # Lebenszeichen der ande
 curl -s http://127.0.0.1:9010/gw/health                 # Gateway und Motor
 bash -lc 'hermes cron list'                             # Hermes-Jobs (hermes ist über SSH nicht im PATH)
 tail -n 50 ~/mc2-notify.log                             # was zuletzt gemeldet wurde
-tail -n 5 /srv/models/mc2-deploy.log                    # welcher Stand seit wann live ist
+tail -n 5 /srv/models/mc2-deploy.log                    # welche Stände wann live gingen
+cat /srv/models/mc2-stand.json                          # welcher Stand gerade live ist (seit 24.09.)
+cat /srv/models/mc2-einstellungen.json                  # Update-Zeitfenster und Radar-Schalter der Oberfläche
 sudo journalctl -u llama-swap -n 100                    # Motor (System-Dienst)
 ```
 
@@ -39,9 +41,16 @@ sudo journalctl -u llama-swap -n 100                    # Motor (System-Dienst)
   Morgenmeldung. Zuletzt Gesendetes: `night-queue.txt.zuletzt-gesendet`. Das Skript kürzt außerdem
   `~/mc2-notify.log` ab 3 MB auf die letzten 2 MB.
 - **Scheitern beide Wege,** steht die Meldung mit `FALLBACK` im Protokoll und geht per `wall` an die
-  Box-Konsolen (`MC_NOTIFY_OHNE_WALL=1` schaltet `wall` ab).
-- **Testen:** `bash ~/mission-control-v2/deploy/notify.sh -s "[Test]" "Testmeldung"`; nachts landet sie in der
-  Warteschlange, mit `-d` kommt sie sofort.
+  Box-Konsolen (`MC_NOTIFY_OHNE_WALL=1` schaltet `wall` ab). Seit 24.09. steht im `FALLBACK`-Eintrag auch, warum der
+  Zweitweg scheiterte: `FALLBACK (telegram fehlgeschlagen: <Ausgabe von hermes send>; Zweitweg: <Grund>): <Text>`,
+  etwa „Zugangsdatei … fehlt oder ist nicht lesbar“ oder „Telegram lehnt ab, HTTP-Fehler“ (ohne Klammern, damit
+  `update_verlauf.py` den Eintrag weiter trennen kann).
+- **Testen:** Einstellungen → Meldungen → „Test senden“ (je Instanz; `POST /api/einstellungen/telegram-test` bzw.
+  `/api/homelab/einstellungen/telegram-test`). Der Knopf ruft `notify.sh -d -s "[Test]" …` mit
+  `MC_NOTIFY_NO_ANNOUNCE=1` (Lucy spricht den Test nicht) und liest das Ergebnis samt Grund über eine Kennung aus dem
+  Melde-Log (`services/einstellungen.py`). Höchstens ein Test alle 20 s. Von Hand:
+  `bash ~/mission-control-v2/deploy/notify.sh -s "[Test]" "Testmeldung"`; nachts landet sie in der Warteschlange,
+  mit `-d` kommt sie sofort.
 
 | Betreff | Absender | Inhalt |
 |---|---|---|
@@ -81,7 +90,9 @@ es für einen Gast zweimal hintereinander, gibt es einen gelben Hinweis „<App>
 
 - **Selbstreparatur:** Nur ein abgestürzter Dienst (`ActiveState=failed`) wird neu gestartet, höchstens 2× je Stunde
   und Hinweis. Ein gestoppter Dienst (`inactive`) wird nur gemeldet. Ein schlafender Dienst (`inactive` und
-  `disabled`) ist kein Befund.
+  `disabled`) ist kein Befund. Bei Timer-Läufen schläft der Timer, nicht der Dienst dahinter (der ist `static`):
+  Ist `mc2-radar.timer` abgeschaltet (Einstellungen → Radar aus), ist ein alter Fehlschlag von `mc2-radar` kein
+  Befund mehr.
 - **Während eines Updates** (ein Prozess `autoupdate.sh`, `update-engine.sh`, `update-swap.sh` oder `hermes … update`
   läuft) prüft er Dienste und Kern nicht und repariert nichts. Die Oberfläche zeigt dann „Update läuft".
 - **Meldungen:** Rote Hinweise gehen an Telegram und in den Briefkasten, bei Fortbestand alle 6 h erneut; nachts gilt
@@ -96,6 +107,45 @@ es für einen Gast zweimal hintereinander, gibt es einen gelben Hinweis „<App>
   (`/running`), nicht mehr „irgendein Modell läuft". Lädt es gerade (`starting`), ist das kein Befund — höchstens
   10 Minuten lang (`MC_WAECHTER_HIRN_LADEN_S`), danach heißt der Hinweis „Lucys Hirn lädt nicht fertig".
 
+## Einstellungen der Oberfläche (Zeitfenster, Radar-Schalter)
+
+Seit 24.09.2026, Logik in `backend/services/einstellungen.py`, Schnittstellen unter `/api/einstellungen`.
+
+- **Eine Datei:** `/srv/models/mc2-einstellungen.json` (`update_fenster: {tag: 1–7, uhrzeit: "HH:MM"}`,
+  `radar: {an}`). Nur MC2 schreibt sie; `deploy.sh` und `autoupdate.sh` lesen sie. Fehlt sie, gilt So 04:30 und
+  Radar an. Sie steckt in jeder Sicherung (`mc2-*.json`).
+- **Update-Zeitfenster:** Speichern schreibt das Drop-in
+  `~/.config/systemd/user/mc2-autoupdate.timer.d/zeitfenster.conf` (`OnCalendar=` leer, dann der neue Plan). Ablauf:
+  Timer stoppen → Drop-in → `daemon-reload` → Stempel `~/.local/share/systemd/timers/stamp-mc2-autoupdate.timer`
+  auf jetzt → Timer starten. Grund: Der Timer hat `Persistent=true`. Ein laufender Timer rechnet beim Reload mit
+  seinem letzten Lauf und dem neuen Plan, ein frisch gestarteter mit dem Stempel. Beides hätte einen schon vorbei
+  gewesenen Termin sofort nachgeholt (so am 24.09. mittags passiert). Scheitert ein Schritt, kommt das alte Drop-in
+  zurück, und der Timer läuft wieder. Während `mc2-autoupdate.service` läuft, lehnt MC2 das Ändern ab.
+- **Neustart-Fenster:** `deploy/wartungsfenster.sh` (von `autoupdate.sh` eingebunden) erlaubt den Neustart nur in
+  den drei Stunden ab der vollen Stunde des Beginns: So 04:30 → So 04:00–06:59, Sa 23:30 → Sa 23:00 – So 01:59.
+  Es liest das Fenster mit `jq` aus der Einstellungsdatei; `MC_WARTUNGSFENSTER="<Tag> <HH:MM>"` und
+  `MC_FENSTER_JETZT` sind Test-Schalter. `MC_AUTOUPDATE_REBOOT_JETZT=1` erzwingt den Neustart wie bisher.
+- **Radar-Schalter:** Aus = `systemctl --user disable --now mc2-radar.timer` (ein laufender Nachttest endet noch).
+  An = `enable`, Stempel `stamp-mc2-radar.timer` auf jetzt, `start` — kein Nachholen, also tagsüber kein Laden.
+- **Deploy:** Das Drop-in fasst `deploy.sh` nie an. Steht das Radar auf aus, lässt der Deploy den Timer aus
+  (`disable --now`) statt ihn wie früher einzuschalten; steht es auf an und läuft der Timer nicht, startet ihn der
+  Deploy mit Stempel, also ohne Nachholen.
+- **Wächter:** Ein ausgeschaltetes Radar schläft (Timer `inactive` und `disabled`) und ist kein Befund; die
+  Oberfläche zeigt unter Einstellungen „Schläft“.
+- **Prüfen auf der Box:**
+  `systemctl --user cat mc2-autoupdate.timer`, `systemctl --user list-timers mc2-autoupdate.timer mc2-radar.timer`,
+  `systemctl --user is-enabled mc2-radar.timer`.
+
+## Software-Stand
+
+- **Stand-Datei:** Nach dem Umschalten schreibt `deploy.sh` (nach der Nachprüfung) `/srv/models/mc2-stand.json`:
+  `commit` (kurz), `betreff`, `commit_datum`, `deploy_zeit`. `deploy/homelab/ausrollen.sh` schreibt dasselbe nach
+  erfolgreichem `einrichten.sh` in den Container (`/var/lib/mc2/mc2-stand.json`, Eigentümer `mc2`). Beide nutzen
+  `deploy/stand-schreiben.py` (nur Standardbibliothek, atomar). Scheitert nur das Schreiben, gilt der Deploy trotzdem.
+- **Anzeige:** `/api/instanz` liefert `stand` mit, `/api/partner/instanz` den der anderen Instanz; Einstellungen →
+  Software-Stand zeigt beide und einen Hinweis, wenn sie abweichen. Ohne Stand-Datei liest MC2 den Stand aus git
+  (`quelle: "git"`, ohne Deploy-Zeit), sonst `unbekannt`.
+
 ## Dienste schlafen legen und wecken
 
 - Schlafen legen: `systemctl --user disable --now <unit>` (seit 24.09.: `box-console`, `voice-service`).
@@ -127,7 +177,9 @@ systemd-Einheiten und überleben den Neustart von MC2. Dann den alten Stand merk
    `--watch-config` selbst neu. Weicht die lebende Datei nur ab, gibt es einen Hinweis und sonst nichts.
 4. Alle Repo-Units nach `~/.config/systemd/user/`, dazu die Drop-ins `mc2-steward.service.d/warmset.conf` und
    `mission-control-2.service.d/override.conf`; `daemon-reload`; `enable` für die Units in `AKTIV`; Timer starten
-   (den Update-Timer nur, wenn er noch nicht läuft).
+   (den Update-Timer nur, wenn er noch nicht läuft). Das Drop-in `mc2-autoupdate.timer.d/zeitfenster.conf` gehört
+   der Oberfläche und bleibt unangetastet. Den Radar-Timer schaltet der Deploy nach dem Schalter in
+   `mc2-einstellungen.json`: aus = `disable --now`, an = `enable` und, falls er nicht läuft, Start mit Stempel.
 5. Cron-Skripte `deploy/jobs/*.sh` und `*.py` nach `~/.hermes/scripts/`.
 6. Skills `deploy/skills/*` nach `~/.hermes/skills/<name_mit_unterstrich>/`, abgelöste Skills nach
    `~/.hermes/skills-archiv/`. Plugins `deploy/hermes-plugins/*` nach `~/.hermes/plugins/`; aktiviert werden sie
@@ -135,7 +187,8 @@ systemd-Einheiten und überleben den Neustart von MC2. Dann den alten Stand merk
 7. Neustart von `mc2-gateway`, `mission-control-2` und `mc2-steward`, dann bis zu 60 s Nachprüfung: `/api/health`,
    `/gw/health`, Steward aktiv.
 
-Erfolg: eine Zeile in `/srv/models/mc2-deploy.log` und „Deploy <commit> ist live". Danach (Schritt 8) zieht der Deploy den
+Erfolg: eine Zeile in `/srv/models/mc2-deploy.log`, die Stand-Datei `/srv/models/mc2-stand.json` und „Deploy <commit>
+ist live". Danach (Schritt 8) zieht der Deploy den
 Homelab-Teil mit, sobald `box-partner.sh` einen Partner eingerichtet hat: `deploy/homelab/ausrollen.sh` mit der IP aus
 `partner.conf`. Scheitert das, bleibt die Box live und es kommt „[Alarm] Deploy"; `MC_DEPLOY_OHNE_HOMELAB=1` lässt
 den Schritt aus. Scheitert ein Schritt:
@@ -328,7 +381,8 @@ Update erneut.
 | `~/mission-control-v2` | Checkout von `main` (nur über `deploy.sh` ändern) |
 | `~/mission-control-v2/backend/.venv` | Python-Umgebung des Box-Warts (Python 3.14) |
 | `~/.config/systemd/user/` | User-Units und Drop-ins |
-| `/srv/models/` | Modelle, Box-Wart-Zustand (`mc2-*.json`), Sicherungen (`mc2-backups/`), Radar-Downloads (`radar/`) |
+| `/srv/models/` | Modelle, Box-Wart-Zustand (`mc2-*.json`, darunter `mc2-einstellungen.json` und `mc2-stand.json`), Sicherungen (`mc2-backups/`), Radar-Downloads (`radar/`) |
+| `~/.config/systemd/user/mc2-autoupdate.timer.d/zeitfenster.conf` | Update-Zeitfenster aus der Oberfläche (nur MC2 schreibt es) |
 | `/etc/llama-swap/config.yaml` | lebende llama-swap-Config (+ `.bak-*`) |
 | `/opt/llamacpp-vulkan/`, `/usr/local/bin/llama-server` | Motor (llama.cpp Vulkan) |
 | `/usr/local/bin/llama-swap`, `/usr/local/bin/llama-swap-warmup.sh` | Router und Vorwärm-Skript (Root-Kopie) |

docs/wissen/OFFENE-FAEDEN.md

@@ -49,17 +49,23 @@ Technik: [ARCHITEKTUR.md](../ARCHITEKTUR.md), Abschnitt „Der Homelab-Teil“;
 
 - Modelle ohne Rolle (Modelle-Seite, „Aufräumen"): gpt-oss-120b (60 GB), Qwen3-VL-30B-A3B (19 GB), Muse-Glimmer-30B,
   alte Drafts. Die Originale von Hirn und Coder sind der Rückweg, Nemotron ist Reserve: beides bewusst entscheiden.
-- Reste neben dem Betrieb (Prüfbericht 24.09.): rund 10 GB Test- und venv-Ordner im Home-Verzeichnis, alte Skripte in
-  `~/.hermes/scripts` (`deploy.sh` legt neue dazu, räumt alte nicht weg), das inaktive Plugin `mc2-memory`,
-  `~/.hermes/PINNED_VERSION` (veraltet; Pins stehen in `/srv/models/mc2-pins.json`), zwei fremde Dateien im
-  Hermes-Quellbaum, alte Worktrees unter `~/.hermes/worktrees` und `~/projekte/mc2-referenz`, abgeschaltete
-  Alt-Units in `~/.config/systemd/user`.
+- Reste neben dem Betrieb stehen seit 24.09. im selben Panel unter „Altreste“ (feste Liste in
+  `backend/services/aufraeumen.py`, am 24.09. auf der Box gemessen, zusammen gut 11 GB): TTS-Test, alter ROCm-Build,
+  mem0, Kanban-Arbeitsordner, alte venvs, audio.cpp-Test, Avatar, alte Worktrees, Test-Reste, fremde Dateien im
+  Hermes-Quellbaum, alte Skripte in `~/.hermes/scripts`, Plugin `mc2-memory`, `PINNED_VERSION`, abgeschaltete
+  Alt-Units. Löschen je Eintrag per Klick.
+- Bewusst nicht in der Liste, weil nicht klar tot (bei Gelegenheit von Hand entscheiden): `~/.voice` (die
+  Spracherkennung schläft nur), `~/.cache`, `~/.opencode` (steht in `~/.bashrc`), `~/.hermes/kanban.db` (Hermes öffnet
+  sie), die Archive `profiles-archive-20260819.tar.gz`, `~/archiv-aufraeumen-20260820`, `~/wissens-vault`,
+  `~/.hermes/state-snapshots`, der PBS-Weg, `ampel-waechter.sh`, `night-cron-wrapper.sh` und `pc_path_lookup.*`
+  (aktive Skills nennen sie).
+- Die crontab ruft sonntags `~/.hermes/scripts/curator-idle-watchdog.sh` auf; das Skript gibt es nicht mehr.
 
 ## Beobachten
 
 - **25.09. 00:30:** Radar-Neutest Ornith-1.5-35B-A3B (Hirn), jetzt mit Draft-Varianten. **01.10.:** Qwen3.8-Flash-Next
   (Coder, passt nur knapp).
 - **So 27.09. 04:30:** erster regulärer Sonntagslauf über den Timer; der Bericht kommt mit der Morgenmeldung um 07:00,
-  der Verlauf steht auf der Updates-Seite.
+  der Verlauf steht auf der Updates-Seite. Wird das Zeitfenster vorher in den Einstellungen verschoben, gilt das neue.
 - **Daily News 07:00:** Die `web_extract`-Werkzeugfehler sollten mit dem Plugin `mc2-web-lesen` verschwunden sein
   (Hermes am 24.09. neu gestartet).