dogfather-universe/server/manager-ziele-tabellen.js

/* =====================================================================
   MANAGER-ZIELE — die Tabellen (02.10.2026)
   =====================================================================

   Vier feste Monatsaufgaben für Scouts, Manager, DogFather und Spicy
   Media: Creator rekrutieren, Manager-Meeting, Schulung oder Community
   Talk, Werbung auf TikTok. Jede mit einer Zielzahl, einer Ampel und
   einem Monatsschnitt.

   WARUM EINE EIGENE DATEI: Die Tabellen hängen an `personen` (CASCADE)
   und an `leads`. Beide entstehen im Bauplan von workspace.js, und
   workspace-manager-ziele.js importiert AUS workspace.js — stünden die
   Tabellen dort, wäre das ein Importkreis. Über einen Kreis kommen
   Konstanten als `undefined` an, ohne dass irgendwo ein Fehler
   erscheint; hilfe-tabellen.js, support-tabellen.js und
   notiz-tabellen.js stehen aus demselben Grund getrennt.

   ---------------------------------------------------------------------
   DREI ENTSCHEIDUNGEN, DIE MAN SPÄTER NICHT MEHR BILLIG ÄNDERN KANN

   1. DAS ZIEL WIRD PRO MONAT EINGEFROREN, nicht als eine laufende
      Einstellung geführt.

      Filipe wollte die Zielzahlen änderbar haben, wirksam ab dem
      nächsten Monat. Läge nur EIN aktueller Wert in `einstellungen`,
      dann schriebe jede spätere Änderung rückwirkend den gesamten
      Verlauf um: Ein Monat, der mit 2/2 als „erreicht" abgeschlossen
      war, stünde nach einer Erhöhung auf 4 plötzlich als „nicht
      erreicht" da — ohne dass jemand etwas getan hätte. Ein Verlauf,
      der sich rückwirkend ändert, ist kein Verlauf.

      Deshalb: `mz_ziel` hat den Monat im Schlüssel. Beim ersten
      Zugriff auf einen Monat wird er festgeschrieben (siehe
      `monatSichern` im Fachmodul), und ab da steht er fest.

   2. DIE SPERRE VERGANGENER MONATE SITZT IN DER DATENBANK, nicht nur
      im Code.

      Dieselbe Überlegung wie bei workspace-schulung.js: „Ein Schutz,
      der nur im Code steht, ist beim nächsten neuen Weg zur Datenbank
      wieder weg." Drei Trigger lehnen jede Änderung an einem
      abgeschlossenen Monat ab.

      DIE AUSNAHME FÜR DOGFATHER LÄSST SICH IN SQLITE NICHT ÜBER DIE
      SITZUNG ABFRAGEN — es gibt keine Sitzungsvariablen. Deshalb
      `mz_freigabe`: eine einzige Zeile, die seine Route INNERHALB
      derselben Transaktion auf 1 setzt und danach wieder auf 0. Das
      ist ehrlicher als ein Trigger, den man mit einem Kommentar
      „gilt nicht für den Chef" einfach weglässt — die Ausnahme ist
      damit ein sichtbarer, zählbarer Vorgang und kein Loch.

      WARUM DIE FREIGABE NICHT VERGESSEN WERDEN KANN: Sie wird im
      `finally` einer synchronen Transaktion zurückgesetzt, und
      `mz_freigabe.bis` trägt zusätzlich einen Zeitpunkt. Was älter
      als zwei Minuten ist, gilt als nicht freigegeben — ein
      vergessenes Schloss wäre sonst dasselbe wie gar keines
      (dieselbe Erfahrung wie beim Arbeitsschloss in der Buchhaltung).

   3. DER AKTUELLE MONAT STEHT IN EINER TABELLE, nicht in `strftime`.

      Ein Trigger müsste sonst `strftime('%Y-%m','now','localtime')`
      rechnen — und `localtime` ist die Zeitzone des SERVERS. Steht der
      auf UTC, wäre am 1. eines Monats zwischen 00:00 und 02:00 Uhr
      deutscher Zeit noch der Vormonat „aktuell", und die Sperre
      griffe eine Stunde zu früh oder zu spät. `mz_lage` hält den
      Monat, den die Anwendung selbst in Europa/Berlin ausrechnet.
   ===================================================================== */

