Files

T

Deploymentcenter BotandClaude Opus 5 a8b9f6f7c9 feat(docs): Changelog mit "was ist seit meiner Fassung neu"

Bisher musste ein Agent, der eine Anbindung aktualisiert, die gesamte Historie
lesen - oder er las gar nichts und uebersah eine brechende Aenderung. Beides
schlecht.

- public/docs/changelog.json ist die einzige Quelle. Je Fassung eine
  Zusammenfassung, je Aenderung Bereich, ein "breaking"-Kennzeichen und vor
  allem ein Feld "action" mit dem, was konkret zu tun ist. Steht dort null,
  ist nichts zu tun - das ist die haeufigste und nuetzlichste Antwort.
- GET /api/updateservice/v1/changelog?since=2.2.0 liefert nur die neueren
  Fassungen, dazu die Anzahl der Punkte mit Handlungsbedarf und der
  brechenden Aenderungen. count:0 heisst "du bist auf Stand" - dann muss gar
  nichts gelesen werden. Optional nach Bereich filterbar (?area=packager).
- /docs/changelog.php rendert dieselbe Datei fuer Menschen, mit Eingabefeld
  fuer die eigene Fassung. Bewusst dieselbe Quelle: zwei Fassungen zu pflegen
  hiesse, sie auseinanderlaufen zu lassen.
- DeploymentcenterSdk.Version im SDK ist der Bezugspunkt. Damit muss die
  Fassung nicht abgetippt werden.
- AGENT_PROMPT_TEMPLATE.md verpflichtet dazu, sie in der AGENTS.md des
  Projekts festzuhalten und vor jeder Aenderung an der Anbindung den
  Unterschied abzufragen. Auch in der Kurzfassung fuer knappe Prompt-Budgets.

Die Historie ist rueckwirkend bis 2.0.0 gefuellt: 6 Fassungen, 25 Punkte mit
Handlungsbedarf, 13 brechende Aenderungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-14 16:45:50 +02:00

4.4 KiB

Raw Blame History

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.
Änderungen	Was sich je Fassung geändert hat und was zu tun ist. Öffentlich unter `/docs/changelog.php`, maschinenlesbar über `GET /api/updateservice/v1/changelog?since=X`
Release-Anleitung für Agenten	Ein Projekt veröffentlichungsfähig machen: Vorlage kopieren, konfigurieren, ausliefern
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
Erstinstallation — setup.json, Installationskonto, update-agent --action install
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
Setup	Erstinstallation: Anmeldung, Katalog, Anwendungstoken	`/api/setup/v1/login` `/api/setup/v1/catalog` `/api/setup/v1/token`	Login offen, Rest `setup:*`
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.

4.4 KiB Raw Blame History