Deploymentcenter

41 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Deploymentcenter BotandClaude Opus 5	1d5ac92051	feat(2.7.0): Roadmap im DC, Testinstanz mit Testtor, Supervisor und MCP Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere lauffaehig. ROADMAP IM DEPLOYMENTCENTER (2.7.0) Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit. Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger. - Migration 016: epic, roadmap_rank, target_build, defer_trigger, doc_anchor, Status "deferred", Tabelle roadmap_epics. KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item. - Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen. - Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil die Kennung nach einer Loeschung neu vergeben wurde. - Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im Repository, damit sie auf allen drei Schreibwegen gleich greift. - Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php, WebUI-Modul mit Filtern, cli/roadmap.php --write/--check, dc_roadmap und dc_roadmap_set im MCP-Adapter. - cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei; --check prueft nur die Prosa. Was erzeugt wird, kann nicht driften. - docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte. TESTINSTANZ UND TESTTOR - dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel, Basic-Auth davor, Rocket.Chat aus. - 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre. - scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf die Testinstanz und laesst dann den Testlauf laufen. Erst bei Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang). Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht. - tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann nicht versehentlich auf dc.mhdf.de landen. - Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch nicht - der Unterschied darf nicht am Rueckgabewert verschwinden. SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1) - Migration 013: projektuebergreifend melden (dev_agent, evidence, triage_external, affects). - Migration 014: supervisor_findings, Katalog, fuenf serverseitige Detektoren im Tick. - Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung. - DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM. - MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung von Fremddaten gegen Prompt-Injektion. BEHOBEN - observe und status im Supervisor legten den Zustand des Befundes als "status" in die Antwort. Http::ok() merged ['status' => 'success'] darunter, also gewann der Befundzustand - eine angenommene Meldung kam als status="open" an. Heisst jetzt finding_status. War Item #59. Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt. Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf gegen bugtracker_items.epic abfragt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 21:59:20 +02:00
Deploymentcenter BotandClaude Opus 5	f8771c8d1b	fix(guard): Zugangsschutz je Produkt abschaltbar, Dienst-Betrieb, Buildzeiten Sieben Rueckmeldungen aus einer laufenden Integration. Der schwerwiegendste Punkt ist ein Fehler von mir. D2 - Predictalytics ist ausgesperrt. Bestaetigt: /releases/predictalytics/ antwortet mit 401, waehrend die API weiter "Update verfuegbar" meldet. Jede ausgelieferte Installation laeuft damit in die Wand. Ursache ist nicht der Schutz an sich, sondern dass ich ihn scharfgeschaltet habe, ohne zu pruefen, ob die Verbraucher nachgezogen sind - genau der Fall, vor dem UPGRADE §16.1 warnt. Behoben wird die Klasse des Problems, nicht nur dieser Fall: Produkte lassen sich unter UpdateService -> Zugangsschutz einzeln ausnehmen. Damit ist der gestaffelte Rollout moeglich, der bisher fehlte: ausnehmen, Build mit Schluessel ausliefern, wieder einschalten. Ausgenommene Produkte sind in der Uebersicht deutlich als AUSGENOMMEN markiert und faerben den Selbsttest nicht gruen. D5 - BuildInfo.targets verhinderte inkrementelle Builds. BuildDateUtc trug die volle Uhrzeit, aenderte sich also bei jedem Build; WriteOnlyWhenDifferent griff nie, und jedes einbindende Projekt wurde jedes Mal neu uebersetzt. Jetzt tagesgenau. Das Commit-Datum waere stabiler, laesst sich aber nicht verlaesslich holen - die Formatangabe von git log ueberlebt MSBuild und cmd.exe nicht, wie ein Fehlversuch gezeigt hat. D4 - LicenseConfig war uneinheitlich und fuer Dienste unbrauchbar. SetStorageDirectory benutzte den Pfad roh, waehrend der Weg ueber die Umgebungsvariable <slug>/license anhaengte: zwei Produkte im selben Prozess schrieben in dieselbe state.dat. Und ohne $HOME - systemd User= ohne Heimatverzeichnis - landete der Rueckfall im Installationsverzeichnis, unter /opt nicht beschreibbar. Neu: einheitliches Anhaengen und ein Rueckfall auf /var/lib/<slug>, der vorher prueft, ob dort ueberhaupt geschrieben werden kann. D1 - Woher die Anwendung den Lizenzschluessel fuer den Update-Zugang nimmt, stand nirgends zusammenhaengend. Jetzt ein Beispiel in UPDATESERVICE §5A, das TryGetCachedKey und CheckForUpdateAsync verbindet. D3 - Fuer einen laufenden systemd-Dienst gab es keinen Update-Weg. Neu: SETUP §4A mit einer oneshot-Unit, die stoppt, aktualisiert und wieder startet - ohne --restart, weil der Agent sonst an systemd vorbei einen zweiten Prozess startet. Inklusive EnvironmentFile fuer den Schluessel und dem Hinweis auf die Dateirechte nach einem Lauf als root. D6 - Die Empfehlung Environment.Exit(1) passt fuer handelnde Systeme nicht. Ein neuer Abschnitt im Lizenz-Leitfaden beschreibt den Sperrbetrieb: abschalten, was neue Verpflichtungen eingeht; weiterlaufen lassen, was bestehende abwickelt. D7 - Die Drosselungsgrenzen aller Endpunkte stehen jetzt in docs/README.md. /api/errors/v1/report erlaubt 300 pro Minute, nicht 60; die Einstellung bugtracker.error_rate fehlte in der Beispielkonfiguration. Der zweite Teil des Befunds war veraltet: docs/README.md fuehrt die Release-Anleitung bereits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-14 21:41:53 +02:00
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

