wartung: Dashboard-Token weg, alte Hermes-Umgebung ablösbar, Box-Units als Kopie

- Hermes-Dashboard: festes Session-Token der früheren Desktop-Anbindung wird
  nicht mehr gesichert oder zurückgespielt (liegt im Archiv auf der Box).
  Es bindet weiter an 0.0.0.0, weil Hermes seine Anmeldung auf 127.0.0.1
  abschaltet; ufw hält 9119 zu (Kommentar in config.py nachgezogen).
- Selbstreparatur und PC-Pfad-Skill nutzen das System-Python (hat PyYAML)
  statt der alten Hermes-venv; die steht jetzt samt Sicherung als Altrest
  im Aufräumen-Panel (Löschen per Klick, empfohlen nach dem Sonntagslauf).
- deploy/nur-box/: Kopien der Units, die nur auf der Box leben
  (Hermes-Dashboard, llama-swap samt Drop-ins) — werden nicht ausgespielt.
- Offene Fäden nachgezogen: Discard VM 106, Rückweg-Probe, AdGuard,
  Ausbauplan-Entscheide der Klärungsrunde.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

backend/config.py

@@ -103,10 +103,11 @@ VOICE_SERVICE_URL = os.environ.get("MC_VOICE_SERVICE_URL", "http://127.0.0.1:865
 LUCY_STIMME_URL = os.environ.get("MC_LUCY_STIMME_URL", "http://127.0.0.1:8021").rstrip("/")
 # Eingebaute Hermes-Web-GUI (`hermes serve`/`dashboard` — die richtige Agent-Oberfläche mit
 # Threads/Tool-Calls, die auch die Electron-Desktop-App umhüllt). ‼️ Sie bindet NICHT auf Loopback:
-# ein systemd-Drop-in überschreibt `--host 127.0.0.1` mit `0.0.0.0` und setzt dafür ein
+# ein systemd-Drop-in überschreibt `--host 127.0.0.1` mit `0.0.0.0`, weil Hermes seine Anmeldung auf
-# Session-Token. Dass sie trotzdem nicht im LAN hängt, liegt allein an ufw (9119 ist nicht
+# Loopback abschaltet (dann wäre /hermes-ui/ ohne Login offen). Dass sie trotzdem nicht im LAN hängt,
-# freigegeben — am 27.08.2026 von einem zweiten Rechner aus gegengeprüft). Wer die Firewall
+# liegt allein an ufw (9119 ist nicht freigegeben — 27.08. und 25.09.2026 vom PC aus gegengeprüft).
-# anfasst, öffnet damit auch diese Oberfläche. MC2 erreicht sie über Loopback und reicht sie
+# Wer die Firewall anfasst, öffnet damit auch diese Oberfläche. Das feste Session-Token der früheren
+# Desktop-Anbindung ist seit 25.09.2026 weg. MC2 erreicht sie über Loopback und reicht sie
 # same-origin unter
 # /hermes-ui/ durchgereicht (routers/hermes_ui.py). Anders als das ttyd-Terminal ist es eine volle
 # SPA → das Bundle wird mit Vite-base=/hermes-ui/ gebaut, damit Assets/API/WS unter dem Präfix

backend/services/aufraeumen.py

@@ -227,6 +227,11 @@ ALTRESTE: tuple[Altrest, ...] = (
                 "selbstkritik-feed.sh", "venv-audit.sh", "worker.sh")),
             "Skripte früherer Cron-Jobs (Werkstatt, Ampel, alte Radare). Kein Job, kein Cron und kein aktiver "
             "Skill ruft sie auf; deploy.sh legt nur die heutigen Skripte dorthin."),
