main
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
72e51c57b6 |
Den Monatswechsel durchgespielt -- und zwei stille Fehler gefunden
Der zentrale Weg dieser Kachel war nie gelaufen: „Am 1. jedes Monats
um 00:00 Uhr starten alle Zaehler automatisch bei 0." Der erste
Oktober lag vor der Auslieferung, der erste November liegt dahinter.
Er laeuft ohne Zutun und betrifft alle gleichzeitig -- waere er
falsch, waere er fuer alle auf einmal falsch, und niemand wuesste
warum.
Dieselbe Lage gab es am 01.09.2026 schon einmal in RunOne (der Umbau
zur Hashkette war seit Tagen live und nie gelaufen). Die Lehre stand
danach in der Projektnotiz, und sie gilt hier woertlich: Was sich
nicht zuruecknehmen laesst, wird vorher auf einer Kopie durchgespielt.
`pruef-monatswechsel.mjs` verstellt dafuer die Uhr -- eine Huelle um
`Date`, ganz oben, vor jedem Import. Damit laeuft der ECHTE Code
durch zwei echte Monatswechsel (20. Oktober -> 1. November, 00:05 ->
3. Dezember), ohne dass eine Zeile dafuer umgebaut werden muesste.
41 Pruefungen, 0 Fehler: Zaehler bei 0, keine Warnung am ersten Tag,
die neuen Zielzahlen greifen, die alten Eintraege stehen unveraendert
da, der Oktober ist zu, der Verlauf misst ihn am OKTOBER-Ziel, und
„Neuer Monat" geht an alle drei -- auch an den, der den Oktober voll
hatte.
WAS DABEI AUFGEFALLEN IST -- zwei Fehler, beide stumm
1. DIE SUCHE NACH DEM ROLLENWECHSEL MASS DIE FALSCHE PERSON.
`WHERE person_id = ?` im Protokoll findet den, der die Aenderung
GEMACHT hat -- also DogFather --, nicht den, dessen Rolle sich
geaendert hat (workspace-personen.js schreibt die betroffene
Nummer ins `detail`). Fuer den Betroffenen fand die Abfrage
deshalb nie etwas; bei DogFather schob jede fremde
Rollenaenderung SEINEN Pflichtbeginn. In der echten Datenbank
stand bei ihm „grund: rollenwechsel" -- ein plausibler Wert aus
der falschen Zeile.
NACHGESEHEN, OB ES SCHADET: Alle sechs Zeilen stehen auf 2026-10,
und das ist ohnehin der frueheste moegliche Monat. Der Fehler
hatte noch keine Wirkung -- er haette sie beim naechsten
Rollenwechsel bekommen.
2. `node:sqlite` BINDET EINE ZAHL ALS REAL.
Der erste Versuch der Reparatur lautete
`detail LIKE ('#' || ? || ' %')` und traf NIE -- ohne Fehler, ohne
Warnung, immer leer. Nachgemessen:
SELECT ('#' || ? || ' %') mit der Zahl 42 -> '#42.0 %'
Gesucht wurde „#42.0 ", gespeichert ist „#42 ". Mit derselben Zahl
als Zeichenkette stimmt es sofort. Das Muster wird jetzt in
JavaScript gebaut; im uebrigen Haus kommt dieselbe Verkettung mit
einer Zahl nicht vor (nachgesehen).
Gefunden hat das nicht das Lesen, sondern eine Pruefung, die den
ECHTEN Weg benutzt (die Route der Personenverwaltung) statt den
Protokolltext selbst zu schreiben. Haette sie ihn selbst
geschrieben, haette sie ihre eigene Annahme geprueft und waere
gruen gewesen.
AUSSERDEM BERICHTIGT
Der Pflichtbeginn wurde EINMAL gesetzt und nie wieder angesehen
(`INSERT OR IGNORE`). Wer die Rolle verliert und spaeter zurueck-
bekommt, haette damit keinen Schonmonat mehr bekommen, obwohl die
Vorlage ihn zusichert. Jetzt wird neu gerechnet, wenn seit der
Festlegung ein Rollenwechsel dazugekommen ist -- und nur dann;
geprueft wird ausdruecklich, dass ein zweiter Abruf nichts bewegt.
GEPRUEFT: 216 + 41 = 257 Pruefungen, 0 Fehler
Mit drei Gegenproben an der neuen Stelle: DogFathers Pflichtbeginn
bewegt sich NICHT, wenn er die Rolle eines anderen aendert; ein
unbeteiligter Scout behaelt seinen Wert; und ein zweiter Abruf
rechnet nichts neu. Ohne die erste waere der Fehler von oben
unentdeckt geblieben, ohne die zweite hiesse „einer hat sich
geaendert" vielleicht „alle".
Co-Authored-By: Claude Opus 5 <[email protected]>
|