docs: "Waechter"/Orchestrator gestaffelt (billiger Heartbeat vs teure Steuerung)

Idee Container-start/stop auf RVS-Hosts: billiger Teil (Registrierung/Heartbeat
-> Flotten-Sichtbarkeit + Router-Erreichbarkeit) lohnt bald; teurer Teil
(Agent+Controller+Placement = Mini-Nomad) erst bei groesserer Flotte, dann eher
Swarm/Nomad statt Eigenbau. Fuer 2 Gameboxen: statische Platzierung + llama-swap.

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

docs/plan-local-llm-router.md

@@ -195,6 +195,24 @@ VRAM-Bedarf: 12 GB (1×3060) = kuratierte Tools; 24 GB (2×3060, eine Box) = Qwe
 mit grossem Kontext/volles Schema oder groesseres Modell; Cluster = weitere
 GPU-Hosts als Modell-Server ueber RVS. (B0.5/B1-UI.)
 
+### „Waechter" / Orchestrator (Ausbaustufe, gestaffelt)
+
+Idee: ein Dienst, der auf den am RVS angemeldeten Hosts Container startet/stoppt.
+Zerfaellt in zwei Teile:
+- **Billig & bald nuetzlich — Registrierung + Heartbeat:** jeder GPU-Host meldet
+  dem RVS „lebe, GPUs, VRAM frei, laufende Dienste" (kleine Erweiterung der
+  Adapter; whisper broadcastet schon Status). Nutzen: Diagnostic zeigt die
+  Flotte (Live-Daten fuers ⓘ), Router weiss ob lokal erreichbar (sonst Claude).
+- **Teuer & aufschiebbar — Steuerung (Container start/stop):** Agent pro Host
+  (Docker-Socket) + Controller mit Placement-Policy + Reconciliation +
+  Broadcast-Kollisions-Vermeidung (nicht 2× dieselbe Faehigkeit). = Mini-Nomad.
+
+**Empfehlung:** Fuer 2 Gameboxen NICHT bauen — statische Platzierung reicht
+(Gamebox1=LLM, Gamebox2=Voice). Dynamisches Laden/Entladen zum VRAM-Freimachen
+deckt `llama-swap` innerhalb eines Hosts (B0.5). Waechst die Flotte: erst den
+billigen Heartbeat-Teil; fuer echte Orchestrierung Docker Swarm / Nomad nehmen
+statt selbst einen Scheduler zu bauen.
+
 ## Nicht-Ziele
 
 - Kein echter Gemini-Live-Duplex-Klon (Text-Modell als Hirn).