Fruehjahrsputz. Alles hier ist unabhaengig von der laufenden Supervisor-
Arbeit im Arbeitsverzeichnis - die bleibt unangetastet.
Entfernt:
- Die zwoelf Symbole unter public/assets/ waren bitgleiche Dubletten der
Dateien in public/assets/icons/. Referenziert wurde ausschliesslich der
Pfad mit icons/. getMonitorIconUrl() setzt flach gespeicherte Altwerte
aus der Datenbank jetzt auf icons/ um, damit bestehende Monitore ihr
Symbol behalten.
- System.CommandLine (2.0.0-beta4) aus dem Packager. Kein using, kein
Symbol, die Argumente werden von Hand geparst. Build bleibt fehlerfrei.
Geschlossen:
- client-php/ und mcp/ wurden weder von der .htaccess gesperrt noch vom
Deployment ausgeschlossen. Die .mjs-Datei haette der Webserver im
Klartext ausgeliefert. Beide gehoeren nicht ins Webroot: die PHP-Datei
wird ins Zielprojekt kopiert, der MCP-Server laeuft lokal ueber stdio.
Jetzt in beiden Ausschlusslisten - wie client-dotnet.
- Fuer /api/supervisor/v1/ fehlte die Rewrite-Regel. Der Datei-Fallback
haette /api/supervisor/v1/findings auf eine nicht vorhandene Datei
geleitet, obwohl Code und OpenAPI diese Schreibweise vorsehen.
Ergaenzt:
- __pycache__/ und *.pyc in .gitignore.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Regression aus dem vorigen Commit
- /api/license/v1/validate lieferte die Antwort im neuen status/error-Umschlag.
Der Vertrag dieses Endpunkts ist aber bereits ausgerollt: das Feld "status"
auf oberster Ebene trägt den Lizenzzustand (valid, revoked, expired ...).
LicenseClient las dadurch "success" statt "valid" — jeder ausgelieferte
Client hätte seine Lizenz für ungültig gehalten. Die Lizenz-Endpunkte
antworten jetzt wieder ohne Umschlag (Http::raw).
Gefunden durch Ausführen der projekteigenen Test-Suite gegen den Server.
Packager
- FTP-Zugangsdaten standen als Standardwerte im Quelltext und zusätzlich in
packager.config.json und in der Integrationsanleitung. Alle drei Fundstellen
bereinigt; die Konfigurationsdatei ist nicht mehr versioniert. Zugangsdaten
kommen aus Datei, Umgebungsvariablen oder CLI-Argument, sonst bricht das
Programm mit einer klaren Meldung ab.
- Das Veröffentlichen sendet jetzt ein Token (updateservice:publish) und nutzt
den Endpunkt /api/updateservice/v1/publish.
- Fehler wurden von einem leeren catch verschluckt, und ohne Erfolgsfall wurde
gar nichts ausgegeben. Das Werkzeug meldete am Ende immer Erfolg und lieferte
Rückgabewert 0, selbst wenn FTP-Upload und API-Aufruf fehlgeschlagen waren.
Jetzt ehrliche Meldungen und Rückgabewerte 0/1/2.
- packager.config.json wurde vom csproj nie ins Ausgabeverzeichnis kopiert,
weshalb sie dort nie gefunden wurde und stets die hartkodierten Werte griffen.
UpdateClient
- IsVersionNewer entfernte die Vorabkennung, aber kein führendes "v". Damit
scheiterte Version.TryParse bei "v1.4.2" und es wurde auf einen
alphabetischen Vergleich zurückgefallen, in dem "v1.9.0" als neuer gilt als
"v1.10.0" — derselbe Fehler wie zuvor serverseitig im SQL. Ersetzt durch
einen vollständigen semantischen Vergleich, verifiziert mit 16 Testfällen.
- Der Rückfall auf die API lag in einem catch-Block, aber GetAsync wirft bei
einem 404 keine Exception. Fehlte die statische latest.json, brach die
Prüfung ab, statt die API zu befragen.
Dokumentation
- BUGTRACKER_INTEGRATION_GUIDE.md beschrieb denselben Workflow ein zweites Mal
und war bereits auseinandergelaufen: Aufrufe ohne Token, alte Pfade, weder
Claim/Lease noch Idempotenz. Ersetzt durch einen Verweis auf das gepflegte
Agenten-Handbuch samt Übersicht der Änderungen.
- UPDATESERVICE_INTEGRATION_GUIDE.md um Token, Umgebungsvariablen und
Rückgabewerte ergänzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
