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]>

workspace/assets/css/leistung.css

@@ -430,3 +430,69 @@
    eigenen Knoepfe. Gerollt wird INNEN, damit "Uebernehmen" immer
    erreichbar bleibt. */
 .dialog--breit .neu { max-height: min(86vh, 900px); overflow-y: auto; }
+
+/* =====================================================================
+   ZEITRÄUME AUS BACKSTAGE (14.09.2026)
+
+   Filipe: "sieh zu dass die excel auch so durch geht."
+
+   Sie stehen zwischen der Woche und den Tageszeilen -- gröber als ein
+   Tag, feiner als gar nichts. Und sie sehen ABSICHTLICH anders aus als
+   die Wochenkarten: Wer sie für Tageswerte hält, rechnet mit ihnen
+   weiter. Der Zeitraum steht deshalb ganz vorn und nicht als Beiwerk.
+   ===================================================================== */
+.leistung-spannen { margin: 26px 0 0; }
+.spannen__satz {
+  margin: 4px 0 12px;
+  font-size: .8rem; line-height: 1.55;
+  color: var(--text-still);
+  max-width: 62ch;
+}
+.spannen {
+  display: grid; gap: 10px;
+  grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
+}
+.spanne {
+  border: 1px solid var(--rand); border-radius: 14px;
+  padding: 11px 13px 12px;
+  background: rgba(255, 255, 255, .025);
+}
+.spanne__kopf {
+  display: flex; align-items: baseline; gap: 8px; flex-wrap: wrap;
+  margin-bottom: 8px;
+}
+.spanne__zeit {
+  font-size: .95rem; font-weight: 650; color: var(--text);
+  font-variant-numeric: tabular-nums;
+}
+/* Die Zahl der Tage ist die WICHTIGSTE Einordnung und trotzdem still:
+   "12.480 Diamanten" ueber drei Tage ist etwas anderes als ueber
+   dreizehn -- ohne diese Angabe sagt die Zahl nichts. */
+.spanne__tage {
+  font-size: .74rem; color: var(--text-still);
+  border: 1px solid var(--rand); border-radius: 999px;
+  padding: 1px 8px 2px;
+}
+.spanne__werte {
+  display: grid; gap: 3px 14px;
+  grid-template-columns: repeat(auto-fill, minmax(96px, 1fr));
+}
+.spanne__wert { display: flex; flex-direction: column; gap: 1px; min-width: 0; }
+.spanne__name {
+  /* .72rem = 11.52 px, knapp ueber der Lesbarkeitsgrenze von 11.5 px.
+     .68rem waeren 10.88 gewesen -- und eine gesperrte Versalzeile ist
+     ohnehin schwerer zu lesen als normale Schrift. Zum zweiten Mal an
+     diesem Tag derselbe Griff; deshalb steht die Zahl jetzt mit
+     Begruendung da und nicht nur als Wert. */
+  font-size: .72rem; letter-spacing: .07em; text-transform: uppercase;
+  color: var(--text-still);
+}
+.spanne__zahl {
+  font-size: .92rem; color: var(--text-leise);
+  font-variant-numeric: tabular-nums;
+}
+.spanne__schnitt {
+  margin: 9px 0 0; padding-top: 8px;
+  border-top: 1px solid var(--rand);
+  font-size: .76rem; color: var(--text-still);
+}