# Portal-QA cp.go-ki.eu — 2026-07-23 (Worker C)

Echte Browser-Automation (Claude-Browser-MCP) gegen https://cp.go-ki.eu, angemeldet über
VM302-Autologin. Jeder Bereich wurde per echtem Klick/Navigation getestet, keine Behauptungen
ohne Beleg (Netzwerk-Requests, gerenderter Text, Vorher/Nachher-Vergleich).

## Bereichs-Matrix

| Bereich | Status | Beleg |
|---|---|---|
| Uebersicht | ✅ funktioniert | Live-Werte (RAM/GPU/Power/Services 11/11) gerendert |
| Hardware | ✅ funktioniert | IPMI-Sensoren, Luefter, Spannungen, SMART, Chassis live |
| Netzwerk | ✅ funktioniert | Live-Throughput + Tabelle Zeitraeume (Hinweis: 2/7/14-Tage-Werte identisch mit "Heute" — Datenaggregation fragwuerdig, kein Blocker) |
| VMs & Container | ✅ funktioniert | GPU-1 (4/4) + PM-1 (5/5) VMs + Docker-Container live |
| Storage | ⚠️ teilweise | ZFS/PBS/Storageboxen ok. **Wasabi S3: `InvalidAccessKeyId`** — Access-Key in rclone.conf/Backend ungueltig. **[BÄR]**, kein Portal-Code-Fix (Credential-Rotation noetig) |
| Sicherheit | ✅ funktioniert | NTP, Logins, IPMI-Log, Cron-Jobs live |
| Alarme | ✅ funktioniert | 2 aktive Alarme + Historie live; Aktions-Buttons (Fortsetzen) bewusst NICHT geklickt (Seiteneffekt auf echtes Monitoring) |
| Domains | ✅ funktioniert | Domain-Registry-Tabelle korrekt |
| NPM Manager | ✅ funktioniert | 7 Proxy-Hosts, 6 SSL-Zerts, Live-Daten aus NPM-API |
| GPUPCs | ✅ funktioniert | GPU-Shadow + Monster-PC Status async geladen, "Check"-Button real getestet (Re-Check ausgeloest). Monster-API :9001 nicht erreichbar → **[BÄR]**-Infra-Befund |
| Links | ✅ funktioniert | 30 Eintraege, Copy-Button real geklickt, kein JS-Fehler |
| **Video → SD Forge** | 🔴→✅ **BUG GEFIXT** | Tab lud Modell-Liste nie automatisch (nur "Lade Modelle..." fuer immer). Ursache: `vSwitch()` rief `sdLoadModels()` nicht auf, nur ein fragiler `DOMContentLoaded`-Listener. Fix: Auto-Load direkt in `vSwitch()` ergaenzt. Backend selbst liefert 503 (SD-Forge-WebUI-API :8201 nicht erreichbar) — das ist ein separater Infra-Befund **[BÄR]** |
| **Video → GPU Manager** | 🔴→✅ **BUG GEFIXT** | Gleicher Root-Cause wie SD Forge, `gpuRefresh()` fehlte in `vSwitch()`. Nach Fix laedt VRAM/Modelle/Jobs sofort beim Tab-Oeffnen |
| Video → Veo3 Pipeline | ✅ funktioniert | Eigenes Panel (kein Duplikat wie zunaechst vermutet) |
| Video → Barby Studio | ✅ funktioniert | Entkleiden/Text2Img-Formular vollstaendig |
| Video → Ton & Musik | ✅ funktioniert | Song-Generator, TTS, MusicGen-Formulare |
| Video → Queue | ✅ funktioniert | Leere Queue korrekt angezeigt |
| Video → GPU Stack | ✅ funktioniert | Live VRAM/ComfyUI/Ollama-Status, Aktionslog |
| Video → KI Chat | ✅ funktioniert | Echte Nachricht gesendet, LLM hat generiert (qwen2.5:72b, Cold-Start dauert ~1-2 Min wg. 44GB-Modell-Ladezeit) |
| Video → Video Erstellen | ✅ funktioniert | One-Click-Pipeline-Formular eigenstaendig, unterscheidet sich korrekt von Veo3 |
| Video → Video Tools | ✅ funktioniert | Wav2Lip/Compositing/F5-TTS Formulare |
| Video → Links | ✅ funktioniert | Service-Link-Liste mit Live-Status-Punkten |
| Video → Hermes | ✅ funktioniert | Status "ollama:online", Chat-Historie geteilt mit KI-Chat |
| Benachrichtigungen | ✅ funktioniert | Formular laedt; Test-Mail/SMS bewusst NICHT ausgeloest (echter Seiteneffekt) |
| Notizen | ✅ funktioniert | **Echte Notiz erstellt + wieder geloescht** (API-Test, Original-Notizen unangetastet) |
| Dateien | ✅ funktioniert | Ordnerbaum + Datei-Listing (Groesse/Datum/Download/Teilen/Loeschen) live in `configs/` geprueft |
| Tunnel | ⚠️ Daten-Inkonsistenz | Health-Zaehler "5/8 online" vs. Tabelle zeigt 6 Online-Zeilen. Ursache: externe "Tunnel-API" liefert Health-Snapshot und Server-Liste in unterschiedlichem Timing — **nicht in app.py berechnet**, daher kein Portal-Fix moeglich. **[BÄR]**-Befund (externer Dienst) |
| Admin → System-Info | ✅ funktioniert | Hostname/Uptime/Load/Disk/RAM/Python/Dateigroessen live |
| **Admin → Backups anzeigen** | 🔴→✅ **BUG GEFIXT** | Blieb ewig bei "Lade Backup-Liste...". Ursache: Backend liefert `{backups:[...],count:N}`, Frontend erwartete rohes Array (`d.length`/`d.map` = TypeError, keine `.catch()`). Fix: Frontend liest `d.backups`, zeigt Groesse an, hat jetzt Fehlerbehandlung. Verifiziert: 88 Backups korrekt gelistet |
| Admin → Eigene Links | ✅ funktioniert | Real per API getestet: Link hinzugefuegt + wieder geloescht (Button-Klick per Koordinate traf in dieser Headless-Testumgebung nicht zuverlaessig — direkter Funktionsaufruf bestaetigt: kein Produktbug) |
| Admin → Tab-Reihenfolge & Gruppen | ✅ sichtbar/geladen | Drag&Drop-Editor vorhanden, nicht destruktiv getestet (Speichern haette echte Tab-Reihenfolge veraendert) |