/** Die vier Aufgaben. Reihenfolge = Anzeigereihenfolge.
 *
 *  `feld` sagt, welche Zusatzangabe die Aufgabe braucht — daraus
 *  entstehen Formular, Prüfung und Dublettenschutz, damit die Liste
 *  nicht an vier Stellen getrennt gepflegt werden muss. Eine Liste,
 *  die niemand pflegt, kann nicht veralten. */
export const AUFGABEN = [
  {
    schluessel: "creator",
    name: "Creator rekrutieren",
    kurz: "Creator",
    einheit: ["Creator", "Creator"],
    vorgabe: 3,
    feld: "name",
    hinweis: "TikTok-Name des Creators",
  },
  {
    schluessel: "meeting",
    name: "Manager Meeting über Discord",
    kurz: "Meeting",
    einheit: ["Manager Meeting", "Manager Meetings"],
    vorgabe: 2,
    feld: null,
    hinweis: "Nur Datum und auf Wunsch eine Notiz",
  },
  {
    schluessel: "schulung",
    name: "Schulung oder Community Talk",
    kurz: "Schulung",
    einheit: ["Schulung oder Talk", "Schulungen oder Talks"],
    vorgabe: 2,
    feld: "art",
    arten: [
      { wert: "schulung", name: "Schulung" },
      { wert: "talk", name: "Community Talk" },
    ],
    hinweis: "Über Discord",
  },
  {
    schluessel: "werbung",
    name: "Werbung auf TikTok hochladen",
    kurz: "Werbung",
    einheit: ["Werbe-Video", "Werbe-Videos"],
    vorgabe: 1,
    feld: "link",
    arten: [
      { wert: "agentur", name: "Für die Agentur" },
      { wert: "eigen", name: "Eigenwerbung" },
      { wert: "beides", name: "Beides" },
    ],
    hinweis: "Link zum Video",
  },
];

export const AUFGABEN_SCHLUESSEL = AUFGABEN.map((a) => a.schluessel);

/** Wer die vier Aufgaben erfüllen muss.
 *
 *  Filipe am 02.10.2026 auf die Frage, wer eigene Zähler hat: „Alle
 *  vier Rollen." Creator stehen bewusst NICHT dabei — sie bekommen
 *  weder die Kachel noch eine Erinnerung. Modis und die Community
 *  kommen hier gar nicht vor: Sie gehören zum Haus Team Dogi, und die
 *  beiden Häuser sind seit dem 24.09.2026 getrennt. */
export const PFLICHT_ROLLEN = ["spicy", "admin", "manager", "scout"];

/** Wer die Zielzahlen ändern darf.
 *
 *  Filipe: „dogfather und spicy rolle sollen aber gleichzeitig es
 *  immer ändern können für alle." Das ist dieselbe Menge wie
 *  `siehtAlles()` in workspace.js — sie wird dort abgefragt und nicht
 *  hier abgeschrieben, damit es nicht zwei Mengen gibt, die
 *  auseinanderlaufen. Diese Zeile steht nur als Erinnerung daran, dass
 *  es eine bewusste Entscheidung war und keine Nebenwirkung. */

/** Der erste Monat, den es überhaupt gibt.
 *
 *  Aus der Vorlage: „Der erste gültige Monat ist Oktober 2026; davor
 *  gibt es keine Daten und keine Warnungen." Steht hier und nicht
 *  dreimal im Fachmodul. */
export const ERSTER_MONAT = "2026-10";

/** Wie lange eine Freigabe für einen abgeschlossenen Monat gilt.
 *
 *  Zwei Minuten. Lang genug für jede Korrektur, kurz genug, dass ein
 *  vergessenes Zurücksetzen keine dauerhaft offene Tür ist. */
export const FREIGABE_SEKUNDEN = 120;

/* Die Tabellen als TEXT und nicht direkt ausgefuehrt: Der Umbau
   weiter unten muss sie nach einem DROP TABLE ein zweites Mal
   anlegen koennen -- samt der Indizes, die mit der Tabelle
   verschwinden. Zweimal hingeschrieben waeren es zwei Fassungen,
   von denen eine veraltet. */
