doku: Historisches ins Archiv, Ueberfluessiges geloescht

- 19 Dateien nach docs/archiv/ mit Datumspraefix (JJJJ-MM-TT-): SAVEPOINT, Autonomie-,
  Optimierungs- und TTS-Plan, Review 02.07., ZeroClaw-Auftrag und -Ergebnis, Hermes-Setup,
  Gemini-Briefing, Antigravity-Review-Prompt, Zielbild, Uebergabe Drei Welten,
  Umbauplan Abloesung, Hermes-Werkzeuge, Raphael, die drei Dateien aus docs/aufgaben
  und der Skill-Text gitea-workflow.
- Die alte Liste OFFENE-FAEDEN (Stand 04.09.) ebenfalls ins Archiv; sie enthaelt die
  Lucy-Faeden, die sonst verloren gingen. Die neue Liste folgt im naechsten Schritt.
- Geloescht (kein eigenes Wissen, Git-Historie reicht): docs/memory/* (4 Kopien der
  Claude-Notizen vom Juni), STATUS, CUTOVER, AUDIT_KICKOFF, CLAUDE_CODE_BRIEF,
  UPGRADE und skills/orchestrator.md (Quelle war der Skill selbst).
- Formatfehler im Archiv behoben: uebrig gebliebene </content>-Tags im Optimierungsplan
  und im ZeroClaw-Auftrag; toter Link auf GEDAECHTNIS-BEREICHE.md zeigt jetzt auf die
  Git-Historie (geloescht am 07.08., c3851f8).

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

docs/AUDIT_KICKOFF.md

@@ -1,75 +0,0 @@
-# Kickoff: Voll-Audit MC2 (Front+Backend) + Box-SSH + Optimierungsplan
-
-> Für eine **frische Claude-Code-Session mit echtem Terminal** (direkter SSH-Zugang zur Box).
-> Aufgabe vom Nutzer: front/backend komplett scannen (IST-Zustand), via SSH auf die Box gehen
-> (ausdrücklich erlaubt), und am Ende einen **sauberen, strukturierten Plan** liefern, wie es
-> weitergeht — inkl. Optimierungen für ALLE LLM-Rollen und einem **neuen `scout`-Modell**.
-> Erst auditieren/planen — keine destruktiven Änderungen ohne Plan-Freigabe.
-
-## Zugänge
-- **Repo (Dev-PC):** `F:\Coding Stuff\mission-control-2` (Windows). Auf der Box: `~/mission-control-v2`.
-- **Box:** `ssh hitonabi@192.168.178.151` (key-based, funktioniert non-interaktiv). Hostname
-  `tobisniceaiarbeitstier`, AMD Ryzen AI MAX+ 395 (Strix Halo), 122 GB RAM, GTT ~124 GB, Vulkan/RADV.
-- **Wichtige Box-Pfade:** `/etc/llama-swap/config.yaml` (Engine, `-watch-config`),
-  `~/.hermes/config.yaml` (Hermes-Agent = Lucys Hirn), `/srv/models/` (GGUFs),
-  `/opt/llamacpp-vulkan/llama-server` (Engine v9843).
-- **Dienste (systemd --user):** `hermes-gateway` (:8642), `hermes-webui` (:8787), llama-swap (:8080),
-  MC2-Gateway (:9001). Live-Logs: `journalctl --user -u hermes-gateway -f`.
-
-## Architektur (verifiziert 30.06.2026)
-- **llama-swap** (:8080) lädt GGUFs; Rollen = llama-swap **`aliases`**; Warm-Bleiben über
-  `groups: { brains: { swap:false } }` + `ttl`.
-- **MC2-Gateway** (:9001/v1, FastAPI) mit virtuellen Lanes `chat`(→fast/heavy) & `coding`(→coder_lite/coder).
-  Code: `backend/services/router_logic.py`, `routing_policy.py`, `roles.py`, `llamaswap.py`, `budget.py`,
-  `fit.py`; Router `backend/routers/{models,routing,voice}.py`. Frontend: `frontend/src/views/ModelsView.tsx`,
-  `components/models/*`, `SystemDrawer.tsx`.
-- **Hermes-Agent** (:8642) = Lucys Hirn (`~/.hermes/config.yaml: model.default`), Delegation `heavy`.
-- **Lucy-Client** (`client/lucy-desktop`, Electron) spawnt lokal pocket-tts (:8130); Persona+Umlaut-Logik
-  im Client (`renderer/src/config.ts`, `lib/voice/useVoiceAgent.ts`).
-- **Features sind eigene Rollen** (hirn-unabhängig): Sehen=`Qwen3-VL-8B`, Hören=Whisper(`stt`),
-  Sprechen=pocket-tts, Embedding=`Qwen3-Embedding-0.6B`(ttl 0, immer warm), Gedächtnis=Mem0/MCP.
-
-## Modelle / Rollen (Stand jetzt)
-| Rolle (alias) | Modell | aktiv | ctt/ttl | Notiz |
-|---|---|---|---|---|
-| fast | Qwen3.6-35B-A3B | 3B | ttl 0, --parallel 2, mmproj | chat-Lane Default |
-| heavy | Qwen3.5-122B-A10B | 10B | ttl 600 | Delegation-Ziel |
-| coder | Qwen3-Coder-Next | — | ttl 600, spec draft-simple (Qwen3-0.6B) | |
-| coder_lite | Qwen3-Coder-30B-A3B | 3B | ttl 300 | coding-Lane Default |
-| vision | Qwen3-VL-8B-Instruct | — | ttl 300 | Screen-Beschreibung |
-| (embedding) | Qwen3-Embedding-0.6B | — | ttl 0 | immer warm |
-| **brain (NEU, Lucy)** | **gemma-4-26B-A4B-it** | 4B | ttl 0, **noch Alias `scout`** | Hermes default seit 30.06. |
-
-## Bereits gemacht (30.06.)
-- Lucys Hirn `fast` → **`gemma-4-26B-A4B-it`** (`~/.hermes/config.yaml model.default`, Backup
-  `~/.hermes/config.yaml.gemma-swap.bak`, hermes-gateway neu gestartet, verifiziert).
-- Umlaut-Fix: Client-Stammliste erweitert (`useVoiceAgent.ts`) **und** Server-Netz `_fix_umlauts`
-  (`client/lucy-tts/pocket_server.py`). Hermes-System-Prompt fordert echte Umlaute (Client-Persona).
-- pocket-tts getunt: A1 safetensors-Voice-Cache, A2 Referenz-Cleaning, B3 FP-Gate skip kurze Audios,
-  FAST_FIRST (kurzer 1. Chunk, TTFB ~1,3s), seriell (WORKERS=0) als Default. Details: `docs/LUCY_TTS_PLAN.md`.
-
-## Offene Probleme / Aufgaben
-1. **Brain-Rolle fehlt als Konzept.** gemma läuft als Alias `scout`, ist NICHT in `brains: swap:false`
-   → unter Speicherdruck evakuierbar trotz ttl 0. Detail-Brief: **`docs/CLAUDE_CODE_BRIEF_lucy-brain-role.md`**
-   (Backend+Frontend-Umbau: erstklassige `brain`-Rolle, auto-warm/ko-resident, Hermes-Sync).
-2. **`scout`-Rolle jetzt vakant** (gemma war scout, ist jetzt Hirn). **Neues scout-Modell suchen:**
-   multimodaler Allrounder, klein/MoE (schnell, KO-Residenz-freundlich), Tools wünschenswert. Tagesaktuell
-   recherchieren + Empfehlung.
-3. **MTP-Speculative-Decoding für gemma** (1,5–2× Durchsatz, 0 Qualitätsverlust): Engine kann `draft-mtp`
-   ✓; MTP-Drafter `gemma-4-26B-A4B-it-assistant` (~0,4B) muss nach `/srv/models/`, gemma-cmd ergänzen
-   (`-md <assistant.gguf> --spec-type draft-mtp --spec-draft-n-max/-n-min`; **alte** `--draft-max/-min`
-   sind entfernt!). MC2-UI/Backend kennt MTP-Drafter nicht (zeigte „Vocab ?") → erweitern. (Im Brain-Brief.)
-4. **Optimierung ALLER Rollen prüfen:** je Modell ctx/quant/ttl/Warm-Gruppe/Parallelität/Spec-Decoding
-   (MTP für Gemma; Draft-Eignung für Qwen-Modelle) gegen das GTT-/RAM-Budget (~124 GB) und reale t/s
-   auf Strix Halo (bandbreitenlimitiert → MoE bevorzugt; dichte Modelle langsam). KO-Residenz-Set
-   sinnvoll definieren (was muss gleichzeitig warm sein für Lucy + IDE-Coding?).
-
-## Deliverable
-Ein **strukturierter Plan** (z.B. `docs/OPTIMIZATION_PLAN.md`): IST-Zustand → konkrete Maßnahmen je Rolle
-(mit Begründung/Zahlen) → Reihenfolge/Risiko/Revert → offene Entscheidungen. Erst Plan, dann Umsetzung
-nach Freigabe. Alles reversibel (Config-Backups vor jeder Änderung).
-
-## Leitplanken
-- Features (Sehen/Hören/Sprechen/Embedding/Gedächtnis) + IDE-Lanes dürfen NICHT brechen.
-- Vor jeder Box-Config-Änderung Backup; llama-swap reloadt per `-watch-config`.
-- Keine destruktiven Aktionen ohne Plan-Freigabe des Nutzers.

docs/CLAUDE_CODE_BRIEF_lucy-brain-role.md

@@ -1,106 +0,0 @@
-# Claude-Code-Auftrag: „Brain"-Rolle für Lucy (Front- + Backend-Umbau)
-
-> Ziel: Lucys Hirn (aktuell `gemma-4-26B-A4B-it`) als **erstklassige, dauer-warme Rolle** im MC2-Stack
-> verankern — statt es als `scout` zu führen, das nach `ttl` entladen wird. Features (Sehen/Hören/
-> Sprechen/Embedding) dürfen NICHT verloren gehen, KO-Residenz + Budget müssen sauber bleiben.
-
-## Kontext / Architektur (Ist-Zustand, verifiziert 30.06.)
-- **Engine:** llama-swap (config: `/etc/llama-swap/config.yaml` auf der Box, läuft mit `-watch-config`).
-  Rollen werden als llama-swap **`aliases`** gesetzt; Warm-Bleiben über `groups:` (eine Gruppe
-  `brains: { swap: false }`) + `ttl`. Installierte Modelle: `Qwen3.6-35B-A3B` (fast, ttl 0),
-  `Qwen3.5-122B-A10B` (heavy, ttl 600), `Qwen3-Coder-Next` (coder, ttl 600),
-  `Qwen3-Coder-30B-A3B-Instruct` (coder_lite, ttl 300), `Qwen3-VL-8B-Instruct` (vision, ttl 300),
-  `Qwen3-Embedding-0.6B` (ttl 0 = immer warm), `gemma-4-26B-A4B-it` (ttl 180).
-- **Gateway:** MC2 builtin auf `:9001/v1` mit virtuellen Lanes `chat` (→ fast/heavy) und
-  `coding` (→ coder_lite/coder). Code: `backend/services/router_logic.py`, `routing_policy.py`.
-  **Lucy nutzt die Lanes NICHT** — sie ist der Hermes-Agent.
-- **Lucy-Hirn:** Hermes-Agent (`:8642`), Brain = `~/.hermes/config.yaml` → `model.default`
-  (jetzt `gemma-4-26B-A4B-it`), Delegation = `heavy`. Persona/Prompt kommt aus dem **Client**
-  (`client/lucy-desktop/src/renderer/src/config.ts`), nicht aus der Box-Config.
-- **Hardware:** Strix Halo (Ryzen AI Max+ 395), 122 GB, GTT ~124 GB, bandbreitenlimitiert →
-  MoE mit wenig aktiven Params ist schnell, dichte Modelle langsam.
-
-## Root-Cause des Bugs
-1. Kanonische Rollen `ROLE_IDS = {fast, heavy, coder, vision, scout}` — **keine `brain`/Agent-Rolle**.
-   (Kommentar im Code: „kein agent/reasoning mehr".)
-2. Es gibt keine Verknüpfung „Hirn-Modell ⇒ muss warm bleiben". gemma trägt den Alias `scout`,
-   ist NICHT in der `brains`-Gruppe, `ttl 180` → entlädt im Leerlauf → Lucy lädt kalt nach (~5–10 s).
-3. `roles.py` referenziert noch eine `hermes`-Rolle, die in `ROLE_IDS` nicht existiert → Inkonsistenz.
-
-## Aufgabe
-
-### Backend (`backend/`)
-1. **Neue erstklassige Rolle `brain` einführen** (oder `hermes` reaktivieren) und in ALLEN
-   Quellen synchronisieren (heute dupliziert!):
-   - `services/llamaswap.py` → `ROLE_IDS`
-   - `services/sources.py` → `ROLE_IDS` + Titel/Icon (analog `scout: {title, icon}`)
-   - `services/maintenance.py` (Modell-Upgrade-Rollenliste)
-   - `services/roles.py` → `_capability_suit`/`_pref`/`_reason` für `brain` (Tools Pflicht,
-     mittlere Größe + MoE bevorzugt, niedrige Latenz). `hermes`-Altlast bereinigen.
-2. **Rolle `brain` ⇒ automatisch warm + ko-resident.** Beim Zuweisen der `brain`-Rolle
-   (`POST /api/models/{model_id}/role`, `routers/models.py`):
-   - Modell via `set_group("brains", members=[...], swap=False, persist=True)` in die Warm-Gruppe
-     aufnehmen (bestehender Helper in `llamaswap.py`).
-   - `ttl: 0` setzen (oder hoch), vorheriges Brain-Modell aus `brains` entfernen + ttl entspannen.
-   - Embedding (`Qwen3-Embedding-0.6B`, ttl 0) MUSS warm bleiben — nicht verdrängen.
-3. **Single Source of Truth für „Lucys Hirn":** beim Setzen der `brain`-Rolle auch Hermes'
-   `~/.hermes/config.yaml` → `model.default` auf das Modell setzen + `systemctl --user restart
-   hermes-gateway` (mit Backup der config). So bleibt MC2-UI-Auswahl ↔ Hermes-Brain konsistent.
-4. **Budget/KO-Residenz-Safety:** Brain(warm) + Embedding(warm) + on-demand Vision + Coder müssen
-   in GTT (~124 GB) passen. `services/budget.py`/`fit.py` nutzen, bei OOM warnen (nicht hart laden).
-5. **Lanes/IDEs unangetastet lassen:** chat/coding-Routing (`router_logic.py`) bleibt wie es ist;
-   `fast` bleibt für die chat-Lane warm.
-
-### Frontend (`frontend/src/`)
-1. **Rollen-Taxonomie** um `brain` erweitern (Badges/Titel/Icon) — Duplikat zur Backend-Liste
-   finden & angleichen (`components/models/*`, `views/ModelsView.tsx`, evtl. `ModelBadges.ROLES`).
-   gemma darf NICHT mehr als `scout` erscheinen.
-2. **Rollen-Zuweisungs-Modal:** `brain` auswählbar; Warm-/KO-Residenz-Status anzeigen
-   (ist das Brain in `brains`? warm? ttl?). Empfehlung via bestehendem `/api/roles/{role}/recommend`.
-3. **Warm-Set / GTT-Budget sichtbar machen** (Dashboard/Models): was ist gerade ko-resident,
-   passt es ins Budget? (nutzt `/api/models` `running` + budget-Infos).
-4. Optional: „Lucy-Hirn"-Selector, der die `brain`-Rolle setzt (treibt Backend #2 + #3).
-
-### Zusatz: MTP-Speculative-Decoding für Gemma (Durchsatz für agentische Arbeit)
-Lucy ist ein **voller Agent** (Tools/MCP/PC-Control/Vision/Delegation) — Durchsatz zählt, nicht nur
-TTFB. Gemma 4 bringt **MTP** (Multi-Token-Prediction) mit → 1,5–2× schneller bei null Qualitätsverlust.
-- **Engine kann es bereits:** `llama-server` v9843 listet `--spec-type … draft-mtp …`. ✓
-- **Vocab-kompatibler „Draft" = Gemmas eigener MTP-Kopf** `gemma-4-26B-A4B-it-assistant` (~0,4B,
-  identischer Tokenizer per Konstruktion). Quelle z.B. `unsloth/gemma-4-26B-A4B-it-GGUF` (enthält den
-  MTP-Drafter, PR ggml-org/llama.cpp#23398). Muss nach `/srv/models/...` geladen werden (noch nicht da).
-- **Flag-Änderung beachten:** `--draft-max/--draft-min` sind ENTFERNT → `--spec-draft-n-max` /
-  `--spec-draft-n-min`. Drafter laden via `-md <assistant.gguf> --spec-type draft-mtp`. Exakte Flags
-  des Builds mit `llama-server --help` gegenprüfen.
-- **MC2-Bug:** die Spec-Draft-Auswahl (UI + Backend) kennt **nur klassische Drafts** (vergleicht stur
-  `n_vocab`/`pre`) und bot fälschlich nur den Qwen-Draft an („Vocab ?"). **Erweitern:** MTP-Drafter
-  (`gemma4_assistant`-Arch) als gültigen, vocab-kompatiblen Draft erkennen, den passenden `-assistant`-
-  GGUF anbieten, und beim Aktivieren `-md … --spec-type draft-mtp --spec-draft-n-max/-n-min` in die
-  llama-swap-cmd schreiben. Co-Residenz: Drafter ~0,4B → vernachlässigbar.
-
-## Akzeptanzkriterien
-- [ ] `gemma-4-26B-A4B-it` wird in der UI als **`brain`** geführt (nicht `scout`).
-- [ ] Es bleibt **warm**: in `brains: swap:false`, `ttl 0`; überlebt > alter ttl Leerlauf
-      (Verifikation: `curl :8080/running` nach >5 Min Idle zeigt das Modell weiterhin `ready`).
-- [ ] Lucy antwortet ohne Kalt-Nachladen nach Leerlauf.
-- [ ] Vision (`Qwen3-VL-8B`), Embedding (`Qwen3-Embedding-0.6B`), Coder bleiben funktionsfähig &
-      ko-resident; **kein OOM**; IDE-Lanes (chat/coding) unverändert.
-- [ ] Brain-Wechsel in der UI aktualisiert llama-swap (Warm-Gruppe) UND Hermes `model.default`
-      (+ Restart), reversibel (Backup).
-
-## Sofort-Hotfix (unabhängig vom Umbau — macht Lucy JETZT warm)
-Auf der Box, bis der saubere Umbau steht:
-```bash
-# gemma als immer-warm + in die brains-Gruppe (Backup zuerst!)
-cp /etc/llama-swap/config.yaml /etc/llama-swap/config.yaml.bak
-# gemma ttl 180 -> 0  und  groups.brains.members um gemma-4-26B-A4B-it ergänzen
-# (manuell editieren oder via MC2 set_group), dann:
-# llama-swap reloadt per -watch-config automatisch.
-```
-
-## Wichtige Dateien (Einstieg)
-- Backend: `services/llamaswap.py` (Rollen=aliases, `set_role_alias`, `set_group`, `register_model`),
-  `services/roles.py`, `services/sources.py`, `services/routing_policy.py`,
-  `services/router_logic.py`, `services/budget.py`, `services/fit.py`, `routers/models.py`,
-  `routers/routing.py`.
-- Frontend: `views/ModelsView.tsx`, `components/models/*`, `components/SystemDrawer.tsx`.
-- Box (nicht im Repo): `/etc/llama-swap/config.yaml`, `~/.hermes/config.yaml`.

docs/CUTOVER.md

@@ -1,45 +0,0 @@
-# Cutover — Stand & Anleitung
-
-## Was auf der Box LÄUFT (verifiziert)
-- **MC2** auf `:9001` (sudo-freier User-Dienst, `~/mission-control-v2`). Update: `deploy/deploy.sh`.
-- **Modelle/Rollen:** `fast` = Qwen3.6-35B-A3B, `heavy` = Qwen3.5-122B-A10B, `coder` = Qwen3-Coder-30B,
-  `vision` = Qwen3-VL-8B, `scout` = Qwen3-8B, `hermes` = Hermes-4-14B (immer warm, ttl 99999). Alle
-  tool-fähig (`--jinja` wo nötig). Legacy `manager`/`reviewer` entfernt.
-- **Gateway (eingebaut, `:9001/v1`, OpenAI-kompatibel):** `model: auto` → kurz/Standard = `fast`,
-  lang/komplex = `heavy`. End-to-End verifiziert.
-- **Hermes:** **eigenes festes Hirn = Hermes-4-14B** (`model.model: hermes`) + **Delegation an `heavy`**.
-  `model:auto` ist NUR für Vibe Coding/IDEs, nicht Hermes. MCP verdrahtet: `mission-control-memory` +
-  `mission-control-stack`. Verifiziert: „bist du da?" → 3s, sauber, kein Thrash.
-- **Gedächtnis vereinheitlicht:** MC2 nutzt die bestehende DB (`mission-control-memory.db`) — geteilte
-  „Verfassung" für Cockpit, Hermes, IDEs.
-- **Cockpit-Features:** HF-Link/Suche-Install (W2), Rollen/ctx/löschen-UX (W3), Wartung (W8: OS/Engine-
-  Update, Restart, Reboot, Logs, dyn. Modell-Upgrades), Bedien-Anleitung (BEDIENUNG.md + Hilfe-Link).
-
-## Thrash-Fix (war der „Hermes ist dumm"-Grund)
-Ursache war NICHT das Modell/die Session, sondern **kaputte/Cloud-Tools im Toolset** (browser ohne Chrome
-→ Loop, vision auf Text, natives memory falsch aufgerufen). Global abgeschaltet über
-`agent.disabled_toolsets` in `~/.hermes/config.yaml` (Achtung: `hermes tools disable` greift nur cli,
-NICHT den api_server). Natives memory zusätzlich aus (`memory.memory_enabled:false`); geteiltes
-Gedächtnis bleibt via MCP. Behaltene Tools: web/terminal/file/code_execution/skills/todo/session_search/
-clarify/delegation/cronjob + 2 MCP.
-
-## Cutover-Schritte
-1. v2 läuft bereits auf `:9001` parallel — alles dort testen: `http://192.168.178.151:9001`.
-2. Vibe-Coding-Tools auf den Gateway zeigen (Verbinden-Tab → `:9001/v1`, `model: auto`).
-3. **v1 stilllegen** — bereits erledigt: `hermes-dashboard` (:9119) disabled (killte 4 v1-MCP-Zombies).
-   **Noch offen (braucht dein sudo, NOPASSWD deckt nur `restart`):**
-   ```
-   sudo systemctl disable --now mission-control      # v1-Cockpit :9000 aus
-   ```
-   `llama-swap` (System) + `hermes-gateway` (User) bleiben — die nutzt v2 weiter.
-4. Optional v2 auf den „Haupt"-Port legen — `MC_PORT` in der mc2-Unit.
-5. Backup vorher: Cockpit → System → „Backup jetzt".
-
-## Offene Tuning-/Setup-Punkte (kein Blocker)
-1. **nesquena hermes-webui** (:8787) installieren (Plan Block C) → „Hermes öffnen" zeigt darauf statt :9119.
-2. **Ko-Residenz** `hermes`+`fast` (swap:false, Plan Block E) — GTT beobachten, bei OOM-Nähe zurück.
-3. **SSH→Windows** (voller PC-Zugriff): OpenSSH-Server am Windows-PC + Key `id_ed25519_hermes_agent`.
-4. **sudoers erweitern** (`apt-get`, `reboot`) → OS-Update/Reboot klicki-bunti (Zeilen in BEDIENUNG.md).
-5. **Delegation an heavy** ist konfiguriert; triggert modell-diskretionär bei echt harten Teilaufgaben.
-
-> v1 bleibt bis zum `disable` lauffähig — Cutover ist reversibel (`sudo systemctl enable --now mission-control`).

docs/STATUS.md

@@ -1,57 +0,0 @@
-# Mission Control 2.0 — Status & Resume-Guide
-
-> So machst du jederzeit nahtlos weiter. Der vollständige Architektur-Plan liegt in
-> `C:\Users\TobisPC\.claude\plans\piped-cuddling-sloth.md` (genehmigt).
-
-## Wo das Projekt lebt
-- **Code:** `F:\Coding Stuff\mission-control-2` (Windows-Dev-PC) + Gitea-Remote
-  `https://git.tobisniceshomelab.ddnsfree.com/Hitonabi/mission-control-v2` (Branch `main`).
-- **v1** (`F:\Coding Stuff\mission-control`) wird abgelöst (Cutover läuft, s.u.).
-- **Box** (Bosgame, `192.168.178.151`): **MC2 LIVE auf :9001** als sudo-freier systemd-USER-Dienst
-  (`~/mission-control-v2`, Update via `deploy/deploy.sh`).
-
-## Gateway = builtin (NICHT LiteLLM)
-LiteLLM verlangt Python <3.14; die Box hat nur 3.14 (uvloop+orjson scheitern). Der **eingebaute
-Gateway** (`:9001/v1`, OpenAI-kompatibel) liefert `model:auto` (kurz→`fast`, komplex→`heavy`) +
-Streaming und ist E2E verifiziert. Vertrag (OpenAI-API) bleibt austauschbar.
-
-## Phasen-Fortschritt
-- [x] **Phase 0 — Gerüst:** FastAPI + React/shadcn-Shell (Cmd+K, Dark, PWA). Live auf Box.
-- [x] **Phase 1 — Engine + Routing:** Compute (fit/caps/sources), Discover (live HF), Engine-Write
-      (register + groups), **builtin Gateway** `model:auto`, Modelle&Routing-UI. Box-verifiziert.
-- [x] **Phase 2 — System/OS + Connect:** Metriken, Dienste, Self-Update, Connect-Snippets → Gateway.
-- [x] **Phase 3 — Memory + MCP:** Memory-UI, `mcp_memory.py` + `mcp_mc.py` (Stack-Management).
-- [x] **Phase 4 — Hermes-Schicht:** Agent-Status + AgentView; **Box: Hermes verdrahtet** (eigenes Hirn,
-      MCP memory+stack). hermes-webui (nesquena) = Block C offen.
-- [x] **Phase 5 — Betrieb/Politur:** Backup, Services-Health, Observability-Links, Theme-Toggle.
-- [x] **W1–W8** (Audit-Arbeitspaket): Thrash-Fix, HF-Install, Rollen-UX, BEDIENUNG.md, Wartung. ✅
-- [~] **Phase 6 — Cutover:** läuft (s.u.). v1-Dashboard+Zombies weg; v1 :9000 Stop offen (User-sudo).
-
-## Hermes-Hirn (Entscheidung 2026-06-25)
-Hermes hat ein **eigenes festes Hirn = Hermes-4-14B** (`model.model: hermes`, ttl 99999 = immer warm)
-+ **interne Delegation an `heavy`** (Qwen3.5-122B) für harte Teilaufgaben. **`model:auto` ist NUR
-Gateway/Vibe-Coding**, nicht Hermes. Verifiziert: „bist du da?" → **3s, sauber, kein Thrash**.
-
-## Box-Stand (Session 2026-06-25)
-- **8 Modelle**, Rollen sauber: `fast` (Qwen3.6-35B-A3B), `heavy` (Qwen3.5-122B-A10B), `coder`
-  (Qwen3-Coder-30B), `vision` (Qwen3-VL-8B), `scout` (Qwen3-8B), `hermes` (Hermes-4-14B). Legacy
-  `manager`/`reviewer`-Aliase entfernt (Modelle bleiben per Realname ladbar).
-- **Thrash behoben** (war NICHT die Session): kaputte Tools global via `agent.disabled_toolsets`
-  abgeschaltet (browser/vision/computer_use/image_gen/tts/video*/memory). Details: Memory
-  `hermes-thrash-rootcause-fix`. **`hermes tools disable` greift NICHT am api_server** — nur die config.
-- **Cutover teilweise:** `hermes-dashboard` (:9119) disabled (killte 4 v1-MCP-Zombies);
-  **v1 `mission-control.service` (:9000) läuft noch** → `sudo systemctl disable --now mission-control`.
-- MCP nutzt `/opt/mission-control/.venv/bin/python` (hat `mcp`-Modul) für v2-Skripte → /opt-Dir bleibt.
-
-## Nächste Schritte (siehe Plan „Nächste Schritte" + docs/CUTOVER.md)
-- **Block C:** nesquena hermes-webui (:8787) installieren → „Hermes öffnen" zeigt darauf.
-- **Block E:** Ko-Residenz `hermes`+`fast` (swap:false) testen, GTT beobachten.
-- **User-sudo:** v1 :9000 stoppen; sudoers für apt-get/reboot erweitern (OS-Update/Reboot).
-- Offen/user-seitig: SSH→Windows (OpenSSH am PC), v1-Passwort-Hygiene (Git-Historie).
-
-## Lokal entwickeln/verifizieren
-```bash
-cd backend && .venv/Scripts/python -m uvicorn app:app --port 9000   # Backend
-cd frontend && npm run dev                                          # http://localhost:5173
-cd frontend && npm run build                                        # Prod-Build (committet)
-```