+    Altrest("hermes-alt-umgebung", "Alte Hermes-Umgebung (Python 3.11)",
+            ("~/.hermes/hermes-agent/venv", "~/.hermes/hermes-agent/venv.bak-20260925-vor-pm"),
+            "Hermes' Umgebung von vor dem eigenen Paketmanager (hermes pm, 25.09.) und ihre Sicherung. Seit 25.09. "
+            "starten Gateway und Dashboard aus der neuen Umgebung; Selbstreparatur und PC-Pfad-Skill nutzen das "
+            "System-Python. Empfohlen: erst nach einem grünen Sonntagslauf (27.09.) löschen."),
     Altrest("mc2-memory", "Plugin mc2-memory", ("~/.hermes/plugins/mc2-memory",),
             "Gedächtnis-Plugin aus der mem0-Zeit, in Hermes nicht aktiviert und nicht mehr im Repo."),
     Altrest("pinned-version", "Veraltete PINNED_VERSION", ("~/.hermes/PINNED_VERSION",),

deploy/backup.sh

@@ -40,10 +40,9 @@ mkdir -p "$STAGE/hermes" "$STAGE/llama-swap"
 # Desktop-Verbindung und die pre_verify-Gates STILL (config.yaml referenziert die Hooks):
 [ -d "$HERMES/agent-hooks" ]                 && cp -a "$HERMES/agent-hooks" "$STAGE/hermes/agent-hooks" || true
 [ -f "$HERMES/shell-hooks-allowlist.json" ]  && cp -a "$HERMES/shell-hooks-allowlist.json" "$STAGE/hermes/" || true
-[ -f "$HERMES/desktop-gateway-token" ]       && cp -a "$HERMES/desktop-gateway-token" "$STAGE/hermes/" || true
 [ -f "$HERMES/pc-paths.yaml" ]               && cp -a "$HERMES/pc-paths.yaml" "$STAGE/hermes/" || true
-_TOKDROPIN="$HOME/.config/systemd/user/hermes-builtin-ui.service.d/session-token.conf"
+# Das feste Dashboard-Token der früheren Desktop-Anbindung (desktop-gateway-token, session-token.conf) gibt es seit
-[ -f "$_TOKDROPIN" ] && { mkdir -p "$STAGE/hermes/systemd-dropins"; cp -a "$_TOKDROPIN" "$STAGE/hermes/systemd-dropins/"; } || true
+# 25.09.2026 nicht mehr — es wird nicht mehr gesichert (liegt nur noch im Archiv ~/.hermes/archiv-20260925-dashboard).
 # Cron-Jobs + Radar-State (10.07.2026) — jobs.json liegt AUSSERHALB des Repos; ohne diese
 # Zeilen verliert ein Restore ALLE Hermes-Crons (traum/Briefing/Monats-Review/Chef-Gutachter/
 # Release-Radar) still:

deploy/nur-box/README.md

@@ -0,0 +1,21 @@
+# Units, die nur auf der Box leben — Kopien zum Nachlesen
+
+Stand 25.09.2026, abgezogen von der KI-Box. **`deploy.sh` spielt diese Dateien nicht aus**; die Wahrheit ist die Box.
+Sie stehen hier, damit man ohne SSH sieht, wie Hermes-Dashboard und llama-swap gestartet werden, und damit ein
+Wiederaufbau eine Vorlage hat. Jede Sicherung (`deploy/backup.sh`) nimmt die echten Dateien ohnehin mit.
+
+| Datei hier | Ort auf der Box |
+|---|---|
+| `hermes-builtin-ui.service` | `~/.config/systemd/user/hermes-builtin-ui.service` |
+| `hermes-builtin-ui.service.d-override.conf` | `~/.config/systemd/user/hermes-builtin-ui.service.d/override.conf` |
+| `llama-swap.service` | `/etc/systemd/system/llama-swap.service` |
+| `llama-swap.service.d-vulkan.conf` | `/etc/systemd/system/llama-swap.service.d/vulkan.conf` |
+| `llama-swap.service.d-warmset.conf` | `/etc/systemd/system/llama-swap.service.d/warmset.conf` |
+| `llama-swap.service.d-warmup.conf` | `/etc/systemd/system/llama-swap.service.d/warmup.conf` (ruft `/usr/local/bin/llama-swap-warmup.sh`, Vorlage `deploy/warmup.sh`) |
+
+Beim Hermes-Dashboard gilt der Drop-in, nicht die Kommentare der Basis-Unit: Es bindet an `0.0.0.0:9119`, weil Hermes
+seine Anmeldung auf `127.0.0.1` abschaltet; ufw hält den Port zu, erreichbar ist es nur über `/hermes-ui/` im
+Orchestrator. Seit 25.09.2026 startet es über den Starter der neuen Hermes-Umgebung (`hermes pm`), und das feste
+Session-Token der früheren Desktop-Anbindung ist weg.
+
+Die alte Unit `hermes-dashboard.service` (abgeschaltet, alte Umgebung) steht als Altrest im Aufräumen-Panel.

deploy/nur-box/hermes-builtin-ui.service

@@ -0,0 +1,19 @@
+[Unit]
+Description=Hermes Built-in Web UI (hermes dashboard — Agent-Dashboard/Chat, nur ueber MC2 /hermes-ui/)
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+# Serviert die EINGEBAUTE Hermes-Web-GUI (die reiche Agent-Oberflaeche mit Threads/Tool-Calls) headless.
+# Erreichbar nur ueber den MC2-Reverse-Proxy (routers/hermes_ui.py → same-origin /hermes-ui/ auf Port 9001).
+# Der Drop-in override.conf bindet an 0.0.0.0, damit Hermes' Anmeldung greift (auf 127.0.0.1 schaltet Hermes
+# sie ab); ufw haelt 9119 zu. --skip-build nutzt das von deploy.sh mit Vite-base=/hermes-ui/ vorgebaute web_dist.
+# Seit 25.09.2026 ueber den Starter der neuen Hermes-Umgebung (hermes pm) statt der alten venv (3.11).
+Type=simple
+Environment=HERMES_HOME=%h/.hermes
+ExecStart=%h/.hermes/hermes-agent/.hermes/bin/hermes dashboard --no-open --skip-build --host 127.0.0.1 --port 9119
+Restart=always
+RestartSec=3
+
+[Install]
+WantedBy=default.target

deploy/nur-box/hermes-builtin-ui.service.d-override.conf

@@ -0,0 +1,9 @@
+# Stufe 1 (20.08.2026), bereinigt 21.08. und 25.09.2026: Das Dashboard bindet nach aussen, damit
+# seine Anmeldung greift — auf 127.0.0.1 schaltet Hermes sie ab (hermes_cli/dashboard_auth: „no-op
+# on loopback“), dann waere es ueber MC2s /hermes-ui-Proxy ohne Login offen. Port 9119 ist in ufw ZU —
+# erreichbar nur ueber MC2 auf 9001. Zugangsdaten stehen NUR in config.yaml (dashboard.basic_auth).
+# Seit 25.09.2026 ueber den Starter der neuen Hermes-Umgebung (hermes pm, Python 3.14) statt des alten
+# venv (3.11); das feste Session-Token der frueheren Desktop-Anbindung ist weg (liegt im Archiv).
+[Service]
+ExecStart=
+ExecStart=%h/.hermes/hermes-agent/.hermes/bin/hermes dashboard --no-open --skip-build --host 0.0.0.0 --port 9119

deploy/nur-box/llama-swap.service

@@ -0,0 +1,16 @@
+[Unit]
+Description=llama-swap (lokaler LLM Router)
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+Type=simple
+User=hitonabi
+Environment=HSA_OVERRIDE_GFX_VERSION=11.5.1
+Environment=PATH=/usr/local/bin:/usr/bin:/bin
+ExecStart=/usr/local/bin/llama-swap --config /etc/llama-swap/config.yaml --listen 0.0.0.0:8080 --watch-config
+Restart=on-failure
+RestartSec=3
+
+[Install]
+WantedBy=multi-user.target

deploy/nur-box/llama-swap.service.d-vulkan.conf

@@ -0,0 +1,2 @@
+[Service]
+Environment=LD_LIBRARY_PATH=/opt/llamacpp-vulkan

deploy/nur-box/llama-swap.service.d-warmset.conf

@@ -0,0 +1,8 @@
+[Service]
+# 25.07.2026 — KORREKTUR. Hier standen kurzzeitig "fast coder kritiker": das schob
+# ~35 s Modell-Laden VOR das Vorkauen von Hermes' Agenten-Prompt (warmup.sh warmt erst
+# alle Chat-Modelle, dann Embeddings, DANN den Agenten-Prompt). Der Tool-Smoke im
+# hermes-postcheck hat 90 s Limit und lief dadurch in die Zeitueberschreitung.
+# Der Coder waermt sich beim ersten Auftrag selbst (23 s einmalig, dann 90 min warm) —
+# Lucys Hirn und der Agenten-Prompt haben Vorrang.
+Environment=MC_WARMUP_MODELS=fast

deploy/nur-box/llama-swap.service.d-warmup.conf

@@ -0,0 +1,2 @@
+[Service]
+ExecStartPost=-/usr/local/bin/llama-swap-warmup.sh

deploy/restore.sh

@@ -137,9 +137,10 @@ systemctl --user stop $SERVICES 2>/dev/null || true
 # Hermes-Desktop-/Gate-Infrastruktur (Gegenstück zu backup.sh, 09.07.2026):
 [ -d "$STAGE/hermes/agent-hooks" ]                && { mkdir -p "$HERMES/agent-hooks"; cp -a "$STAGE/hermes/agent-hooks/." "$HERMES/agent-hooks/"; chmod +x "$HERMES/agent-hooks/"*.sh 2>/dev/null || true; }
 [ -f "$STAGE/hermes/shell-hooks-allowlist.json" ] && cp -a "$STAGE/hermes/shell-hooks-allowlist.json" "$HERMES/"
-[ -f "$STAGE/hermes/desktop-gateway-token" ]      && { cp -a "$STAGE/hermes/desktop-gateway-token" "$HERMES/"; chmod 600 "$HERMES/desktop-gateway-token"; }
 [ -f "$STAGE/hermes/pc-paths.yaml" ]              && cp -a "$STAGE/hermes/pc-paths.yaml" "$HERMES/"
-[ -f "$STAGE/hermes/systemd-dropins/session-token.conf" ] && { mkdir -p "$HOME/.config/systemd/user/hermes-builtin-ui.service.d"; cp -a "$STAGE/hermes/systemd-dropins/session-token.conf" "$HOME/.config/systemd/user/hermes-builtin-ui.service.d/"; chmod 600 "$HOME/.config/systemd/user/hermes-builtin-ui.service.d/session-token.conf"; systemctl --user daemon-reload 2>/dev/null || true; }
+# Ältere Sicherungen enthalten noch das feste Dashboard-Token der früheren Desktop-Anbindung (desktop-gateway-token,
+# systemd-dropins/session-token.conf). Seit 25.09.2026 wird es bewusst NICHT zurückgespielt: Ohne festes Token würfelt
+# das Dashboard pro Start ein neues.
 # Cron-Jobs + Radar-State (Gegenstück zu backup.sh, 10.07.2026) — der Gateway-Neustart unten
 # lädt die wiederhergestellten Jobs:
 [ -d "$STAGE/hermes/cron" ]  && { mkdir -p "$HERMES/cron";  cp -a "$STAGE/hermes/cron/."  "$HERMES/cron/"; }

deploy/self-repair.sh

@@ -19,7 +19,8 @@ HERMES="${HERMES_HOME:-$HOME/.hermes}"
 CFG="$HERMES/config.yaml"
 WARN_FILE="${HERMES_CONFIG_WARNINGS:-/tmp/hermes-config-warnings.txt}"
 LLAMA="${LLAMA_SWAP_URL:-http://127.0.0.1:8080}"
-VENV_PY="$HERMES/hermes-agent/venv/bin/python"
+# System-Python (hat PyYAML) statt der alten Hermes-venv, die seit dem Umstieg auf `hermes pm` (25.09.2026) wegfällt.
+YAML_PY="$(command -v python3)"
 export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}"
 
 say(){ echo "[self-repair] $*"; }
