Zuendung (S4): Idle-Radar + Grossbau-Etappen-Regeln

- deploy/idle-radar-feed.sh (Hermes-Cron 03:45): destilliert aus Journal-
  Fehlermustern (24h) + juengster Traum-Notiz max. 2 belegte Wartungs-
  Kandidaten und legt sie als rohe Ideen (triage) ins native Kanban.
  Ehrlichkeits-Gate: Beleg-Zitat wird MECHANISCH gegen das Material
  geprueft (reproduziert-oder-abgelehnt). Stau-Bremse (>=4 offene Queue-
  Aufgaben oder >=3 offene Karten -> nichts Neues), Dedup dreifach
  (State-Datei + Board-Abgleich inkl. archivierter + --idempotency-key),
  Security/Config/Updates tabu. Analyst gpt-oss-120b, Vertretung GLM.
- deploy/idle-radar-prompt.md: versionierter Boten-Auftrag (Lucys Stimme,
  max 3 Saetze, nichts selbst umsetzen).
- deploy.sh: kopiert idle-radar-feed.sh nach ~/.hermes/scripts/ (greift
  wegen Selbst-Reset-Falle erst ab dem 2. Deploy -> Vorinstallation
  einmalig von Hand; Cron-Registrierung einmalig: hermes cron create).
- Grossbau-Etappen-Regeln (Zielbild-Entscheid 4, 10.07.): werkstatt-SOUL
  Regel 6 + wartung-/orchestrator-SKILL Scope-Check: Grosses nicht mehr
  ablehnen, sondern in Etappen bauen - jede Etappe eigener Branch, fuer
  sich lauffaehig + annehmbar, Folge-Etappen als neue Queue-Aufgaben,
  NIE auf unangenommene Branches aufbauen.
- Doku: AUFTRAGSBUCH.md (Idle-Radar-Abschnitt), wissen/OFFENE-FAEDEN.md.

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

deploy/skills/orchestrator/SKILL.md

@@ -29,8 +29,14 @@ Langsamer (Swap-Latenz + einer nach dem anderen: Minuten), aber bei Hintergrund-
 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):
-dann NUR einen **Plan** als Text im Telegram-Vorschlag liefern, KEINEN Code — der Commander schneidet
-dann kleiner.
+**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 "<Projekt> — Etappe <n>: <was>" --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

deploy/skills/wartung/SKILL.md

@@ -16,7 +16,11 @@ Nutze diesen Skill, wenn ein kleiner, klar umrissener Wartungsauftrag für das M
 
 **Scope-Check zuerst:** Klein = Config-Schlüssel-Migration, Dependency-Bump (Lockfile),
 Patch in 1–2 Dateien. Alles Größere (Architektur, mehrere Module, neue Features):
-NUR einen Plan liefern (Text im Telegram-Vorschlag), KEINEN Code.
+NICHT pauschal ablehnen, sondern den **Etappen-Weg** gehen (Großbau-Entscheid 10.07.2026):
+einen Etappen-Plan in den Vorschlag schreiben (jede Etappe für sich lauffähig + annehmbar)
+und NUR Etappe 1 als eigenen Vorschlags-Branch bauen; Folge-Etappen als neue Aufgaben in
+die Ideen-Queue (`hermes kanban create "<Projekt> — Etappe <n>: <was>" --triage`). NIE auf
+unangenommene Branches aufbauen — erst wenn die Vor-Etappe in main ist, kommt die nächste.
 
 ## Leitplanken (nicht verhandelbar)