docs/UPGRADE.md

@@ -1,35 +0,0 @@
-# Upgrades & Versions-Pins
-
-## Warum Pins
-Der Mem0-Sidecar nutzt mem0-**Interna** (NoThink-LLM-Swap, Roh-Zugriff auf die Chroma-Collection
-für den Graphen, Annahmen übers Result-Format). Ein unkontrolliertes mem0/chromadb-Upgrade kann das
-**still brechen**. Darum sind die Versionen in `mem0_service/requirements.txt` gepinnt — Upgrades
-passieren nur absichtlich.
-
-## Isolation (warum ein Upgrade nicht alles mitreißt)
-- mem0 lebt in `~/.mem0/venv` (Python 3.12) — getrennt vom MC2-Backend (3.14).
-- Die stabile Grenze nach außen ist **`/api/memory`**. UI, MCP (IDEs) und der Hermes-Provider
-  reden NUR damit, nie direkt mit mem0. Ein mem0-Upgrade betrifft also **nur den Sidecar**.
-
-## mem0 / chromadb sicher upgraden
-```bash
-cd ~/mission-control-v2
-bash deploy/backup.sh                                   # 1. Backup
-# 2. Pin anheben in mem0_service/requirements.txt (z.B. mem0ai==X.Y.Z)
-uv pip install --python ~/.mem0/venv/bin/python -r mem0_service/requirements.txt   # 3. installieren
-~/.mem0/venv/bin/python mem0_service/smoke_test.py      # 4. Smoke-Test (Wegwerf-Collection)
-```
-- **Grün** → `systemctl --user restart mem0-service`, fertig.
-- **Rot** → entweder den Sidecar (`mem0_service/app.py`) an die neue mem0-API anpassen, oder Pin
-  zurücksetzen und alten Stand per `deploy/restore.sh latest` wiederherstellen.
-
-## Weitere Upgrade-Fallen
-- **Embed-Modell wechseln** = andere Vektor-Dimension → Chroma muss **neu indiziert** werden
-  (alle Fakten neu einbetten). Aktuell: Qwen3-Embedding-0.6B / 1024 Dim.
-- **reagraph** ist auf **4.22.0** gepinnt — 4.23+ braucht `@react-three/fiber` v9 = React 19,
-  das Projekt ist React 18 (Crash „reading 'S'" sonst).
-- **Nach Hermes-Upgrades**: prüfen, dass `~/.hermes/plugins/mc2-memory` noch lädt und `sync_turn`
-  feuert — die `MemoryProvider`-ABC könnte sich ändern (ein Turn über den Gateway, dann
-  `curl /api/memory` checken).
-- **OS/Engine-Updates** (apt, llama.cpp) laufen separat über die UI (Wartungs-Drawer) und sind
-  von mem0 entkoppelt.

docs/archiv/2026-06-30-optimierungsplan.md

@@ -297,4 +297,3 @@ on-demand-Modelle laufen allein). Kein Box-Risiko, nur genauere ctx-Empfehlungen
   W1/W2 macht sie sogar robuster (kein OOM mehr).
 - Vor jeder Box-Config-Änderung Backup; llama-swap reloadt per `-watch-config`.
 - **Keine destruktiven Aktionen ohne Freigabe dieses Plans.**