@@ -78,7 +79,7 @@ if [ -z "$CHANGED" ]; then
 fi
 
 # ── 3) YAML noch gültig? ──────────────────────────────────────────────────────
-if [ -x "$VENV_PY" ] && ! "$VENV_PY" -c "import yaml; yaml.safe_load(open('$CFG'))" 2>/dev/null; then
+if [ -x "$YAML_PY" ] && ! "$YAML_PY" -c "import yaml; yaml.safe_load(open('$CFG'))" 2>/dev/null; then
   say "YAML nach Fix ungültig → zurück zum Backup."
   cp -a "$BAK" "$CFG"; echo "SELFREPAIR_SUGGESTION=$SUGG"; exit 2
 fi

deploy/skills/pc-pfad-cache/pc_path_lookup.sh

@@ -14,8 +14,8 @@ set -euo pipefail
 
 MODUS="${1:?FEHLT: lookup|merken|liste}"
 YAML_FILE="$HOME/.hermes/pc-paths.yaml"
-PY="$HOME/.hermes/hermes-agent/venv/bin/python"
+# System-Python hat PyYAML; die alte Hermes-venv fällt seit dem Umstieg auf `hermes pm` (25.09.2026) weg.
-[ -x "$PY" ] || PY=python3
+PY=python3
 
 normalize() {
   # Umlaute ZUERST ausschreiben (beide Fälle — tr lowercased kein Ä/Ö/Ü), dann klein,

docs/wissen/OFFENE-FAEDEN.md

@@ -1,6 +1,6 @@
 # Offene Fäden — die eine Liste
 
-_Stand 25.09.2026 vormittags. Neues hier rein, Erledigtes raus (die Git-Historie behält es). Entschiedenes steht in
+_Stand 25.09.2026 nachmittags. Neues hier rein, Erledigtes raus (die Git-Historie behält es). Entschiedenes steht in
 [VERDIKTE.md](VERDIKTE.md), nicht hier. Die Liste bis 04.09.2026, samt den Lucy-Fäden, liegt im Archiv:
 [2026-09-04-offene-faeden-alt.md](../archiv/2026-09-04-offene-faeden-alt.md)._
 
@@ -24,22 +24,27 @@ zwei Minuten, Meldung auf Telegram, der Snapshot bleibt als Rückweg liegen. Dan
 Technik: [ARCHITEKTUR.md](../ARCHITEKTUR.md), Abschnitt „Der Homelab-Teil“; Einrichtung und Betrieb:
 [BETRIEB.md](../BETRIEB.md).
 
+## Ausbauplan (Klärungsrunde 25.09.2026)
+
+Der User hat alle Wellen des Feature-Ausbauplans freigegeben (Plan-Dokument, Abschnitt „Feature-Ausbauplan“, jede
+Zeile mit Entscheid): erst Design v5 auf alle Seiten, dann Welle 1, 2, 3 und „Später“ nacheinander. Punkt 4 (Wartezeit
+für frische Versionen) entfällt; die Android-App (Phase 5) wird danach gemeinsam geplant. Festgelegt: Lucy mit mehr
+Freiheit (Sicherheitsupdates und Rückweg bei Rot selbst, Meldung danach; sonst nach Ja), Wartungsfenster So
+03:00–04:15 mit anfangs nur Sicherheitsupdates automatisch, ein „ja“ in Telegram löst genau die gefragte Aktion aus,
+„Übernehmen“ bei neuen Geräten setzt das Etikett, Konfig-Sicherung geschwärzt in ein privates Gitea-Repo, kein
+Web-Push (Telegram bleibt), Arcane-Lücken-Scan sonntags 02:00, NAS-Platten über SNMP.
+
 ## Offene Einzelpunkte (Homelab)
 
-0. **AdGuard (Container 100): Aufbewahrung des Abfrageprotokolls auf 14 Tage (User, 25.09. angesagt).** Am 24.09. war
+- **Zugang von außen:** Der Eintrag `mc.tobisniceshomelab.ddnsfree.com` in NPMplus (Proxy-Host 14 → Box :9001) hatte
-   die 2-GB-Platte voll (Abfrageprotokoll, eingestellt: 90 Tage). Mit User-Ja wurde die alte Datei `querylog.json.1`
+  keine Zugangsliste. Der User hängt die vorhandene Liste (die an nginx., pvescriptslocal. und rippy.) auch an mc.
-   vom 09.08. (539 MB) gepackt auf den Proxmox-Host gelegt (`/root/mc2-archiv/adguard-querylog-bis-2026-08-09.json.zst`,
+  (User, 25.09. zugesagt). Prüfen: `pct exec 101 -- grep -c auth_basic_user_file /opt/npmplus/nginx/proxy_host/14.conf`.
-   44 MB) und aus dem Container genommen. Seit dem Abend schreibt AdGuard wieder (25.09.: 485 MB seit 09.08., gut
+- **NAS-Platten (SNMP):** Der User schaltet am QNAP SNMP v1/v2 ein; den Zugangsnamen trägt er in den Einstellungen ein.
-   10 MB am Tag, Platte 72 %). Weg in AdGuard: Einstellungen → Allgemeine Einstellungen → Konfiguration der
-   Protokolle → Rotation der Abfrageprotokolle → Benutzerdefiniert, 336 Stunden → Speichern. AdGuard behält die
-   laufende und die vorige Datei; die jetzige (ab 09.08.) wird beim ersten Rotieren zur vorigen und fällt 14 Tage
-   später weg. Danach bleiben rund 300 MB. Volle Gastplatten meldet seit 24.09. der Wächter.
 
-1. **Arcane-VM (106): Discard einschalten (User).** Ihre Platte belegt im Speicherpool 161 GB, genutzt sind darin
+Erledigt am 25.09. nachmittags: AdGuard-Abfrageprotokoll auf 7 Tage (User); Discard für die Arcane-VM 106 an
-   35 GB (25.09.): Discard ist aus, freigegebener Platz kommt nie im Pool an. In Proxmox: VM 106 → Hardware →
+(`discard=on,ssd=1`, einmal `fstrim`: 122 GB zurück, Speicherpool 50 % → 17 %, Ubuntu trimmt ab jetzt wöchentlich);
-   Festplatte → „Discard“ anhaken, VM einmal neu starten (Docker-Dienste kurz weg); danach gibt Ubuntu freien Platz
+**Rückweg-Probe** gebaut und mit PVE Scripts echt bewiesen (Snapshot → absichtlich rot → zurück → läuft und antwortet,
-   wöchentlich zurück. Steht als Empfehlung in der Karte „Speicher und Sicherungen“; nötig erst, wenn der Pool knapp
+gut 3 Minuten).
-   wird (heute 49 %).
 
 Erledigt am 25.09.: Arcane-API-Schlüssel (vom User eingetragen, Docker-Updates echt), feste IP 192.168.178.31 für
 Container 107 (Fritzbox, User), Etikett `watcher` für die Arcane-VM 106 (User-Ja; der Ausführer legt vor echten
@@ -49,11 +54,12 @@ Docker-Updates einen Snapshot an und geht bei Rot zurück). OS-Updates der VM ü
 
 ## Offene Einzelpunkte (Box-Wart)
 
-1. **Session-Token des Hermes-Dashboards (nur mit User-Ja).** Das Drop-in
+Erledigt am 25.09.: Das feste Session-Token des Hermes-Dashboards (Drop-in `session-token.conf` und
-   `hermes-builtin-ui.service.d/session-token.conf` aus der früheren Desktop-Anbindung ist weiter gesetzt; `backup.sh`
+`desktop-gateway-token` der früheren Desktop-Anbindung) liegt im Archiv `~/.hermes/archiv-20260925-dashboard`, wird
-   und `restore.sh` sichern es samt Kopie `desktop-gateway-token`. Entfernen ist Security-Config.
+weder gesichert noch zurückgespielt. Das Dashboard startet über den Starter der neuen Hermes-Umgebung und bindet
-2. **Units nur auf der Box:** `hermes-builtin-ui.service` samt Drop-ins und die llama-swap-Drop-ins (darunter
+weiter an 0.0.0.0 — auf 127.0.0.1 schaltet Hermes seine Anmeldung ab; ufw hält 9119 zu (vom PC gegengeprüft). Die
-   `warmset.conf`) liegen nicht im Repo; seit 24.09. stehen sie als Kopie in jeder Sicherung.
+Units, die nur auf der Box leben, stehen als Kopie in `deploy/nur-box/`. Die tote Cron-Zeile für
+`curator-idle-watchdog.sh` ist raus (alte crontab im selben Archiv).
 
 ## Aufräumen auf der Box (nur per User-Klick)
 
@@ -69,13 +75,13 @@ Docker-Updates einen Snapshot an und geht bei Rot zurück). OS-Updates der VM ü
   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.
+- Neu im Panel „Altreste“ (25.09.): die alte Hermes-Umgebung (Python 3.11) samt Sicherung, zusammen ~11 GB —
+  empfohlen erst nach einem grünen Sonntagslauf (27.09.) löschen. Modelle ohne Rolle (gpt-oss-120b, Qwen3-VL-30B)
+  hat der User zum Löschen freigegeben; er klickt es selbst (endgültiges Löschen macht Claude nicht).
 
 ## Beobachten
 
-- **25.09. 00:30:** Radar-Neutest Ornith-1.5-35B-A3B (Hirn), jetzt mit Draft-Varianten. **01.10.:** Qwen3.8-Flash-Next
+- **01.10.:** Radar-Test Qwen3.8-Flash-Next (Coder, passt nur knapp). Ornith-1.5-35B-A3B (Hirn) fiel am 25.09. durch.
-  (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. 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
+- **Daily News 07:00:** Am 25.09. lief sie ohne `web_extract`-Fehler (Plugin `mc2-web-lesen`); weiter beobachten.
-  (Hermes am 24.09. neu gestartet).