Zwei bis drei Bilder je Supportmeldung -- und zwei Funde unterwegs

VanVan im Support, Meldung #11, VIERMAL gemeldet: „Hier im
Supportbereich kann man immer nur ein Bild hinzufuegen bei einer
Meldung. 2-3 waeren besser." Und in der zweiten Runde der Satz, auf
den es ankommt: „wenn man es nacheinander versucht hinzuzufuegen wird
das Bild immer nur ersetzt."

EINE TABELLE STATT NEUER SPALTEN

`support_bilder` haelt ab jetzt JEDES Supportbild -- das der Meldung
(`runde_nr` NULL) und das einer Antwort (`runde_nr` = Runde). Die
Alternative waere `bild2_datei`, `bild3_datei` gewesen, und beim
vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im
Schema; die Grenze steht an EINER Stelle im Code (`BILDER_MAX = 3`)
und kommt von dort in die Oberflaeche, statt dort ein zweites Mal
zu stehen.

DIE ACHT VORHANDENEN BILDER WANDERN MIT. Ohne diesen Schritt haette
die neue Tabelle ab heute recht und die alten Bilder waeren
unsichtbar -- ohne Fehler, ohne rote Zeile, nur acht leere Karten.
Der Umzug steht NACH der Spaltennachruestung: Er liest
`urteil_bild_datei`, und die gibt es in einer bestehenden Datenbank
erst, nachdem sie ergaenzt wurde. Stuende er davor, scheiterte er
genau dort, wo es darauf ankommt -- live, waehrend lokal alles gruen
bliebe, weil jede Pruefung ihre Datenbank frisch anlegt.

DREI BILDER IN EINER ANFRAGE

`x-bilder: 20481,15320` sagt, wo zu schneiden ist, der Rumpf ist die
Aneinanderreihung. `multipart/form-data` haette einen Zerleger
gebraucht, den dieses Haus nicht hat; drei Anfragen nacheinander
haetten den Zustand „Meldung da, Bild zwei laedt noch" erzeugt --
genau den, gegen den die Kommentare an dieser Route schon vorher
argumentieren. Die Summe muss auf das Byte stimmen, und jedes Stueck
wird einzeln an seinen ersten Bytes erkannt: Wer falsch schneidet,
bekommt eine Absage, kein verfaelschtes Bild. Ohne den Kopf gilt der
ganze Rumpf als ein Bild -- derselbe Satz mit einer Laenge, damit
eine Seite aus dem Zwischenspeicher weiterlaeuft.

EINE ROUTE STATT DREI. `/:id/bild` und `/:id/runde/:nr/bild` sind
weg; es gibt `/:id/bild/:bid`. Wohin ein Bild gehoert, steht in
seiner Zeile -- der Weg muss es nicht wiederholen. Die
Meldungsnummer bleibt trotzdem im Pfad: Sie ist die
Sichtbarkeitsfrage, und beides muss zusammenpassen (gemessen).

ZWEI FUNDE, DIE DIE PRUEFUNG GEMACHT HAT UND NICHT ICH

 1. UEBER DIE SEITE KAM GAR KEIN BILD MEHR AN. Beim Melden stand
    kein `Content-Type`. Das ging gut, solange der Rumpf eine
    einzelne Datei war -- ein `File` bringt seinen Typ mit. Ein
    `Blob` aus mehreren hat keinen, `fetch` schickt die Zeile dann
    gar nicht, `express.raw` fuehlt sich nicht zustaendig, und der
    Server bekam einen leeren Rumpf. Die Meldung waere durchgegangen,
    der Text angekommen, die Bilder weg -- ohne Fehlermeldung. Alle
    Pruefungen am Server waren dabei gruen; gefunden hat es erst der
    echte Browser.

 2. DAS KREUZ DES DRITTEN BILDES LAG AUF DEM ZWEITEN. Der
    Entfernen-Knopf ist 44 px breit und absolut gesetzt, der Kasten
    aber nur so breit wie sein Bild. Bei einem schmalen Bild ragt er
    darueber hinaus -- wer „das zweite weg" antippt, loescht das
    dritte. `min-width`/`min-height` loesen das an der Ursache: Ein
    Kasten ist nie schmaler als der Knopf in ihm.

WAS ICH FALSCH ANGENOMMEN HATTE: Ich hatte eingebaut, dass ein
Nachtrag in derselben Runde die Bilder ersetzt. Die Pruefung dazu
wurde rot -- zu Recht: Eine zweite Antwort in derselben Runde kann
es nicht geben, die erste verlaesst den Stand „wartet". Der Code
waere nie gelaufen und damit nie pruefbar gewesen. Er ist weg; an
seiner Stelle steht der Beweis, dass er nicht fehlt.

