Deploymentcenter BotandClaude Opus 5
65e60899f9
Rücksprung auf das Dashboard Nach jedem Speichern landete man auf der Standard-Unteransicht des Moduls statt dort, wo man gearbeitet hatte. Drei Ursachen: - Die Handler setzten nur den Modul-Anker (#tab-watchdog). Damit blieb die Unteransicht unbestimmt und es wurde die erste angezeigt. - Die Wiederherstellung aus dem Anker leitete den Modulnamen aus dem Namen der Unteransicht ab (sub-<modul>-<rest>). Für "sub-update-releases" ergab das "update" statt "updateservice". - Der zugehörige Navigationsknopf wurde über seinen Beschriftungstext gesucht, der den Modulnamen nie enthält. Der Rückweg schlug also immer fehl. Jetzt teilt das Formular beim Absenden mit, welche Unteransicht offen war (_return), und der Server leitet dorthin zurück. Umgesetzt als zentraler submit-Zuhörer, damit künftige Formulare das Verhalten erben. Die Zuordnung Unteransicht -> Modul kommt aus derselben Liste, die auch die Navigation aufbaut, und die Knöpfe tragen eine eindeutige Kennung statt Text. Zusätzlich wird die Ansicht jetzt auch bei Vor- und Zurück-Navigation im Browser wiederhergestellt. Lizenzmodul Vier Unteransichten für eine Aufgabe sind auf zwei sinnvolle reduziert: - "Dashboard" zeigte drei Zahlen; sie stehen jetzt über der Liste. - "Lizenz Bearbeiten & HW" ist entfallen. Zum Bearbeiten musste man die gerade angeklickte Lizenz in einer Auswahlliste erneut suchen. Jetzt öffnet sich ein Dialog direkt über der Tabelle, die Hardware-Liste steht daneben. - "Settings" enthielt zwei fest verdrahtete URLs und ist in "Integration" aufgegangen, zusammen mit einem Beispielaufruf. - Der dort angezeigte "Ed25519 Public Key" war frei erfunden und wurde entfernt; die Offline-Vorschau nennt jetzt das tatsächlich verwendete HMAC-SHA256 und weist darauf hin, dass nur der Download signiert ist. Nebenbei Der Inhalt des Projekte-Moduls lag direkt im Modul-Container, ohne subtab-content. Der Navigationseintrag "Projekte Übersicht" zeigte damit ins Leere. Jetzt einheitlich wie alle anderen Module. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploymentcenter — Entwickler- und Agenten-Dokumentation
Zentrale Plattform für Lizenzverwaltung, Software-Updates, Infrastruktur- Monitoring und einen Bugtracker, den Coding-Agenten selbständig bedienen.
Zuerst lesen
| Dokument | Wofür |
|---|---|
| UPGRADE.md | Ablaufplan für die Umstellung auf 2.0. Enthält Pflichtschritte: Zugangsdaten wechseln, Migration, Evaluator-Cron. |
| Agent-Prompt-Vorlage | Textbaustein für CLAUDE.md / AGENTS.md eines Projekts |
| Agenten-Handbuch | Vollständige Beschreibung des Bugtracker-Workflows, öffentlich unter /docs/ |
Modul-Handbücher
- Lizenzsystem (Hardware-ID v2) — Hardware-Anbindung, Schlüsselvalidierung, Offline-Cache, CLI, Windows und Linux/Docker
- Watchdog (Heartbeat & Telemetrie) — Überwachung von Anwendungen, Diensten und Infrastruktur
- UpdateService — Release-Verteilung und Update-Prüfung
- Bugtracker — Anbindung aus Anwendungen heraus
Modulübersicht
| Modul | Aufgabe | Endpunkte | Authentifizierung |
|---|---|---|---|
| Bugtracker | Fehler, Feature Requests und Ideen; Agenten-Workflow mit Claim/Lease | /api/bugtracker/v1/report/api/bugtracker/v1/projects/api/bugtracker/v1/manage |
Token mit bugtracker:* |
| UpdateService | Release-Verteilung, semantischer Versionsvergleich | /api/updateservice/v1/check/api/updateservice/v1/publish |
Lesen offen, Publish braucht updateservice:publish |
| Watchdog | Heartbeat-Monitoring, Zustandsbewertung, Alarmierung | /api/watchdog/v1/ping/api/watchdog/v1/evaluate |
Token mit watchdog:ping |
| Lizenzen | Lizenzprüfung, Hardware-ID v2, Offline-Cache | /api/license/v1/validate/api/license/v1/deactivate |
Validierung offen, Deaktivierung authentifiziert |
| Tokens | Selbst-Provisionierung von Sub-Tokens | /api/tokens/v1/provision |
Master-Token |
| System | Verfügbarkeit, Schema-Status, Schnittstellenbeschreibung | /api/health/api/openapi.json |
Health optional, OpenAPI offen |
Schnittstelle maschinenlesbar
GET https://dc.mhdf.de/api/openapi.json
Ein Agent kann sich daran selbst orientieren — der früher fest im WebUI hinterlegte Textblock entfällt damit.
Antwortformat
Alle JSON-Endpunkte antworten einheitlich:
{ "status": "success", "…": "…" }
{ "status": "error", "error": { "code": "already_claimed", "message": "…" } }
Der code ist stabil und für Programme gedacht; die message richtet sich an
Menschen und kann sich ändern.
Betrieb
| Aufgabe | Befehl |
|---|---|
| Deployment | python scripts/deploy.py |
| Migration | php public/install_db.php oder WebUI → System → DB-Migration |
| Evaluator (Cron, minütlich) | curl -fsS -H "Authorization: Bearer <SHARED_KEY>" https://dc.mhdf.de/api/watchdog/v1/evaluate |
| Zustand prüfen | curl https://dc.mhdf.de/api/health |
| Logs | var/log/dc-<datum>.log auf dem Server |
Aufbau
config/ Zugangsdaten (nicht versioniert), Vorlage in config.example.php
src/ Anwendungscode, PSR-4 unter dem Namensraum Deploymentcenter\
Core/ Bootstrap, Konfiguration, DB, Auth, CSRF, HTTP, Tokens, Migrator
Modules/ Bugtracker, License, UpdateService, Watchdog, Notify
public/ Webroot-Inhalte: WebUI, API-Endpunkte, öffentliche Dokumentation
sql/ Schema und Migrationen (fortlaufend nummeriert)
var/log/ Laufzeitprotokolle
scripts/ Deployment
Neue Klassen werden automatisch geladen, sobald sie dem Namensraum-Pfad
entsprechen — eine require-Zeile ist nicht mehr nötig.