simplify Athena runtime and centralize MCP management

ATHENA.md

@@ -13,9 +13,9 @@ Fehlersuche sie benötigt.
 - Lokale Konfiguration und Secrets: `/etc/mike-ai` (niemals in Git).
 - Benutzerzugriff auf KI-Dienste: über WireGuard, nicht über das Uni-LAN.
 - OpenAI-kompatible Modell-API: Profile Router auf Port 8081.
-- Oberfläche auf Athena: OpenWebUI. Der offizielle Hermes Agent läuft auf
-  Unraid unter `/mnt/nvme-storage/appdata/Hermes-Agent` und verwendet Athenas
-  Router als Modell-Backend.
+- Oberfläche und Agent: Hermes auf Unraid unter
+  `/mnt/nvme-storage/appdata/Hermes-Agent`. Athena stellt dafür nur die
+  OpenAI-kompatible Router-API bereit. OpenWebUI ist abgeschaltetes Rückfallnetz.
 - Inferenz: genau ein aktives llama.cpp-Textprofil; der Router wechselt bei
   Bedarf zwischen Fast, Medium, Large, Ultra und Uncensored.
 
@@ -35,16 +35,11 @@ Migration höchstens als gekennzeichnetes Archiv existieren.
 
 ## Container-Prinzip
 
-Ein eigener Container ist sinnvoll, wenn ein Dienst eigene Abhängigkeiten,
-Zugangsdaten oder eine eigene Fehlergrenze hat. Deshalb bleiben die fachlichen
-MCPs getrennt, beispielsweise Home Assistant, Unraid, ARR, Navidrome, Deemix,
-Web und SSH. Es gibt jedoch keine zusätzlichen MCPs für einzelne
-Zwischenschritte einer Installation.
-
-Hermes auf Unraid ist die primäre Oberfläche für längere administrative und
-agentische Aufgaben. OpenWebUI auf Athena erhält weiterhin die Werkzeuge, die
-für kurze Abfragen sinnvoll sind. Ein neuer MCP muss nicht automatisch in jede
-Oberfläche eingebunden werden; das richtet sich nach dem Auftrag.
+Athena betreibt nur Inferenz, Router, Sprache/Bild, Backup und den
+hostgebundenen Athena-Operator. Portable Fach-MCPs laufen als getrennte
+Unterprozesse im **einen MCPHub-Container auf Unraid**. Sie bleiben unter
+`/mcp/NAME` einzeln sichtbar und abschaltbar, brauchen aber nicht je einen
+Docker-Container. `config/mcp-registry.json` ist die einzige Serverliste.
 
 ## Standardablauf für Änderungen
 
@@ -63,18 +58,14 @@ Werkzeugaufruf wird höchstens einmal wiederholt.
 
 ## Neuer MCP
 
-Für einen neuen MCP sind gewöhnlich nur diese Teile nötig:
+Portable MCPs werden nach dem Skill `mcphub-deployer` in das reproduzierbare
+MCPHub-Image eingebaut. Dazu gehören gepinnte Quelle, genau ein Registry-Eintrag,
+Secret-Datei nur im Appdata, Build, Handshake und eine read-only-Probe. Danach
+wird ausschließlich MCPHub über Unraid DockerMan neu erstellt. Router, Qwen,
+WireGuard und andere Container werden nicht neu gestartet.
 
-1. Servercode und Dockerfile unter `platform/mcp/`.
-2. Ein Service im eingebundenen `platform/mcp/compose.yaml`.
-3. Eine Env-Beispieldatei unter `config/`; echte Werte nach `/etc/mike-ai`.
-4. Genau ein Eintrag in `config/mcp-registry.json`; daraus werden Hermes und
-   OpenWebUI automatisch erzeugt.
-5. Ein kleiner Test sowie ein kurzer Eintrag in dieser Datei oder in der
-   Komponentenübersicht, falls wirklich zusätzliche Erklärung nötig ist.
-
-Dann wird nur der neue MCP gebaut und gestartet. Router, Qwen, WireGuard,
-Hermes und der komplette Stack werden nicht pauschal neu gestartet.
+Nur ein Werkzeug, das Athenas Host selbst verwalten muss, gehört in den
+Athena-Operator. Es wird kein zweiter allgemeiner Terminal- oder Doku-MCP gebaut.
 
 ## Temporär oder dauerhaft