-- 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);