c9c821a44a079ec29bff59416e5b03637c788f89
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Deploymentcenter BotandClaude Opus 5
|
c9c821a44a |
fix(webui): Ansichtsrettung suchte am falschen Ort, Suche findet Nummern
#288 war mit dem Transport allein nicht behoben. Die Ansichtsrettung fragte dokumentweit nach der offenen Unteransicht: document.querySelector('.subtab-content.active') Im Markup tragen aber ACHT Unteransichten diese Klasse - jedes Modul hat seine eigene Startansicht, und switchMainTab() raeumt nur innerhalb des Moduls auf, das es oeffnet. Zurueck kam deshalb immer die erste in Dokumentreihenfolge (sub-projects-list), voellig unabhaengig davon, was gerade sichtbar war. Wer im Bugtracker filterte, waere also auf der Projektverwaltung gelandet. Dass die Rettung fuer POST-Formulare zu funktionieren schien, lag an den wenigen, die ihren Anker fest in der action stehen haben. Gesucht wird jetzt erst das aktive Modul und darin die Unteransicht. Zusaetzlich tragen die drei Filterformulare das Feld "view" fest im Markup. Dort ist ohne Zweifel bekannt, wo sie stehen - das haengt an keiner DOM-Abfrage mehr. Und restoreViewFromHash() faellt bei einer unbekannten Unteransicht auf das Modul zurueck, statt wortlos im Dashboard zu landen. Nachgewiesen an einer DOM-Probe, die die Modulstruktur aus index.php nachbaut und die echten Funktionen darauf laufen laesst: alte Fassung -> tab-projects, neue Fassung -> sub-bugtracker-items. Ausserdem, aus derselben Sitzung gemeldet: Die Suche findet Eintraege jetzt ueber ihre Nummer. Sie ist das, was ueberall zitiert wird, und stand in keiner der durchsuchten Spalten - "288" lief ins Leere. "288" findet jetzt das Item mit dieser Nummer und alles, was die Zahl im Text hat; "#288" ausschliesslich dieses eine. Gilt fuer Bugtracker, Fehler-Stream und den Parameter search der API, der bei der Gelegenheit auch in die OpenAPI-Beschreibung gekommen ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
0c1d269665 |
test(e2e): whoami absichern und die gemeldete Fassung festnageln
Vier Faelle, die genau die Fehler wiederfinden wuerden, um die es in 2.7.1 ging: - whoami nennt Bindung und Rechte, und zwar dieselben, die provisioniert wurden - whoami gibt den Klartextwert des Tokens nicht heraus. Eine Auskunft ueber ein Token darf das Token nicht weiterreichen - whoami ohne Token antwortet 401 - Health meldet dieselbe Fassung, die changelog.json fuehrt. Das ist der Fall, der #346 nicht wiederkommen laesst: Ein fester Wert in der Konfiguration faellt sonst niemandem auf, weil die Datei gitignored ist Ausserdem: Wird der Shared Key an whoami geschickt, sagt der Endpunkt das jetzt (not_a_token) statt "Token unbekannt". Der Shared Key ist kein Token - er hat weder Bindung noch Rechteliste, und ohne den Hinweis sucht der Aufrufer den Fehler bei seinem Token. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
57aa0bc5be |
feat(tokens): Master-Tokens nachtraeglich bearbeiten
Bisher erzwang jede Korrektur ein neues Token: ein Schreibfehler im Namen, ein
falsch gewaehlter Identitaetstyp, ein nachtraeglich gebrauchtes Recht. Das ist
nicht nur laestig, sondern gefaehrlich - der neue Wert muss auf alle Maschinen
verteilt werden, und am Ende laeuft das alte weiter, weil eine vergessen wurde.
AENDERBAR ist alles ausser dem Tokenwert selbst, der Nummer, dem Typ und dem
Anlagedatum: Name, Identitaetstyp, freie Identitaet, Projekt, Lizenzschluessel,
Umgebung, Ablaufdatum und die Rechte.
Der Wert bleibt unberuehrt, weil er es muss - er liegt nur als Hash vor und
steht auf fremden Maschinen. Ein "geaenderter" Wert waere ein neues Token mit
alter Nummer. Genau diese Zusage haelt ein eigener Testfall fest: derselbe rohe
Token muss nach der Aenderung weiter funktionieren.
- TokenManager::updateMasterToken() mit zwei Schranken: leerer Name und
leere Rechteliste werden abgewiesen. Ein Token ohne Rechte sieht gueltig
aus und laesst jeden Aufruf mit "unauthorized" scheitern, ohne dass der
Grund sichtbar waere.
- Was sich geaendert hat, geht ins Log. Eine stille Rechteaenderung an einem
Token ist genau das, was man spaeter rekonstruieren will.
- Dialog in der Token-Verwaltung, erreichbar ueber den Stift in der Zeile.
Zeigt Nummer und Hinweis, dass der Wert unveraendert bleibt.
- Haengen Sub-Tokens daran, sagt der Dialog, dass eine Einschraenkung NICHT
rueckwirkend auf sie durchschlaegt - sie haben ihre Rechte beim Ausstellen
bekommen. Wer die Kinder beschneiden will, widerruft und stellt neu aus.
$scopeChoices ist aus dem Anlegeformular in den Datenteil gewandert. Beide
Formulare lesen jetzt dieselbe Liste - eine an zwei Stellen gefuehrte Liste
haette genau den Fehler wiederholt, der eben erst behoben wurde: Die
Supervisor-Rechte fehlten monatelang im Formular, obwohl TokenManager sie kennt.
Testlauf 136 Faelle. Da die Bearbeitung bewusst keine API hat - ein Token soll
seine eigenen Rechte nicht erweitern koennen - fuehrt der Weg dorthin ueber
testctl.php?action=update_master_token, wie schon beim Werkbank-Token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
c9bad697e5 |
feat(roadmap): Roadmap des Deploymentcenters uebernommen (I9)
61 Eintraege aus docs/ROADMAP.md stehen jetzt als Items im Deploymentcenter:
17 offen, 24 erledigt, 7 zurueckgestellt, 13 verworfen. Keine Waisen, jedes
Item mit doc_anchor. Der Abgleich laeuft ohne Befund durch.
Die Datei behaelt, was eine Tabellenzelle nicht traegt: die Begruendungen.
Der Zustand steht zwischen dc:roadmap-Markern und wird erzeugt.
- scripts/roadmap_import.py: wertet die Datei aus und uebertraegt sie.
Wiederholbar ueber client_ref, legt fehlende Themenbereiche an, wartet
bei Drosselung. Die Prioritaet liest es aus dem Abschnitt "Als
Naechstes" - solange die Datei die Quelle ist, soll auch die Prioritaet
von dort kommen.
- docs/ROADMAP.md: Statustabellen raus, erzeugter Block rein,
21 Ueberschriften und 14 Querverweise auf Item-Nummern umgestellt,
Abschnitt H mit Item-Nummern versehen.
WAS DIE UEBERNAHME ZUTAGE FOERDERTE
- G8 war zweimal vergeben: einmal offen, einmal erledigt. Genau die
Kollision handvergebener Kennungen, gegen die der Entwurf argumentiert.
Beide sind eigene Items.
- Bereich H fehlte in roadmap_epics - Migration 016 hatte nur A-G und I
gesetzt. Die Waisenerkennung meldete es. Das Importskript legt fehlende
Bereiche jetzt an, ueberschreibt aber keine vorhandenen: Ein
Uebernahmeskript darf anlegen, kuratierte Angaben nicht ueberschreiben.
- "Item #42" stand als erfundenes Beispiel im Rueckkanal-Absatz - und #42
gibt es wirklich, in predictalytics. Der Abgleich hat es gemeldet, ein
Mensch haette es nie bemerkt.
- Vier Marker waren veraltet (E1, E2, I8, D1).
BEHOBEN: spliceBlock() zerstoerte Dateien, die den Marker erwaehnen
strpos() nahm die erste Fundstelle von "<!-- dc:roadmap". Erwaehnt eine Datei
den Marker im Fliesstext - und die Einleitung einer ordentlichen Roadmap tut
genau das - setzte der Splice dort an und ueberschrieb den halben Dateikopf.
check() klammerte aus demselben Grund Prosa aus statt des Blocks.
Es trifft also ausgerechnet die Dateien, die das Verfahren beschreiben. Der
echte Block wird jetzt am Zeilenanfang samt "stand=" erkannt; das Blockende
wird ab dem Anfang gesucht, nicht ab Dateibeginn.
BEHOBEN: IPv6-Erkennung im Testlauf war launisch
erreichbar() prueft seit jeher IPv6 mit einem blossen connect(). Auf dieser
Strecke gelingt der Verbindungsaufbau zeitweise, waehrend danach nichts mehr
fliesst - der Lauf blieb dann auf IPv6 und jede Anfrage lief 21 Sekunden in
einen Timeout. Weil es launisch war, sah es mal nach einem Haenger und mal
nach einem sauberen Lauf aus. Geprueft wird jetzt bis zur Antwort:
TLS-Handschlag und ein HTTP-HEAD.
WebUI: Verweise im Inhalt hatten keine Farbregel und erschienen im
Browservorgabeblau auf schwarzem Grund. Der Bereichsverweis der Roadmap
springt ausserdem auf die Liste statt auf die Uebersicht - dort wirkt der
Filter, den er setzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
8b6d6a307e |
feat(mcp): Ressourcen und Prompts fuer Claude Desktop, zwei Befunde behoben
MCP-ADAPTER 1.1
Werkzeuge ruft ein Modell von sich aus auf - Ressourcen und Prompts waehlt ein
MENSCH. In Claude Desktop sind das Anhang-Menue und Schraegstrich-Befehle, und
genau die fehlten.
- Vier Ressourcen: dc://roadmap (fertiger Markdown-Block),
dc://naechste-schritte, dc://projekte, dc://befunde.
- Vier Prompts: arbeit-aufnehmen, befunde-sichten, fehler-melden,
roadmap-pflegen. Ihr Wert liegt nicht in der gesparten Tipparbeit, sondern
darin, dass die Hausregeln mitkommen - erst nachsehen wer dransitzt,
Fremdmeldung nur mit Begruendung, Verworfenes nicht ohne neues Argument
wiedervorschlagen. Bisher standen die nur in Werkzeugbeschreibungen, und
die liest ein Modell erst, wenn es das Werkzeug schon gewaehlt hat.
- DC_PROJECT: worauf die Ressourcen zeigen. Werkzeuge nehmen project_slug je
Aufruf, Ressourcen haben keine Argumente.
- Ressourcen laufen durch dieselbe Fremddaten-Abgrenzung wie
Werkzeugergebnisse - sie sind eher ein Einfallstor, weil sie ungefragt im
Kontext landen.
- Einrichtung fuer claude_desktop_config.json dokumentiert.
Behoben: "initialize" spiegelte die verlangte Protokollfassung zurueck. Ein
Client, der 2025-06-18 anfragte, bekam sie bestaetigt, obwohl der Adapter
fuer 2024-11-05 geschrieben war. Jetzt wird gegen eine Liste tatsaechlich
bedienter Fassungen ausgehandelt.
Behoben: process.exit() mitten in schliessenden libuv-Handles. Unter Windows
eine Assertion und Rueckgabewert != 0 - ein sauber beendeter Server sah aus
wie ein abgestuerzter.
ZWEI BEFUNDE, DIE ERST DIE RESSOURCEN ZUTAGE FOERDERTEN
- roadmap.php?action=render lehnte fuer ein Werkbank-Token mit
"missing_project" ab. projectFilter() laesst es beim Lesen bewusst durch
(es soll die Landschaft sehen) und liefert null, also wurde der
Projektbezug "all". Betroffen war ausgerechnet der Tokentyp, den der
Adapter verlangt. Rueckfall ist jetzt das Heimatprojekt des Tokens.
- ProjectLinks::between() benutzte :a dreimal, forProject() :slug zweimal.
Bei ATTR_EMULATE_PREPARES = false unzulaessig -> HY093 und ein 500 auf
/api/bugtracker/v1/projects. Derselbe Fehler wie einst in der
Volltextsuche des Bugtrackers; ein Suchlauf ueber alle prepare()-Aufrufe
der Codebasis fand keine weitere Stelle.
WARUM BEIDE UNBEMERKT BLIEBEN
Beide Wege laufen nur mit einem Werkbank-Token (owner_type = dev_agent). Der
Testlauf hatte keines - es gibt keine API, so eines anzulegen, und in der
Produktion geschieht das von Hand. Ein Tokentyp, den kein Testfall benutzt,
ist ein Tokentyp, dessen Sonderwege niemand prueft.
testctl.php kann jetzt action=workbench_token; vier Testfaelle decken die Wege
ab, samt Gegenprobe, dass der Rueckfall aufs Heimatprojekt das Lesen ueber alle
Projekte nicht einschraenkt. 128 Faelle, alle gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
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>
|