const TABELLEN = `
    /* ---------- Ein Eintrag --------------------------------------- */
    CREATE TABLE IF NOT EXISTS mz_eintrag (
      id          INTEGER PRIMARY KEY AUTOINCREMENT,
      /* SET NULL UND NICHT CASCADE -- berichtigt am 02.10.2026, am
         selben Tag, an dem die Tabelle entstand.

         Zuerst stand hier CASCADE mit der Begruendung, ein Eintrag
         ohne Person sei sinnlos. Die Vorlage sagt aber ausdruecklich:
         „Wer die Rolle verliert, sieht die Kachel nicht mehr; die
         Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
         genau das nicht wahr gewesen -- DELETE FROM personen in
         workspace-personen.js haette den ganzen Monatsverlauf eines
         Menschen lautlos mitgenommen, mitten in einem laufenden Jahr.

         Das ist dieselbe Entscheidung wie bei support_meldungen: Wird
         ein Zugang geloescht, verliert der Eintrag seinen Absender,
         nicht seinen Inhalt. Deshalb stehen Name und Rolle zusaetzlich
         als Text daneben -- eine Verknuepfung allein ueberlebt das
         Loeschen nicht. */
      person_id   INTEGER REFERENCES personen(id) ON DELETE SET NULL,
      /* WER ES WAR, als er es eintrug. Nicht nur verknuepft, sondern
         mitgeschrieben: Nach einem Rollenwechsel oder einer Loeschung
         stuende sonst „—" neben einer Zahl, die in den Monatsverlauf
         eingeht. Die Rolle entscheidet ausserdem, welches Ziel fuer
         diesen Monat galt -- eine heute andere Rolle wuerde den
         abgeschlossenen Monat rueckwirkend an anderen Zahlen messen. */
      von_name    TEXT,
      von_rolle   TEXT,
      aufgabe     TEXT    NOT NULL
                  CHECK (aufgabe IN ('creator','meeting','schulung','werbung')),
      /* 'JJJJ-MM'. Der Monatsschnitt entsteht über diese Spalte und
         NICHT über das Löschen alter Zeilen -- aus der Vorlage:
         „Löse das über die Zuordnung der Einträge zu Monat/Jahr,
         nicht über das Löschen von Daten." */
      monat       TEXT    NOT NULL CHECK (length(monat) = 7),
      datum       TEXT    NOT NULL CHECK (length(datum) = 10),
      /* Der TikTok-Name bei 'creator'. Zusätzlich normalisiert in
         name_klein, damit der Dublettenschutz nicht an einem
         Großbuchstaben oder einem führenden @ scheitert. Zwei Spalten
         statt einer Rechnung beim Suchen: So kann ein Index darauf
         liegen. */
      name        TEXT,
      name_klein  TEXT,
      /* Der Link bei 'werbung', ebenfalls mit normalisierter Fassung.
         Filipe am 02.10.2026: jede gültige Internetadresse, nicht nur
         TikTok. */
      link        TEXT,
      link_klein  TEXT,
      /* schulung|talk  bzw.  agentur|eigen|beides */
      art         TEXT,
      notiz       TEXT,
      /* DIE BRÜCKE ZUR SCOUT-PIPELINE. Darf leer sein: Nicht jede
         Rekrutierung läuft über einen Lead, und ein Pflichtfeld hier
         würde den Weg von Hand unmöglich machen. SET NULL, weil ein
         gelöschter Lead den Monatseintrag nicht entwerten darf — die
         Rekrutierung hat ja stattgefunden. */
      lead_id     INTEGER REFERENCES leads(id) ON DELETE SET NULL,
      /* Ob jemand anders denselben Creator bzw. denselben Link in
         diesem Monat schon eingetragen hatte. Kein Grund abzulehnen
         (zwei Menschen können denselben Creator ansprechen), aber
         DogFather soll es in der Übersicht sehen können. */
      doppelt_bei INTEGER REFERENCES personen(id) ON DELETE SET NULL,
      erstellt    TEXT    NOT NULL,
      geaendert   TEXT,
      geaendert_von INTEGER REFERENCES personen(id) ON DELETE SET NULL
    );
    CREATE INDEX IF NOT EXISTS idx_mz_person_monat
      ON mz_eintrag (person_id, monat, aufgabe);
    CREATE INDEX IF NOT EXISTS idx_mz_monat    ON mz_eintrag (monat);
    CREATE INDEX IF NOT EXISTS idx_mz_name     ON mz_eintrag (monat, name_klein);
    CREATE INDEX IF NOT EXISTS idx_mz_link     ON mz_eintrag (monat, link_klein);
    CREATE INDEX IF NOT EXISTS idx_mz_lead     ON mz_eintrag (lead_id);

    /* ---------- Das Ziel, eingefroren je Monat und Rolle ----------- */
    CREATE TABLE IF NOT EXISTS mz_ziel (
      monat       TEXT    NOT NULL CHECK (length(monat) = 7),
      rolle       TEXT    NOT NULL,
      aufgabe     TEXT    NOT NULL
                  CHECK (aufgabe IN ('creator','meeting','schulung','werbung')),
      /* 0 heißt ausdrücklich „für diese Rolle nicht gefordert" und
         nicht „vergessen". Eine Zeile mit 0 erzeugt keine Warnung und
         zählt nicht in den Gesamtfortschritt. */
      ziel        INTEGER NOT NULL CHECK (ziel >= 0 AND ziel <= 99),
      gesetzt_von INTEGER REFERENCES personen(id) ON DELETE SET NULL,
      gesetzt_am  TEXT    NOT NULL,
      PRIMARY KEY (monat, rolle, aufgabe)
    );

    /* ---------- Ab wann jemand pflichtig ist ----------------------- */
    /* Aus der Vorlage: „Wer erst im Laufe des Monats eine der Rollen
       bekommt, erhält in diesem Monat keine Warnungen; die Pflicht
       beginnt im Folgemonat."

       EINMAL GEMESSEN UND GESPEICHERT statt bei jeder Abfrage aus dem
       Protokoll gerechnet. Das Protokoll ist ein Log: Es wird
       irgendwann aufgeräumt, und dann änderte sich rückwirkend, ab
       wann jemand pflichtig war. Ein Fundament darf nicht aus etwas
       bestehen, das ein Aufräumlauf kürzen darf. */
    CREATE TABLE IF NOT EXISTS mz_start (
      person_id    INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE,
      erster_monat TEXT    NOT NULL CHECK (length(erster_monat) = 7),
      gesetzt_am   TEXT    NOT NULL,
      /* Woraus die Zahl entstanden ist — damit man es später
         nachvollziehen kann, ohne das Protokoll zu durchsuchen. */
      grund        TEXT
    );

    /* ---------- Welcher Monat gerade läuft ------------------------- */
    CREATE TABLE IF NOT EXISTS mz_lage (
      eins  INTEGER PRIMARY KEY CHECK (eins = 1),
      monat TEXT NOT NULL
    );
    INSERT OR IGNORE INTO mz_lage (eins, monat) VALUES (1, '0000-00');

    /* ---------- Die Freigabe für abgeschlossene Monate ------------- */
    CREATE TABLE IF NOT EXISTS mz_freigabe (
      eins  INTEGER PRIMARY KEY CHECK (eins = 1),
      offen INTEGER NOT NULL DEFAULT 0 CHECK (offen IN (0, 1)),
      bis   TEXT
    );
    INSERT OR IGNORE INTO mz_freigabe (eins, offen, bis) VALUES (1, 0, NULL);
`;

