Files
Deploymentcenter/docs
Deploymentcenter BotandClaude Opus 5 8f514eb17a feat(2.9.1): Die Begruendung zieht ins Deploymentcenter, die Datei wird erzeugt
Bis hierher galt eine Zweiteilung: Zustand im Deploymentcenter, Begruendung
in docs/ROADMAP.md, verbunden ueber doc_anchor. Die Beschreibung der
uebernommenen Eintraege sagte es woertlich - "Die Begruendung steht weiterhin
in der Datei - hier steht nur der Zustand."

Zwei Folgen, die erst im Betrieb sichtbar wurden:

1. Die Roadmap-Tafel kann die Begruendung nicht zeigen. Sie sieht die
   Datenbank; die Datei liegt auf einem Entwicklungsrechner. Im Seitenpanel
   stand deshalb nur doc_anchor als nicht anklickbarer Text mit dem Hinweis,
   er zeige auf etwas, das das WebUI nie zu sehen bekommt.

2. Schwerer: Die Beschreibung von dc_roadmap wies Agenten an, vor dem
   erneuten Vorschlagen eines zurueckgestellten Vorhabens "diesen Absatz" zu
   lesen. Ein Agent in polytrader oder clawddotnet kann ihn nicht lesen - er
   liegt in einem fremden Repository. Die Anweisung war nicht befolgbar.

Dazu kam, dass cli/roadmap.php --check PHP braucht und auf dem
Windows-Arbeitsplatz keines liegt: Die Haelfte der Pflegemaschinerie, die die
Zweiteilung zusammenhalten sollte, lief dort nie.

== Was sich aendert ==
bugtracker_items und roadmap_epics tragen rationale (Migration 020). Ein
EIGENES Feld neben description, nicht statt dessen: description sagt, was
gemeldet wurde, und kommt oft von einer fremden Maschine; rationale sagt,
warum wir uns so entschieden haben. Zusammengelegt haette jede redaktionelle
Ueberarbeitung den urspruenglichen Wortlaut der Meldung ueberschrieben, also
die Grundlage, auf der entschieden wurde.

Der Verlauf vermerkt nur, DASS die Begruendung sich geaendert hat und um wie
viele Zeichen. Der ganze Absatz ein zweites Mal im Verlauf haette ihn nach
der fuenften Ueberarbeitung unlesbar gemacht.

== Der Weg herauf, einmalig ==
?action=import_rationale liest eine mitgeschickte Roadmap-Datei. Drei Formen
werden erkannt: Bereichsabschnitte, Vorhabensabschnitte und Tabellenzeilen.
Die dritte ist kein Beiwerk - der Abschnitt "Verworfen" fuehrt seine zwoelf
Ablehnungen als Tabelle, und ohne sie bliebe ausgerechnet das nicht am Item
auffindbar, was am haeufigsten gebraucht wird: warum etwas schon einmal
abgelehnt wurde. Ohne overwrite=true bleibt stehen, was im DC schon steht.

== Der Weg herunter, dauerhaft ==
Ein zweites Markerpaar dc:rationale neben dc:roadmap. Bewusst ein zweites und
keine Erweiterung des ersten: Zwischen den beiden steht in jeder gewachsenen
Roadmap-Datei Handgeschriebenes - Einleitung, Leitlinie, Statuszeichen -, und
ein einziger Block haette das beim naechsten Erzeugen verschluckt.
?action=render_file setzt beide Bloecke serverseitig ein, damit die
Markersuche nur einmal umgesetzt ist. Sie hat eine Feinheit, die zweimal
umgesetzt zweimal verschieden waere: Ein im Fliesstext ERWAEHNTER Marker darf
nicht gefunden werden - die Einleitung dieser Datei erwaehnt jetzt beide.

== Werkzeuge ==
scripts/dc.py roadmap-import und roadmap-write, in Python und nicht in
cli/roadmap.php - sonst waeren sie auf dem Arbeitsplatz wieder nicht
aufrufbar. roadmap-write behaelt die Zeilenenden der Datei bei.

== Bestand ==
35 Vorhaben und 6 Bereiche aus docs/ROADMAP.md uebernommen, 476 Zeilen
handgepflegte Prosa durch den erzeugten Block ersetzt. Gegengeprueft auf
Wortebene: Aus dem Fliesstext fehlt nichts, die einzigen Abweichungen sind
die ersetzten Ueberschriften und die alte Einleitung.

Kaertchen ohne hinterlegte Begruendung tragen auf der Tafel eine dezente
Marke - erledigte nicht, dort waere sie ein Vorwurf ohne Adressaten.

MCP-Adapter auf 1.3.0: dc_roadmap_set nimmt rationale, und die Beschreibung
von dc_roadmap verweist nicht mehr auf eine Datei, die der Agent nicht
erreichen kann.

