Deploymentcenter BotandClaude Opus 5
1d5ac92051
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>
43 lines
1.9 KiB
Markdown
43 lines
1.9 KiB
Markdown
# Archiv
|
||
|
||
Abgelöste Entwurfs- und Planungsdokumente.
|
||
|
||
**Diese Dateien beschreiben keinen gültigen Stand mehr.** Sie werden
|
||
aufbewahrt, weil sie die ausführliche Herleitung enthalten — warum eine
|
||
Entscheidung so und nicht anders getroffen wurde, welche Alternativen geprüft
|
||
und aus welchem Grund verworfen wurden. Diese Begründungen sind zu wertvoll zum
|
||
Wegwerfen und zu lang für die Roadmap.
|
||
|
||
**Der gültige Stand steht in [../ROADMAP.md](../ROADMAP.md).**
|
||
|
||
Wer hier etwas liest, sollte jeden Punkt gegen die Roadmap prüfen, bevor er
|
||
danach handelt. Die Erfahrung, die zu diesem Archiv geführt hat: In
|
||
`SUPERVISOR_MCP_DESIGN.md` stand eine Liste offener Punkte, die der Code längst
|
||
erledigt hatte — ein Agent hat sie gelesen und daraufhin Arbeit vorgeschlagen,
|
||
die es nicht mehr gab.
|
||
|
||
---
|
||
|
||
| Dokument | Ursprung | Was daraus wurde |
|
||
|---|---|---|
|
||
| [SUPERVISOR_MCP_DESIGN.md](./SUPERVISOR_MCP_DESIGN.md) | Entwurf für Supervisor, Detektor-Katalog und MCP-Anbindung, geschrieben vor der Umsetzung | Etappen 1–3 sind in 2.6.0 ausgeliefert. Der Etappenplan, die offenen Punkte und die verworfenen Ansätze sind in die Roadmap übernommen. Hier steht weiterhin die vollständige Begründung — besonders Abschnitt 0 (warum Beobachtung und Urteil getrennt sind) und Abschnitt 7 (warum der Client keinen Quelltext sieht) |
|
||
|
||
---
|
||
|
||
## Nicht archiviert
|
||
|
||
Die Integrationsanleitungen in `../` sind **kein** Archiv. Sie beschreiben,
|
||
wie eine Anwendung heute anzubinden ist, werden von den Agenten in den anderen
|
||
Projekten gelesen und bleiben dort, wo sie sind:
|
||
|
||
- `SUPERVISOR_INTEGRATION_GUIDE.md`
|
||
- `BUGTRACKER_INTEGRATION_GUIDE.md`
|
||
- `LICENSE_INTEGRATION_GUIDE.md`
|
||
- `SETUP_INTEGRATION_GUIDE.md`
|
||
- `UPDATESERVICE_INTEGRATION_GUIDE.md`
|
||
- `WATCHDOG_INTEGRATION_GUIDE.md`
|
||
|
||
Ebenso bleibt `UPGRADE.md`: ein Ablaufplan für die Umstellung bestehender
|
||
Installationen. Er beschreibt Vergangenes, wird aber weiterhin gebraucht, wenn
|
||
jemand von einer älteren Fassung kommt.
|