Die Zeitraum-Regel galt nur an einer Stelle -- Filipe fand die andere

"jetzt hab ich eine hochgeladen ber sehe sie nicht."

WAS PASSIERT IST, aus der Datenbank gelesen und nicht vermutet: Seine
Backstage-Ausgabe lief durch den EINZEL-Import ("Aus Datei einlesen")
und schrieb genau eine Zeile -- creator_id 2, Tag 2026-09-01, alle
Werte 0, Quelle "import", erfasst 11:52. Unsichtbar war sie aus zwei
Gruenden: Der 1. September liegt 13 Tage zurueck (die Liste zeigt
sieben), und es stand nichts darin.

DREI FEHLER AUF EINMAL, und alle drei waren meine:

1. DER ZEITRAUM-SCHUTZ STAND NUR IM BACKSTAGE-WEG. Ich hatte ihn heute
   frueh gebaut, gemessen, geprueft -- und an genau einer von drei
   Stellen eingesetzt. "2026-09-01 ~ 2026-09-11" wurde im Einzel-Import
   weiterhin zum 1. September.

   Das ist an diesem Tag das DRITTE Mal dieselbe Sache: eine Regel,
   zweimal aufgeschrieben, und die zweite Abschrift ist die
   unvollstaendige. Jetzt steht sie EINMAL in `tagAusZelle()` und wird
   dreimal benutzt. Sie liefert immer genau eines von beidem: Tag oder
   Grund -- nie beides, nie keines.

2. DIE DAUER-EINHEIT FEHLTE DORT EBENFALLS. Auch das hatte ich nur im
   Backstage-Weg eingesetzt.

3. DIE DATEI GEHOERTE GAR NICHT DORTHIN. Sie enthaelt ALLE
   Creator:innen; der Einzel-Import schreibt auf EINE Person. Es gab
   keine Fehlermeldung -- es passierte nur nichts Sichtbares, und das
   ist die schlechteste aller Antworten.

   Jetzt erkennt der Weg eine Namensspalte mit mehreren verschiedenen
   Eintraegen und sagt: "In dieser Datei stehen 3 verschiedene Creator
   (Spalte ...). Dieser Weg schreibt auf EINE Person. Nimm
   'Backstage-Tabelle einfuegen'." Mit Gegenprobe, dass eine Datei mit
   EINEM Creator weiterhin durchgeht.

pruef-xlsx 60 -> 67, pruef-backstage-import 82 -> 86.

NEBENBEFUND AUS DER EIGENEN PRUEFUNG: Mein Testfile fuer den
Einzel-Import hatte selbst zwei verschiedene Creator -- die neue Sperre
hat es sofort abgewiesen. Das war ihr erster echter Treffer, und es
zeigt, dass ich den Weg beim Schreiben der Pruefung selbst falsch
verstanden hatte. Jetzt steht dort, wofuer er da ist: eine Person,
mehrere Tage.

Die Zeile vom 1. September steht noch in der Datenbank. Sie zu
entfernen ist Filipes Entscheidung, nicht meine.

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

server/pruef-backstage-import.mjs

@@ -537,10 +537,14 @@ console.log("\n=== Die Seite ===");
      erste Entwurf schickte zehn Bytes "PK…" und war gruen, weil der
      Server "ZIP-Ende fehlt" meldete -- das haette auch bei kaputtem
      Leser gestimmt. */
+  /* EINE Person, ZWEI Tage -- dafuer ist dieser Weg da. Der erste
+     Entwurf hatte hier zwei verschiedene Creator; dass die neue Sperre
+     ihn abgewiesen hat, war ihr erster echter Treffer. */
+  const vortag = new Date(Date.now() - 2 * 86400000).toISOString().slice(0, 10);
   const xlsxDatei = xlsxBauen([
     ["Datum", "Creator", "Diamanten", "LIVE-Dauer"],
     [gestern, "@Nova_Live", "12.480", "3Std. 4Min."],
-    [gestern, "Kiro", "3.900", "1Std. 35Min."],
+    [vortag, "@Nova_Live", "3.900", "1Std. 35Min."],
   ]);
   await seite.click("#import-oeffnen");
   await seite.waitForTimeout(300);
@@ -561,6 +565,57 @@ console.log("\n=== Die Seite ===");
   ok(xlsx.text.includes("Diamanten") && xlsx.text.includes("LIVE-Dauer"),
     `die Vorschau nennt die erkannten Spalten ("${xlsx.text.slice(0, 55)}…")`);
 
+  /* ---- EINE DATEI MIT ALLEN CREATORN GEHOERT WOANDERS HIN ---------
+     (14.09.2026) Genau das ist Filipe passiert: Er hat seine
+     Backstage-Ausgabe -- eine Tabelle mit allen Creator:innen -- hier
+     hochgeladen. Dieser Weg schreibt auf EINEN Creator. Herausgekommen
+     ist eine Zeile mit lauter Nullen auf einem Tag, den er nicht mehr
+     sah; eine Fehlermeldung gab es nicht.
+
+     "Es passiert nichts Sichtbares" ist die schlechteste aller
+     Antworten. Jetzt sagt der Weg, WAS los ist und WOHIN die Datei
+     gehoert. */
+  const vieleLeute = xlsxBauen([
+    ["Datenzeitraum", "Creator*innen-Anmeldename", "Diamanten"],
+    [gestern, "nova_live", "12.480"],
+    [gestern, "kiro_on", "3.900"],
+    [gestern, "lumistreamt", "22.010"],
+  ]);
+  await seite.setInputFiles("#datei", {
+    name: "alle.xlsx",
+    mimeType: "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
+    buffer: vieleLeute,
+  });
+  await seite.waitForTimeout(1400);
+  const viele = await seite.evaluate(() => ({
+    fehler: document.getElementById("import-fehler")?.textContent || "",
+    vorschau: document.getElementById("vorschau")?.hidden,
+  }));
+  ok(viele.fehler.includes("3 verschiedene Creator"),
+    `die Datei mit drei Creatorn wird erkannt ("${viele.fehler.slice(0, 55)}…")`);
+  ok(viele.fehler.includes("Backstage-Tabelle"),
+    "und der richtige Knopf wird genannt");
+  ok(viele.vorschau === true, "es entsteht KEINE Vorschau -- geschrieben wird nichts");
+
+  /* GEGENPROBE: EIN Creator in der Datei geht weiterhin durch. Sonst
+     hiesse das oben nur, dass jede Datei mit Namensspalte abgewiesen
+     wird. */
+  await seite.setInputFiles("#datei", {
+    name: "einer.xlsx",
+    mimeType: "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
+    buffer: xlsxBauen([
+      ["Datenzeitraum", "Creator*innen-Anmeldename", "Diamanten"],
+      [gestern, "nova_live", "12.480"],
+    ]),
+  });
+  await seite.waitForTimeout(1400);
+  const einer = await seite.evaluate(() => ({
+    fehler: document.getElementById("import-fehler")?.textContent || "",
+    vorschau: document.getElementById("vorschau")?.hidden,
+  }));
+  ok(einer.vorschau === false && einer.fehler === "",
+    `eine Datei mit EINEM Creator kommt durch ("${einer.fehler.slice(0, 40)}")`);
+
   /* DIE ALTE .xls IST ETWAS ANDERES -- kein ZIP, sondern BIFF. Sie
      bekommt weiterhin eine Absage, und die muss WEITERHELFEN. */
   await seite.setInputFiles("#datei", {