12fb06fb48163ca2edb8b70d195fc5e83fd0879d
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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> |
||
|
Deploymentcenter BotandClaude Opus 5
|
f0ed67ad29 |
feat(2.9.0): Hardwarekey an der WebUI-Anmeldung und die Roadmap als Tafel
Zwei angeforderte Funktionen, dazu zwei Befunde, die ihnen im Weg lagen. == Zweite Stufe der Anmeldung (#666) == Nach korrektem Passwort verlangt das WebUI einen registrierten FIDO2-Schluessel. Die Pflicht haengt je Konto daran, OB ein Schluessel registriert ist - nicht an einem Schalter. Ein Schalter, den man vor der Registrierung umlegt, sperrt den Betreiber aus seiner eigenen Verwaltung aus. Ohne Fremdbibliothek gebaut (das Projekt hat bewusst kein Composer): src/Core/Webauthn/ mit CBOR-Leser, COSE-nach-DER-Wandlung und Pruefung ueber openssl_verify (ES256, RS256). Auth::login() heisst jetzt Auth::startLogin() und liefert drei Zustaende statt eines bool - aus "wahr heisst drin" ist "wahr heisst vielleicht drin" geworden, und ein uebersehener Aufrufer soll an einem fehlenden Methodennamen scheitern statt an einer truthy Zeichenkette. Die Setup-API der Zielsysteme geht ueber verifyCredentials() daran vorbei und bleibt unberuehrt. Notfalltoken als Ersatzweg: nur als Hash in der Datenbank, Klartext einmalig angezeigt, Einmalgebrauch. Laeuft als gewoehnliches Formular ohne JavaScript - ein Ersatzweg mit denselben Voraussetzungen wie der Hauptweg waere keiner. Fehlversuche auf der zweiten Stufe laufen in dieselbe Konto- und IP-Sperre wie das Passwort; zuvor zaehlte nur die erste Stufe. Benutzerverwaltung kann Konten umbenennen. Beim Loeschen eines Kontos und beim Zuruecksetzen der Testinstanz werden seine Schluessel mitgenommen: credential_id ist geraeteweit eindeutig, eine verwaiste Zeile haette denselben Yubikey dauerhaft unbrauchbar gemacht. == Roadmap-Tafel (#664) == Neuer Unterreiter Roadmap -> Tafel. Der Server liefert die fertige Gliederung (RoadmapBoard, ?action=board), die Seite rendert nur - sonst schneidet das WebUI anders als die API und ein spaeterer Export ein drittes Mal anders. Phasen stehen nicht im Code: gepflegt in der neuen Tabelle roadmap_phases, sonst an den groessten Luecken der Rangfolge geschnitten und sichtbar als geraten gekennzeichnet. Links die gekappte Spalte des Erledigten, rechts "Wird ueberlegt". Nachpruefung ist ein eigener Zustand und wird nicht als erledigt gezeichnet. Klick oeffnet ein Seitenpanel: Volltext, Verlauf, Kommentieren mit action_taken, Aendern von Bereich, Rang, Zielfassung, Status und Ausloeser - ohne Seitenwechsel. Das war der eigentliche Gewinn: Wer etwas bemerkte, musste sich bisher die Nummer merken und im Bugtracker danach suchen. Tiefe Verweise #roadmap/<projekt>/item/<id>. Ziehen zwischen Phasen ueber ?action=rank_between. Fremdtext wird ausschliesslich ueber textContent gesetzt, nie ueber innerHTML. == Befund: roadmap_rank war projektweit und bereichslokal zugleich (#177) == Entschieden: projektweit. move() sucht den Nachbarn ohne Bereichsfilter, reorder() schreibt keinen ganzen Bereich mehr auf 10/20/30 um, sondern vertauscht nur die Raenge, die die Eintraege ohnehin halten. rank_between rechnet die Mitte zwischen zwei Nachbarn und nummeriert nur dann einmal neu - unter Erhalt der Reihenfolge -, wenn dort kein Platz mehr ist; die Antwort sagt es dann. == Befund: CSRF an sitzungsauthentifizierten API-Schreibzugriffen == ApiAuth akzeptiert die WebUI-Sitzung, die Endpunkte prueften dabei kein CSRF-Token. Der Kommentar in Http::beginJson - "ausschliesslich per Token-Header, niemals per Cookie" - traf auf die API nie zu. Schreibende Anfragen im Sitzungsweg verlangen jetzt csrf_token bzw. X-CSRF-Token. Token-Clients sind nicht betroffen und wurden gegengeprueft. == Geprueft == tests/e2e/suite_tafel.py neu (16 Faelle), Suite gesamt 172 von 172 gegen die Testinstanz. Die WebAuthn-Zeremonien zusaetzlich gegen einen Software- Authenticator mit echtem P-256 und echtem CBOR: Registrieren, Anmelden, verfaelschte Signatur, veraltete Herausforderung und Zaehler-Rueckfall als Klonverdacht werden je mit 403 abgewiesen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
8447b2d10a |
fix(mcp): SERVER_VERSION auf 1.2.0 - beinahe dieselbe Falle wie #354
Der Adapter hat in 2.8.1 den Parameter "fields" fuer dc_roadmap und dc_search bekommen, SERVER_VERSION blieb dabei auf 1.1.0 stehen. Damit melden sich zwei verschiedene Adapter in serverInfo identisch - und serverInfo ist das Einzige, woran ein Aufrufer erkennt, welchen er vor sich hat. Das ist genau der Fehler, der bei dc-testkit zweimal aufgetreten ist und gerade als #354 behoben wurde (1.0.0 und 1.1.0 je zweimal mit verschiedenem Inhalt ausgeliefert). Aufgefallen beim Beantworten der Frage, wie der Adapter ueberhaupt zu den Agenten kommt. Die Regel steht jetzt als Absatz ueber der Konstante - so wie im Testkit. Anders als dort gibt es dafuer noch keinen mechanischen Riegel: Der Adapter wird nicht ausgeliefert (mcp/ ist in beiden Deploy-Skripten ausgeschlossen), deshalb greift die Pruefung in deploy.py hier nicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
0e93345ab8 |
fix(2.8.1): Sechs Befunde, eine Bauart - die Voreinstellung, die einsprang
Drei Agenten haben von aussen gemeldet, und fast jeder Befund hat dieselbe Form: Irgendwo sprang ein Vorgabewert ein, obwohl die richtige Antwort bekannt war - meist das Projekt, an das der Aufrufer ohnehin gebunden ist. #351 manage?action=next antwortete durchgaengig mit HTTP 500. In BugRepo::buildFilter() stand :project_scope zweimal in derselben Anweisung; mit ATTR_EMULATE_PREPARES=false bindet PDO jeden Namen genau einmal - zwei Marker, ein Wert, SQLSTATE[HY093]. Getroffen war nur "next", weil nur dort der Rueckkanal-Filter gesetzt wird. Damit gab es keine exklusive Uebernahme. Es ist der VIERTE Fall dieser Bauart, deshalb prueft scripts/pruefe_platzhalter.py das jetzt mechanisch vor jedem Ausliefern. #382 Meldungen ohne project_slug landeten im Scheinprojekt "default" - #387 ohne dc_projects-Zeile, also project_id NULL. Die Antwort sah wie ein #397 Erfolg aus, und danach sperrte dieselbe Token-Bindung den Zugriff (403 project_forbidden). Der Rueckfall aufs Heimatprojekt war an !isWorkbench gebunden; ein Werkbank-Token ohne Slug bekam gar keinen Vorgabewert. Jetzt: genannter Slug, sonst Heimatprojekt, sonst 400. Ein unbekanntes Projekt wird abgewiesen statt still angelegt. #364 Ohne project_slug lieferten list, stats und die Roadmap ALLE #176 Projekte statt des eigenen, weil die Vorgabe auf "all" stand und ein Werkbank-Token beim Lesen absichtlich nicht unter die Schranke faellt. Gemessen: 393 Items, davon 28 eigene. Ausgerechnet der erste Aufruf jeder Sitzung. Die Roadmap antwortet ausserdem schmal - 55 Felder je Eintrag waren 628.392 Zeichen und fuellten das Kontextfenster. #404 Watchdog-Monitore bekamen nie ein Projekt: upsertHeartbeat() wurde keines uebergeben, obwohl authorizeSource() die Token-Bindung liest. Befunde erbten dadurch "default" - dc_findings(project_slug=...) war fuer eine laufende, meldende Instanz leer. #131 Wo der Leseweg richtig verengte, sagte er es nicht: HTTP 200 mit dem umgeschriebenen Filter sieht aus wie eine Auskunft ueber das angefragte Projekt. Ein Agent, der vor dem Melden dc_search fragt, legt so das Duplikat an. Jetzt scoped_to und scope_note im Umschlag - nur bei tatsaechlicher Verengung. #354 dc-testkit 1.1.0 wurde zweimal mit verschiedenem Inhalt ausgeliefert (1898 und 1930 Zeilen), 1.0.0 davor ebenso. Der Absatz ueber DC_TESTKIT_VERSION stand die ganze Zeit im Skript und hat nicht getragen. Jetzt 1.1.1 plus ein Riegel in deploy.py, der abbricht, wenn sich der Inhalt aendert und die Nummer nicht. Warum die Testsuite all das nicht sah: Ihr Master-Token ist an kein Projekt gebunden und nimmt deshalb ueberall den anderen Zweig. Es gab sogar einen Testfall fuer action=next - er lief gruen, waehrend der Aufruf in der Praxis ausnahmslos scheiterte. Die neuen Faelle benutzen ausdruecklich projektgebundene Token; testctl kann dafuer jetzt owner_type und scopes waehlen. Ausserdem: Die Agentenvorlage nennt fuer die SDK-Fassung dc_link_project statt einer abgeschriebenen Zahl - "SDK 2.5.1" stand dort als Beispiel und wurde als Wert uebernommen. Nicht enthalten: die 20 Altlasten in "default". Sie sind ueber die API nicht erreichbar; sql/wartung/2026-08-31_default-projekt-aufraeumen.sql liegt dafuer bereit (alle 20 haben einen titelgleichen Zwilling im richtigen Projekt). 156 e2e-Faelle gruen, davon 9 neue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
8274a6c0ac |
feat(2.8.0): Pruefen duerfen, ohne beheben zu duerfen
Der Unterschied zwischen "ich habe es behoben" und "der Fix eines anderen traegt" ist das Rueckgrat des Pruefverfahrens aus 2.6.1. Er stand bisher nur in der Anleitung - im Datenbestand und in den Rechten kam beides gleich an. RECHTE bugtracker:manage war ein einziger Schreib-Scope: Wer eine Nachpruefung bestaetigen durfte, durfte auch resolve, update, bulk_update und die Roadmap umschreiben. Fuer einen Pruefstand ist das zu viel - und wer einen Fix schreibt und ihn selbst abnimmt, prueft gegen die Erwartung, die er beim Schreiben hatte. bugtracker:verify deckt jetzt ab, was ein Pruefer braucht: next, claim, release, comment, confirm, report. Nicht mehr. manage schliesst es ein (IMPLIED_SCOPES), vorhandene Token verlieren nichts. "status" bleibt bewusst bei manage. Darueber liesse sich sonst jeder Zustand setzen, auch "resolved" - der Umweg um genau diese Trennung. DATENBESTAND Eine bestaetigte Nachpruefung war nicht von "jemand hat das Item zugemacht" zu unterscheiden: dc-testkit confirm setzte status=closed und schrieb den Rest in einen Kommentar. Damit war die eine Frage, fuer die das Verfahren gebaut ist, nicht beantwortbar - wurde dieses Item je gegen ein ausgeliefertes Paket geprueft? Ein Kommentartext laesst sich nicht zaehlen und nicht filtern. Migration 017 legt verified_at, verified_in_build und verified_by an. Kein eigener Status daneben: Ein bestaetigtes Item IST geschlossen, die Bestaetigung ist eine Eigenschaft dieses Abschlusses. Ein zweiter Wert waere dieselbe Falle, die 016 beim is_roadmap-Flag vermieden hat. verified_in_build steht neben resolved_in_build, weil beide verschiedene Fragen beantworten und auseinandergehen koennen - genau das ist der interessante Fall. Das eine ist die Behauptung des Behebenden, das andere die Beobachtung des Pruefenden. confirm laesst sich nur auf Items anwenden, die jemand als behoben ausgegeben hat (resolved, awaiting_verification, in_verification, fix_insufficient). Ein offenes Item zu "bestaetigen" waere ein Schliessen mit schmueckendem Beiwort - und stuende hinterher als geprueft in einer Statistik, die genau das misst. Antwort: 409 not_verifiable. MCP dc_confirm. Der Adapter hatte dc_next_task und dc_resolve, aber keinen Weg, eine Nachpruefung abzuschliessen; dc_comment kennt nur action_taken, keinen Status. Ein Pruefagent ueber MCP konnte einen Auftrag uebernehmen und dann nichts damit anfangen. 16 Werkzeuge statt 15. TESTKIT dc-testkit confirm nutzt die Aktion und schickt die gepruefte Fassung als Feld. Antwortet der Server mit 404, faellt es auf den alten Weg zurueck und sagt, dass die Fassung dann nur im Kommentar landet. Drei neue e2e-Faelle: dass confirm die gepruefte Fassung festhaelt, dass es nur dort geht, wo es etwas zu bestaetigen gibt, und dass ein verify-Token kommentieren, aber nicht beheben darf. 147 bestanden, 0 uebersprungen. 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>
|