diff --git a/SAVEPOINT.md b/SAVEPOINT.md index fd82926..dd8ec63 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -1,26 +1,57 @@ -# Savepoint — Mission Control 2.0 (MC2) - -_Stand: 2026-08-19. Zustands-Snapshot nach Stack-Vollupdate (Hermes v0.20.4, llama.cpp b10502, llama-swap v250, Qwen 3.8 DFlash-2 Vorbereitung & Doku-Bereinigung)._ - -## 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, Vulkan/RADV Engine b10502). -- **Hermes Agent** `:8642` (`hermes-gateway`, v0.20.4 mit nativem Bot-Mode). -- **Sidecars:** `mem0_service/` (:8765, semantischer Chroma-Gedächtnis-Sidecar), `voice_service/` (:8650, faster-whisper STT + Piper TTS), `mcp/` (MCP-Server), `client/hermes-pc` (PC-Executor :7777). - -## Aktueller Zustand (19.08.2026) -- **Stack-Vollupdate abgeschlossen:** llama-swap v250, llama.cpp b10502 (Vulkan), Hermes Agent v0.20.4 (Bot-Mode Support). -- **Selbsttests:** `self-smoke.sh` zu 100 % grün. -- **Codebase-Bereinigung:** Verwaiste Governor-Schnittstellen im Frontend entfernt, Regex-Versionsparsing in `maintenance.py` gefixt, Doku-Wahrheit (Mem0-Sidecar, Modelltabellen, Ports) wiederhergestellt. -- **Modelle live:** hermes=Qwen3.6-35B-A3B (immer warm, ~70–90 t/s) · coder=Qwen3-Coder-Next (51,5 t/s) · debugger=Muse-Glimmer-30B · kritiker=Devstral-Small-2-24B (16k Deckel) · dense-planer=Qwen3.8-27B · heavy=gpt-oss-120b · vision=Qwen3-VL-30B · scout=GLM-4.6V · embed/reranker=Qwen3 0.6B. - -## Letzter Sicherungspunkt -- Stand: 19.08.2026 nach Stack-Audit & Cleanup. +# 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/`. diff --git a/deploy/skills/orchestrator/SKILL.md b/deploy/skills/orchestrator/SKILL.md index fa3de49..fc800f9 100644 --- a/deploy/skills/orchestrator/SKILL.md +++ b/deploy/skills/orchestrator/SKILL.md @@ -1,220 +1,220 @@ ---- -name: orchestrator -description: "Orchestrieren wie ein Manager: einen groesseren Auftrag in Teil-Tasks zerlegen, jeden SERIELL an das passende Worker-Modell delegieren (worker.sh, Ein-Schuss via llama-swap), die Ergebnisse einsammeln + zusammensetzen, per Fremd-Kritiker gaten und als Telegram-Vorschlag zurueckgeben. NIE selbst mergen/deployen — der Commander ist das Gate." -version: 1.0.0 -author: MC2 (Autonomie — Orchestrator) -platforms: [linux] -metadata: - hermes: - tags: [orchestrator, delegation, werkstatt, mc2, fliessband] ---- - -# Orchestrator — du managst, du fuehrst nicht alles selbst aus - -Nutze diesen Skill, wenn ein Auftrag zu gross fuer EINEN Rutsch ist, sich aber in wenige klar -abgegrenzte Teil-Tasks zerlegen laesst (ueberwiegend Code-Bau). Du bist der **Manager**: du -zerlegst, verteilst die Teile SERIELL an Worker-Modelle (die arbeiten), fuegst die Ergebnisse -zusammen und lieferst am Ende einen **Vorschlag** — der Commander entscheidet. - -Das ist die Verallgemeinerung der **Werkstatt** (`wartung`): dort delegierst du EINEN Schritt -(Code-Review) an ein Fremdmodell. Hier delegierst du MEHRERE Bau-Schritte an Worker und behaeltst -die Integration + das Gate. - -## Warum seriell (und warum das ok ist) -Mehrere grosse Modelle GLEICHZEITIG passen nicht in den Speicher. llama-swap ist **seriell** — ein -Modell laden → arbeiten → tauschen → naechstes. Orchestrierung ist ein **Fliessband, kein Schwarm.** -Langsamer (Swap-Latenz + einer nach dem anderen: Minuten), aber bei Hintergrund-/Telegram-Jobs egal. - -## Scope-Check zuerst (klein anfangen) -Passt: ein Auftrag, der in **2–4 abgegrenzte Teil-Tasks** zerfaellt, jeder ein 1–2-Datei-Bau-Schritt -(neues kleines Modul + Test, kleine neue Funktion + Verdrahtung, zusammenhaengender Refactor in -wenigen Dateien). Zu gross (viele Module, echte Architektur-Entscheidungen, breite API-Aenderung): -**Etappen-Weg statt Ablehnung** (Grossbau-Entscheid 10.07.2026) — zerlege das Projekt in Etappen, -von denen JEDE fuer sich lauffaehig, gate-gruen und einzeln annehmbar ist. Baue in DIESEM Lauf nur -Etappe 1 (als normalen Orchestrator-Durchlauf mit Workern + Zwei-Kritiker-Gate); den Etappen-Plan -in den Telegram-Vorschlag schreiben und die Folge-Etappen als neue Aufgaben in die Ideen-Queue -legen (`hermes kanban create " — Etappe : " --triage`, im Body: Plan + Branch der -Vor-Etappe). Eine Folge-Etappe wird erst gebaut, wenn der Branch der Vor-Etappe in main ist — -NIE auf unangenommene Branches aufbauen. Rauere Qualitaet ist bei Grossbau ok, aber ehrlich im -Vorschlag ausweisen, was fehlt oder wacklig ist. - -## Leitplanken (nicht verhandelbar) -- **Du delegierst, du baust NICHT selbst.** Jedes Bau-Artefakt MUSS aus einem `worker.sh`-Aufruf - stammen. Schreibst du den Code selbst (auch wenn der Teil-Task „einfach genug" wirkt), statt ihn - vom Worker zu holen, ist der Lauf GESCHEITERT — sag das ehrlich, statt Eigenbau als Orchestrierung - auszugeben. Belege jeden Teil-Task im Vorschlag mit dem `worker.sh`-Aufruf UND den ersten Zeilen - seiner Roh-Ausgabe. (Warum so streng: das Manager-Modell kann kleine Tasks selbst — genau dann - faellt Delegation aus Bequemlichkeit weg; das ist der haeufigste Orchestrierungs-Fehler.) -- **„Task zu klein" ist KEIN Freibrief (kein Ermessensspielraum).** Du darfst Planung, Delegation - oder das Zwei-Kritiker-Gate NICHT eigenmaechtig ueberspringen — auch nicht transparent angesagt - („Overkill, ich mach das direkt" = GESCHEITERTER Lauf, Vorfall 09.07.2026). Wirkt der Auftrag - wirklich zu klein fuers Fliessband, ist dein EINZIGER erlaubter Ausweg: **abbrechen ohne Code** - und im Vorschlag melden „zu klein fuer den Orchestrator — bitte als Werkstatt-Auftrag (hermes -z) - oder direkt im Desktop laufen lassen". Ein Lauf, der Code liefert, enthaelt IMMER worker.sh-Belege - UND beide Kritiker-Verdikte — ohne Ausnahme. -- **Die Helfer EXISTIEREN.** `~/.hermes/scripts/worker.sh` und `~/.hermes/scripts/fremdblick.sh` - sind installiert, aber NICHT auf deinem PATH → immer mit vollem Pfad aufrufen (nie bloss `worker.sh`). - Glaubst du, sie fehlen, IRRST du dich: erst `ls -la ~/.hermes/scripts/worker.sh` ausfuehren und den - Pfad lesen, dann nutzen. „Skript fehlt" ist KEIN gueltiger Grund, den Schritt selbst zu machen. -- **Propose-only.** Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der Commander. - NIEMALS auf `main` committen, NIEMALS mergen, NIEMALS deployen oder Dienste neu starten. -- **Nur im Worktree arbeiten.** Die Live-Instanz `~/mission-control-v2` bleibt unberuehrt. -- **Warm-Set-Schutz (Speicher vs Latenz).** Worker werden ueber **`worker.sh`** aufgerufen. - Fuer die Umsetzung von Code nutzt du **`Qwen3-Coder-Next`** (laedt klein neben dem Warm-Set). - Fuer die initiale **Planung** nutzt du explizit den Chef-Gutachter **`gpt-oss-120b`** (heavy), - auch wenn dessen Laden (~15s) Lucys Sprech-Latenz temporaer aussetzt. Das ist fuer diesen - Hintergrund-Prozess gewollt. -- **Fremd-Kritiker ist Pflicht-Gate.** Der zusammengesetzte Diff MUSS von `fremdblick.sh` (anderes - Modell) gegengelesen werden, bevor du vorschlaegst. Ein Manager, der Worker-Output blind - zusammenklebt, produziert leisen Muell. -- **Security-Config ist TABU:** keine Tokens, approvals, ufw, sudoers, ssh-Keys anfassen. -- **Hermes-first (10.07.2026):** Bevor ein Teil-Task NEUE Infrastruktur baut (Skript, Dienst, - Tool, Cron), pruefe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte schauen - (`~/wissens-vault/eigenbau-landkarte.md`), notfalls `bash -lc 'hermes --help'`. Den - Pruef-Befund in den Vorschlag schreiben („nativ vorhanden: nein/ja, weil …"). -- Gate rot oder Kritiker dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschoenigen. - -## Ablauf - -### 1. Beratung & Zerlegen (Manager plant mit dem Chef) -Bevor du selbst Tasks aufteilst, befragst du zwingend **`gpt-oss-120b`** nach einem Architektur-Plan: -1. Sende den initialen Auftrag per `worker.sh` an den Chef-Planer: - ```bash - printf '%s' "Auftrag: $auftrag" | WORKER_MODEL=gpt-oss-120b WORKER_ROLE=plan ~/.hermes/scripts/worker.sh > /tmp/orch-plan.txt - ``` -2. Lies den Plan (`cat /tmp/orch-plan.txt`) und nutze ihn, um den Auftrag in eine **geordnete, nummerierte Liste von Teil-Tasks** zu zerlegen. -3. Fuer jeden Teil-Task entscheide: (a) Artefakt, (b) Worker (`Qwen3-Coder-Next` + `build`/`refactor`), (c) Kontext. - -### 2. Worktree anlegen (Slug = kurzer Kebab-Case-Name des Auftrags) -Worktrees liegen unter `~/.hermes/worktrees/` (NICHT /tmp — ueberlebt keinen Reboot und -hinterlaesst kaputte Worktree-Registrierungen, Review-Befund 15.07.): -``` -mkdir -p ~/.hermes/worktrees && cd ~/mission-control-v2 && git fetch -q origin \ - && git worktree add ~/.hermes/worktrees/orch- -b orchestrator/ origin/main -mkdir -p ~/.hermes/worktrees/orch--work # Ablage fuer rohe Worker-Ausgaben -``` - -### 3. Routen — je Teil-Task ein Worker-Ein-Schuss (seriell) -Fuer jeden Bau-Teil-Task: -1. Baue die Eingabe: **genau der noetige Kontext** + der praezise Auftrag (siehe unten). Bereits - fertige Artefakte aus frueheren Schritten als Kontext mitgeben, wenn der Worker sie braucht. -2. Ruf den Worker auf und fang die Ausgabe roh ab: - ``` - printf '%s' "$eingabe" | WORKER_ROLE=build ~/.hermes/scripts/worker.sh > ~/.hermes/worktrees/orch--work/.out - ``` - (Default-Modell ist `Qwen3-Coder-Next`. Fuer einen bewusst anderen Worker `WORKER_MODEL=`.) -3. **Pruefe die Ausgabe, bevor du sie verwendest:** Beginnt sie mit `FEHLT:`, hast du zu wenig - Kontext gegeben → nachliefern und erneut rufen. Hat der Worker versehentlich einen ```-Codezaun - oder Prosa drumherum gesetzt, entferne ihn. Dann schreibe das saubere Artefakt mit deinen - Datei-Tools an seinen Platz im Worktree (`~/.hermes/worktrees/orch-/...`). Der Worker hat KEINE - Datei-Haende — das Schreiben machst DU. -4. **Schreibziel-Pflicht (Vorfall 09.07.2026):** JEDES write_file/patch-Ziel MUSS mit - `~/.hermes/worktrees/orch-/` beginnen — vor dem ersten Schreiben einmal laut pruefen. NIEMALS nach - `~/mission-control-v2/...` schreiben (Live-Checkout!), NIEMALS Work-Dirs/Worktrees FREMDER - Slugs wiederverwenden (beim Doku-Lauf landete ein Artefakt im Live-Checkout, weil das alte - `/tmp/orch-hermes-desktop-work` recycelt wurde). Existiert dein `~/.hermes/worktrees/orch-` noch nicht, - ist das der Beweis, dass Schritt 2 fehlt — erst Worktree anlegen. -5. **Grosse Artefakte NIE im Klartext in deine Antwort** — sie gehoeren in Dateien im Worktree. - Wer Dateiinhalte in die Antwort kippt, stirbt am Output-Limit mitten im Lauf (Doku-Lauf - 09.07.2026: abgewuergt VOR Kritiker-Gate und Vorschlag). In der Antwort: Pfade + 1-Zeilen-Zusammenfassung. - -### 4. Integrieren + Self-Gate (nach jedem Schritt bzw. am Ende) -Die Worker liefern Bausteine — DU sorgst dafuer, dass sie zusammenpassen (Imports, Verdrahtung, -Namen). Dann das Selbst-Gate, was zutrifft: -- Python geaendert → `python3 -m py_compile ` (und wenn ein Test dabei ist und ohne - schwere Deps laeuft: den Test im Worktree ausfuehren). -- Shell geaendert → `bash -n ` -- Frontend (`frontend/src/...`) → **Node EXISTIERT auf der Box** (bewiesen 09.07.2026, Läufe - role-metadata + desktop-gateway): im Worktree `cd frontend && npm install && npm run build` - ausfuehren und das neue `frontend/dist` MIT-committen (AGENTS.md-Pflicht — sonst zeigt die Box - nach Merge+Deploy den alten Stand). **Danach `git checkout -- frontend/package-lock.json`**, - falls npm install es nur als Nebeneffekt angefasst hat (wiederkehrendes Muster: 3 Laeufe in - Folge hatten lockfile-Dreck) — es gehoert NUR in den Commit, wenn Dependencies sich wirklich - aendern sollten. Schlaegt der Build fehl, ehrlich ausweisen: „Gate eingeschraenkt: Build - fehlgeschlagen, tsc laeuft beim Merge auf dem PC." -- **Live-Checkout unberuehrt (PFLICHT, zwei Beweise):** - - `git -C ~/mission-control-v2 status --porcelain -uno` **muss LEER sein** (Beweis, dass du - wirklich nur im Worktree gearbeitet hast — ein gruener Health-curl allein reicht NICHT, weil - der laufende Dienst den alten Code im RAM haelt und eine schmutzige Datei auf der Platte nicht - bemerkt). - - `curl -sf http://127.0.0.1:9001/api/health` muss gruen bleiben. - - Ist `git status` NICHT leer: die fremden Aenderungen im Live-Checkout mit - `git -C ~/mission-control-v2 checkout -- ` zuruecknehmen (deine Arbeit liegt sicher im - Worktree) und im Vorschlag ehrlich erwaehnen. - -### 5. Zwei-Kritiker-Gate ueber den GESAMTEN Diff (Pflicht) -Zwei Zweitgutachter mit je anderer Staerke lesen den zusammengesetzten Diff gegen — aus demselben -Grund wie in der Werkstatt („wer seine eigenen Hausaufgaben benotet, stimmt sich selbst zu"). **NICHT -`delegate_task`** (laeuft ueber `heavy` → 64K-Floor + Warm-Set-Kollision). - -**Zuerst ALLES stagen** — sonst fehlen NEUE Dateien im Diff (haeufigste Falle: `git diff` ignoriert -untracked Dateien, die Kritiker bekaemen einen LEEREN Diff und wuerden alles blind ablehnen): -``` -git -C ~/.hermes/worktrees/orch- add -A -``` -Dann die Eingabe EINMAL bauen (mit `--cached`, damit die neuen Dateien drin sind): -``` -EINGABE="AUFTRAG (im Wortlaut): - - -ZERLEGUNG (deine Teil-Tasks, je 1 Zeile): -<1..n> - -GIT-DIFF des Worktrees: -$(git -C ~/.hermes/worktrees/orch- diff --cached origin/main)" -``` -Ist dieser Diff LEER, hast du nicht gestaged (oder nichts gebaut) → NICHT weiter, erst beheben. -**Kritik A — Kompetenz** (`Qwen3-Coder-Next`, starker Coder, vom Bauen noch geladen → KEIN Swap): -``` -printf '%s' "$EINGABE" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh -``` -**Kritik B — Fremd-Blick** (`GLM-4.6V-Flash`, andere Modellfamilie, andere blinde Flecken): -``` -printf '%s' "$EINGABE" | FREMDBLICK_MODE=code FREMDBLICK_MODEL=GLM-4.6V-Flash FREMDBLICK_MAXTOK=3000 ~/.hermes/scripts/fremdblick.sh -``` -Reihenfolge bewusst: erst A (Coder-Next ist noch warm), dann B (ein Swap zu GLM). Beide beginnen mit -`URTEIL: `. **Warte auf beide.** - -**Gate-Regel (streng):** Sagt AUCH NUR EINER `ABGELEHNT` → nachbessern (max. 2 Runden: den -betroffenen Teil-Task neu an den Worker, integrieren, BEIDE Kritiker erneut). `FREIGABE-MIT-VORBEHALT` -→ die Vorbehalte adressieren oder im Vorschlag ehrlich ausweisen (NICHT wegdiskutieren). Nur wenn -BEIDE tragen → Vorschlag. Beide Urteile KONKRET in den Vorschlag (welcher Kritiker was sagte). Faellt -ein Kritiker technisch aus (`FEHLGESCHLAGEN`/`ABGESCHNITTEN`) → einmal wiederholen, sonst „⚠ Kritik X -fiel aus" vermerken (NICHT als Freigabe zaehlen). - -> Der schwere **Chef-Gutachter (`gpt-oss`)** laeuft NICHT in diesem heissen Pfad — er muesste 60 GB -> kalt laden und Lucys Warm-Set stoeren. Er prueft separat NACHTS im Leerlauf ueber die offenen -> Orchestrator-Vorschlaege (eigener Cron), wo Ladezeit + Warm-Set-Umbau verkraftbar sind. -- `ABGELEHNT` / berechtigte `FREIGABE-MIT-VORBEHALT` → nachbessern (max. 2 Runden: den betroffenen - Teil-Task neu an den Worker geben, integrieren, erneut gaten). Bleibt es kritisch: Kritik in den - Vorschlag schreiben, Branch bleibt liegen, Entscheidung dem Commander. -- `FREMDBLICK FEHLGESCHLAGEN`/`ABGESCHNITTEN` → einmal wiederholen; sonst im Vorschlag ehrlich - „⚠ Fremd-Review fiel aus — UNGEPRUEFT" vermerken (NICHT als Freigabe behandeln). - -### 6. Telegram-Vorschlag (in LUCYS Stimme) -`bash ~/mission-control-v2/deploy/notify.sh -s "[Orchestrator]" ""` — an den Commander, nicht -als anonymer Job: erst 1–2 Saetze, was gebaut wurde und was er jetzt entscheiden soll; dann knapp: -- die **Zerlegung** (welcher Teil-Task an welches Worker-Modell ging), -- geaenderte/neue Dateien · Kern des Diffs, -- Self-Gate-Ergebnis · Kritiker-Urteil KONKRET ausgeschrieben (nicht nur „ok"), -- Branch-Name · Frage „merge oder verwerfen?" - -### 7. Nichts loeschen -Worktree + Branch + rohe Worker-Ausgaben bleiben liegen, bis der Commander entschieden hat. - -## Kontext-Uebergabe — hier geht Orchestrierung am ehesten schief -Jeder Worker startet **frisch und zustandslos**: kein Gedaechtnis der bisherigen Schritte, kein -Zugriff aufs Repo. Er sieht NUR, was du ihm auf stdin gibst. Deshalb: -- Gib ihm den **relevanten Ausschnitt** mit — die betroffene Datei (oder den betroffenen Block), - benachbarte Muster zum Nachahmen, die genaue Signatur/den Namen, den er treffen muss, und bei - Folge-Schritten die bereits fertigen Artefakte, auf die er aufbaut. -- Sei praezise beim Zielartefakt: „Gib den VOLLSTAENDIGEN Inhalt der neuen Datei `X` aus" bzw. „Gib - einen unified Diff gegen den folgenden Stand von `Y` aus". -- Zu wenig Kontext → der Worker raet oder meldet `FEHLT:`. Zu viel unnoetiger Kontext → er verliert - den Fokus. Ziel: das kleinste, das den Teil-Task eindeutig macht. - -## Nach dem Commander-Entscheid (kommt als neuer Auftrag) -- „verwerfen" → `git worktree remove ~/.hermes/worktrees/orch- --force && git branch -D orchestrator/` - (+ `rm -rf ~/.hermes/worktrees/orch--work`; Remote-Branch loeschen, falls gepusht). -- „merge" → das Mergen nach main + Deploy macht der PC/Claude (Frontend-Builds gibt es nur dort). - Du pushst NIE nach main. +--- +name: orchestrator +description: "Orchestrieren wie ein Manager: einen groesseren Auftrag in Teil-Tasks zerlegen, jeden SERIELL an das passende Worker-Modell delegieren (worker.sh, Ein-Schuss via llama-swap), die Ergebnisse einsammeln + zusammensetzen, per Fremd-Kritiker gaten und als Telegram-Vorschlag zurueckgeben. NIE selbst mergen/deployen — der Commander ist das Gate." +version: 1.0.0 +author: MC2 (Autonomie — Orchestrator) +platforms: [linux] +metadata: + hermes: + tags: [orchestrator, delegation, werkstatt, mc2, fliessband] +--- + +# Orchestrator — du managst, du fuehrst nicht alles selbst aus + +Nutze diesen Skill, wenn ein Auftrag zu gross fuer EINEN Rutsch ist, sich aber in wenige klar +abgegrenzte Teil-Tasks zerlegen laesst (ueberwiegend Code-Bau). Du bist der **Manager**: du +zerlegst, verteilst die Teile SERIELL an Worker-Modelle (die arbeiten), fuegst die Ergebnisse +zusammen und lieferst am Ende einen **Vorschlag** — der Commander entscheidet. + +Das ist die Verallgemeinerung der **Werkstatt** (`wartung`): dort delegierst du EINEN Schritt +(Code-Review) an ein Fremdmodell. Hier delegierst du MEHRERE Bau-Schritte an Worker und behaeltst +die Integration + das Gate. + +## Warum seriell (und warum das ok ist) +Mehrere grosse Modelle GLEICHZEITIG passen nicht in den Speicher. llama-swap ist **seriell** — ein +Modell laden → arbeiten → tauschen → naechstes. Orchestrierung ist ein **Fliessband, kein Schwarm.** +Langsamer (Swap-Latenz + einer nach dem anderen: Minuten), aber bei Hintergrund-/Telegram-Jobs egal. + +## Scope-Check zuerst (klein anfangen) +Passt: ein Auftrag, der in **2–4 abgegrenzte Teil-Tasks** zerfaellt, jeder ein 1–2-Datei-Bau-Schritt +(neues kleines Modul + Test, kleine neue Funktion + Verdrahtung, zusammenhaengender Refactor in +wenigen Dateien). Zu gross (viele Module, echte Architektur-Entscheidungen, breite API-Aenderung): +**Etappen-Weg statt Ablehnung** (Grossbau-Entscheid 10.07.2026) — zerlege das Projekt in Etappen, +von denen JEDE fuer sich lauffaehig, gate-gruen und einzeln annehmbar ist. Baue in DIESEM Lauf nur +Etappe 1 (als normalen Orchestrator-Durchlauf mit Workern + Zwei-Kritiker-Gate); den Etappen-Plan +in den Telegram-Vorschlag schreiben und die Folge-Etappen als neue Aufgaben in die Ideen-Queue +legen (`hermes kanban create " — Etappe : " --triage`, im Body: Plan + Branch der +Vor-Etappe). Eine Folge-Etappe wird erst gebaut, wenn der Branch der Vor-Etappe in main ist — +NIE auf unangenommene Branches aufbauen. Rauere Qualitaet ist bei Grossbau ok, aber ehrlich im +Vorschlag ausweisen, was fehlt oder wacklig ist. + +## Leitplanken (nicht verhandelbar) +- **Du delegierst, du baust NICHT selbst.** Jedes Bau-Artefakt MUSS aus einem `worker.sh`-Aufruf + stammen. Schreibst du den Code selbst (auch wenn der Teil-Task „einfach genug" wirkt), statt ihn + vom Worker zu holen, ist der Lauf GESCHEITERT — sag das ehrlich, statt Eigenbau als Orchestrierung + auszugeben. Belege jeden Teil-Task im Vorschlag mit dem `worker.sh`-Aufruf UND den ersten Zeilen + seiner Roh-Ausgabe. (Warum so streng: das Manager-Modell kann kleine Tasks selbst — genau dann + faellt Delegation aus Bequemlichkeit weg; das ist der haeufigste Orchestrierungs-Fehler.) +- **„Task zu klein" ist KEIN Freibrief (kein Ermessensspielraum).** Du darfst Planung, Delegation + oder das Zwei-Kritiker-Gate NICHT eigenmaechtig ueberspringen — auch nicht transparent angesagt + („Overkill, ich mach das direkt" = GESCHEITERTER Lauf, Vorfall 09.07.2026). Wirkt der Auftrag + wirklich zu klein fuers Fliessband, ist dein EINZIGER erlaubter Ausweg: **abbrechen ohne Code** + und im Vorschlag melden „zu klein fuer den Orchestrator — bitte als Werkstatt-Auftrag (hermes -z) + oder direkt im Desktop laufen lassen". Ein Lauf, der Code liefert, enthaelt IMMER worker.sh-Belege + UND beide Kritiker-Verdikte — ohne Ausnahme. +- **Die Helfer EXISTIEREN.** `~/.hermes/scripts/worker.sh` und `~/.hermes/scripts/fremdblick.sh` + sind installiert, aber NICHT auf deinem PATH → immer mit vollem Pfad aufrufen (nie bloss `worker.sh`). + Glaubst du, sie fehlen, IRRST du dich: erst `ls -la ~/.hermes/scripts/worker.sh` ausfuehren und den + Pfad lesen, dann nutzen. „Skript fehlt" ist KEIN gueltiger Grund, den Schritt selbst zu machen. +- **Propose-only.** Am Ende steht IMMER ein Telegram-Vorschlag; die Entscheidung trifft der Commander. + NIEMALS auf `main` committen, NIEMALS mergen, NIEMALS deployen oder Dienste neu starten. +- **Nur im Worktree arbeiten.** Die Live-Instanz `~/mission-control-v2` bleibt unberuehrt. +- **Warm-Set-Schutz (Speicher vs Latenz).** Worker werden ueber **`worker.sh`** aufgerufen. + Fuer die Umsetzung von Code nutzt du **`coder`** (laedt klein neben dem Warm-Set). + Fuer die initiale **Planung** nutzt du explizit den Chef-Gutachter **`gpt-oss-120b`** (heavy), + auch wenn dessen Laden (~15s) Lucys Sprech-Latenz temporaer aussetzt. Das ist fuer diesen + Hintergrund-Prozess gewollt. +- **Fremd-Kritiker ist Pflicht-Gate.** Der zusammengesetzte Diff MUSS von `fremdblick.sh` (anderes + Modell) gegengelesen werden, bevor du vorschlaegst. Ein Manager, der Worker-Output blind + zusammenklebt, produziert leisen Muell. +- **Security-Config ist TABU:** keine Tokens, approvals, ufw, sudoers, ssh-Keys anfassen. +- **Hermes-first (10.07.2026):** Bevor ein Teil-Task NEUE Infrastruktur baut (Skript, Dienst, + Tool, Cron), pruefe ob hermes-agent das nativ kann — erst in die Eigenbau-Landkarte schauen + (`~/wissens-vault/eigenbau-landkarte.md`), notfalls `bash -lc 'hermes --help'`. Den + Pruef-Befund in den Vorschlag schreiben („nativ vorhanden: nein/ja, weil …"). +- Gate rot oder Kritiker dagegen → trotzdem ehrlich melden (Branch bleibt liegen), nichts beschoenigen. + +## Ablauf + +### 1. Beratung & Zerlegen (Manager plant mit dem Chef) +Bevor du selbst Tasks aufteilst, befragst du zwingend **`gpt-oss-120b`** nach einem Architektur-Plan: +1. Sende den initialen Auftrag per `worker.sh` an den Chef-Planer: + ```bash + printf '%s' "Auftrag: $auftrag" | WORKER_MODEL=gpt-oss-120b WORKER_ROLE=plan ~/.hermes/scripts/worker.sh > /tmp/orch-plan.txt + ``` +2. Lies den Plan (`cat /tmp/orch-plan.txt`) und nutze ihn, um den Auftrag in eine **geordnete, nummerierte Liste von Teil-Tasks** zu zerlegen. +3. Fuer jeden Teil-Task entscheide: (a) Artefakt, (b) Worker (`coder` + `build`/`refactor`), (c) Kontext. + +### 2. Worktree anlegen (Slug = kurzer Kebab-Case-Name des Auftrags) +Worktrees liegen unter `~/.hermes/worktrees/` (NICHT /tmp — ueberlebt keinen Reboot und +hinterlaesst kaputte Worktree-Registrierungen, Review-Befund 15.07.): +``` +mkdir -p ~/.hermes/worktrees && cd ~/mission-control-v2 && git fetch -q origin \ + && git worktree add ~/.hermes/worktrees/orch- -b orchestrator/ origin/main +mkdir -p ~/.hermes/worktrees/orch--work # Ablage fuer rohe Worker-Ausgaben +``` + +### 3. Routen — je Teil-Task ein Worker-Ein-Schuss (seriell) +Fuer jeden Bau-Teil-Task: +1. Baue die Eingabe: **genau der noetige Kontext** + der praezise Auftrag (siehe unten). Bereits + fertige Artefakte aus frueheren Schritten als Kontext mitgeben, wenn der Worker sie braucht. +2. Ruf den Worker auf und fang die Ausgabe roh ab: + ``` + printf '%s' "$eingabe" | WORKER_ROLE=build ~/.hermes/scripts/worker.sh > ~/.hermes/worktrees/orch--work/.out + ``` + (Default-Modell ist `coder`. Fuer einen bewusst anderen Worker `WORKER_MODEL=`.) +3. **Pruefe die Ausgabe, bevor du sie verwendest:** Beginnt sie mit `FEHLT:`, hast du zu wenig + Kontext gegeben → nachliefern und erneut rufen. Hat der Worker versehentlich einen ```-Codezaun + oder Prosa drumherum gesetzt, entferne ihn. Dann schreibe das saubere Artefakt mit deinen + Datei-Tools an seinen Platz im Worktree (`~/.hermes/worktrees/orch-/...`). Der Worker hat KEINE + Datei-Haende — das Schreiben machst DU. +4. **Schreibziel-Pflicht (Vorfall 09.07.2026):** JEDES write_file/patch-Ziel MUSS mit + `~/.hermes/worktrees/orch-/` beginnen — vor dem ersten Schreiben einmal laut pruefen. NIEMALS nach + `~/mission-control-v2/...` schreiben (Live-Checkout!), NIEMALS Work-Dirs/Worktrees FREMDER + Slugs wiederverwenden (beim Doku-Lauf landete ein Artefakt im Live-Checkout, weil das alte + `/tmp/orch-hermes-desktop-work` recycelt wurde). Existiert dein `~/.hermes/worktrees/orch-` noch nicht, + ist das der Beweis, dass Schritt 2 fehlt — erst Worktree anlegen. +5. **Grosse Artefakte NIE im Klartext in deine Antwort** — sie gehoeren in Dateien im Worktree. + Wer Dateiinhalte in die Antwort kippt, stirbt am Output-Limit mitten im Lauf (Doku-Lauf + 09.07.2026: abgewuergt VOR Kritiker-Gate und Vorschlag). In der Antwort: Pfade + 1-Zeilen-Zusammenfassung. + +### 4. Integrieren + Self-Gate (nach jedem Schritt bzw. am Ende) +Die Worker liefern Bausteine — DU sorgst dafuer, dass sie zusammenpassen (Imports, Verdrahtung, +Namen). Dann das Selbst-Gate, was zutrifft: +- Python geaendert → `python3 -m py_compile ` (und wenn ein Test dabei ist und ohne + schwere Deps laeuft: den Test im Worktree ausfuehren). +- Shell geaendert → `bash -n ` +- Frontend (`frontend/src/...`) → **Node EXISTIERT auf der Box** (bewiesen 09.07.2026, Läufe + role-metadata + desktop-gateway): im Worktree `cd frontend && npm install && npm run build` + ausfuehren und das neue `frontend/dist` MIT-committen (AGENTS.md-Pflicht — sonst zeigt die Box + nach Merge+Deploy den alten Stand). **Danach `git checkout -- frontend/package-lock.json`**, + falls npm install es nur als Nebeneffekt angefasst hat (wiederkehrendes Muster: 3 Laeufe in + Folge hatten lockfile-Dreck) — es gehoert NUR in den Commit, wenn Dependencies sich wirklich + aendern sollten. Schlaegt der Build fehl, ehrlich ausweisen: „Gate eingeschraenkt: Build + fehlgeschlagen, tsc laeuft beim Merge auf dem PC." +- **Live-Checkout unberuehrt (PFLICHT, zwei Beweise):** + - `git -C ~/mission-control-v2 status --porcelain -uno` **muss LEER sein** (Beweis, dass du + wirklich nur im Worktree gearbeitet hast — ein gruener Health-curl allein reicht NICHT, weil + der laufende Dienst den alten Code im RAM haelt und eine schmutzige Datei auf der Platte nicht + bemerkt). + - `curl -sf http://127.0.0.1:9001/api/health` muss gruen bleiben. + - Ist `git status` NICHT leer: die fremden Aenderungen im Live-Checkout mit + `git -C ~/mission-control-v2 checkout -- ` zuruecknehmen (deine Arbeit liegt sicher im + Worktree) und im Vorschlag ehrlich erwaehnen. + +### 5. Zwei-Kritiker-Gate ueber den GESAMTEN Diff (Pflicht) +Zwei Zweitgutachter mit je anderer Staerke lesen den zusammengesetzten Diff gegen — aus demselben +Grund wie in der Werkstatt („wer seine eigenen Hausaufgaben benotet, stimmt sich selbst zu"). **NICHT +`delegate_task`** (laeuft ueber `heavy` → 64K-Floor + Warm-Set-Kollision). + +**Zuerst ALLES stagen** — sonst fehlen NEUE Dateien im Diff (haeufigste Falle: `git diff` ignoriert +untracked Dateien, die Kritiker bekaemen einen LEEREN Diff und wuerden alles blind ablehnen): +``` +git -C ~/.hermes/worktrees/orch- add -A +``` +Dann die Eingabe EINMAL bauen (mit `--cached`, damit die neuen Dateien drin sind): +``` +EINGABE="AUFTRAG (im Wortlaut): + + +ZERLEGUNG (deine Teil-Tasks, je 1 Zeile): +<1..n> + +GIT-DIFF des Worktrees: +$(git -C ~/.hermes/worktrees/orch- diff --cached origin/main)" +``` +Ist dieser Diff LEER, hast du nicht gestaged (oder nichts gebaut) → NICHT weiter, erst beheben. +**Kritik A — Kompetenz** (`coder`, starker Coder, vom Bauen noch geladen → KEIN Swap): +``` +printf '%s' "$EINGABE" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh +``` +**Kritik B — Fremd-Blick** (`debugger`, andere Modellfamilie, andere blinde Flecken): +``` +printf '%s' "$EINGABE" | FREMDBLICK_MODE=code FREMDBLICK_MODEL=debugger FREMDBLICK_MAXTOK=3000 ~/.hermes/scripts/fremdblick.sh +``` +Reihenfolge bewusst: erst A (Coder-Next ist noch warm), dann B (ein Swap zu GLM). Beide beginnen mit +`URTEIL: `. **Warte auf beide.** + +**Gate-Regel (streng):** Sagt AUCH NUR EINER `ABGELEHNT` → nachbessern (max. 2 Runden: den +betroffenen Teil-Task neu an den Worker, integrieren, BEIDE Kritiker erneut). `FREIGABE-MIT-VORBEHALT` +→ die Vorbehalte adressieren oder im Vorschlag ehrlich ausweisen (NICHT wegdiskutieren). Nur wenn +BEIDE tragen → Vorschlag. Beide Urteile KONKRET in den Vorschlag (welcher Kritiker was sagte). Faellt +ein Kritiker technisch aus (`FEHLGESCHLAGEN`/`ABGESCHNITTEN`) → einmal wiederholen, sonst „⚠ Kritik X +fiel aus" vermerken (NICHT als Freigabe zaehlen). + +> Der schwere **Chef-Gutachter (`gpt-oss`)** laeuft NICHT in diesem heissen Pfad — er muesste 60 GB +> kalt laden und Lucys Warm-Set stoeren. Er prueft separat NACHTS im Leerlauf ueber die offenen +> Orchestrator-Vorschlaege (eigener Cron), wo Ladezeit + Warm-Set-Umbau verkraftbar sind. +- `ABGELEHNT` / berechtigte `FREIGABE-MIT-VORBEHALT` → nachbessern (max. 2 Runden: den betroffenen + Teil-Task neu an den Worker geben, integrieren, erneut gaten). Bleibt es kritisch: Kritik in den + Vorschlag schreiben, Branch bleibt liegen, Entscheidung dem Commander. +- `FREMDBLICK FEHLGESCHLAGEN`/`ABGESCHNITTEN` → einmal wiederholen; sonst im Vorschlag ehrlich + „⚠ Fremd-Review fiel aus — UNGEPRUEFT" vermerken (NICHT als Freigabe behandeln). + +### 6. Telegram-Vorschlag (in LUCYS Stimme) +`bash ~/mission-control-v2/deploy/notify.sh -s "[Orchestrator]" ""` — an den Commander, nicht +als anonymer Job: erst 1–2 Saetze, was gebaut wurde und was er jetzt entscheiden soll; dann knapp: +- die **Zerlegung** (welcher Teil-Task an welches Worker-Modell ging), +- geaenderte/neue Dateien · Kern des Diffs, +- Self-Gate-Ergebnis · Kritiker-Urteil KONKRET ausgeschrieben (nicht nur „ok"), +- Branch-Name · Frage „merge oder verwerfen?" + +### 7. Nichts loeschen +Worktree + Branch + rohe Worker-Ausgaben bleiben liegen, bis der Commander entschieden hat. + +## Kontext-Uebergabe — hier geht Orchestrierung am ehesten schief +Jeder Worker startet **frisch und zustandslos**: kein Gedaechtnis der bisherigen Schritte, kein +Zugriff aufs Repo. Er sieht NUR, was du ihm auf stdin gibst. Deshalb: +- Gib ihm den **relevanten Ausschnitt** mit — die betroffene Datei (oder den betroffenen Block), + benachbarte Muster zum Nachahmen, die genaue Signatur/den Namen, den er treffen muss, und bei + Folge-Schritten die bereits fertigen Artefakte, auf die er aufbaut. +- Sei praezise beim Zielartefakt: „Gib den VOLLSTAENDIGEN Inhalt der neuen Datei `X` aus" bzw. „Gib + einen unified Diff gegen den folgenden Stand von `Y` aus". +- Zu wenig Kontext → der Worker raet oder meldet `FEHLT:`. Zu viel unnoetiger Kontext → er verliert + den Fokus. Ziel: das kleinste, das den Teil-Task eindeutig macht. + +## Nach dem Commander-Entscheid (kommt als neuer Auftrag) +- „verwerfen" → `git worktree remove ~/.hermes/worktrees/orch- --force && git branch -D orchestrator/` + (+ `rm -rf ~/.hermes/worktrees/orch--work`; Remote-Branch loeschen, falls gepusht). +- „merge" → das Mergen nach main + Deploy macht der PC/Claude (Frontend-Builds gibt es nur dort). + Du pushst NIE nach main. diff --git a/deploy/skills/wartung/SKILL.md b/deploy/skills/wartung/SKILL.md index 214ee0a..30e753c 100644 --- a/deploy/skills/wartung/SKILL.md +++ b/deploy/skills/wartung/SKILL.md @@ -80,7 +80,7 @@ unangenommene Branches aufbauen — erst wenn die Vor-Etappe in main ist, kommt diff origin/main>" | FREMDBLICK_MODE=code ~/.hermes/scripts/fremdblick.sh ``` - Das läuft auf `Qwen3-Coder-Next` (128k, code-stark, anderes Modell als der Qwen3.6-Worker, + Das läuft auf `coder` (128k, code-stark, anderes Modell als der Qwen3.6-Worker, lädt klein neben dem Warm-Set) mit einem Code-Review-Raster. **Warte auf die Ausgabe.** Der Kritiker leitet den Fehlerfall SELBST aus der Bug-Beschreibung ab (glaubt dem Autor nicht), spielt den geänderten Code durch und beginnt mit `URTEIL: