Move development runtime to isolated Athena Debian instance

README.md

@@ -18,37 +18,24 @@ Downloads und Builds sind deaktiviert. Details: [GUI-Prototyp](STUDIO.md).
 ## Zugang und API-Token
 
 Beim ersten Öffnen werden Oberflächenkennwort und separater API-Token eingerichtet.
-Beide sind unter **Zugang & API** änderbar. Die lokale Vorschau ist jetzt ebenfalls
-anmeldepflichtig. Details und API-Rechte: [Zugangsverwaltung](ACCESS.md).
+Beide sind unter **Zugang & API** änderbar. Der Debian-Installer richtet den Zugang vor dem Serverstart ein. Details und API-Rechte: [Zugangsverwaltung](ACCESS.md).
 
 ## WireGuard-Einstellungen
 
-Installation einer getrennten Server-Instanz, sicherer Conf-Import und LAN-/Tunnel-Zugriff
-sind jetzt unter Einstellungen verfügbar. Einrichtung, Sicherheitsgrenzen und Tests:
-[WireGuard-Modul](network/README.md). Ohne Installation bleibt die Mac-Vorschau
-rein lokal; erst der Installationsknopf erstellt den neuen Container auf Athena.
+Das separate [WireGuard-Modul](network/README.md) enthält Conf-Import und
+LAN-/Tunnel-Zugriff. In der aktuellen Debian-Entwicklungsinstanz ist es nicht
+angebunden; der Zugriff erfolgt über SSH-Tunnel. Der bestehende Gateway bleibt unverändert.
 
-## Start und Stopp auf dem Mac
+## Zielsystem und Entwicklung
 
-```sh
-cd /Users/mike_i386/Documents/ChatGPT/Athena/AI-Profile-Router/experiments/athena-control-ui
-python3 server.py --port 8108
-```
+Athena Deck läuft vollständig auf einem Debian-Server mit RTX 5080 und RTX 3060.
+Oberfläche, API, Demo-Prozess und Hardware-Erfassung laufen dort. Der Arbeitsplatz
+benötigt nur Browser und SSH; er ist kein Anwendungsserver. Auch Builds und
+Integrationstests werden auf Athena ausgeführt. Modelllaufzeiten sind noch nicht angebunden.
 
-GUI: http://127.0.0.1:8108 · Beenden mit Ctrl+C im Startterminal.
-SIGTERM beendet ebenfalls den Server und seinen Demo-Kindprozess sauber.
-Ein belegter UI-Port führt zum Abbruch, nicht zur Übernahme eines Dienstes.
-Der Demo-Port wird vom Betriebssystem vergeben und als bereits gebundener
-Socket an den Kindprozess weitergereicht (keine Port-Prüfungs-Race).
-Kein SSH-Tunnel erforderlich. Die Anwendung bindet ausschließlich Loopback.
-Im separaten Git-Repository liegen diese Dateien im Wurzelverzeichnis;
-dort entsprechend `cd` in den Checkout und denselben Startbefehl verwenden.
-
-Hardware-Abfragen verwenden den vorhandenen SSH-Zugang:
-`ssh -i ~/.ssh/athena_key -o BatchMode=yes root@192.168.1.212`.
-Der bekannte Hostschlüssel muss bereits hinterlegt sein. Schlüssel werden
-weder kopiert noch ausgegeben. Athena erhält nur den Collector über stdin;
-auf dem Host werden keine Dateien angelegt und keine Dienste gesteuert.
+Die isolierte Entwicklungsinstallation ist in [DEVELOPMENT.md](DEVELOPMENT.md)
+beschrieben. Hardware wird direkt über `/proc`, hwmon und nvidia-smi gelesen;
+Deck benötigt dafür keinen SSH-Schlüssel. Der Demo-Prozess lädt kein Modell.
 
 ## Interne API v1
 
@@ -75,8 +62,8 @@ curl -X POST -H 'Authorization: Bearer <API-TOKEN>' http://127.0.0.1:8108/api/v1
 curl -X POST -H 'Authorization: Bearer <API-TOKEN>' http://127.0.0.1:8108/api/v1/demo/stop
 ```
 
-Hardware: `available` bezeichnet Erfolg der SSH-Collector-Abfrage, einzelne
-Messwerte können trotzdem fehlen (`null`). SSH-Ausfall liefert available=false,
+Hardware: `available` bezeichnet Erfolg der Hardware-Abfrage, einzelne
+Messwerte können trotzdem fehlen (`null`). Ein Ausfall der Erfassung liefert available=false,
 leere Daten und eine Fehlermeldung, keine alten Werte als vermeintliches Livebild.
 CPU-Auslastung: 250-ms-Differenz aus `/proc/stat` ohne doppelte Guest-Zählung.
 RAM: MemTotal minus MemAvailable aus `/proc/meminfo`, Einheit Bytes.
@@ -90,7 +77,7 @@ Keine Historie und kein Hintergrund-Collector bei geschlossener Hardware-Seite.
 ## Struktur und Grenzen
 
 - `server.py`: API, separater HardwareProvider, eigenständiger DemoService.
-- `demo.py`: Health-only HTTP-Kindprozess auf dem Mac, ohne Modellabhängigkeiten.
+- `demo.py`: Health-only HTTP-Kindprozess auf dem Debian-Server, ohne Modellabhängigkeiten.
 - `collect_hardware.py`: fest begrenzte lesende Linux-Hardware-Abfragen.
 - `index.html`, `app.js`, `style.css`: neue responsive Oberfläche.
 - `test_server.py`: Prozess-Lebenszyklus, Kontrollgrenzen, Hardware-Ausfall.
@@ -102,8 +89,7 @@ mit derselben Status-/Start-/Stopp-Trennung erhalten. Noch kein Worker-Registry,
 Scheduler oder produktionsreifer Worker-Supervisor. Die optionale Server-Instanz
 hat eine eigene Passwortanmeldung; ihre Netzwerkgrenzen stehen in der Modul-Dokumentation.
 SIGKILL/Absturz-Cleanup ist nicht implementiert; regulär Ctrl+C/SIGTERM verwenden.
-SSH verwendet den vorgegebenen Root-Zugang; ein eingeschränktes Telemetrie-Konto
-wäre ein späterer eigener Auftrag. Der Hardware-Collector ändert keine Host-Konfiguration. Die optionale
+Der Hardware-Collector ändert keine Host-Konfiguration. Die optionale
 Netzwerkmodul-Installation erzeugt einen eigenen Docker-Container samt Portbindungen.
 
 ## Verifikation am 28.09.2026