dogfather-universe

740 Commits 2 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	6ed61a6b3d	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]>	2026-09-14 12:01:49 +02:00
DogFatherGitandClaude Opus 5	58932ece8c	Excel-Dateien werden gelesen -- und drei Fallen dahinter entschaerft Filipe: "mach doch bitte so dass man alle dateien hoch laden könne auch excel dateien. gib gas und krieg das hin." server/workspace-xlsx.js liest .xlsx mit Bordmitteln: Eine .xlsx ist ein ZIP mit XML darin, und Node kann beides (`zlib.inflateRawSync`). Kein zusaetzliches Paket fuer eine Datei mit neun Zeilen. GEMESSEN AN ZWEI ECHTEN BACKSTAGE-AUSGABEN vom 11. und 12.09.2026, die auf dem Rechner lagen -- nicht an der Dokumentation. Sie haben mir an drei Stellen widersprochen, und JEDE davon waere sonst ein stiller Fehler geworden: 1. DER ZEITRAUM. In "Datenzeitraum" steht `2026-09-01 ~ 2026-09-11`. `datumLesen` griff sich davon den ersten Tag -- elf Tage Diamanten waeren auf den 1. September gebucht worden. Die Zahl steht da, sie ist gross, sie sieht richtig aus, und niemand kann spaeter sagen, dass elf Tage darin stecken. Neu: `zeitraumLesen`; eine Zeile mit einem Zeitraum ueber mehrere Tage wird abgelehnt UND begruendet ("Stell in Backstage den Zeitraum auf EINEN Tag"). Ein Zeitraum von einem Tag geht durch. 2. DIE EINHEIT. "LIVE-Dauer" enthaelt `86Std. 10Min. 52Sek.`. `zahlLesen` ergab daraus `null` -- die Dauer fiel weg. Bei einem anderen Trennzeichen waere es schlimmer gewesen: 86 statt 5171, Faktor 60 daneben und plausibel. Neu: `dauerLesen`, versteht die deutsche und englische Schreibweise, die Uhrzeitform und weiterhin die blosse Zahl. 3. DIE DATUMSSPALTE. `/datum\|date\|tag\|day/i` erklaerte "Tage seit dem Beitritt" zur Datumsspalte (Wert "65") und traf in der Leistungstabelle "Gueltige LIVE-Gehen-Tage" genauso. Jetzt nur noch als ganzes Wort, dafuer mit "zeitraum" -- Backstages Spalte wurde bisher nur zufaellig gefunden, weil in "Daten" die Silbe "date" steckt. Gefunden hat das keine Ueberlegung, sondern der ganze Weg einmal mit der echten Datei durchlaufen. WEITER GEBAUT: - Titelzeilen werden uebersprungen: "Creator:innen verwalten" hat in Zeile 1 nur "Exportiert am :…", die Ueberschriften stehen darunter. Die Regel misst (drei gefuellte Felder UND halb so breit wie die breiteste Zeile), statt eine feste Zahl zu nehmen. - Fehlende Zellen verschieben nichts: Eine leere Zelle steht in der Datei gar nicht; wer der Reihe nach liest, verrutscht ab dort jede Spalte, und die Zeile sieht voll aus. - Datums-Seriennummern werden nur umgerechnet, wenn das FORMAT es sagt (sonst stuende 46271 in der Vorschau). Der Nullpunkt ist an zwei nachschlagbaren Werten festgenagelt. - Der Backstage-Dialog nimmt die Datei jetzt AUCH -- dort gehoert sie hin, denn Filipes Ausgabe enthaelt alle Creator auf einmal. Sie fuellt das Einfuegefeld; ab da laeuft derselbe Weg wie beim Einfuegen. Keine zweite Fassung derselben Regeln. - Die alte .xls (BIFF, kein ZIP) wird erkannt und bekommt einen Weg gezeigt, statt "ging nicht" zu sagen. NEU: pruef-xlsx.mjs (60) -- baut seine Dateien selbst (ZIP-Schreiber in helfer-xlsx-bauen.mjs), damit keine Creator-Daten ins Repo wandern und auch Faelle pruefbar sind, die es als Datei nicht gibt: kaputtes Verzeichnis, fehlendes Blatt, abgeschnittene Datei. Jeder davon mit Gegenprobe, dass die heile Datei durchgeht. pruef-backstage-import 77 -> 82, dabei zwei Pruefungen GEDREHT: Die .xlsx bekommt keine Absage mehr, sondern eine Vorschau. DREI EIGENE FEHLER DABEI, alle von einer Messung gefunden: - Ich hielt Seriennummer 46264 fuer den 06.09.; es ist der 30.08. Der Code hatte recht. Deshalb stehen jetzt zwei nachschlagbare Anker drin. - Eine Zeile war gruen, weil mein Muster den SPALTENNAMEN "Datenzeitraum" traf statt der Begruendung. Jetzt wird auf den Text der Ablehnung geprueft. - Beim Umbau habe ich pruef-backstage-import beschaedigt (ein Suchtreffer weiter oben als gemeint) und aus Git zurueckgeholt. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-14 11:35:21 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

6ed61a6b3d

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

2026-09-14 12:01:49 +02:00