DREI WEITERE ROTE ZEILEN, DIE NICHT ZU DIESEM UMBAU GEHOERTEN

 * `manager-ziele.js` hatte einen ZWEITEN Notnagel
   (`frageNach ? … : confirm(…)`). `nachfrage.js` hat denselben
   laengst, und zwar mit dem vollstaendigen Text; der hiesige war
   der kuerzere und haette gewonnen. Zwei Antworten auf dieselbe
   Frage -- gemeldet von `pruef-nachfrage`.
 * Zwei Mittelpunkte in `reaktion.css` standen woertlich im
   `content`. Sie liegen im Latin-1-Block, wo `pruef-zeichen` die
   Truemmer einer verunglueckten Kodierung sucht. Jetzt als Escape
   -- im Browser nachgemessen, es steht Zeichen fuer Zeichen
   dasselbe da.
 * Das Aufraeumen nach 90 Tagen loeschte nur das EINE Bild der
   Meldung; die Bilder aus den Antwortrunden blieben ohne Zeile auf
   der Platte liegen. Die Liste kommt jetzt aus einer Abfrage statt
   aus einer Spalte und kann deshalb nicht wieder unvollstaendig
   sein.

GEPRUEFT

  pruef-support            78 -> 104 ok
    darunter: der Umzug der alten Bilder auf einer eigenen
    Wegwerf-Datenbank -- zweimal und dreimal gestartet, nichts
    verdoppelt, Datum von damals erhalten
  pruef-support-bilder     NEU, 36 ok (echter Browser)
    dreimal nacheinander waehlen ergibt drei, das vierte wird mit
    einem Satz abgelehnt, dasselbe zaehlt nicht doppelt, einzeln
    entfernen laesst die anderen stehen, alle drei laden wirklich
    (naturalWidth), Kreuze 44x44 und keines verdeckt (mit Gegenprobe
    per Deckel), nichts ragt auf 390 px heraus
  pruef-nachfrage          69 -> 74 ok
  pruef-struktur          102 ok, 413 Routen (vorher 414: zwei weg,
                          eine neu)
  pruef-zeichen             7 ok (vorher 1 Fehler)
  pruef-aufbewahrung       45 ok
  pruef-manager-ziele     216 ok
  pruef-ports              10 ok · pruef-portnummern 41 ok
    (die neue Pruefdatei verschiebt die abgeleiteten Nummern)

NUR DAS AGENTURHAUS IST BETROFFEN. Die Supportseite liegt unter
`/workspace`; am Crew-Haus aendert sich keine Zeile.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/support-tabellen.js

