v1.3.41 · Sicherheits-Scanner blockierte jede Neuinstallation (behoben)

Dringender Fix: Hermes' eigener Sicherheits-Scanner stufte dieses Repo als GEFAEHRLICH ein (Muster curl_pipe_python, KRITISCH) und blockierte jede Neuinstallation, auch mit --force. Ursache: ein 'curl ... | python3 -' Befehl in der README fuer den Notausstieg ohne laufendes Hermes Desktop (siehe v1.3.35). Jetzt in zwei Schritte aufgeteilt (Download, dann Ausfuehren) - funktional identisch, ohne das Pipe-Muster. Kein Code in restore-original.py selbst veraendert.

Hinweis: Ich kann Hermes' Scanner von hier aus nicht selbst erneut laufen lassen, um das Ergebnis direkt zu bestaetigen. Wer betroffen war: bitte melden, ob die Installation jetzt durchlaeuft.

v1.3.40 · Wächter repariert nur noch, was im Katalog sichtbar ist

Community-Report ueber unser eigenes Diagnose-Tool zeigte einen Reparatur-Loop: group-chat-limits wurde alle paar Minuten bis Stunden als 'repariert' gemeldet, war aber beim naechsten Check wieder 'missing' - inklusive dem teuren automatischen Desktop-Neubau bei jedem Fund. Der Anker selbst ist intakt (gegen aktuellen Hermes main erneut verifiziert), das eigentliche Problem liegt woanders: group-chat-limits ist seit dem 10.09. bewusst als unfertig aus dem Katalog versteckt, wurde aber fuer Nutzer, die es davor installiert hatten, trotzdem fuer immer automatisch geprueft und repariert.

Der Waechter prueft und repariert jetzt nur noch, was aktuell im Katalog sichtbar ist. Eine bereits installierte, aber versteckte Komponente bleibt unangetastet liegen und loest keinen Rebuild-Loop mehr aus. Ist der Katalog aus irgendeinem Grund nicht lesbar, faellt das bewusst auf die alte Pruefung ALLER Komponenten zurueck - lieber zu viel geprueft als riskant zu wenig.

Ausserdem: eine irrefuehrende Neustart-Meldung nach einem Hub-eigenen Update korrigiert (v1.3.39 nachgezogen) - der Hub selbst hot-reloadet seine Oberflaeche automatisch, ganz ohne Neustart, das betraf nur die Nutzer-Meldung, nicht die eigentliche Funktion.

v1.3.39 · Irreführenden Neustart-Hinweis nach Hub-Update korrigiert

Community-Rueckmeldung: nach einem Hub-Selbstupdate blieb der Hinweis 'Hermes komplett beenden und neu starten' stehen, obwohl das Backend bereits erfolgreich neu geladen hatte. Nachgeprueft gegen Hermes' eigene Desktop-Plugin-SDK-Dokumentation: unser Hub ist ein 'Unified Package' ($HERMES_HOME/plugins/aiianer-hub/desktop/plugin.js) und laeuft ueber dieselbe Disk-Pipeline wie jedes andere Desktop-Plugin - die App hot-reloadet die Oberflaeche automatisch bei jeder Aenderung, ganz ohne Neustart. Nur das Backend brauchte den expliziten restartGateway()-Schritt, den es schon gab.

Die Meldung nach einem Hub-Update behauptete faelschlich, ein kompletter Neustart sei noetig. Jetzt korrekt: Backend ist bereits aktuell, die Oberflaeche laedt sich normalerweise von selbst binnen Sekunden nach - bleibt trotzdem der alte Stand sichtbar, hilft die Befehlspalette (Strg/Cmd+K) -> 'Reload desktop plugins', oder ein normaler Neustart als Rueckfall.

Wichtig zur Einordnung: das betrifft NUR den Hub selbst. Die deutsche Sprachdatei aendert echten Hermes-Quellcode statt eines Plugin-Files und braucht deshalb weiterhin den vollen Neubau-Weg aus v1.3.36-1.3.38 - zwei technisch unterschiedliche Faelle, die beide 'die Oberflaeche zeigt noch den alten Stand' ausloesen koennen, aber unterschiedliche Loesungen brauchen.

v1.3.38 · Verwaister Build-Stempel wird jetzt auch erkannt

Community-Befund, sehr praezise diagnostiziert: der automatische Neubau aus v1.3.37 griff in einem bestimmten Fall trotzdem nicht. Genauer Ablauf: ein FRUEHERER Waechter-Lauf (noch mit einer aelteren Hub-Version ohne automatischen Rebuild) reparierte den Quellcode und entfernte dabei korrekt den Build-Stempel - baute aber noch nicht neu. Kurz danach aktualisierte sich der Hub selbst auf 1.3.37 und der Gateway startete neu. Der neue Waechter fand den Quellcode bereits intakt vor und brach ab, ohne zu pruefen, dass der Build-Stempel immer noch fehlte. Ergebnis: die fertige App blieb veraltet, obwohl der Quellcode laengst wieder stimmte.

Der Waechter prueft den fehlenden Build-Stempel jetzt als EIGENSTAENDIGES Signal, unabhaengig davon, ob im selben Durchlauf auch am Quellcode etwas zu reparieren war. Sechs neue Tests (tests/test_guard_check_rebuild.py) sichern das ab, inklusive eines Tests, der nachweislich fehlschlaegt ohne diesen Fix.

v1.3.37 · Automatischer Wächter baut jetzt auch selbst neu

