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]>
This commit is contained in:
2026-09-14 12:01:49 +02:00
co-authored by Claude Opus 5
parent 58932ece8c
commit 6ed61a6b3d
32 changed files with 518 additions and 372 deletions
+41
View File
@@ -303,6 +303,47 @@ console.log("\n=== Der dritte Ausgang ===");
zwei Werte, die jeder nachschlagen kann. Verrutscht die Basis um
einen Tag, faellt es hier auf und nicht erst in einer Tabelle.
======================================================================= */
console.log("");
console.log("=== Die eine Regel fuer den Tag ===");
{
/* DIE LUECKE, DIE FILIPE GEFUNDEN HAT (14.09.2026).
Der Zeitraum-Schutz stand am Vormittag nur im Backstage-Weg. Er
schickte seine echte Datei durch den EINZEL-Import -- dort fehlte
er, und es entstand eine Zeile mit lauter Nullen auf dem
1. September. Sichtbar war davon nichts: Der Tag lag 13 Tage
zurueck, und die Liste zeigt sieben.
Dieselbe Regel, zweimal aufgeschrieben, und die zweite Abschrift
war die unvollstaendige -- zum dritten Mal an einem Tag. Jetzt
steht sie EINMAL in tagAusZelle(), und diese Pruefung haelt fest,
dass sie beides kann: ablehnen UND durchlassen. */
const { tagAusZelle } = await import("./workspace-leistung.js");
const faelle = [
["2026-09-01 ~ 2026-09-11", null, "mehrere Tage"],
["2026-09-06 ~ 2026-09-06", "2026-09-06", null],
["2026-09-06", "2026-09-06", null],
["06.09.2026", "2026-09-06", null],
["65", null, "unlesbar"],
["", null, "unlesbar"],
];
for (const [text, sollTag, sollFehler] of faelle) {
const r = tagAusZelle(text);
if (sollTag) {
ok(r.tag === sollTag && !r.fehler,
`"${text}" wird zum Tag ${sollTag} (${r.tag || r.fehler})`);
} else {
ok(!r.tag && typeof r.fehler === "string" && r.fehler.includes(sollFehler),
`"${text}" wird abgelehnt und begruendet ("${(r.fehler || "").slice(0, 42)}…")`);
}
}
/* Und die Regel gibt NIE beides und nie keines zurueck -- sonst
entscheidet jeder Aufrufer selbst, was Vorrang hat. */
const alle = faelle.map(([t]) => tagAusZelle(t));
ok(alle.every((r) => (!!r.tag) !== (!!r.fehler)),
"sie liefert immer genau eines von beidem: Tag oder Grund");
}
console.log("");
console.log("=== Der Nullpunkt der Excel-Zeitrechnung ===");
{