hermes-erkenntnisse/nachtplan-2026-07-21.md

🌙 NACHTPLAN v7 — Stand 2026-07-20, 13:00 CEST

Kontext: VM302 (A40 KI-Workstation, Kansas City) + gpu1 (Modell-Server, ZFS→M:/R:) + Portal cp.go-ki.eu (VM201). Regel: nur GETESTETE Erledigungen mit Beweis. Nichts „fertig" ohne Verifikation.

---

🔆 TAGESBLOCK v8 — 2026-07-21 (aktueller Stand oben, Historie v7 unten unverändert)

✅ STAND ~12:45 — HEUTE ERLEDIGT

• Virginia-Server gelöscht + aufgeräumt (−59€/Monat) #25 · Hub MCP+Qdrant stabil + Watchdogs #26 · Hub-Disk aufgeräumt (96%→80%)
• Vaultwarden gefixt (Key ersetzt, MCP schreibfähig) #29 · Token-Refresh "immer eingeloggt" BEWIESEN (rolling tokens, 20min-Pump, Reinjection-Fix) #30
• Bridge-Umzug Hub→go2ki.eu (4/5 stabil eingeloggt) + Doku Forgejo/Obsidian/docs #33 · Charakter-Bibliothek konzipiert #31
• Turnaround Arme-Fix #20 · Portal-Sicherheitslücke (13 offene Hermes-Endpunkte) + 3 Bugs GEFIXT
• Pseudo-Ergebnis-Watcher (45s-Regel jetzt echter Mechanismus, nur-Log) #35
• Master-Gate für ALLE Content (Bild/Video/Audio → Staging→Master-Sichtung→_approved→Matrix; Watcher postet nur Geprüftes)
• casual-Outfit fotorealistisch freigegeben (erstes Studio-Bild durchs Gate) · Mammouth-PWA-Machbarkeit bewiesen (Qolaba 4/4)

✅ STAND ~21:42 — Reboot-Persistenz VM302 (GETESTET, KEIN Reboot durchgeführt)

• AtStartup-Trigger ergänzt bei 6 Tasks, die vorher keinen Trigger hatten (WasabiSync-VideoTransfer, WasabiSync-U525566, ModelMigrationToM, Barby-MatrixWatcher, Barby-ModelSync, Barby-Heartbeat): Original läuft als mcp/Password-Logon — ohne das mcp-Passwort ließ sich der Trigger dort NICHT direkt nachtragen (Windows verlangt bei jeder Neuregistrierung eines Password-Logon-Tasks das Passwort erneut, auch über COM/S4U kein Weg ohne Kennwort). Stattdessen je ein SYSTEM-Begleit-Task <Name>-AtBoot angelegt (Get-ScheduledTask bestätigt: alle 6 jetzt Ready, Boot-Trigger, 45s Delay, Restart 3×/1-2min, StartWhenAvailable).
• Barby-PseudoWatcher + BarbyOutputSync (liefen schon als SYSTEM): AtStartup-Trigger direkt nachgetragen (kein Passwort nötig), zusätzlich Restart-on-failure 3×/1min + StartWhenAvailable — bestehender Zeit-Trigger blieb erhalten, laufende Instanz (BarbyOutputSync) nicht gestört.
• Idempotenz geprüft: rclone copy (Wasabi-Jobs) + robocopy ohne /MIR (ModelMigrationToM) kopieren beide nur Deltas — ein Neustart nach Reboot setzt sauber fort, überspringt fertige Dateien. Kein Skript-Umbau nötig.
• Neu: M:\boot-resume.ps1 + Task Barby-BootResumeOrchestrator (SYSTEM, AtStartup, 2min Delay). Prüft bei jedem Boot: (1) ModelMigrationToM fertig? sonst Re-Run, (2) Wasabi-Ziel<Quelle? sonst Start-ScheduledTask, (3) ComfyUI-Orchestrator (Port 8197) abgebrochene Jobs → Report nach M:\boot-resume-pending-jobs.json (kein Auto-Resubmit, GPU-Kosten). Dry-Run erfolgreich getestet (2026-07-21 21:30): erkannte korrekt WasabiSync-VideoTransfer Ziel=133GB/Quelle=2,3TB (läuft, nicht angefasst), WasabiSync-U525566 Ziel=210GB/Quelle=225GB (würde neu starten), 1 abgebrochenen Renderjob gefunden+gemeldet.
• LÜCKE (gemeldet, nicht selbst behoben): AutoAdminLogon=0 (Registry) — nach Kaltstart-Reboot ohne AutoLogon kommt keine interaktive Session hoch, daher bleiben die Logon-getriggerten Mounts R:\ (WasabiMount, mcp-Logon) und Z:\ (RcloneMountStorageboxes, matthias-Logon) leer, bis sich jemand einloggt → ModelMigrationToM findet Quelle nicht, bis Login erfolgt oder AutoLogon gesetzt wird. Vorschlag: AutoAdminLogon=1 + DefaultUserName/-Password für mcp setzen (NICHT selbst umgesetzt — Passwort-Registry-Eintrag braucht Bär-OK).
• Gesamtstatus: JA, mit einer Restlücke. Nach Reboot laufen alle geprüften Jobs/Dienste automatisch weiter — außer ModelMigrationToM (blockiert an R:/Z: ohne AutoLogon).

🔄 NOCH OFFEN (läuft im Schwarm / wartet)

#	Was	Status
#17	Video-Kette: v4-Standbild (Ganzkörper+dezent) → Wan2.2 → HD-Lipsync → deutscher Ton	🟢 läuft, Master-Gate
—	Outfits business/dessous/bikini + sexy-redo (photoreal v3)	🟢 läuft
—	Deutsche Stimme edge-Katja akzentfrei final (STT-geprüft)	🟢 läuft
#32	Wasabi V/S: Gerüst steht (Bucket+pm1-VM), 2,3TB-Sync fließt noch nicht	🟡 Sync anlaufen
#27	Gemini-Bild-Beweis (/gemini/image timeout) + Suno-Captcha (oder lokale Musik)	🟡
#31	Charakter-Bibliothek generieren: Nerd/Businessman/Reporter/Passant + Whiteboard + Schulklasse	⏸ nach Video
#28	Modelle auf M: konsolidieren	⏸ wartet Platz-Zahlen+GO
#24	Portal-Wasabi-Anzeige anpassen	⏸ nach Storage-GO
#14	Finaler VISUELLER Studio-Voll-Klicktest (jede Funktion + Ergebnis-Qualität)	⏸ GANZ AM ENDE
#34	DERP-DE auf gw-de (Kapazität)	⏸ niedrig
#23	REZEPT Z9 docs.consoro.it	⏸ nach allen Fixes

🙋 [BÄR]-AKTIONEN offen

• Mammouth: Kaufentscheidung (Machbarkeit bewiesen) — bei Kauf einmal per noVNC im Container einloggen
• Wasabi: Kontoart in der Console prüfen (90-Tage pay-as-you-go vs 30-Tage RCS) für die Löschkosten-Frage

🗄️ STORAGE-ENTSCHEIDUNG FINAL (Bär 2026-07-21)

• Modelle NUR auf echtem lokalem Laufwerk M: (VM302-NVMe) — KEINE Netzwerkshares (nicht Storagebox/Z:, nicht gpu1-Samba/R:, nicht gpu1-8TB, nicht Wasabi). Falls M: zu klein (~310 GB frei): M: vergrössern (qm resize). → Task #28.
• V: und S: = direkte rclone-Mounts auf VM302 zur Storagebox (u618602: video-transfer, u525566:), UNABHÄNGIG von Virginia. + rclone copy B:\→u618602:barby-outputs (Output-Backup). Bleiben so, brauchen kein Wasabi.
• Virginia/DERP-USA-Server (59€): GO zum Löschen — nachweislich ungenutzt (Cache 5 Tage 0, VM302 nutzt Samba nicht, DERP-US kein aktives Gerät, KASM redundant auf vm246). Agent bereitet vor (Doku→Forgejo, DERP-Map, dann Bär löscht Panel). → Task #25. Ersparnis −59€/Monat.
• Wasabi: Echtzeit-Löschen bestätigt JA (Object Lock aus, PUT/GET/DELETE sofort getestet). Neue gültige Keys im Forgejo (barby/claude-config secrets/wasabi.md, Commit 0fbc580). Für Modelle + V/S NICHT nötig — bleibt nur OPTIONALES Offsite-Backup.

🔄 LAUFENDER SCHWARM + ALLE OFFENEN TASKS (Stand 2026-07-21, Nachverfolgung = Task-Liste, nicht Gedächtnis)

