Ein Zeitraum geht jetzt durch -- als Zeitraum, nicht als Tag

Filipe: "verbesser das, also ich will dass das auch so geht, mach dass
es funktioniert, ich will es so einfach und perfekt wie moeglich. also
sieh zu dass die excel auch so durch geht."

Backstage gibt eine Ausgabe fuer einen ZEITRAUM heraus --
"2026-09-01 ~ 2026-09-13", eine Zeile je Creator, alle Zahlen
aufsummiert. Am Vormittag wurde so eine Zeile abgewiesen. Jetzt geht
sie durch.

DREI WEGE WAEREN MOEGLICH GEWESEN, ZWEI DAVON WAEREN
ZAHLENFAELSCHUNG:
  * auf den ersten Tag schreiben -> dreizehn Tage auf einem Tag; die
    Zahl steht da, sie ist gross, sie sieht richtig aus, und niemand
    kann spaeter sagen, was darin steckt;
  * gleichmaessig verteilen -> erfundene Tage, die es nie gab.
Der dritte ist dieser: den Zeitraum ALS Zeitraum ablegen. Was drinsteht,
ist dann wahr -- und was er nicht sagt (welcher Tag wie lief),
behauptet er auch nicht.

EIGENE TABELLE UND NICHT EIN FELD IN `leistung`: Dort ist der
Schluessel (creator, tag). Ein Zeitraum ab dem 1. September wuerde mit
dem ECHTEN 1. September zusammenstossen, und eine der beiden Zahlen
waere weg. Getrennt kann keines das andere ueberschreiben -- und die
Wochenzahlen bleiben, was sie sind: aus Tagen gerechnet.

Der Schluessel ist (creator, von, bis): Dieselbe Datei zweimal
einzulesen ersetzt denselben Zeitraum, statt ihn zu verdoppeln.

AUF DER SEITE steht ein eigener Block zwischen Woche und Tageszeilen:
die Spanne vorn, die Zahl der Tage als Marke daneben, die Werte
darunter. Dazu EINE Umrechnung, und nur diese: "Ø 4.129 Diamanten pro
Tag" -- als Durchschnitt bezeichnet, nirgends gespeichert. Wer eine
Woche vergleichen will, braucht sie; wer sie fuer einen echten Tag
haelt, hat das Wort nicht gelesen. Darueber steht woertlich, dass diese
Zahlen nicht in die Wochenzahlen eingehen.

MIT DER ECHTEN DATEI GEMESSEN: alle 8 Zeilen gehen durch, 8 als
Zeitraum, 0 abgelehnt. Spanne 01.09.-11.09. = 11 Tage, Diamanten
53.679, Dauer 5171 Minuten.

pruef-backstage-import 86 -> 106. Die Pruefung, auf die es ankommt, ist
nicht "es wird gespeichert", sondern "es wird NICHT in die Woche
gemischt": kein Tag kommt hinzu, die Wochenzahl bleibt Ziffer fuer
Ziffer dieselbe. Dazu die Gegenprobe, dass ein Zeitraum von EINEM Tag
weiterhin ein Tag bleibt -- sonst hiesse alles andere nur, dass jetzt
alles als Zeitraum abgelegt wird.

DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT: Zwei behaupteten noch die
Ablehnung vom Vormittag. Und tagAusZelle() hat jetzt DREI Ausgaenge
statt zwei (Tag, Zeitraum, Grund) -- geprueft wird, dass nie zwei davon
gleichzeitig kommen. Gaebe es zwei, entschiede jeder Aufrufer selbst,
was Vorrang hat, und der zweite entschiede anders als der erste. Genau
daran ist heute frueh der Zeitraum-Schutz gescheitert.

ZWEI EIGENE MESSFEHLER, beide von der Pruefung gefunden: Ich verlangte
"kein einziger Tag in der Spanne" und uebersah, dass weiter oben schon
ein Tag geschrieben worden war, der hineinfaellt -- gemessen wird jetzt
die VERAENDERUNG. Und ich mass den Zeitraum-Block, waehrend ein anderer
Creator geoeffnet war: keine Frage an die Seite, sondern an die falsche
Person.

Nebenbei zum zweiten Mal heute: eine Versalzeile mit 10,88 px. Auf
.72rem angehoben, bevor pruef-css-klassen sie findet.

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

server/workspace.js

@@ -3250,6 +3250,55 @@ export function db() {
                        CHECK (quelle IN ('hand','import')),
         PRIMARY KEY (creator_id, tag)
       );
+
+      /* ZAHLEN FUER EINEN ZEITRAUM (14.09.2026).
+
+         Filipe: "ich will dass das auch so geht, mach dass es
+         funktioniert ... sieh zu dass die excel auch so durch geht."
+
+         Backstage gibt eine Ausgabe fuer einen ZEITRAUM heraus --
+         "2026-09-01 ~ 2026-09-13", eine Zeile je Creator, alle Zahlen
+         aufsummiert. Bis heute wurde so eine Zeile abgewiesen, weil
+         daraus kein Tageswert wird.
+
+         DREI WEGE WAEREN MOEGLICH GEWESEN, und zwei davon waeren
+         Zahlenfaelschung:
+           * auf den ersten Tag schreiben -> 13 Tage auf einem Tag,
+             sieht richtig aus, ist es nicht;
+           * gleichmaessig verteilen -> erfundene Tage, die es nie gab.
+         Der dritte ist dieser: den Zeitraum ALS Zeitraum ablegen. Was
+         drinsteht, ist dann wahr -- und was es nicht sagt (welcher Tag
+         wie lief), behauptet es auch nicht.
+
+         EIGENE TABELLE UND NICHT EIN FELD IN "leistung": Dort ist der
+         Schluessel (creator, tag). Ein Zeitraum ab dem 1. September
+         wuerde mit dem ECHTEN 1. September zusammenstossen -- und eine
+         der beiden Zahlen waere weg. Getrennt kann keines das andere
+         ueberschreiben, und die Wochenzahlen bleiben, was sie sind:
+         aus Tagen gerechnet.
+
+         DER SCHLUESSEL IST (creator, von, bis): Dieselbe Datei zweimal
+         einzulesen ersetzt denselben Zeitraum, statt ihn zu
+         verdoppeln. */
+      CREATE TABLE IF NOT EXISTS leistung_zeitraum (
+        creator_id     INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
+        von            TEXT NOT NULL,
+        bis            TEXT NOT NULL,
+        tage           INTEGER NOT NULL,
+        diamanten      INTEGER,
+        dauer_min      INTEGER,
+        gueltige_tage  INTEGER,
+        zuschauer_avg  INTEGER,
+        zuschauer_max  INTEGER,
+        verweildauer_s INTEGER,
+        schenker       INTEGER,
+        follower_neu   INTEGER,
+        erfasst        TEXT NOT NULL,
+        erfasst_von    INTEGER REFERENCES personen(id) ON DELETE SET NULL,
+        PRIMARY KEY (creator_id, von, bis)
+      );
+      CREATE INDEX IF NOT EXISTS idx_leistung_zeitraum_creator
+        ON leistung_zeitraum (creator_id, bis DESC);
       CREATE INDEX IF NOT EXISTS idx_leistung_tag ON leistung (tag DESC);
 
       /* ZIELE je Creator. Aus dem 90-Tage-Plan, den es im Profil schon