-</content>

docs/archiv/2026-06-30-zeroclaw-poc-auftrag.md

@@ -80,4 +80,3 @@ Modell-Pflaster.
 - **Hermes/Lucy bleibt live** — PoC läuft isoliert (eigener Port, eigene Memory-Datei). Null Risiko.
 - Vor Box-Config-Änderungen Backup; llama-swap reloadt per `-watch-config`.
 - Erst messen (Prompt-Größe + Latenz), dann über vollen Umzug entscheiden.
-</content>

docs/archiv/2026-07-19-uebergabe-drei-welten.md

@@ -39,7 +39,7 @@ Playbook-Karte an `betrieb`. Beweis 19.07.: Homepage-Deploy auf LXC 106 in 92 s
 5. **Gedächtnis-Bereiche** statt zweitem mem0: neue Fakten tragen `bereich: alltag|projekt`;
    `GET /memory?bereich=` filtert (Alt-Fakten laufen immer mit). Einmal-Cron
    `gedaechtnis-check` (16.08. 09:10) prüft Schutt und legt bei Bedarf SELBST die
-   Werkstatt-Karte an — Bauauftrag komplett in [GEDAECHTNIS-BEREICHE.md](GEDAECHTNIS-BEREICHE.md).
+   Werkstatt-Karte an — Bauauftrag komplett in `docs/wissen/GEDAECHTNIS-BEREICHE.md` (am 07.08.2026 gelöscht, Commit `c3851f8`; nur noch in der Git-Historie).
 6. **Sicherheit:** Gitea-Registrierung AUS (app.ini `[service]` in CT 104 — Achtung:
    `deploy/gitea_app.ini.example` setzt den Key fälschlich in `[security]`, Gitea ignoriert
    das stumm!). ~157 GB Müll von der Box (u. a. 103 GB HF-Cache), Hermes Desktop komplett

