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>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
4cd856bd34
commit
59631601b9
@@ -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.
|
||||
@@ -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`.
|
||||
@@ -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`).
|
||||
@@ -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)
|
||||
```
|
||||
@@ -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.
|
||||
@@ -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>
|
||||
@@ -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>
|
||||
+1
-1
@@ -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
|
||||
@@ -0,0 +1,57 @@
|
||||
# Savepoint — Mission Control 2.0 (MC2)
|
||||
|
||||
_Stand: 2026-08-20, nach der Aufräum-Runde. Alle Zahlen hier sind **auf der Box gemessen**, nicht
|
||||
aus Doku übernommen._
|
||||
|
||||
## Was das ist (in einem Satz)
|
||||
MC2 ist die **Web-Admin-Konsole** einer 100 % lokalen KI-Appliance („die Box", Bosgame M5 / AMD
|
||||
Strix Halo, 128 GB Unified RAM, llama.cpp-Vulkan). Sie verwaltet Engine, Modelle, Gedächtnis,
|
||||
Agenten-Status, Updates & Wartung — und dient als Steuerpult für die autonome KI („Lucy").
|
||||
|
||||
## Architektur (Kurzform — Details in AGENTS.md/docs/)
|
||||
- **Backend** `backend/` — FastAPI, `:9001` als systemd-**User-Dienst** (reboot-fest, sudo-frei).
|
||||
- **Frontend** `frontend/` — React/Vite/Tailwind/shadcn. **`frontend/dist` ist ABSICHT im git**
|
||||
(Box hat kein Node; Backend liefert die gebauten Assets direkt aus).
|
||||
- **MC2-Gateway** `:9010` (`/v1`-Datenpfad, model:auto Routing + native Bildweiche).
|
||||
- **Modell-Router** `:8080` (llama-swap v250, Vulkan/RADV Engine b10502).
|
||||
- **Hermes Agent** `:8642` (`hermes-gateway`, v0.20.4) + `hermes dashboard` auf `:9119` (nur Loopback).
|
||||
- **Sidecars:** `voice_service/` (:8650, faster-whisper STT + Piper TTS), `mcp/` (4 MCP-Server),
|
||||
`client/hermes-pc` (PC-Executor :7777).
|
||||
‼️ `mem0_service/` liegt noch im Baum, ist aber **stillgelegt** — `:8765` antwortet nicht.
|
||||
|
||||
## Modelle live (gemessen 20.08.2026)
|
||||
| Rolle (Alias) | Modell | Tempo | Zustand |
|
||||
|---|---|---|---|
|
||||
| `hermes` / `fast` | Qwen3.6-35B-A3B (MoE, DFlash) | **95,7 t/s** · Prompt 221 t/s | immer warm |
|
||||
| `coder` | Qwen3.8-27B (dicht, Vision) | **12,6 t/s** · Prompt 144 t/s | ttl 5400, ~29 s Kaltstart |
|
||||
| `debugger` | Muse-Glimmer-30B (DFlash) | — | ttl 600 |
|
||||
| `heavy` | gpt-oss-120b | — | on-demand |
|
||||
| `vision` | Qwen3-VL-30B-A3B-Instruct | — | on-demand |
|
||||
| `embed` / `reranker` | Qwen3-Embedding-0.6B / Qwen3-Reranker-0.6B | — | immer warm |
|
||||
|
||||
Warm-Gruppe `brains` = embed + reranker + Qwen3.6-35B-A3B. Warm-Wächter weckt nur `fast`.
|
||||
|
||||
**Hintergrund zum Tempo:** Strix Halo liefert ~215 GB/s Speicherbandbreite. Ein *dichtes* Modell
|
||||
muss pro Token seine vollen Gewichte lesen → 17 GB ÷ 215 GB/s ≈ 12,6 t/s ist das **Hardware-Limit**,
|
||||
kein Konfigurationsfehler. MoE-Modelle lesen pro Token nur einen Bruchteil und sind darum ~8× schneller.
|
||||
|
||||
## Aufgeräumt am 20.08.2026
|
||||
- CI-Ampel wieder **grün** (Lauf #77) — zwei ungenutzte `MEM0_SERVICE_URL`-Importe entfernt.
|
||||
- Kaputter systemd-Timer `mc2-morgen-digest` abgeschaltet (der Hermes-Cron macht die Arbeit).
|
||||
- `mcp-stderr.log` (27 MB, 238k Ping-Zeilen) geleert.
|
||||
- Config-Drift aufgelöst: Repo == `/etc/llama-swap/config.yaml`. Warm-Set-Idee geparkt auf
|
||||
Branch `parked/warm-set-5d93822`.
|
||||
- Entfernt: Governor-Reste, OpenCode-/aider-Reste (853 MB), 61 alte Backup-Dateien,
|
||||
verwaiste Modelle Devstral-Small-2 + GLM-4.6V-Flash + mem0 (21,5 GB) → `/srv/models` 209 → 189 GB.
|
||||
- **Fähigkeiten repariert:** `orchestrator`- und `wartung`-Skill sowie `fremdblick.sh` zeigten auf
|
||||
gelöschte Modelle (`Qwen3-Coder-Next`, `GLM-4.6V-Flash`, `GLM-4.7-Flash`) → der Kritiker-Gate war
|
||||
stumm kaputt. Jetzt auf **Rollen-Aliase** umgestellt, damit Modellwechsel sie nicht mehr brechen.
|
||||
- Alles Gelöschte liegt gesichert in `~/archiv-aufraeumen-20260820/` (11 MB).
|
||||
|
||||
## Offen
|
||||
- `mem0_service/` + `_mem0_reachable()` in `backend/routers/system.py` ausbauen (toter Port).
|
||||
- `~/.hermes/scripts/fremdblick.sh` ist **unversioniert** — gehört ins Repo.
|
||||
- MCP-Log dauerhaft deckeln (Hermes' `max_size_mb` greift für gekapertes stderr nicht).
|
||||
- Verschwundene Wächter: Ampel-Wächter, Prüfstand, Stack-Rundumschlag.
|
||||
- Coder-Tempo: Entwurfsmodelle für spekulatives Dekodieren liegen ungenutzt unter
|
||||
`/srv/models/Qwen3.8-27B-DFlash2-GGUF/`.
|
||||
@@ -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`
|
||||
@@ -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
|
||||
}
|
||||
```
|
||||
@@ -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)
|
||||
@@ -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)
|
||||
@@ -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/`._
|
||||
Reference in New Issue
Block a user