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>
59 lines
2.2 KiB
Plaintext
59 lines
2.2 KiB
Plaintext
# ======================================================================
|
|
# Zugangssperre der Testinstanz
|
|
#
|
|
# Dieser Block wird von scripts/deploy_dev.py der Repo-.htaccess
|
|
# VORANGESTELLT und nur auf die Testinstanz hochgeladen. Die Produktion
|
|
# bekommt ihn nie zu sehen, deshalb steht er hier und nicht in der
|
|
# .htaccess selbst.
|
|
#
|
|
# Warum ueberhaupt: Die Testinstanz laeuft mit app.debug = true, mit
|
|
# Beispieldaten und mit einem Datenbestand, den jeder Testlauf loeschen
|
|
# darf. Nichts davon gehoert ins offene Netz - weder fuer Menschen noch
|
|
# fuer Suchmaschinen.
|
|
#
|
|
# Die Ausnahme fuer /api/ mit Token: Ohne sie muesste jedes SDK und jedes
|
|
# Testskript zusaetzlich zu seinem Token auch noch die Basic-Auth-Daten
|
|
# kennen. Damit wuerde die Testinstanz etwas anderes pruefen als die
|
|
# Produktion - naemlich einen Aufrufweg, den es dort nicht gibt. Die
|
|
# Ausnahme greift nur unterhalb von /api/ und nur, wenn ein Token-Header
|
|
# ueberhaupt vorhanden ist; geprueft wird er weiterhin von ApiAuth und
|
|
# TokenManager. Sie oeffnet also nichts, was auf dc.mhdf.de nicht ohnehin
|
|
# offen waere. WebUI, Installer und /docs/ bleiben in jedem Fall hinter
|
|
# der Basic-Auth.
|
|
#
|
|
# %DOCROOT% wird beim Deployment ersetzt.
|
|
# ======================================================================
|
|
|
|
<IfModule mod_setenvif.c>
|
|
SetEnvIfNoCase Request_URI "^/api/" DC_IS_API
|
|
SetEnvIf X-Agent-Token "." DC_HAS_TOKEN
|
|
SetEnvIf X-Master-Token "." DC_HAS_TOKEN
|
|
SetEnvIf X-License-Key "." DC_HAS_TOKEN
|
|
SetEnvIf X-Watchdog-Key "." DC_HAS_TOKEN
|
|
SetEnvIf Authorization "^Bearer\s+\S" DC_HAS_TOKEN
|
|
</IfModule>
|
|
|
|
AuthType Basic
|
|
AuthName "Deploymentcenter Testinstanz"
|
|
AuthUserFile %DOCROOT%/config/.htpasswd
|
|
|
|
<IfModule mod_authz_core.c>
|
|
<RequireAny>
|
|
Require valid-user
|
|
<RequireAll>
|
|
Require env DC_IS_API
|
|
Require env DC_HAS_TOKEN
|
|
</RequireAll>
|
|
</RequireAny>
|
|
</IfModule>
|
|
<IfModule !mod_authz_core.c>
|
|
Require valid-user
|
|
Order allow,deny
|
|
Allow from env=DC_HAS_TOKEN
|
|
Satisfy any
|
|
</IfModule>
|
|
|
|
# Ab hier folgt unveraendert die .htaccess aus dem Repository.
|
|
# ======================================================================
|
|
|