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:
Hitonabi
co-authored by
Claude Opus 5.5
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).
|
W1/W2 macht sie sogar robuster (kein OOM mehr).
|
||||||
- Vor jeder Box-Config-Änderung Backup; llama-swap reloadt per `-watch-config`.
|
- Vor jeder Box-Config-Änderung Backup; llama-swap reloadt per `-watch-config`.
|
||||||
- **Keine destruktiven Aktionen ohne Freigabe dieses Plans.**
|
- **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.
|
- **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`.
|
- Vor Box-Config-Änderungen Backup; llama-swap reloadt per `-watch-config`.
|
||||||
- Erst messen (Prompt-Größe + Latenz), dann über vollen Umzug entscheiden.
|
- 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`;
|
5. **Gedächtnis-Bereiche** statt zweitem mem0: neue Fakten tragen `bereich: alltag|projekt`;
|
||||||
`GET /memory?bereich=` filtert (Alt-Fakten laufen immer mit). Einmal-Cron
|
`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
|
`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:
|
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
|
`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
|
das stumm!). ~157 GB Müll von der Box (u. a. 103 GB HF-Cache), Hermes Desktop komplett
|
||||||
@@ -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