/* =====================================================================
   DER UMBAU: aus CASCADE wird SET NULL (02.10.2026)
   =====================================================================

   Noetig, weil die Tabelle am selben Tag schon mit CASCADE ausgeliefert
   wurde. Ein ALTER TABLE kann in SQLite weder einen Fremdschluessel
   noch ein NOT NULL aendern -- dafuer gibt es nur den Weg ueber eine
   neue Tabelle.

   DREI DINGE, DIE HIER ANDERS GEMACHT SIND ALS BEIM LETZTEN MAL

   1. DIE SPALTENLISTE WIRD ABGELEITET, NICHT GEPFLEGT. Am 11.09.2026
      hat im Creator Workspace genau so ein Umbau DREI Spalten mit
      Inhalt verloren -- die Liste war von Hand abgeschrieben, zweimal
      (einmal fuer CREATE, einmal fuer INSERT), und beim Hinzufuegen
      der naechsten Spalte hat sie niemand nachgezogen. Hier fragt
      PRAGMA, was in BEIDEN Tabellen steht; eine Liste, die niemand
      pflegt, kann nicht veralten.

   2. GEZAEHLT WERDEN ZEILEN *UND* SPALTEN. Die Zeilenzaehlung war
      damals als Sicherung gedacht und konnte den Spaltenverlust gar
      nicht sehen: 24 Spalten hinein, 21 heraus, bei unveraenderter
      Zeilenzahl, ohne Fehlermeldung. Stimmt hier etwas nicht, wird
      geworfen -- und die Umstellung laeuft in einer Transaktion,
      die dann zurueckrollt.

   3. ER LAEUFT NUR, WENN ER MUSS. Gefragt wird die Datenbank selbst
      (PRAGMA foreign_key_list), nicht eine Fassungsnummer, die jemand
      hochzaehlen muesste.
   ===================================================================== */