@@ -252,8 +252,55 @@ export function supportTabellen(d) {
       ON support_meldungen(stand, id DESC);
     CREATE INDEX IF NOT EXISTS idx_support_person
       ON support_meldungen(person_id, id DESC);
+
+    /* ==== MEHRERE BILDER JE MELDUNG (02.10.2026) ==================
+
+       VanVan im Support, Meldung #11 -- VIERMAL gemeldet: „Hier im
+       Supportbereich kann man immer nur ein Bild hinzufügen bei einer
+       Meldung. 2-3 wären besser." Und in Runde 2: „wenn man es
+       nacheinander versucht hinzuzufügen wird das Bild immer nur
+       ersetzt."
+
+       KEINE GEGEN-APOSTROPHE IN DIESEM TEXT. Er steht in einem
+       Template-Literal, und einer davon beendet es -- der Server
+       startet dann gar nicht mehr. Genau das ist in der Nacht zum
+       25.09. schon einmal passiert, zwanzig Zeilen weiter unten
+       steht die Warnung dazu, und beim Schreiben dieses Kommentars
+       ist es trotzdem wieder passiert. Ein Kommentar, der vor einem
+       Fehler warnt, verhindert ihn nicht.
+
+       EINE TABELLE FUER ALLE SUPPORTBILDER, nicht drei Spaltensaetze
+       nebeneinander. Die Alternative waere gewesen, bild2_datei,
+       bild3_datei danebenzustellen -- und beim vierten Bild wieder.
+       Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze
+       steht an EINER Stelle im Code (BILDER_MAX) und laesst sich dort
+       aendern, ohne die Datenbank anzufassen.
+
+       runde_nr SAGT, WOZU ES GEHOERT: NULL heisst „zur Meldung
+       selbst", eine Zahl heisst „zur Antwort in dieser Runde". Damit
+       braucht es keine zweite Tabelle fuer die Runden -- es ist
+       dieselbe Frage („welches Bild gehoert hierhin?"), und zwei
+       Tabellen waeren zwei Antworten darauf.
+
+       DIE REIHENFOLGE IST DIE DES HOCHLADENS (die id). Eine eigene
+       Spalte nr waere eine Zahl, die jemand pflegen muss, sobald ein
+       Bild dazwischen weggeht. */
+    CREATE TABLE IF NOT EXISTS support_bilder (
+      id         INTEGER PRIMARY KEY AUTOINCREMENT,
+      meldung_id INTEGER NOT NULL
+                 REFERENCES support_meldungen(id) ON DELETE CASCADE,
+      runde_nr   INTEGER,
+      datei      TEXT    NOT NULL,
+      typ        TEXT,
+      breite     INTEGER,
+      hoehe      INTEGER,
+      erstellt   TEXT    NOT NULL
+    );
+    CREATE INDEX IF NOT EXISTS idx_support_bilder
+      ON support_bilder (meldung_id, runde_nr, id);
   `);
 
+
   /* ==== NACHTRAGEN, WAS `IF NOT EXISTS` NICHT NACHTRAEGT ============
      (02.10.2026)
 
@@ -290,4 +337,53 @@ export function supportTabellen(d) {
       console.error(`[support] Spalte '${spalte}':`, fehler?.message);
     }
   }
+
+  /* ==== DIE VORHANDENEN BILDER WANDERN MIT (02.10.2026) ============
+
+     Ohne diesen Schritt haette die neue Tabelle ab heute recht und
+     die acht Bilder von vorher waeren unsichtbar -- ein Umbau, der
+     Daten verliert, ohne dass etwas rot wird. Genau die Sorte, die
+     am 11.09. drei Spalten gekostet hat.
+
+     ERST HIER, NICHT WEITER OBEN. Gelesen wird `urteil_bild_datei`
+     aus `support_runden` -- und diese Spalte gibt es in einer
+     bestehenden Datenbank erst, nachdem die Nachruestung direkt
+     darueber gelaufen ist. Haette der Umzug oben gestanden, waere er
+     genau dort gescheitert, wo es darauf ankommt: live. Lokal waere
+     nichts aufgefallen, weil jede Pruefung ihre Datenbank frisch
+     anlegt und `CREATE TABLE` die Spalte dann gleich mitbringt.
+
+     ZWEIMAL AUSFUEHRBAR: Eingetragen wird nur, wo es noch keine Zeile
+     gibt. Ein zweiter Start darf nichts verdoppeln.
+
+     DIE ALTEN SPALTEN BLEIBEN STEHEN und werden ab jetzt nicht mehr
+     GESCHRIEBEN. Sie wegzunehmen hiesse, die Tabelle neu zu bauen --
+     und genau dabei gingen am 11.09. die drei Spalten verloren.
+     Gelesen wird ab jetzt nur noch `support_bilder`; die alten Felder
+     sind Geschichte, kein zweiter Weg daneben. */
+  try {
+    const n = new Date().toISOString();
+    const ausMeldung = d.prepare(`
+      INSERT INTO support_bilder (meldung_id, runde_nr, datei, typ, breite, hoehe, erstellt)
+      SELECT m.id, NULL, m.bild_datei, m.bild_typ, m.bild_breite, m.bild_hoehe,
+             COALESCE(m.erstellt, ?)
+        FROM support_meldungen m
+       WHERE m.bild_datei IS NOT NULL
+         AND NOT EXISTS (SELECT 1 FROM support_bilder b
+                          WHERE b.meldung_id = m.id AND b.runde_nr IS NULL
+                            AND b.datei = m.bild_datei)`).run(n);
+    const ausRunde = d.prepare(`
+      INSERT INTO support_bilder (meldung_id, runde_nr, datei, typ, breite, hoehe, erstellt)
+      SELECT r.meldung_id, r.nr, r.urteil_bild_datei, r.urteil_bild_typ,
+             r.urteil_bild_breite, r.urteil_bild_hoehe, COALESCE(r.urteil_am, ?)
+        FROM support_runden r
+       WHERE r.urteil_bild_datei IS NOT NULL
+         AND NOT EXISTS (SELECT 1 FROM support_bilder b
+                          WHERE b.meldung_id = r.meldung_id AND b.runde_nr = r.nr
+                            AND b.datei = r.urteil_bild_datei)`).run(n);
+    const mit = (ausMeldung.changes || 0) + (ausRunde.changes || 0);
+    if (mit) console.log(`[support] ${mit} vorhandene Bilder nach support_bilder uebernommen.`);
+  } catch (fehler) {
+    console.error("[support] BILDER NICHT UEBERNOMMEN:", fehler?.message);
+  }
 }