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/team.html

@@ -7,20 +7,20 @@
 <meta name="robots" content="noindex, nofollow" />
 <link rel="manifest" href="/workspace/app.webmanifest" />
 <meta name="theme-color" content="#06090f" />
-<link rel="icon" type="image/png" href="/assets/img/app-symbole/workspace-32.png?v=202609141428" />
-<link rel="apple-touch-icon" href="/assets/img/app-symbole/workspace-180.png?v=202609141428" />
-<link rel="stylesheet" href="assets/css/gate.css?v=202609141428" />
-<link rel="stylesheet" href="assets/css/start.css?v=202609141428" />
-<link rel="stylesheet" href="assets/css/aufgaben.css?v=202609141428" />
-<link rel="stylesheet" href="assets/css/team.css?v=202609141428" />
-<link rel="stylesheet" href="assets/css/module.css?v=202609141428" />
+<link rel="icon" type="image/png" href="/assets/img/app-symbole/workspace-32.png?v=202609141622" />
+<link rel="apple-touch-icon" href="/assets/img/app-symbole/workspace-180.png?v=202609141622" />
+<link rel="stylesheet" href="assets/css/gate.css?v=202609141622" />
+<link rel="stylesheet" href="assets/css/start.css?v=202609141622" />
+<link rel="stylesheet" href="assets/css/aufgaben.css?v=202609141622" />
+<link rel="stylesheet" href="assets/css/team.css?v=202609141622" />
+<link rel="stylesheet" href="assets/css/module.css?v=202609141622" />
 <!-- haus.css MUSS die letzte Stilvorlage sein (10.09.2026).
      Auf der Agenturadresse ist sie leer -- das Haus hier IST der
      Grundzustand. Auf der Adresse von Team Dogi biegt der Server
      genau diesen Dateinamen auf crew-haus.css um, und die Seite
      kommt schon beim ERSTEN Abruf in Lila und Babyblau an --
      ohne Umfaerben im Browser, ohne Flackern. -->
-<link rel="stylesheet" href="assets/css/haus.css?v=202609141428" />
+<link rel="stylesheet" href="assets/css/haus.css?v=202609141622" />
 </head>
 
 <body class="start">
@@ -110,10 +110,10 @@
 
 </main>
 
-<script src="assets/js/wahl.js?v=202609141428" defer></script>
-<script src="assets/js/bereiche.js?v=202609141428" defer></script>
-<script src="assets/js/kopf.js?v=202609141428" defer></script>
-<script src="assets/js/glocke.js?v=202609141428" defer></script>
-<script src="assets/js/team.js?v=202609141428" defer></script>
+<script src="assets/js/wahl.js?v=202609141622" defer></script>
+<script src="assets/js/bereiche.js?v=202609141622" defer></script>
+<script src="assets/js/kopf.js?v=202609141622" defer></script>
+<script src="assets/js/glocke.js?v=202609141622" defer></script>
+<script src="assets/js/team.js?v=202609141622" defer></script>
 </body>
 </html>