Document Athena rebuild and clarify tool volume ownership

README.md

@@ -60,6 +60,7 @@ Qwen-Modells.
 - [Betrieb und Profilwechsel](docs/OPERATIONS.md)
 - [Sicherheitsmodell](docs/SECURITY.md)
 - [Disaster Recovery](docs/DISASTER_RECOVERY.md)
+- [Protokoll des Athena-Leerhostaufbaus](docs/ATHENA_REBUILD_LOG.md)
 - [Komponenten](docs/COMPONENTS.md)
 
 ## Wichtige Dateien

docs/ATHENA_REBUILD_LOG.md

@@ -0,0 +1,65 @@
+# Athena-Leerhostaufbau – Praxisprotokoll
+
+Dieses Protokoll hält die Abweichungen fest, die beim realen Neuaufbau auf
+einem frischen Debian-13-Host sichtbar wurden. Jede dauerhaft notwendige
+Korrektur muss zusätzlich im Installer, Restore-Skript oder in der regulären
+Betriebsdokumentation umgesetzt werden. Das Protokoll enthält keine Secrets,
+Chats oder privaten Nutzdaten.
+
+## Zielsystem
+
+- Hostname: `Athena`
+- Betriebssystem: Debian 13 amd64
+- Persistente Datenplatte: `/data`, ext4
+- Haupt-GPU: NVIDIA RTX 5080 mit 16 GB VRAM
+- Containerbetrieb: Docker CE und Compose-Plugin
+- Inferenz: gepinnter llama.cpp-Build in Docker
+- Oberfläche: OpenWebUI
+- Werkzeuge: getrennte MCP-Container für Web, Home Assistant, ARR und Unraid
+
+## Bereits eingearbeitete Korrekturen
+
+| Bereich | Beobachtung im Leerhosttest | Dauerhafte Umsetzung |
+|---|---|---|
+| NVIDIA | Debian-Basispakete allein lieferten nicht den benötigten aktuellen Treiberzweig. | Offizielles NVIDIA-Repository, Mindestversion, Open-Kernelmodule und reproduzierbarer Neustartpfad im Installer. |
+| CUDA | Container fanden einzelne CUDA-Kompatibilitätsbibliotheken nicht zuverlässig. | Bibliothekspfad und `ldconfig` werden vom Installer hergestellt und geprüft. |
+| Modelle | Durch die restriktive Installer-Umask konnte der unprivilegierte Inferenzprozess GGUF-Dateien nicht lesen. | Nach erfolgreicher Hashprüfung werden Modelle unveränderlich, aber lesbar mit Modus `0444` gesetzt. |
+| MTP | Das Fast-Modell besitzt den verwendeten MTP-Tensor bereits im IQ4-MIX-GGUF. | Kein redundanter Draft-Download und kein falscher separater Startparameter. |
+| Router | Frische Volumes und der unmittelbar folgende API-Aufruf führten zu Ownership- beziehungsweise Start-Rennen. | Minimale Dateisystem-Capabilities, eigener Healthcheck, Abhängigkeit von gesundem Controller und explizite Readiness-Prüfung. |
+| Installer | Ein erfolgreicher Containerstart wurde zu früh als erfolgreiche Installation gewertet. | Abschluss erst nach Router-Health, erfolgreicher Fast-Aktivierung und eindeutigem `INSTALL_READINESS_OK`-Marker. |
+| Websuche | TinySearch/SearXNG wurden in mehreren Pfaden gestartet. | Websuche wird ausschließlich durch den Tool-Stack installiert und gestartet. |
+| MCP | Altcontainer sollten nicht in die neue Architektur übernommen werden. | Neue, getrennte Tool-Container; Restore importiert nur freigegebene Secret- und Laufzeitdateien. |
+| OpenWebUI | Eine gesicherte Datenbank war neuer als das zunächst gepinnte OpenWebUI-Image. | Datenbank und Image werden versionsgleich wiederhergestellt; Registry-Digest und OCI-Build-Revision werden geprüft. |
+| Image-Backup | Das alte Archiv `openwebui-mcp-images.tar.gz` enthielt trotz seines Namens nicht das inventarisierte OpenWebUI-Image. | Restore nutzt als sicheren Fallback nur den gesicherten unveränderlichen Digest. Künftige Backups benötigen einen isolierten Probeimport. |
+| Wiederholung | Ein späterer Installerlauf hätte die restaurierte OpenWebUI-Version wieder überschrieben. | Das Restore schreibt den geprüften lokalen Image-Tag auch in die dauerhafte Installationskonfiguration. |
+| TinySearch-Volume | Das vom Installer vorbereitete Modellvolume wurde von Compose gleichzeitig als Compose-eigen behandelt. | Das Volume besitzt einen festen Namen und ist in Compose ausdrücklich als extern vorbereitet markiert. |
+
+## Abnahmezustand am 21. August 2026
+
+- Basisinstallation einschließlich Treiber, Docker, llama.cpp, Router und
+  Fast-Profil erfolgreich.
+- Fast-Profil mit 76.800 Token Kontext gestartet und durch Readiness bestätigt.
+- HA-, ARR-, Unraid- und Web-MCP als getrennte Container gestartet.
+- OpenWebUI-Daten und freigegebene MCP-Konfiguration aus dem Referenzbackup
+  übernommen.
+- Exakter OpenWebUI-Build anhand des gesicherten Registry-Digests und Commits
+  rekonstruiert.
+- Vollständiger Restore ein zweites Mal erfolgreich und ohne Datenbankmigration
+  ausgeführt.
+- OpenWebUI, Router und Fast-Inferenz sind gesund; HTTP-Zugriffe liefern Status
+  200 und der Router meldet `qwen-fast`, `qwen-medium` und `qwen-long`.
+- Alle vier MCP-Endpunkte sind aus dem OpenWebUI-Netz per TCP erreichbar.
+
+## Noch abzunehmen
+
+1. Anmeldung und Profilwechsel über die Oberfläche ohne Lesen alter
+   Chat-Inhalte.
+2. MCP-Protokolltest jedes Werkzeugs und Prüfung seiner Sicherheitsgrenze.
+3. Neustarttest des gesamten Hosts.
+4. WireGuard- und Fail-closed-Test am späteren Universitätsstandort.
+5. Standardbenchmark mit RTX 5080 und anschließend mit der RTX 3060.
+6. Push der lokalen Commits nach unabhängiger Prüfung des Git-Server-
+   Hostschlüssels.
+
+Erst nach diesen Punkten gilt Athena als vollständig reproduzierbare
+Referenzinstallation.

platform/mcp/compose.yaml

@@ -144,4 +144,6 @@ networks:
 
 volumes:
   tinysearch-models:
+    name: mike-ai-tools_tinysearch-models
+    external: true
   unraid-audit: