Deploymentcenter/sql/migrations/013_cross_project_reporting.sql

-- Migration 013: Projektuebergreifendes Melden und Projektbeziehungen
--
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091
-- ("existiert bereits"), sodass sie auf einer teilweise migrierten Datenbank
-- durchlaeuft.
--
-- Hintergrund: Einige Projekte arbeiten stark verzahnt, das Deploymentcenter
-- am staerksten. Ein Agent, der das SDK in Projekt X integriert und dabei
-- einen Fehler im Deploymentcenter findet, muss ihn dort ablegen koennen.
-- Bisher verweigerte ApiAuth::enforceProject() genau das - obwohl die
-- Agenten-Prompt-Vorlage es ausdruecklich verlangt.
--
-- Siehe docs/SUPERVISOR_MCP_DESIGN.md, Abschnitt 5.

-- ---------------------------------------------------------------------------
-- 1. Herkunft einer Meldung
-- ---------------------------------------------------------------------------
-- Aus welchem Projekt heraus wurde gemeldet? Das ist keine Buchhaltung,
-- sondern das wertvollste Signal im Vorgang: melden drei Projekte unabhaengig
-- dieselbe Sache gegen das Deploymentcenter, ist das kein "low" mehr.
ALTER TABLE bugtracker_items
  ADD COLUMN reported_from VARCHAR(64) NULL AFTER created_by;

-- Begruendungspflicht bei Fremdmeldungen: was wurde beobachtet, und warum
-- liegt die Ursache dort und nicht hier. Ein Agent in Projekt X kann kaum
-- unterscheiden, ob das Deploymentcenter kaputt ist oder ob X das SDK falsch
-- benutzt; die Voreinstellung eines hilfsbereiten Modells ist im Zweifel
-- "melde es". Etwas ausformulieren zu muessen kostet einen Reflex fast immer
-- den Kopf.
ALTER TABLE bugtracker_items
  ADD COLUMN evidence TEXT NULL AFTER reported_from;

ALTER TABLE bugtracker_items
  ADD KEY ix_bt_reported_from (reported_from, status);

-- ---------------------------------------------------------------------------
-- 2. Eigener Eingang fuer Fremdmeldungen
-- ---------------------------------------------------------------------------
-- Fremdmeldungen landen nicht im offenen Backlog, sondern in 'triage_external'
-- und zaehlen erst nach Bestaetigung in die Statistik.
--
-- Das ist kein Misstrauen gegen den meldenden Agenten, sondern Schutz der
-- Auswertung: die Detektoren aus dem Supervisor-Entwurf (Neuheit, Abweichung,
-- Flottenvergleich) kalibrieren auf diesen Zahlen. Ein Detektor, der auf
-- Fehlmeldungen kalibriert, ist wertlos.
--
-- 'triage_external' gilt bewusst NICHT als aktiver Status - open_items und
-- critical_items in getProjects() bleiben dadurch unveraendert sauber.
ALTER TABLE bugtracker_items
  MODIFY COLUMN status
    ENUM('open','planned','in_progress','resolved','closed','rejected','ignored','triage_external')
    NOT NULL DEFAULT 'open';

-- ---------------------------------------------------------------------------
-- 3. Wer ist betroffen?
-- ---------------------------------------------------------------------------
-- Statt drei Items fuer denselben SDK-Fehler entsteht eines mit wachsender
-- Betroffenenliste. Die Buendelung laeuft ueber den dedup_key des Items,
-- nicht ueber client_ref - der ist nur je Melder eindeutig.
CREATE TABLE IF NOT EXISTS bugtracker_item_affects (
  id                BIGINT AUTO_INCREMENT PRIMARY KEY,
  item_id           BIGINT      NOT NULL,
  project_slug      VARCHAR(64) NOT NULL,
  report_count      INT         NOT NULL DEFAULT 1,
  first_reported_at DATETIME    NOT NULL DEFAULT CURRENT_TIMESTAMP,
  last_reported_at  DATETIME    NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY ux_affects (item_id, project_slug),
  KEY ix_affects_project (project_slug),
  FOREIGN KEY (item_id) REFERENCES bugtracker_items(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- ---------------------------------------------------------------------------
-- 4. Beziehungen zwischen Projekten
-- ---------------------------------------------------------------------------
-- dc_projects kannte bisher Slug, Name und Notiz - aber nicht, welches
-- Projekt auf welchem aufsetzt. Damit war die Frage "welche meiner Projekte
-- sind von diesem SDK-Fehler betroffen?" nicht beantwortbar.
--
-- integrated_version loest nebenbei ein Wartungsproblem: die von Hand
-- gepflegte Zeile "Deploymentcenter-Anbindung: SDK 2.5.1" in jeder
-- Projekt-CLAUDE.md wandert hierher. Sie veraltet dort schweigend, sobald
-- jemand sie einmal vergisst.
--
-- Bewusst kein Fremdschluessel auf dc_projects.slug: ein Projekt darf eine
-- Beziehung eintragen, bevor das Gegenstueck angelegt ist. Genauso haelt es
-- bugtracker_items.project_slug.
CREATE TABLE IF NOT EXISTS dc_project_links (
  id                 INT AUTO_INCREMENT PRIMARY KEY,
  from_slug          VARCHAR(64) NOT NULL,
  to_slug            VARCHAR(64) NOT NULL,
  kind               ENUM('uses_sdk','depends_on','shares_code') NOT NULL DEFAULT 'uses_sdk',
  integrated_version VARCHAR(32)  NULL,
  integrated_at      DATETIME     NULL,
  notes              VARCHAR(255) NULL,
  created_at         DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at         DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY ux_link (from_slug, to_slug, kind),
  KEY ix_link_to (to_slug, kind)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;