docs/memory/project-hermes-setup.md

@@ -1,75 +0,0 @@
-> ⚠️ **TEILS VERALTET (Juni 2026, Archiv).** Aktueller Hermes-Stand (v0.18.2, delegation,
-> Toolset-Diät, Desktop): [docs/wissen/STACK.md](../wissen/STACK.md) +
-> [docs/wissen/FALLEN.md](../wissen/FALLEN.md). Der Zwei-Ebenen-Toolset-Gotcha hier gilt weiter.
-
----
-name: project-hermes-setup
-description: "Hermes Agent — vollständige Verdrahtung, MCP-Server, Telegram, PC-Executor (Stand 2026-06-27)"
-metadata: 
-  node_type: memory
-  type: project
-  originSessionId: e6bf38ac-b5dc-4aaa-80c3-ad8dd078a1fe
----
-
-## Hermes-Version & Ort
-- **Version:** v0.17.0 (2026-06-19), NousResearch/hermes-agent
-- **Repo:** `https://github.com/NousResearch/hermes-agent.git`
-- **Install-Pfad Box:** `~/.hermes/hermes-agent/`
-- **Venv:** `~/.hermes/hermes-agent/venv/bin/python`
-- **Config:** `~/.hermes/config.yaml`
-
----
-
-## Hermes-Hirn
-- **Brain:** `model.model: hermes` → Hermes-4-14B (immer warm, TTL=0)
-- **Delegation:** `heavy` für harte Teilaufgaben (Qwen3.5-122B)
-- **NICHT model:auto** — das ist nur für IDE/Vibe-Coding
-
----
-
-## MCP-Server (in ~/.hermes/config.yaml)
-| Name | Script | Zweck |
-|---|---|---|
-| `mission-control-memory` | `mcp/mcp_memory.py` | Geteiltes Gedächtnis (SQLite) |
-| `mission-control-stack` | `mcp/mcp_mc.py` | MC2 Stack-Management |
-| `hermes-pc-control` | `mcp/mcp_pc.py` | PC-Steuerung via executor.py |
-| `hermes-web-fetch` | `mcp/mcp_web.py` | Web-Fetch via trafilatura |
-
-Alle MCP-Skripte liegen in `~/mission-control-v2/mcp/` auf der Box.
-`mcp_pc.py` und `mcp_web.py` laufen mit Hermes-Venv (nicht MC2-Venv → Python 3.11 Kompatibilität).
-
-**PC_EXECUTOR_URL:** `http://192.168.178.98:7777` (als Env-Var in hermes config)
-
----
-
-## PC Executor (Windows PC)
-- **Datei:** `client/hermes-pc/executor.py` (FastAPI, Port 7777)
-- **Starten:** `client\hermes-pc\start.bat` auf dem Windows-PC (manuell, kein Autostart)
-- **Health:** `GET http://192.168.178.98:7777/health`
-- **Endpoints:** `/shell`, `/screenshot`, `/type`, `/key`, `/open`, `/search`
-- **Autostart noch nicht eingerichtet** → per start.bat starten wenn Hermes PC-Zugriff braucht
-
----
-
-## Telegram-Integration
-- **Bot-Token:** in `~/.hermes/.env` (`TELEGRAM_BOT_TOKEN`)
-- **Erlaubte User-ID:** 6150562984
-- **Platform-Toolsets:** telegram hat alle Tools (terminal, file, web, code_execution, delegation, todo, skills, session_search, hermes-telegram)
-- Slash-Befehle der CLI funktionieren auch im Telegram-Bot
-
----
-
-## Abgeschaltete Tools (Thrash-Prevention)
-`agent.disabled_toolsets: [browser, vision, computer_use, image_gen, tts, video, video_gen, memory]`
-`tool_loop_guardrails.hard_stop_enabled: true`
-
-**Why:** Browser-Tool ohne Chrome → Endlos-Loop; Cloud-Tools nicht vorhanden → Loop.
-Native memory deaktiviert (`memory.memory_enabled: false`); geteiltes Gedächtnis läuft via MCP.
-
----
-
-## Web-Suche
-- `web.search_backend: ddgs` (DuckDuckGo, kein API-Key)
-- `web.extract_backend: ddgs` — aber ddgs kann NICHT extrahieren!
-- **Echte Extraktion:** über `hermes-web-fetch` MCP-Server (trafilatura, kein API-Key)
-- trafilatura installiert in Hermes-Venv: `pip install trafilatura`

