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>
170 lines
9.1 KiB
SQL
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);
|