Author

SHA1

Message

Date

Deploymentcenter BotandClaude Opus 5

1d5ac92051

feat(2.7.0): Roadmap im DC, Testinstanz mit Testtor, Supervisor und MCP

Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht
eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es
nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen
Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere
lauffaehig.

ROADMAP IM DEPLOYMENTCENTER (2.7.0)

Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten
Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits
fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit.

Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger.

  - Migration 016: epic, roadmap_rank, target_build, defer_trigger,
    doc_anchor, Status "deferred", Tabelle roadmap_epics.
    KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item.
  - Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein
    epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen.
  - Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die
    schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil
    die Kennung nach einer Loeschung neu vergeben wurde.
  - Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein
    Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im
    Repository, damit sie auf allen drei Schreibwegen gleich greift.
  - Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php,
    WebUI-Modul mit Filtern, cli/roadmap.php --write/--check,
    dc_roadmap und dc_roadmap_set im MCP-Adapter.
  - cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei;
    --check prueft nur die Prosa. Was erzeugt wird, kann nicht driften.
  - docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte.

TESTINSTANZ UND TESTTOR

  - dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel,
    Basic-Auth davor, Rocket.Chat aus.
  - 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre.
  - scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf
    die Testinstanz und laesst dann den Testlauf laufen. Erst bei
    Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang).
    Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht.
  - tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann
    nicht versehentlich auf dc.mhdf.de landen.
  - Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit
    Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch
    nicht - der Unterschied darf nicht am Rueckgabewert verschwinden.

SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1)

  - Migration 013: projektuebergreifend melden (dev_agent, evidence,
    triage_external, affects).
  - Migration 014: supervisor_findings, Katalog, fuenf serverseitige
    Detektoren im Tick.
  - Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung.
  - DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM.
  - MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung
    von Fremddaten gegen Prompt-Injektion.

BEHOBEN

  - observe und status im Supervisor legten den Zustand des Befundes als
    "status" in die Antwort. Http::ok() merged ['status' => 'success']
    darunter, also gewann der Befundzustand - eine angenommene Meldung kam
    als status="open" an. Heisst jetzt finding_status. War Item #59.

Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt.
Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf
gegen bugtracker_items.epic abfragt.

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