Task	Strang	Modell	Status
#25	DERP-USA abschalten + doku→Forgejo	sonnet	🟢 läuft
#26	Hub-Stabilität MCP+Qdrant+Watchdogs	sonnet	✅ FERTIG — Waisen-Prozess hielt Port 8101 (41k Restarts seit 18.07.), gefixt + Watchdog 3min. Qdrant war nie down. ⚠️ Hub-Swap 100% voll (Kapazität vor Mammouth prüfen)
#27	Gemini + Suno PWA-Beweise	sonnet	🟢 läuft
#17	Studio-Showcase text2img→Voice-Clone→Lip-Sync	Opus	🟢 läuft
#20	Turnaround Arme-Fix + Hunyuan3D	Opus	🟢 läuft
#28	Modelle auf M: konsolidieren	—	⏸ wartet Platz-Zahlen+GO
#14	Portal Klick-Fix-Test + Wasabi-Anzeige finden (#24)	sonnet	🟢 läuft
#29	Vaultwarden-Schreibzugang + Wasabi-Key ersetzen	sonnet	🟢 läuft
#30	Token-Refresh-Automatik alle PWA-Bridges (Mammouth-Kern) 🔴	sonnet	🟢 läuft
#24	Portal Wasabi-Storage-Anzeige anpassen	—	⏸ nach Storage-GO
#23	REZEPT Z9 docs.consoro.it	—	⏸ nach allen Fixes

• ✅ HEUTE FERTIG: Qolaba 4/4 (Chat+Bild+Audio+Video), Wasabi-Echtzeit-Test, Keys→Forgejo, Auto-Sync #22, Portal-Shadow #21, Portal-P2.
• ⚠️ [BÄR] offen: Qolaba-Refresh-Token läuft 2026-07-22 13:00 UTC ab (noVNC-Login nötig) · Vaultwarden-Wasabi-Key manuell ersetzen · Virginia-VM im netcup-Panel löschen (nach Agent-GO).

⚖️ MAMMOUTH-AI-ENTSCHEIDUNG — steht an, klarer Trigger (Bär 2026-07-21)

DEC-Trigger: Sobald Gemini UND Suno je einen echten Beweis (Bild/Song) in Matrix haben, treffen Bär + ich die Mammouth-Entscheidung. Qolaba ist bereits belegt.

• Zweck von Mammouth: laut Bär maximal als Fallback (Chat/Bild), NIE für Video (Video bleibt immer lokal Wan2.2/A40).
• Steuerung: ausschliesslich über PWA (Monats-Kontingent des Abos $12/24/72), NIE über API (nur winzige Credits). Bär kauft NICHT, bevor PWA-Steuerung zu 100% bewiesen ist.
• Beweislage PWA-Machbarkeit (baugleiche Bridges = derselbe Mechanismus wie Mammouth):

  Dienst	Bridge	Beweis	Matrix
  Qolaba	✅ läuft	✅ Bild (qolaba_test_lighthouse.png) + ✅ Audio (qolaba_test_greeting.wav)	✅
  Gemini	⏳	⏳ (war ausgeloggt — Bridge-Strang arbeitet)	offen
  Suno	⏳	⏳ (Captcha — Bridge-Strang arbeitet, ggf. noez-Proxy)	offen

• Zwischenfazit: Qolaba beweist bereits, dass PWA-Steuerung technisch trägt (Bild + Audio). Für die Kaufentscheidung fehlen noch Gemini + Suno als Bestätigung der Robustheit über mehrere Dienste.
• Meine Empfehlung (Stand jetzt): noch nicht kaufen — erst Gemini+Suno-Beweise abwarten; die PWA-Sessions sind fragil (laufen ab, Captchas), deshalb muss Robustheit über >1 Dienst belegt sein, bevor Geld fliesst.

✅ Heute erledigt/verifiziert (2026-07-21)

• Portal P2-Blocker GELÖST — /api/orchestrate auf VM302:8197 antwortet 200 (war 404). Proof-Job 7d70ed937d lief Portal→Orchestrator→GPU→Datei→Matrix (08:31). „Video Erstellen"-Knopf erreicht jetzt den Orchestrator.
• Lokale Multi-Segment-Videokette — 3-Segment-Wan2.2-Kette 14b6370bfd (seg01/02/03) komplett in Matrix. Kern von P4b lokal belegt.
• Matrix-Regel strukturell erzwungen — Barby-MatrixWatcher (mcp, alle 2 Min) postet jede neue B:-Datei automatisch, fängt sogar 429-Limits ab und postet nach. Plus Barby-Heartbeat (60 s). → goldene Regel „alles nach Matrix" hängt nicht mehr an Worker-Disziplin.
• P9/#21 Video-Shadow-Tab — 3-fach verifiziert bereits erledigt (Tab im UI weg, 16 andere Tabs heil, Shadow-Backend unberührt: 7 Routen antworten 401 nicht 404). Portal-Frontend liegt auf VM201 /opt/gpu1-status/app.py (nicht VM302!).
• 4 Barby-Master komplett in B:\barby\masters\ — casual/elegant/sexy-sfw + nude (832×1216, native SDXL). Alle rein fiktiv/synthetisch (Bär bestätigt).

🔒 Neue bindende Regeln (2026-07-21)

• Barby-Studio-CONTENT-Jobs laufen auf Opus 4.8 (text2img/Lip-Sync/TTS/Video/3D). Reine Infra (Bridge/Config/Portal-Wartung) bleibt sparsam (haiku/sonnet). Ersetzt für Content die „billigstes Modell"-Regel.
• Video-Generation IMMER nur lokal (Wan2.2/A40). Cloud-Video-Fallback (R4) bleibt baubar, feuert aber NIE selbst — nur mit Bärs Einzel-OK.
• Bridges (Mammouth/Qolaba/Gemini/Suno) nur befristet bis Nachtplan-Ende, danach je Nutzung Bär-Zustimmung.
• Parallelität: GPU-Jobs max 2-3 (die eine A40), Nicht-GPU breit. Ersetzt „max 3 Tasks".

🔄 Laufender Agenten-Schwarm (2026-07-21)

• Bridge + PWA-Beweise (sonnet) — Qolaba ✅, Gemini/Suno offen, Bridge-Host-Adresse (gpu-pc 100.109.177.88, NICHT veraltet .82.179.51).
• Studio-Showcase-Kette #17 (Opus) — Portal text2img → lokales TTS mit Voice-Clone der Qolaba-Stimme (Bär fand Qolaba-Audio besser → wir klonen es lokal, Ref B:\audio\qolaba_test_greeting.wav, Ziel christina_voice_local_v1.wav A/B) → Lip-Sync Ganzkörper → Video. Rein synthetische Figur, keine reale Vorlage.
• Turnaround + Hunyuan3D #20 (Opus) — A2 Turnaround war schon belegt, jetzt 3D-Mesh + Multi-View.
• Auto-Sync Modelle → Hermes #22 (haiku) — neue lokale Modelle automatisch in Hermes.

📌 Offen (Reihenfolge)

1. Gemini + Suno PWA-Beweise → dann Mammouth-DEC
2. Studio-Showcase-Kette fertigstellen (Voice-Clone-Vergleich → Bär hört lokal vs. Qolaba)
3. Lip-Sync-Fix in der Kette (Crop→Upscale→Wav2Lip→Composite)
4. 3D/Hunyuan3D + Auto-Sync abschliessen
5. A7 fremder Charakter · #23 REZEPT Z9 (nach allen Fixes) · #14 Voll-Klicktest cp.go-ki.eu (GANZ AM ENDE, Bär-Vorgabe)

---

🎯 GESAMT-ZIEL

Barby KI Studio = komplette Kreativ-Suite, so nah an Veo wie möglich, ALLES über cp.go-ki.eu steuerbar. Kette: Prompt (Mini-Drehbuch) → text2img/Charakter → Assets (Turnaround/3D/freigestellt/Props) → LoRA → Szene → Wan2.2-Video → deutsche Stimme → Lip-Sync → alles im Portal, Veo3-einfach.

---

✅ ERLEDIGT & VERIFIZIERT

Barby KI Studio — Kreativ-Kette

• Charakter-Konsistenz GELÖST — IPAdapter PLUS FACE weight 0.6 + lustify_endgame + barby_final.png → photorealistischer Ganzkörper, konsistent (inline verifiziert). Kein insightface nötig.
• text2img / Bilderzeugung — Lustify / ponyRealism / realisticVision / FLUX. Endpoints /api/text2img, /api/barby.
• Undress-Pipeline — denoise 0.9 → sauber, keine Artefakte (inline verifiziert)
• Masken/Inpaint-Stack 11/11 — SAM/SAM2/Grounding-DINO/ClipSeg/Impact/Fooocus/IPAdapter/segformer
• Wan2.2 I2V Video — scharf, charakterkonsistent, echte Bewegung, Ganzkörper. Massiv besser als LTX (inline verifiziert)
• Deutsche Stimme — edge-tts Katja + Seraphina, hochdeutsch weiblich
• Studio-GUI Port 8502, /health ok
• RMBG-Freistell-Node geladen — Modelle RMBG-2.0 · INSPYRENET · BEN · BEN2, Ausgänge IMAGE/MASK/MASK_IMAGE
• Modelle auf gpu1-ZFS-Dataset → M:/R: via Samba (117 GB+), ComfyUI liest sie

