Files
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>
2026-08-29 21:59:20 +02:00

170 lines
9.1 KiB
SQL

-- Migration 016: Roadmap als Sicht auf den Bugtracker
--
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
--
-- WOZU
--
-- Vorhaben lagen bisher in ROADMAP.md je Projekt: Status, Reihenfolge und
-- Zustaendigkeit von Hand gepflegt, neben einem Bugtracker, der genau diese
-- drei Dinge bereits fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war keine
-- Moeglichkeit, sondern eine Frage der Zeit.
--
-- Diese Migration legt KEINE Roadmap-Tabelle an. Ein Roadmap-Eintrag ist ein
-- bugtracker_item; es fehlten nur vier Angaben, die ein Backlog nicht braucht
-- und eine Roadmap schon:
--
-- epic Themenbereich (die Abschnitte A-H der bisherigen Datei)
-- roadmap_rank Reihenfolge - Schweregrad ist keine Prioritaet
-- target_build Zielfassung VOR der Umsetzung (resolved_in_build ist danach)
-- defer_trigger Woran erkennt man, dass "spaeter" jetzt ist?
--
-- DIE ZUGEHOERIGKEIT
--
-- Ein Item steht auf der Roadmap, wenn es ein `epic` hat. Kein zweites
-- Kennzeichen, kein is_roadmap-Flag daneben - sonst gaebe es wieder zwei
-- Angaben, die dasselbe behaupten und auseinanderlaufen koennen. Ein Vorhaben
-- auf die Roadmap heben heisst: ihm einen Themenbereich geben.
--
-- WARUM KEINE HANDVERGEBENEN KENNUNGEN MEHR
--
-- "A12" in der Datei und "A12" in der Datenbank sind zwei Schluessel, die
-- dasselbe meinen sollen. Wird A12 geloescht und die Kennung spaeter neu
-- vergeben, sind beide Seiten fuer sich stimmig und meinen Verschiedenes -
-- eine stille Fehldeutung, die niemand bemerkt.
--
-- Die Kennung ist deshalb bugtracker_items.id. AUTO_INCREMENT vergibt nie
-- zweimal dieselbe Nummer; eine geloeschte Zeile hinterlaesst eine haengende
-- Referenz, und die MELDET der Abgleich, statt sie stillschweigend
-- umzudeuten. Das Thema traegt weiterhin der Buchstabe, aber nur als Gruppe:
--
-- ### [A] #142 - Symbol-Upload und dc_symbolicate
-- ---------------------------------------------------------------------------
-- 1. Themenbereich
-- ---------------------------------------------------------------------------
-- Kurz gehalten. Der Buchstabe bzw. ein knappes Kuerzel ist die Gruppe; der
-- Klartext dazu steht in der Datei, nicht hier. Wuerde der volle Titel des
-- Bereichs in jeder Zeile stehen, waere er in jeder Zeile anders schreibbar.
ALTER TABLE bugtracker_items
ADD COLUMN epic VARCHAR(24) NULL AFTER tags;
-- ---------------------------------------------------------------------------
-- 2. Reihenfolge
-- ---------------------------------------------------------------------------
-- NICHT "rank": das ist seit MySQL 8.0 ein reserviertes Wort und muesste in
-- jeder Abfrage gequotet werden - ein Fehler, der erst beim ersten ungequoteten
-- Zugriff auffaellt.
--
-- NULL heisst "keine Meinung"; solche Eintraege sortieren hinter die
-- gereihten. Die Luecken zwischen den Werten sind Absicht (10, 20, 30 ...):
-- Ein Eintrag laesst sich dazwischenschieben, ohne alle folgenden neu zu
-- nummerieren.
ALTER TABLE bugtracker_items
ADD COLUMN roadmap_rank INT NULL AFTER epic;
-- ---------------------------------------------------------------------------
-- 3. Zielfassung
-- ---------------------------------------------------------------------------
-- Abgrenzung zu resolved_in_build: Das ist die Fassung, in der etwas
-- TATSAECHLICH gelandet ist, gesetzt beim Abschluss. target_build ist die
-- Absicht davor. Beide in eine Spalte zu legen hiesse, Plan und Ergebnis nicht
-- mehr unterscheiden zu koennen - und genau diese Differenz ist die
-- interessante Zahl.
ALTER TABLE bugtracker_items
ADD COLUMN target_build VARCHAR(64) NULL AFTER roadmap_rank;
-- ---------------------------------------------------------------------------
-- 4. Der Auslöser fuer Zurueckgestelltes
-- ---------------------------------------------------------------------------
-- Ohne Ausloeser ist ein Vorhaben nicht zurueckgestellt, sondern vergessen.
-- Deshalb bekommt der Status `deferred` (Punkt 6) ein Pflichtfeld an die Seite:
-- Woran erkennt man, dass "spaeter" jetzt ist?
ALTER TABLE bugtracker_items
ADD COLUMN defer_trigger TEXT NULL AFTER target_build;
-- ---------------------------------------------------------------------------
-- 5. Wo steht die Begruendung?
-- ---------------------------------------------------------------------------
-- Die Arbeitsteilung: Zustand hier, Herleitung in der Datei. Damit die beiden
-- Haelften zueinander finden, traegt das Item den Ort der Prosa -
-- "docs/ROADMAP.md#a-supervisor-und-befunde" oder ein Pfad im Projektrepo.
--
-- Bewusst ein freier String und keine Fremdschluesselbeziehung: Die Datei liegt
-- in einem anderen Repository, die Datenbank kann sie nicht pruefen. Wer das
-- prueft, ist `cli/roadmap.php --check`.
ALTER TABLE bugtracker_items
ADD COLUMN doc_anchor VARCHAR(190) NULL AFTER defer_trigger;
-- ---------------------------------------------------------------------------
-- 6. Der Status "zurueckgestellt"
-- ---------------------------------------------------------------------------
-- Es gab bisher nur `rejected` fuer beides. Das ist ein Unterschied ums Ganze:
-- Verworfen heisst "nicht erneut vorschlagen, hier steht warum".
-- Zurueckgestellt heisst "jetzt nicht, aber es gibt einen Anlass, an dem es
-- wieder ansteht". Wer beides gleich ablegt, verliert entweder die Begruendung
-- oder den Anlass.
--
-- Hinten angehaengt, damit bestehende Zeilen ihren numerischen Index behalten
-- und das ALTER ohne Datenbewegung laeuft.
--
-- `deferred` ist bewusst NICHT in CLAIMABLE_STATUSES: Zurueckgestelltes taucht
-- in ?action=next nicht auf. Genau das ist der Zweck des Status.
ALTER TABLE bugtracker_items
MODIFY COLUMN status
ENUM('open','planned','in_progress','resolved','closed','rejected','ignored',
'triage_external','awaiting_verification','in_verification','fix_insufficient',
'deferred')
NOT NULL DEFAULT 'open';
-- ---------------------------------------------------------------------------
-- 7. Index fuer die Roadmap-Sicht
-- ---------------------------------------------------------------------------
-- Die Roadmap-Ansicht fragt immer dieselbe Form: alle Items eines Projekts mit
-- gesetztem epic, sortiert nach Bereich und Reihenfolge. Der bestehende
-- ix_bt_proj_env passt dafuer nicht - er beginnt mit environment und type.
ALTER TABLE bugtracker_items
ADD KEY ix_bt_roadmap (project_slug, epic, roadmap_rank);
-- ---------------------------------------------------------------------------
-- 8. Klartext je Themenbereich
-- ---------------------------------------------------------------------------
-- Die einzige neue Tabelle, und sie ist winzig. Grund: Der Bereichstitel
-- ("A - Supervisor und Befunde") wuerde sonst in jeder Item-Zeile stehen und
-- waere in jeder Zeile anders schreibbar - drei Tippfehler, drei Bereiche.
--
-- `sort_order` traegt die Reihenfolge der Bereiche untereinander, `is_closed`
-- markiert einen Bereich, der abgeschlossen ist, ohne dass seine Items
-- verschwinden muessen.
CREATE TABLE IF NOT EXISTS roadmap_epics (
id INT AUTO_INCREMENT PRIMARY KEY,
project_slug VARCHAR(64) NOT NULL,
epic VARCHAR(24) NOT NULL,
title VARCHAR(160) NOT NULL,
summary TEXT NULL,
sort_order INT NOT NULL DEFAULT 100,
is_closed TINYINT(1) NOT NULL DEFAULT 0,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY ux_roadmap_epic (project_slug, epic),
KEY ix_roadmap_epic_order (project_slug, sort_order)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
-- ---------------------------------------------------------------------------
-- 9. Themenbereiche des Deploymentcenters
-- ---------------------------------------------------------------------------
-- Die Abschnitte der bisherigen docs/ROADMAP.md. Sie werden hier angelegt,
-- damit die Uebernahme der vorhandenen Eintraege (siehe
-- docs/ROADMAP_MIGRATION.md) nicht bei jedem Item einen Bereich erfinden muss.
--
-- INSERT IGNORE: Ein wiederholter Migrationslauf soll die von Hand
-- nachgeschaerften Titel nicht ueberschreiben.
INSERT IGNORE INTO roadmap_epics (project_slug, epic, title, summary, sort_order) VALUES
('deploymentcenter', 'A', 'Supervisor und Befunde', 'Serverseitige Detektoren, Katalog, Symbolisierung.', 10),
('deploymentcenter', 'B', 'Oberflaeche', 'Was im WebUI sichtbar ist - und was noch nicht.', 20),
('deploymentcenter', 'C', 'Projektlandschaft', 'Melden ueber Projektgrenzen, Beziehungen, Rueckkanal.', 30),
('deploymentcenter', 'D', 'Werkzeuganbindung (MCP)', 'Der stdio-Adapter und was er abdeckt.', 40),
('deploymentcenter', 'E', 'Betrieb', 'Kein Code, aber Voraussetzung dafuer, dass Gebautes wirkt.', 50),
('deploymentcenter', 'F', 'Quelltext-Zugriff', 'Drei Stufen der Preisgabe fuer die Diagnose.', 60),
('deploymentcenter', 'G', 'Testumgebung', 'Die geteilte Linux-Test-VM und die Selbstbedienung.', 70),
('deploymentcenter', 'I', 'Roadmap im Deploymentcenter', 'Diese Umstellung selbst.', 80);