--- 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) ``` cd ~/mission-control-v2 && git fetch -q origin \ && git worktree add /tmp/orch- -b orchestrator/ origin/main mkdir -p /tmp/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 > /tmp/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 (`/tmp/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 `/tmp/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 `/tmp/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 /tmp/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 /tmp/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 /tmp/orch- --force && git branch -D orchestrator/` (+ `rm -rf /tmp/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.