docs/memory/project-mc2-architecture.md

@@ -1,78 +0,0 @@
-> ⚠️ **TEILS VERALTET (Juni 2026, Archiv).** Aktuelle Dienste/Ports/Modelle:
-> [docs/wissen/STACK.md](../wissen/STACK.md) · Fallen: [docs/wissen/FALLEN.md](../wissen/FALLEN.md).
-> Die Schichten-/Key-File-Übersicht hier stimmt im Kern noch.
-
----
-name: project-mc2-architecture
-description: "MC2 Architektur — Schichten, Key-Files, API-Endpunkte, wichtige Eigenheiten"
-metadata: 
-  node_type: memory
-  type: project
-  originSessionId: e6bf38ac-b5dc-4aaa-80c3-ad8dd078a1fe
----
-
-## Stack-Schichten
-```
-Windows PC (192.168.178.98)
-  └─ executor.py :7777  ← PC-Steuerung (FastAPI, manuell via start.bat)
-
-AI Box (192.168.178.151) — Ryzen AI MAX+ 395, 122GB unified RAM
-  ├─ llama-swap :8080       ← Engine (ROCm/HIP, lemonade-sdk/llamacpp-rocm)
-  ├─ mission-control-2 :9001 ← MC2 (FastAPI + React, user-service)
-  │    └─ /v1              ← Builtin Gateway (model:auto, OpenAI-kompatibel)
-  ├─ hermes-gateway :8642   ← Hermes Agent (NousResearch, user-service)
-  │    ├─ mcp_pc.py        ← MCP → executor.py auf Windows PC
-  │    ├─ mcp_web.py       ← MCP → trafilatura Web-Fetch
-  │    ├─ mcp_memory.py    ← MCP → SQLite Gedächtnis
-  │    └─ mcp_mc.py        ← MCP → MC2 Stack-Management
-  └─ hermes-webui :8787     ← nesquena hermes-webui (user-service)
-
-Proxmox (192.168.178.108)  ← LXCs: adguard(100) npmplus(101) netbird(102) gitea(104)
-```
-
----
-
-## MC2 Key-Files
-| Datei | Zweck |
-|---|---|
-| `backend/app.py` | FastAPI Einstieg, Router-Mounting |
-| `backend/config.py` | Alle Env-Vars (LLAMA_SWAP_URL, HERMES_*, PC_EXECUTOR_URL, etc.) |
-| `backend/services/agent.py` | `/api/agent/status` (gateway/webui/telegram/mcp/pc) |
-| `backend/services/llamaswap.py` | llama-swap API, ROLE_IDS, Modell-CRUD |
-| `backend/services/maintenance.py` | Updates, Logs, Restart, ROLE_MAP |
-| `backend/services/sources.py` | CATEGORIES für Discover (roles: vision/coder/agent/scout) |
-| `backend/gateway/gateway_proxy.py` | Builtin OpenAI-Gateway, model:auto Routing |
-| `frontend/src/lib/api.ts` | TypeScript-Interfaces für alle API-Responses |
-| `frontend/src/lib/queries.ts` | React-Query Hooks (useModels, useAgentStatus, etc.) |
-| `mcp/mcp_pc.py` | PC-Control MCP-Server |
-| `mcp/mcp_web.py` | Web-Fetch MCP-Server (trafilatura) |
-| `mcp/mcp_memory.py` | Shared Memory MCP-Server |
-
----
-
-## Wichtige Eigenheiten / Gotchas
-- **Python 3.14 auf Box** → LiteLLM unmöglich (uvloop scheitert). MC2 hat eigenen Gateway.
-- **mcp_pc.py / mcp_web.py müssen Hermes-Venv nutzen** (nicht MC2-Venv). Python 3.11 vs 3.14 TaskGroup-Kompatibilität.
-- **Builtin-Gateway Port:** MC2 läuft auf `:9001`, der `/v1`-Endpunkt ist Teil von MC2 (nicht separater Dienst).
-- **MC_PORT vs tatsächlicher Port:** In Env ist `MC_PORT=9000`, aber der User-Service hört auf `:9001` (Port in Unit-Definition). Beim SSH-Deploy immer `:9001` verwenden.
-- **llama-swap Config braucht sudo** zum Schreiben (`/etc/llama-swap/config.yaml`), aber `hitonabi` ist in `adm`-Gruppe → journalctl ohne sudo lesbar.
-- **ROLE_IDS** in llamaswap.py = `{"vision", "coder", "agent", "scout"}` (reasoning entfernt 2026-06-27).
-- **Discover-CATEGORIES** in sources.py: vision / coder / agent / scout (kein reasoning mehr).
-- **API_SERVER_KEY:** in `~/.hermes/.env` auf der Box
-
----
-
-## /api/agent/status Felder (Stand 2026-06-27)
-```python
-{
-  "gateway_reachable": bool,    # Hermes :8642
-  "webui_reachable": bool,      # hermes-webui :8787
-  "brain_model": str,           # aus ~/.hermes/config.yaml
-  "has_config": bool,
-  "has_skills": bool,
-  "has_memories": bool,
-  "telegram_enabled": bool,     # TELEGRAM_BOT_TOKEN gesetzt?
-  "mcp_server_count": int,      # enabled MCP-Server in config.yaml
-  "pc_executor_reachable": bool # 192.168.178.98:7777/health
-}
-```

