diff --git a/deploy/skills/orchestrator/SKILL.md b/deploy/skills/orchestrator/SKILL.md
index 5c21f1f..cd95041 100644
--- a/deploy/skills/orchestrator/SKILL.md
+++ b/deploy/skills/orchestrator/SKILL.md
@@ -46,10 +46,11 @@ dann kleiner.
 - **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 (harte Speicher-Falle).** Worker nur ueber **`worker.sh`** und nur Modelle, die
-  KLEIN neben dem Warm-Set laden — v1 = **`Qwen3-Coder-Next`** (Default in worker.sh). **NIEMALS
-  `heavy`/`gpt-oss-120b` als Worker** (60 GB → stirbt neben dem VL-30B-Warm-Set, gefaehrdet Lucys
-  ~1-s-Sprech-Latenz). Planung/Zerlegung/Integration machst DU (Hermes, schon warm) selbst.
+- **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.
@@ -58,12 +59,14 @@ dann kleiner.
 
 ## Ablauf
 
-### 1. Zerlegen (der Manager denkt)
-Brich den Auftrag in eine **geordnete, nummerierte Liste von Teil-Tasks**. Fuer jeden Teil-Task
-entscheide: (a) was ist das Artefakt (welche Datei, was tut sie), (b) welches Worker-Modell +
-welche Rolle (`build`/`refactor`), (c) welchen Kontext braucht der Worker (siehe Abschnitt
-„Kontext-Uebergabe"). Halte die Liste kurz. Reihe die Teile so, dass spaetere auf fertige
-fruehere aufbauen koennen.
+### 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)
 ```
diff --git a/deploy/worker.sh b/deploy/worker.sh
index 66b1032..550ce00 100644
--- a/deploy/worker.sh
+++ b/deploy/worker.sh
@@ -5,10 +5,11 @@
 # → umgeht Hermes' 64K-Delegations-Floor (MINIMUM_CONTEXT_LENGTH) und das Laden grosser Modelle
 # neben dem Warm-Set liegt bewusst in DEINER Hand.
 #
-# WICHTIG (harte Speicher-Falle): Waehle nur Worker, die KLEIN neben dem Warm-Set laden.
-#   v1-Palette = Qwen3-Coder-Next (128k, code-stark, laedt klein). NIEMALS "heavy"/gpt-oss-120b
-#   als Worker: 60 GB stirbt beim Laden neben dem VL-30B-Warm-Set (Health-Check-Timeout) und
-#   gefaehrdet Lucys ~1-s-Sprech-Latenz.
+# WICHTIG (Speicher & Latenz-Trade-off):
+#   Der Standard-Worker ist Qwen3-Coder-Next (laedt klein und schnell neben dem Warm-Set).
+#   Fuer initiale Planung kann "gpt-oss-120b" gerufen werden. Das Modell passt knapp in den
+#   Speicher (124 GB RAM), aber das on-demand Laden unterbricht Lucys 1-s-Latenz fuer ca.
+#   15-30 Sekunden. Dieser Latenz-Hit wird fuer die Orchestrator-Planung in Kauf genommen.
 #
 # Der Worker ist ZUSTANDSLOS: kein Gedaechtnis, keine Datei-Haende. Er bekommt GENAU den Kontext,
 # den du ihm auf stdin gibst, und liefert TEXT zurueck (Datei-Inhalt / Diff / Plan). Das SCHREIBEN