# Entwicklung auf Athena (Debian)

Zielsystem: Debian 13, RTX 5080 und RTX 3060. Der Arbeitsplatz dient nur als
Editor/SSH-Client und Browser. Die Anwendung und ihre Tests laufen auf Athena.

- Quellcode: `/opt/athena-deck-dev/source`
- Eigener Container: `athena-deck-dev`
- Zustand und Installationsmanifest: `/opt/athena-deck-dev/runtime`
- Serverbindung: ausschließlich `127.0.0.1:8108`
- GPU-Zugriff: NVIDIA `utility` für Telemetrie; keine Modellstarts.

Vom Arbeitsplatz:

```sh
ssh -i /Users/mike_i386/.ssh/athena_key -o BatchMode=yes -N -o ExitOnForwardFailure=yes -L 8108:127.0.0.1:8108 root@192.168.1.212
```

Browser: http://127.0.0.1:8108 . Die Adresse führt durch den Tunnel zum Server.
Beim ersten Öffnen neue Zugangsdaten einrichten. Vorhandene Zugangsdaten werden
nicht vom Arbeitsplatz übertragen. Browser-Profilentwürfe bleiben bei gleicher
Adresse erhalten. Nur diese isolierte Entwicklungsinstanz erlaubt die einmalige
Browser-Einrichtung über den SSH-Tunnel (`development_setup` im Manifest).
Der normale Debian-Installer provisioniert weiterhin vor dem Start.

Auf Athena:

```sh
cd /opt/athena-deck-dev/source
./install.sh --status --directory /opt/athena-deck-dev/runtime
./install.sh --stop --directory /opt/athena-deck-dev/runtime
./install.sh --start --directory /opt/athena-deck-dev/runtime
# Nach gezielter Aktualisierung der Quelldateien:
./install.sh --update --directory /opt/athena-deck-dev/runtime
python3 -m unittest discover -s . -v
```

Diese Befehle verwalten ausschließlich den eigenen, per Label geprüften
Deck-Container. Produktiver Router, Modelle, WireGuard und Hostkonfiguration
werden nicht verändert. Kein Docker-Socket im Webcontainer.

Profile und llama.cpp-Build/Update sind weiterhin GUI-Entwürfe. Die Netzwerk-Erweiterung ist in dieser Installation deaktiviert.
Das Verschieben der Entwicklung aktiviert keine dieser Funktionen automatisch.

## Verbindliche Zielarchitektur

Das Produkt wird ein nativer Debian-systemd-Dienst unter eingeschränktem Benutzer.
Docker ist ausschließlich die vorläufige Testverpackung. Katalog, Downloads und
spätere Worker-Adapter dürfen Docker nicht voraussetzen. Kein Docker-Socket und
keine Hostprozesssteuerung über Docker. Der vorhandene WireGuard-Container bleibt
unverändert; Zugriff derzeit über SSH-Tunnel.

## Live-Funktionen ab 0.5

Hugging-Face-Suche nach Bereich, feste Repository-Revision, Dateiauswahl und
serieller Download öffentlicher GGUF-/Safetensors-/JSON-Dateien. Eigener Ordner
`runtime/state/models`; Fortschritt, Abbruch, 10 GiB Speicherreserve, Größenprüfung
und bei vorhandenem LFS-Prüfwert SHA-256-Abgleich. Bei Neustart wird ein laufender
Download nicht fortgesetzt; unvollständige Dateien sind keine Bibliothekseinträge.
Keine automatische Ausführung heruntergeladener Dateien. Gated/private Modelle,
Paketauflösung, VRAM-/Kontextprognose und Worker-Starts fehlen noch.

Interne API (nur angemeldeter Administrator):
- GET `/api/v1/catalog/search?q=...&kind=chat|image|audio|video`
- GET `/api/v1/catalog/files?repo=owner/name`
- GET `/api/v1/catalog`: Bibliothek, Downloadstatus, freier Speicher
- POST `/api/v1/catalog/download`: repo, filename, revision, kind
- POST `/api/v1/catalog/cancel`: leeres JSON-Objekt

Anbieter-Dokumentation: https://huggingface.co/docs/hub/api . Audio-Suche filtert
zunächst Sprachausgabe; weitere Audioaufgaben folgen. Einzelne Dateien stellen
noch keine vollständige Installation eines mehrteiligen Modells dar.

Update-Sicherungen enthalten den Konfigurationszustand, nicht die heruntergeladenen
Modelldateien. Diese bleiben im persistenten Zustandsverzeichnis erhalten.