function umbauWennNoetig(d) {
  let brauchtEs = false;
  try {
    const verweise = d.prepare("PRAGMA foreign_key_list(mz_eintrag)").all();
    brauchtEs = verweise.some((v) => v.table === "personen"
      && v.from === "person_id" && String(v.on_delete).toUpperCase() === "CASCADE");
  } catch {
    return;                       // Tabelle gibt es (noch) nicht
  }
  if (!brauchtEs) return;

  const spaltenVon = (t) => d.prepare(`PRAGMA table_info(${t})`).all().map((s) => s.name);
  const vorherZeilen = d.prepare("SELECT COUNT(*) n FROM mz_eintrag").get().n;
  const vorherSpalten = spaltenVon("mz_eintrag");

  /* Die Fremdschluessel muessen WAEHREND des Umbaus aus sein, sonst
     laufen die Verweise waehrend der Umbenennung ins Leere. Danach
     wieder an -- und ueberprueft. */
  const warenAn = d.prepare("PRAGMA foreign_keys").get()?.foreign_keys;
  d.exec("PRAGMA foreign_keys = OFF");
  /* EIGENE TRANSAKTION NUR, WENN NOCH KEINE LAEUFT. Diese Funktion
     wird aus dem Bauplan in workspace.js gerufen, und der oeffnet an
     zwei Stellen selbst eine. Ein BEGIN darin wirft („cannot start a
     transaction within a transaction") -- und das waere ein Abbruch
     beim Serverstart, also die schlimmste Stelle fuer einen Fehler,
     der sich vermeiden laesst. */
  let meine = false;
  try {
    try { d.exec("BEGIN"); meine = true; } catch { meine = false; }
    /* Die neue Tabelle entsteht aus derselben Vorlage wie die echte --
       nur unter anderem Namen. Ein zweiter, von Hand geschriebener
       CREATE waere die Fassung, die auseinanderlaeuft. */
    d.exec(TABELLEN.replace(/mz_eintrag/g, "mz_eintrag_neu"));

    const nachher = spaltenVon("mz_eintrag_neu");
    const gemeinsam = vorherSpalten.filter((s) => nachher.includes(s));
    if (!gemeinsam.includes("id") || !gemeinsam.includes("person_id")) {
      throw new Error("Umbau: die Schluesselspalten fehlen in der neuen Tabelle");
    }
    const liste = gemeinsam.join(", ");
    d.exec(`INSERT INTO mz_eintrag_neu (${liste}) SELECT ${liste} FROM mz_eintrag`);

    const kopiert = d.prepare("SELECT COUNT(*) n FROM mz_eintrag_neu").get().n;
    if (kopiert !== vorherZeilen) {
      throw new Error(`Umbau: ${kopiert} statt ${vorherZeilen} Zeilen uebernommen`);
    }
    /* DIE SPALTENPROBE. Jede alte Spalte muss es weiterhin geben --
       sonst ist still Inhalt verschwunden. */
    const verloren = vorherSpalten.filter((s) => !nachher.includes(s));
    if (verloren.length) {
      throw new Error(`Umbau: Spalten verloren: ${verloren.join(", ")}`);
    }

    d.exec("DROP TABLE mz_eintrag");
    d.exec("ALTER TABLE mz_eintrag_neu RENAME TO mz_eintrag");
    if (meine) d.exec("COMMIT");
    console.log(`[manager-ziele] person_id auf SET NULL umgestellt --`
      + ` ${kopiert} Zeilen, ${nachher.length} Spalten (vorher ${vorherSpalten.length}).`);
  } catch (fehler) {
    if (meine) { try { d.exec("ROLLBACK"); } catch { /* schon zurueck */ } }
    try { d.exec("DROP TABLE IF EXISTS mz_eintrag_neu"); } catch { /* egal */ }
    console.error("[manager-ziele] Umbau abgebrochen:", fehler?.message);
    throw fehler;
  } finally {
    if (warenAn) d.exec("PRAGMA foreign_keys = ON");
  }

  /* NACH dem Umbau nachsehen, ob die Verweise noch stimmen. Ein
     Umbau mit abgeschalteten Fremdschluesseln kann sie hinterlassen,
     ohne dass irgendetwas meckert. */
  const kaputt = d.prepare("PRAGMA foreign_key_check(mz_eintrag)").all();
  if (kaputt.length) {
    console.error(`[manager-ziele] ACHTUNG: ${kaputt.length} Verweise zeigen ins Leere.`);
  }
}