Geprueft: 7 neue Testfaelle, Suite gesamt 179 von 179.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-20 18:59:06 +02:00
..

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
ROADMAP.md Der eine Ort für alles Geplante, Zurückgestellte und bewusst Verworfene. Ab 2.7.0 gilt die Arbeitsteilung: Zustand im Deploymentcenter (WebUI → Roadmap, dc_roadmap), Begründung hier.
ROADMAP_MIGRATION.md Eine vorhandene ROADMAP.md oder TODO.md ins Deploymentcenter überführen. Einmalig je Projekt, sechs Schritte. Für die Agenten der angebundenen Projekte.
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
Linux-Testumgebung Die geteilte Test-VM. Wie ein Agent dort selbständig testet: DEV-Lizenz holen, Auslieferung prüfen, Befunde melden — mit dc-testkit
Testinstanz & automatisierter Testlauf dc-dev.mhdf.de — die zweite Installation zum Kaputtmachen. 136 Fälle gegen API, Rechte, Migrationen und Zugangssperre (tests/e2e/run.py). scripts/deploy.py führt sie vor jedem Produktiv-Upload aus und bricht bei Fehlschlägen ab (--ohne-test umgeht das)
Agenten anbinden Was einmalig je Projekt zu tun ist, damit ein Agent Bugtracker, Roadmap und MCP sinnvoll benutzt: Token, Adapter, Bausteine, Roadmap-Übernahme — mit Prüffragen am Ende
Agent-Prompt-Vorlage Die Textbausteine selbst. A Grundhaltung (immer), B mit MCP, C ohne MCP, D Test-VM — nicht alles einkopieren
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
  • Supervisor — Befunde: was ist ungewöhnlich? Läuft serverseitig auf ohnehin eingehenden Daten, ohne Einbau in die Anwendungen. Enthält auch den Rückbau begonnener Vorbereitungen
  • MCP-Adapter — Claude Code und Claude Desktop an Bugtracker, Roadmap und Supervisor anschließen — 15 Werkzeuge, 4 Ressourcen, 4 Prompts

Hintergrund zu Supervisor und MCP, inklusive der Frage, warum der Client keinen Quelltext sieht: archiv/SUPERVISOR_MCP_DESIGN.md — archiviert, die Herleitung gilt weiter, der Stand steht in der Roadmap.


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
Supervisor Befunde: was ist ungewöhnlich? Fünf Detektoren laufen serverseitig im Tick und brauchen keine Client-Änderung /api/supervisor/v1/observe
/api/supervisor/v1/findings
/api/supervisor/v1/catalog
Melden supervisor:report, Lesen supervisor:read, Einstufen supervisor:manage
Lizenzen Lizenzprüfung, Hardware-ID v2, Offline-Cache, befristete DEV-Schlüssel zur Selbstbedienung /api/license/v1/validate
/api/license/v1/deactivate
/api/license/v1/dev-key
Validierung offen, Deaktivierung authentifiziert, DEV-Schlüssel license:dev
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.


Drosselung

Je IP und Minute. Wird die Grenze überschritten, antwortet der Endpunkt mit 429 rate_limited — dann das Intervall verdoppeln und später erneut versuchen, nicht sofort wiederholen.

Endpunkt Grenze Einstellbar über
/api/errors/v1/report 300 bugtracker.error_rate
/api/bugtracker/v1/report 60 bugtracker.report_rate
/api/supervisor/v1/observe 120 supervisor.observe_rate
/api/license/v1/* 120 fest
/api/license/v1/dev-key 10 fest — ein Schlüssel je Testlauf, nicht je Sekunde
/api/updateservice/v1/* 240 fest
/api/setup/v1/login 10 fest — dort werden Passwörter geprüft
/api/tokens/v1/provision 20 fest

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,
             ProjectLinks (welches Projekt nutzt welches, in welcher Fassung)
  Modules/   Bugtracker, License, Supervisor, UpdateService, Watchdog, Notify
public/    Webroot-Inhalte: WebUI, API-Endpunkte, öffentliche Dokumentation,
           testkit/dc-testkit.sh (das Werkzeug für die Linux-Test-VM)
sql/       Schema und Migrationen (fortlaufend nummeriert)
var/log/   Laufzeitprotokolle
scripts/   Deployment
mcp/       MCP-Adapter für Claude Code — eine Datei, keine Abhängigkeiten
client-dotnet/ Client-SDK: Lizenz, Update, Setup

Der Supervisor läuft ausschließlich hier — an den Detektoren in Modules/Supervisor/ServerDetectors.php im minütlichen Tick mit (gedrosselt auf zehn Minuten). Er arbeitet auf Daten, die ohnehin hereinkommen — Fehlerberichte, Heartbeats, Kennzahlen — und braucht dafür keine Änderung an den Anwendungen.

Neue Klassen werden automatisch geladen, sobald sie dem Namensraum-Pfad entsprechen — eine require-Zeile ist nicht mehr nötig.