Schliesst die letzte Luecke aus v1.3.36. Dort baute der Marktplatz die Desktop-App bei Installation, Deinstallation und Reparatur bereits selbst neu, aber nur, wenn jemand aktiv im Marktplatz-Reiter klickte. Der automatische Waechter, der nach jedem Hermes-Update die Sprachdatei repariert, tat das bisher weiterhin nur am Quellcode, ohne die Desktop-App neu zu bauen - man musste also nach einem Hermes-Update trotzdem einmal manuell nachhelfen.

Der Waechter loest jetzt ebenfalls einen sofortigen Neubau aus, ganz ohne Zutun. Der richtige Moment dafuer ist ohnehin gegeben: er feuert beim naechsten Hermes-Start nach einem Update, und genau da hat man gerade erst Hermes' eigenen Update-Bildschirm hinter sich gebracht ("Fenster schliesst sich, Neustart folgt automatisch") - ein paar zusaetzliche Sekunden bis Minuten fuer den Neubau fallen in diesem Wartemoment nicht mehr auf. Gateway-Hooks laufen laut Hermes' eigener Dokumentation, ohne die Gateway-Pipeline zu blockieren, der Start haengt dadurch nicht.

Damit sollte die deutsche Sprachdatei jetzt wirklich in jedem Fall von selbst da sein, ohne jemals den Marktplatz-Reiter oeffnen zu muessen.

v1.3.36 · Sprachdatei wird jetzt wirklich sofort sichtbar

Der Fix aus v1.3.35 (Content-Hash-Stempel entfernen) war richtig, aber nicht vollstaendig: ein Community-Bericht kurz nach dem Release zeigte, dass ein normales Oeffnen ueber das App-Symbol den Neubau der Desktop-App gar nicht erst anstoesst. Diese Erweiterung veraendert Hermes' Quellcode, verlaedt aber nichts zur Laufzeit nach - aus dem veraenderten Quellcode muss erst wieder eine fertige App gebaut werden, und nur "hermes desktop" im Terminal tut das von Haus aus. Ein einfacher Neustart ueber das Programm-Symbol nicht.

Installation, Deinstallation und Reparatur bauen die Desktop-App deshalb jetzt selbst neu (hermes desktop --build-only --force-build), direkt waehrend der Aktion, nicht erst beim naechsten zufaelligen Terminal-Start. Ein normaler Neustart danach reicht wirklich. Das kann den Installieren-Knopf spuerbar laenger dauern lassen (bis zu ein paar Minuten je nach Rechner), dafuer stimmt das Ergebnis. Schlaegt der automatische Neubau ausnahmsweise fehl, bleibt der bisherige Weg als Rueckfall: einmal "hermes desktop" im Terminal ausfuehren.

Ausserdem: der Diagnose-Weg fuer nicht-technische Nutzer ist jetzt zugaenglicher - statt eines nackten Terminal-Befehls gibt es einen Satz zum Kopieren in den Hermes-Chat, Hermes fuehrt die Diagnose dann selbst aus.

v1.3.35 · Deutsche Sprachdatei: Ursache für „verschwindet nach Update" gefunden und behoben

Der wichtigste Fix in diesem Release betrifft die deutsche Sprachdatei. Hermes Desktop entscheidet über einen Content-Hash-Stempel, ob es sich beim nächsten Start neu baut. Weder die Installation noch der Wächter haben diesen Stempel bisher gelöscht, wenn sie die Sprachdatei nach einem Hermes-Update reparierten - Hermes hielt dadurch manchmal einen veralteten Stand für aktuell und baute nicht neu. Das erklärt das gemeldete Muster "Update entfernt Deutsch, ein Neustart bringt es nicht zurück, erst ein manueller Eingriff hilft". Installation, Deinstallation und der Wächter entfernen den Stempel jetzt selbst, sobald sie etwas an Hermes' Sprachdateien ändern - ein Neustart baut danach zuverlässig neu.

Dazu, für den Fall, dass Hermes Desktop nach der Sprachdatei-Installation gar nicht mehr aufgeht und der Marktplatz-Reiter deshalb unerreichbar ist: ein Notausstieg direkt im Terminal, ohne laufendes Hermes Desktop (extensions/german-language/restore-original.py, siehe README).

Weitere Fixe und neue Werkzeuge in diesem Release:

• Ein Live-Drift in der internen Gruppenchat-Grenzen-Komponente gefunden und behoben (aktueller Hermes main hatte eine Funktionssignatur erweitert; unser Anker war zu wörtlich).
• Neuer Diagnose-Befehl (python3 guard_check.py diagnostics, auch als Route im Dashboard): ein copy-paste-fertiger Status-Report für Support-Anfragen, läuft auch im Terminal, wenn die GUI selbst das Problem ist.
• Täglicher automatischer Trockenlauf gegen den aktuellen Hermes-Quellcode (GitHub Actions), meldet einen gerissenen Anker künftig von selbst, bevor ihn jemand als Fehler erlebt.
• Komponenten-Installationen laden jetzt bevorzugt vom releasten Git-Tag statt vom jeweils aktuellsten main-Stand.
• Der Installieren-Knopf für Deutsch prüft jetzt vorher, ob Hermes' Sprachdateien noch zur erwarteten Form passen, statt erst beim Klick zu scheitern.

v1.3.32 · Optionale Host-API abgesichert

Fehlende optionale Host-Funktionen beenden den Hub nicht mehr.

v1.3.31 · Hook-Reihenfolge vollständig stabilisiert

Der Backup-Tab-Hook wird vor allen frühen Render-Rückgaben aufgerufen.

v1.3.30 · React-Hook-Reihenfolge stabilisiert

Der Desktop-Hub lädt die Daten über einen einzigen stabilen React-Hook und hält die Hook-Reihenfolge konstant.