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>

public/docs/changelog.json

@@ -1,16 +1,205 @@
 {
   "_comment": "Einzige Quelle der Wahrheit fuer den Changelog. Wird von /docs/changelog.php gerendert und von GET /api/updateservice/v1/changelog?since=X ausgeliefert. Neue Eintraege oben einfuegen.",
-
   "schema": 1,
-  "current": "2.6.0",
-
+  "current": "2.7.0",
   "versions": [
+    {
+      "version": "2.7.0",
+      "date": "2026-08-29",
+      "summary": "Die Roadmap zieht in das Deploymentcenter: Planungsstand, Reihenfolge und Zustaendigkeit stehen dort, wo sie ohnehin gefuehrt werden, und nicht mehr in handgepflegten Markdown-Dateien daneben. Die Dateien behalten, was eine Tabellenzelle nicht traegt - die Begruendung.",
+      "actionRequired": true,
+      "changes": [
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Roadmap als Sicht auf den Bugtracker - keine zweite Ablage",
+          "text": "Migration 016 legt KEINE Roadmap-Tabelle an. Ein Roadmap-Eintrag IST ein bugtracker_item; es fehlten nur vier Angaben, die ein Backlog nicht braucht und eine Planung schon: epic (Themenbereich), roadmap_rank (Reihenfolge - Schweregrad ist keine Prioritaet), target_build (Zielfassung VOR der Umsetzung, abgegrenzt von resolved_in_build danach) und defer_trigger. Dazu doc_anchor: der Verweis auf die Stelle in der Projektdatei, an der die Begruendung steht. Neu ausserdem der Status \"deferred\" und die winzige Tabelle roadmap_epics fuer die Bereichstitel - stuenden die an jedem Item, waeren sie in jeder Zeile anders schreibbar. Die Zugehoerigkeit ist EIN Feld: Ein Item steht auf der Roadmap, wenn es ein epic hat. Ein zweites Kennzeichen daneben waeren zwei Angaben, die dasselbe behaupten und auseinanderlaufen koennen.",
+          "action": "Migration 016 ausfuehren. Wer eigene Auswertungen auf bugtracker_items.status hat, muss \"deferred\" einordnen: Es zaehlt NICHT als offener Punkt und taucht bewusst nicht in ?action=next auf - genau das ist sein Zweck. Abzugrenzen von \"rejected\": verworfen heisst \"nicht erneut vorschlagen\", zurueckgestellt heisst \"es gibt einen Anlass, an dem es wieder ansteht\"."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Zurueckstellen ohne Ausloeser wird abgelehnt",
+          "text": "status=deferred verlangt defer_trigger mit mindestens 10 Zeichen: Woran erkennt man, dass \"spaeter\" jetzt ist? Ohne benannten Anlass ist ein Vorhaben nicht zurueckgestellt, sondern vergessen - und ein vergessener Punkt sieht in jeder Liste aus wie ein geplanter. Die Regel sitzt im Repository und gilt damit auf allen drei Wegen gleich (WebUI, /manage?action=update, roadmap.php?action=set); in einem Formular allein waere sie in dem Moment wirkungslos, in dem ein Agent die API benutzt. Abgelehnt wird mit 400 invalid_update statt 404 - ein fehlender Ausloeser ist kein fehlendes Item. Ein zurueckgestelltes Item verliert ausserdem seine Lease: Wer etwas vertagt, arbeitet nicht mehr daran.",
+          "action": null
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Neuer Endpunkt /api/bugtracker/v1/roadmap.php",
+          "text": "Lesend (bugtracker:read): action=list liefert die Eintraege nach Bereich und Reihenfolge, epics die Bereiche samt Zaehlung je Lage, next die vorderen Eintraege der Warteschlange, active wer gerade welches Item haelt, render den erzeugten Markdown-Block, check den Abgleich einer mitgeschickten Datei. Schreibend (bugtracker:manage, nur im eigenen Projekt): set, move, reorder, epic. Der status-Parameter nimmt eine Lage statt eines ENUM-Werts - aktiv, offen, arbeit, erledigt, zurueckgestellt, verworfen; zwoelf Status sind fuer die Ablage richtig und fuer eine Auswahlliste zu viele. Angelegt wird weiterhin ueber /report und abgeschlossen ueber /manage: Ein zweiter Schreibweg auf dieselben Spalten waere eine zweite Stelle, an der Regeln gelten muessten.",
+          "action": null
+        },
+        {
+          "area": "mcp",
+          "breaking": false,
+          "title": "dc_roadmap und dc_roadmap_set - der Planungsstand als Werkzeug",
+          "text": "Der Adapter hat jetzt 15 Werkzeuge. dc_roadmap beantwortet zu Sitzungsbeginn die zwei Fragen, die man sich sonst falsch beantwortet: was ist als Naechstes dran, und arbeitet schon jemand daran. dc_roadmap_set hebt ein Item auf die Roadmap (epic setzen), reiht es ein und traegt die Zielfassung nach. Beide bewusst getrennt von dc_report: Anlegen und Einplanen sind zwei Entscheidungen, und ein Werkzeug, das beides zugleich tut, trifft die zweite ungefragt mit.",
+          "action": "In den Projekten mit eingerichtetem Adapter den Roadmap-Abschnitt aus docs/AGENT_PROMPT_TEMPLATE.md in CLAUDE.md bzw. AGENTS.md uebernehmen. Ohne ihn weiss ein Agent nicht, dass er vor der Arbeit nachsehen soll."
+        },
+        {
+          "area": "webui",
+          "breaking": false,
+          "title": "Neues Modul \"Roadmap\" mit Filtern nach Bereich, Lage, Zielfassung und Agent",
+          "text": "Vier Unteransichten: Uebersicht (Kennzahlen, \"Als Naechstes\", wer arbeitet gerade woran, Fortschritt je Themenbereich), Alle Vorhaben (die Liste mit Reihenfolge-Pfeilen und Bearbeitungsdialog), Aufnahmeliste (offene Vorhaben ohne Bereich - der Weg vom Backlog auf die Planung) und Themenbereiche. Gefiltert wird serverseitig ueber GET-Parameter, die Ansicht ist damit als Link teilbar. Voreinstellung der Lage ist \"aktiv\" und nicht \"alle\": Eine Roadmap, die mit sechzig erledigten Eintraegen beginnt, beantwortet die Frage nicht, fuer die man sie aufschlaegt. Der Fortschrittsbalken rechnet Zurueckgestelltes und Verworfenes aus dem Nenner heraus - ein Bereich, in dem die Haelfte verworfen wurde, ist nicht zur Haelfte fertig, er ist kleiner geworden.",
+          "action": null
+        },
+        {
+          "area": "cli",
+          "breaking": false,
+          "title": "cli/roadmap.php: Zustandsblock erzeugen, Prosa abgleichen",
+          "text": "Die Antwort auf die Frage, wie Datenbank und Markdown-Datei zusammenbleiben, ist nicht \"besser aufpassen\", sondern zweigeteilt. --write ERZEUGT den Zustandsteil der Datei zwischen <!-- dc:roadmap -->-Markern; dort kann nichts driften, weil dort niemand tippt, und ausserhalb wird nichts angefasst. --check prueft, was von Hand geschrieben ist: Verweist ein Absatz auf ein Item, das es nicht gibt (unknown_item)? Gehoert es einem anderen Projekt (foreign_item)? Fehlt zu einer zurueckgestellten Entscheidung die Begruendung (decision_undocumented)? Rueckgabewert 1 bei Fehlern, damit sich der Aufruf in deploy.py haengen laesst. Ein Item OHNE Absatz ist bewusst kein Befund - nicht jedes Vorhaben braucht eine Herleitung. Handvergebene Kennungen entfallen: Die Kennung ist die Item-ID, denn AUTO_INCREMENT vergibt nie zweimal dieselbe Nummer, waehrend ein neu vergebenes \"A12\" auf beiden Seiten stimmig aussieht und Verschiedenes meint.",
+          "action": "Vorhandene ROADMAP.md, TODO.md oder PLAN.md je Projekt einmalig uebernehmen. Sechs Schritte, beschrieben in docs/ROADMAP_MIGRATION.md."
+        },
+        {
+          "area": "api",
+          "breaking": true,
+          "title": "observe und status: der Zustand des Befundes heisst jetzt finding_status",
+          "text": "Beide Endpunkte legten das Feld \"status\" des Befundes in dieselbe Ebene wie das Umschlagfeld \"status\" der API. Http::ok() arbeitet mit array_merge(['status' => 'success'], $data) - der Wert aus dem Body gewann. Eine angenommene Meldung kam beim Client also als status=\"open\" an. Jeder Client, der wie ueberall sonst auf status === \"success\" prueft, hielt eine erfolgreiche Meldung fuer einen Fehlschlag, und zwar ausgerechnet an dem Endpunkt, den ein meldender Client am haeufigsten aufruft. Das Feld heisst jetzt finding_status; der Umschlag sagt wieder \"success\". Zwei Testfaelle halten beides fest - dass der Umschlag stimmt UND dass die Angabe nicht einfach verschwunden ist, denn ein geloeschtes Feld haette denselben Test bestanden.",
+          "action": "Wer die Antwort von /api/supervisor/v1/observe oder /status auswertet, liest den Befundzustand nun aus finding_status. In der Praxis war das Feld vorher nicht benutzbar - es kollidierte ja gerade mit dem Umschlag."
+        },
+        {
+          "area": "betrieb",
+          "breaking": false,
+          "title": "Testinstanz dc-dev.mhdf.de und ein Testtor vor jedem Produktiv-Upload",
+          "text": "Eine vollstaendige zweite Installation, die jederzeit geloescht und neu aufgebaut werden darf: eigene Datenbank, eigene Schluessel, Basic-Auth davor, Rocket.Chat aus. Dazu 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen und die Zugangssperre. scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf die Testinstanz und laesst dann den Testlauf darauf laufen; erst bei Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test ist der Notausgang). Die Reihenfolge ist der Punkt: Liefe der Test gegen den vorhandenen Dev-Stand, prueft er aelteren Code als den, der gleich hochgeht. Gefundene, noch offene Fehler stehen mit Item-Nummer in tests/e2e/bekannte_befunde.json - sie laufen als BEK mit und blockieren nicht; besteht so ein Fall wieder, sagt der Lauf das ausdruecklich. Ein Lauf, in dem mehr uebersprungen als geprueft wurde, endet mit Rueckgabewert 2 statt 0: nichts ist kaputt, geprueft wurde es aber auch nicht, und der Unterschied darf nicht am Rueckgabewert verschwinden. Anleitung: docs/TESTINSTANZ.md.",
+          "action": "Wer deployt, braucht scripts/deploy_dev_config.json (Vorlage: ...example.json). Ohne sie bricht scripts/deploy.py ab und verweist auf --ohne-test."
+        }
+      ]
+    },
+    {
+      "version": "2.6.1",
+      "date": "2026-08-28",
+      "summary": "Agenten koennen auf der Linux-Testumgebung selbstaendig testen: DEV-Lizenzschluessel zur Selbstbedienung, ein Werkzeug fuer Auslieferung und Meldung, und eine Nachpruefung, die als Arbeit zurueckkommt statt als Benachrichtigung.",
+      "actionRequired": true,
+      "changes": [
+        {
+          "area": "api",
+          "breaking": true,
+          "title": "Nachpruefung: der Fix ist erst fertig, wenn ihn jemand gegen ein Paket geprueft hat",
+          "text": "Drei neue Zustaende (Migration 015): awaiting_verification, in_verification, fix_insufficient. Ein Item, dessen Fix veroeffentlicht wurde, geht nicht mehr direkt zu, sondern auf awaiting_verification - und taucht damit in ?action=next als Aufgabe auf. Das IST der Rueckkanal: Die Zustellung existierte laengst, es fehlte nur ein Status, der in der Warteschlangenabfrage vorkommt. Uebernehmen befoerdert nach in_verification, ueber denselben Claim wie gewoehnliche Arbeit. Bestaetigt wird mit status=closed; wer stattdessen erneut meldet, schiebt das Item selbsttaetig auf fix_insufficient - kein neues Item, Versuch und Fehlschlag bleiben auf einem Strang. Eine Regression bleibt davon unberuehrt und bekommt weiterhin ein eigenes Item: Sie betrifft ein bestaetigt geschlossenes Item, das zurueckkommt. Gegen das Verrotten: Laeuft die Lease ab, geht es zurueck in die Schlange; nach drei abgebrochenen Anlaeufen holt ein Vermerk einen Menschen; nach 30 Tagen ohne Pruefung wird ungeprueft geschlossen, mit einem Kommentar, der genau das sagt. Neu auch die Spalten status_changed_at (traegt den Timeout) und verification_cycles. Der Verlauf entsteht ohne zusaetzliche Tabelle: Jeder Statuswechsel schreibt jetzt strukturiertes meta_json (from/to/actor/since) in den vorhandenen Kommentarstrang - zuvor stand dort nur deutscher Fliesstext und der alte Status gar nicht.",
+          "action": "Migration 015 ausfuehren. Wer eigene Auswertungen auf bugtracker_items.status hat, muss die drei neuen Werte einordnen: awaiting_verification und in_verification zaehlen NICHT als offene Fehler (der Fix ist ausgeliefert, offen ist nur die Frage), fix_insufficient dagegen schon - er ist ein offener Fehler, und zwar ein besonders aergerlicher. Wer Items ueber ?action=next abholt, muss den Status pruefen: in_verification heisst 'pruefe, ob der Fix traegt', nicht 'behebe das'."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Behoben: liegengelassene Items verschwanden lautlos aus der Warteschlange",
+          "text": "Uebernehmen befoerdert ein Item von 'open' nach 'in_progress'. Lief die Lease ab, gab expireStaleLeases() zwar claimed_by, claimed_at und lease_until frei - liess den Status aber stehen. Da claimNext() nur nach 'open,planned' fragt, war ein liegengelassenes Item danach unauffindbar: kein Besitzer, nicht in der Schlange, kein Hinweis darauf, dass es je jemand angefasst hatte. Es blieb fuer immer liegen. Die Freigabe stuft den Status jetzt denselben Weg zurueck, den das Uebernehmen ihn befoerdert hat (in_progress -> open, in_verification -> awaiting_verification). Der Fehler bestand unabhaengig von der Nachpruefung und betraf jedes Projekt mit Agentenbetrieb.",
+          "action": null
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Wer einen Fremdbefund gemeldet hat, bekommt den Pruefauftrag",
+          "text": "Beim Schreiben gilt sonst ohne Ausnahme: Ein Agent uebernimmt nur Items seines eigenen Projekts. Genau das machte den Rueckkanal unmoeglich - meldet PolyTrader einen Fehler im Deploymentcenter, gehoert das Item dem Deploymentcenter, und PolyTraders Agent bekaeme es nie zu sehen, obwohl er oft der Einzige ist, der bestaetigen kann, dass der Fix bei ihm wirkt. Geoeffnet wird deshalb genau ein Spalt: fremde Items, die auf Nachpruefung warten UND bei denen das eigene Projekt in bugtracker_item_affects vermerkt ist. Wer auf diesem Weg etwas haelt, darf es kommentieren, im Status setzen und zurueckgeben - aber nicht resolve oder update. Was in einem fremden Projekt als 'behoben in Build X' gilt, entscheidet dieses Projekt.",
+          "action": null
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Regression oder nur ein veralteter Pruefstand? Der Tracker vergleicht jetzt die Fassungen",
+          "text": "Trifft eine Meldung auf ein bereits erledigtes Item, wurde daraus bisher IMMER eine Regression - ein neues Item mit Verweis auf das alte. Verglichen wurde nichts. Auf einer Testumgebung ist der haeufigste Fall aber ein anderer: Ein Lauf gegen 1.4.2 findet einen Fehler, der in 1.4.3 behoben wurde. Das ist kein Rueckschritt der Software, sondern eine veraltete Installation. Waere jede solche Meldung eine 'Regression', waere die Kennzeichnung wertlos fuer die echten. Neu wird build_version gegen resolved_in_build des erledigten Items verglichen (ueber den vorhandenen semantischen Vergleicher UpdateService\\Version, nicht ueber einen zweiten). Ist die gemeldete Fassung AELTER, entsteht nichts: kein Item, kein Kommentar, kein hochgezaehlter Zaehler. Die Antwort traegt stattdessen known_fixed_in und reported_build und sagt, dass aktualisiert und erneut geprueft werden soll. Ist sie gleich oder neuer, bleibt es bei der Regression - der Systemkommentar nennt jetzt beide Fassungen. Nicht vergleichbare Angaben ('dev', 'nightly', 'unknown', fehlendes resolved_in_build) fuehren weiterhin zur Regression; im Zweifel wird gemeldet und nicht verschluckt.",
+          "action": "Wer eigene Meldewege gebaut hat, schickt build_version mit. Ohne diese Angabe kann der Server nicht unterscheiden und legt weiterhin im Zweifel ein Regressionsitem an. dc-testkit traegt sie automatisch aus der manifest.json des geprueften Verzeichnisses nach."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "DEV-Lizenzschluessel zur Selbstbedienung",
+          "text": "Neu: POST /api/license/v1/dev-key, Scope license:dev. Eine Testmaschine stellt sich damit fuer ihr Projekt selbst einen befristeten Lizenzschluessel aus - Vorgabe 30 Tage, hoechstens 90, drei Aktivierungen, hoechstens zwoelf gleichzeitig je Projekt. Der Aufruf ist wiederholbar: Fuer dieselbe Kombination aus project_slug und instance_id kommt derselbe Schluessel zurueck und seine Frist wird verlaengert; ein Testskript darf ihn deshalb an den Anfang jedes Laufs setzen. Der Schluessel wird beim Ausstellen sofort in die .htpasswd des Produkts nachgezogen und oeffnet damit auch die Release-Ablage. Er ist markiert (customer_email dev-agent@testumgebung.invalid, Name 'DEV <maschine>'), damit Testhardware in der Aktivierungsliste von echten Installationen zu unterscheiden ist. Abgelaufene Schluessel werden nach vierzehn Tagen automatisch geloescht. ACHTUNG beim Anbinden: Dieser Endpunkt antwortet im Hausformat (status: success), nicht im abweichenden Altformat von validate und deactivate daneben.",
+          "action": "Wer auf der Linux-Test-VM testet, braucht je Projekt ein Werkbank-Token mit den Rechten bugtracker:manage und license:dev (Besitzerart dev_agent, an das Projekt gebunden). Bis das angelegt ist, laufen 'dc-testkit license' und 'dc-testkit report' ins Leere. Anleitung: docs/TESTUMGEBUNG.md, Abschnitt 4.2."
+        },
+        {
+          "area": "tooling",
+          "breaking": false,
+          "title": "dc-testkit - ein Weg fuer Lizenz, Auslieferung und Meldung",
+          "text": "Neu unter public/testkit/dc-testkit.sh, auf der Testmaschine zu holen ueber https://dc.mhdf.de/testkit/dc-testkit.sh. Deckt den ganzen Kreis eines Testlaufs ab: doctor prueft Werkzeuge, Netz, Token und Projekt; license holt und verlaengert den DEV-Schluessel; agent laedt den update-agent und gleicht die Pruefsumme gegen installer.json ab; install liefert in einen leeren Sandkasten aus; update, repair und list decken die uebrigen Wege ab; verify vergleicht das geschriebene manifest.json mit dem, was der Server als neueste Fassung fuehrt; report, next, comment, resolve und unclaim bedienen den Bugtracker; run macht alles nacheinander und meldet, was scheitert; cleanup raeumt auf und gibt den Schluessel zurueck. Braucht nur curl und python3 - jq ist auf der VM nicht installiert und wird nicht vorausgesetzt. Der Lizenzschluessel geht ueber DC_LICENSE_KEY an den Agenten und nicht ueber --license-key: Auf einer geteilten Maschine sieht jeder andere Benutzer fremde Befehlszeilen in 'ps aux'. Meldungen tragen ein aus Projekt, Titel und Fundstelle abgeleitetes client_ref - derselbe Befund aus zehn Laeufen legt ein Item an und nicht zehn.",
+          "action": null
+        },
+        {
+          "area": "docs",
+          "breaking": false,
+          "title": "Anleitung fuer die Linux-Testumgebung, projektuebergreifend",
+          "text": "Neu: docs/TESTUMGEBUNG.md. Beschreibt die geteilte Test-VM vollstaendig - Zugang, vorhandene Werkzeuge, Testkit, Konventionen fuer den Parallelbetrieb mehrerer Projekte (eigene Datenbank, eigenes X-Display, Projektpraefix in /tmp), Sichtpruefung von Oberflaechen ueber Xvfb, xdotool und ImageMagick, sowie Belegungsliste und Aufraeumen. Bewusst NICHT unter public/: Die Datei nennt eine interne Adresse, einen Benutzernamen und den Weg, sudo zeitweise freizuschalten; /docs/ ist oeffentlich erreichbar. Zuvor lag die Beschreibung im PolyTrader-Repo, obwohl sie fuer alle Projekte gilt; dort steht jetzt nur noch ein Verweis samt der PolyTrader-eigenen Angaben.",
+          "action": null
+        },
+        {
+          "area": "docs",
+          "breaking": false,
+          "title": "Bekannte Luecke: der Installationsdialog ist nicht kopflos pruefbar",
+          "text": "update-agent --action install ist ein Dialog mit Auswahllisten und Passwortabfrage. Ein Agent kann ihn nicht treiben - Auswahllisten brauchen Pfeiltasten an einem echten Terminal, und ein Agent gibt grundsaetzlich kein Passwort ein. 'dc-testkit install' prueft deshalb die Auslieferung in ein leeres Verzeichnis: denselben Pfad, den der Installer intern nimmt, mit Download, SHA256, Signatur, Staging und Rollback. Ungeprueft bleiben die Aufloesung von setup.json und das Schreiben der Konfiguration. Als Vorhaben in der Roadmap unter G1 vermerkt.",
+          "action": null
+        },
+        {
+          "area": "docs",
+          "breaking": false,
+          "title": "Fremdmeldungen: was dabei anders ist, steht jetzt dort, wo Agenten es lesen",
+          "text": "Projektuebergreifendes Melden gibt es seit 2.6.0 (C1), beschrieben war es aber nirgends dort, wo ein meldender Agent hinsieht. Drei Eigenheiten fuehrten deshalb verlaesslich in die Irre: evidence ist bei einer Fremdmeldung PFLICHT (mind. 40 Zeichen, sonst 400 missing_evidence); der Schweregrad wird serverseitig auf medium gedeckelt, weil ein fremder Melder die Dringlichkeit nicht beurteilen kann; und die Meldung landet in triage_external statt in open, wird in der offenen Liste des Zielprojekts also nicht gefunden. Steht jetzt in TESTUMGEBUNG.md Abschnitt 4.6 und in der Agent-Prompt-Vorlage. Neu im Testkit: 'dc-testkit projects' zeigt die gueltigen Slugs, 'report --project <fremd> --evidence ...' meldet dorthin, und die Deckelung wird vorher angesagt statt hinterher entdeckt.",
+          "action": "Wer die Agent-Prompt-Vorlage in ein Projekt kopiert hat, zieht den Abschnitt 'Projekt bestimmen' nach - die alte Fassung sagte zwar, dass DC-Fehler unter 'deploymentcenter' gehoeren, verschwieg aber die Pflichtangabe evidence. Ein Agent, der ihr folgte, lief in 400 missing_evidence und legte den Befund danach im eigenen Projekt ab, wo ihn niemand behebt."
+        },
+        {
+          "area": "tooling",
+          "breaking": false,
+          "title": "Testkit: 'feature' wurde stillschweigend zu 'bug'",
+          "text": "Der Bugtracker kennt genau zwei Typen, bug und feature_request, und deutet alles Uebrige wortlos in 'bug' um (BugRepo Zeile 92). Ein '--type feature' haette Feature Requests also als Fehler abgelegt, ohne dass es jemandem aufgefallen waere. Das Testkit uebersetzt jetzt feature/fr/wunsch/verbesserung nach feature_request und lehnt unbekannte Typen ab, statt sie umzudeuten. 'idea' wird gesondert abgefangen: Das ist ein Schweregrad, kein Typ. Schweregrade werden ebenfalls gegen die erlaubte Liste geprueft.",
+          "action": null
+        }
+      ]
+    },
     {
       "version": "2.6.0",
       "date": "2026-08-21",
-      "summary": "Der Installer prueft die Laufzeit und richtet die Ueberwachung des Hosts ein.",
-      "actionRequired": false,
+      "summary": "Supervisor-Befunde, MCP-Anbindung und projektuebergreifendes Melden. Der Installer prueft die Laufzeit und richtet die Ueberwachung des Hosts ein.",
+      "actionRequired": true,
       "changes": [
+        {
+          "area": "server",
+          "breaking": false,
+          "title": "Serverseitige Detektoren finden, woran niemand gedacht hat",
+          "text": "Fuenf Detektoren laufen im minuetlichen Tick (gedrosselt auf zehn Minuten) und arbeiten ausschliesslich auf Daten, die ohnehin hereinkommen: novel.error_signature meldet Fehlersignaturen, die es in dieser Fassung noch nie gab; silence.heartbeat verstummte Instanzen; deviation.self Abweichungen vom eigenen Verlauf; deviation.fleet Ausreisser gegenueber den anderen Installationen derselben Fassung; regression.build Verschiebungen zwischen zwei Fassungen. Keiner davon muss den gesuchten Fehler vorher kennen - der Massstab kommt aus der Wirklichkeit statt aus einem Kopf. Sie brauchen keine Client-Aenderung.",
+          "action": "Fuer deviation.fleet und regression.build den Monitoren ein Projekt zuordnen (watchdog_monitors.project_slug). Ohne Zuordnung laufen die uebrigen Detektoren weiter. Ein Beobachter in der ausgelieferten Anwendung ist NICHT noetig und auch nicht vorgesehen - diese Detektoren arbeiten auf Daten, die ohnehin hereinkommen."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "/api/supervisor/v1/ - Befunde einliefern und abfragen",
+          "text": "POST observe nimmt Befunde entgegen (Scope supervisor:report), GET findings und summary liefern sie aus (supervisor:read), catalog nennt alle bekannten Detektoren, POST status stuft ein (supervisor:manage). Ein Befund ist keine Fehlermeldung: er behauptet nicht, dass etwas kaputt ist, sondern dass etwas ungewoehnlich ist - deshalb loest er keine Benachrichtigung aus. Idempotent ueber client_ref, damit ein minuetlich pruefender Beobachter einen Eintrag mit hohem Zaehler erzeugt und nicht 1.440 am Tag. Wer einliefert, sind Pruefwerkzeuge und Testlaeufe (dc-testkit ab 2.6.1) - ein Beobachter im ausgelieferten Programm war erwogen und ist verworfen worden, siehe docs/ROADMAP.md Abschnitt H.",
+          "action": ""
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Projektuebergreifend melden",
+          "text": "Ein Token vom Typ dev_agent darf jetzt in ein fremdes Projekt melden - der Fall, den die Agenten-Prompt-Vorlage seit jeher verlangte und den ApiAuth::enforceProject() mit 403 verweigerte. Laufzeit-Token duerfen es weiterhin nicht: sie stecken im ausgelieferten Client und sind extrahierbar. Fuer Fremdmeldungen ist evidence Pflicht, reported_from wird aus der Token-Bindung abgeleitet statt aus dem Body uebernommen, das Item landet im Status triage_external und wird auf Schweregrad medium gedeckelt. Meldet ein zweites Projekt dasselbe, entsteht kein neues Item - es waechst die Liste der Betroffenen.",
+          "action": "Fuer Claude Code je Projekt ein Token vom Typ dev_agent anlegen, gebunden an das jeweilige Projekt."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "MCP-Adapter fuer Claude Code und andere Werkzeuge",
+          "text": "Unter mcp/ liegt ein Adapter ohne Fremdabhaengigkeiten, der 13 Werkzeuge bereitstellt: Bugtracker (Suchen, Uebernehmen, Melden, Kommentieren, Abschliessen), Supervisor (Befunde, Zaehlung je Detektor, Kennzahlverlauf) und die Projektlandschaft. Fremddaten - Fehlermeldungen, Stacktraces, Kommentare - werden im Werkzeugergebnis abgegrenzt gekennzeichnet: sie entstehen auf fremden Maschinen und sind Daten, keine Anweisungen. Damit entfaellt das Einkopieren der Agenten-Prompt-Vorlage in jedes Projekt.",
+          "action": "Adapter je Projekt in .mcp.json eintragen, siehe mcp/README.md."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Beziehungen zwischen Projekten",
+          "text": "dc_project_links haelt fest, welches Projekt welches nutzt und in welcher Fassung. Damit ersetzt POST /api/bugtracker/v1/projects die von Hand gepflegte Zeile \"Deploymentcenter-Anbindung: SDK x.y.z\" in jeder Projekt-CLAUDE.md - eine Angabe, die an N Stellen nachgezogen werden muss und nach dem ersten Vergessen schweigend falsch ist. Erstmals beantwortbar: welche meiner Projekte sind von diesem SDK-Fehler betroffen?",
+          "action": "Nach jeder Aenderung an der Anbindung dc_link_project aufrufen."
+        },
+        {
+          "area": "client",
+          "breaking": false,
+          "title": "DeploymentcenterSdk.Version stand auf 2.5.1",
+          "text": "Die Konstante war beim Sprung auf 2.6.0 nicht mitgezogen worden. Wer den Changelog wie vorgesehen mit ?since=DeploymentcenterSdk.Version abfragte, bekam 2.6.0 dauerhaft als neu gemeldet, auch nach dem Aktualisieren. Jetzt korrekt.",
+          "action": ""
+        },
+        {
+          "area": "server",
+          "breaking": false,
+          "title": "Projektgebundene Token kamen an fremde Statistiken",
+          "text": "?action=stats nahm project_slug aus der Anfrage, ohne die Bindung des Tokens zu erzwingen - ein an Projekt X gebundenes Token konnte damit die Zahlen jedes anderen Projekts abrufen. Die Bindung geht der Anfrage jetzt vor.",
+          "action": ""
+        },
         {
           "area": "client",
           "breaking": false,