docs/memory/project-pending-tasks.md

@@ -1,51 +0,0 @@
-> ⚠️ **VERALTET (Stand 27.06.2026, Archiv).** Die einzige gepflegte Liste offener Punkte ist
-> [docs/wissen/OFFENE-FAEDEN.md](../wissen/OFFENE-FAEDEN.md).
-
----
-name: project-pending-tasks
-description: Offene Tasks und bekannte Baustellen im MC2-Projekt (Stand 2026-06-27)
-metadata: 
-  node_type: memory
-  type: project
-  originSessionId: e6bf38ac-b5dc-4aaa-80c3-ad8dd078a1fe
----
-
-## Offen / Pending
-
-### WebUI-Ersatz (LobeChat oder Alternative)
-- hermes-webui (nesquena) läuft aktuell auf `:8787`
-- Plan war: LobeChat als Docker-Container auf Proxmox LXC 105
-- Deploy-Artefakte liegen in `deploy/lobechat/` (docker-compose.yml, .env.example)
-- **Noch nicht deployed** — LXC existiert noch nicht
-- User erwähnte "AnywhereLLM" — unklar ob er AnythingLLM meint oder LobeChat; klären
-
-### Update-Checks in "Updates & Pflege"
-- **Hermes Agent Updates:** Hermes v0.17.0 aus NousResearch/hermes-agent (GitHub)
-  - GitHub API: `https://api.github.com/repos/NousResearch/hermes-agent/releases/latest`
-  - Installierte Version via `hermes --version` ermitteln
-  - Noch nicht implementiert in `backend/services/maintenance.py`
-- **WebUI Updates:** abhängig von welchem WebUI (LobeChat/hermes-webui/AnythingLLM)
-  - Noch nicht implementiert
-
-### PC Executor Windows Autostart
-- `executor.py` läuft aktuell nur wenn `start.bat` manuell gestartet wird
-- Kein Windows Startup-Task eingerichtet
-
-### Docs/README veraltet
-- `README.md`, `docs/STATUS.md`, `docs/CUTOVER.md`, `docs/HERMES_SETUP.md` beschreiben
-  noch den Zustand vor Hermes-Unchaining, PC-Executor, MCP-Servern, Reasoning-Entfernung
-- Sollten in einer Session aktualisiert werden
-
----
-
-## Erledigte größere Meilensteine (diese + letzte Session)
-- ✅ Hermes unchained: Telegram + alle Tools + MCP-Server + PC-Steuerung
-- ✅ mcp_pc.py + executor.py (PC-Zugriff via MCP)
-- ✅ mcp_web.py (trafilatura Web-Extraktion)
-- ✅ Reasoning-Modell entfernt (Nemotron, 25 GB freigegeben)
-- ✅ UI-Audit: AgentStatusCard 2x2 + Telegram/MCP/PC-Status
-- ✅ UI-Audit: PC-Executor-Karte (ersetzt SSH-Bypass-Karte)
-- ✅ UI-Audit: incomplete-Badge + Load-Button disabled
-- ✅ UI-Audit: TokenStatsCard "Juni 2026" entfernt
-- ✅ LobeChat Deploy-Artefakte committed (deploy/lobechat/)
-- ✅ Alter hermes-agent Daemon-Code entfernt (war obsolet)

docs/memory/project-stack-state.md