DogFatherGitandClaude Opus 5

58932ece8c

Excel-Dateien werden gelesen -- und drei Fallen dahinter entschaerft

Filipe: "mach doch bitte so dass man alle dateien hoch laden könne auch
excel dateien. gib gas und krieg das hin."

server/workspace-xlsx.js liest .xlsx mit Bordmitteln: Eine .xlsx ist ein
ZIP mit XML darin, und Node kann beides (`zlib.inflateRawSync`). Kein
zusaetzliches Paket fuer eine Datei mit neun Zeilen.

GEMESSEN AN ZWEI ECHTEN BACKSTAGE-AUSGABEN vom 11. und 12.09.2026, die
auf dem Rechner lagen -- nicht an der Dokumentation. Sie haben mir an
drei Stellen widersprochen, und JEDE davon waere sonst ein stiller
Fehler geworden:

1. DER ZEITRAUM. In "Datenzeitraum" steht `2026-09-01 ~ 2026-09-11`.
   `datumLesen` griff sich davon den ersten Tag -- elf Tage Diamanten
   waeren auf den 1. September gebucht worden. Die Zahl steht da, sie
   ist gross, sie sieht richtig aus, und niemand kann spaeter sagen,
   dass elf Tage darin stecken. Neu: `zeitraumLesen`; eine Zeile mit
   einem Zeitraum ueber mehrere Tage wird abgelehnt UND begruendet
   ("Stell in Backstage den Zeitraum auf EINEN Tag"). Ein Zeitraum von
   einem Tag geht durch.

2. DIE EINHEIT. "LIVE-Dauer" enthaelt `86Std. 10Min. 52Sek.`.
   `zahlLesen` ergab daraus `null` -- die Dauer fiel weg. Bei einem
   anderen Trennzeichen waere es schlimmer gewesen: 86 statt 5171,
   Faktor 60 daneben und plausibel. Neu: `dauerLesen`, versteht die
   deutsche und englische Schreibweise, die Uhrzeitform und weiterhin
   die blosse Zahl.

3. DIE DATUMSSPALTE. `/datum|date|tag|day/i` erklaerte "Tage seit dem
   Beitritt" zur Datumsspalte (Wert "65") und traf in der
   Leistungstabelle "Gueltige LIVE-Gehen-Tage" genauso. Jetzt nur noch
   als ganzes Wort, dafuer mit "zeitraum" -- Backstages Spalte wurde
   bisher nur zufaellig gefunden, weil in "Daten" die Silbe "date"
   steckt.

Gefunden hat das keine Ueberlegung, sondern der ganze Weg einmal mit
der echten Datei durchlaufen.

WEITER GEBAUT:
- Titelzeilen werden uebersprungen: "Creator:innen verwalten" hat in
  Zeile 1 nur "Exportiert am :…", die Ueberschriften stehen darunter.
  Die Regel misst (drei gefuellte Felder UND halb so breit wie die
  breiteste Zeile), statt eine feste Zahl zu nehmen.
- Fehlende Zellen verschieben nichts: Eine leere Zelle steht in der
  Datei gar nicht; wer der Reihe nach liest, verrutscht ab dort jede
  Spalte, und die Zeile sieht voll aus.
- Datums-Seriennummern werden nur umgerechnet, wenn das FORMAT es sagt
  (sonst stuende 46271 in der Vorschau). Der Nullpunkt ist an zwei
  nachschlagbaren Werten festgenagelt.
- Der Backstage-Dialog nimmt die Datei jetzt AUCH -- dort gehoert sie
  hin, denn Filipes Ausgabe enthaelt alle Creator auf einmal. Sie fuellt
  das Einfuegefeld; ab da laeuft derselbe Weg wie beim Einfuegen. Keine
  zweite Fassung derselben Regeln.
- Die alte .xls (BIFF, kein ZIP) wird erkannt und bekommt einen Weg
  gezeigt, statt "ging nicht" zu sagen.

NEU: pruef-xlsx.mjs (60) -- baut seine Dateien selbst (ZIP-Schreiber in
helfer-xlsx-bauen.mjs), damit keine Creator-Daten ins Repo wandern und
auch Faelle pruefbar sind, die es als Datei nicht gibt: kaputtes
Verzeichnis, fehlendes Blatt, abgeschnittene Datei. Jeder davon mit
Gegenprobe, dass die heile Datei durchgeht.

pruef-backstage-import 77 -> 82, dabei zwei Pruefungen GEDREHT: Die
.xlsx bekommt keine Absage mehr, sondern eine Vorschau.

DREI EIGENE FEHLER DABEI, alle von einer Messung gefunden:
- Ich hielt Seriennummer 46264 fuer den 06.09.; es ist der 30.08. Der
  Code hatte recht. Deshalb stehen jetzt zwei nachschlagbare Anker drin.
- Eine Zeile war gruen, weil mein Muster den SPALTENNAMEN
  "Datenzeitraum" traf statt der Begruendung. Jetzt wird auf den Text
  der Ablehnung geprueft.
- Beim Umbau habe ich pruef-backstage-import beschaedigt (ein
  Suchtreffer weiter oben als gemeint) und aus Git zurueckgeholt.

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

2026-09-14 11:35:21 +02:00