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>

sql/migrations/015_verification_workflow.sql

@@ -0,0 +1,87 @@
+-- Migration 015: Verifikation als Arbeitsschlange
+--
+-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
+--
+-- WOZU
+--
+-- Bisher endete ein Fehler mit "resolved": Ein Agent sagt, er habe ihn behoben,
+-- und damit war der Vorgang zu. Ob der Fix in einem ausgelieferten Paket
+-- tatsaechlich traegt, hat nie jemand nachgesehen - es gab keinen Ort, an dem
+-- diese Aufgabe gestanden haette.
+--
+-- Der Rueckkanal dafuer muss nichts zustellen. Er existiert bereits: Agenten
+-- fragen ueber ?action=next nach Arbeit. Ein Status, der in dieser Abfrage
+-- vorkommt, IST die Zustellung. Deshalb hier drei Zustaende statt einer
+-- Benachrichtigungsstrecke.
+--
+--   awaiting_verification  Der Fix steckt in einem veroeffentlichten Build.
+--                          Jemand kann jetzt nachsehen - vorher ging es nicht,
+--                          weil es kein Paket gab.
+--   in_verification        Jemand sieht gerade nach. Entsteht durch denselben
+--                          Claim wie in_progress, damit es nur einen
+--                          Uebernahmeweg gibt.
+--   fix_insufficient       Gegen den Build geprueft, Fehler immer noch da. Der
+--                          Fix hat nie getragen.
+--
+-- ABGRENZUNG zu "Regression": fix_insufficient bleibt am selben Item - Versuch
+-- und Fehlschlag gehoeren auf einen Strang. Eine Regression ist etwas anderes:
+-- Das Item war bestaetigt erledigt und kam spaeter zurueck. Sie bekommt
+-- weiterhin ein eigenes Item mit Verweis auf das alte.
+--
+-- WARUM KEINE HISTORIENTABELLE
+--
+-- Die Frage, fuer die der Timeout gebraucht wird, lautet "wie lange steht das
+-- schon so?". Das ist ein Zustand des Items, kein Ereignis - eine Spalte
+-- beantwortet ihn, ein Log muesste dafuer durchsucht werden. Der Verlauf
+-- selbst steht weiterhin in bugtracker_comments; ab dieser Fassung mit
+-- strukturiertem meta_json (from/to/actor), sodass er auch auswertbar ist.
+-- Eine eigene Tabelle lohnt erst fuer Fragen ueber Items hinweg ("wie oft
+-- faellt ein Fix durch die Pruefung?") - dann aber auf gefuellten meta_json
+-- aufbauend und nicht daneben.
+
+-- ---------------------------------------------------------------------------
+-- 1. Die drei neuen Zustaende
+-- ---------------------------------------------------------------------------
+-- Reihenfolge im ENUM bewusst am Lebenslauf entlang und hinten angehaengt:
+-- Bestehende Zeilen behalten ihren numerischen Index, ein ALTER ohne
+-- Datenbewegung.
+ALTER TABLE bugtracker_items
+  MODIFY COLUMN status
+    ENUM('open','planned','in_progress','resolved','closed','rejected','ignored',
+         'triage_external','awaiting_verification','in_verification','fix_insufficient')
+    NOT NULL DEFAULT 'open';
+
+-- ---------------------------------------------------------------------------
+-- 2. Seit wann steht das so?
+-- ---------------------------------------------------------------------------
+-- Traegt den Timeout. Ohne diese Spalte muesste "steht seit X Tagen in diesem
+-- Status" aus Kommentartexten gelesen werden - dort steht der Statuswechsel
+-- heute als deutscher Fliesstext.
+--
+-- Vorbelegt mit updated_at bzw. created_at: Fuer bestehende Zeilen ist das die
+-- ehrlichste verfuegbare Naeherung. Ein NULL waere sauberer, macht aber jede
+-- Abfrage zu einem Sonderfall.
+ALTER TABLE bugtracker_items
+  ADD COLUMN status_changed_at DATETIME NULL AFTER status;
+
+UPDATE bugtracker_items
+   SET status_changed_at = COALESCE(updated_at, created_at, UTC_TIMESTAMP())
+ WHERE status_changed_at IS NULL;
+
+-- ---------------------------------------------------------------------------
+-- 3. Wie oft wurde die Pruefung schon begonnen und nicht beendet?
+-- ---------------------------------------------------------------------------
+-- Gegen das Pendeln: Laeuft die Lease in der Pruefung ab, geht das Item zurueck
+-- nach awaiting_verification. Ohne Zaehler koennte es das ewig tun und dabei
+-- lebendig aussehen, waehrend nichts geschieht - genau die Schlange, die
+-- niemand leert, nur mit Zwischenschritten.
+ALTER TABLE bugtracker_items
+  ADD COLUMN verification_cycles TINYINT UNSIGNED NOT NULL DEFAULT 0 AFTER status_changed_at;
+
+-- ---------------------------------------------------------------------------
+-- 4. Index fuer die Wartungslaeufe
+-- ---------------------------------------------------------------------------
+-- Der Evaluator fragt minuetlich "welche Items stehen zu lange in welchem
+-- Status?". Ohne Index waere das ein Full Scan je Minute.
+ALTER TABLE bugtracker_items
+  ADD KEY ix_bt_status_changed (status, status_changed_at);