@@ -1,76 +0,0 @@
-> ⚠️ **VERALTET (Stand 27.06.2026, Archiv).** Die aktuelle, live-verifizierte Wahrheit
-> steht in [docs/wissen/STACK.md](../wissen/STACK.md). Diese Datei nur noch als Historie lesen.
-
----
-name: project-stack-state
-description: "Aktueller Stand des MC2-Projekts — Infrastruktur, Modelle, Dienste, Git-State (Stand 2026-06-27)"
-metadata: 
-  node_type: memory
-  type: project
-  originSessionId: e6bf38ac-b5dc-4aaa-80c3-ad8dd078a1fe
----
-
-## Wo alles liegt
-- **Code lokal:** `F:\Coding Stuff\mission-control-2` (Windows-Dev-PC)
-- **Git-Remote:** `https://git.tobisniceshomelab.ddnsfree.com/Hitonabi/mission-control-v2` (Branch `main`)
-- **AI Box:** `hitonabi@192.168.178.151` — MC2 live auf `:9001` als User-Dienst
-- **Deploy:** `ssh hitonabi@192.168.178.151 "bash ~/mission-control-v2/deploy/deploy.sh"`
-- **Windows PC:** `192.168.178.98` (Tobis PC)
-- **Proxmox:** `root@192.168.178.108:8006` (Passwort in Keepass)
-
-**Why:** Ist die einzige Quelle der Wahrheit für Verbindungsdaten.
-**How to apply:** Vor SSH/Deploy immer diese IPs nutzen, nicht raten.
-
----
-
-## Dienste auf der AI Box (Stand 2026-06-27)
-| Dienst | Port | Beschreibung |
-|---|---|---|
-| `llama-swap` (system) | `:8080` | Engine, **Vulkan/RADV** (seit 2026-06-27, vorher ROCm/HIP) |
-
-### Engine-Backend: Vulkan/RADV (Cutover 2026-06-27)
-- **Gemessen:** RADV schlägt ROCm/HIP auf gfx1151 bei tg um **+12–22 %** (fast 53→65 t/s roh), Prefill gleich.
-  „ROCm gewinnt Prefill" gilt hier NICHT; auch bei 32K Tiefe bleibt RADV vorn. hipBLASLt bringt nichts.
-- **Setup:** Vulkan-llama.cpp (offizieller Build b9821) in `/opt/llamacpp-vulkan`; Symlink
-  `/usr/local/bin/llama-server` → dorthin; systemd Drop-in `/etc/systemd/system/llama-swap.service.d/vulkan.conf`
-  mit `LD_LIBRARY_PATH=/opt/llamacpp-vulkan`. Treiber: `mesa-vulkan-drivers` (RADV STRIX_HALO, Mesa 26.0.3).
-- **ROCm-Build bleibt** unter `/opt/llamacpp` (lemonade llamacpp-rocm) als Rollback liegen.
-- **Rollback:** `sudo ln -sfn /opt/llamacpp/llama-server /usr/local/bin/llama-server` + Drop-in löschen + `sudo systemctl daemon-reload && sudo systemctl restart llama-swap`.
-- **ACHTUNG maintenance.py:** `_engine_update_available()` trackt noch `lemonade-sdk/llamacpp-rocm` — passt nicht
-  mehr zum aktiven Vulkan-Build (b9821 von ggml-org/llama.cpp). Engine-Update-Quelle anpassen.
-- **Spec-Draft (2026-06-27 gefixt):** `qwen2.5-1.5b` war vocab-inkompatibel mit Qwen3.6 UND `--spec-type` fehlte
-  → war inaktiv. Auch Qwen3-0.6B ist mit Qwen3.6 inkompatibel → **`fast` läuft jetzt ohne Draft** (kein
-  kompatibler verfügbar). **`coder` (Qwen3-Coder-Next)**: Qwen3-0.6B IST kompatibel → Draft
-  `/srv/models/drafts/Qwen3-0.6B-Q8_0.gguf` + `--spec-type draft-simple`, **0,75 Akzeptanz** (echter Coding-Speedup).
-  Alter `qwen2.5-1.5b-instruct-q4_k_m.gguf` in drafts/ ist jetzt ungenutzt (löschbar, 1,1 GB).
-- **Modell-cmds (config.yaml):** llama.cpp dieser Generation braucht `--spec-type` zusätzlich zu
-  `--spec-draft-model`, sonst ist Spec inaktiv. Drafts müssen **exakt vocab-gleich** zum Target sein.
-| `mission-control-2` (user) | `:9001` | MC2 Backend + Frontend |
-| `hermes-gateway` (user) | `:8642` | Hermes Agent API |
-| `hermes-webui` (user) | `:8787` | nesquena hermes-webui |
-
-MC2-Gateway auf `:9001/v1` ist der OpenAI-kompatible Endpunkt für IDEs (model:auto).
-
----
-
-## Modell-Stack (llama-swap, Stand 2026-06-27)
-| Alias | Modell | TTL | Besonderheit |
-|---|---|---|---|
-| `hermes` | Hermes-4-14B (Q6_K) | 0 (immer warm) | Agent-Hirn, in brains-Gruppe |
-| `fast` | Qwen3.6-35B-A3B (Q4_K_M) | 0 (immer warm) | MoE, Vision, SPEC-Draft, 2 Slots; in brains-Gruppe |
-| `vision` | Qwen3-VL-2B-Instruct (Q4_K_M) | 0 (immer warm) | Tiny Vision; in brains-Gruppe |
-| `heavy` | Qwen3.5-122B-A10B (Q4_K_M) | 600s | MoE, 32k ctx |
-| `coder` | Qwen3-Coder-Next (Q4_K_M) | 600s | SPEC-Draft, 2 Slots |
-| `scout` | gemma-4-26B-A4B-it (Q4_K_M) | 180s | Multimodal |
-
-`reasoning`-Rolle wurde entfernt (Nemotron gelöscht, 25 GB freigegeben, 2026-06-27).
-brains-Gruppe hat `swap:false, persist:true` → hermes/fast/vision bleiben immer resident.
-
-**Config-Pfad auf Box:** `/etc/llama-swap/config.yaml`
-
----
-
-## Git-Stand
-- Lokal, Gitea und AI Box alle synchron auf `main`
-- Working tree clean (Stand nach letztem Push)
-- Push nur via **PowerShell-Tool** mit `dangerouslyDisableSandbox:true` (kein Bash-Push → GCM-Auth-Problem)

docs/skills/orchestrator.md