export function managerZieleTabellen(d) {
  d.exec(TABELLEN);
  umbauWennNoetig(d);
  d.exec(TABELLEN);   // nach einem Umbau fehlen die Indizes

  /* EIN GEAENDERTER TRIGGER WIRD NICHT VON SELBST NEU (02.10.2026).
     `CREATE TRIGGER IF NOT EXISTS` sieht den Namen, findet ihn und
     tut nichts -- die alte Fassung bliebe stehen, und zwar fuer
     immer. Deshalb wird nachgesehen, ob die geltende Fassung die
     Ausnahme fuer ON DELETE SET NULL schon kennt; wenn nicht, kommt
     sie weg und wird unten neu gebaut.

     Erkannt am INHALT und nicht an einer Fassungsnummer: Eine Nummer
     muesste jemand hochzaehlen, und genau das wird vergessen. */
  try {
    const alt = d.prepare(
      "SELECT sql FROM sqlite_master WHERE type='trigger' AND name='mz_kein_alter_update'")
      .get()?.sql || "";
    if (alt && !alt.includes("NEW.person_id IS NULL")) {
      d.exec("DROP TRIGGER mz_kein_alter_update");
      console.log("[manager-ziele] Sperr-Trigger erneuert (laesst jetzt ON DELETE SET NULL durch).");
    }
  } catch (fehler) {
    console.error("[manager-ziele] Trigger pruefen:", fehler?.message);
  }

  /* ---------- Die Sperre ------------------------------------------
     Drei Trigger, einer je Richtung. Sie stehen hier und nicht in
     einer Umstellung: Sie gehören zur Tabelle wie ihre Spalten.

     DIE BEDINGUNG IST DREITEILIG und jeder Teil hat einen Grund:
       * der Monat des Eintrags liegt vor dem laufenden
       * die Freigabe steht nicht auf 1
       * ODER die Freigabe ist abgelaufen (`bis` liegt in der
         Vergangenheit) -- eine vergessene Freigabe ist damit nach
         zwei Minuten von selbst wieder zu.

     `datetime('now')` ist hier unbedenklich, obwohl die Zeitzone des
     Servers unbekannt ist: Verglichen wird ein UTC-Zeitstempel mit
     einem UTC-Zeitstempel (die Anwendung schreibt `toISOString()`),
     und beide wandern gemeinsam. Beim MONAT wäre genau das nicht so --
     deshalb steht er in `mz_lage`.
     --------------------------------------------------------------- */
  d.exec(`
    CREATE TRIGGER IF NOT EXISTS mz_kein_alter_insert
    BEFORE INSERT ON mz_eintrag
    WHEN NEW.monat <> (SELECT monat FROM mz_lage WHERE eins = 1)
     AND NOT (SELECT offen FROM mz_freigabe WHERE eins = 1)
    BEGIN
      SELECT RAISE(ABORT, 'monat_gesperrt');
    END;

    /* DIE AUSNAHME IN ZEILE DREI IST KEINE BEQUEMLICHKEIT, sondern die
       Reparatur eines Fehlers, den die Pruefung gefunden hat
       (02.10.2026).

       ON DELETE SET NULL ist kein Loeschen -- es ist ein UPDATE auf
       mz_eintrag.person_id. Dieser Trigger hat es als Aenderung an
       einem abgeschlossenen Monat gesehen und abgebrochen. Folge:
       Wer eine Person loeschen wollte, die irgendwann einmal etwas
       eingetragen hatte, bekam 'monat_gesperrt' -- und die ganze
       Personenverwaltung in workspace-personen.js waere daran
       gescheitert, an einer Stelle, die mit Monatszielen nichts zu
       tun hat.

       Erlaubt ist deshalb genau EINE Aenderung an einem alten Monat:
       dem Eintrag seinen Besitzer zu nehmen. Alles andere -- Datum,
       Name, Link, Notiz -- bleibt gesperrt.

       ALS BEDINGUNG UND NICHT ALS SPALTENLISTE (UPDATE OF ...):
       Eine Liste muesste jemand pflegen, und beim Hinzufuegen der
       naechsten Spalte wuerde sie vergessen -- dann waere die Sperre
       dort still unwirksam. Diese Bedingung beschreibt, WAS erlaubt
       ist, und gilt damit auch fuer jede Spalte, die es noch nicht
       gibt. */
    CREATE TRIGGER IF NOT EXISTS mz_kein_alter_update
    BEFORE UPDATE ON mz_eintrag
    WHEN OLD.monat <> (SELECT monat FROM mz_lage WHERE eins = 1)
     AND NOT (NEW.person_id IS NULL AND OLD.person_id IS NOT NULL)
     AND NOT ((SELECT offen FROM mz_freigabe WHERE eins = 1)
              AND (SELECT bis FROM mz_freigabe WHERE eins = 1) > datetime('now'))
    BEGIN
      SELECT RAISE(ABORT, 'monat_gesperrt');
    END;

    CREATE TRIGGER IF NOT EXISTS mz_kein_alter_delete
    BEFORE DELETE ON mz_eintrag
    WHEN OLD.monat <> (SELECT monat FROM mz_lage WHERE eins = 1)
     AND NOT ((SELECT offen FROM mz_freigabe WHERE eins = 1)
              AND (SELECT bis FROM mz_freigabe WHERE eins = 1) > datetime('now'))
    BEGIN
      SELECT RAISE(ABORT, 'monat_gesperrt');
    END;
  `);

  /* ---------- Nachrüstung für Bestände ohne die neuen Spalten -------
     ABGELEITET, NICHT ABGESCHRIEBEN. Am 11.09.2026 hat im Creator
     Workspace eine von Hand gepflegte Spaltenliste beim Tabellenumbau
     drei Spalten mit Inhalt verloren -- ohne Fehlermeldung, bei
     unveränderter Zeilenzahl. Deshalb wird hier gefragt, was DA ist,
     statt eine Liste zu pflegen. */
  const da = new Set(d.prepare("PRAGMA table_info(mz_eintrag)").all().map((s) => s.name));
  const fehlt = [
    ["name_klein", "TEXT"], ["link_klein", "TEXT"],
    ["doppelt_bei", "INTEGER REFERENCES personen(id) ON DELETE SET NULL"],
    ["von_name", "TEXT"], ["von_rolle", "TEXT"],
  ].filter(([spalte]) => !da.has(spalte));
  for (const [spalte, typ] of fehlt) {
    d.exec(`ALTER TABLE mz_eintrag ADD COLUMN ${spalte} ${typ}`);
  }
}