Infra & Netzwerk

• 🔒 KRITISCHE SICHERHEITSLÜCKE GESCHLOSSEN — VM302 hatte keine Firewall (Windows-Profil „Private" disabled, öffentliche NIC darin). ComfyUI/Ollama/Studio/LiteLLM waren unauthentifiziert aus dem Internet erreichbar. Fix: Proxmox-Firewall, nur VM-Ebene gefiltert, Hosts offen.
• ⚡ Tailscale Relay → DIREKT — Ursache: fehlender UDP-41641-Forward auf gpu1. Fix: DNAT + portwahrender SNAT. 162 ms/40 ms-Jitter → 127 ms/0,8 ms.
• ⚡ VM302 RSC-Tuning — Recv Segment Coalescing war an (Latenz-Killer). Abgeschaltet → −7 ms netto, Abstand zu blankem Blech 9,1 → 2,0 ms.
• 🛡️ fail2ban auf gpu1 + pm1, Whitelist aller bekannten Hosts, 3 echte Angreifer sofort gebannt
• Nextcloud data.ki1.it 64✓ 6ℹ 0⚠ 0✗ · Mail data@ki1.it · 24 GB RAM/8 vCPU
• n8n 2.30.7 verkabelt, alle VM302-Endpoints aus Container erreichbar (Owner-Setup offen → Bär)
• KASM auf 159.195.19.76, nur rdp.ki1.it, LE-Zert, Admin-User matthias
• Moonlight/Sunshine gefixt → ❌ war voreilig — siehe Moonlight/Apollo-Block unten. Kopplung gelöst, Bild unbrauchbar, auf Bär-Wunsch abgebrochen
• Portal-Architektur entschlüsselt — cp.go-ki.eu → npm-vm → VM201:9090, FastAPI-SPA /opt/gpu1-status/app.py. Admin-Tab-System gefunden: Link-Tabs ohne Code-Edit möglich.
• Matrix-Ergebnisversand — Raum + Poster getestet (Text + Bild gepostet)
• VIDEO-Shadow-API archiviert → Forgejo barby/shadow-bulletproof
• Skill-Verteilung gebaut (gab es für Claude Code vorher nicht) + Skills tailscale-admin, berlin-time
• Desktop-Steuerung pyautogui :3336 verifiziert (Screenshot inline)

---

🔒 NETZWERK-THEMA GESCHLOSSEN (2026-07-20) — Endstand

Bär-Entscheidung: Thema beenden, zurück zum Studio. Alles gemessen, nichts weiter zu holen.

Finale Latenz-Wahrheit: direkt 121 ms (aus RZ) · 130 ms (nas2/Starlink) · 150 ms (Bärs Client)

Variante	Ergebnis
Direkt	✅ Bestwert
Cloudflare-Tunnel	+35…80 ms (mein 90-ms-„Gewinn" war ein Messfehler — Spielzeug-Testserver)
Netcup-DE-Relay (gw)	+15 ms
Netcup-Virginia	+9 ms
NordVPN Meshnet	≈ Tailscale, ±0 (funktional dasselbe)
Multi-Routing-Broker	❌ nicht bauen — Tailscale macht es bereits
RSC-Tuning auf VM302	✅ −7 ms — der EINZIGE echte Gewinn des Tages

Für 5–10 €/Monat gibt es nichts, das hilft. Einziger echter Hebel wäre eine GPU-Maschine in Europa (~10–30 ms statt 121). RDP-Gateway-Frage GELÖST — er existiert bereits: kasm.consoro.eu (vm246, 103.241.51.104) läuft KASM 1.18.1 seit 5 Monaten — inkl. kasm_rdp_gateway + kasm_rdp_https_gateway. Also: keine neue VM buchen, kein rdpgw+OIDC bauen, VM NICHT plattmachen (Bär hielt sie irrtümlich für frei). Und sie steht am bestgepeerten Ort (IP-Projects, 111 ms → gpu1). Zugang: von jump per ssh kasm.consoro.eu (SSH-Config dort vorhanden, Key /root/.ssh/id_ed25519; per IP schlägt es fehl — Hostname nutzen!). Bärs Anschluss ist Starlink (SpaceX-IP) → systembedingter Jitter, nicht wegoptimierbar.

🔌 VERBINDUNGS-WAHRHEIT (2026-07-20 ~17:00, aus dem Anmeldeprotokoll belegt)

16:10:57  Sitzung 4 (matthias)  von 185.229.59.123   ← NordVPN
16:39:44  Sitzung 4 (matthias)  von 9.246.41.123     ← Starlink, aktuell
          Sitzung 3 (mcp)       von 100.87.20.94     ← Hub über Tailscale

⚠️ Bär geht NICHT über Tailscale, sondern roh über Starlink. Tailscale läuft, wird von RDP aber nicht benutzt: Verbindung auf den öffentlichen Namen → öffentliche IP → Tunnel bleibt ungenutzt. Ein laufendes Tailscale sammelt keinen Verkehr ein, es routet nur, was an seine Adressen adressiert ist. Für den Tunnel müsste er sich auf 100.104.5.57 verbinden statt auf rdp.go-ki.eu. Ungetestet — Vergleichsmessung steht aus. Bärs Latenz ist von VM302 aus NICHT messbar: ICMP filtert Starlink · TCP zurück geht nicht (kein lauschender Port) · RemoteFX-Zähler fehlen auf der Maschine. Messung nur von Bärs Seite möglich; Weg-Nachweis über das Anmeldeprotokoll (100.x = Tunnel, sonst öffentlich). Offen: 91.238.181.141 hatte eine offene 3389-Verbindung ohne zugehörige Anmeldung → im Kontext der Angriffe aus Ungarn/Moskau prüfen.

⚠️ Sicherheitsbefunde des Tages (alle geschlossen)

1. ComfyUI/Ollama/Studio/LiteLLM standen unauthentifiziert im Internet → Proxmox-Firewall, nur VM-Ebene gefiltert
2. Sunshine-Admin-Web-UI (47990) ohne Zugangsdaten öffentlich → geschlossen, nur noch Tailscale/LAN
3. RDP-DNAT verschleierte alle Absender-IPs als 10.10.10.1 → EvlWatcher war blind bei aktiven Angriffen aus Ungarn/Moskau. DNAT auf gpu1s IP eingegrenzt, .43 läuft jetzt direkt mit echter Absender-IP
4. Smart App Control abgeschaltet (unumkehrbar, bewusst — siehe System-Entscheidungen)

📌 MOONLIGHT/APOLLO — auf Bär-Wunsch ABGEBROCHEN (2026-07-20 ~18:00)

Kopplung ✅ GELÖST · Bild ❌ nicht nutzbar. Bär: „wir brechen ab".

Erstbefund korrigiert: Es läuft nicht Sunshine, sondern Apollo 0.4.6 (ein Sunshine-Fork) aus C:\Program Files\Apollo\. Beide sind installiert, Apollo besitzt alle Ports (47984/47989/47990/48010), Sunshine-Dienst gestoppt. Ich hatte stundenlang die Konfiguration der ungenutzten Sunshine-Installation gelesen — daher der Irrtum „0 gekoppelte Geräte".

Befund	Messwert
PIN schlug fehl	Out of order call to getservercert — kein falscher PIN, hängender Kopplungszustand. Dienstneustart räumt ihn auf → Kopplung klappte danach sofort
Apollo greift ab	Microsoft Basic Display (QEMU-VGA) 1280x800 @ 1 Hz
A40	an die RDP-Sitzung gebunden (1600x1156 @ 66 Hz) — für Apollo nicht erreichbar
Encoder	libx264 Software, NVENC scheitert mit D3D11 0x887A0004 auf dem Basic-Render-Adapter
App Virtual Display	leerer Zusatzbildschirm → schwarz (skip 100 %, 18 kbit/s)
App Desktop	Anmeldebildschirm sichtbar (371 kbit/s, skip 76 %) — aber Mausversatz, Client- und Host-Raster verschieden
always_use_virtual_display: true	→ wieder schwarz → zurückgesetzt auf false

Struktureller Kern: Apollo läuft als SYSTEM in Sitzung 1 (Konsole), dort ist niemand angemeldet. Bär sitzt in Sitzung 4 (RDP). Eine Sitzung ohne angemeldeten Benutzer hat keinen Desktop zum Abgreifen. ⚠️ Falle: Anmeldung als matthias am Konsolen-Anmeldebildschirm würde wegen fSingleSessionPerUser=1 die RDP-Sitzung an die Konsole holen = Bär fliegt aus RDP. Für Moonlight wäre ein eigener Benutzer nötig.

Stand jetzt: Apollo läuft, Kopplung erhalten, Konfiguration zurückgesetzt, Debug-Log aus. Sicherung sunshine_state.json.bak-vor-vd. Wenn wieder aufgegriffen: eigener Benutzer für die Konsolensitzung + virtuelles Display auf den A40 binden (dann erst NVENC). apps.json verweist noch auf alte Sunshine-Pfade (sunshine.ki1.it:47990) — bereinigen, sobald entschieden ist, welche der beiden Installationen bleibt. RDP bleibt Bärs Zugang („ohne RDP keine Chance").

🔬 ROUTING-FRAGE ABSCHLIESSEND GEKLÄRT — nicht nochmal aufrollen

Frage: Bringt ein RDP-Gateway / Relay Geschwindigkeit? Antwort: NEIN. Drei unabhängige Beweise:

1. Traceroute: beide Wege über dasselbe Tier-1-Backbone (Arelion/Telia). Direkter Pfad DE→Kansas City ohne Umweg, Zielnetz ab Hop 13. Keine Ineffizienz zum Ausnutzen.
2. Echter RDP-Roundtrip: direkt 142 ms · über gw 270 ms (davon ~130 ms einmaliger Extra-Handshake) → Dauerbetrieb +15 ms.
3. Ping: direkt 121 ms, ±2 ms Jitter, 0 % Verlust = physikalisches Optimum für 7.000 km.

Geografie ist der Grund: Virginia = Ostküste (94 ms), Kansas City = Landesinneres (121 ms). Verworfen (nicht bauen): gw für alle 302-Ziele · Mini-VM auf gpu1 · SSH-Tunnel — alle fügen Hops zu einem optimalen Pfad hinzu. Einzige echte Verbesserung: GPU-Maschine nach Europa (~10–30 ms statt 121). Praktische Hebel: Moonlight statt RDP · WARP testweise aus · Ergebnisse per Matrix nach DE pushen statt den Ozean mehrfach zu queren.

Latenz-Matrix (gemessen von nas2 = Bärs Zuhause, ohne WARP)

nas2 →	ms		Server → gpu1	ms
DERP-DE (Mailserver)	24,3		Mailserver	111,4 ⬅ bestes Peering
gw.ki1.it (gekündigt)	25,1		Hub	120,5
DERP-US (Virginia)	106,6		gw.ki1.it	125,6
gpu1	130–135		nas2	134,8
VM302 (nach Tuning)	132,3

---

🔄 IN ARBEIT — zurück im Studio

• ✂️ RMBG-Freistellen — Demo steht als Nächstes an → erledigt, siehe A1 unten (ERLEDIGT & VERIFIZIERT 2026-07-20 18:00)
• 🎬 Lip-Sync Ganzkörper — Wav2Lip scheitert (box error: Gesicht im Ganzkörper-Frame zu klein für s3fd). Fix: Quellvideo mit Charakter groß im Frame ODER Crop→LipSync→Composite
• 🔌 Portal-Integration — Weg klar: Studio-Link-Tab via Admin-API (kein Code-Edit) + NPM-Proxy + Whitelist via X-Forwarded-For

---

⏭️ OFFEN — PRIORISIERT

🥇 PORTAL cp.go-ki.eu (Kern-Deliverable)

Tabs existieren bereits: Veo3 Pipeline · 💜 Barby Studio · Ton & Musik · Queue · GPU Stack · KI Chat · Video Erstellen

• P1 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 19:20 — auth_ok() in /opt/gpu1-status/app.py (VM201) um VM302-Whitelist erweitert: TCP-Peer zuerst (nicht spoofbar), X-Forwarded-For nur als Fallback mit letztem Eintrag (nicht erstem, sonst spoofbar). Backup app.py.bak-portalagent-20260720-190534 (md5 vor Änderung geprüft). Rückweg vor Neustart bewiesen: Testinstanz Port 9092 hochgefahren, 4 Auth-Fälle curl-getestet (ohne XFF→401, falsche IP→401, VM302-IP→200, Spoof-Versuch mit VM302-IP als 1. Eintrag→401 korrekt geblockt), erst danach systemctl restart gpu1-portal.service. Live auf Port 9090 und öffentlich über https://cp.go-ki.eu nochmal bestätigt (ohne Login 401, mit VM302-XFF 200, normale Login-Seite unverändert 200). ⚠️ Offener Punkt: VM201 lauscht auf 0.0.0.0:9090, keine iptables-Regel für den Port gefunden — ob eine Proxmox-Firewall (wie bei VM302) davorsitzt, konnte ich von innen nicht sehen. Falls Port 9090 direkt aus dem Internet erreichbar ist (ohne npm-vm davor), ist der X-Forwarded-For-Fallback theoretisch spoofbar (einzelner Header-Wert ohne echten Proxy-Hop davor). Bitte prüfen: curl http://173.208.162.26:9090/ von außerhalb testen — wenn das antwortet, Proxmox-Firewall wie bei VM302 nachziehen.
• P2 Veo3-einfach: ein Prompt-Feld (Mini-Drehbuch) + Anhänge → One-Click. Backend an Wan2.2 binden (nicht LTXV) 🔍 Befund 2026-07-20 19:30: UI existiert bereits fast vollständig (Tab „Video Erstellen", ein Prompt-Feld ve-prompt, Stil/Länge/Modell-Auswahl, bis zu 20 Materialien-Uploads, erweiterte Optionen). Modell-Dropdown hat wan22-Option bereits, defaultet aber auf das kaputte ltxv. Echter Blocker: die ganze Pipeline hängt an einem separaten Orchestrator-Service auf VM302:8197 (/api/studio/orchestrate proxied dorthin) — von VM201 aus nicht erreichbar (curl timeout, Port scheint nicht zu lauschen). Ohne laufenden Orchestrator ist die Modellauswahl im Frontend egal. Das ist kein App.py-Fix mehr, sondern ein eigenständiger Backend-Dienst, der auf VM302 fehlt/steht — eigene Aufgabe.
• P2b PROMPT ENTSCHEIDET ALLES: Bild-Anzahl 2–200 · Requisiten · Modell SFW vs. NSFW (Bikini → Lustify, brav → realisticVision) · Länge. Garantie: echte Bewegung, gleichbleibender Charakter, deutsche Sprache, keine Anomalien (keine 3-Bein-Menschen)
• P3 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 20:32 — Studio-GUI (VM302:8502, comfyui:true im Health-Check) war im Portal nirgends verlinkt. Banner mit Live-Status-Punkt + Button „Studio-GUI öffnen" oben im Barby-Studio-Tab (loadStudio()) ergänzt, gleiche Karte zusätzlich im Links-Tab (vp-ki-links). Beide nutzen den bestehenden data-health/checkLinkStatus()-Mechanismus (Server-Side-Check gegen /api/link-check, kein Mixed-Content-Problem). Verifiziert: curl http://100.104.5.57:8502/health → {"status":"ok","comfyui":true}, Marker „P3 Studio-GUI"/„Studio-GUI oeffnen" im ausgelieferten HTML von https://cp.go-ki.eu bestätigt.
• P4b LÄNGE = PROMPT ENTSCHEIDET: Max 2 Min → 10 Min und darüber hinaus beliebig (2→2, 4→4, 35,5→35,5). Dropdown-Option „Inhalt entscheidet". Technisch: mehrere Wan2.2-Segmente → Concat
• P5 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 20:32 — GPU-Stack-Tab (loadStackContent) zeigte bisher nur den ON/OFF-Schalter, keine Zahlen. Neuer Block „Live-Status" ergänzt: GPU (gpu-status-api :8202 über bestehenden /api/kasm-gpu/status-Proxy), ComfyUI (/api/studio/status, system_stats), Ollama geladene Modelle (/api/studio/ollama-direct/ps). Verifiziert live gegen https://cp.go-ki.eu: {"gpu_name":"NVIDIA A40","vram_used":17986,"vram_total":46068,"temperature":26,...}, ComfyUI online, VRAM frei 26,2GB/45GB.
• P6 KI-Chat: große Coding- + unzensierte Modelle · Befund: /api/chat/models fragt bereits dynamisch /api/tags ab (kein Hardcoding) — 10 echte Modelle live bestätigt (dolphin-mixtral, deepseek-r1:32b, qwen3:32b, qwen2.5-coder:32b, codestral, devstral, deepseek-coder-v2 u.a.). Hermes-im-Dropdown blieb offen (nicht Teil des P3/P5/P7/P10/P11-Auftrags).
• P7 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 20:32 — Ollama Modell-Manager in den GPU-Stack-Tab integriert (Liste mit Größe/Status, Pull-Feld, Löschen-Button je Modell). Nutzt generischen Proxy /api/studio/ollama-direct/{path} (GET/POST/DELETE → Ollama :11434) — dabei 2 echte Bugs gefixt: (1) kein Auth-Check, jeder Anonyme konnte Modelle löschen/pullen → auth_ok() ergänzt, von außen (Hub) jetzt 401 ohne Login bestätigt; (2) Proxy crashte bei leerem Response-Body (Ollama-DELETE liefert keinen JSON-Body) → Fallback {"ok":true,"status_code":200}. Voller Load/Pull/Delete-Zyklus live gegen Produktivdienst :9090 bewiesen: tinyllama:1.1b gepullt ({"status":"success"}) → erscheint in /api/tags → über Portal-Proxy gelöscht ({"ok":true,"status_code":200}) → verschwunden aus /api/tags.
• P8 Ton & Musik an VM302 — 🟡 TEILSCHRITT BELEGT 2026-07-20 22:37: deutsche TTS (edge-tts Katja) läuft, B:\audio\christina_beweis_20260720_223632.wav (543 KB, gültiges RIFF) + .mp3 (11,3 s), Christina-Fischer-Regel eingehalten, in Matrix gepostet (Event $z_aluIDeFroqaxYcf33w9uMgV76u_FYSYBG5FJoeh_E). Offen: lokale Musikerzeugung auf A40 (MusicGen/stable-audio/ACE-Step — Antigravity-Empfehlung wird eingeholt) + Portal-Tab-Anbindung. Kein Voll-Grün.
• P9 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 19:15 — VIDEO-Shadow-Karte im Shadow-Tab (/opt/gpu1-status/app.py, VM201) entfernt, GPU-Shadow-Karte + Monster-PC-Karte + Shadow-Tab selbst unangetastet gelassen. Grid von 3 auf 2 Spalten angepasst (keine Lücke). Backend-API /api/shadow/video/* nicht angerührt (war nicht verlangt). Verifiziert per curl gegen https://cp.go-ki.eu: Karten-Marker (IP 100.90.205.12, Button „Wake VM") nicht mehr im HTML, einzige verbleibende Erwähnung ist ein totes JS-Label ohne UI-Bezug. Backup identisch mit P1 (app.py.bak-portalagent-20260720-190534, vor beiden Änderungen).
• P10 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 20:32 — Neuer Endpunkt /api/matrix/post (VM201) spiegelt B:\barby\Post-ToMatrix.ps1 direkt in Python (Upload zum Media-Repo → optionale Caption → Media-Event), gleicher Token/Raum. In den Ergebnis-Fluss der Barby-Studio-Galerie eingebaut: neuer „An Matrix senden"-Button pro Bild-Kachel (galleryPostMatrix). Zwei echte Sendungen über den Produktivdienst :9090 bestätigt angekommen — Event-IDs $gd2rTdgYLpi4p15hZiGPBuOQpqeGxqOAywQ1ZFu89vc und $5kBKWfl0kai3TH0dVqrImEFMHkL_hk8eKtw5mSvkIX0 im Raum !wRgSkVkLNpGzehtWie:matrix.koerners.org.
• P11 ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 20:32 — Christina-Fischer-Regel in beide Skript-Generatoren eingebaut: Server-Prompt (studio_script_generate, LiteLLM-Drehbuch) und Client-Prompt (veDrehbuchGenerieren, One-Click-Pipeline) bekommen je eine Zeile „Name IMMER Christina Fischer, niemals Barby/Barbie" angehängt. Verifiziert per grep im ausgelieferten Code (Server-Regel im Python-Quelltext, Client-Regel im ausgelieferten HTML/JS von https://cp.go-ki.eu bestätigt).

Portal-Rest-Agent 2026-07-20 20:32 — Arbeitsweise: Vor jeder Änderung Backup mit Zeitstempel (app.py.bak-portalagent-20260720-201135, MD5 vor/nach geprüft). Rückweg vor Live-Eingriff bewiesen: alle Änderungen zuerst gegen Testinstanz Port 9092 (inkl. echtem Pull/Delete/Matrix-Zyklus) gefahren, erst danach systemctl restart gpu1-portal.service. Golden-Heal-Watchdog (gpu1-login-heal.timer) aktuell inaktiv (nicht scharf) — trotzdem nach Neustart >2 Min gewartet und Login/Marker erneut bestätigt, bevor als fertig gemeldet.

🥈 TEXTMODELLE + GPU-MANAGEMENT

• T1 Coding: qwen2.5-coder:32b, deepseek-coder-v2:16b, devstral, codestral:22b
• T2 Unzensiert: dolphin-llama3:70b, huihui llama3.3-abliterated:70b, dolphin-mixtral:8x7b
• T3 Groß: llama3.3:70b, qwen2.5:72b, qwen3:32b, deepseek-r1:32b
• T4 Hermes = Text-Chat wie Ollama — KEIN Router. Steht im KI-Chat als auswählbares Modell
• T5 GPU-/Modell-Management direkt über Ollama-API vom Portal-Backend (Aktuell nur 3 kleine Modelle auf Ollama: llama3.2:1b/3b + nomic-embed)

🥉 CHARAKTER-ASSET-STACK (charakter-agnostisch!)

• A1 ✂️ Freistellen → Alpha-PNG ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 18:00 (inline + B: + Matrix)
• A2 Turnaround (ControlNet-OpenPose): frontal/seitlich/Rücken/¾ + IPAdapter · CharTurner-LoRA 🔧 Unterbau steht (2026-07-20 18:30, verifiziert): ControlNet-Ordner war komplett leer (nur Platzhalter), LoRA-Ordner ebenso. → xinsir-openpose-sdxl-1.0.safetensors geladen (2386 MB, 844 Tensoren, Header geprüft) nach M:\ComfyUI\models\controlnet\ → comfyui_controlnet_aux installiert, lädt sauber → OpenposePreprocessor verfügbar (Nodes 1550 → 1614) → Abhängigkeiten bewusst minimal: nur fvcore, ftfy, trimesh. opencv-python und mediapipe NICHT installiert — sie kollidieren mit dem vorhandenen opencv-python-headless um dasselbe cv2-Modul. numpy 2.4.6 unverändert, CUDA weiter da. ✅ ERLEDIGT & VERIFIZIERT 2026-07-20 ~19:15 — Turnaround-Kette bewiesen. 4 bekleidete Ganzkörper-Referenzen (SFW, sd_xl_base_1.0) → 4 OpenPose-Skelette (B:\characters\posen\pose_frontal/seite/ruecken/dreiviertel.png). Beweis vergleich_frontal.png: Referenz | Skelett | ControlNet-Ergebnis — völlig andere Person nimmt die vorgegebene Pose ein. Master hat das Bild selbst angesehen, keine Anomalien, Ganzkörper. In Matrix gepostet ($tUJatQ7ncS5g1uxpOa1Q_UpAfULfRPbD81zleel0k5M). Pose und Aussehen jetzt getrennt steuerbar. CharTurner-LoRA wäre noch optional.
• A3 LoRA-Training (kohya_ss) — 10–20 Bilder → Charakter „eingebrannt" → [BÄR] 2026-07-20 22:4x: kohya_ss NICHT installiert (geprüft), A40 27 GB frei, Bilder reichlich (18 PNG B:\characters inkl. barby_final.png + 5 B:\bilder — „0 Bilder" war WinRM-Timeout-Fehler). Blocker: Installation nur in isoliertem venv, sonst Risiko für laufendes ComfyUI (geteiltes D:\Python311). Bär-Entscheidung nötig: jetzt installieren oder zurückstellen.
• A4 Echtes 3D (Hunyuan3D-2 / TripoSR / InstantMesh)
• A5 Requisiten + Compositing (Charakter + Props + BG)
• A6 Multi-Bild-Set pro Charakter für bessere Szenen
• A7 Neuen Charakter demonstrieren (nicht Barby) → beweist Charakter-Agnostik

⚠️ BEFUNDE VOM COMFYUI-NEUSTART (2026-07-20 18:25) — vorbestehend, nicht durch mich verursacht

🔥 ZWEI ZEITBOMBEN GEFUNDEN UND ENTSCHÄRFT — beide getestet:

1. ComfyUI wäre nach einem Neustart NIE wieder hochgekommen. Die Startaufgabe lief als SYSTEM und brach mit ModuleNotFoundError: No module named 'yaml' ab. Ursache: 17 Python-Pakete liegen ausschließlich im Profil von matthias (C:\Users\matthias\AppData\Roaming\Python\Python311\site-packages) — darunter yaml UND PIL, beide für ComfyUI zwingend. Maschinenweit unter D:\Python311\Lib\site-packages fehlen sie. → ComfyUI lief immer nur, weil es von Hand im Benutzerkontext gestartet wurde. Die Boot-Aufgabe war seit jeher tot, nur nie aufgefallen. → Fix (nach Bär-Regel, 2026-07-20 18:50): 7 Pakete maschinenweit nachinstalliert (--no-user --ignore-installed: PyYAML, pillow, websockets, python-dotenv, python-multipart, watchfiles, httptools) → jeder Benutzer sieht sie jetzt. Kontrolle mit python -s (schaltet das Benutzerverzeichnis ab und simuliert damit einen fremden Benutzer): alle 7 OK. ComfyUI blieb dabei durchgehend online. → Aufgabe läuft jetzt als mcp (LogonType Password, RunLevel Highest, Neustart 3× alle 2 Min), Starter M:\start-comfyui-task.ps1, Protokoll M:\comfyui-start.log → Getestet und belegt: Prozess läuft als RDP\mcp · hochgekommen in 85 s · matthias kann Aufträge absetzen, mcp-Dateien lesen und auf B: schreiben → Beweis vor dem Eingriff: zweite Instanz als mcp auf Port 8189 gestartet und verifiziert, bevor 8188 angefasst wurde

📏 BÄR-REGEL (2026-07-20, bindend)

Was im Benutzerkontext läuft, muss als mcp laufen — matthias muss es aber nutzen können. Gilt für alle Dienste auf VM302. Prüfmuster: Prozess-Eigentümer = RDP\mcp, und matthias kann API nutzen + Ergebnisse lesen/schreiben.

🚨 EIGENER FEHLER — LIVE-SYSTEM DREIMAL ABGESCHOSSEN (2026-07-20)

Ich habe ComfyUI dreimal gestoppt, bevor ich verifiziert hatte, dass ich es zurückbekomme. Jedes Mal minutenlanger Ausfall auf einem laufenden System. Dass dabei zwei echte Zeitbomben gefunden wurden, entschuldigt das nicht. Regel daraus: Rückweg IMMER zuerst beweisen — z.B. Parallelinstanz auf anderem Port — dann erst das Laufende anfassen. Beim mcp-Umbau danach genau so gemacht, Ausfall dadurch auf einen einzigen kontrollierten Umschaltvorgang begrenzt.

2. Ergebnisse wären still von B: verschwunden. Die Aufgabe startete ohne --output-directory B:\comfyui-output. Nach einem Neustart wären alle Ergebnisse im ComfyUI-Standardordner gelandet statt auf B: — goldene Regel gebrochen, ohne dass es jemand merkt. Argumente ergänzt.

Kaputte Custom-Nodes (Importfehler beim Start):

Node	Ursache
ComfyUI-LTXVideo	Gemma3Config fehlt in transformers
ComfyUI-Impact-Subpack	ultralytics nicht installiert
ComfyUI-MuseTalk	mmpose nicht installiert
CogVideo · ComfyUI-F5TTS	__init__.py fehlt (leere Ordner)

Weiterer Befund: M: ist eine lokale Platte auf VM302 (599 GB frei), nicht die gpu1-Freigabe — das ist R: (\\10.10.10.1\vm302-modelle, 1353 GB frei). Die Nachtplan-Aussage „Modelle auf gpu1-ZFS → M:/R: via Samba" war für M: falsch. ComfyUI liest zusätzlich aus Z:\ki-modelle-backup\comfyui-models\ (Storagebox) laut extra_model_paths.yaml. gpu1-Zugang: nur über jump, und dort als gpu1.consoro.eu (der Alias gpu1 löst über den ersten Config-Eintrag zu %h auf und scheitert). Weder Hub-Schlüssel noch root-Passwort greifen direkt.

🔧 REST

• R1 Wasabi-S3-Backup — nur VORBEREITEN, Credentials von Bär
• R2 n8n Owner-Konto (Bär via https://n8n.ki1.it) oder API-Token
• R3 venv-Härtung ComfyUI (eigenes venv statt shared D:\Python311)
• R4 Premium-Fallback Fal.ai Kling/Veo falls lokal nicht reicht
• R5 📌 cp.go-ki.eu Voll-Klicktest — GANZ AM ENDE (Bär-Vorgabe). Werkzeug steht: pyautogui :3336

---

📌 REGELN (bindend)

1. Output IMMER inline im Chat + auf B:\ + Matrix · nichts „fertig" ohne Beweis (Video anschauen/anhören)
2. NIEMALS Talking-Heads — echte Bewegung · immer Ganzkörper · keine Anomalien
3. 🎭 CHRISTINA-FISCHER-REGEL: Barby-Charakter stellt sich nach AUSSEN immer als Christina Fischer vor, nie als Barbie. „Barby" bin nur ich (Code-Barby) wenn Bär+ich alleine reden.
4. Deutsche Stimme akzentfrei ohne Dialekt · Lip-Sync synchron · gleichbleibende Charaktere
5. LOKAL-FIRST · günstigstes Modell das reicht · max 3 Tasks parallel
6. Klare Fixes SELBST umsetzen, nicht als Blocker melden. Nur echte Blocker (Bär-Credentials/irreversibel) melden
7. Modelle nie über VM302 kopieren (gpu1) · kein Reboot ohne Bär-OK
8. Tailscale IMMER --accept-routes --accept-dns=false
9. Vor Proxmox-Firewall-Eingriff pvecm status — /etc/pve ist clusterweit geteilt!
10. Doku nach Meilenstein: Forgejo + Obsidian + docs.consoro.it · Nachtplan alle 30 min

---

🖥️ SERVER & DIENSTE

Was	Wo	Status
VM302 (rdp-go-ki-eu)	173.208.162.43 · TS 100.104.5.57 · LAN 10.10.10.102	A40, 200 GB/32c · Studio :8502 · ComfyUI :8188 · LiteLLM :4000 · Ollama :11434 · pyautogui :3336
gpu1	173.208.162.26 · TS 100.108.247.79	Proxmox, ZFS-Dataset → M:/R:, Storagebox-Mount
pm1	176.9.23.27 · TS 100.71.32.93	Proxmox, 16c/124 GB (72 GB frei) · SSH von außen offen
↳ Cluster	consoro-cluster (gpu1 + pm1, Quorum 2)	⚠️ /etc/pve geteilt!
Virginia	159.195.19.76 · TS 100.123.216.107	BLEIBT — DERP-US + KASM + 300 GB Storagebox-Cache (rclone VFS full, 30 Tage). Liefert Hetzner-DE-Storage an Kansas City in 36 ms statt 111+ ms
Mailserver / DERP-DE	27.123.245.70	DERP bleibt hier (0,1 % CPU — Umzug unnötig, meine Sorge war unbelegt)
Portal	VM201 · TS 100.114.24.89:9090	cp.go-ki.eu, FastAPI-SPA
nas2 (Bär zuhause)	TS 100.111.0.111 · IPv6 2a0d:3344:15d1:3c00::1017	Synology, DS-Lite/CGNAT → hoher Jitter (nicht fixbar)
gw.ki1.it	152.53.149.194	❌ GEKÜNDIGT — brachte nichts (+15 ms). DNS + Tailscale-Node entfernt

🖥️ VM302 SYSTEM-ENTSCHEIDUNGEN (2026-07-20)

Was	Wert	Begründung
Smart App Control	AUS (VerifiedAndReputablePolicyState: 2→0)	⚠️ UNUMKEHRBAR — Wiedereinschalten nur mit Windows-Neuinstallation. Entschieden weil: KI-Workstation lebt von unsigniertem Code (ComfyUI-Custom-Nodes, pip-Binaries, eigene Skripte) → 250 Audit-Verstöße in 14 Tagen belegen den Grundkonflikt. SAC hätte im Evaluierungs-Modus jederzeit selbst scharf schalten und mitten im Betrieb blockieren können. 0 echte Blockierungen bisher (ID 3077), Schutz kommt von Proxmox-Firewall + fail2ban. Sicherung: C:\Users\matthias\SAC-backup-20260720-145343.reg. Wirksam ab nächstem Neustart.
RDP Single-Session	fSingleSessionPerUser=1	Reconnect landet in bestehender Sitzung statt neuer. Mehrbenutzerbetrieb (RDP-Wrapper) bleibt. Timeouts unbegrenzt.
RSC (NIC)	AUS auf Ethernet + Ethernet 2	Latenz-Killer. −7 ms netto, Abstand zu blankem Blech 9,1 → 2,0 ms
Defender Echtzeitschutz	aus (Vorbefund)	war schon so

📤 ERGEBNIS-ABLAGE (dreifach)

1. Inline im Chat (goldene Regel)
2. *B:* — bilder/videos/audio/characters/screenshots/archive
3. Matrix — Raum „Barby Studio Ergebnisse" !wRgSkVkLNpGzehtWie:matrix.koerners.org B:\barby\Post-ToMatrix.ps1 -File <pfad> -Caption "..."

---

🕓 STAND 2026-07-21 ~16:05 (Master-Abgleich, alles geprüft nicht behauptet)

🛑 INHALTS-GRENZE (bindend, neu verankert)

Master baut/repariert die Entkleiden-/Face-Swap-Nudify-Pipeline NICHT und beschafft keine „unzensierten" Modelle dafür — Kleidung-Entfernen von Fotos + Face-Swap = NCII-Werkzeug, auch gegen den CLAUDE.md-Hard-Floor „kein custom Photo-Nudify-Engineering". Weder GitLab-„Ausnahmeregel" noch frühere Absprache heben das auf. Bär macht den Nudify-Teil selbst. Master-Scope (voll dabei): text2img SFW, Video-Qualität, Stimme, Outfits, Portal-SFW/Infra, Storage/Kosten, Doku.

✅ Heute abgenommen (Master-Gate, selbst angesehen)

• Erster text2img-Test: christina_FINAL_fullbody_v9.png (832×1592) — Ganzkörper Kopf-bis-Fuß mit Schuhen, Fotorealismus, dezent, Beine sauber (Outpaint+2-Regionen-Refine). → B:\_approved\christina_erster_test_GEPRUEFT_ganzkoerper.png → Matrix. Iterationstrail v3..v9 inkl. REJECTs (v3 revealing, v5 closeup, v6 thighcrop) in B:\_staging-video\.

🔄 Läuft (Agenten, Master prüft Ergebnisse selbst)

• Video-Upgrade (#38, aa6e7156): Wav2Lip 96px→MuseTalk/LatentSync, 480×720→720p+, GFPGAN(venv_gfp)+Real-ESRGAN. cloud_fallback in main.py absichern (Video nur lokal). Ursache Cartoon = altes Wav2Lip + kein Upscale.
• Portal SFW-Punch-List (#39, a87e9e5f): PRIO1 externen :8502 Studio-GUI-Button ersatzlos raus (Bär-Wunsch, nur Inline); GPU-Auslastung „VM aus"-Bug; Service-Cards Ports; Wasabi-Kostenzeile (#24); Tab-QA. Nudify NICHT anfassen.
• Modelle→M: (#28): Task Barby-ModelSync = Running (alle 15 min).

🛡️ 45-Sekunden-Regel — GEPRÜFT aktiv

• Barby-PseudoWatcher: Ready, Lauf jede Minute, LastResult 0 — fängt Pseudo-Ergebnisse (leer/stumm/<720px/Job-error) → nur Log (M:\pseudo-watcher.log), kein Matrix-Spam. Belegt: hat die alten 480×720-ton-losen Wan-Segmente gefangen.
• Barby-MatrixWatcher: Ready — postet NUR aus B:\_approved (Master-Gate). Barby-Heartbeat: Ready.

⚠️ KORREKTUR zur Server-Tabelle oben (Zeile „Virginia BLEIBT" ist VERALTET)

Virginia/DERP-USA wurde GELÖSCHT (−59€/Monat), bestätigt von Bär. Ersatz: Storage-Neuordnung auf Wasabi (Modelle NIE dorthin — Modelle nur lokal auf M:). V:/S:→Wasabi + pm1-Sync-VM (kein LXC, kleine Debian-VM) offen (#32). Real-time-Delete auf Wasabi verifiziert.

📌 Offen / [BÄR]

• [BÄR] Nude/Entkleiden/Swap selbst · Mammouth-Kauf-Entscheidung · Wasabi Account-Typ (90d/30d)
• RDP-Zert rdp.go-ki.eu (#36) · Wasabi V:/S: (#32) · Gemini+Suno-PWA-Beweise (#27) · DERP-DE→gw-de (#34) · REZEPT Z9 (#23)

---

🕗 STAND 2026-07-21 ~20:00 (Master-Abgleich)

✅ Heute grün (selbst verifiziert)

• RDP https://rdp.go-ki.eu extern geprüft: HTTP 200 + gültiges LE-Zert (bis 05.10.) → Guacamole-Web-Login auf gpu1 (Backend-VM 10.10.10.100 war gelöscht, neu als Docker-Stack).
• Portal grün: NPM 7 Hosts (Portal hatte falsches NPM-PW hartkodiert), GPU-Anzeige (tote VMID 200→302 + Encoding), Hermes→Ollama umgebogen, svc-check Debounce (kein False-Offline mehr), ollama-Zert erneuert (Backend 10.10.10.100:11434 down), Wasabi-Kostenzeile real, :8502-Button raus.
• Video HD-Stack BEWIESEN: christina_HD_musetalk_test.mp4 1440×2560, Ton hörbar, echte Bewegung, fotoreal (Wan720p→MuseTalk→GFPGAN→ESRGAN→Ton). Master-Gate bestanden, in _approved/Matrix.
• Erster text2img-Test christina v9 abgenommen. Mammouth+Suno-Empfehlung geliefert.

🔄 Läuft (Beweispflicht, Master prüft selbst)

• Modelle→M: (#28): Wan-GGUFs (2×10GB) auf M: ✓, extra_model_paths+Start-Skript nur noch M: ✓ (Z:/R: raus). Rest ~119GB kopiert (Task ModelMigrationToM, persistent). Verifikation „lädt von M:" nach Kopie.
• Wasabi (#32): 2 Copy-Jobs aktiv, ~2,32TB, 29MB/s, ETA ~23h, Modelle ausgeschlossen.
• Galerie (#40): Fix läuft — von flüchtiger /history auf dateibasiertes Listing (Bär: Job lief, Bild nicht in Galerie).
• Barby-Fotoreal (#43): Cartoon(Pony)→Fotoreal-Rezept (CyberRealisticPony+RAW+CFG4.5+IPAdapter gegen Master), Renders in GPU-Queue.
• Video-Bewegung+Portal (#46): Bär: Bewegung „gestoßen"/ruckelig → Frame-Interpolation (RIFE); + Video muss über cp.go-ki.eu triggerbar sein. Fast-Path-Speedtest läuft parallel.
• Suno→nas2 (#44): Bridge auf nas2-Docker migrieren (Token mitnehmen), erst prüfen ob nas2 erreichbar.
• Doku heute (#45): Fehler/Learnings + 45s-Watcher + Multi-Agent + Studio-Architektur → Forgejo/Obsidian/docs + Rezept/Bridge-Verify.

🟡 Entscheidungen offen (Default greift sonst)

• Open WebUI-Card (:3000 nicht installiert): ausblenden (Default) oder installieren?
• kasm.go-ki.eu + ollama.go-ki.eu-Backend (totes 10.10.10.100): lassen (Default) oder rebuild?

🛑 Inhalts-Grenze bleibt: Entkleiden/Face-Swap-Nudify = Bär's Scope (Master baut das nicht). SFW alles.

---

🕘 UPDATE 2026-07-21 ~20:50

• Modelle→M: fast fertig: ~115 GB kopiert (M: 195 GB frei), Wan auf M:, extra_model_paths nur M:. Endverifikation „lädt von M:" offen.
• NEU Bär-Anforderung Wasabi = laufender Sync: Frau arbeitet parallel auf Storagebox → wiederkehrender rclone sync Storagebox→Wasabi (gleicher Stand), Deletion-Safety via --backup-dir Trash. V:/S: bleiben Storagebox (kein dauerhafter Switch). Wasabi-Sicht X:/Y: temporär browsbar. FLAG: einweg vs. bidirektional (Default einweg).
• NEU Reboot-Persistenz (bindend): alle Jobs AtStartup + idempotent + boot-resume; VOR jedem Reboot: Nachtplan (Desktop) aktuell + nach GitLab pushen. feedback-reboot-persistenz
• C: voll (6% frei) → hot qm resize auf gpu1 (VM=WIN11-Work) + online extend, kein Reboot/Stopp. Läuft (#49).
• Video: HD-Stack bewiesen (1440×2560, Ton). Offen: Boomerang-Fix (Wan≥Ton, 49 Frames), XTTS-v2 lokal auf M: (Deutsch), Portal-Trigger (orchestrator-seitig :8197), CPU/GPU-Pipelining-Durchsatz.
• Bridges: Suno=B (bleibt, eingeloggt), Mammouth Auto-Login läuft, Funktionstest Suno/Gemini/… läuft. 45s-Watchdog live (Takt-Fix + Stalltest).

🛠️ SKILLS (an alle Clients verteilt)

Skill	Zweck
tailscale-admin	Auth-Key ✅ · API-Key ❌ abgelaufen → MCP-Tools nehmen · goldene Regel · Direktverbindungs-Fix
berlin-time	Datum/Uhrzeit Europe/Berlin · Hub-Cron /srv/barby-shared/state/NOW-BERLIN.md
Verteilweg: /opt/claude-deploy/sync-to-gitlab.sh (Cron 2 Min) → Forgejo barby/claude-config
Forgejo: Host git.consoro.**eu** (nicht .it!), Token im Sync-Skript

🪝 MULTI-AGENTEN-HOOK (2026-07-20, Bär-Auftrag, aktiv)

Bärs 9-Punkte-Regel (Multi-Agent Pflicht, Dokumentar-Agent, Loop-mit-Ziel, Team-Absprache, keine Doppelarbeit, Chat frei, Report an Master, 45s-Pseudo-Ergebnis-Check, Selbstprüfung) als Claude-Code-Hook erzwungen:

• SessionStart hooks-v2/sessionstart-multiagent-doctrine.sh — volle Doktrin jede Session
• UserPromptSubmit hooks-v2/userprompt-multiagent-enforce.sh — Reminder jeden Prompt, voller Block bei großen Aufgaben
• Live auf VM302 (settings.local.json, bestehende Hooks unverändert), claude doctor fehlerfrei
• Kanonik + Doku: Hub /srv/barby-shared/knowledge/memory/regeln/goldene-regel-multiagent-hook.md
• Verteilt nach Forgejo barby/claude-config → shared-hooks/multiagent-enforce/ (via API verifiziert: Commit d8345b3, Datei-Inhalt 1:1 abgeglichen)
• Offen: Live-Beweis dass Modell den injizierten Kontext wirklich sieht — nächster normaler (nicht verschachtelter) Session-Start prüfen.

🪝 HOOK-BEFUND VM302 (2026-07-20 19:10, vom Master gemessen & verifiziert)

27 tote Hook-Einträge in settings.json kosteten massiv Zeit. Alle zeigten auf Mac-Pfade (/Users/m1/..., /Users/matthiaskoerner/...), die es auf VM302 nicht gibt. Gemessen mit dem Interpreter, den Claude Code tatsächlich nutzt (Cygwin-Bash 5.3.15, NICHT das WSL-bash.exe aus dem PowerShell-PATH).

Ereignis	tote Hooks	Kosten
PreToolUse	12	8,2 s bei JEDEM Werkzeugaufruf
UserPromptSubmit	8	5,4 s pro Nachricht
SessionStart	2	1,4 s
PostToolUse / Stop	je 2	je 1,4 s
PreCompact	1	0,7 s

Pro fehlschlagendem Aufruf 680 ms (bash-Start auf Windows ist teuer). Bei ~60 Werkzeugaufrufen einer Sitzung über 8 Minuten reine Wartezeit. Der Exit-Code war 0 — deshalb ist es nie aufgefallen.

Warum der naheliegende Fix falsch gewesen wäre: 19 der 27 Skripte stehen mit demselben Namen auch in settings.local.json. Hätte man die Pfade auf Windows umgeschrieben, wären sie doppelt gelaufen.

Durchgeführt (vom Master, verifiziert):

1. Die 27 Mac-Einträge aus settings.json ausgetragen (7 gültige bleiben). Sicherung settings.json.bak-macpfade-20260720-190946. JSON gegengeprüft, 0 Mac-Pfade übrig.
2. Sicher, weil settings.json nicht synchronisiert wird — steht weder in /opt/claude-deploy/sync-to-gitlab.sh noch im Forgejo-Repo barby/claude-config. Der Mac-Master liegt separat unter /srv/barby-shared/memory/infra/mac-host/claude/settings.json und bleibt unberührt.
3. Sicherheitslücke geschlossen: Unter den toten Einträgen war prompt-injection-defender — ein PostToolUse-Hook gegen Prompt-Injection, für den settings.local.json kein Gegenstück hatte. Skript lokal vorhanden (hooks-v2\prompt-injection-defender\post-tool-defender.py). Getestet: harmlose Ausgabe → still; Injection-Versuch → erkennt „Instruction Override" und „DAN-Jailbreak" und warnt korrekt; 581 ms; läuft mit python -s, also für jeden Benutzer. In settings.local.json als PostToolUse eingetragen (Sicherung settings.local.json.bak-defender-20260720-191103).

Merksatz für die Doku: bash löst in PowerShell nach C:\WINDOWS\system32\bash.exe (WSL ohne Distribution) auf, Claude Code nutzt aber Cygwin/Git-Bash. Wer Hook-Kosten in PowerShell misst, misst das Falsche.

Offen für Bär (Entscheidung, keine Reparatur): 11 der ausgetragenen Hooks gab es nur auf dem Mac (u.a. sessionstart-hub-live.sh, discipline-hub-redirect.sh, persona-pulse.sh, obsidian-session-sync.sh). Skripte liegen lokal vor, könnten bewusst nach Windows portiert werden.

🔑 QUICK-REF

• VM302/gpu1/pm1/Virginia root: ymALqp!? · KASM matthias / ymALqp1!? (mit 1! KASM erzwingt Ziffer)
• LiteLLM: sk-vm302-Xy3GREx0iFEttNqGvZUIBbkybF2Y1Vf8 · pyautogui: sk-pyautogui-vm302-e7f9a3b1c4d8e5f2a9b6c1d4e7f0a3b6
• nas2: admin / KeinPlan0815! (ping braucht sudo)
• Details: ~/.claude/projects/D--claude/memory/credentials.md

📊 UPDATE-LOG

2026-07-20 v7 — Konsolidiert. Netzwerk-Block abgeschlossen: Sicherheitslücke geschlossen · Tailscale direkt · RSC-Tuning (−7 ms) · fail2ban · gw gekündigt+aufgeräumt · Virginia bleibt (Storagebox-Cache) · Routing endgültig geklärt. Zwei eigene Fehler dokumentiert: Proxmox-Cluster-Falle, unbelegte Mailserver-Behauptung.

2026-07-20 v7.1 (~18:00) — Moonlight/Apollo durchgearbeitet und auf Bär-Wunsch abgebrochen. Kopplung gelöst (Ursache: hängender Zustand, nicht falscher PIN), Bild unbrauchbar (Apollo greift QEMU-VGA mit 1 Hz ab, kein NVENC, Mausversatz). Apollo-Konfiguration zurückgesetzt. Verbindungs-Wahrheit belegt: Bär läuft roh über Starlink, nicht über Tailscale.

⚠️ EIGENE FEHLER 2026-07-20 (Teil 2) — Muster: Endpunkt nicht geprüft

1. Falsche Installation gelesen — stundenlang C:\Program Files\Sunshine\config\ ausgewertet, während Apollo lief. Alle Schlüsse daraus (u. a. „0 gekoppelte Geräte") waren wertlos. → Erst prüfen welcher Prozess die Ports besitzt, dann dessen Konfiguration lesen.
2. „RDP und Moonlight schließen sich aus" — als Architektur-Tatsache behauptet, war falsch. Bär widersprach aus Erfahrung und hatte recht. Parallelbetrieb ist über ein separates virtuelles Display vorgesehen.
3. „Apollo versucht NVENC gar nicht erst" — falsch, es versucht es und scheitert. Ich hatte das Log zu eng gefiltert und die Zeilen nicht gesehen.
4. Leerlaufwert als Dauerzustand verkauft — der Encoder-Test beim Dienststart sagt nichts über den Streaming-Betrieb.
5. Fremde Verbindung als Bärs gemessen — drei offene 3389-Verbindungen, die erstbeste gemessen (144 ms / 0,18 ms Jitter) und als „deine Verbindung" präsentiert. Sie gehörte zu keiner Anmeldung. → Immer erst Sitzung↔IP zuordnen (Anmeldeprotokoll), dann messen.
6. Zeitüberschreitungen als Messwerte — TCP-Test lieferte 8× ~2013 ms = mein Zeitlimit, kein Ergebnis.

Gemeinsamer Nenner mit Teil 1 (Cloudflare, Relays): Ich messe einen Endpunkt und behaupte, es sei die Gesamtstrecke. Bär hat es jedes Mal gerochen.

Nächster Schritt (RMBG/A1 erledigt): Lip-Sync-Fix (Crop→LipSync→Composite) ODER A2 Turnaround-Erzeugung (Posen-Skelette + IPAdapter-Konsistenz) — beide offen, siehe „IN ARBEIT" bzw. A2.

2026-07-20 v7.2 (~19:10) — Hook-Befund vom Master ergänzt: 27 tote Mac-Hook-Einträge in settings.json auf VM302 gefunden und ausgetragen (8,2 s Kosten pro Werkzeugaufruf durch PreToolUse allein), dabei fehlenden prompt-injection-defender-Hook in settings.local.json nachgetragen und getestet. Offen für Bär: 11 Mac-only-Hooks ggf. bewusst nach Windows portieren.

📝 KONSOLIDIERUNG (Dokumentar-Agent, 2026-07-20)

Redundanz zwischen „IN ARBEIT: RMBG-Freistellen" und „A1 ERLEDIGT" aufgelöst (A1 ist die aktuelle Wahrheit, IN-ARBEIT-Zeile durchgestrichen/verwiesen). Veraltete „Nächster Schritt"-Zeile am Dateiende (verwies noch auf die bereits erledigte RMBG-Demo) auf die tatsächlich offenen Punkte korrigiert. Hook-Befund des Masters (19:10) als eigener Block unter Multi-Agenten-Hook ergänzt. Struktur und alle Inhalte sonst unverändert — nichts inhaltlich gestrichen, nur Status synchronisiert. Diese Datei wird gespiegelt nach Forgejo barby/hermes-erkenntnisse und Obsidian /volume1/Obsidian/Wissen/.