fix(skills): worker.sh und restliche Doku auf Rollen-Aliase umgestellt

Zweite Fundwelle derselben Ursache: deploy/worker.sh setzte
WORKER_MODEL-Default auf Qwen3-Coder-Next - damit waere JEDE delegierte
Bau-/Refactor-Aufgabe des Orchestrators mit HTTP 404 gescheitert.

Ausserdem: konzept-fliessband nannte GLM-4.7-Flash als Skeptiker,
router_logic.py nannte Qwen3-Coder-Next hinter der coder-Rolle.
Modellnamen raus, Rollen rein - Namen veralten, Rollen nicht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/services/router_logic.py

@@ -3,7 +3,7 @@ Lane-Routing für den eingebauten MC2-Gateway (:9001/v1).
 
 Zwei virtuelle Lanes, die Clients/IDEs auswählen — der Router pickt das echte Modell:
 - **chat**  (= altes `auto`): Alltag → `fast`, schwer/lang → `heavy`.
-- **coding**: Code-Arbeit → `coder` (Qwen3-Coder-Next); riesiger/architektonischer Kontext → `heavy`;
+- **coding**: Code-Arbeit → `coder`; riesiger/architektonischer Kontext → `heavy`;
   triviale Kurzfrage ohne Code → `fast` (Tempo).
 
 Regelbasiert, sub-ms, ohne Cloud. Schwellen/Aliases liegen in einer UI-editierbaren Policy

deploy/skills/konzept-fliessband/SKILL.md

@@ -44,7 +44,7 @@ heavy-Rollen einer Runde am Stueck (heavy bleibt warm), DANN der Skeptiker (ein
   aus — fuer diesen Hintergrund-Job gewollt. heavy hat nur **32k Kontext** → halte das Konzept-
   Dokument kompakt und schleppe KEINE alten Runden-Protokolle mit (siehe Kontext-Uebergabe).
 - **REASONING-MODELLE brauchen Token-Luft (verifiziert 14.07.).** heavy (gpt-oss) UND der Skeptiker
-  (GLM-4.7-Flash) „denken" erst ausfuehrlich (im `reasoning_content`), bevor die eigentliche Antwort
+  (`fast`) „denken" erst ausfuehrlich (im `reasoning_content`), bevor die eigentliche Antwort
   in `content` landet — `worker.sh`/`fremdblick.sh` lesen NUR `content`. Zu knappes `max_tokens` =
   das Modell verbraucht alles beim Denken, `content` bleibt LEER, das Skript meldet „FEHLGESCHLAGEN"
   (obwohl das Modell lief). GLM verbrennt real ~2000 Tokens Denken fuer 2 Zeilen Antwort. Deshalb

deploy/worker.sh

@@ -6,7 +6,7 @@
 # neben dem Warm-Set liegt bewusst in DEINER Hand.
 #
 # WICHTIG (Speicher & Latenz-Trade-off):
-#   Der Standard-Worker ist Qwen3-Coder-Next (laedt klein und schnell neben dem Warm-Set).
+#   Der Standard-Worker ist die Rolle `coder` (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.
@@ -16,10 +16,10 @@
 # in Dateien macht der Manager (Hermes) danach mit seinen eigenen Tools.
 #
 # Nutzung:  printf '%s' "$teiltask_mit_kontext" | WORKER_ROLE=build worker.sh > /tmp/out.py
-#           printf '%s' "$spec" | WORKER_MODEL=Qwen3-Coder-Next WORKER_ROLE=build worker.sh
+#           printf '%s' "$spec" | WORKER_MODEL=coder WORKER_ROLE=build worker.sh
 #
 # Env-Overrides:
-#   WORKER_MODEL   echte llama-swap-ID (Default: Qwen3-Coder-Next). NICHT gpt-oss/heavy (siehe oben).
+#   WORKER_MODEL   Rollen-Alias oder echte ID (Default: coder). NICHT gpt-oss/heavy (siehe oben).
 #   WORKER_ROLE    build (Default) | refactor | plan | prose  — waehlt das System-Raster.
 #   WORKER_SYS     eigenes System-Raster (uebersteuert WORKER_ROLE).
 #   WORKER_MAXTOK  max_tokens (Default 4000 — Code braucht Platz).
@@ -29,7 +29,7 @@ set -uo pipefail
 # Achtung: llama-swap listet unter /v1/models die ECHTEN Modell-IDs, nicht die Gateway-Aliase
 # (kein "heavy"/"coder"/"scout" hier — die echte ID nehmen).
 ENDPOINT="${WORKER_ENDPOINT:-http://127.0.0.1:8080/v1/chat/completions}"
-MODEL="${WORKER_MODEL:-Qwen3-Coder-Next}"
+MODEL="${WORKER_MODEL:-coder}"
 ROLE="${WORKER_ROLE:-build}"
 MAXTOK="${WORKER_MAXTOK:-4000}"
 TEMP="${WORKER_TEMP:-0.1}"