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>
2.6 KiB
2.6 KiB
Bugtracker-Integration
Dieser Leitfaden wurde zusammengeführt.
Die vollständige, gepflegte Beschreibung steht im Agenten-Handbuch — öffentlich erreichbar unter
https://dc.mhdf.de/docs/und maschinenlesbar unterhttps://dc.mhdf.de/api/openapi.json.Zuvor existierten zwei Beschreibungen desselben Workflows nebeneinander. Sie waren bereits auseinandergelaufen: die hier stehenden Beispiele riefen die Endpunkte ohne Token auf, benutzten
report.phpundmanage/index.phpals Pfade und kannten weder Claim/Lease noch Idempotenz. Ein Agent, der diesem Dokument folgte, wäre seit Version 2.0 an401 unauthorizedgescheitert.
Was sich gegenüber der alten Fassung geändert hat
| Alt | Neu |
|---|---|
POST /api/bugtracker/v1/report.php ohne Token |
POST /api/bugtracker/v1/report mit Token (bugtracker:report) |
GET /api/bugtracker/v1/projects.php ohne Token |
GET /api/bugtracker/v1/projects mit Token (bugtracker:read) |
GET .../manage/index.php?project_slug=… |
GET .../manage?action=list&project_slug=… |
created_by frei wählbar |
Wird aus dem Token abgeleitet |
| Keine Reservierung — zwei Agenten konnten dasselbe Item bearbeiten | ?action=next holt und reserviert exklusiv (Claim/Lease) |
| Wiederholte Sendung erzeugte Duplikate | client_ref bzw. Header Idempotency-Key |
| Fehler nur als Freitext | Stabiler error.code zum Auswerten |
Kürzestmögliche Fassung
# 1. Arbeit holen und übernehmen
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=next" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"project_slug": "myapp", "limit": 1}'
# 2. Zwischenstand festhalten
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=comment&id=42" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"comment": "Ursache gefunden.", "action_taken": "investigated"}'
# 3. Abschließen
curl -X POST "https://dc.mhdf.de/api/bugtracker/v1/manage?action=resolve&id=42" \
-H "Authorization: Bearer $DC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"resolved_in_build": "v1.4.3", "resolution_notes": "Fix in AuthController."}'
Weiterführend
- Agenten-Handbuch — vollständige Referenz mit allen Feldern, Filtern, Fehlercodes und einem Python-Beispiel
- Agent-Prompt-Vorlage — Textbaustein für
CLAUDE.md/AGENTS.md - UPGRADE.md — Umstellungsschritte für bestehende Integrationen