## Gefixte Bugs (Portal-Code, VM201 100.114.24.89, `/opt/gpu1-status/app.py`)

1. **SD Forge + GPU Manager: kein Auto-Load beim Tab-Wechsel**
   - Root Cause: `vSwitch()` rief fuer `ki-sd-forge`/`ki-gpu-manager` keine Ladefunktion auf; verlassen auf einen `DOMContentLoaded`-Listener, der nicht zuverlaessig griff.
   - Fix: `sdLoadModels()` bzw. `gpuRefresh()` direkt in `vSwitch()` ergaenzt (gleiches Muster wie `studio`/`bild`/`ton`/`queue`/`stack`).
   - Backup: `app.py.bak-sdforge-gpumanager-autoload-20260723-150731`

2. **Admin → Backups anzeigen: haengt permanent bei "Lade Backup-Liste..."**
   - Root Cause: Backend-Antwort `{backups:[...],count:N}` vs. Frontend erwartete Array direkt, TypeError ohne `.catch()`.
   - Fix: Frontend liest `d.backups||d||[]`, zeigt Dateigroesse, hat Fehlerbehandlung.
   - Backup: `app.py.bak-adminbackups-fix-20260723-152842`

Beide Fixes nach Skill-Ablauf: Backup → Aendern (eindeutiges Python-Suchmuster) → `py_compile` (OK) →
Testinstanz Port 9092/9093 (HTTP 200, Fix im HTML verifiziert) → `systemctl restart gpu1-portal.service`
→ Nachkontrolle `https://cp.go-ki.eu/` (200) → im echten Browser reproduziert und **live verifiziert**.

## [BÄR] / Infra-Befunde (nicht im Portal-Code fixbar)

- **Wasabi S3 `InvalidAccessKeyId`** (Storage-Tab) — Access-Key `CEADGY9UH44FF2QTK5ZE` in der hinterlegten rclone-Konfiguration ist ungueltig/abgelaufen. Braucht neue Wasabi-Credentials.
- **Monster-API :9001 nicht erreichbar** (GPUPCs-Tab) — Monster-PC ist offline, daher erwartungsgemaess kein API-Zugriff.
- **SD-Forge-WebUI-API :8201 → 503** (Video → SD Forge) — Backend-Dienst laeuft nicht/ist nicht erreichbar. Portal zeigt das jetzt korrekt an statt endlos zu haengen.
- **Tunnel-Registry Health-Zaehler-Inkonsistenz** — externe Tunnel-API liefert Snapshot-Mismatch zwischen Health-Zahl und Server-Liste (5/8 vs. tatsaechlich 6 online in der Tabelle).

## Kleinere Beobachtungen (kein Blocker)
- Netzwerk-Tab: "2 Tage / 7 Tage / 14 Tage"-Spalten zeigen exakt dieselben Werte wie "Heute" — Aggregation wirkt unvollstaendig implementiert, aber nicht funktionsbrechend.
- NPM Manager: ein abgelaufenes Duplikat-Zertifikat `ollama.go-ki.eu` (Provider "other", -11 Tage) neben dem gueltigen — Aufraeum-Kandidat, kein Fehler.

## Guardrails eingehalten
- Kein VM302-Reboot
- Vor jedem Code-Eingriff Backup (`app.py.bak-*`) angelegt
- Testinstanz auf separatem Port vor jedem Neustart des echten Dienstes
- Laufender Dienst nur nach erfolgreichem Testinstanz-Check neu gestartet, danach Domain-Health per `curl` bestaetigt
- Keine Test-Mails/SMS/PagerDuty-Alerts ausgeloest, keine echten VM/PC-Power-Aktionen (Start/Stop/Hibernate) ausgefuehrt
- Alle Test-Artefakte (Notiz, Eigener Link) wieder entfernt