@@ -1,198 +0,0 @@
-# orchestrator — Auftraege managen, nicht selbst ausfuehren
-
-> **Kurz:** Wenn ein Auftrag zu gross fuer einen Rutsch ist, zerlegt der Orchestrator-Skill ihn in Teil-Tasks, delegiert diese seriel an Worker-Modelle, integriert die Ergebnisse, laesst sie von zwei Zweitgutachtern pruefen und gibt dem Commander einen Vorschlag zur Entscheidung — der Orchestrator schreibt nie selbst Code.
-
-## Was der Skill tut
-
-Der Skill beschreibt ein Manager-Modell, das komplexe Auftraege in klar abgegrenzte Teil-Tasks zerlegt, jeden Teil seriel (nacheinander) an ein passendes Worker-Modell delegiert, die Ergebnisse einsammelt und zusammensetzt, sie durch ein Zwei-Kritiker-Gate prueft und als Telegram-Vorschlag zurueckgibt. Der Commander entscheidet, ob er annimmt oder verwirft. Der Orchestrator selbst baut und deployt **nie** etwas.
-
-## Wann er zum Einsatz kommt
-
-| Situation | Aktion |
-|---|---|
-| Auftrag ist zu gross fuer einen Rutsch (2-4 Teil-Tasks) | Orchestrator (diese Datei) |
-| Auftrag ist klein und einfach | Direkt bearbeiten, kein Orchestrator |
-| Auftrag ist zu gross (breite Architektur-Aenderung, viele Module) | Etappen-Plan: in lauffaehige Teilprojekte zerlegen |
-| Nur ein einziger Code-Review-Schritt ist nötig | Werkstatt-Skill (`wartung`) |
-
-## Konfiguration
-
-### Vorhandene Skripte (immer mit vollem Pfad!)
-
-| Skript | Pfad | Aufgabe |
-|---|---|---|
-| Worker | `~/.hermes/scripts/worker.sh` | Delegiert einen Teil-Task an ein Worker-Modell (Ein-Schuss) |
-| Fremdkritik | `~/.hermes/scripts/fremdblick.sh` | Laesst den zusammengesetzten Diff von einem zweiten Modell gegengelesen |
-
-**Wichtig:** Beide Skripte liegen NICHT auf dem PATH — sie muessen IMMER mit vollem Pfad aufgerufen werden. Glaubst du, sie fehlen: erst `ls -la ~/.hermes/scripts/worker.sh` ausfuehren.
-
-### Worker-Modelle
-
-| Rolle | Modell | Warum |
-|---|---|---|
-| Planung | `gpt-oss-120b` (heavy) | Fuer die initiale Architektur-Planung (laedt ~15s, stört Lucys Latenz gewollt — Hintergrundprozess) |
-| Code-Bau | `Qwen3-Coder-Next` | Klein, passend neben dem Warm-Set, ideal fuer Teil-Task-Umsetzung |
-
-### Arbeitsverzeichnis
-
-Worktrees liegen unter `~/.hermes/worktrees/` (nicht `/tmp` — ueberlebt keinen Reboot). Die Live-Instanz `~/mission-control-v2` bleibt **unberuehrt** — immer im Worktree arbeiten.
-
-## Arbeitsablauf (Schritt-für-Schritt)
-
-### 1. Beratung & Zerlegen
-
-Bevor du selbst Tasks aufteilst, befragst du zwingend `gpt-oss-120b` nach einem Architektur-Plan:
-
-```bash
-printf '%s' "Auftrag: <Beschreibung>" | \
-  WORKER_MODEL=gpt-oss-120b WORKER_ROLE=plan \
-  ~/.hermes/scripts/worker.sh > /tmp/orch-plan.txt
-```
-
-Lies den Plan und zerlege den Auftrag in eine geordnete, nummerierte Liste von Teil-Tasks (2-4).
-
-### 2. Worktree anlegen
-
-```bash
-mkdir -p ~/.hermes/worktrees && cd ~/mission-control-v2 && \
-  git fetch -q origin && \
-  git worktree add ~/.hermes/worktrees/orch-<slug> \
-    -b orchestrator/<slug> origin/main
-mkdir -p ~/.hermes/worktrees/orch-<slug>-work
-```
-
-Der Slug ist ein kurzer Kebab-Case-Name des Auftrags (z. B. `login-fix`).
-
-### 3. Teil-Tasks seriel an Worker delegieren
-
-Fuer jeden Bau-Teil-Task:
-
-```bash
-printf '%s' "<Kontext + genauer Auftrag>" | \
-  WORKER_ROLE=build \
-  ~/.hermes/scripts/worker.sh > \
-  ~/.hermes/worktrees/orch-<slug>-work/<n>.out
-```
-
-- Die Ausgabe beginnt mit `FEHLT:` → zu wenig Kontext, nachliefern und erneut rufen.
-- Enthaltene Code-Zaunen (` ``` `) oder Prosa entfernen, sauberes Artefakt bleibt.
-- **Du** schreibst das Artefakt mit deinen Datei-Tools an seinen Platz im Worktree.
-- **Schreibziel-Pflicht:** Jedes write_file/patch MUSS mit `~/.hermes/worktrees/orch-<slug>/` beginnen.
-
-### 4. Integrieren + Self-Gate
-
-Die Worker liefern Bausteine — du sorgst dafuer, dass sie zusammenpassen (Imports, Verdrahtung, Namen).
-
-- **Python:** `python3 -m py_compile <dateien>` (Tests wenn moeglich mitlaufen lassen)
-- **Shell:** `bash -n <dateien>`
-- **Frontend:** im Worktree `cd frontend && npm install && npm run build`, neues `frontend/dist` MIT-committen
-
-**Live-Checkout unberuehrt (zwei Beweise):**
-
-```bash
-git -C ~/mission-control-v2 status --porcelain -uno  # MUSS LEER sein
-curl -sf http://127.0.0.1:9001/api/health            # MUSS Gruen zeigen
-```
-
-### 5. Zwei-Kritiker-Gate
-
-Zwei Zweitgutachter mit je anderer Staerke lesen den **gesamten** Diff gegen `origin/main`:
-
-Zuerst ALLES stagen:
-
-```bash
-git -C ~/.hermes/worktrees/orch-<slug> add -A
-```
-
-Dann die Eingabe bauen:
-
-```bash
-EINGABE="AUFTRAG (im Wortlaut):
-<urspruenglicher Auftrag>
-
-ZERLEGUNG (deine Teil-Tasks, je 1 Zeile):
-<1..n>
-
-GIT-DIFF des Worktrees:
-$(git -C ~/.hermes/worktrees/orch-<slug> diff --cached origin/main)"
-```
-
-**Kritik A — Kompetenz** (`Qwen3-Coder-Next`, noch warm):
-
-```bash
-printf '%s' "$EINGABE" | FREMDBLICK_MODE=code \
-  ~/.hermes/scripts/fremdblick.sh
-```
-
-**Kritik B — Fremd-Blick** (`GLM-4.6V-Flash`, andere Modellfamilie):
-
-```bash
-printf '%s' "$EINGABE" | FREMDBLICK_MODE=code \
-  FREMDBLICK_MODEL=GLM-4.6V-Flash FREMDBLICK_MAXTOK=3000 \
-  ~/.hermes/scripts/fremdblick.sh
-```
-
-**Gate-Regel (streng):**
-
-| Urteil | Aktion |
-|---|---|
-| Beide `FREIGABE` | Vorschlag erstellen |
-| Einer `ABGELEHNT` | Nachbessern (max. 2 Runden), dann erneut gaten |
-| Einer `FREIGABE-MIT-VORBEHALT` | Vorbehalte im Vorschlag ehrlich ausweisen |
-| Kritiker fiel aus (`FEHLGESCHLAGEN`) | Einmal wiederholen, sonst "⚠ Kritik X fiel aus" vermerken |
-
-**Wichtig:** Ein Kritiker sagt JEWEILS `ABGELEHNT` oder `FREIGABE` oder `FREIGABE-MIT-VORBEHALT`. Sagt AUCH NUR EINER `ABGELEHNT` → nachbessern. Nur wenn BEIDE tragen → Vorschlag.
-
-### 6. Telegram-Vorschlag
-
-```bash
-bash ~/mission-control-v2/deploy/notify.sh -s "[Orchestrator]" "<text>"
-```
-
-Der Vorschhalt enthaelt:
-- 1-2 Saetze: was gebaut wurde, was der Commander entscheiden soll
-- Die Zerlegung (welcher Teil-Task an welches Worker-Modell)
-- Geaenderte/neue Dateien · Kern des Diffs
-- Self-Gate-Ergebnis · Kritiker-Urteil KONKRET (nicht nur "ok")
-- Branch-Name · Frage "merge oder verwerfen?"
-
-### 7. Nichts loeschen
-
-Worktree + Branch + rohe Worker-Ausgaben bleiben liegen, bis der Commander entschieden hat.
-
-## Leitplanken (nicht verhandelbar)
-
-- **Du delegierst, du baust NICHT selbst.** Jedes Bau-Artefakt MUSS aus einem `worker.sh`-Aufruf stammen. Selbstgebaut = gescheiterter Lauf.
-- **"Task zu klein" ist KEIN Freibrief.** Planung, Delegation oder Zwei-Kritiker-Gate NICHT eigenmaechtig ueberspringen — auch nicht "transparent angesagt".
-- **Propose-only.** Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der Commander. NIEMALS auf `main` committen, mergen oder deployen.
-- **Nur im Worktree arbeiten.** Die Live-Instanz `~/mission-control-v2` bleibt unberuehrt.
-- **Security-Config ist TABU:** keine Tokens, approvals, ufw, sudoers, ssh-Keys anfassen.
-- **Hermes-first:** Bevor ein Teil-Task NEUE Infrastruktur baut, pruefe ob hermes-agent das nativ kann.
-
-## Pitfalls
-
-| Falle | Vermeidung |
-|---|---|
-| Code selbst schreiben statt Worker zu delegieren | Jedes Artefakt MUSS worker.sh-Quelle haben |
-| In Live-Checkout schreiben statt Worktree | Schreibziel muss mit `~/.hermes/worktrees/` beginnen |
-| `/tmp` fuer Worktrees nutzen | `~/.hermes/worktrees/` — ueberlebt Reboots |
-| `git diff` ohne `add -A` → Kritiker sehen LEEREN Diff | Immer zuerst `git add -A`, dann `git diff --cached` |
-| Zu wenig Kontext fuer Worker → `FEHLT:` | Betroffene Datei/Ausschnitt + Beispiel + genaue Signatur mitgeben |
-| Grosse Artefakte in Antwort kippen → Output-Limit | In Dateien schreiben, Pfade + 1-Zeilen-Zusammenfassung in Antwort |
-| Fremdblick-Skript nicht gefunden | Immer vollen Pfad `~/.hermes/scripts/fremdblick.sh` verwenden |
-| Lockfile-Dreck beim Frontend-Build | Nach `npm install`: `git checkout -- frontend/package-lock.json` falls nicht geaendert |
-| Nur Health-Curl als Beweis | `git status --porcelain -uno` MUSS LEER sein (Health-Curl allein reicht NICHT) |
-
-## Konsistenz mit MC2-Konventionen
-
-- **Sprache:** Deutsch, direkt, kein Marketing-Sprech.
-- **Struktur:** Kurze Beschreibung → Wann einsetzen → Konfiguration → Arbeitsablauf → Pitfalls → Konsistenz.
-- **Querverweise:** Verweise auf Werkstatt-Skill, Auftragsbuch, Worker- und Fremdkritik-Skripte.
-- **Tabellen:** Wo sinnvoll (Situationen, Modelle, Gate-Regeln, Pitfalls) als Tabelle formatiert.
-- **Code-Blöcke:** Alle Befehle als bash-Code-Blöcke mit klaren Variablen-Platzhaltern.
-- **Keine Secrets:** Tokens und Pfade werden referenziert, nicht ausgeschrieben.
-- **Leitplanken:** Nicht-verhandelbare Regeln als eigene Sektion, um Delegationstreue zu erzwingen.
-
----
-
-_Diese Datei wurde als Skill-Dokumentation im MC2-Repo erstellt. Sie ist Teil der Skills-Docs in `docs/skills/`._