Files
Deploymentcenter/sql/migrations/014_supervisor_findings.sql
T
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

104 lines
4.7 KiB
SQL

-- Migration 014: Supervisor-Befunde
--
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
--
-- Ein Befund ist keine Fehlermeldung. Er behauptet nicht, dass etwas kaputt
-- ist, sondern dass etwas ungewoehnlich ist. Die Einstufung trifft die
-- empfangende Seite, die den Flottenblick hat - deshalb heisst das Feld
-- severity_hint und nicht severity.
--
-- Siehe docs/SUPERVISOR_MCP_DESIGN.md, Abschnitte 1 und 2.
CREATE TABLE IF NOT EXISTS supervisor_findings (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
project_slug VARCHAR(64) NOT NULL,
-- Welche Installation? Bei serverseitigen Detektoren die Quelle des
-- Monitors, bei clientseitigen die vom Beobachter gemeldete Kennung.
instance VARCHAR(100) NOT NULL DEFAULT 'default',
-- Name aus dem Katalog, Form "familie.sache". Wandert nie mehr; kommt etwas
-- dazu, bekommt es einen neuen Namen. Nur so bleiben Befunde aus
-- verschiedenen Projekten vergleichbar.
detector VARCHAR(64) NOT NULL,
-- Worauf bezieht sich der Befund - eine Metrik, ein Jobname, eine
-- Fehlersignatur, eine Zusicherung.
subject VARCHAR(190) NOT NULL,
-- Kam der Befund von einer Installation oder aus einem Detektorlauf hier?
-- Serverseitige Detektoren arbeiten auf Daten, die ohnehin hereinkommen,
-- und brauchen keinen neuen Client.
origin ENUM('client','server') NOT NULL DEFAULT 'client',
severity_hint ENUM('idea','wishlist','low','medium','high','critical') NULL,
-- Was wurde gemessen, und wogegen? Bewusst als JSON: jeder Detektor bringt
-- andere Groessen mit, und eine Spalte je Detektor waere nach dem dritten
-- unhaltbar.
observed_json JSON NULL,
baseline_json JSON NULL,
build VARCHAR(64) NULL,
commit_sha VARCHAR(64) NULL,
environment ENUM('production','development','staging','testing') NOT NULL DEFAULT 'production',
-- open - frisch, ungesichtet
-- acknowledged- angesehen, kein Handlungsbedarf im Moment
-- promoted - daraus wurde ein Bugtracker-Item (siehe bug_item_id)
-- resolved - Ursache behoben
-- ignored - dauerhaft uninteressant, zaehlt aber weiter hoch
status ENUM('open','acknowledged','promoted','resolved','ignored')
NOT NULL DEFAULT 'open',
bug_item_id BIGINT NULL,
occurrence_count INT NOT NULL DEFAULT 1,
-- Aus Detektor, Gegenstand und Fassung gebaut, nicht zufaellig: derselbe
-- Befund darf beliebig oft gemeldet werden, ohne ein Duplikat anzulegen.
-- Ein Beobachter, der minuetlich nachsieht, wuerde sonst 1.440 Eintraege am
-- Tag erzeugen.
client_ref VARCHAR(190) NOT NULL,
first_seen_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
last_seen_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
acknowledged_at DATETIME NULL,
acknowledged_by VARCHAR(100) NULL,
UNIQUE KEY ux_finding (project_slug, client_ref),
KEY ix_find_detector (detector, status),
KEY ix_find_project (project_slug, status, last_seen_at),
KEY ix_find_instance (instance, last_seen_at),
KEY ix_find_cleanup (last_seen_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
-- ---------------------------------------------------------------------------
-- Zu welchem Projekt gehoert ein Monitor?
-- ---------------------------------------------------------------------------
-- Der Watchdog kannte bisher nur Quelle und Instanz. Fuer den Flottenvergleich
-- reicht das nicht: verglichen werden darf nur, was vergleichbar ist, und
-- "Fassung 1.0" zweier verschiedener Produkte hat nichts miteinander zu tun.
-- Die Kohorte ist deshalb (Projekt, app_version).
--
-- Bewusst NICHT vom Agenten gesetzt, sondern administrativ. Sonst braeuchte
-- diese Etappe einen Rollout neuer Agentenskripte auf jede Maschine - und der
-- ganze Punkt der serverseitigen Detektoren ist, dass sie auf Daten arbeiten,
-- die ohnehin schon hereinkommen.
--
-- Bleibt das Feld leer, laufen die monitorbezogenen Detektoren trotzdem; ihre
-- Befunde landen dann unter dem Projekt aus supervisor.default_project.
-- Flotten- und Regressionsvergleich setzen dagegen eine Zuordnung voraus und
-- ueberspringen nicht zugeordnete Monitore.
ALTER TABLE watchdog_monitors
ADD COLUMN project_slug VARCHAR(64) NULL AFTER group_key;
ALTER TABLE watchdog_monitors
ADD KEY ix_wd_project (project_slug, app_version);
-- Taktgeber fuer die serverseitigen Detektoren. Sie haengen im minuetlichen
-- Cron, sollen aber nicht minuetlich laufen - ein Flottenvergleich alle zehn
-- Minuten sagt dasselbe wie einer jede Minute und kostet ein Zehntel.
INSERT INTO watchdog_cron_jobs (name, interval_sec, enabled)
VALUES ('supervisor_detectors', 600, 1)
ON DUPLICATE KEY UPDATE interval_sec = VALUES(interval_sec);