2026-08-29 21:59:20 +02:00

Deploymentcenter BotandClaude Opus 5

f8771c8d1b

fix(guard): Zugangsschutz je Produkt abschaltbar, Dienst-Betrieb, Buildzeiten

Sieben Rueckmeldungen aus einer laufenden Integration. Der schwerwiegendste
Punkt ist ein Fehler von mir.

D2 - Predictalytics ist ausgesperrt. Bestaetigt: /releases/predictalytics/
antwortet mit 401, waehrend die API weiter "Update verfuegbar" meldet. Jede
ausgelieferte Installation laeuft damit in die Wand. Ursache ist nicht der
Schutz an sich, sondern dass ich ihn scharfgeschaltet habe, ohne zu pruefen,
ob die Verbraucher nachgezogen sind - genau der Fall, vor dem UPGRADE §16.1
warnt.
Behoben wird die Klasse des Problems, nicht nur dieser Fall: Produkte lassen
sich unter UpdateService -> Zugangsschutz einzeln ausnehmen. Damit ist der
gestaffelte Rollout moeglich, der bisher fehlte: ausnehmen, Build mit
Schluessel ausliefern, wieder einschalten. Ausgenommene Produkte sind in der
Uebersicht deutlich als AUSGENOMMEN markiert und faerben den Selbsttest nicht
gruen.

D5 - BuildInfo.targets verhinderte inkrementelle Builds. BuildDateUtc trug die
volle Uhrzeit, aenderte sich also bei jedem Build; WriteOnlyWhenDifferent griff
nie, und jedes einbindende Projekt wurde jedes Mal neu uebersetzt. Jetzt
tagesgenau. Das Commit-Datum waere stabiler, laesst sich aber nicht
verlaesslich holen - die Formatangabe von git log ueberlebt MSBuild und cmd.exe
nicht, wie ein Fehlversuch gezeigt hat.

D4 - LicenseConfig war uneinheitlich und fuer Dienste unbrauchbar.
SetStorageDirectory benutzte den Pfad roh, waehrend der Weg ueber die
Umgebungsvariable <slug>/license anhaengte: zwei Produkte im selben Prozess
schrieben in dieselbe state.dat. Und ohne $HOME - systemd User= ohne
Heimatverzeichnis - landete der Rueckfall im Installationsverzeichnis, unter
/opt nicht beschreibbar. Neu: einheitliches Anhaengen und ein Rueckfall auf
/var/lib/<slug>, der vorher prueft, ob dort ueberhaupt geschrieben werden kann.

D1 - Woher die Anwendung den Lizenzschluessel fuer den Update-Zugang nimmt,
stand nirgends zusammenhaengend. Jetzt ein Beispiel in UPDATESERVICE §5A, das
TryGetCachedKey und CheckForUpdateAsync verbindet.

D3 - Fuer einen laufenden systemd-Dienst gab es keinen Update-Weg. Neu:
SETUP §4A mit einer oneshot-Unit, die stoppt, aktualisiert und wieder startet -
ohne --restart, weil der Agent sonst an systemd vorbei einen zweiten Prozess
startet. Inklusive EnvironmentFile fuer den Schluessel und dem Hinweis auf die
Dateirechte nach einem Lauf als root.

D6 - Die Empfehlung Environment.Exit(1) passt fuer handelnde Systeme nicht. Ein
neuer Abschnitt im Lizenz-Leitfaden beschreibt den Sperrbetrieb: abschalten,
was neue Verpflichtungen eingeht; weiterlaufen lassen, was bestehende abwickelt.

D7 - Die Drosselungsgrenzen aller Endpunkte stehen jetzt in docs/README.md.
/api/errors/v1/report erlaubt 300 pro Minute, nicht 60; die Einstellung
bugtracker.error_rate fehlte in der Beispielkonfiguration. Der zweite Teil des
Befunds war veraltet: docs/README.md fuehrt die Release-Anleitung bereits.

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

2026-08-14 21:41:53 +02:00

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